Slightly update after offlist discussion

This removes the participant ID, as we want to use JIDs for this.
It also puts TODOs around discussions for use of 'real' pubsub for
messages and presence from the room and makes presence to the room
explicitly a normal presence stanza

inbox/mix.xml

@@ -75,17 +75,17 @@
     <li>MIX conversations (roughly equivalent to MUC rooms) are hosted on a MIX domain, e.g. `mix.example.com`, which is discoverable through &xep0030;. Each conversation on the service may then be discovered and queried.</li>
     <li>Re-using the model from &xep0163; (where every user JID (e.g., `user@example.com`) is its own pubsub service), in MIX each conversation (e.g., `conversation@mix.example.com`) is a pubsub service.</li>
     <li>A conversation's pubsub service can contains any number of nodes for different event types or data formats. As described below, this document defines several standard nodes; however, future specifications or proprietary services can define their own nodes for extensibility.</li>
-    <li>All information sharing within the conversation uses standard PubSub semantics from &xep0060;. There are no special-purpose message or presence stanzas, such as those used to join roooms in MUC.</li>
     <li>Affiliations with the nodes are, by default, tied together as affiliations on the conversation itself rather than individual nodes, so that allowing or denying access to a conversation is a single affiliation change.</li>
     <li>&xep0313; (MAM) is used for all history access, with each node being individually addressable for MAM queries. This simplifies implementation compared to MUC (which had a specialized and rather limited history retrieval mechanism).</li>
     <li>A client can achieve a 'quick resync' of a node by requesting just those changes it has not yet received, using standard MAM protocol. This solves the old MUC issue of either receiving duplicate messages when rejoining a room or potentially missing messages.</li>
     <li>Because MAM is used for history, only those nodes that have a 'current value' need to store any items in them - e.g. 'urn:xmpp:mix:nodes:presence' and 'urn:xmpp:mix:nodes:subject' would store their current values (with older values being queryable through MAM), while 'urn:xmpp:mix:nodes:messages' would store no items.</li>
-    <li>In the context of a conversation, each participant is addressable by a stable participant identifier or "PID" that is assigned by the MIX service. This PID is an opaque identifier (such as a UUID) that an be supplemented by a human-friendly "handle" (equivalent to a nickname in MUC). Note that MIX decouples addressing of participants from their handles, so that changes to handles don't modify addressing.</li>
     <li>A user's participation in a conversation outlives their presence session. A user who is offline will not share presence within the conversation, but will still be listed as an participant. This too is a significant departure from MUC.</li>
+    <li>MUC2 decouples addressing of occupants from their nicknames, such that nickname changes don't affect addressing, adding flexibility.</li>
+    <li>Each occupant is addressible by a single JID - in non-anonymous rooms these are just the ocucpant's 'real' JID such that messages between users are only mediated by the MUC2 service in semi-anonymous rooms. These are full JIDs, allowing transparency when a user has multiple online resources participating in the MIX.</li>
   </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. (Note that, like in 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 is purely an example).</p>
-    <p>Every MIX conversation 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. Other than the special "join" command, all communication with the MIX service follows &xep0060;.</p>
+    <p>Every MIX conversation 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, some protocol is added or optimised in this document for the MIX use cases. For example, when a message is published to the 'urn:xmpp:mix:nodes:messages' node, a message unlike a &xep0060; payload is distributed to occupants (more akin to the old &xep0045;); this enables standard XMPP semantics of message stanzas to be used.</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 conversation). Each node can be archived separately (e.g., the presence node or the configuration node). MIX clients can retrieve information archived in MAM in order to quickly resync with regard to a conversation, and can do so without necessarily providing presence information.</p>
@@ -95,7 +95,7 @@
     <ul>
       <li>'urn:xmpp:mix:nodes:messages' for publishing messages. Each item of this node will contain one message, containing each of the distributed payloads.</li>
       <li>'urn:xmpp:mix:nodes:subject' for publishing the subject of the conversation.</li>
-      <li>'urn:xmpp:mix:nodes:participants' for publishing the list of participants, including their details (e.g., the participant IDs in an appropriately configured conversation). This is equivalent to the "room roster" in MUC.</li>
+      <li>'urn:xmpp:mix:nodes:participants' for publishing the list of participants, including their details (e.g., the participant JIDs in an appropriately configured conversation). This is equivalent to the "room roster" in MUC.</li>
       <li>'urn:xmpp:mix:nodes:presence' for publishing information about the availability status of the participants. This is a significant departure from MUC, where occupancy and presence were tightly coupled. In MIX it is possible to have a 'presenceless conversation' by not using this node. As another significant departure from MUC (where a participant is active in the room from multiple resources), information about the presence of each resource associated with an account is individually available, as is normal outside MUC.</li>
       <li>'urn:xmpp:mix:nodes:config' for storing configuration information. In another departure from MUC, by storing configuration in the same manner as other data, it is possible to tweak access rights such that participants are able to read the configuration if desired. A further benefit is that notifications of configuration changes fall out "for free".</li>
       <li>'urn:xmpp:mix:nodes:acl' for storing information about access control lists (such as the list of owners and moderators). Naturally this information might be restricted to authorized users.</li>
@@ -207,7 +207,7 @@
 <section1 topic='Use Cases' anchor='usecases'>
   <section2 topic='Common User Use Cases' anchor='usecases-user'>
     <section3 topic='Joining a Conversation' anchor='usecase-user-join'>
-      <p>A user joins a conversation by sending a MIX "join" command. There's no default set of nodes: all nodes must be specified if the user wants that information (but clients should pick the standard MIX ones at least by default for normal usage). It's possible to forward-subscribe to nodes that don't yet exist, in case they're added (e.g. presence added to a MUC). The server injects a new item into the "urn:xmpp:mix:nodes:participants" node automatically.</p>
+      <p>A user joins a conversation by sending a MIX "join" command. There's no default set of nodes: all nodes must be specified if the user wants that information (but clients should pick the standard MIX ones at least by default for normal usage). It's possible to forward-subscribe to nodes that don't yet exist, in case they're added (e.g. presence added to a MUC). The server injects a new item into the "urn:xmpp:mix:nodes:participants" node automatically. TODO: include the nickname at this point?</p>
         <example caption="User Joins a Conversation"><![CDATA[
 <iq type='set'
     from='hag66@shakespeare.example'
@@ -222,13 +222,13 @@
   </pubsub>
 </iq>
 ]]></example>
-      <p>The conversation must process the join atomically. The conversation responds with an IQ-result. This stanza includes the nodes to which the user was subscribed, as well as the permanent participant identifier (PID) of the user.</p>
+      <p>The conversation must process the join atomically. The conversation responds with an IQ-result. This stanza includes the nodes to which the user was subscribed, as well as the JID that will be used for the user in this room (real JID for non-anonymous rooms, proxy JID for semi-anonymous rooms). TODO: does this need to always be a proxyJID? List discussion.</p>
       <example caption="Conversation Successfully Processes Join"><![CDATA[
 <iq type='result'
     from='coven@mix.shakespeare.example'
     to='hag66@shakespeare.example'
     id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
-  <join xmlns='urn:xmpp:mix:0' pid='3608A5E0C4C8'>
+  <join xmlns='urn:xmpp:mix:0' jid='hag66@shakespeare.example'>
     <subscribe node='urn:xmpp:mix:nodes:messages'/>
     <subscribe node='urn:xmpp:mix:nodes:presence'/>
     <subscribe node='urn:xmpp:mix:nodes:participants'/>
@@ -243,7 +243,7 @@
     from='hag66@shakespeare.example'
     to='coven@mix.shakespeare.example'
     id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
-  <join xmlns='urn:xmpp:mix:0' pid='3608A5E0C4C8'>
+  <join xmlns='urn:xmpp:mix:0' jid='hag66@shakespeare.example'>
     <subscribe node='urn:xmpp:mix:nodes:messages'/>
     <subscribe node='urn:xmpp:mix:nodes:participants'/>
     <subscribe node='urn:xmpp:mix:nodes:subject'/>
@@ -259,7 +259,6 @@
     <items node='urn:xmpp:mix:nodes:participants'>
       <item id='33EB6D2A-3473-4FFB-82DF-C4290FB761E4'>
         <participant xmlns='urn:xmpp:mix:0'
-                     pid='3608A5E0C4C8'
                      jid='hag66@shakespeare.example'
                      nick='thirdwitch'/>
       </item>
@@ -267,10 +266,10 @@
   </event>
 </message>
       ]]></example>
-      <p>Each &lt;participant&gt; element includes a 'pid' attribute, which is the stable participant identifier for this user in this conversation. If this is a transparent conversation, the element MAY include a 'jid' attribute specifying the bare JID of the user. If the user has registered a service-wide nickname, the element MAY also include a 'nick' attribute.</p>
+      <p>Each &lt;participant&gt; element includes a 'jid' attribute, which is the stable participant identifier for this user in this conversation.  TODO: proxy/realJID mapping (admins might see real JIDs even in a semianon room)</p>
     </section3>
     <section3 topic='Registering with a MIX Service' anchor='usecase-user-register'>
-      <p>A user can register with the MIX service (not any particular conversation) by sending a &lt;register/&gt; command to the service.</p>
+      <p>A user can register with the MIX service (not any particular conversation) by sending a &lt;register/&gt; command to the service. TODO: This should be available either room or service-based, with discovery.</p>
       <example caption="User Registers with Service"><![CDATA[
 <iq type='set'
     from='hag66@shakespeare.example/pda'
@@ -307,10 +306,10 @@
   </error>
 </iq>
       ]]></example>
-      <p>If the register request does not contain a &lt;nick/&gt; element, then the MIX service assigns one (this SHOULD be a UUID).</p>
+      <p>If the register request does not contain a &lt;nick/&gt; element, then the MIX service assigns one (this SHOULD be a UUID). TODO: Discuss - is there any reason for this to be a UUID? Surely anything the server wants to assign is fine (with security consideration about leaking JID information).</p>
     </section3>
     <section3 topic='Coming Online' anchor='usecase-user-presence'>
-      <p>Participation in the conversation is decoupled from sending presence through the conversation. A participant comes online by publishing availability to the "urn:xmpp:mix:nodes:presence" node.</p>
+      <p>Participation in the conversation is decoupled from sending presence through the conversation. A participant comes online by publishing availability to the "urn:xmpp:mix:nodes:presence" node. TODO: Move back to using presence normally (suggested with rooms in rosters), for correct 'offline' behaviour, etc.</p>
       <example caption="User Comes Online in the Conversation"><![CDATA[
 <iq type='set'
     from='hag66@shakespeare.example/pda'
@@ -331,7 +330,7 @@
   </pubsub>
 </iq>
       ]]></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.</p>
+      <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. TODO: List discussion on the benefits of wrapping vs. normal presence.</p>
       <example caption="Conversation Distributes Presence"><![CDATA[
 <message from='mix.shakespeare.example'
          to='hecate@shakespeare.example'
@@ -354,23 +353,16 @@
       ]]></example>
     </section3>
     <section3 topic='Going Offline' anchor='usecase-user-offline'>
-      <p>To go offline, the user retracts its availability item from the presence node.</p>
+      <p>To go offline, the user sends a normal unavailable stanza (usually through their server's usual offline broadcast rules).</p>
       <example caption="User Goes Offline in the Conversation"><![CDATA[
-<iq type='set'
+<presence type='unavailable'
     from='hag66@shakespeare.example/pda'
-    to='coven@mix.shakespeare.example'
+    to='coven@mix.shakespeare.example'/>
-    id='bv71gr8m'>
-  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
-    <retract node='urn:xmpp:mix:nodes:presence'>
-      <item id='bnd81g37d61f49fgn581'/>
-    </retract>
-  </pubsub>
-</iq>
       ]]></example>
-      <p>The conversation retracts the item and notifies subscribers to the presence node.</p>
+      <p>The conversation retracts the item and notifies subscribers to the presence node. TODO: Update depending on discussion about events vs. presence.</p>
     </section3>
     <section3 topic='Sending a Message' anchor='usecase-user-message'>
-      <p>A user sends a message by publishing it to messages node.</p>
+      <p>A user sends a message by publishing it to messages node. TODO: List discussion about type=groupchat messages vs. xep60 publish.</p>
       <example caption="User Sends Message to Conversation"><![CDATA[
 <iq type='set'
     from='hag66@shakespeare.example/pda'
@@ -411,7 +403,7 @@
   <leave xmlns='urn:xmpp:mix:0'/>
 </iq>
       ]]></example>
-      <p>Note that leaving the conversation is a permanent action, not just a matter of telling the conversation that the user is not currently available (as in MUC). If the user leaves the conversation, the MIX service is responsible for unsubscribing the user from all nodes in the conversation, and also for telling participants that the user is offline.</p>
+      <p>Note that leaving the conversation is a permanent action for a user across all clients, not just a matter of telling the conversation that the user is not currently available (as in MUC), or for a single client. If the user leaves the conversation, the MIX service is responsible for unsubscribing the user from all nodes in the conversation, and also for telling participants that the user is offline.</p>
     </section3>
     <section3 topic='Inviting a Contact To a Conversation' anchor='usecase-user-invite'>
       <p>User sends to conversation requesting invite, receives it, forwards it to contact. Solves issues with both directed and mediated invites. ### TODO: Dave had a point about contact preverification about users' invites. Discuss.</p>