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

Dave Cridland dave at cridland.net
Thu Jun 4 14:20:39 UTC 2015

I'm in broad agreement with what Kurt writes below.

I think the only point where we differ is that the "does MUC issue new ids"
question is really one we could answer now (and if not directly answer,
certainly fix).

I would also add that using the stanza's id and from attributes, plus a
(possibly server-provided) public tracking identifier for the stream,
should be unique - and in at least most cases where we care we can mandate

On 4 June 2015 at 11:56, Kurt Zeilenga <kurt.zeilenga at isode.com> wrote:

> 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/57ae0d24/attachment.html>

More information about the Standards mailing list