moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-22 07:38:52 -05:00
Code Issues Releases Wiki Activity

Namespace bump to mix:1

Browse Source
This commit is contained in:
Steve Kille 2017-06-20 09:42:17 +01:00
parent c478a562ba
commit 8e5e03168a
1 changed files with 107 additions and 106 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

213
xep-0369.xml
View File

@ -50,6 +50,7 @@
Change mix_nick_register to nick-register;
Separate namespace for roster information;
rename jidmap2 to jidmap-visible;
version bump to urn:xmpp:mix:1;
</p></remark>
</revision>
<revision>
@ -503,7 +504,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</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 '123456#coven@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a &lt;participant/&gt; element qualified by the 'urn:xmpp:mix:0' namespace. The nick associated with the user is mandatory and is stored in a &lt;nick/&gt; child element of the &lt;participant/&gt; element. 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'. Information is stored in a &lt;participant/&gt; element qualified by the 'urn:xmpp:mix:1' namespace. The nick associated with the user is mandatory and is stored in a &lt;nick/&gt; child element of the &lt;participant/&gt; element. 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.
@ -515,7 +516,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<example caption="Value of Participants Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:participants'>
<item id='123456#coven@mix.shakespeare.example'>
<participant xmlns='urn:xmpp:mix:0'>
<participant xmlns='urn:xmpp:mix:1'>
<nick>thirdwitch</nick>
</participant>
</item>
@ -526,11 +527,11 @@ 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. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap'. 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 and JID Maybe Visible channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant. Information is stored in a &lt;participant/&gt; element qualified by the 'urn:xmpp:mix:0' namespace. The real JID is stored in a &lt;jid/&gt; child element of the &lt;participant/&gt; element. </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. Information is stored in a &lt;participant/&gt; element qualified by the 'urn:xmpp:mix:1' namespace. The real JID is stored in a &lt;jid/&gt; child element of the &lt;participant/&gt; element. </p>
<example caption="Value of JID Map Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:jidmap'>
<item id='123456#coven@mix.shakespeare.example'>
<participant xmlns='urn:xmpp:mix:0'>
<participant xmlns='urn:xmpp:mix:1'>
<jid>hecate@mix.shakespeare.example</jid>
</participant>
</item>
@ -590,7 +591,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<item id='2016-05-30T09:00:00'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
<value>urn:xmpp:mix:1</value>
</field>
<field var='Name'>
<value>Witches Coven</value>
@ -670,7 +671,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<item id='2016-05-30T09:00:00'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
<value>urn:xmpp:mix:1</value>
</field>
<field var='Owner'>
<value>hecate@shakespeare.lit</value>
@ -742,7 +743,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<p>The MIX service then MUST return its identity and the features it supports, which MUST include the 'urn:xmpp:mix:0' feature, and the identity MUST have a category of 'conference' and a type of 'text', as shown in the following example: </p>
<p>The MIX service then MUST return its identity and the features it supports, which MUST include the 'urn:xmpp:mix:1' feature, and the identity MUST have a category of 'conference' and a type of 'text', as shown in the following example: </p>
<example caption="Service responds with Disco Info result" ><![CDATA[
<iq from='mix.shakespeare.example'
id='lx09df27'
@ -753,18 +754,18 @@ This approach enables flexible support of multiple clients for a MIX channel pa
category='conference'
name='Shakespearean Chat Service'
type='text'/>
<feature var='urn:xmpp:mix:0'/>
<feature var='urn:xmpp:mix:0#searchable'>
<feature var='urn:xmpp:mix:1'/>
<feature var='urn:xmpp:mix:1#searchable'>
</query>
</iq>
]]></example>
<p>
A MIX service MUST return the 'urn:xmpp:mix:0' feature and MAY return the other features listed here:
A MIX service MUST return the 'urn:xmpp:mix:1' feature and MAY return the other features listed here:
</p>
<ul>
<li>'urn:xmpp:mix:0': This indicates support of MIX, and is returned by all MIX services.</li>
<li>'urn:xmpp:mix:0#searchable': This is shown in the above example and indicates that a the MIX Service MAY be searched for channels. This presence of this feature can be used by a client to guide the user to search for channels in a MIX service.</li>
<li>'urn:xmpp:mix:0#create-channel': This is described in <link url='#usecase-admin-check-create'> Checking for Permission to Create a Channel</link> in support of channel administration. When an end user client needs to create channels, perhaps for short term usage, this feature helps the client to identify an MIX service to use. It enables a configuration where permanent (searchable) channels are placed in one MIX service and clients will be able to create channels in another MIX service which is not searchable.</li>
<li>'urn:xmpp:mix:1': This indicates support of MIX, and is returned by all MIX services.</li>
<li>'urn:xmpp:mix:1#searchable': This is shown in the above example and indicates that a the MIX Service MAY be searched for channels. This presence of this feature can be used by a client to guide the user to search for channels in a MIX service.</li>
<li>'urn:xmpp:mix:1#create-channel': This is described in <link url='#usecase-admin-check-create'> Checking for Permission to Create a Channel</link> in support of channel administration. When an end user client needs to create channels, perhaps for short term usage, this feature helps the client to identify an MIX service to use. It enables a configuration where permanent (searchable) channels are placed in one MIX service and clients will be able to create channels in another MIX service which is not searchable.</li>
</ul>
<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>
@ -812,7 +813,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
category='conference'
name='A Dark Cave'
type='mix'/>
<feature var='urn:xmpp:mix:0'/>
<feature var='urn:xmpp:mix:1'/>
<feature var='urn:xmpp:mam:1'/>
</query>
</iq>
@ -866,10 +867,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<pubsub xlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:mix:nodes:info>>
<item>
<item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:0'>
<item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:1'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
<value>urn:xmpp:mix:1</value>
</field>
<field var='Name'>
<value>Witches Coven</value>
@ -909,12 +910,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<pubsub xlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:mix:nodes:participants'>
<item id='123456#coven@mix.shakespeare.example'>
<participant xmlns='urn:xmpp:mix:0'>
<participant xmlns='urn:xmpp:mix:1'>
<nick>thirdwitch</nick>
</participant>
</item>
<item id='87123#coven@mix.shakespeare.example'>
<participant xmlns='urn:xmpp:mix:0'>
<participant xmlns='urn:xmpp:mix:1'>
<nick>top witch</nick>
</participant>
</item>
@ -949,7 +950,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<feature var='http://jabber.org/protocol/disco#info'/>
<feature var='http://jabber.org/protocol/disco#items'/>
<feature var='http://jabber.org/protocol/muc'/>
<feature var='urn:xmpp:mix:0'/>
<feature var='urn:xmpp:mix:1'/>
</query>
</iq>
]]></example>
@ -959,7 +960,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 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. The &lt;join/&gt; is a child element of &lt;iq/&gt; element. The &lt;join/&gt; element is qualified by the 'urn:xmpp:mix:0' namespace. The channel is specified by a 'channel' attribute in the &lt;join/&gt; element. The requested nodes are encoded as &lt;subscribe/&gt; child elements of the &lt;join/&gt; element.
<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. The &lt;join/&gt; is a child element of &lt;iq/&gt; element. The &lt;join/&gt; element is qualified by the 'urn:xmpp:mix:1' namespace. The channel is specified by a 'channel' attribute in the &lt;join/&gt; element. The requested nodes are encoded as &lt;subscribe/&gt; child elements of the &lt;join/&gt; element.
The join leads 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>
@ -975,7 +976,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example/UUID-a1j/7533'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:0'
<join xmlns='urn:xmpp:mix:1'
channel='coven@mix.shakespeare.example'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
@ -993,7 +994,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:0'>
<join xmlns='urn:xmpp:mix:1'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
<subscribe node='urn:xmpp:mix:nodes:participants'/>
@ -1007,7 +1008,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='123456#coven@mix.shakespeare.example'>
<join xmlns='urn:xmpp:mix:1' 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'/>
@ -1025,7 +1026,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='123456#coven@mix.shakespeare.example'>
<join xmlns='urn:xmpp:mix:1' 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'/>
@ -1045,7 +1046,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:0' jid='123456#coven@mix.shakespeare.example'>
<join xmlns='urn:xmpp:mix:1' 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'/>
@ -1060,7 +1061,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:mix:nodes:participants'>
<item id='123456#coven@mix.shakespeare.example'>
<participant xmlns='urn:xmpp:mix:0'/>
<participant xmlns='urn:xmpp:mix:1'/>
</item>
</items>
</event>
@ -1071,14 +1072,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa
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 encoded as a &lt;update-subscription/$gt; child element of &lt;iq/&gt; element. The &lt;update-subscription/$gt; element is qualified by the 'urn:xmpp:mix:0' namespace. The requested notes are encoded as &lt;subscribe/&gt; child elements of the &lt;update-subscription/$gt; element with the node name encoded as a 'node' attribute. 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. The following example shows subscription modification.
A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a &lt;update-subscription/$gt; child element of &lt;iq/&gt; element. The &lt;update-subscription/$gt; element is qualified by the 'urn:xmpp:mix:1' namespace. The requested notes are encoded as &lt;subscribe/&gt; child elements of the &lt;update-subscription/$gt; element with the node name encoded as a 'node' attribute. 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. The following example shows subscription modification.
</p>
<example caption="User Modifies Subscription Request"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<update-subscription xmlns='urn:xmpp:mix:0'>
<update-subscription xmlns='urn:xmpp:mix:1'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
</update-subscription>
</iq>
@ -1087,7 +1088,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'>
<update-subscription xmlns='urn:xmpp:mix:0' jid='hag66@shakespeare.example'>
<update-subscription xmlns='urn:xmpp:mix:1' jid='hag66@shakespeare.example'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
</update-subscription>
</iq>
@ -1143,12 +1144,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:0'>
<join xmlns='urn:xmpp:mix:1'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
<value>urn:xmpp:mix:1</value>
</field>
<field var='JID Visibility'>
<value>never</value>
@ -1163,12 +1164,12 @@ 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='hag66@shakespeare.example'>
<join xmlns='urn:xmpp:mix:1' jid='hag66@shakespeare.example'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
<value>urn:xmpp:mix:1</value>
</field>
<field var='JID Visibility'>
<value>never</value>
@ -1183,23 +1184,23 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</join>
</iq>
]]></example>
<p>The client MAY also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard, by providing a form template in the result. The request is encoded as a &lt;user-preference/&gt; child element of &lt;iq/&gt;. &lt;user-preference/&gt; is qualified by the 'urn:xmpp:mix:0' namespace. The result is encoded as a form child element in the &lt;user-preference/&gt; element.</p>
<p>The client MAY also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard, by providing a form template in the result. The request is encoded as a &lt;user-preference/&gt; child element of &lt;iq/&gt;. &lt;user-preference/&gt; is qualified by the 'urn:xmpp:mix:1' namespace. The result is encoded as a form child element in the &lt;user-preference/&gt; element.</p>
<example caption="User Requests and Recieves Preferences Template Form"><![CDATA[
<iq type='get'
from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<user-preference xmlns='urn:xmpp:mix:0'/>
<user-preference xmlns='urn:xmpp:mix:1'/>
</iq>
<iq type='result'
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example/UUID-a1j/7533'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<user-preference xmlns='urn:xmpp:mix:0'>
<user-preference xmlns='urn:xmpp:mix:1'>
<x xmlns='jabber:x:data' type='form'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
<value>urn:xmpp:mix:1</value>
</field>
<field type='list-single' label='Preference for JID Visibility'
var='JID Visibility'>
@ -1226,10 +1227,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<user-preference xmlns='urn:xmpp:mix:0'/>
<user-preference xmlns='urn:xmpp:mix:1'/>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
<value>urn:xmpp:mix:1</value>
</field>
<field var='JID Visibility'>
<value>never</value>
@ -1247,10 +1248,10 @@ 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'>
<user-preference xmlns='urn:xmpp:mix:0'>
<user-preference xmlns='urn:xmpp:mix:1'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
<value>urn:xmpp:mix:1</value>
</field>
<field var='JID Visibility'>
<value>never</value>
@ -1268,7 +1269,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 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. The leave command is encoded as a &lt;leave/&gt; child element of &lt;iq/&gt; element. The &lt;leave/&gt; element is qualified by the 'urn:xmpp:mix:0' namespace, with the channel specified as a 'channel" attribute. 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>
<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. The leave command is encoded as a &lt;leave/&gt; child element of &lt;iq/&gt; element. The &lt;leave/&gt; element is qualified by the 'urn:xmpp:mix:1' namespace, with the channel specified as a 'channel" attribute. 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[
@ -1276,7 +1277,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example/UUID-a1j/7533'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<leave xmlns='urn:xmpp:mix:0'
<leave xmlns='urn:xmpp:mix:1'
channel=`coven@mix.shakespeare.example`/>
</iq>
]]></example>
@ -1290,7 +1291,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<leave xmlns='urn:xmpp:mix:0'/>
<leave xmlns='urn:xmpp:mix:1'/>
</iq>
]]></example>
@ -1302,7 +1303,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'>
<leave xmlns='urn:xmpp:mix:0'/>
<leave xmlns='urn:xmpp:mix:1'/>
</iq>
]]></example>
@ -1316,7 +1317,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'>
<leave xmlns='urn:xmpp:mix:0'/>
<leave xmlns='urn:xmpp:mix:1'/>
</iq>
]]></example>
<p>When the user leaves the channel, the MIX service is responsible for unsubscribing the user from all nodes in the channel and for removing the user from the participants and presence list. If the user has online presence when the user leaves the channel, the change of presence status caused by removing the user's entry or entries from the presence node will ensure that subscribers to the presence node are correctly updated on presence status.
@ -1358,14 +1359,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<li>The MIX service generates the nick. In this case it is RECOMMENDED that the assigned nick is a UUID following &rfc4122;.</li>
</ol>
<p>
A user will typically set a nick when joining a channel and MAY update this nick from time to time. The user does this by sending a command to the channel to set the nick. This command is a &lt;setnick/&gt; child element of &lt;iq/&gt; element. The &lt;setnick/&gt; element is qualified by the 'urn:xmpp:mix:0' namespace. The nick is encoded as a &lt;nick/&gt; child element of the &lt;setnick/&gt; element. If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result.
A user will typically set a nick when joining a channel and MAY update this nick from time to time. The user does this by sending a command to the channel to set the nick. This command is a &lt;setnick/&gt; child element of &lt;iq/&gt; element. The &lt;setnick/&gt; element is qualified by the 'urn:xmpp:mix:1' namespace. The nick is encoded as a &lt;nick/&gt; child element of the &lt;setnick/&gt; element. If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result.
</p>
<example caption="User sets Nick on Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'
id='7nve413p'>
<setnick xmlns='urn:xmpp:mix:0'>
<setnick xmlns='urn:xmpp:mix:1'>
<nick>thirdwitch</nick>
</setnick>
</iq>
@ -1380,7 +1381,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='7nve413p'>
<setnick xmlns='urn:xmpp:mix:0'>
<setnick xmlns='urn:xmpp:mix:1'>
<nick>thirdwitch</nick>
</setnick>
</iq>
@ -1406,22 +1407,22 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='mix.shakespeare.example'
id='7nve413p'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
<feature var='urn:xmpp:mix:0#nick-register'/>
<feature var='urn:xmpp:mix:1#nick-register'/>
</query>
</iq>
]]></example>
<p>
The response will be a list of features of the MIX channel. If Nick Registration is supported, then the result set will include &lt;feature var="urn:xmpp:mix:0#nick-register"/&gt;.
The response will be a list of features of the MIX channel. If Nick Registration is supported, then the result set will include &lt;feature var="urn:xmpp:mix:1#nick-register"/&gt;.
</p>
<p>
To register a nick with the MIX service the user sends
a register command to the service. This is encoded as a &lt;register/&gt; child element of an &lt;iq/&gt; element. The &lt;register/&gt; element is qualified by the urn:xmpp:mix:0' namespace. The nick is encoded in a &lt;nick/&gt; child element of the &lt;register/&gt; element. </p>
a register command to the service. This is encoded as a &lt;register/&gt; child element of an &lt;iq/&gt; element. The &lt;register/&gt; element is qualified by the urn:xmpp:mix:1' namespace. The nick is encoded in a &lt;nick/&gt; child element of the &lt;register/&gt; element. </p>
<example caption="User Registers with Service"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/UUID-a1j/7533'
to='mix.shakespeare.example'
id='7nve413p'>
<register xmlns='urn:xmpp:mix:0'>
<register xmlns='urn:xmpp:mix:1'>
<nick>thirdwitch</nick>
</register>
</iq>
@ -1437,7 +1438,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
to='mix.shakespeare.example'
from='hag66@shakespeare.example/UUID-a1j/7533'
id='7nve413p'>
<register xmlns='urn:xmpp:mix:0'>
<register xmlns='urn:xmpp:mix:1'>
<nick>thirdwitch</nick>
</register>
</iq>
@ -1547,7 +1548,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<pubsub xlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:mix:nodes:jidmap'>
<item id='123456#coven@mix.shakespeare.example'>
<participant xmlns='urn:xmpp:mix:0'>
<participant xmlns='urn:xmpp:mix:1'>
<jid>hecate@mix.shakespeare.example<jid/>
</participant>
</item>
@ -1589,7 +1590,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:mix:nodes:jidmap'>
<item id='123456#coven@mix.shakespeare.example'>
<participant xmlns='urn:xmpp:mix:0'>
<participant xmlns='urn:xmpp:mix:1'>
<jid>hecate@mix.shakespeare.example<jid/>
</participant>
</item>
@ -1661,7 +1662,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</message>
]]></example>
<p>
The MIX channel then adds information to the message using a &lt;mix&gt; element qualified by the 'urn:xmpp:mix:0' namespace. This element contains two child elements:
The MIX channel then adds information to the message using a &lt;mix&gt; element qualified by the 'urn:xmpp:mix:1' namespace. This element contains two child elements:
</p>
<ol>
<li>A &lt;nick&gt; element that contains the Nick of the message sender, taken from the Participants Node.</li>
@ -1676,7 +1677,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
<mix xmlns='urn:xmpp:mix:0'>
<mix xmlns='urn:xmpp:mix:1'>
<nick>thirdwitch</nick>
<jid>123456#coven@mix.shakespeare.example</jid>
</mix>
@ -1689,7 +1690,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
<mix xmlns='urn:xmpp:mix:0'>
<mix xmlns='urn:xmpp:mix:1'>
<nick>thirdwitch</nick>
<jid>123456#coven@mix.shakespeare.example</jid>
</mix>
@ -1704,7 +1705,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
<mix xmlns='urn:xmpp:mix:0'>
<mix xmlns='urn:xmpp:mix:1'>
<nick>thirdwitch</nick>
<jid>123456#coven@mix.shakespeare.example</jid>
<submission-id>92vax143g</submission-id>
@ -1715,13 +1716,13 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section3 topic="Retracting a Message" anchor="usecase-retract">
<p>
A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. If this is done the original message MAY be replaced by a tombstone. The protocol to request retraction does this by adding to the message a &lt;retract&gt; element qualified by the 'urn:xmpp:mix:0' namespace as shown in the following example.
A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. If this is done the original message MAY be replaced by a tombstone. The protocol to request retraction does this by adding to the message a &lt;retract&gt; element qualified by the 'urn:xmpp:mix:1' namespace as shown in the following example.
</p>
<example caption="User Retracts a Message"><![CDATA[
<message from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'
id='92vax143g'>
<retract id='28482-98726-73623' xmlns='urn:xmpp:mix:0'/>
<retract id='28482-98726-73623' xmlns='urn:xmpp:mix:1'/>
</message>
]]></example>
<p>
@ -1735,7 +1736,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</p>
<p>
The second approach is to leave a tombstone, which if taken MUST be done in the following manner. This is appropriate where it is desired to leave a record of the message that was redacted.
With this approach, the original message &lt;body&gt; is removed and replaced with a tombstone using the &lt;retracted&gt; element qualified by the 'urn:xmpp:mix:0' namespace that shows the JID of user performing the retraction and the time of the retraction.
With this approach, the original message &lt;body&gt; is removed and replaced with a tombstone using the &lt;retracted&gt; element qualified by the 'urn:xmpp:mix:1' namespace that shows the JID of user performing the retraction and the time of the retraction.
</p>
<example caption="Retracted message tombstone in a MAM result"><![CDATA[
<message id='aeb213' to='juliet@capulet.lit/UUID-e3r/9264'>
@ -1744,7 +1745,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<delay xmlns='urn:xmpp:delay' stamp='2010-07-10T23:08:25Z'/>
<message xmlns='jabber:client' from="hag66@shakespeare.example"
to="macbeth@shakespeare.lit">
<retracted xmlns='urn:xmpp:mix:0' by='hag66@shakespeare.example'
<retracted xmlns='urn:xmpp:mix:1' by='hag66@shakespeare.example'
time='2010-07-10T23:08:25Z'/>
</message>
</forwarded>
@ -1772,14 +1773,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<li>The invitee MAY send a response to the inviter, indicating if the invitation was accepted or declined.</li>
</ol>
<p>
The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time. The invitation request is encoded as an &lt;invite/&gt; child element of an &lt;iq/&gt; element. The &lt;invite/&gt; element is qualified by the 'urn:xmpp:mix:0' namespace. &lt;invite/&gt; contains an &lt;invitation/&gt; child element, which contain &lt;inviter/&gt;, &lt;invitee/&gt;, &lt;channel/&gt; and &lt;token/&gt; child elements.
The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time. The invitation request is encoded as an &lt;invite/&gt; child element of an &lt;iq/&gt; element. The &lt;invite/&gt; element is qualified by the 'urn:xmpp:mix:1' namespace. &lt;invite/&gt; contains an &lt;invitation/&gt; child element, which contain &lt;inviter/&gt;, &lt;invitee/&gt;, &lt;channel/&gt; and &lt;token/&gt; child elements.
</p>
<example caption='Inviter Requests and Receives Invitation'><![CDATA[
<iq from='hag66@shakespeare.lit/UUID-h5z/0253'
id='kl2fax27'
to='coven@mix.shakespeare.lit'
type='get'>
<invite xmlns='urn:xmpp:mix:0'>
<invite xmlns='urn:xmpp:mix:1'>
<invitee>cat@shakespeare.lit</invitee>
</invite>
</iq>
@ -1789,7 +1790,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='kl2fax27'
to='hag66@shakespeare.lit/UUID-h5z/0253'
type='result'>
<invite xmlns='urn:xmpp:mix:0'>
<invite xmlns='urn:xmpp:mix:1'>
<invitation>
<inviter>hag66@shakespeare.lit</inviter>
<invitee>cat@shakespeare.lit</invitee>
@ -1807,7 +1808,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='f5pp2toz'
to='cat@shakespeare.lit'>
<body>Would you like to join the coven?<body>
<invitation xmlns='urn:xmpp:mix:0'>
<invitation xmlns='urn:xmpp:mix:1'>
<inviter>hag66@shakespeare.lit</inviter>
<invitee>cat@shakespeare.lit</invitee>
<channel>coven@mix.shakespeare.lit</channel>
@ -1821,7 +1822,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='cat@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:0'>
<join xmlns='urn:xmpp:mix:1'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<invitation>
<inviter>hag66@shakespeare.lit</inviter>
@ -1833,7 +1834,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</iq>
]]></example>
<p>The invitee MAY send an acknowledgement back to the inviter, noting the status of the invitation.
This is encoded as an &lt;invitation-ack/&gt; child element of &lt;message/&gt; element. The &lt;invitation-ack/&gt; element is qualified by the 'urn:xmpp:mix:0' namespace. The &lt;invitation-ack/&gt; has an &lt;invitation/&gt; child element that encodes the invitation being acknowledged and a &lt;value/&gt; child element to encode the acknowledgement value.
This is encoded as an &lt;invitation-ack/&gt; child element of &lt;message/&gt; element. The &lt;invitation-ack/&gt; element is qualified by the 'urn:xmpp:mix:1' namespace. The &lt;invitation-ack/&gt; has an &lt;invitation/&gt; child element that encodes the invitation being acknowledged and a &lt;value/&gt; child element to encode the acknowledgement value.
&lt;value/&gt; has the following values:</p>
<ul>
<li>'Joined': The invitee has joined the channel.</li>
@ -1845,7 +1846,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='b6p9llze'
to='hag66@shakespeare.lit/UUID-h5z/0253'>
<body>No Thanks - too busy chasing mice....<body>
<invitation-ack xmlns='urn:xmpp:mix:0'>
<invitation-ack xmlns='urn:xmpp:mix:1'>
<value>Declined</value>
<invitation>
<inviter>hag66@shakespeare.lit</inviter>
@ -1952,14 +1953,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa
It is important that messages are all transferred from the MIX channel to the server associated with the each channel participant. Transfer between servers will typically happen quickly and &xep0198; will deal with short connection failures between servers. Longer connection failures could lead to message loss. This would lead to online users (who remain connected to their servers) missing messages, and to messages being missed out of the user archive. This section describes how MIX addresses this.
</p>
<p>
When there is a long term connection failure, the MIX channel will receive an error from the XMPP server indicating that a message failed to transfer to a recipient. When this happens, the MIX channel MUST take responsibility to ensure that the message is retransmitted and delivered. When the MIX channel detects a failure it will make use of an IQ Marker message to determine when the connection to the peer server is working again. Once the channel has received a response to the marker IQ it will retransmit the pending messages. The marker is encoded as a &lt;marker/&gt; child element of an &lt;iq/&gt; element. The &lt;marker/&gt; element is qualified by the 'urn:xmpp:mix:0' namespace.
When there is a long term connection failure, the MIX channel will receive an error from the XMPP server indicating that a message failed to transfer to a recipient. When this happens, the MIX channel MUST take responsibility to ensure that the message is retransmitted and delivered. When the MIX channel detects a failure it will make use of an IQ Marker message to determine when the connection to the peer server is working again. Once the channel has received a response to the marker IQ it will retransmit the pending messages. The marker is encoded as a &lt;marker/&gt; child element of an &lt;iq/&gt; element. The &lt;marker/&gt; element is qualified by the 'urn:xmpp:mix:1' namespace.
</p>
<example caption="Channel Sends Marker Message" ><![CDATA[
<iq from='coven@mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example'
type='get'>
<marker xmlns='urn:xmpp:mix:0'/>
<marker xmlns='urn:xmpp:mix:1'/>
</iq>
@ -1967,7 +1968,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='lx09df27'
to='coven@mix.shakespeare.example'
type='result'>
<marker xmlns='urn:xmpp:mix:0'/>
<marker xmlns='urn:xmpp:mix:1'/>
</iq>
]]></example>
</section2>
@ -2003,7 +2004,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section3 topic='Checking For Permission To Create a Channel' anchor='usecase-admin-check-create'>
<p>
MIX does not standardize an access control model for creating and deleting MIX channels. The choice is left to the MIX implementer, and could be a very simple or complex approach. A client can determine if it has permission to create a channel on a MIX service, which MAY be used to control options presented to the user. This is achieved by a disco command on the MIX service. If the 'urn:xmpp:mix:0#create-channel' feature is returned, the user is able to create a channel.
MIX does not standardize an access control model for creating and deleting MIX channels. The choice is left to the MIX implementer, and could be a very simple or complex approach. A client can determine if it has permission to create a channel on a MIX service, which MAY be used to control options presented to the user. This is achieved by a disco command on the MIX service. If the 'urn:xmpp:mix:1#create-channel' feature is returned, the user is able to create a channel.
</p>
<example caption="Client determines Capability to Create a Channel" ><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
@ -2022,29 +2023,29 @@ This approach enables flexible support of multiple clients for a MIX channel pa
category='conference'
name='Shakespearean Chat Service'
type='text'/>
<feature var='urn:xmpp:mix:0'/>
<feature var='urn:xmpp:mix:0#create-channel'>
<feature var='urn:xmpp:mix:1'/>
<feature var='urn:xmpp:mix:1#create-channel'>
</query>
</iq>
]]></example>
</section3>
<section3 topic='Creating a Channel' anchor='usecase-admin-create'>
<p>
A client creates a channel by sending a simple request to the MIX service. A channel MAY be created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). The create is encoded as a &lt;create/&gt; child element of &lt;iq/&gt; element. The &lt;create/&gt; is qualified by the 'urn:xmpp:mix:0' namespace. The &lt;create/&gt; element MUST have a 'channel' attribute to specify the channel name.
A client creates a channel by sending a simple request to the MIX service. A channel MAY be created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). The create is encoded as a &lt;create/&gt; child element of &lt;iq/&gt; element. The &lt;create/&gt; is qualified by the 'urn:xmpp:mix:1' namespace. The &lt;create/&gt; element MUST have a 'channel' attribute to specify the channel name.
</p>
<example caption="Creating a Channel with Default Parameters" ><![CDATA[
<iq from='hag66@shakespeare.example/UUID-a1j/7533'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
<create channel='coven' xmlns='urn:xmpp:mix:0'/>
<create channel='coven' xmlns='urn:xmpp:mix:1'/>
</iq>
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/UUID-a1j/7533'
type='result'>
<create channel='coven' xmlns='urn:xmpp:mix:0'/>
<create channel='coven' xmlns='urn:xmpp:mix:1'/>
</iq>
]]></example>
<p>
@ -2055,10 +2056,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
<create channel='coven' xmlns='urn:xmpp:mix:0'>
<create channel='coven' xmlns='urn:xmpp:mix:1'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
<value>urn:xmpp:mix:1</value>
</field>
<field var='Owner'>
<value>hecate@shakespeare.lit</value>
@ -2081,7 +2082,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='lx09df27'
to='hag66@shakespeare.example/UUID-a1j/7533'
type='result'>
<create channel='coven' xmlns='urn:xmpp:mix:0'/>
<create channel='coven' xmlns='urn:xmpp:mix:1'/>
</iq>
]]></example>
@ -2097,14 +2098,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
<create xmlns='urn:xmpp:mix:0'/>
<create xmlns='urn:xmpp:mix:1'/>
</iq>
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/UUID-a1j/7533'
type='result'>
<create channel='A1B2C345' xmlns='urn:xmpp:mix:0'/>
<create channel='A1B2C345' xmlns='urn:xmpp:mix:1'/>
</iq>
]]></example>
</section3>
@ -2140,7 +2141,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
MIX channels are always explicitly destroyed by an owner of the channel or by a server operator. There is no concept of temporary channel, equivalent to &xep0045; temporary room which is automatically destroyed by the server when the users leave. However, channels MAY be configured with an explicit lifetime, after which the channel MUST be removed by the MIX service. Where a channel is created for ad hoc use, it MAY be desirable to keep the channel for history reference or for re-use by the same set of users. Note that the owner of the channel does not need to have presence registered in the channel in order to destroy it.
</p>
<p>
The destroy operation is encoded as a &lt;destroy/&gt; child element of an &lt;iq/&gt; element. The &lt;destroy/&gt; element is qualified by the 'urn:xmpp:mix:0' namespace. The &lt;destroy/&gt; element MUST have a 'channel' attribute to specify the channel to be destroyed.
The destroy operation is encoded as a &lt;destroy/&gt; child element of an &lt;iq/&gt; element. The &lt;destroy/&gt; element is qualified by the 'urn:xmpp:mix:1' namespace. The &lt;destroy/&gt; element MUST have a 'channel' attribute to specify the channel to be destroyed.
A client destroys a channel using a simple set operation, as shown in the following example.
</p>
<example caption="Client Destroys a Channel" ><![CDATA[
@ -2148,7 +2149,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
<destroy channel='coven' xmlns='urn:xmpp:mix:0'/>
<destroy channel='coven' xmlns='urn:xmpp:mix:1'/>
</iq>
<iq from='mix.shakespeare.example'
@ -2184,7 +2185,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<items node='urn:xmpp:mix:nodes:info'>
<x xmlns='jabber:x:data' type='form'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
<value>urn:xmpp:mix:1</value>
</field>
<title>Information Node Modification</title>
<field type='text-multi'
@ -2213,7 +2214,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<publish node='urn:xmpp:mix:nodes:info'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
<value>urn:xmpp:mix:1</value>
</field>
<field var='Name'>
<value>Witches Coven</value>
@ -2236,7 +2237,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:mix:nodes:info'>
<item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:0'/>
<item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:1'/>
</publish>
</pubsub>
</iq>
@ -2260,10 +2261,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
to='hag66@shakespeare.example/UUID-a1j/7533'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items xmlns='urn:xmpp:mix:0' node='urn:xmpp:mix:nodes:config'>
<items xmlns='urn:xmpp:mix:1' node='urn:xmpp:mix:nodes:config'>
<x xmlns='jabber:x:data' type='form'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
<value>urn:xmpp:mix:1</value>
</field>
<title>Configuration Node Modification</title>
<field type=jid-multi'
@ -2284,7 +2285,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<publish node='urn:xmpp:mix:nodes:config'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
<value>urn:xmpp:mix:1</value>
</field>
<field var='Owner'>
<value>hecate@shakespeare.lit</value>
@ -2310,7 +2311,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:mix:nodes:config'>
<item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:0'/>
<item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:1'/>
</publish>
</pubsub>
</iq>
@ -2423,7 +2424,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
<mix xmlns='urn:xmpp:mix:0'>
<mix xmlns='urn:xmpp:mix:1'>
<nick>thirdwitch</nick>
<jid>123456#coven@mix.shakespeare.example</jid>
</mix>
@ -2442,7 +2443,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
<mix xmlns='urn:xmpp:mix:0'>
<mix xmlns='urn:xmpp:mix:1'>
<nick>thirdwitch</nick>
<jid>123456#coven@mix.shakespeare.example</jid>
</mix>
@ -2453,7 +2454,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
<mix xmlns='urn:xmpp:mix:0'>
<mix xmlns='urn:xmpp:mix:1'>
<nick>thirdwitch</nick>
<jid>123456#coven@mix.shakespeare.example</jid>
</mix>
@ -2488,7 +2489,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example/UUID-a1j/7533'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:0'
<join xmlns='urn:xmpp:mix:1'
channel='coven@mix.shakespeare.example'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
@ -2505,7 +2506,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:0'>
<join xmlns='urn:xmpp:mix:1'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
<subscribe node='urn:xmpp:mix:nodes:participants'/>
@ -2587,11 +2588,11 @@ This approach enables flexible support of multiple clients for a MIX channel pa
category='conference'
name='Shakespearean Chat Service'
type='text'/>
<feature var='urn:xmpp:mix:0'/>
<feature var='urn:xmpp:mix:1'/>
<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>
<value>urn:xmpp:mix:1#serviceinfo</value>
</field>
</x>
</query>
@ -2610,10 +2611,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
category='conference'
name='Shakespearean Chat Service'
type='text'/>
<feature var='urn:xmpp:mix:0'/>
<feature var='urn:xmpp:mix:1'/>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0#serviceinfo</value>
<value>urn:xmpp:mix:1#serviceinfo</value>
</field>
<field var='muc-mirror'
type='jid-single'
@ -2624,7 +2625,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</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>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:1#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 sharing MIX service location" ><![CDATA[
<iq from='chat.shakespeare.example'
@ -2639,7 +2640,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<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>
<value>urn:xmpp:mix:1#serviceinfo</value>
</field>
<field var='mix-mirror'
type='jid-single'
@ -2650,7 +2651,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</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>
<p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:1#serviceinfo'. The field with var='mix-mirror' is the value of which is the mirrored MIX domain's JID. </p>
<section2 topic="Choosing Which Invite to Send" anchor="mix-muc-invite-choice">
<p>
Where a client supports MUC and MIX and has determined that for a channel that the server also supports a MUC room, the client has a choice as to which type of invite to send. This SHOULD be done by determining if the client support MIX using the mechanism specified in