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
