On 28 Sep 2016, at 21:18, Tobias M <tmarkm...@googlemail.com> wrote: > >> >> On 28 Sep 2016, at 18:38, Kevin Smith <kevin.sm...@isode.com> wrote: >> >> On 27 Sep 2016, at 10:06, Tobias M <tmarkm...@googlemail.com> wrote: >>> >>> >>>> On 27 Sep 2016, at 00:33, Kevin Smith <kevin.sm...@isode.com> wrote: >>>> >>>>> However, it has little discussion on why there is this restriction. While >>>>> it certainly is a MUST for security reasons in MUC situations where >>>>> different full JIDs are different accounts (i.e. associated to different >>>>> bare JIDs), it is less so for security reasons in the non-MUC case. >>>> >>>> I think one can construct other situations like MUC, where multiple people >>>> control different resources of the same bare JID, but maybe that’s >>>> pathological (although I’m not sure). >>> >>> If multiple people would use different resources of the same bare JID, this >>> would also lead to strange UX regarding Carbons where the user will see >>> messages as sent which they didn’t write. I think this is a rather rare >>> edge case we shouldn’t put much efforts in to support. >> >> That may well be true. >> >>> >>>> >>>>> I’ve shortly discussed it with other community members in the XSF >>>>> chatroom [1], but thought I’d bring it up here for discussion with a >>>>> wider audience, while providing a short summary of the room discussions >>>>> below: >>>>> >>>>> When would a client send an correction for a message from another account >>>>> resource? Two cases come to mind: >>>>> a) Carbons, editing a message from another client when you switch clients >>>>> mid-discussion. >>>> >>>> Certainly in this case we’d want to be able to correct them. >>>> >>>>> b) Reconnection, where a client has the server assign it a resource. >>>> >>>> Which is more or less the same instance as (a), I think. >>>> >>>>> What do you think? Do you have further comments on this issue? >>>> >>>> I think there’s also a concern that different resources may use the same >>>> IDs. Perhaps we should be moving away from using stanza IDs for this, and >>>> move towards something like 359 (although 359 has the client-id, stanza-id >>>> oddity which we should probably fix at some point and just use multiple >>>> stanza-id stamps with the relevant ‘by’ instead). >>> >>> Aren’t stanza IDs supposed to be UUIDs, i.e. unique? XEP-0359 could provide >>> a solution if we can’t rely on unique and stable stanza IDs. It’s not >>> discussed in XEP-0359, but I guess it’s the reason for its existence, that >>> stanza IDs may only be stable/unique regarding one XMPP stream and might >>> change in a multi-hop routing like C-to-S -> S-to-S -> S-to-C or C-to-S -> >>> MUC -> S-to-C. >> >> Sadly not, 6121 says >> " It is up to the originating entity whether the value of the 'id' >> attribute is unique only within its current stream or unique >> globally.” > > So, basically XEP-0308 should adopt XEP-0359 in a new version (probably > requires namespace version bump) and use the sender's ID for replacements? Is > that what you suggest?
It doesn’t seem to be a stupid approach, to me, at least. It has the advantage of working in MUCs that do stanza id rewriting, too, as well as working through MAM and Carbons, etc. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
