Add MUC Comparison Introduction Section;

xep-0369.xml

@@ -50,6 +50,7 @@
       Replace contents of section 6.3 (Ensuring Message Delivery) with reference to future XEP;
       Add MIX Channels in Roster Section;
       Add Proxy JID Architecture Section;
+      Add MUC Comparison Introduction Section;
     </p></remark>
   </revision>
   <revision>
@@ -387,6 +388,39 @@
 </section1>
 
 <section1 topic='Concepts' anchor='concepts'>
+  <section2 topic="Comparsion to MUC" anchor="concepts-muc-comparison">
+    <p>
+      This  section is written as an introduction to MIX for those with detailed knowledge of &xep0045;, to summarize key differences and some rationale for the differences.   For those unfamiliar with MUC, this section should be ignored.
+    </p>
+    <p>
+      In MUC, a client joins a MUC room.   After this, the client is sent history information, presences, and messages until the client leaves the room by going offline.  Key MIX features as summarized below:
+    </p>
+    <ol>
+      <li>MIX has "channels", which are equivalent to MUC rooms.</li>
+   
+      <li>MIX separates out various services, in particular messages and presence.   A MUC channel is implemented as a set of PubSub nodes, and a user (not client) can subscribe to a set of nodes.  This control means that users can subscribe to presence and/or messages, which gives useful flexibility.  This addresses requirements 3 and 5.  Subscribing to message and presence nodes gives a service broadly equivalent to MUC.</li>
+      
+      <li>Messages and presence sent by a MIX channel use the same formats as MUC and do not use PubSub encodings.</li>
+      
+      <li>Channels do not have a "subject".  This MUC capability is not supported by core MIX.</li>
+      
+      <li>Users join MIX channels for an extended period and participation is not impacted by clients going online and offline (requirement 1).   This means that a MIX client uses channel subscriptions as negotiated by the MIX user.</li>
+      
+      <li>MIX messages and presence are always sent and are addressed to the user (bare JID).   This addressing is a consequence of users (not clients) being the participants in a MIX channel; It is a key difference between MUC and MIX.  This addressing change means that the user's server needs to have MIX-specific behaviour to correctly distribute arriving messages and presence appropriately to MIX clients; there may be zero or more online clients that support MIX.   This server behaviour is specified by MIX. </li>
+      
+      <li>MIX messages are archived using MAM on the user's server.   This enables flexible access to channel history, independent of the MIX channel server. </li>
+      
+      <li>A user's roster contains the MIX channels to which the user is subscribed.   A client can use a MIX roster extension to determine which MIX channels the user is subscribed to.   When a client comes online, this will lead to directed presence for the client to be sent to each MIX channel.   A MIX channel can then share the user's presence with channel participants that have subscribed to the presence.    The MIX channel will also return to the client a full list of presence information for the channel.   This means that when a client comes online, it will receive presence updates for the participants in all subscribed MIX channels.</li>
+      
+      <li>In MIX, a Nick belongs to the user and not to each client.</li>
+      
+      <li>
+        MUC semi-anonymous rooms are achieved by sharing on the Nick with room members.    MIX provides a similar capability to address requirement 7, which is that channels have "JID Hidden" and "JID Visible" options.   A mechanism is provided that is common for all channels, so that operation flow is the same for all channels and it is easy to switch between JID Visible and JID Hidden.   Each channel participant has an anonymized proxy JID that references the user in the channel.   There is a PubSub mechanism to map proxy JID to Nick which allows clients to look up (current) Nick for a proxy JID.   There is also a PubSub mechanism to map from proxy JIDs to real JIDs.  This mechanism is used by the channel to map JIDs and may be used by clients in JID Visible channels to determine the JID.
+      </li>
+   
+    </ol>
+  </section2>
+  
   <section2 topic="Specification Appproach" anchor="concepts-approach">
     <p>
       MIX will enable a wide range of auxiliary services.  The goal of the MIX specification is to set out the core capabilities needed for MIX.   It is anticipated that additional XEPs will be written to extend the core MIX, and the core MIX specification notes some areas where this may happen.  This approach will avoid the core MIX specification becoming unduly large.   Profiles referencing sets of related MIX XEPs may be developed in the future.