moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-25 10:42:19 -05:00
Code Issues Releases Wiki Activity

Update to reflect MIX-CORE/MIX-PRESENCE changes

Browse Source
This commit is contained in:
Steve Kille 2018-06-05 15:30:06 +01:00
parent ad5185c356
commit ba44bb18b9
1 changed files with 46 additions and 84 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

128
xep-0404.xml
View File

@ -37,6 +37,17 @@
<shortname>MIX-ANON</shortname> <shortname>MIX-ANON</shortname>
&ksmithisode; &ksmithisode;
&skille; &skille;
<revision>
<version>0.2.0</version>
<date>2018-06-05</date>
<initials>sek</initials>
<remark><p>
Remove vCard (now in MIX-PRESENCE);
Update PM rules;
Reflect changes in MIX-CORE and MIX-PRESENCE;
New JID map format;
</p></remark>
</revision>
<revision> <revision>
<version>0.1.0</version> <version>0.1.0</version>
<date>2018-05-21</date> <date>2018-05-21</date>
@ -65,8 +76,8 @@
<section2 topic="Private Messages" anchor="concepts-pm"> <section2 topic="Private Messages" anchor="concepts-pm">
<p> <p>
&xep0369; exposes participant JIDs to other participants, and so messages can always be sent directly. When JIDs are hidden this is no longer possible. &xep0369; exposes participant JIDs to other participants, and so messages can always be sent directly. When JIDs are hidden this is no longer possible.
Private messages MAY be sent to channel participants if allowed by channel policy. Private messages are Private messages MAY be sent to channel participants if allowed by channel policy. Private messages are switched through the channel to hide addressing.
addressed to the user's bare proxy JID determined from the participants node, and routed by the MIX to the user's bare real JID, where standard distribution rules will apply.
</p> </p>
</section2> </section2>
@ -100,12 +111,13 @@
<section2 topic="JID Visibility Architecture" anchor="proxy-jid-architecture"> <section2 topic="JID Visibility Architecture" anchor="proxy-jid-architecture">
<p> <p>
MUC hides real JIDs 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. In &xep0369;, the participants node provides a mapping from the proxy JID to the real JID. To hide JIDs, this specification makes two key changes MUC hides real JIDs 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 Stable Participant ID. In &xep0369;, the users JID is in the participants node and is shared in messages and presence. To hide JIDs, this specification makes three key changes
</p> </p>
<ol> <ol>
<li>The requirement to include real JID in the participants list is relaxed for channels that are not "JID Visible". For a "JID Hidden" channel, real JIDs MUST NOT be included in the participants list. For a "JID Maybe Visible" channel, real JIDs will be included in the participants node according to participant preference. </li> <li>The requirement to include real JID in the participants list is relaxed for channels that are not "JID Visible". For a "JID Hidden" channel, real JIDs MUST NOT be included in the participants list. For a "JID Maybe Visible" channel, real JIDs will be included in the participants node according to participant preference. </li>
<li>JIDs are not shared in messages and presence.</li>
<li>In presence messages, the client resource is anonymized, to prevent leakage of information through the resource.</li> <li>In presence messages, the client resource is anonymized, to prevent leakage of information through the resource.</li>
</ol> </ol>
@ -116,7 +128,7 @@ This change means that the client will not be able to determine real JID of the
</p> </p>
<p> <p>
It is important that MUC owners and administrators are able to see the real JIDs of participant. For this reason, a MIX channel following this specification MUST hold a JID Map node, which gives a mapping between proxy JID and real JID. It is important that MUC owners and administrators are able to see the JIDs of participant. For this reason, a MIX channel following this specification MUST hold a JID Map node, which gives a mapping between Stable Participant ID and JID.
</p> </p>
@ -132,16 +144,16 @@ This change means that the client will not be able to determine real JID of the
<p> <p>
When JIDs are being hidden, the resource of the full JIDs stored in the presence node MUST also be anonymized using a similar mechanism. When JIDs are being hidden, the resource of the full JIDs stored in the presence node MUST also be anonymized using a similar mechanism.
First the bare JID in presence is a proxy JID, as defined in &xep0369;. Where the JID is not being hidden, the resource is simply the resource of the clients full JID. Where the JID is hidden, 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. Where the JID is not being hidden, the resource is simply the resource of the clients full JID. Where the JID is hidden, the resource is replaced with a generated value. For example, 'hag66@shakespeare.example/UUID-a1j/7533' in the channel coven might have an encoded JID of '123456#coven@mix.shakespeare.example/789'. There is no client visible mapping 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 encoded 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>
</section2> </section2>
<section2 topic="JID Map Node" anchor="concepts-nodes"> <section2 topic="JID Map Node" anchor="concepts-nodes">
<p>This specification defines a JID Map node, so that administrators can see real JIDs for JID Hidden channels.</p> <p>This specification defines a JID Map node, so that administrators can see JIDs for JID Hidden channels.</p>
<table caption="JID Map Node"> <table caption="JID Map Node">
<tr><td>JID Map</td><td>'urn:xmpp:mix:nodes:jidmap'</td><td>For storing a list of bare proxy JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs.</td><td>Automatic</td><td>PubSub</td></tr> <tr><td>JID Map</td><td>'urn:xmpp:mix:nodes:jidmap'</td><td>For storing a list of Stable Participant IDs from the participants node with a 1:1 mapping to the corresponding JIDs.</td><td>Automatic</td><td>PubSub</td></tr>
</table> </table>
@ -149,12 +161,12 @@ This change means that the client will not be able to determine real JID of the
<p>The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap'. The JID Map node MUST have one entry for each entry in the Participants node. This value is added when a user joins the channel and is removed when the user leaves the channel. <p>The JID Map node is used to associate a Stable Participant ID to its corresponding bare JID. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap'. The JID Map node MUST have one entry for each entry in the Participants node. This value is added when a user joins the channel and is removed when the user leaves the channel.
Each item is identified by proxy bare JID, mapping to the real bare JID. This node is used to give administrator access to real JIDs and participant access to real JIDs in jid-visible channels. This node MUST NOT be modified directly using pubsub. Each item is identified by Stable Participant ID mapping to the bare JID. This node is used to give administrator access to JIDs. This node MUST NOT be modified directly using pubsub.
In JID Visible channels, all participants MAY subscribe to this node. In JID Hidden and JID Maybe Visible channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant. Information is stored in a &lt;participant/&gt; element qualified by the 'urn:xmpp:mix:anon:0' namespace. The real JID is stored in a &lt;jid/&gt; child element of the &lt;participant/&gt; element. </p> Only administrators can subscribe to this node. The JID Map node is a permanent node with one item per participant. Information is stored in a &lt;participant/&gt; element qualified by the 'urn:xmpp:mix:anon:0' namespace. The real JID is stored in a &lt;jid/&gt; child element of the &lt;participant/&gt; element. </p>
<example caption="Value of JID Map Node"><![CDATA[ <example caption="Value of JID Map Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:jidmap'> <items node='urn:xmpp:mix:nodes:jidmap'>
<item id='123456#coven@mix.shakespeare.example'> <item id='123456'>
<participant xmlns='urn:xmpp:mix:anon:0'> <participant xmlns='urn:xmpp:mix:anon:0'>
<jid>hecate@mix.shakespeare.example</jid> <jid>hecate@mix.shakespeare.example</jid>
</participant> </participant>
@ -337,84 +349,34 @@ This change means that the client will not be able to determine real JID of the
<section2 topic='Sending Private Messages' anchor='usecase-user-private-messages'> <section2 topic='Sending Private Messages' anchor='usecase-user-private-messages'>
<p> <p>
Private Messages are used to provide communication with another channel participant through the MIX channel, where the initiating user does not the real JID of the channel participant. A channel MAY support use of Private Messages. Private messages are standard XMPP messages and MUST NOT be groupchat. A message goes through a number of stages with different addressing. This is set out in the following table. Private Messages are used to provide communication with another channel participant through the MIX channel, where the initiating user does not know the real JID of the channel participant. A message is addressed to the channel using the encoded JID of the client to which the message is being sent. This is shown in the following example.
</p> </p>
<table caption="Setting From and To when sending Private Messages">
<tr><th>Message</th><th>From</th><th>To</th></tr> <example caption="User Sends a Private Message"><![CDATA[
<tr><td>First Message from Client to MIX Channel</td><td>Full JID of initiator's client</td><td>Proxy bare JID of responder</td></tr> <message from='hag66@shakespeare.example/UUID-a1j/7533'
<tr><td>First Message from MIX Channel to responder's server</td><td>Proxy full JID of initiator's client</td><td>Bare JID of responder</td></tr> to='444456#coven@mix.shakespeare.example/4588'
<tr><td>First Message from responder's server to one or more of the responder's clients</td><td>Proxy full JID of initiator</td><td>Full JID of responder's client</td></tr> id='92vax143g'>
<tr><td>Messages from responder's client to MIX Channel</td><td>Full JID of responder's client</td><td>Proxy full JID of initiator's client</td></tr> <body>Private meeting about Macbeth???</body>
<tr><td>Messages from MIX channel to initiator's client</td><td>Proxy full JID of responder's client</td><td>Full JID of initiator's client</td></tr> </message>
<tr><td>Messages from initiator's client to MIX Channel</td><td>Full JID of initiator's client</td><td>Proxy full JID of responder's client</td></tr> ]]></example>
<tr><td>Message from MIX Channel to responder's client</td><td>Proxy full JID of initiator's client</td><td>Full JID of responder's client</td></tr>
</table> <p>
The MIX channel will then process the message, to send to the real JID of the recipient. An encoded JID is used to identify the message sender.
</p>
<example caption="MIX Channel Sends Private Message to Recipient"><![CDATA[
<message from='123456#coven@mix.shakespeare.example/9988'
to='hag99@shakespeare.example/UUID-a1j/7533'
id='92vax143g'>
<body>Private meeting about Macbeth???</body>
</message>
]]></example>
<p>Private Messages MAY be archived using MAM by the XMPP servers associated with initiator and responder. Private Messages MUST NOT be archived by the MIX channel.</p> <p>Private Messages MAY be archived using MAM by the XMPP servers associated with initiator and responder. Private Messages MUST NOT be archived by the MIX channel.</p>
</section2> </section2>
<section2 topic="Requesting vCard" anchor="usecase-vcard">
<p>A client MAY request the vCard of a channel participant where the participant's real JID is not known, by sending a request through the channel. The MIX channel MAY pass this request on or MAY block it. vCard requests MAY use &xep0054; (vcard-temp) or &xep0292; (vCard4 over XMPP). The MIX channel does not process the vCard requests, but simply relays them on to real bare JID of the target. A MIX service MAY choose to relay one or both protocols. Where a MIX service relays one or both of these protocols, each protocol relayed MUST be advertised as a feature of the MIX service. In the following example, using vcard-temp, the requesting client sends a message to the bare proxy JID of the channel participant for which the vCard is desired.</p>
<example caption="Client directly requests vCard through channel" ><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='lx09df27'
to='989898#coven@mix.shakespeare.example'
type='get'>
<vCard xmlns='vcard-temp'/>
</iq>
]]></example>
<p>The MIX channel MAY pass on the vCard request or MAY reject with an error, dependent on channel policy. The MIX service will then address the vCard request to the user's server (using bare JID) using a full proxy JID to hide the requester. </p>
<example caption="Channel passes on vCard request to the User&apos;s Server" ><![CDATA[
<iq from='123456#coven@mix.shakespeare.example/6789'
id='lx09df27'
to='peter@shakespeare.example'
type='get'>
<vCard xmlns='vcard-temp'/>
</iq>
]]></example>
<p>
The user's server, on behalf of the user, MAY send a response or reject with an error. The user's server will send the vCard back to the channel.
</p>
<example caption="User's Server sends vCard Response via MIX channel" ><![CDATA[
<iq from='peter@shakespeare.example'
id='lx09df27'
to='123456#coven@mix.shakespeare.example/6789'
type='result'>
<vCard xmlns='vcard-temp'>
<FN>Peter Saint-Andre</FN>
<N>
<FAMILY>Saint-Andre</FAMILY>
<GIVEN>Peter</GIVEN>
<MIDDLE/>
</N>
<NICKNAME>stpeter</NICKNAME>
<URL>http://www.xmpp.org/xsf/people/stpeter.shtml</URL>
</vCard>
<query xmlns='http://jabber.org/protocol/disco#info'>
</iq>
]]></example>
<p>
The MIX channel will then send the vCard response to the requesting client on behalf of the client sending the response.
</p>
<example caption="MIX Channel sends vCard responst to Client" ><![CDATA[
<iq from='989898#coven@mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/UUID-c8y/1573'
type='result'>
<vCard xmlns='vcard-temp'>
<FN>Peter Saint-Andre</FN>
<N>
<FAMILY>Saint-Andre</FAMILY>
<GIVEN>Peter</GIVEN>
<MIDDLE/>
</N>
<NICKNAME>stpeter</NICKNAME>
<URL>http://www.xmpp.org/xsf/people/stpeter.shtml</URL>
</vCard>
</iq>
]]></example>
</section2>
</section1> </section1>