From 31b8526e59ff8faa959c342c338c0bd84394a961 Mon Sep 17 00:00:00 2001
From: Steve Kille <steve.kille@isode.com>
Date: Wed, 22 Mar 2017 14:19:55 +0000
Subject: [PATCH] MIX (XEP-0369) to version 0.9 (#455)

* XEP-0369: Minor editing

* Small edit following Georg's edits

* Edits to address Georg's comments

* New Proxy JID format.

* Clarify MAM Archive on Send

* Sort Mechanisms to only share JIDs when users prefer to

* Add examples of Real JID lookup and set version date
---
 xep-0369.xml | 313 ++++++++++++++++++++++++++++++++++++---------------
 1 file changed, 221 insertions(+), 92 deletions(-)

diff --git a/xep-0369.xml b/xep-0369.xml
index 11dd192f..d2f6e22a 100644
--- a/xep-0369.xml
+++ b/xep-0369.xml
@@ -36,6 +36,18 @@
   &ksmithisode;
   &skille;
   &stpeter;
+  <revision>
+    <version>0.9</version>
+    <date>2017-03-27</date>
+    <initials>sek</initials>
+    <remark><p>
+      Editorial Changes (mainly from Georg Lukas);
+      Change to new syntax for proxy JIDs;
+      Clarify MAM archive on Send;
+      Extend to sort Selected JID visibility;
+      Add examples of lookup read JID from proxy JID;
+    </p></remark>
+  </revision>
   <revision>
     <version>0.8.2</version>
     <date>2017-03-3</date>
@@ -251,7 +263,7 @@
     <li>It is impractical to address a number of the requirements listed in the next section with MUC or with extensions to MUC. </li>
     <li>In the years after MUC was designed, both &xep0060; and &xep0313; have been developed and it is desirable to reuse these building blocks (e.g., MAM can be used for message history) rather than using the less robust methods defined in &xep0045;.</li>
   </ul>
-  <p>Because it is anticipated that there will significant co-existence between MUC and MIX, this specification is designed so that:</p>
+  <p>Because it is anticipated that there will be significant co-existence between MUC and MIX, this specification is designed so that:</p>
   <ul>
     <li>XMPP clients can implement MUC and this specification in a way that provides a coherent user experience.</li>
     <li>XMPP servers can implement this specification and also provide a MUC interface in order to support clients that only implement MUC.</li>
@@ -302,7 +314,6 @@
     <li>Online clients MAY register presence, which is then shared with participants who have subscribed to presence.</li>
     <li>MIX decouples addressing of channel participants from their nicknames, so that nickname changes do not affect addressing.</li>
     <li>Each participant is addressable by a single bare JID, which is a proxy JID (not the user's real JID) to make it straightforward to hide the user's real JID from other channel participants. Full JIDs comprised of this bare JID plus a resource (also anonymized) are then constructed, allowing visibility into the number of online resources participating in a channel.</li>
-    <li>MIX requires client support and server support from the server providing the MIX service. </li>
     <li> Although some protocol is shared with MUC, MUC clients are not interoperable with a MIX service.  This means that where a user chooses to use MIX, all of the users clients need to support MIX.</li>
     <li>MIX requires the server to which the MIX client connects to provide functionality to support MIX.  This functionality is defined in this specification and referenced as "MIX Participant's Server Behaviour".</li>
     <li>MIX domains MUST NOT be used to host end user JIDs. </li>
@@ -318,7 +329,7 @@
   </section2>
   <section2 topic="Behaviour of MIX Participant's Server" anchor="concepts-mix-participant-server">
     <p>
-      A MIX channel does not send messages and presence directly to an XMPP MIX client of a channel participant, but addresses them to participant using the participant's bare JID. The participant's server MUST then handle these messages and pass them on to zero, one or multiple clients.   To enable MIX to work, this behaviour is necessary and so the server of every MIX client MUST follow the rules set out in this specification.
+      A MIX channel does not send messages and presence directly to the MIX client of a channel participant, but addresses them to the participant using the participant's bare JID. The participant's server MUST then handle these messages and pass them on to zero, one or multiple clients.   To enable MIX to work, this behaviour is necessary and so the server of every MIX client MUST follow the rules set out in this specification.
 This approach  enables flexible support of multiple clients for a MIX channel participant.
        The MIX 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.
        There are a number of MIX requirements on behaviour of the MIX Participant's server, which are summarized here:
@@ -327,16 +338,16 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
 
 
       <li>Messages from a MIX client to a MIX channel will go direct to the MIX service.  They are relayed, but not modified, by the participant's server.</li>
-      <li>Messages from a MIX channel to a MIX client are always sent to the MIX participants server (addressed by bare JID) and MUST be handled by the MIX participant's server.</li>
+      <li>Messages from a MIX channel to a MIX client are always sent to the MIX participant's server (addressed by bare JID) and MUST be handled by the MIX participant's server.</li>
       <li>All messages received by the MIX participant's server MUST be stored using MAM.</li>
-      <li>The MIX participant's server will only send messages to online clients and will discard messages if no clients are online.
-        This means that a MIX client needs to resynchronize with the MIX service when it comes online.  This message synchronization will happen between the MIX client and the MAM archive held on the MIX participant's server.</li>
+      <li>The MIX participant's server will only forward messages to online clients and will not forward messages if no clients are online.
+        This means that a MIX client needs to resynchronize with all MIX channels when it comes online.  This message synchronization will happen between the MIX client and the MAM archive held on the MIX participant's server.</li>
 
       <li>The MIX client will generally send management and other messages directly to the MIX channel and this MUST be done except where specifically noted.  </li>
-      <li>The user's roster contains each MIX channel to which the user is subscribed and is sharing presence.   To achieve this the user's server needs to manage the roster on behalf of the user.  For this reason, MIX join and leave commands MUST be sent by a client to the user's server.   This enables the user's server to correctly manage the roster on behalf of the user.</li>
+      <li>The user's roster contains each MIX channel to which the user is subscribed.   To achieve this the user's server needs to manage the roster on behalf of the user.  For this reason, MIX join and leave commands MUST be sent by a client to the user's server.   This enables the user's server to correctly manage the roster on behalf of the user.</li>
     </ol>
     <p>
-   Messages being sent from MIX channel to a MIX participant’s server (which will be of type=groupchat)  and presence information are sent to the bare JID.  This means that the MIX participant's server  MUST support a modification of the standard &rfc6121; rules.
+   Messages from a MIX channel to a MIX participant (which will be of type=groupchat) and presence information are sent to the participant's server using the participant's bare JID.  This means that the MIX participant's server  MUST implement a modification of the standard &rfc6121; message processing rules.
     </p>
     <p>
       The core MIX specification sets out how the MIX channel interacts directly with XMPP clients and with the MIX participant's server. Behaviour of the MIX participant's server is also specified in this MIX specification.
@@ -344,10 +355,10 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
   </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 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.
+      MIX channels store presence of each online client for a user that chooses to publish presence.  Presence is stored in the presence node and is encoded using a full proxy JID.  Where a user publishes presence for one or more 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.
+      Channel participants can send messages to clients publishing their presence by sending them to the  full proxy JID published 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.
@@ -362,31 +373,38 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
   </section2>
   <section2 topic="Proxy JIDs and JID Visibility" anchor="proxy-jid">
     <p>
-      MIX channels have two modes controlling JID visibility:
+      MIX channels have three modes controlling JID visibility:
     </p>
     <table caption="JID Visibility Modes">
       <tr><th>Mode</th><th>Description</th></tr>
-      <tr><td>'JID Visible'</td><td>In these channels, some or all participant JIDs are visible to all channel participants.</td></tr>
+      <tr><td>'JID Visible'</td><td>In these channels all participant JIDs are visible to all channel participants.</td></tr>
+      <tr><td>'JID Maybe Visible'</td><td>In these channels, participant JIDs are visible to all channel participants when participant preference allows.</td></tr>
       <tr><td>'JID&nbsp;Hidden'</td><td>In these channels, no participant JIDs are visible to channel participants, but they are visible to channel administrators.</td></tr>
     </table>
     <p>
-      A channel participant MAY specify their preferences for JID visibility, with one of the following values:
+      A channel participant MAY specify a preference for JID visibility for the channel, with one of the following values:
     </p>
     <table caption="JID Visibility Preference Options">
       <tr><th>Preference</th><th>Description</th></tr>
-      <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>
-      <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>
-      <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>
+      <tr><td>'No JID Visibility Preference'</td><td>The users JID will be visible if the channel is  JID Visible or  JID Maybe Visible channels and hidden if the channel is JID Hidden.  </td></tr>
+      <tr><td>'Prefer Hidden'</td><td>The user's JID will be hidden if the channel is  JID Maybe Visible and shown if the channel is  JID Visible .</td></tr>
+      <tr><td>'Enforce Hidden'</td><td>The user's JID will never be shown and the user will be removed from channel if channel mode is changed to JID Visible.</td></tr>
       <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;".  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.
+      For JID Visible and JID Hidden channels the default user visibility preference is No JID Visibility Preference.   For JID Maybe Visible channels, the default user visibility preference is Prefer Hidden, so that JIDs will only be visible when users explicitly permit this.
+    </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.
+    </p>
+    <p>
+      The mapping of real bare JID to proxy JID is defined when a participant joins a channel.  While a user is a participant in a Channel, the mapping between real JID and proxy JID MUST NOT be changed.   This mapping must be maintained after the user leaves the channel.   Proxy JID values MUST NOT be re-used.   If a JID that left a channel joins the channel again the same proxy JID MAY be used again or a different new proxy JID MAY be assigned.   
     </p>
     <p>
       The example real full JIDs in this specification are aligned the anticipated new format that splits the resource into two parts.  The first part is UUID that is a stable and fixed value for the client and is anticipated to be a fixed format which may well be UUID 4.  The second part is server assigned and will vary with each session.    A realistic JID with resource is:  'hag66@shakespeare.example/d104f6a7-97e9-477f-8947-e4a37691d7ee/7533375f2cd'.   This specification uses examples of the style:  'hag66@shakespeare.example/UUID-a1j/7533' which are aligned to real resources, but more compact.     CITATION TO BE ADDED.  If the final specification differs from this, the examples will be updated.   
     </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 '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.
+       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>
   </section2>
   <section2 topic="Standard Nodes" anchor="concepts-nodes">
@@ -395,7 +413,8 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
       <tr><th>Name</th><th>Node</th><th>Description</th><th>Update</th><th>Distribution</th></tr>
       <tr><td>Messages</td><td>'urn:xmpp:mix:nodes:messages'</td><td>For distributing messages to the channel. Each item of this node will contain a message sent to the channel.</td><td>Message</td><td>Message</td></tr>
       <tr><td>Participants</td><td>'urn:xmpp:mix:nodes:participants'</td><td>For storing the list of participants and the associated nick.  Channel participants are added when they join the channel and removed when they leave </td><td>Join/Leave/Set Nick</td><td>PubSub</td></tr>
-      <tr><td>JID Map</td><td>'urn:xmpp:mix:nodes:jidmap'</td><td>For storing a list of anonymized bare 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 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 Maybe Visible Map</td><td>'urn:xmpp:mix:nodes:jidmap2'</td><td>For storing a list of bare proxy JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs for participants that choose to share real JIDs in a channel with JID Maybe Visible mode.</td><td>Automatic</td><td>PubSub</td></tr>
       <tr><td>Presence</td><td>'urn:xmpp:mix:nodes:presence'</td><td>For storing information about the availability status of online participants, which MAY include multiple clients for a single participant.</td><td>Presence</td><td>Presence</td></tr>
       <tr><td>Information</td><td>'urn:xmpp:mix:nodes:info'</td><td>For storing general channel information, such as description. </td><td>PubSub</td><td>PubSub</td></tr>
       <tr><td>Allowed</td><td>'urn:xmpp:mix:nodes:allowed'</td><td>For storing JIDs that are allowed to be channel participants.</td><td>PubSub</td><td>PubSub</td></tr>
@@ -404,7 +423,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
     </table>
     <p>
       All of the standard nodes are OPTIONAL.   A channel providing a service similar to MUC will typically use all of the standard nodes, but other channels MAY use any combination of these nodes.
-      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.  Some nodes are accessed and managed with PubSub, whereas other nodes define MIX specific mechanisms for their use, shown in the last two columns of the table.
+      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.  Some nodes are accessed and managed with PubSub, whereas other nodes define MIX specific mechanisms for their use, as shown in the last two columns of the table.
     </p>
     <p>
       MIX also makes use of two nodes for support of Avatars.  These nodes and their use is defined in &xep0084;.  These nodes MAY be created as part of a MIX channel, where it is desired to publish an avatar associated with the channel.
@@ -423,14 +442,14 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
       </p>
       <table caption="Channel Roles">
         <tr><th>Role</th><th>Membership and Rights</th></tr>
-        <tr><td>Owners</td><td>These are owners of the list, as specified in the channel configuration node.  Only owners are allowed to modify the channel configuration node.</td></tr>
-        <tr><td>Administrators</td><td>Administrators are defined in the channel configuration node.  Administrators have update rights to the Allowed Node and Banned Node, so can control which users are allowed to participate in a channel.  </td></tr>
+        <tr><td>Owners</td><td>These are owners of the channel, as specified in the channel configuration node.  Only owners are allowed to modify the channel configuration node.</td></tr>
+        <tr><td>Administrators</td><td>Administrators are defined in the channel configuration node.  Administrators have update rights to the Allowed Node and Banned Node, so they can control which users are allowed to participate in a channel.  </td></tr>
         <tr><td>Participants</td><td>Participants are users listed by JID in the participants node.</td></tr>
-        <tr><td>Allowed</td><td>Allowed is the set of JIDs that are participants or are allowed to become participants.  A JID is allowed if it does not match entry in the banned node and either it matches an entry in the allowed node or the allowed node is not present. </td></tr>
+        <tr><td>Allowed</td><td>Allowed is the set of JIDs that are participants or are allowed to become participants.  A JID is allowed if it does not match an entry in the banned node and either it matches an entry in the allowed node or the allowed node is not present. </td></tr>
         <tr><td>Anyone</td><td>Any user, including users in the banned node.</td></tr>
       </table>
       <p>
-        There MUST always be at least one owner and "anyone" will always have role occupants.   Other roles  MAY NOT have any role occupants.  Rights are defined in a strictly hierarchical manner, so that for example Owners will always have rights that Administrators have.
+        There MUST always be at least one Owner.   Administrators, Participants, and Allowed MAY NOT have any members.  Rights are defined in a strictly hierarchical manner following the order of this table, so that for example Owners will always have rights that Administrators have.
       </p>
     </section3>
 
@@ -441,14 +460,14 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
     </section3>
     <section3 topic="Messages Node" anchor="messages-node">
       <p>
-        The Message node is used to distribute messages.   The Messages node is a transient node and so no PubSub items are held.  Messages MUST go to the associated MAM archive and history is retrieved by use of  MAM. Users subscribe to this node to indicate that messages from the channel are to be sent to them.   Private Messages are not distributed by the messages node.
+        The Messages node is used to distribute messages.   The Messages node is a transient node and so no PubSub items are held.  Messages MUST go to the associated MAM archive and history is retrieved by use of  MAM. Users subscribe to this node to indicate that messages from the channel are to be sent to them.   Private Messages are not distributed by the Messages node.
 
       </p>
 
     </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.  The nick for each channel participant MUST be different to the nick of other participants.
+      <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 '123456#coven@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.
       </p>
       <p>
         When a user joins a channel, the user's bare JID is added to the participants node by the MIX service.   When a user leaves a channel, they are removed from the participants node.  The participants node MUST NOT be directly modified using pubsub.
@@ -457,7 +476,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
       <p>The participants node is OPTIONAL.  If the Participants Node is not used, information on channel participants is not shared.  If there is no participants node, the access control value 'participants' MUST NOT be used.   The Participants node is a permanent node with one item per participant.</p>
       <example caption="Value of Participants Node"><![CDATA[
 <items node='urn:xmpp:mix:nodes:participants'>
-  <item id='coven+123456@mix.shakespeare.example'>
+  <item id='123456#coven@mix.shakespeare.example'>
     <participant xmlns='urn:xmpp:mix:0'
                  nick='thirdwitch'/>
   </item>
@@ -468,27 +487,35 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
 
       <p>The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID.  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.
-       In JID visible channels, all participants MAY subscribe to this node.  In JID hidden channels, only administrators can subscribe.   The JID Map node is a permanent node with one item per participant.</p>
+       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.</p>
       <example caption="Value of JID Map Node"><![CDATA[
 <items node='urn:xmpp:mix:nodes:jidmap'>
-  <item id='coven+123456@mix.shakespeare.example'>
+  <item id='123456#coven@mix.shakespeare.example'>
     <participant xmlns='urn:xmpp:mix:0'
                  jid='hecate@mix.shakespeare.example'/>
   </item>
 </items>
 ]]></example>
     </section3>
+    
+    <section3 topic="JID Maybe Visible Map Node" anchor="jid-map2-node">
+      
+      <p>The JID Maybe Visible Map node is a similar node to the JID Map node that is used in addition to the JID Map Node in JID Maybe Visible channels.   All participants may subscribe to and access this node.    It uses the same encoding as JID Map node and all participant JIDs MUST be included.    Where a participant's preference is to not share the JID, the encoded participant value is the proxy JID.   This will enable a user looking up a JID to clearly determine that the user preference is to not share the JID and to clearly distinguish this case from an erroneous proxy JID.
+      </p>
+      
+    </section3>
+    
     <section3 topic="Presence Node" anchor="presence-node">
       <p>
         The presence node contains the presence value for clients belonging to participants that choose to publish presence to the channel. A MIX channel MAY require that all participants publish presence.  Each item in the presence node is identified by the full proxy JID, and contains the current presence value for that JID.  The presence is encoded in the same way as data that would be sent in a presence stanza. The full proxy JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control MAY be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list.
       </p>
 
       <p>
-        This node MAY be subscribed to by users and this subscription MUST use the users bare JID.  So presence of online clients is sent to the user's server for each user subscribed to this node. Presence is always sent using standard presence protocol and NOT using pubsub protocol.   Clients MUST NOT directly access the presence node using pubsub.  The Presence node is a permanent PubSub node.
+        This node MAY be subscribed to by users and this subscription MUST use the user's bare JID.  So presence of online clients is sent to the user's server for each user subscribed to this node. Presence is always sent using standard presence protocol and NOT using pubsub protocol.   Clients MUST NOT directly access the presence node using pubsub.  The Presence node is a permanent PubSub node.
       </p>
       <example caption="Value of Presence Node"><![CDATA[
 <items node='urn:xmpp:mix:nodes:presence'>
-  <item id='coven+123456@mix.shakespeare.example/8765'>
+  <item id='123456#coven@mix.shakespeare.example/8765'>
     <presence xmlns='jabber:client'>
       <show>dnd</show>
       <status>Making a Brew</status>
@@ -505,11 +532,15 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
       <table caption="Information Node Attributes">
         <tr><th>Name</th><th>Description</th><th>Field Type</th><th>Values</th><th>Default</th></tr>
         <tr><td>'Name'</td><td>A short string providing a name for the channel.  For example "The Coven".  Typical uses of this value will be to present a user with the name of this channel in a list of channels to select from or as the header of UI display of the channel.  It is intended for use where a short string is needed to represent the channel.</td><td>text-single</td><td>-</td><td>-</td></tr>
-        <tr><td>'Description'</td><td>A longer description of the channel. For example "The Place where the Macbeth Witches Meet up".   A typical use would be to provide a user with more information about the channel, for example in tool tip.</td><td>text-single</td><td>-</td><td>-</td></tr>
+        <tr><td>'Description'</td><td>A longer description of the channel. For example "The Place where the Macbeth Witches Meet up".   A typical use would be to provide a user with more information about the channel, for example in a tool tip.</td><td>text-single</td><td>-</td><td>-</td></tr>
         <tr><td>'Contact'</td><td>The JID or JIDs of the person or role responsible for the channel.</td><td>jid-multi</td><td>-</td><td>-</td></tr>
+        <tr><td>'JID Visibility'</td><td>Specified JID visibility of the channel.</td><td>list-single</td><td>'jid-hidden'; 'jid-maybe-visible'; 'jid-visible'</td><td>'jid-hidden'</td></tr>
       </table>
       <p>
-        Name and Description of the channel apply to the whole channel and are will usually be changed infrequently.
+        Name and Description of the channel apply to the whole channel and will usually be changed infrequently.
+      </p>
+      <p>
+        JID visibility is included in the Information Node as this is information that will be useful for participant clients and may also be important when choosing to join a channel.
       </p>
       <p>The name and description values 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 element.  The format of the Information node follows &xep0004;.  This allows configuration to be updated by MIX defined commands and that the results of update commands are the same as the PubSub node.
       The following example shows the format of a item in the information node for the example coven@mix.shakespeare.example channel.
@@ -531,6 +562,9 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
          <field var='Contact'>
              <value>greymalkin@shakespeare.lit</value>
          </field>
+         <field var='JID Visibility'>
+             <value>jid-visible</value>
+         </field>
       </x>
   </item>
 </items>
@@ -539,7 +573,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
 
       <section3 topic="Allowed" anchor="allowed-node">
         <p>
-          This node represents a list of JIDs that are allowed to become participants. If the allowed node is not present, all JIDs are allowed. This node is accessed and managed using standard pubsub.  The allowed list is always considered in conjunction with the banned list, stored in the banned node.  Only Administrators and Owners have write permission to the allowed node and are also the only roles that are allows to subscribe to this node.   The Allowed node is a permanent node.  Each item contains a real bare JID.  The following example shows how the allowed list can specify single JIDs and domains.
+          This node represents a list of JIDs that are allowed to become participants. If the Allowed node is not present, all JIDs are allowed. This node is accessed and managed using standard pubsub.  The Allowed list is always considered in conjunction with the banned list, stored in the banned node.  Only Administrators and Owners have write permission to the Allowed node and are also the only roles that are allowed to subscribe to this node.   The Allowed node is a permanent node.  Each item contains a real bare JID.  The following example shows how the Allowed list can specify single JIDs and domains.
         </p>
         <example caption="Allowed Node"><![CDATA[
 <items node='urn:xmpp:mix:nodes:allowed'>
@@ -550,7 +584,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
       </section3>
       <section3 topic="Banned" anchor="banned-node">
         <p>
-          This node represents a list of JIDs that are explicitly not allowed to become participants. The values in this list take priority over values in the allowed node. This node is accessed and managed using standard pubsub  Only Administrators and Owners have write permission to the allowed node and are also the only roles that are allows to subscribe to this node. Each item contains a real bare JID.   The Banned node is a permanent node.
+          This node represents a list of JIDs that are explicitly not allowed to become participants. The values in this list take priority over values in the Allowed node. This node is accessed and managed using standard pubsub  Only Administrators and Owners have write permission to the Banned node and are also the only roles that are allowed to subscribe to this node. Each item contains a real bare JID.  The Banned node can contain bare JIDs and/or domains.  The Banned node is a permanent node.
         </p>
         <example caption="Banned Node"><![CDATA[
 <items node='urn:xmpp:mix:nodes:banned'>
@@ -569,8 +603,8 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
         <tr><td>'Owner'</td><td>Bare JIDs with Owner rights as defined in ACL node.  When a channel is created, the JID creating the channel is configured as an owner, unless this attribute is explicitly configured to another value.</td><td>jid-multi</td><td>-</td><td>-</td></tr>
         <tr><td>'Administrator'</td><td>Bare JIDs with Administrator rights.</td><td>jid-multi</td><td>-</td><td>-</td></tr>
         <tr><td>'End of Life'</td><td>The date and time at which the channel will be automatically removed by the server.   If this is not set, the channel is permanent.</td><td>text-single</td><td>-</td><td>-</td></tr>
-        <tr><td>'Nodes Present'</td><td>Specifies which nodes are present. Presence of  config nodes is implicit.  Jidmap node MUST be present if participants node is present. 'avatar' means that both Avatar Data and Avatar Metadata nodes are present.</td><td>list-multi</td><td>'participants'; 'presence'; 'information'; 'allowed'; 'banned'; 'avatar'</td><td>-</td></tr>
-        <tr><td>'Message Node Subscription'</td><td>Controls who can subscribe to messages node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'</td><td>'participants'</td></tr>
+        <tr><td>'Nodes Present'</td><td>Specifies which nodes are present. Presence of  config nodes is implicit.  Jidmap node MUST be present if participants node is present. 'avatar' means that both Avatar Data and Avatar Metadata nodes are present.</td><td>list-multi</td><td>'participants'; 'presence'; 'information'; 'allowed'; 'banned'; 'jidmap2'; 'avatar'</td><td>-</td></tr>
+        <tr><td>'Messages Node Subscription'</td><td>Controls who can subscribe to messages node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'</td><td>'participants'</td></tr>
         <tr><td>'Presence Node Subscription'</td><td>Controls who can subscribe to presence node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'</td><td>'participants'</td></tr>
         <tr><td>'Participants Node Subscription'</td><td>Controls who can subscribe to participants node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'; 'nobody'; 'admins'; 'owners'</td><td>'participants'</td></tr>
 
@@ -580,13 +614,13 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
         <tr><td>'Configuration Node Access'</td><td>Controls who can subscribe to configuration node and who has read access to it.</td><td>list-single</td><td>'participants'; 'allowed';  'nobody'; 'admins'; 'owners' </td><td>'owners'</td></tr>
         <tr><td>'Information Node Update Rights'</td><td>Controls who can make changes to the information node</td><td>list-single</td><td>'participants'; 'admins'; 'owners' </td><td>'admins'</td></tr>
         <tr><td>'Avatar Nodes Update Rights'</td><td>Controls who can make changes to the avatar data and metadata nodes</td><td>list-single</td><td>'participants'; 'admins'; 'owners' </td><td>'admins'</td></tr>
-        <tr><td>'JID Visibility'</td><td>Controls JID visibility in the channel.</td><td>list-single</td><td>'jid-hidden'; 'jid-optionally-visible'; 'jid-mandatory-visible'</td><td>'jid-hidden'</td></tr>
+        
         <tr><td>'Open Presence'</td><td>If selected, any client MAY register presence.  If not selected, only clients with bare JID in the participants list are allowed to register presence.</td><td>boolean</td><td>-</td><td>false</td></tr>
         <tr><td>'Participants Must Provide Presence'</td><td>If selected, all channel participants are REQUIRED to share presence information with the channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
-        <tr><td>'Allow User Message Retraction'</td><td>If this option is selected users will be able to retract messages sent to the MIX channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
-        <tr><td>'Administrator Message Retraction Rights'</td><td>This controls which group is able to retract messages sent to the MIX channel.</td><td>list-single</td><td>'nobody'; 'admins'; 'owners'</td><td>'owners'</td></tr>
+        <tr><td>'User Message Retraction'</td><td>If this option is selected users will be able to retract messages that they have sent to the MIX channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
+        <tr><td>'Administrator Message Retraction Rights'</td><td>This controls which group is able to retract any message sent to the MIX channel.</td><td>list-single</td><td>'nobody'; 'admins'; 'owners'</td><td>'owners'</td></tr>
         <tr><td>'Participation Addition by Invitation from Participant'</td><td>This option extends a channel  so that  a channel participant has rights to invite and enable other users as participants.</td><td>boolean</td><td>-</td><td>false</td></tr>
-        <tr><td>'No Private Messages'</td><td>If this option is selected, private messages MUST NOT be used with the channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
+        <tr><td>'Private Messages'</td><td>If this option is selected, private messages MAY be used with the channel.</td><td>boolean</td><td>-</td><td>true</td></tr>
       </table>
       <p>
         The configuration node is in &xep0004; format and includes all of the options used by the channel, including values for options using default values.  This means that the value in the form can be directly mapped with the form returned by configuration administration commands. Configuration nodes will typically have a large number of elements. The following short example is provided to illustrate the syntax of the configuration node.
@@ -604,12 +638,9 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
         <field var='Owner'>
             <value>greymalkin@shakespeare.lit</value>
         </field>
-        <field var='Message Node Subscription'>
+        <field var='Messages Node Subscription'>
            <value>allowed</value>
          </field>
-        <field var='JID Visibility'>
-           <value>jid-mandatory-visible</value>
-         </field>
          <field var='No Private Messages'>
             <value>true</value>
          </field>
@@ -628,11 +659,11 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
 
 <section1 topic="Error Handling" anchor="error-handling">
   <p>
-    The MIX specification is built on layered services that have defined errors.  This enables the core MIX specification to reflect primarily the successful use case, as in almost all cases the error reporting of the layer service provide what is needed.   A message sender MUST be prepared to handle any valid error from the layer services.   When a message receiver encounters an error situation, it MUST use the most appropriate layer server error to report this issue back to the sender.   For example a message receiver might use the "not authorized" IQ error in response to a MIX disco that is not authorized.   Errors for the following layer services need to be handled for MIX:
+    The MIX specification is built on layered services that have defined errors.  This enables the core MIX specification to reflect primarily the successful use case, as in almost all cases the error reporting of the layer service provides what is needed.   A message sender MUST be prepared to handle any valid error from the layer services.   When a message receiver encounters an error situation, it MUST use the most appropriate layer server error to report this issue back to the sender.   For example a message receiver might use the "not authorized" IQ error in response to a MIX disco that is not authorized.   Errors for the following layer services need to be handled for MIX:
   </p>
   <ol>
     <li>IQ.  All of the IQ errors of &rfc6120; MUST be supported.</li>
-    <li>Messages.  If a message is received and an error situation is encountered, an message of type error MUST be sent back to the message sender. This message format is specified in &rfc6121; containing an error defined in &rfc6120;, which is the same error set as for IQs.</li>
+    <li>Messages.  If a message is received and an error situation is encountered, a message of type error MUST be sent back to the message sender. This message format is specified in &rfc6121; containing an error defined in &rfc6120;, which is the same error set as for IQs.</li>
     <li>Presence.  Any responses to presence messages MUST follow the rules of &rfc6121;.</li>
     <li>PubSub.  Where MIX protocol messages use PubSub protocol, the errors defined in &xep0060; MUST be used and supported.</li>
   </ol>
@@ -698,7 +729,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
     <p>A MIX service MUST NOT advertise support for &xep0313;, as MAM is supported by the channels and not by the service.   A  MIX service MUST NOT advertise support for generic &xep0060;, as although MIX makes use of PubSub it is not a generic PubSub service.</p>
   </section2>
   <section2 topic='Discovering the Channels on a Service' anchor='disco-channel-list'>
-    <p>The list of channels supported by a MIX service is obtained by a disco#items command.   The MIX service MUST only return channel that exist and that the user making the query has rights to subscribe to.  </p>
+    <p>The list of channels supported by a MIX service is obtained by a disco#items command.   The MIX service MUST only return channels that exist and that the user making the query has rights to subscribe to.  </p>
     <example caption='Client Queries for Channels on MIX Service'><![CDATA[
 <iq from='hag66@shakespeare.example/UUID-c8y/1573'
     id='kl2fax27'
@@ -730,7 +761,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
   <query xmlns='http://jabber.org/protocol/disco#info' node='mix'/>
 </iq>
 ]]></example>
-    <p> The channel MUST return its identity and the features it supports.  Note that a MIX channel MUST support MAM and so the response will always include both MIX and MAM support.  All disco queries on a MIX channel and results returned MUST include the attribute node='mix'.   The reason for this is to facilitate MIX channels and &xep0045; MUC rooms sharing the same JID.   This extra parameter will enable a server to return appropriate information.</p>
+    <p>If the querying user is allowed to subscribe, the channel MUST return its identity and the features it supports.  Note that a MIX channel MUST support MAM and so the response will always include both MIX and MAM support.  All disco queries on a MIX channel and results returned MUST include the attribute node='mix'.   The reason for this is to facilitate MIX channels and &xep0045; MUC rooms sharing the same JID.   This extra parameter will enable a server to return appropriate information.</p>
     <example caption='Channel Returns Disco Info Result'><![CDATA[
 <iq from='coven@mix.shakespeare.lit'
     id='ik3vs715'
@@ -819,8 +850,8 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
   </section2>
   <section2 topic='Determining the Participants in a Channel' anchor='find-channel-participants'>
     <p>
-      Online clients in the channel are determined from the presence node using PubSub.   Participants in the channel are determined from the Participants Node which will give proxy JID and nick. The jidmap node is used to map to real JIDs.    For JID Hidden channels, only the nicks are returned.  For JID Visible channels, nicks and real JIDs are returned. This query MUST be made directly by a client.</p>
-    <example caption='User&apos;s Server Requests Participant List'><![CDATA[
+         Participants in the channel are determined using PubSub retrieval of the Participants Node which will give proxy JID and nick. </p>
+    <example caption='User&apos;s Client Requests Participant List'><![CDATA[
 <iq from='hag66@shakespeare.example/UUID-c8y/1573'
     id='kl2fax27'
     to='coven@mix.shakespeare.lit'
@@ -830,20 +861,23 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
      </pubsub>
 </iq>
 ]]></example>
-    <example caption='MIX Service Returns Participant List for JID Visible Room'><![CDATA[
+    <example caption='MIX Service Returns Participant List'><![CDATA[
 <iq from='coven@mix.shakespeare.lit'
     id='kl2fax27'
     to='hag66@shakespeare.example/UUID-c8y/1573'
     type='result'>
      <pubsub xlns='http://jabber.org.protocol.pubsub'>
           <items node='urn:xmpp:nodes:participants'>
-             <item jid='hag66@shakespeare.lit' nick='thirdwitch'>
-             <item jid='hag01@shakespeare.lit' nick='top witch'>
+             <item jid='123456#coven@mix.shakespeare.example' nick='thirdwitch'>
+             <item jid='87123#coven@mix.shakespeare.example' nick='top witch'>
            </items>
      </pubsub>
   <items>
 </iq>
 ]]></example>
+    <p>
+      Online clients in the channel can be looked up in a similar manner by PubSub query of the Presence node.
+    </p>
   </section2>
   <section2 topic="Discovering Client MIX Capability" anchor="mix-client-discovery">
     <p>
@@ -877,7 +911,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
 <section1 topic='Use Cases' anchor='usecases'>
   <section2 topic='Common User Use Cases' anchor='usecases-user'>
     <section3 topic='Joining a Channel' anchor='usecase-user-join'>
-      <p>A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to messages, and presence.
+      <p>A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to messages, and presence.
          This will lead to the server subscribing the user to each of the requested nodes associated with the channel. The MIX service will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.
 
       </p>
@@ -925,7 +959,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
     from='coven@mix.shakespeare.example'
     to='hag66@shakespeare.example'
     id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
-  <join xmlns='urn:xmpp:mix:0' jid='coven+123456@mix.shakespeare.example'>
+  <join xmlns='urn:xmpp:mix:0' jid='123456#coven@mix.shakespeare.example'>
     <subscribe node='urn:xmpp:mix:nodes:messages'/>
     <subscribe node='urn:xmpp:mix:nodes:presence'/>
     <subscribe node='urn:xmpp:mix:nodes:participants'/>
@@ -943,7 +977,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
     from='coven@mix.shakespeare.example'
     to='hag66@shakespeare.example/UUID-a1j/7533'
     id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
-  <join xmlns='urn:xmpp:mix:0' jid='coven+123456@mix.shakespeare.example'>
+  <join xmlns='urn:xmpp:mix:0' jid='123456#coven@mix.shakespeare.example'>
     <subscribe node='urn:xmpp:mix:nodes:messages'/>
     <subscribe node='urn:xmpp:mix:nodes:presence'/>
     <subscribe node='urn:xmpp:mix:nodes:participants'/>
@@ -956,14 +990,14 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
 
       <p>
         The following response example shows a successful response to the initial request example where
-        the participant is not be subscribed to all nodes associated with the channel (in this case only messages, participants, and information). This example shows the message from the MIX channel to the user's server, which will be modified and sent to the client.
+        the participant is not subscribed to all nodes associated with the channel (in this case only messages, participants, and information). This example shows the message from the MIX channel to the user's server, which will be modified and sent to the client.
       </p>
       <example caption="Channel Processes Join With Some Nodes Not Subscribed To"><![CDATA[
 <iq type='result'
     from='hag66@shakespeare.example'
     to='coven@mix.shakespeare.example'
     id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
-  <join xmlns='urn:xmpp:mix:0' jid='coven+123456@mix.shakespeare.example'>
+  <join xmlns='urn:xmpp:mix:0' jid='123456#coven@mix.shakespeare.example'>
     <subscribe node='urn:xmpp:mix:nodes:messages'/>
     <subscribe node='urn:xmpp:mix:nodes:participants'/>
     <subscribe node='urn:xmpp:mix:nodes:info'/>
@@ -977,14 +1011,17 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
          id='5A9C7398-DB13-4BFA-A091-2D466C710AAF'>
   <event xmlns='http://jabber.org/protocol/pubsub#event'>
     <items node='urn:xmpp:mix:nodes:participants'>
-      <item id='coven+123456@mix.shakespeare.example'>
+      <item id='123456#coven@mix.shakespeare.example'>
         <participant xmlns='urn:xmpp:mix:0'/>
       </item>
     </items>
   </event>
 </message>
 ]]></example>
-      <p>The user that has been added to the channel is identified by the item id of the item added to the pubsub node, which is the proxy JID of the new channel participant. Note that the &lt;participant&gt; element MUST NOT include a nick of the user being added. The nick MAY be set after the join.</p>
+      <p>The user that has been added to the channel is identified by the item id of the item added to the Participants node, which is the proxy JID of the new channel participant. Note that the &lt;participant&gt; element MUST NOT include a nick of the user being added. The nick MAY be set after the join.</p>
+      <p>
+        At the same time the participant MUST be added to the JID Map node, to map from proxy JID to real JID.   For a JID Maybe Visible channel, the participant MUST be added to the JID Maybe Visible Map node.    The value in this node MUST reflect the user's visibility preference for the channel and MUST be updated to reflect any changes to this preference.
+      </p>
       <p>
         A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request, as shown in the following example.  This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action.
       </p>
@@ -1027,15 +1064,14 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
     </section3>
 
    <section3 topic="User Preferences and Additional Information" anchor="usecase-visibilty-pref">
-     <p>A channel MAY store user preferences and parameters with each user.    There are several standard preference options.
+     <p>A channel MAY store user preferences and parameters with each user.    A user  JID visibility preference has the following values:
        </p>
-     <p>
-       A user  JID visibility preference have the following values:
-     </p>
+     
      <ol>
-       <li>'Default'.   In this setting, the channel default value will be used.  This value is used if another value is not explicitly set.</li>
-       <li>'Never'.  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'.   If this is set, JID will only be shared if mode is JID-visible-mandatory.</li>
+       <li>'Default'.   In this setting, the channel default value will be used.  This value is used if another value is not explicitly set. This means JID is visible for a JID Visible channel and JID is hidden for JID Hidden and JID Maybe Visible channels.</li>
+       <li>'Never'.  If this is set, JID will never be shared and user will be removed from the channel if its mode changes to JID Visible.</li>
+       <li>'Always'.  If this is set, JID will always be shared and users will be removed from the channel if its mode changes to JID Hidden.</li>
+       <li>'Prefer Not'.   If this is set, JID will only be shared if mode is JID Visible.</li>
      </ol>
      <p>
       The user MAY specify that no Private Messages are to be sent from the channel, and allow vCard retrieval.
@@ -1048,12 +1084,12 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
      </p>
      <table caption="Standard User Preference Options">
        <tr><th>Option</th> <th>Values</th><th>Default</th></tr>
-       <tr><td>'JID Visibility'</td> <td>'Default', 'Never',  'Prefer Not'</td>  <td>'Default'</td></tr>
+       <tr><td>'JID Visibility'</td> <td>'Default', 'Never', 'Always', 'Prefer Not'</td>  <td>'Default'</td></tr>
        <tr><td>'Private Messages'</td><td>'Allow', 'Block'</td> <td>'Allow'</td></tr>
        <tr><td>'vCard'</td><td>'Allow', 'Block'</td> <td>'Block'</td></tr>
        <tr><td>'Presence'</td><td>'Share', 'Not Share'</td><td>'Share'</td></tr>
      </table>
-     <p>When joining a channel, the client MAY specify one or more preference options as a &xep0004; form.   In the response, the  server MUST specify all of the user preferences supported by the server, with default values if the user has not requested a different value.  The following example shows joining a channel and setting a preference.  The following example shows the message sent from the user's server to the MIX channel.</p>
+     <p>When joining a channel, the client MAY specify one or more preference options as a &xep0004; form.   In the response, the  server MUST specify all of the user preferences supported by the server, with default values if the user has not requested a different value.  The following example shows joining a channel and setting a preference.  The following example shows the message sent from the user's server to the MIX channel, which will have been preceded by a message from the user's client to the user's server.</p>
      <example caption="User Joins a Channel and Specifies a preference"><![CDATA[
 <iq type='set'
     from='hag66@shakespeare.example'
@@ -1073,7 +1109,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
   </join>
 </iq>
 ]]></example>
-     <p>The following example shows a successful join, which also reports all the user preferences. This is the message coming from the MIX channel to the user's server.  All join operations are addressed by a client to the user's server.</p>
+     <p>The following example shows the result of a successful join, which also reports all the user preferences. This example shows the message coming from the MIX channel to the user's server, which will be sent on to the user.</p>
      <example caption="Channel Successfully Processes Join and returns the preferences set"><![CDATA[
 <iq type='result'
     from='coven@mix.shakespeare.example'
@@ -1184,7 +1220,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
    </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 the user remains as a participant 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.   Leave commands are sent indirectly through the user's server, to enable roster removal.   Leaving is initiated by a client request, as</p>
+      <p>Users generally remain in a channel for an extended period of time.  In particular the user remains as a participant the channel when the user goes offline.  Note that this is different to  &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients.  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.   Leave commands are sent indirectly through the user's server, to enable roster removal.   Leaving is initiated by a client request, as shown in the following example.</p>
 
 
       <example caption="Client Requests to Leave a Channel"><![CDATA[
@@ -1245,7 +1281,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
                 to='hecate@shakespeare.example' id='f5pp2toz'>
   <event xmlns='http://jabber.org/protocol/pubsub#event'>
     <items node='urn:xmpp:mix:nodes:participants'>
-      <retract id='coven+123456@mix.shakespeare.example'/>
+      <retract id='123456#coven@mix.shakespeare.example'/>
     </items>
   </event>
 </message>
@@ -1254,7 +1290,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
                 to='other-witch@shakespeare.example' id='bar'>
   <event xmlns='http://jabber.org/protocol/pubsub#event'>
     <items node='urn:xmpp:mix:nodes:presence'>
-      <retract id='coven+123456@mix.shakespeare.example/8765'/>
+      <retract id='123456#coven@mix.shakespeare.example/8765'/>
     </items>
   </event>
 </message>
@@ -1393,10 +1429,10 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
   <show>dnd</show>
   <status>Making a Brew</status>
 </presence>]]></example>
-      <p>The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node, with the 'publisher' attribute set to the user's participant identifier (the proxy JID). The MIX channel then broadcasts the presence change to all users who are subscribed to the "urn:xmpp:mix:nodes:presence" node.  The presence stanza is sent from the proxy (anonymized) full JID of the user.
+      <p>The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node, with the 'publisher' attribute set to the user's participant identifier (the proxy JID). The MIX channel then broadcasts the presence change to all users who are subscribed to the "urn:xmpp:mix:nodes:presence" node.  The presence stanza is sent from the full proxy JID of the user.
       Note that presence is associated with a client and so will have a full JID as it comes directly from the client and not from the user's server.</p>
       <example caption="Channel Distributes Presence">
-<![CDATA[<presence from='coven+123435@mix.shakespeare.example/678'
+        <![CDATA[<presence from='123435#coven@mix.shakespeare.example/678'
           to='coven@mix.shakespeare.example'
           id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
   <nick xmlns='http://jabber.org/protocol/nick'>thirdwitch</nick>
@@ -1432,8 +1468,90 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
     </section3>
     <section3 topic="Determining Real JIDs" anchor="usecase-real-jids">
       <p>
-        Presence information will provide a MIX client with the nicks and anonymized proxy JIDs for participants.   For JID visible rooms, the user MAY look up the real JID using the "urn:xmpp:mix:nodes:jidmap" node.   The items in this node are identified by proxy JID, and so the real JID can be retrieved using a straightforward PubSub query.    While a user MAY subscribe to the jidmap node, it is more likely to be used to directly look up JIDs as and when needed.
+        Presence information will provide a MIX client with the nicks and  proxy JIDs for participants in a channel.    Messages sent to a channel and retrieved from MAM archives will show the proxy JID and nick of the sender.   It is sometimes useful to determine the real JID associated with proxy JID.  This can always be done for JID Visible channels and can sometimes be done for JID Maybe Visible channels.   
+      
       </p>
+      <p>
+        For current users JID visible rooms, the real JID is found by a PubSub lookup on the JID Map node.  This is shown in the following example:
+      </p>
+      
+      <example caption='Client looks up Real JID from Proxy JID'><![CDATA[
+<iq from='hag66@shakespeare.example/UUID-c8y/1573'
+    id='kl2fax27'
+    to='coven@mix.shakespeare.lit'
+    type='get'>
+     <pubsub xlns='http://jabber.org.protocol.pubsub'>
+          <items node='urn:xmpp:nodes:jidmap'>
+              <item id='123456#coven@mix.shakespeare.example'/>
+          </items>
+     </pubsub>
+</iq>
+
+<iq from='coven@mix.shakespeare.lit'
+    id='kl2fax27'
+    to='hag66@shakespeare.example/UUID-c8y/1573'
+    type='result'>
+     <pubsub xlns='http://jabber.org.protocol.pubsub'>
+          <items node='urn:xmpp:nodes:jidmap'>
+             <item id='123456#coven@mix.shakespeare.example'>
+                 <participant xmlns='urn:xmpp:mix:0'
+                      jid='hecate@mix.shakespeare.example'/>
+             </item>
+           </items>
+     </pubsub>
+  <items>
+</iq>]]> </example>
+
+      
+      <p>For JID Maybe Visible rooms the lookup is performed on the JID Maybe Visible Map node.   Note that where a user prefers to not share real JID, the result of this lookup of proxy JID will be the (same) proxy JID. </p>
+      
+      <p>
+        When an older message is considered, it is possible that the proxy JID of the sender is not current.   Such a JID can be looked up in the MAM Archive of the JID Map Node.  This is shown in the following example:
+      </p>
+      <example caption='Client looks up Real JID from Proxy JID in MAM Archive'><![CDATA[
+<iq from='hag66@shakespeare.example/UUID-c8y/1573'
+    id='kl2fax27'
+    to='coven@mix.shakespeare.lit'
+    type='set'>
+     <query xlns='urn:xmpp:mam:2'
+          queryid='f28'
+          node='urn:xmpp:nodes:jidmap'>
+            <x xmlns='jabber:x:data' type='submit'>
+               <field var='FORM_TYPE' type='hidden'>
+                     <value>urn:xmpp:mam:2</value>
+               </field>
+               <field var='id'>
+                    <value>123456#coven@mix.shakespeare.example</value>
+                </field>
+            </x>      
+     </query>
+</iq>
+
+<message id='iasd208' to='hag66@shakespeare.example/UUID-c8y/1573'>
+  <result xmlns='urn:xmpp:mam:2' queryid='f28' id='28482-20987-73623'>
+    <forwarded xmlns='urn:xmpp:forward:0'>
+      <delay xmlns='urn:xmpp:delay' stamp='2010-07-10T23:08:25Z'/>
+         <message xmlns="jabber:client">
+                  <event xmlns='http://jabber.org/protocol/pubsub#event'>
+                       <items node='urn:xmpp:nodes:jidmap'>
+                           <item id='123456#coven@mix.shakespeare.example'>
+                                  <participant xmlns='urn:xmpp:mix:0'
+                                  jid='hecate@mix.shakespeare.example'/>
+                           </item>
+                       </items>
+                  </event>
+         </message>
+    </forwarded>
+  </result>
+</message>
+
+<iq from='coven@mix.shakespeare.lit'
+    to='hag66@shakespeare.example/UUID-c8y/1573'
+    id='kl2fax27'
+    type='result'>
+</iq>]]> </example>
+      
+      
 
     </section3>
 
@@ -1462,7 +1580,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
 ]]></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 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'
+<![CDATA[<presence from='12345#coven@mix.shakespeare.example/678'
           to='hecate@shakespeare.example'
           id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
           type='unavailable'/>]]></example>
@@ -1488,7 +1606,18 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
 </message>
 ]]></example>
       <p>The MIX channel then puts a copy of the message into the MAM archive for the channel and sends a copy of  the message to each participant in
-        standard groupchat format.    These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's local server.  The message from value is the JID of the channel.  To enable sender identification, the Nick and bare proxy JID of the sender are included in the message as MIX parameters.   The id of the message is the ID from the MAM archive and NOT the id used by the sender.</p>
+        standard groupchat format.    These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's local server.  The message from value is the JID of the channel.  To enable sender identification, the Nick and bare proxy JID of the sender are included in the message as MIX parameters.   The id of the message is the ID from the MAM archive and NOT the id used by the sender. The message placed in the MAM archive is the reflected message without a 'to' element.</p>
+      
+      
+      <example caption="Channel Puts Message in MAM Archive"><![CDATA[
+<message from='coven@mix.shakespeare.example'
+         id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
+         type='groupchat'>
+  <body>Harpier cries: 'tis time, 'tis time.</body>
+  <nick xmlns='urn:xmpp:mix:0'>thirdwitch</nick>
+  <jid xmlns='urn:xmpp:mix:0'>123456#coven@mix.shakespeare.example</jid>
+</message>
+]]></example>
 
       <example caption="Channel Reflects Message to Participants"><![CDATA[
 <message from='coven@mix.shakespeare.example'
@@ -1497,7 +1626,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
          type='groupchat'>
   <body>Harpier cries: 'tis time, 'tis time.</body>
   <nick xmlns='urn:xmpp:mix:0'>thirdwitch</nick>
-  <jid xmlns='urn:xmpp:mix:0'>coven+123456@mix.shakespeare.example</jid>
+  <jid xmlns='urn:xmpp:mix:0'>123456#coven@mix.shakespeare.example</jid>
 </message>
 ]]></example>
       <p>
@@ -1510,7 +1639,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
          type='groupchat'>
   <body>Harpier cries: 'tis time, 'tis time.</body>
   <nick xmlns='urn:xmpp:mix:0'>thirdwitch</nick>
-  <jid xmlns='urn:xmpp:mix:0'>coven+123456@mix.shakespeare.example</jid>
+  <jid xmlns='urn:xmpp:mix:0'>123456#coven@mix.shakespeare.example</jid>
   <submission-id xmlns='urn:xmpp:mix:0'>92vax143g</submission-id>
 </message>
 ]]></example>
@@ -1681,18 +1810,18 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
 
 
     <section3 topic="Requesting vCard" anchor="usecase-vcard">
-      <p>A user MAY request the vCard of a channel participant by sending a request through the channel.  The request MAY be sent directly by the client or MAY be sent by the user's server on behalf of the user.  The MIX channel MAY pass this request on or MAY block it.  vCard requests MAY use &xep0054; (vcard-temp) or &xep0292; (vCard4 over XMPP).  Where a MIX service supports one or both of these protocols, the protocol 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 anonymized bare JID of the channel participant for which the vCard is desired.</p>
+      <p>A user MAY request the vCard of a channel participant by sending a request through the channel.  The request MAY be sent directly by the client or MAY be sent by the user's server on behalf of the user.  The MIX channel MAY pass this request on or MAY block it.  vCard requests MAY use &xep0054; (vcard-temp) or &xep0292; (vCard4 over XMPP).  Where a MIX service supports one or both of these protocols, the protocol 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='coven+989898@mix.shakespeare.example'
+    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 an anonymous full proxy JID to hide the requester.  </p>
+      <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='coven+123456@mix.shakespeare.example/6789'
+<iq from='123456#coven@mix.shakespeare.example/6789'
     id='lx09df27'
     to='peter@shakespeare.lit'
     type='get'>
@@ -1705,7 +1834,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
       <example caption="User's Server sends vCard Response via MIX channel" ><![CDATA[
 <iq from='peter@shakespeare.lit'
     id='lx09df27'
-    to='coven+123456@mix.shakespeare.example/6789'
+    to='123456#coven@mix.shakespeare.example/6789'
     type='result'>
     <vCard xmlns='vcard-temp'>
     <FN>Peter Saint-Andre</FN>
@@ -1724,7 +1853,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
         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='coven+989898@mix.shakespeare.example'
+<iq from='989898#coven@mix.shakespeare.example'
     id='lx09df27'
     to='hag66@shakespeare.example/UUID-c8y/1573'
     type='result'>
@@ -1865,7 +1994,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
             <value>hecate@shakespeare.lit</value>
             <value>greymalkin@shakespeare.lit</value>
         </field>
-        <field var='Message Node Subscription'>
+        <field var='Messages Node Subscription'>
            <value>allowed</value>
          </field>
         <field var='JID Visibility'>
@@ -2090,7 +2219,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
             <value>hecate@shakespeare.lit</value>
             <value>greymalkin@shakespeare.lit</value>
         </field>
-        <field var='Message Node Subscription'>
+        <field var='Messages Node Subscription'>
            <value>allowed</value>
          </field>
         <field var='JID Visibility'>
@@ -2224,7 +2353,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
          type='groupchat'>
   <body>Harpier cries: 'tis time, 'tis time.</body>
   <nick xmlns='urn:xmpp:mix:0'>thirdwitch</nick>
-  <jid xmlns='urn:xmpp:mix:0'>coven+123456@mix.shakespeare.example</jid>
+  <jid xmlns='urn:xmpp:mix:0'>123456#coven@mix.shakespeare.example</jid>
 </message>
 ]]></example>
 
@@ -2239,7 +2368,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
          type='groupchat'>
   <body>Harpier cries: 'tis time, 'tis time.</body>
   <nick xmlns='urn:xmpp:mix:0'>thirdwitch</nick>
-  <jid xmlns='urn:xmpp:mix:0'>coven+123456@mix.shakespeare.example</jid>
+  <jid xmlns='urn:xmpp:mix:0'>123456#coven@mix.shakespeare.example</jid>
 </message>
 
 <message from='coven@mix.shakespeare.example'
@@ -2248,7 +2377,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
          type='groupchat'>
   <body>Harpier cries: 'tis time, 'tis time.</body>
   <nick xmlns='urn:xmpp:mix:0'>thirdwitch</nick>
-  <jid xmlns='urn:xmpp:mix:0'>coven+123456@mix.shakespeare.example</jid>
+  <jid xmlns='urn:xmpp:mix:0'>123456#coven@mix.shakespeare.example</jid>
 </message>
 
 ]]></example>