[Standards] Proposed XMPP Extension: Message Fastening

Florian Schmaus flo at geekplace.eu
Wed Dec 18 12:18:27 UTC 2019


On Wed, Dec 18, 2019, 13:03 Dave Cridland <dave at cridland.net> wrote:

>
> On Wed, 18 Dec 2019 at 11:00, Florian Schmaus <flo at geekplace.eu> wrote:
>
>> On 12/11/19 6:10 PM, Kevin Smith wrote:
>> >> On 9 Sep 2019, at 20:37, Florian Schmaus <flo at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191218/ffcddfee/attachment.html>


More information about the Standards mailing list