[Standards] Proposed XMPP Extension: Unique and stable message IDs
flo at geekplace.eu
Sun Jun 7 18:38:52 UTC 2015
On 04.06.2015 12:56, Kurt Zeilenga 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.
Possible, but a revision of the XMPP RFC changing the semantic and
requirements of the 'id' attribute of stanzas in such a way won't ever
happen I'd say. Yes, XEP-MID breaks if entities strip it out. But I can
live with that.
> 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
As far as the use case is concerned where the ID attribute would get
"overridden", it's not really overriding an existing ID. Maybe the XEP
should use other terminology here. I full agree that stable IDs cannot
> 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
MAM IDs are never provided by another entity then the MAM archive
itself. At least that is my understanding of how MAM will/should work.
> It’s not clear to me how this id provided by this extension would or
> could be used in message type=error stanzas.
That's simple: MIDs are not at all used for 'error' type messages.
> 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 was intentionally designed to be a solution for message stanzas only.
I can't think why would want unique and stable messages IDs, like they
are required to build an archive of stanza, for IQs and presences. IQ
are simple request-response mechanisms and presence are ... Hmm, ok so
maybe there is a reason one would archive presences in MAM (if we leave
the privacy implications aside). That's actually a good point. What do
the others think? I'm happy to s/message-id/stanza-id/.
> 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.
Spoofing is actually a valid security concern. That is why XEP-MID
states those strict business rules.
> For the MUC use case, I rather we solve this as part of the MUC2 effort…
I don't want to wait for MUC2, I want to solve
cant-track-my-own-messages-in-muc issue right now, as it's pretty simple
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 603 bytes
Desc: OpenPGP digital signature
More information about the Standards