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