> -----Original Message----- > From: Standards <standards-boun...@xmpp.org> On Behalf Of Florian > Schmaus > Sent: 03 June 2018 17:27 > To: XMPP Standards <standards@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@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@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@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@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@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@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@mix.service are standard groupchat messages > - Messages send to channel@mix.serivce/stable-paticiapnt-id are send to a > participant (PMs, e.g. fan-out via carbons, most available resource, …) > - Messages send to channel@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 _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
