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. > > 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. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
