[Standards] Proposed XMPP Extension: Unique and stable message IDs

Kurt Zeilenga kurt.zeilenga at isode.com
Thu Jun 4 10:56:40 UTC 2015

It’s not clear to me that the problems that this extensions proposes to address can be addressed through use an extension to XMPP.  Extensions ought to be truly optional.  This ProtoXEP appears to be making mandates which are more appropriate made, if the community were to support them being made, in a revision of the XMPP base specification.

For instance, the ProtoXEP not only says "XMPP entities, which are routing stanzas, MUST NOT strip the message-id element from message stanzas” but seems to be rely on all servers adhering to this MUST NOT.  That’s never going to be case… certainly not for implementations not purporting to implement this extension… and likely not for some implementations which might purport to implement this extension.   This spec needs to consider and discuss what happens in face of elements it suggests be added are stripped by another entity.

I have a big problem with one ID to rule them all… and a bigger problem with the last ID being that ID (the overrride requirement).   To the extent IDs are needed, they need to “stable”.  This means they cannot be overridden.

For operational and security reasons, it unwise for one entity to rely on IDs for services it provides (such as MAM) provide by some other entity.  To the extent IDs are needed, we need per-entity IDs… possibly even per-enitty handling IDs (that is, when an IM handles a stanza for the second time (such as after being handled by an MUC service, it might need to separately ID the stanza).  This because stanza content can and will change as its handled by other entities.

It’s not clear to me how this id provided by this extension would or could be used in message type=error stanzas.  It’s not clear to me why this extension proposes a <message/> only solution, when it seems likely that stanza id= problems are not necessarily specific to message stanzas.

It seems that there’s many security risks here associated with ID forgery, replay, etc., but I’m not sure what, if any, mitigation is needed.

I suggest instead an element allowing entities to provide IDs in stanzas they originate or handle.

	<stanza-id xmlns=‘…’ id=‘ID’ provider=“JID”/>

where ID is some opaque ID and JID is the providers JID.  Servers which need to provide different IDs in different contexts can use different JIDs.  (or possibly better to allow a context attribute or something).

I’m not convinced having an extension providing an ID (whether by the ProtoXEP suggestion or mine or other) reliably solves any problem I’m faced with.

For the MUC use case, I rather we solve this as part of the MUC2 effort…

For the MAM case, to the extent what it offers in the current Experimental XEP is not sufficient, I suggest MAM XEP be modified to provide for reliable identification of archived content.

— Kurt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150604/a2f4e922/attachment.html>

More information about the Standards mailing list