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

Steve Kille steve.kille at isode.com
Sun Jun 3 16:32:24 UTC 2018



> -----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.

What do others think?     Can we build a consensus around this?


Steve





More information about the Standards mailing list