moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

Add Proxy JID Architecture Section;

Browse Source
This commit is contained in:
Steve Kille 2018-05-04 12:00:02 +01:00
parent d03530b2ac
commit 180111a7f5
1 changed files with 27 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
xep-0369.xml
View File

@ -49,6 +49,7 @@
Clarification of MIX annotation of roster updates; Clarification of MIX annotation of roster updates;
Flag that section 6.3 (Ensuring Message Delivery) needs review; Flag that section 6.3 (Ensuring Message Delivery) needs review;
Add MIX Channels in Roster Section; Add MIX Channels in Roster Section;
Add Proxy JID Architecture Section;
</p></remark> </p></remark>
</revision> </revision>
<revision> <revision>
@ -477,6 +478,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</section2> </section2>
<section2 topic="Proxy JIDs and JID Visibility" anchor="proxy-jid"> <section2 topic="Proxy JIDs and JID Visibility" anchor="proxy-jid">
<section3 topic="Services Provided" anchor="proxy-jid-services">
<p> <p>
MIX channels have three modes controlling JID visibility: MIX channels have three modes controlling JID visibility:
</p> </p>
@ -499,6 +503,27 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<p> <p>
The default value is 'Prefer Hidden'. The default value is 'Prefer Hidden'.
</p> </p>
</section3>
<section3 topic="Architecture" anchor="proxy-jid-architecture">
<p>
In order to address requirement 7 (a mechanism of JID harvesting), the JID visibility modes of the previous section are defined. MUC achieves this by using Nicks to identify room occupants. This has problems with Nick changing and with multiple active clients for the same user. MIX identifies channel participants by a proxy JID, which is an anonymized stable JID format identifier for each participant. This mapping is used for all channels, as it means that all channels have the same logic and it is straightforward to switch between JID visible and JID hidden channels.
MIX also standardizes the mechanism for mapping between proxy JID and the participant's real JID, so that this can be used by a MIX client. Note that a MUC implementation will need a similar mapping mechanism, but this mechanism is not standardized. MIX maintains three mappings as PubSub nodes to support the necessary mappings:
</p>
<ol>
<li>Participants. This is a list of proxy JIDs of users who have joined the channel. This list is visible to all channel participants. It MAY contain a Nick for each participant. This enables a MIX client to provide a user friendly display of each participant.</li>
<li>JID Map. This contains a mapping of each participant’s real JID with the associated proxy JID. It is used by the MIX channel. For JID Visible channels, it is also accessible to all channel participants, who may use it to display the real JID of each participant.</li>
<li>JIMD Maybe Visible Map. This is used for JID Maybe Visible channels. It contains a mapping from the participant’s real JID with the associated proxy JID, for participants that have elected to share their JID. This enables channel participants to access those JIDs that are shared in a JID Maybe Visible channel. </li>
</ol>
</section3>
<section3 topic="Detailed Specification" anchor="proxy-jid-specification">
<p> <p>
The primary representation of a participant in a MIX channel is a proxy JID, which is an anonymized JID using the same domain as the channel and with the name of the channel encoded, using the format "&lt;generated identifier&gt;#&lt;channel&gt;@&lt;mix domain&gt;". The generated identifier MUST NOT contain the '#', '/' or '@' characters. The Channel name MAY contain the '#' character. For example in the channel 'coven@mix.shakespeare.example', the user 'hag66@shakespeare.example' might have a proxy JID of '123456#coven@mix.shakespeare.example'. The reason for the proxy JID is to support JID Hidden channels. Proxy JIDs are also used in JID Visible channels, for consistency and to enable switching of JID visibility. The "urn:xmpp:mix:nodes:jidmap" node maps from proxy JID to real JID. Servers and clients MUST determine that a JID is a proxy JID from context and MUST NOT infer that a JID is a proxy JID because it contains the '#' character. The primary representation of a participant in a MIX channel is a proxy JID, which is an anonymized JID using the same domain as the channel and with the name of the channel encoded, using the format "&lt;generated identifier&gt;#&lt;channel&gt;@&lt;mix domain&gt;". The generated identifier MUST NOT contain the '#', '/' or '@' characters. The Channel name MAY contain the '#' character. For example in the channel 'coven@mix.shakespeare.example', the user 'hag66@shakespeare.example' might have a proxy JID of '123456#coven@mix.shakespeare.example'. The reason for the proxy JID is to support JID Hidden channels. Proxy JIDs are also used in JID Visible channels, for consistency and to enable switching of JID visibility. The "urn:xmpp:mix:nodes:jidmap" node maps from proxy JID to real JID. Servers and clients MUST determine that a JID is a proxy JID from context and MUST NOT infer that a JID is a proxy JID because it contains the '#' character.
</p> </p>
@ -511,6 +536,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<p> <p>
The full JIDs held in the presence nodes are anonymized using a similar mechanism. First the bare JID is mapped to a bare proxy JID, using the mapping held in the "urn:xmpp:mix:nodes:jidmap" node for the bare JID. Then the resource is replaced with a generated value. For example, 'hag66@shakespeare.example/UUID-a1j/7533' in the channel coven might have a proxy JID of '123456#coven@mix.shakespeare.example/789'. There is no client visible mapping of proxy full JIDs maintained as this is not needed. The MIX channel will need to maintain a mapping, to support directly addressing clients, such as for client to client disco#info queries. While an full proxy JID is held in the presence node, the mapping to real JID MUST NOT be changed. When adding a client to the presence node, the server MAY add the same anonymized JID as used before by that client, or it MAY create a different anonymized JID. The full JIDs held in the presence nodes are anonymized using a similar mechanism. First the bare JID is mapped to a bare proxy JID, using the mapping held in the "urn:xmpp:mix:nodes:jidmap" node for the bare JID. Then the resource is replaced with a generated value. For example, 'hag66@shakespeare.example/UUID-a1j/7533' in the channel coven might have a proxy JID of '123456#coven@mix.shakespeare.example/789'. There is no client visible mapping of proxy full JIDs maintained as this is not needed. The MIX channel will need to maintain a mapping, to support directly addressing clients, such as for client to client disco#info queries. While an full proxy JID is held in the presence node, the mapping to real JID MUST NOT be changed. When adding a client to the presence node, the server MAY add the same anonymized JID as used before by that client, or it MAY create a different anonymized JID.
</p> </p>
</section3>
</section2> </section2>
<section2 topic="Standard Nodes" anchor="concepts-nodes"> <section2 topic="Standard Nodes" anchor="concepts-nodes">
<p>MIX defines a number standard nodes are as follows. Note that all nodes are OPTIONAL and that not every channel will necessarily use each node:</p> <p>MIX defines a number standard nodes are as follows. Note that all nodes are OPTIONAL and that not every channel will necessarily use each node:</p>