Update to reflect Dave Cridland's comments of 15.08.2016

xep-0369.xml

@@ -130,18 +130,18 @@
   </ul>
   <section2 topic="MIX and PubSub" anchor="concepts-pubsub">
     <p>MIX is based upon domains providing a MIX service, such as `mix.shakespeare.example`. Note that although PubSub communication is used, a domain used for MIX is a MIX domain and not a standard &xep0060; domain. Like MUC, there is no requirement on the naming of these domains; the label 'mix' and the fact that it is a subdomain of a 'shakespeare.example' service are purely for example.</p>
-    <p>Every MIX channel is an addressable PubSub service (with additional MIX semantics) that will be addressed by an XMPP client using a bare JID, for example coven@mix.shakespeare.example. While &xep0060; is used as the basis for the MIX model, MIX uses standard presence and groupchat messages to provide an interface to the MIX service that does not expose PubSub for many of the more common functions.
+    <p>Every MIX channel is an addressable PubSub service (with additional MIX semantics) that will be addressed using a bare JID by other XMPP entities, for example coven@mix.shakespeare.example. While &xep0060; is used as the basis for the MIX model, MIX uses standard presence and groupchat messages to provide an interface to the MIX service that does not expose PubSub protocol for many of the more common functions.
 </p>
   </section2>
   <section2 topic="MIX and MAM" anchor="concepts-mam">
-    <p>Message Archive Management is used for all storage of historical data (such as the history of messages sent within the channel). Each node can be archived separately (e.g., the presence node or the configuration node). MIX clients can retrieve archived information with MAM in order to quickly resync messages with regard to a channel, and can do so without providing presence information.</p>
+    <p> Historical data (such as the messages sent to the channel) is stored in an archive supporting  Message Archive Management (MAM) so that clients can subsequently access this data with MAM. Each node can be archived separately (e.g., the presence node or the configuration node). MIX clients can retrieve archived information with MAM in order to quickly resync messages with regard to a channel, and can do so without providing presence information.</p>
   </section2>
   <section2 topic="Delivering Messages to Users" anchor="concepts-delivery">
      <p>
        The primary model is that a user will join a channel over an extended period, and that the user (not a specific client used by the user) joins the channel. The primary subscription is with the client's bare JID. The user will receive messages from the channel and/or access channel presence from time to time with one or more clients.
      </p>
     <p>
-      Where a user has no clients active, the approach expected by MIX is that messages will be archived using MAM and that when clients come online they will use MAM to access messages that have not been delivered to the client.   Following the rules of &rfc6121;, arriving MIX messages (which will be of type=groupchat) will be discarded if all clients are offline. Offline messages are not used with MIX.
+      Where a user has no clients active, the approach is that all messages will be archived by the MIX channel (on arrival at the MIX channel) so that when clients come online they will use MAM to communicate to the MIX channel to access messages that have not been delivered to the client.   Following the rules of &rfc6121;, arriving MIX messages (which will be of type=groupchat) will be discarded if all clients are offline. Offline messages are not used with MIX.
     </p>
     <p>
       Online clients are handled use &xep0376;.
@@ -150,53 +150,75 @@
   </section2>
   <section2 topic="User Presence in MIX" anchor="concepts-presence">
     <p>
-      MIX channels store presence in the presence node using the proxy JID of each online client for a user.   User presence may be included for all or selected clients of a given user, based on client choice to publish presence.    Where a user publishes presence for multiple clients, this information is available to all users subscribing to the channel presence. Queries such as disco requests will be directed to a specific client, routing through the MIX channel, while private messaging will be addressed to the user's bare proxy JID, and routed by the MIX to the user's bare real JID, where standard distribution rules will apply.
+      MIX channels store presence in the presence node using the proxy JID of each online client for a user.   User presence may be included for all or selected clients of a given user, based on client choice to publish presence.    Where a user publishes presence for multiple clients, this information is available to all users subscribing to the channel presence. 
+    </p>
+    <p>
+      External XMPP entities can direct stanzas to clients publishing their presence by sending them to the appropriate full proxy JID in the presence node.   These stanzas MAY be routed to the client by the MIX channel.  The choice to do this is dependent on MIX channel policy.   For example, a disco request MAY be routed through the MIX channel to the client. 
     </p>
     <p>
       Presence updates are distributed by a channel to the bare JID of subscribers and then the subscriber's server will distribute to each of the subscriber's currently online clients.
     </p>
   </section2>
+  <section2 topic="Private Messages" anchor="concepts-pm">
+    <p>
+      Private messages MAY be sent to channel participants if allowed by channel policy.   Private messages are 
+ 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>
+      Private messages MAY also be sent to specific clients identified by the full proxy JID of the client in the participants list, if allowed by channel policy.
+    </p>
+  </section2>
   <section2 topic="Proxy JIDs and JID Visibility" anchor="proxy-jid">
     <p>
       MIX channels have two modes controlling JID visibility:
     </p>
-    <ul>
+    <table caption="JID Visibility Modes">
-      <li>'JID Visible': In these channels, some or all participant JIDs are visible to all channel members.</li>
+      <tr><th>Mode</th><th>Description</th></tr>
-      <li>'JID Hidden': In these channels, no participant JIDs are visible to channel members, but they are visible to channel administrators.</li>
+      <tr><td>'JID Visible'</td><td>In these channels, some or all participant JIDs are visible to all channel members.</td></tr>
-    </ul>
+      
+      <tr><td>'JID&nbsp;Hidden'</td><td>In these channels, no participant JIDs are visible to channel members, but they are visible to channel administrators.</td></tr>
+    </table>
+   
     <p>
       A channel member may specify their preferences for JID visibility, with one of the following values:
     </p>
-    <ul>
+    <table caption="JID Visibility Preference Options">
-      <li>'No JID Visibility Preference': The users JID will be visible in JID Visible channels and hidden in JID Hidden channels.</li>
+      <tr><th>Preference</th><th>Description</th></tr>
-      <li>'Prefer Hidden': The user's JID will be hidden in JID Visible channels if the channel policy allows this.</li>
+      <tr><td>'No JID Visibility Preference'</td><td>The users JID will be visible in JID Visible channels and hidden in JID Hidden channels.</td></tr>
-      <li>'Enforce Hidden': The user's JID will never be shown and the user will be removed from channel if channel administrator enforces visibility.</li>
+      <tr><td>'Prefer Hidden'</td><td>The user's JID will be hidden in JID Visible channels if the channel policy allows this.</td></tr>
-      <li>'Enforce Visible': The users JID will always be shown and the user will be removed from channel if mode is changed to 'JID Hidden'.</li>
+      <tr><td>'Enforce Hidden'</td><td>The user's JID will never be shown and the user will be removed from channel if channel administrator enforces visibility.</td></tr>
-    </ul>
+      <tr><td>'Enforce Visible'</td><td>The users JID will always be shown and the user will be removed from channel if mode is changed to 'JID Hidden'.</td></tr>
+    </table>
+    
     <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;channel&gt;+&lt;generated identifier&gt;@&lt;mix domain&gt;".   For example in the channel 'coven@mix.shakespeare.example',   the user 'hag66@shakespeare.example' might have a proxy JID of 'coven+123456@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.
+      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;channel&gt;+&lt;generated identifier&gt;@&lt;mix domain&gt;".  They generated identifier MUST NOT contain the '+' 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 'coven+123456@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.  While a user is a participant in a Channel, the mapping between real JID and proxy JID MUST NOT be changed,
     </p>
      <p>
-       The full JIDs held in presence 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' in the channel coven might have a proxy JID of 'coven+123456@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.
+       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' in the channel coven might have a proxy JID of 'coven+123456@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 anonymized JID is held in the presence node, the mapping to real JID MUST NOT be changed.  When an anonoymized full JID is added to the presence node, mapping to a real full JID that was previously in the presence node, the same anonymized JID as the previous time MAY be used or a different anonymized JID MAY be used.
      </p>
   </section2>
   <section2 topic="Standard Nodes" anchor="concepts-nodes">
     <p>The standard nodes are as follows (although note that not every channel will necessarily use each node):</p>
-    <ul>
-      <li>'urn:xmpp:mix:nodes:messages' for publishing messages. Each item of this node will contain a message sent to the channel.</li>
-      <li>'urn:xmpp:mix:nodes:subject' for publishing the subject of the channel.</li>
-      <li>'urn:xmpp:mix:nodes:participants' for publishing the list of participants (identified by anonymized bare proxy JID), and identifying the nick.  This is a list of users who would receive messages (by subscription to the messages node) and/or would receive presence (by subscription to the presence node).</li>
     
-      <li>'urn:xmpp:mix:nodes:jidmap' for publishing a list of anonymized bare JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs.</li>
+    <table caption="Standard Nodes">
+      <tr><th>Node</th><th>Description</th></tr>
+      
+      <tr><td>'urn:xmpp:mix:nodes:messages'</td><td>For publishing messages. Each item of this node will contain a message sent to the channel.</td></tr>
+      
+      <tr><td>'urn:xmpp:mix:nodes:subject'</td><td>For publishing the subject of the channels</td></tr>
+      
+      <tr><td>'urn:xmpp:mix:nodes:participants'</td><td>For publishing the list of participants (identified by anonymized bare proxy JID), and identifying the nick.  This is a list of users who would receive messages (by subscription to the messages node) and/or would receive presence (by subscription to the presence node).</td></tr>
+      
+      <tr><td>'urn:xmpp:mix:nodes:jidmap'</td><td>For publishing a list of anonymized bare JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs.</td></tr>
+      
+      <tr><td>'urn:xmpp:mix:nodes:presence'</td><td>For publishing information about the availability status of online participants, which may include multiple clients for a single participant.</td></tr>
+      
+      <tr><td>'urn:xmpp:mix:nodes:config'</td><td>For storing configuration information.</td></tr>
+      
+      <tr><td>'urn:xmpp:mix:nodes:acl'</td><td>For storing information about access control lists (such as the list of owners and administrators). This information will generally be restricted to authorized users.</td></tr>
+    </table>
     
   
-      <li>'urn:xmpp:mix:nodes:presence' for publishing information about the availability status of online participants, which may include multiple clients for a single participant. </li>
-
-
-      <li>'urn:xmpp:mix:nodes:config' for storing configuration information. </li>
-
-      <li>'urn:xmpp:mix:nodes:acl' for storing information about access control lists (such as the list of owners and administrators). This information will generally be restricted to authorized users.</li>
-    </ul>
     <p>
       jidmap is the only node that will always be present for a MIX channel and all other nodes are optional.   All channels will have either a message node, a presence node or both, because a channel will always share messages and/or presence.   MIX provides mechanisms to allow users to conveniently subscribe to a chosen set of nodes and to unsubscribe to all nodes with a single operation.
     </p>
@@ -208,7 +230,7 @@
       <p>Private Messages are not stored in the messages node.</p>
     </section3>
     <section3 topic="Subject Node" anchor="subject-node">
-      <p>The subject node publishes the current subject of channel. Subject history is stored in MAM. A single item is stored in this node at a time which MUST contain a "text" element and MAY contain additional text elements. Where multiple text elements are provided, each MUST posess an xml:lang attribute that describes the natural language of the subject. Users subscribe to this node to receive subject updates. The following example shows the format of a item in the subject node.</p>
+      <p>The subject node publishes the current subject of channel. Subject history is stored in MAM. A single item is stored in this node at a time which MUST contain a "text" element and MAY contain additional text elements. Where multiple text elements are provided, each MUST posses an xml:lang attribute that describes the natural language of the subject. Users subscribe to this node to receive subject updates. The following example shows the format of a item in the subject node.</p>
       <example caption="Subject Node">
 <![CDATA[<items node='urn:xmpp:mix:nodes:subject'>
   <item>
@@ -218,7 +240,7 @@
 </items>]]></example>
     </section3>
     <section3 topic="Participants Node" anchor="participants-node">
-      <p>Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the bare proxy JID of the participant. For example 'coven+123456@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. The nick associated with the user is mandatory and is stored in the item.
+      <p>Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the bare proxy JID of the participant. For example 'coven+123456@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. The nick associated with the user is mandatory and is stored in the item.  The nick for each channel participant MUST be different to the nick of other participants.
       This node may be subscribed to for jid-visible channels that permit subscription to this node - this will allow users to see changes to channel membership.
       </p>
       <example caption="Value of Participants Node"><![CDATA[
@@ -527,11 +549,21 @@
        <li>'Never Show JID'.  If this is set, JID will never be shared and user will be removed from the channel if its mode changes to JID-visible-mandatory.</li>
        <li>'Prefer Not Show JID.   If this is set, JID will only be shared if mode is JID-visible-mandatory.</li>
      </ol>
+     <p>
+       AUTHOR'S NOTE AND QUESTION: Dave Cridland has suggested.   I would prefer:
+      
+        a) User options be sent in the initial join/>.
+        b) Unknown options are ignored.
+       c) User options can be requested (as a form). If clients require an option to
+        be supported, they should request the form.
+       
+       
+     </p>
      <p>AUTHOR'S NOTE AND QUESTION:  Add protocol specifications  and examples.   Are there any other specific per user values that should be listed here? </p>
    </section3>
 
     <section3 topic='Leaving a Channel' anchor='usecase-user-leaving'>
-      <p>Users generally remain in a channel for an extended period of time.  In particular membership of the channel does not change when the user goes offline as happens with &xep0045;. So, leaving the channel is a permanent action for a user across all clients, not just a matter of telling the channel that the user is not currently available or for a single client.  In order to  leave a channel, a user sends a MIX "leave" command to the channel. When a user leaves the channel, the user's server will remove the channel from the user's roster.</p>
+      <p>Users generally remain in a channel for an extended period of time.  In particular membership of the channel does not change when the user goes offline as happens with &xep0045;. So, leaving the channel is a permanent action for a user across all clients, not just a matter of telling the channel that the user is not currently available or for a single client.  In order to  leave a channel, a user sends a MIX "leave" command to the channel. When a user leaves the channel, the user's client will remove the channel from the user's roster.</p>
       <example caption="User Leaves a Channel"><![CDATA[
 <iq type='set'
     from='hag66@shakespeare.example/pda'
@@ -575,7 +607,7 @@
       <li>The user explicitly sets the nick, as described in this section.</li>
       <li>The MIX service generates the nick.  In this case it is recommended that the assigned nick is a UUID following &rfc4122;.</li>
     </ol>
-    <p>AUTHOR'S NOTE AND QUESTION:  REVIEW use of UUID.  Can it make sense for other algorithms, such as a string from the JID</p>
+   
     <p>
    A user will typically set a nick when joining a channel and may update this nick from time to time.   The user does this by sending a command to the channel to set the nick.  If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result.
     </p>
@@ -736,7 +768,7 @@
           from='hag66@shakespeare.example/pda'
           to='coven@mix.shakespeare.example'/>
 ]]></example>
-      <p>The MIX channel will retract (remove) the item in the presence node of the MIX channel identified by the client's full JID.  The MIX channel will notify subscribers to the presence node of the user going offline using a presence stanza from the proxy JID of the client.</p>
+      <p>The MIX channel will retract (remove) the item in the presence node of the MIX channel identified by the client's full JID.  The MIX channel will notify subscribers to the presence node of the user going offline by sending a presence stanza to the full proxy JID of each client.</p>
       <example caption="Channel Distributes Notification of Client going Offline">
 <![CDATA[<presence from='coven+12345@mix.shakespeare.example/678'
           to='hecate@shakespeare.example'
@@ -764,6 +796,7 @@
 </message>
 ]]></example>
       <p>The message comes from the channel as a pubsub notification, with the 'publisher' attribute set to the participant identifier of the sender.</p>
+      <p>AUTHOR NOTE:  Message id coming back is different in example.   Need to be explicit as to compliant behaviour.  Input as to whether the ID should change is solicited.</p>
       <example caption="Channel Reflects Message to Participants"><![CDATA[
 <message from='coven+12345@mix.shakespeare.example/678'
          to='hecate@shakespeare.example'
@@ -792,7 +825,34 @@
         <li>The channel member sends the invitation to the invitee.</li>
         <li>The invitee uses the invitation to construct a request to join the channel.</li>
       </ol>
-      <p> AUTHOR'S NOTES AND QUESTION:   To be expanded considerably.   Dave (Cridland?) raised a point about contact preverification about users' invites.  If this is still relevant, please raise it again and we will consider how to address it. </p>
+      <p> AUTHOR'S NOTES AND QUESTION:   To be expanded considerably and perhaps modified based on the following:  Dave Cridland notes: 
+        > There are three actors - the Member (who is the inviter), the Invitee, and
+        > the Channel.
+        > 
+        > A) The Member obtains an Invitation (containing a verifiable token) from the
+        > Channel. This allows the Channel to reject attempts to invite users who
+        > should not be able to join the channel, but it might provide the token anyway
+        > to avoid probes discovering who is allowed to join the room. This is your step
+        > 1.
+        > 
+        > B) The Member sends this Invitation (including the token) to the Invitee.
+        > (Step 2)
+        > 
+        > C) The Invitee can optionally request from the Channel the validity of the
+        > Invitation. (Not included)
+        > 
+        > D) The Invitee can use the Invitation. (Step 3)
+        > 
+        > The idea behind my step C is that it allows a client to validate that the entity
+        > sending an invitation really is a member of the channel, and could
+        > legitimately act as a Member. This could be folded into (D), although it
+        > depends on whether we want to present the Invitation without knowing its
+        > validity.
+        > 
+        > It feels as if an Invitee executing on an Invitation ought to be able to tell if the
+        > Invitation was genuine or not.
+        > 
+        . </p>
     </section3>
 
 
@@ -807,8 +867,8 @@
 
 
     <section3 topic="Requesting vCard" anchor="usecase-vcard">
-      <p>A user may request the vCard of a channel participant by sending a requestion through the channel.</p>
+      <p>A user may request the vCard of a channel participant by sending a request through the channel.</p>
-      <p> AUTHOR'S NOTES:   To be expanded considerably. </p>
+      <p> AUTHOR'S NOTES:   To be expanded considerably. ( is essentially "send the vCard request to the bare Proxy JID")</p>
     </section3>
   </section2>
 
@@ -969,7 +1029,7 @@
        <li>Describe in an updated version of this XEP.</li>
        <li>Do not specify in a XEP and leave to implementer.</li>
      </ol>
-     <p>QUESTION: Input on these choices is solicited.</p>
+     <p>QUESTION: Input on these choices is solicited.  Dave Cridland votes for new XEP.</p>
    </section2>
 
    <section2 topic="Voice Control" anchor="voice-control">