[Standards] Using route-able JIDs in MIX-CORE

Kevin Smith kevin.smith at isode.com
Mon Jun 4 06:56:29 UTC 2018



> On 3 Jun 2018, at 17:32, Steve Kille <steve.kille at isode.com> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: Standards <standards-bounces at xmpp.org> On Behalf Of Florian
>> Schmaus
>> Sent: 03 June 2018 17:27
>> To: XMPP Standards <standards at xmpp.org>
>> Subject: Re: [Standards] Using route-able JIDs in MIX-CORE
>> 
>> On 03.06.2018 18:01, Steve Kille wrote:
>>>>> That very much looks like that I would currently favour, besides
>>>>> that I don't see a reason why we shouldn't also use the stable
>>>>> participant identifier as the resourcepart of the originating address.
>>>> 
>>>> Uh, and I slightly favour presence also from
>>>> 
>>>> channel at mix.service/stable-participant-id/unique-client-id
>>>> 
>>>> as otherwise you will get presence from different devices from the
>>>> same address. But presence from users with multiple devices is not
>>>> trivial anyway, not only in the context of MIX, so no matter what we
>>>> do, someone has to handle it. I still prefer keeping the invariant
>>>> that presence comes from a unique address per user session, because I think
>> it has the potential to make things easier.
>>> 
>>> [Steve Kille]
>>> 
>>> This is an important point.    All of the information needed is carried in the
>> message.    So a change like this does not provide any more information to the
>> final recipient.
>>> 
>>> However, it means that the JID will be unique for each sending client.   This can
>> facilitate an implementation handling JIDs internally, by enabling sensible
>> switching of messages.
>>> 
>>> If we do this,  I think that it makes sense (for similar reasons) to
>>> have messages sent from a JID that uniquely identifies the sender of
>>> form:  channel at mix.service/stable-participant-id
>> What exactly do you mean with "uniquely identifies the sender"? The sending
>> entity? Or a concrete XMPP session of the sending entity?
>> 
>> Where are possibly a little bit ouf of sync here. Therefore I try to summarize the
>> approach I currently champion:
>> 
>> 1.) message stanza originate from channel at mix.service/stable-participant-id
>> 
>> Rationale: The tuple of channel, service and stable participant id consists of the
>> most valuable information of message receiving entities in the context of
>> persisent groupchats. The unique client id, identifying the concrete sending
>> client(/user session) can be put as (possibly optional) metadata into an extension
>> element of the message.
>> 
>> 2.) presence stanzas originate from
>> channel at mix.service/stable-participant-id/client-id
>> 
>> To keep the invariant that distinct from addresses in presence stanzas represent
>> distinct clients(/user sessions).
>> 
>> 3.) IQ requests usually send to / received from channel at mix.service/stable-
>> participant-id/client-id
>> 
>> To allow us to address a particular client for IQ exchange. (We could add IQ
>> semantics for channel at mix.service/stable-participant-id later on, but I'm
>> undecided yet if it is a good idea)
>> 
>> Bonus points if:
>> - Messages send to channel at mix.service are standard groupchat messages
>> - Messages send to channel at mix.serivce/stable-paticiapnt-id are send to a
>> participant (PMs, e.g. fan-out via carbons, most available resource, …)
>> - Messages send to channel at mix.service/stable-participant-id/client-id
>> are send to single XMPP session of the participant identified by client-id (IBB (?)).
>> 
>> - Florian
> [Steve Kille] 
> 
> I would be happy with this.    I think it reflects what my message said and is aligned to variant 2.   I note that only 1/2 are needed to sort out MIX-CORE/MIX-PAM/MIX-PRESENCE
> 
> 3 and bonus stuff only impacts MIX-ANON.

I don’t think that’s so - if you’re suggesting you could use a real JID for messaging just because you have it available, this isn’t true.

/K


More information about the Standards mailing list