> On 28 Sep 2016, at 18:38, Kevin Smith <[email protected]> wrote:
>
> On 27 Sep 2016, at 10:06, Tobias M <[email protected]
> <mailto:[email protected]>> wrote:
>>
>>
>>> On 27 Sep 2016, at 00:33, Kevin Smith <[email protected]
>>> <mailto:[email protected]>> 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?
Cheers,
Tobi
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
