[Standards] Proposed XMPP Extension: Content Types in Messages

Thijs Alkemade me at thijsalkema.de
Tue Jan 19 19:07:05 UTC 2016

> On 19 jan. 2016, at 17: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.

The Security Considerations section of this proto-XEP is missing, though
XEP-0001 §12 requires every XEP to have one. For this XEP, I don't think an
empty section would suffice because it really should discuss consistency.

Should a client try protect the user from receiving a message that contains
multiple content types with completely different meanings? If I'm reading back
the log of a conversation on a different device, can I trust that the messages
I see there are the same messages I actually responded to? The conversation
could be completely different on two clients supporting different sets of
content types. This can be abused quite easily to scam people or to create
incriminating logs.

Yes, we already have the same problem with XEP-0071, but with only two
different formats it is still manageable to fix it, for example by deprecating
the use of <body/>. If we add the ability to add many different
representations to a message then consistency will be a lost cause forever.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160119/25c34e14/attachment.sig>

More information about the Standards mailing list