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 it. On 4 June 2015 at 11:56, Kurt Zeilenga <kurt.zeile...@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 >
