Merge commit 'refs/pull/660/head' of https://github.com/xsf/xeps

xep-0404.xml

@@ -37,6 +37,14 @@
   <shortname>MIX-ANON</shortname>
   &ksmithisode;
   &skille;
+  <revision>
+    <version>0.2.1</version>
+    <date>2018-06-06</date>
+    <initials>sek</initials>
+    <remark><p>
+      Clarify that PMs can be used in JID Visible channels;
+    </p></remark>
+  </revision>   
   <revision>
     <version>0.2.0</version>
     <date>2018-06-05</date>
@@ -75,9 +83,9 @@
 
   <section2 topic="Private Messages" anchor="concepts-pm">
     <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 MAY 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 switched through the channel to hide addressing.
-
+Private messages MAY be switched through the channel when JIDs are visible.  This might be useful. for example where sending messages directly is blocked.
     </p>
 
   </section2>
@@ -111,13 +119,13 @@
 
     <section2 topic="JID Visibility Architecture" anchor="proxy-jid-architecture">
       <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 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
+         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 user's JID is in the participants node and is shared in messages and presence.    To hide JIDs, this specification makes three key changes
 
       </p>
 
       <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>JIDs are not shared in messages and presence.</li>
+        <li>JIDs are not shared in messages and presence, unless the recipient has permission to see the JID.  Note that in JID Maybe Visible channels, this leads to the creation of two variants of message and presence.   The MAM archive MUST hold only the variant without the JID, in order to prevent leaking of this information.</li>
         <li>In presence messages, the client resource is anonymized, to prevent leakage of information through the resource.</li>
       </ol>
 
@@ -128,7 +136,7 @@ This change means that the client will not be able to determine real JID of the
       </p>
 
       <p>
-        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.
+        It is important that MUC owners and administrators are able to see the  JIDs of participants.   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>
 
 
@@ -144,13 +152,13 @@ This change means that the client will not be able to determine real JID of the
 
      <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.
-   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.
+     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>
     </section2>
 
 
   <section2 topic="JID Map Node" anchor="concepts-nodes">
-    <p>This specification defines a JID Map node, so that administrators can see JIDs for JID Hidden channels.</p>
+    <p>This specification defines a JID Map node, so that administrators can see JIDs for JID Hidden channels.   This node MUST be present for JID Hidden and JID Maybe Visible channels.   This node MAY be present for JID Visible channels.    If this node is not present, JIDs will all be available in the participants node.</p>
     <table caption="JID Map Node">
 
       <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>
@@ -162,7 +170,7 @@ 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 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 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.
+       Each item is identified by Stable Participant ID mapping to the  bare JID.  This node is used to give administrator access to  JIDs.  A MIX server MUST NOT allow this node to be modified directly using pubsub.
        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[
 <items node='urn:xmpp:mix:nodes:jidmap'>
@@ -349,12 +357,12 @@ 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'>
 
       <p>
-       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.
+       Private Messages are used to provide communication with another channel participant through the MIX channel.  This may be used where  the initiating  user does not know the real JID of the channel participant or for other reasons.  A message sent through the channel is addressed  using the encoded JID of the client to which the message is being sent.  Private messages will generally be sent to a bare JID,  and this is shown in the following example.  Private messages MAY be sent to a full JID.
       </p>
        
       <example caption="User Sends a Private Message"><![CDATA[
 <message from='hag66@shakespeare.example/UUID-a1j/7533'
-         to='444456#coven@mix.shakespeare.example/4588'
+         to='444456#coven@mix.shakespeare.example'
          id='92vax143g'>
   <body>Private meeting about Macbeth???</body>
 </message>
@@ -366,13 +374,13 @@ This change means that the client will not be able to determine real JID of the
       
       <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'
+         to='hag99@shakespeare.example'
          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 MUST NOT be archived by the MIX channel.  Private Messages MAY be archived using MAM by the XMPP servers associated with initiator and responder. </p>
     </section2>