[Standards] MIX Addressing
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
> 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:
from="4973d5d365f8 at mixservice.domain.example/client-resource"
to="user at other.example">
- 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
- No non-RFC6122-based operations required on JIDs.
- 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards