[Standards] MIX Addressing

Steve Kille steve.kille at isode.com
Fri Jun 1 02:13:18 UTC 2018


> On Donnerstag, 31. Mai 2018 13:45:06 CEST Kevin Smith wrote:
> > 1) Stick with proxy JIDs and user%channel at domain[/resource] (or
> > similar), with the resource missed off for bare-JID traffic, where
> > ‘user%channel at domain’ as the proxy JID is the user’s identifier used
> > everywhere.
> > 2) Drop proxy JIDs, use channel at domain/user[/resource] and then ‘user’
> > is just a string identifier for the user, of whatever format (as long
> > as it doesn’t contain ‘/‘).
> While discussing about both options in xsf@ with MattJ, we realized that both
> approaches have the same issue, but in a different part of the JID:
> Information about identities is merged in a part of the JID.
[Steve Kille] 

I think this is exactly right.  Your detailed notes set out downsides of each approach.

I think that variant 2 leads to cleaner syntaxes.

However,  I am very much convinced by the argument you made in your previous message: 
        " I very much prefer the semantics of (1). The reason is that about everywhere (except MUC) you can assume that equal bare JID implies equal identity. I would very much like to have that in MIX."

I am thinking that rather than the term "Proxy JID" it would be clearer to move to the term "Participant JID", that makes clear that this encoded JID is representing the participant in the channel.

> So here’s a straw-man proposal, Variant 3 (because, creating many variants is
> what we’re good at!):
> An occupant is identified by an occupant-identifier. The occupant JID is
> occupant-identifier at mix-service. The channel to which a message belongs is
> identified with a payload item. Example message:
>   <message type="groupchat"
>            from="4973d5d365f8 at mixservice.domain.example/client-resource"
>            to="user at other.example">
>     <mix channel="some-channel"/>
>     <body>...</body>
>   </message>

[Steve Kille] 

I really hate this.   There is a natural hierarchy:  mix domain -> channel -> user.     You really want all of these in the Participant JID.  

Variant 3 gives JIDs that are independent of MIX channel, and this feels very wrong.  You could have MIX channels in a domain with entirely different administrators and access control.   Having JIDs that might belong to any channel leads to cross-channel dependencies that seem very desirable to avoid.  In MIX-PAM,  I really feel you want routing to be based on the JID.


More information about the Standards mailing list