Sort Advertizing MAM

Address various clarifications in MIX/MUC, PAM

xep-0369.xml

@@ -100,7 +100,9 @@
 </section1>
 
 <section1 topic='Requirements' anchor='reqs'>
-  <ul>
+
+<p>The following requirements have been identified, which MIX aims to address.</p>
+  <ol>
     <li>A user's participation in a channel persists and is not modified by the user's client going online and offline.</li>
     <li>Multiple devices associated with the same account can share the same nick in the channel, with well-defined rules making each client individually addressable.</li>
     <li>Channels are not required to support or reflect presence for participants.</li>
@@ -115,12 +117,12 @@
     <li>To enable sharing of messages on a channel without requiring sharing of presence.</li>
     <li>To enable sharing of presence without requiring message sending.</li>
     <li>(Desirable) Make it easier to reduce duplicate traffic.</li>
- </ul>
+ </ol>
 </section1>
 
 <section1 topic='Concepts' anchor='concepts'>
   <p>The following concepts underlie the design of MIX.</p>
-  <ul>
+  <ol>
     <li>MIX channels (roughly equivalent to MUC rooms) are hosted on one or more MIX domains, (examples: 'mix.example.com'; 'conference.example.com'; 'talk.example.com'), which are discoverable through &xep0030;. Each channel on a MIX service may then be discovered and queried.</li>
     <li> In MIX each channel (e.g., 'channel@mix.example.com') is a pubsub service. This is based on the model from &xep0163; where every user JID (e.g., 'user@example.com') is its own pubsub service. </li>
     <li>A channel's pubsub service contains a 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>
@@ -132,7 +134,8 @@
     <li>A user's participation in a channel outlives their session. A user who is offline will not share presence within the channel, but will still be listed as an participant. This too is a significant departure from MUC.</li>
     <li>MIX decouples addressing of occupants 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 are then constructed, allowing visibility into the number of online resources participating in a channel.</li>
-  </ul>
+    <li>MIX requires client support and server support from the server providing the MIX service.  Although some protocol is shared with MUC, MUC clients are not interoperable with MIX servers.  This means that where a user chooses to use MIX, all of the users clients need to support MIX.</li>
+  </ol>
   <section2 topic="MIX and PubSub" anchor="concepts-pubsub">
     <p>MIX is based upon domains providing a MIX service, such as 'mix.shakespeare.example'. Note that although PubSub communication is used, a domain used for MIX is a MIX domain and not a standard &xep0060; domain. Like MUC, there is no requirement on the naming of these domains; the label 'mix' and the fact that it is a subdomain of a 'shakespeare.example' service are purely for example.</p>
     <p>Every MIX channel is an addressable PubSub service (with additional MIX semantics) that will be addressed using a bare JID by other XMPP entities, for example coven@mix.shakespeare.example. While &xep0060; is used as the basis for the MIX model, MIX uses standard presence and groupchat messages to provide an interface to the MIX service that does not expose PubSub protocol for many of the more common functions.
@@ -146,11 +149,18 @@
        The primary model is that a user will join a channel over an extended period, and that the user (not a specific client used by the user) joins the channel. The primary subscription is with the client's bare JID. The user will receive messages from the channel and/or access channel presence from time to time with one or more clients.
      </p>
     <p>
-      Where a user has no clients active, the approach is that all messages will be archived by the MIX channel (on arrival at the MIX channel) so that when clients come online they will use MAM to communicate to the MIX channel to access messages that have not been delivered to the client.   Following the rules of &rfc6121;, arriving MIX messages (which will be of type=groupchat) will be discarded if all clients are offline. Offline messages are not used with MIX.
+      Where a user has no clients active, the approach is that all messages will be archived by the MIX channel (on arrival at the MIX channel) so that when clients come online they will use MAM to communicate to the MIX channel to access messages that have not been delivered to the client.   Following the rules of &rfc6121;, arriving MIX messages (which will be of type=groupchat)  and presence information will be discarded if all clients are offline. Offline messages are not used with MIX.  This means that a MIX client needs to resynchronize with the MIX service when it comes online.
     </p>
     <p>
-      Online clients are handled use &xep0376;.
+      MIX delivery does not require any special support from the XMPP server to which the MIX client connects.   When using a basic XMPP server for this service,  all online clients for a user will receive the same set of messages and presence information, as MIX sends this information to the bare JID.
-      The model is that the server will know which of the user's clients are interested in MIX messages, possibly filtered by MIX channel, and will deliver messages appropriately to these clients. MIX will send messages to the user's server addressed with the bare JID of the user. The user's server will then deliver messages to the user's clients, in a manner that is transparent to the MIX server. The same approach is used for sending presence updates to the user, noting that presence information is distributed by a channel to the bare JID of subscribers and then the user's server will distribute to clients as appropriate.
+    </p>
+  </section2>
+  
+  <section2 topic="Advanced Delivery to Online Users" anchor="concepts-online-delivery">
+    
+    <p>
+      It may be desirable in some situtations to provide different service to different clients.  For example, a mobile client may participate in a smaller set of MIX channels than a desktop client.  This needs support from the server to which the client connects, so that MIX client and the connected server can negotiate which channels to send.   This is not supported by the core MIX specification, but it is anticipated that this will be supported by another specification.  
+     This may be &xep0376; (PAM) or a new specification similar to PAM developed specifically in support of MIX.
     </p>
   </section2>
   <section2 topic="User Presence in MIX" anchor="concepts-presence">
@@ -386,22 +396,14 @@
         name='Shakespearean Chat Service'
         type='text'/>
     <feature var='urn:xmpp:mix:0'/>
-    <x xmlns='jabber:x:data' type='result'>
-      <field var='FORM_TYPE' type='hidden'>
-        <value>urn:xmpp:mix:0#serviceinfo</value>
-      </field>
-      <field var='muc-mirror'
-             type='jid-single'
-             label='Location of MUC mirror service'>
-        <value>chat.shakespeare.example</value>
-      </field>
     </x>
   </query>
 </iq>
 ]]></example>
     <p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'.
-      If the MIX service is mirrored to a MUC service for backwards-compatibility, this SHOULD be signaled by the inclusion of field with var='muc-mirror', the value of which is the mirrored MUC domain's JID.  Where a MIX server supports MIX channels as &xep0045; rooms, the domain used for MUC may be different to the MIX domain or it MAY be the same.</p>
+     </p>
-    <p>Note that the MIX service doesn't advertise support for &xep0313;, nor is support for generic &xep0060; advertised.</p>
+    <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 adverstize 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 command.</p>
@@ -420,7 +422,7 @@
   <query xmlns='http://jabber.org/protocol/disco#info'/>
 </iq>
 ]]></example>
-    <p>The channel MUST return its identity and the features it supports:</p>
+    <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.</p>
     <example caption='Channel Returns Disco Info Result'><![CDATA[
 <iq from='coven@mix.shakespeare.lit'
     id='ik3vs715'
@@ -432,6 +434,7 @@
         name='A Dark Cave'
         type='mix'/>
     <feature var='urn:xmpp:mix:0'/>
+    <feature var='urn:xmpp:mam:1'/>
   </query>
 </iq>
 ]]></example>
@@ -1008,6 +1011,104 @@
 </section1>
 
 
+<section1 topic="Supporting MIX and MUC together" anchor="mix-and-muc-together">
+  <p>
+    MIX is specified as a service that can be used independent of MUC and a MIX service may be implemented without MUC.  If both MIX and MUC are implemented, three approaches are noted.
+  </p>
+  <ol>
+    <li>Entirely separate MIX and MUC implementation, with MIX and MUC using separate domains and MIX channels being completely separate from MUC rooms.</li>
+    
+    <li>Fully integrated MIX and MUC implementation, with MIX and MUC sharing a single domain and rooms/channels equivalent.</li>
+    
+    <li>Partially integrated MIX and MUC implementation, with MIX and MUC using separate domains, but rooms/channel are common.  This means that each MIX channel will have MUC room of the same name and common membership.</li>
+  </ol>
+  
+  <p>The fully integrated approach would be transparent to clients.    Disco of a room or channel would show support for both MUC and MIX, which would enable a client to choose whether to use MUC or MIX.  The following example shows how a MIX service that also supported MUC would respond:</p>
+  
+  <example caption="Service responds with Disco Info result showing MIX and MUC support" ><![CDATA[
+<iq from='mix.shakespeare.example'
+    id='lx09df27'
+    to='hag66@shakespeare.example/intibo24'
+    type='result'>
+  <query xmlns='http://jabber.org/protocol/disco#info'>
+    <identity
+        category='conference'
+        name='Shakespearean Chat Service'
+        type='text'/>
+    <feature var='urn:xmpp:mix:0'/>
+    <feature var='http://jabber.org/protocol/muc'/>
+    <x xmlns='jabber:x:data' type='result'>
+      <field var='FORM_TYPE' type='hidden'>
+        <value>urn:xmpp:mix:0#serviceinfo</value>
+      </field>
+    </x>
+  </query>
+</iq>
+]]></example>
+  
+  
+  <p>For the partially integrated service, it will be useful for clients that support both MIX and MUC to be able to determine that the server supports both protocols.   For a MIX client, it will be useful to know the MUC service, so that this information can be shared with a MUC client invitation.   This information is provided by the initial service discovery:</p>
+  
+  
+    <example caption="MIX Service responds with Disco Info result sharig MUC service location" ><![CDATA[
+<iq from='mix.shakespeare.example'
+    id='lx09df27'
+    to='hag66@shakespeare.example/intibo24'
+    type='result'>
+  <query xmlns='http://jabber.org/protocol/disco#info'>
+    <identity
+        category='conference'
+        name='Shakespearean Chat Service'
+        type='text'/>
+    <feature var='urn:xmpp:mix:0'/>
+    <x xmlns='jabber:x:data' type='result'>
+      <field var='FORM_TYPE' type='hidden'>
+        <value>urn:xmpp:mix:0#serviceinfo</value>
+      </field>
+      <field var='muc-mirror'
+             type='jid-single'
+             label='Location of MUC mirror service'>
+        <value>chat.shakespeare.example</value>
+      </field>
+    </x>
+  </query>
+</iq>
+]]></example>
+    
+    <p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'.  THe  field with var='muc-mirror' is the value of which is the mirrored MUC domain's JID.  </p>
+   
+    <p>Where a client supporting both MIX and MUC is given a reference to a MUC room, it is desirable that the client can determine the MIX channel and join using MIX.   This is achieved by an equivalent extension to MUC service discover.</p>
+  
+  <example caption="MUC Service responds with Disco Info result sharig MIX service location" ><![CDATA[
+<iq from='chat.shakespeare.example'
+    id='lx09df27'
+    to='hag66@shakespeare.example/intibo24'
+    type='result'>
+  <query xmlns='http://jabber.org/protocol/disco#info'>
+    <identity
+        category='conference'
+        name='Shakespearean Chat Service'
+        type='text'/>
+    <feature var='http://jabber.org/protocol/muc'/>    
+    <x xmlns='jabber:x:data' type='result'>
+      <field var='FORM_TYPE' type='hidden'>
+        <value>urn:xmpp:mix:0#serviceinfo</value>
+      </field>
+      <field var='mix-mirror'
+             type='jid-single'
+             label='Location of MUC mirror service'>
+        <value>mix.shakespeare.example</value>
+      </field>
+    </x>
+  </query>
+</iq>
+]]></example>
+  
+  <p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'.  THe  field with var='mix-mirror' is the value of which is the mirrored MIX domain's JID.  </p>
+  
+  
+
+</section1>
 
 
 <!--<section1 topic='Implementation Notes' anchor='impl'>