moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-28 04:02:20 -05:00
Code Issues Releases Wiki Activity

Make most operations direct, with join/leave indirect

Browse Source
This commit is contained in:
Steve Kille 2017-02-08 10:39:55 +00:00 committed by Sam Whited
parent d95e6a87dc
commit dfdbca1f81
1 changed files with 163 additions and 92 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

251
xep-0369.xml
View File

@ -42,8 +42,11 @@
<initials>sek</initials>
<remark><p>
Update after Brussels Summit;
Remove Explicit Client Activation;
Limit Indirect to Join/Leave;
Clarify Server use of Disco of Client;
</p></remark>
</revision>
<revision>
<version>0.7.1</version>
<date>2017-01-30</date>
@ -283,15 +286,16 @@ This approach enables flexible support of multiple clients for a MIX channel pa
There are a number of MIX requirements on behaviour of the MIX Participant's server, which are summarized here:
</p>
<ol>
<li>Each MIX client will activate MIX capability with the local server when it comes online. A key benefit of this approach is that MIX messages will only be sent to clients that support MIX. This enables a user to use of clients that do not use MIX in conjunction with clients that use MIX.</li>
<li>MIX Service and Channel subscription and management is handled through the participant's server so that the participant's server can track all subscription changes and share subscription information between MIX clients. To achieve this, a MIX client of a MIX channel participant sends these MIX management queries to the participant's server and received responses back from the participant’s server. The MIX participant’s server will communicate these requests to a MIX channel with messages from the user's bare JID. Because the participant's server is aware of subscription information, it can provide integrated support to a set of MIX clients.</li>
<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>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 handles channel registration and de-registration in the user's roster.</li>
<li>Enabling different clients to access different sets of channels (e.g., a mobile client only accesses a subset of the channels in which a user is interested). MIX Client Activation allows the participant's server to support this.</li>
<li>The MIX client will generally send management and other messages directly to the MIX channel and the 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>
</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.
@ -652,7 +656,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. This query MUST be made indirectly by the user's server.</p>
<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. This query MUST be made directly by a client.</p>
<example caption='User&apos;s Server Queries for Channels on MIX Service'><![CDATA[
<iq from='hag66@shakespeare.lit'
id='kl2fax27'
@ -675,7 +679,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
]]></example>
</section2>
<section2 topic='Discovering Channel Information' anchor='disco-channel-info'>
<p>In order to find out more information about a given channel, a user can send a disco#info query to the channel. This query MUST be made indirectly by the user's server and not the end client.</p>
<p>In order to find out more information about a given channel, a user can send a disco#info query to the channel. This query MUST be made directly by a client.</p>
<example caption='Entity Queries for Information about a Specific Channel'><![CDATA[
<iq from='hag66@shakespeare.lit'
id='ik3vs715'
@ -684,7 +688,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>Note that this query comes from the bare JID to the MIX channel, as it will always be sent to the MIX service by the user's server. 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 rad results returned MUST include 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> 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 rad results returned MUST include 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'
@ -702,7 +706,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
]]></example>
</section2>
<section2 topic='Discovering Nodes at a Channel' anchor='disco-channel-nodes'>
<p>Use disco#items to find the nodes associated with a channel. The MIX service MUST only return nodes that exist and that the user making the query has rights to subscribe to. This query MUST be made by the user's server and not the end client.</p>
<p>Use disco#items to find the nodes associated with a channel. The MIX service MUST only return nodes that exist and that the user making the query has rights to subscribe to. This query MUST be made directly by a client.</p>
<example caption='Entity Queries for Nodes at a Channel'><![CDATA[
<iq from='hag66@shakespeare.lit'
id='kl2fax27'
@ -732,7 +736,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
]]></example>
</section2>
<section2 topic="Determining Information about a Channel" anchor="find-channel-info">
<p>The Information Node contains various information about the channel that can be useful to the user. This query MUST be made indirectly by the user's server using the user's bare JID.</p>
<p>The Information Node contains various information about the channel that can be useful to the user. This query MUST be made directly by a client.</p>
<example caption='User&apos;s Server Requests Channel Information'><![CDATA[
<iq from='hag66@shakespeare.lit'
id='kl2fax27'
@ -768,7 +772,7 @@ 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. 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. An operation is provided to list channel participants. For JID Hidden channels, only the nicks are returned. For JID Visible channels, nicks and real JIDs are returned. This query MUST be made indirectly by the user's server using the user's bare JID.</p>
Online clients in the channel are determined from the presence node. 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. An operation is provided to list channel participants. 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[
<iq from='hag66@shakespeare.lit'
id='kl2fax27'
@ -821,7 +825,32 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</p>
<p>The default MIX model is that only channel participants are allowed to subscribe to nodes. A MIX channel MAY allow non-participant subscription. This will be handled by clients directly subscribing to the desired PubSub nodes.</p>
<example caption="User Joins a Channel"><![CDATA[
<p>
The user's server needs to make roster changes as part of the join functionality. Because of this, the join and leave operations need to operate indirectly.
For this reason the initial join request is sent to the local server with the MIX channel specified as an attribute to the join.
</p>
<example caption="Client sends request to Local Server to Join a Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/pda'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:0'
channel='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'/>
<subscribe node='urn:xmpp:mix:nodes:config'/>
</join>
</iq>
]]></example>
<p>
The user’s server will then pass the request to the MIX channel, with the request coming from the user's bare JID.
</p>
<example caption="User's Server sends Join request to MIX Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
@ -830,13 +859,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
<subscribe node='urn:xmpp:mix:nodes:participants'/>
<subscribe node='urn:xmpp:mix:nodes:subject'/>
<subscribe node='urn:xmpp:mix:nodes:config'/>
</join>
</iq>
]]></example>
<p>The channel responds with an IQ-result. This stanza includes the nodes to which the user has been successfully subscribed, as well as the bare JID that will be used for the user in this channel and added to the participant list. The JID returned in the join is the user's bare proxy JID. The following example shows the result of the above request when the request is completed in full. </p>
<example caption="Channel Processes Join Request in Full"><![CDATA[
<p>The channel responds to the user's sever with an IQ-result addressed to the user's bare JID. This stanza includes the nodes to which the user has been successfully subscribed, as well as the bare JID that will be used for the user in this channel and added to the participant list. The JID returned in the join is the user's bare proxy JID. The following example shows the result of the above request when the request is completed in full. </p>
<example caption="Channel responds to User's Server"><![CDATA[
<iq type='result'
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example'
@ -845,14 +873,31 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
<subscribe node='urn:xmpp:mix:nodes:participants'/>
<subscribe node='urn:xmpp:mix:nodes:subject'/>
<subscribe node='urn:xmpp:mix:nodes:config'/>
</join>
</iq>
]]></example>
<p>
The user's server will then send the join response back to the client that made the join request. The only change is that the incoming message is addressed to bare JID and the outgoing message is addressed to client's full JID. Prior to sending this response, the user's server will make roster modifications as set out in the next section.
</p>
<example caption="User's Server sends response to Client"><![CDATA[
<iq type='result'
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example/pda'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:0' jid='coven+123456@mix.shakespeare.example'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
<subscribe node='urn:xmpp:mix:nodes:participants'/>
<subscribe node='urn:xmpp:mix:nodes:config'/>
</join>
</iq>
]]></example>
<p>
If a user cannot be subscribed to one or more of the requested nodes (e.g., because the node does not exist), but can be subscribed to some the response simply lists the nodes successfully subscribed. If none of the nodes requested are successfully subscribed to, an error response is sent indicating the reason that the first node requested was not subscribed to. This response will also include other nodes requested where subscription failed for the same reason. The following response example shows a 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 subject).</p>
the participant is not be subscribed to all nodes associated with the channel (in this case only messages, participants, and subject). The following example is 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'
@ -865,7 +910,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
</join>
</iq>
]]></example>
<p>The channel also adds the user to the participants node and sends a notification to subscribers to the participants node.</p>
<p>The channel also adds the user to the participants node and sends a notification to subscribers to the participants node. The following example shows such a notification.</p>
<example caption="Channel Adds User to Participants Node"><![CDATA[
<message from='coven@mix.shakespeare.example'
to='hecate@shakespeare.example'
@ -879,13 +924,13 @@ the participant is not be subscribed to all nodes associated with the channel (i
</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 does 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 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>
A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request, as shown in the following example.
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>
<example caption="User Modifies Subscription Request"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
from='hag66@shakespeare.example/pda'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<update-subscription xmlns='urn:xmpp:mix:0'>
@ -894,8 +939,8 @@ the participant is not be subscribed to all nodes associated with the channel (i
</iq>
<iq type='result'
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example/pda'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<update-subscription xmlns='urn:xmpp:mix:0' jid='hag66@shakespeare.example'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
@ -905,7 +950,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
</section3>
<section3 topic="Roster Management" anchor="usecase-roster-management">
<p>
After the user has jointed the channel, the user's server MAY add the MIX channel to the user's roster using standard XMPP to update the roster. This is done to share the user's presence status with the channel and so the MIX channel will get presence information from the user. This roster entry will lead to the user's server correctly sending user's presence from all clients to the MIX channel. The roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information is sent about the MIX channel. The user's server MUST remove this roster entry after the user leaves the channel.
As part of the channel joining process, the user's server MAY add the MIX channel to the user's roster using standard XMPP to update the roster. This is done to share the user's presence status with the channel and so the MIX channel will get presence information from the user. This roster entry will lead to the user's server correctly sending user's presence from all clients to the MIX channel. The roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information is sent about the MIX channel. The user's server MUST remove this roster entry after the user leaves the channel.
</p>
<p>
If the user does not wish to publish presence information to the channel, the user will not add the roster entry. A channel MAY require presence to be provided by all channel participants, which is controlled by the 'Participants Must Provide Presence' option. The channel MAY check that channel participants have done this and MAY remove participants that do not do this.
@ -942,7 +987,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<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.</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.</p>
<example caption="User Joins a Channel and Specifies a preference"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
@ -962,7 +1007,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
</join>
</iq>
]]></example>
<p>The following example shows a successful join, which also reports all the user preferences. </p>
<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>
<example caption="Channel Successfully Processes Join and returns the preferences set"><![CDATA[
<iq type='result'
from='coven@mix.shakespeare.example'
@ -988,10 +1033,10 @@ the participant is not be subscribed to all nodes associated with the channel (i
</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.</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. This query is direct from the client to the MIX channel.</p>
<example caption="User Requests and Recieves Preferences Template Form"><![CDATA[
<iq type='get'
from='hag66@shakespeare.example'
from='hag66@shakespeare.example/pda'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<user-preference xmlns='urn:xmpp:mix:0'/>
@ -999,7 +1044,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<iq type='result'
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example'
to='hag66@shakespeare.example/pda'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<user-preference xmlns='urn:xmpp:mix:0'>
<x xmlns='jabber:x:data' type='form'>
@ -1028,7 +1073,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
</p>
<example caption="User Updates Preferences"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
from='hag66@shakespeare.example/pda'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<user-preference xmlns='urn:xmpp:mix:0'/>
@ -1050,7 +1095,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<iq type='result'
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example'
to='hag66@shakespeare.example/pda'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<user-preference xmlns='urn:xmpp:mix:0'>
<x xmlns='jabber:x:data' type='result'>
@ -1073,7 +1118,23 @@ the participant is not be subscribed to all nodes associated with the channel (i
</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 client will remove the channel from the user's roster.</p>
<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>
<example caption="Client Requests to Leave a Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/pda'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<leave xmlns='urn:xmpp:mix:0'
channel=`coven@mix.shakespeare.example`/>
</iq>
]]></example>
<p>
The user's server will then generate a matching request to the MIX channel.
</p>
<example caption="User Leaves a Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
@ -1081,6 +1142,32 @@ the participant is not be subscribed to all nodes associated with the channel (i
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<leave xmlns='urn:xmpp:mix:0'/>
</iq>
]]></example>
<p>
The MIX channel will then remove the user from the channel, as described below. A response is sent to the user's server.
</p>
<example caption="Channel Confirms Leave to User's Server"><![CDATA[
<iq type='result'
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<leave xmlns='urn:xmpp:mix:0'/>
</iq>
]]></example>
<p>
After receiving the confirmation that the user has left the MIX channel, the user's server will remove the MIX channel entry from the user's roster. The user's server will then notify the client that requested to leave.
</p>
<example caption="User's Server Confirms Leave to Client"><![CDATA[
<iq type='result'
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example/pda'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<leave xmlns='urn:xmpp:mix:0'/>
</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.
@ -1125,7 +1212,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
</p>
<example caption="User sets Nick on Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
from='hag66@shakespeare.example/pda'
to='coven@mix.shakespeare.example'
id='7nve413p'>
<query xmlns='urn:xmpp:mix:0'>
@ -1140,8 +1227,8 @@ the participant is not be subscribed to all nodes associated with the channel (i
<example caption="Channel informs user of Nick"><![CDATA[
<iq type='result'
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
from='coven@mix.shakespeare.example'
to'hag66@shakespeare.example/pda'
id='7nve413p'>
<query xmlns='urn:xmpp:mix:0'>
<nick>thirdwitch</nick>
@ -1181,7 +1268,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
a &lt;register/&gt; command to the service. </p>
<example caption="User Registers with Service"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
from='hag66@shakespeare.example/pda'
to='mix.shakespeare.example'
id='7nve413p'>
<register xmlns='urn:xmpp:mix:0'>
@ -1193,7 +1280,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<example caption="Service Returns User of Nick"><![CDATA[
<iq type='result'
to='mix.shakespeare.example'
from='hag66@shakespeare.example'
from='hag66@shakespeare.example/pda'
id='7nve413p'>
<register xmlns='urn:xmpp:mix:0'>
<nick>thirdwitch</nick>
@ -1204,7 +1291,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<example caption="Nick is Taken">
<![CDATA[<iq type='error'
to='mix.shakespeare.example'
from='hag66@shakespeare.example'
from='hag66@shakespeare.example/pda'
id='7nve413p'>
<error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@ -1700,10 +1787,10 @@ the participant is not be subscribed to all nodes associated with the channel (i
</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). Creating and destroying a channel MUST be done indirectly by the user's server using the user's bare JID.
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). Creating and destroying a channel is done direct from a client.
</p>
<example caption="Creating a Channel with Default Parameters" ><![CDATA[
<iq from='hag66@shakespeare.example'
<iq from='hag66@shakespeare.example/pda'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
@ -1712,7 +1799,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example'
to='hag66@shakespeare.example/pda'
type='result'>
<create channel='coven' xmlns='urn:xmpp:mix:0'/>
</iq>
@ -1721,7 +1808,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
The client MAY also include parameters in &xep0004; format as part of channel creation. If the client wishes to inspect configuration, channel administration procedures SHOULD be used.
</p>
<example caption="Creating a Channel with Client Specified Parameters" ><![CDATA[
<iq from='hag66@shakespeare.example'
<iq from='hag66@shakespeare.example/pda'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
@ -1751,7 +1838,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example'
to='hag66@shakespeare.example/pda'
type='result'>
<create channel='coven' xmlns='urn:xmpp:mix:0'/>
</iq>
@ -1765,7 +1852,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
Rooms MAY be created for ad hoc use between a set of users. Channels of this nature will have channel name created by the server and will not be addressable or discoverable. Here a channel is created without specifying the channel name. Parameters for the channel MAY also be specified.
</p>
<example caption="Creating a Channel for Ad Hoc Use" ><![CDATA[
<iq from='hag66@shakespeare.example'
<iq from='hag66@shakespeare.example/pda'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
@ -1774,7 +1861,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example'
to='hag66@shakespeare.example/pda'
type='result'>
<create channel='A1B2C345' xmlns='urn:xmpp:mix:0'/>
</iq>
@ -1815,7 +1902,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
A client destroys a channel using a simple set operation, as shown in the following example.
</p>
<example caption="Client Destroys a Channel" ><![CDATA[
<iq from='hag66@shakespeare.example'
<iq from='hag66@shakespeare.example/pda'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
@ -1824,7 +1911,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example'
to='hag66@shakespeare.example/pda'
type='result'>
</iq>
]]></example>
@ -1838,7 +1925,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<section3 topic='Modifying Channel Information' anchor='usecase-admin-information'>
<p>Authorized users, typically owners and sometimes administrators, MAY modify the channel information. The client MAY issue a pubsub get command to obtain a form that will facilitate update of the information node. The values in the form show current values, which be defaults or MAY have been explicitly set. In the following example, the channel name was previously set, but other values were not. </p>
<example caption="Getting Information Form" ><![CDATA[
<iq from='hag66@shakespeare.example'
<iq from='hag66@shakespeare.example/pda'
id='lx09df27'
to='mix.shakespeare.example'
type='get'>
@ -1849,7 +1936,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example'
to='hag66@shakespeare.example/pda'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/'>
<items node='urn:xmpp:mix:nodes:info'>
@ -1876,7 +1963,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
]]></example>
<p> Updating the information node is done using a pubsub set command. The MIX channel MUST update the fields with values provided, leaving other fields unchanged. The result returns the id used in the information node item, which is the date/time of the modification. </p>
<example caption="Modifying Channel Information" ><![CDATA[
<iq from='hag66@shakespeare.example'
<iq from='hag66@shakespeare.example/pda'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
@ -1903,7 +1990,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example'
to='hag66@shakespeare.example/pda'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:mix:nodes:info'>
@ -1914,10 +2001,10 @@ the participant is not be subscribed to all nodes associated with the channel (i
]]></example>
</section3>
<section3 topic='Modifying Channel Configuration' anchor='usecase-admin-information'>
<p>Channel owners are allowed to modify the channel configuration. The client MAY issue a pubsub get command to obtain a form that will facilitate update of the configuration node. Other clients MAY be authorized to use this command to see the channel configuration, but only owners MAY update the configuration. The values in the form show current values, which MAY be defaults or MAY have been explicitly set. The following example shows a short form returned to illustrate the syntax. A typical configuration form will be much larger with many fields. Modifying channel configuration MUST be done indirectly by the user's server.
<p>Channel owners are allowed to modify the channel configuration. The client MAY issue a pubsub get command to obtain a form that will facilitate update of the configuration node. Other clients MAY be authorized to use this command to see the channel configuration, but only owners MAY update the configuration. The values in the form show current values, which MAY be defaults or MAY have been explicitly set. The following example shows a short form returned to illustrate the syntax. A typical configuration form will be much larger with many fields. Modifying channel configuration is done directly by a client.
</p>
<example caption="Getting Configuration Form" ><![CDATA[
<iq from='hag66@shakespeare.example'
<iq from='hag66@shakespeare.example/pda'
id='lx09df27'
to='mix.shakespeare.example'
type='get'>
@ -1928,7 +2015,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example'
to='hag66@shakespeare.example/pda'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items xmlns='urn:xmpp:mix:0' node='urn:xmpp:mix:nodes:config'>
@ -1947,7 +2034,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
]]></example>
<p> Updating the information node is done using a pubsub set command. The MIX channel MUST update the fields with values provided, leaving other fields unchanged. The result returns the id used in the configuration node item, which is the date/time of the modification. </p>
<example caption="Modifying Channel Configuration" ><![CDATA[
<iq from='hag66@shakespeare.example'
<iq from='hag66@shakespeare.example/pda'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
@ -1979,7 +2066,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example'
to='hag66@shakespeare.example/pda'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:mix:nodes:config'>
@ -1992,10 +2079,10 @@ the participant is not be subscribed to all nodes associated with the channel (i
<section3 topic='Controlling Channel Partipcipants' anchor='usecase-admin-participants'>
<p>
Owners and Administrators are allowed to control which users can participate in a channel by use of Allowed and Banned lists using PubSub. These operations follow &xep0060; which sets out detailed protocol use and error handling.
Allowed and Banned lists MAY be read by PubSub get of the Banned and Allowed Nodes. This operation MAY be used by users as controlled by 'Allowed Node Subscription' and 'Banned Node Subscription' configuration node options (default Administrators). This MUST be done indirectly by the user's server.
Allowed and Banned lists MAY be read by PubSub get of the Banned and Allowed Nodes. This operation MAY be used by users as controlled by 'Allowed Node Subscription' and 'Banned Node Subscription' configuration node options (default Administrators).
</p>
<example caption="Client Reads Allowed Node" ><![CDATA[
<iq from='hag66@shakespeare.example'
<iq from='hag66@shakespeare.example/pda'
id='lx09df27'
to='mix.shakespeare.example'
type='get'>
@ -2006,7 +2093,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example'
to='hag66@shakespeare.example/pda'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:mix:nodes:allowed'>
@ -2020,7 +2107,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
JIDs can be added to the Allowed and Banned nodes by a pubsub set command. This is used to add one item to a node.
</p>
<example caption="Client Adds a JID to the Allowed Node" ><![CDATA[
<iq from='hag66@shakespeare.example'
<iq from='hag66@shakespeare.example/pda'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
@ -2033,7 +2120,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example'
to='hag66@shakespeare.example/pda'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'/>
</iq>
@ -2042,7 +2129,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
JIDs can be removed from the Allowed and Banned nodes by pubsub retract command.
</p>
<example caption="Client Removes a JID to the Banned Node" ><![CDATA[
<iq from='hag66@shakespeare.example'
<iq from='hag66@shakespeare.example/pda'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
@ -2055,7 +2142,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example'
to='hag66@shakespeare.example/pda'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'/>
</iq>
@ -2175,43 +2262,27 @@ the participant is not be subscribed to all nodes associated with the channel (i
]]></example>
</section2>
<section2 topic="Messages To MIX Channels" anchor="mix-to">
<section2 topic="Messages To MIX Channels" anchor="user-server-to">
<p>
Messages sent by a MIX channel participant to the MIX channel are always sent from a MIX client directly to the channel. The participant's server relays the message but does not modify the messages.
</p>
</section2>
<section2 topic="MIX Management and Discovery" anchor="user-server-disco">
<p>
Most interaction between a MIX client and a MIX channel is directly between the client channel. The participant's server relays the message but does not modify the messages. In particular configuration management and discovery is direct. Interaction will be direct, unless explicitly stated otherwise.
</p>
</section2>
<section2 topic="IQ Support on Local Server" anchor="mix-diso">
<p>
The MIX specification requires that some IQ messages MUST or MAY come from the participant's server, and not directly from the client.
This indirect operation enables the participant's server to use information from the client to improve the service provided to the client.
The following table shows which IQs are direct from client, indirect through the local server.
</p>
<table caption="IQ Direct vs Indirect">
<tr><th>Action</th><th>Direct or Indirect</th></tr>
<tr><td>MIX Service Discovery</td><td>Direct</td></tr>
<tr><td>MIX Service Information Discovery</td><td>Direct</td></tr>
<tr><td>MIX Channel Discovery</td><td>Indirect</td></tr>
<tr><td>Discovering Channel Information</td><td>Indirect</td></tr>
<tr><td>Discovering Channel Nodes</td><td>Indirect</td></tr>
<tr><td>Determining Channel Information from Information Node</td><td>Indirect</td></tr>
<tr><td>Determining Channel Participants</td><td>Indirect</td></tr>
<tr><td>Joining a Channel</td><td>Indirect</td></tr>
<tr><td>Preference Setting</td><td>Indirect</td></tr>
<tr><td>Leaving MIX Channel</td><td>Indirect</td></tr>
<tr><td>Nick Setting</td><td>Indirect</td></tr>
<tr><td>Nick Registration</td><td>Indirect</td></tr>
<tr><td>Channel Creation and Destruction</td><td>Indirect</td></tr>
<tr><td>Channel Configuration Management</td><td>Indirect</td></tr>
</table>
<p>
The rest of this section describes how indirect discovery is achieved, using channel join as an example.
Channel Join and Leave functions operate indirectly through the participant's server. The reason for this is that where a channel shares user presence, the channel is included in the user's roster which is managed in the local server. The Join and Leave functions lead to roster changes and so they MUST go through the participant's server. This is included in each of the operations that work in this manner. The general mechanism to achieve this is illustrated by example in this section.
The client addresses indirect messages to the user's own bare JID, indicating the channel with the channel attribute. This is illustrated below.
</p>
<example caption="Client sends request to local server to Join a MIX Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/pda'