On Wed, Dec 18, 2019, 13:03 Dave Cridland <d...@cridland.net> wrote: > > On Wed, 18 Dec 2019 at 11:00, Florian Schmaus <f...@geekplace.eu> wrote: > >> On 12/11/19 6:10 PM, Kevin Smith wrote: >> >> On 9 Sep 2019, at 20:37, Florian Schmaus <f...@geekplace.eu> wrote: >> >> On 9/5/19 7:52 PM, Jonas Schäfer (XSF Editor) wrote: >> >>> The XMPP Extensions Editor has received a proposal for a new XEP. >> >>> >> >>> Title: Message Fastening >> >>> Abstract: >> >>> This specification defines a way for payloads on a message to be >> >>> marked as being logically fastened to a previous message. >> >>> >> >>> URL: https://xmpp.org/extensions/inbox/fasten.html >> >> >> >> Thank you, Kev for pushing this forward. I think the kind of attention >> >> this ProtoXEP already has received, shows that the XMPP ecosystem needs >> >> such a XEP and the community desires one. >> >> >> >> I want to suggest one small change to how the attached-to message is >> >> specified: I always assumed that, if xep359 is used to refer a message, >> >> the reference would not just be the id-value, but a tuple of id-value >> >> and the id-assigning-entity address. >> >> This avoids ambiguity if a <apply-to/> attaches to a stanza which >> >> multiple <stanza-id/> elements. Furthermore, xep359 makes it very clear >> >> that xep359-IDs are just unique and stable within the scope of the >> >> id-assigning-entity (this allows implementations to use simple >> >> mechanisms to generate the ID without considering collisions with other >> >> id-assigning-entities). >> > >> > Good point, thanks Flo. Although I’m not sure that 359 does make it >> clear that it’s not globally unique >> >> The XEP currently states >> >> The value of the 'id' attribute must be unique and stable, i.e. it MUST >> NOT change later for some reason within the scope of the 'by' value. >> Thus the IDs defined in this extension MUST be unique and stable within >> the scope of the generating XMPP entity. >> >> which tries to express this, but the wording can (and should) probably >> be improved. >> >> , actually the opposite - I believe it’s a SHOULD on using UUID, >> >> No, it is just a friendly recommendation to simply use UUIDs, not a >> SHOULD. >> > > It says RECOMMENDED, which is, according to RFC 2119, the same as SHOULD. > So the specification already says (more or less) that if you want to do > anything else, you need to understand why what you're doing is almost > certainly wrong. >
My fault, I sometimes forget that those are equal. Sorry about that. In the XEP it was meant to be just a friendly recommendation that developers could simply use the UUID library of their platform to generate the xep359 IDs. It shouldn't have been an all caps RECOMMENDED. > >> > and my understanding has always been that these are intended to be >> globally unique (I realise you have authority on claims of the original >> intention) from reading it. This isn’t the only XEP that’s written on the >> basis of the unique IDs being unique :) >> >> Oh, the IDs are unique. But only if you concatenate the 'by' value with >> the ID. Or, in other words, the tuple (xep359-id, xep359-id-by) is >> guaranteed by xep359 to be globally unique. >> >> One reason why xep359 makes this distinction is to prevent ID spoofing. >> Consider an archive which contains a message with the xep359-id 'id1' >> and another user now refers to this message just using 'id1'. If now an >> (malicious) entity would be able to add to the archive another message >> with the same xep359-id 'id1', but a different xep359-id-by value, then >> it is not clear anymore which message is refereed to. >> >> Hence one should always use the tuple (xep359-id, xep359-id-by) when >> referring to stanzas using xep359 IDs. And this is the coordinate system >> fastening should use to establish a link to other messages. >> > > I don't think that existing specifications which refer to XEP-0359 have > made the distinction. Many have decided only to trust identifiers from a > particular source, but not that such identifiers are only unique within the > scope of a particular jid. > Which existing specifications are that? I tried to closely monitor xep359 usages, but can't rule out that I missed some. - Florian
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
