[Standards] MIX Addressing

Jonas Wielicki jonas at wielicki.name
Thu May 31 20:43:37 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. 

Different infrastructure components will have different issues with this:

- Servers might want to block a MIX channel from sending stuff to the user, so 
they want to know the MIX identity a message is coming from. For this, Variant 
2 is more convenient (bare JID == Channel).

- Clients might want to operate on occupant identities (as I mentioned 
elsewhere), and for this Variant 1 is more convenient (bare JID == Occupant).

In both variants, one component will have to deal with special-casing MIX JIDs 
in places which normally would not have to know about MIX. The bad thing here 
is that a non-RFC6122 operation on JIDs is needed, which are otherwise fairly 
well defined. This also has implications with respect to length limits in the 
different parts of the JID. In variant 2, the server would have to Address-
Translate the users resource to prevent the resourcepart from exceeding limits 
in edge cases. In variant 1, the MIX channel identifier would be restricted by 
the length of user identifiers on the service.


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>

Advantages:

- No re-write of resources needed (good for MIXes)
- Bare JID refers to occupant identity (good for clients)
- Servers can simply filter on message/mix/@channel (not perfect, but better 
than requiring a new JID processing function)
- Opens up the possibility of re-using the same proxy JID for the same 
occupant across different channels (may be useful in some deployments, via 
MattJ)
- No non-RFC6122-based operations required on JIDs.

Disadvantages:

- All (including 1:1) stanzas exchanged between occupants require the <mix 
channel="…"/> element for MIX channels to be able to easily route them
- Entities filtering on MIX channel identity still need to know about MIX (and 
the <mix channel="…"/> element)
- The namespace of MIX channel JIDs and occupant JIDs needs to be separated in 
some way. This can be achieved with a single bit, so a forced prefix on 
occupant JIDs (and a forbidden prefix on channel JIDs), such as "%", would 
work for that. (I’m not sure if we would have to standardize the method by 
which services do this split.)


What do you folks think?

kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180531/576baee2/attachment.sig>


More information about the Standards mailing list