On 19 January 2016 at 16:49, XMPP Extensions Editor <[email protected]> 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 more. - 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 anyway. Regards, Matthew _______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
