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

Florian Schmaus 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
> overridden.

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
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. 

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
to solve.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150607/9d986e74/attachment.sig>


More information about the Standards mailing list