[Standards] Proposed XMPP Extension: Compatibility Fallbacks

Dave Cridland dave at cridland.net
Sun Jan 9 20:50:17 UTC 2022

On Sun, 9 Jan 2022 at 13:38, Marvin W <xmpp at larma.de> wrote:

> On 09.01.22 13:24, Dave Cridland wrote:
> > Still, as written, the ability send a message which is rendered in
> > *radically* different ways in different clients just fills me with
> > unease. Fallback bodies are nasty like this - it's why I've never been
> > happy with the "multipart/alternative" style of XHTML-IM, for example
> "multipart/alternative" style as you call it is being used in e-Mail for
> centuries. I might also be worth looking at other modern messengers like
> Matrix, which transports html and plain text as alternatives
> [https://spec.matrix.org/unstable/client-server-api/#mroommessage-msgtypes
> ].

Yes, I'm aware that "multipart/alternative" is used in email, hence my
usage of that particular MIME type to describe the style (I wouldn't say
centuries though - I remember MUAs getting MIME support as an exciting new

It doesn't surprise me that it's repeated in Matrix - it seems like a
practical, sensible idea at first, and it was the only reasonable option
for email, which prior to this had just plaintext ASCII email bodies. It
was generally impossible to update software on your workstation as well,
since (for most people) you only had user level access.

I'd still argue that it's a bad idea these days, even if Matrix haven't
learned from the trouble it's caused in email. Most other proprietary
messaging apps just have one form, the only reason email (and us, and
Matrix) went for alternatives is because of an existing deployed base that
only understood plaintext. This causes not only the problem of messages
having potentially wildly different meanings between the alternatives, but
also you can never get rid of the compatibility layer.

We (like Matrix) would have been better off without it - content
negotiation or graceful degradation are always better options when
available, and upgrading client software is vastly simpler than it used to
be as well.

RFC 1341, which introduced multipart/alternative, also introduced the
MIME-Version header. We repeated that error too - both our versions are
stuck forever at "1.0". (Mark Crispin actually predicted that one back in
1990 or so).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20220109/4bdf60c5/attachment.html>

More information about the Standards mailing list