[Standards] Proposed XMPP Extension: Content Types in Messages

Matthew Wild mwild1 at gmail.com
Wed Jan 20 17:46:17 UTC 2016

On 19 January 2016 at 16:49, XMPP Extensions Editor <editor at xmpp.org> wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> Title: Content Types in Messages
> Abstract: This specification describes a generic method whereby content in messages can be tagged as having a specific Internet Content Type. It also provides a method for sending the same content using different content types, as a fall-back mechanism when communicating between clients having different content type support.
> URL: http://xmpp.org/extensions/inbox/content-types.html
> The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP.

I just voted against this proposal today, for the following reasons:

 - I'm not seeing any consensus in favour of this approach on the
list. Mostly only concerns.

 - I don't believe the problem the specification was written to solve
(including markdown *and* "plaintext" in a single message) is a
problem that needs solving. We already have a standard for
communicating plaintext content (<body/>) and a standard for
communicating formatted content (XHTML-IM). I don't think we need any

 - Adding more (optionally rendered) representations of the content
into a single message increases bandwidth. There is no mechanism to
discover what content types the recipient will understand. Such a
discovery mechanism, if added, would also be complicated (e.g. the
recipient may not be online).

 - Adding more (optionally rendered) representations of the content of
a message introduces further complication into knowing which version
of the content any particular client will display, potentially leading
to security concerns.

 - Unclear interaction with XEPs that encrypt the plaintext content in
a message.

 - Unclear interaction with archiving (e.g. which version(s) of the
content should be archived?)

 - Unclear interaction with xml:lang

 - Not interoperable with existing clients (some of which already
support markdown, and *are* interoperable with other existing clients,
thanks to <body> and XHTML-IM), it is just causing fragmentation and
yet another markup format for clients to implement if they want to
render formatted messages.

 - Finally, regarding Markdown specifically, many noted there is no
commonly-accepted standard, so a simple mimetype would not be enough
to unambiguously describe the format of the content in this case


More information about the Standards mailing list