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