moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00
Code Issues Releases Wiki Activity

XEP-0369: Remove lots of whitespace errors

Browse Source
This commit is contained in:
Sam Whited 2016-11-04 11:23:43 -05:00
parent 55177a8768
commit 325d912a1d
1 changed files with 72 additions and 323 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

253
xep-0369.xml
View File

@ -9,9 +9,6 @@
<header>
<title>Mediated Information eXchange (MIX)</title>
<abstract>This document defines Mediated Information eXchange (MIX), an XMPP protocol extension for the exchange of information among multiple users through a mediating service. The protocol can be used to provide human group communication and communication between non-human entities using channels, although with greater flexibility and extensibility than existing groupchat technologies such as Multi-User Chat (MUC). MIX uses Publish-Subscribe to provide flexible access and publication, and uses Message Archive Management (MAM) to provide storage and archiving. </abstract>
&LEGALNOTICE;
<number>0369</number>
<status>Experimental</status>
@ -39,9 +36,8 @@
<jid>Steve.Kille@isode.com</jid>
</author>
&stpeter;
<revision>
<version>0.5</version>
<version>0.5 (XEP Editor: ssw)</version>
<date>2016-11-04</date>
<initials>sek</initials>
<remark><p>
@ -59,7 +55,6 @@
Conversion 1:1
</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2016-09-21</date>
@ -193,45 +188,30 @@
</p>
<ol>
<li>Each MIX client will register with the MIX Proxy 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 use of clients that do not use MIX in conjunction with the MIX proxy.</li>
<li>MIX Service and Channel subscription and management is handled through the MIX proxy so that the MIX Proxy can track all subscription changes and share subscription information between MIX clients. To achieve this, a MIX client sends these MIX management queries to the MIX Proxy using the clients full JID and receives responses back from the MIX Proxy. The MIX Proxy will communicate these requests to a MIX channel from the MIX using the user's bare JID. Because the MIX Proxy 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 and not through the MIX Proxy.</li>
<li>Messages from a MIX channel to a MIX client MUST be handled by a MIX Proxy.</li>
<li>The MIX Proxy 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 synchronization will happen directly between the MIX client and MIX channel.</li>
<li>The MIX Proxy will know which channels are subscribed to, and so can send this list to a MIX client. Because channel subscriptions are long term, this information will be used instead of the bookmark approach used with MUC.</li>
<li>The MIX Proxy will manage channel registration and de-registration in the user's roster.</li>
<li>Different clients may wish to access different channels (e.g., a mobile client may only access a subset of the channels in which a user is interested). The MIX Proxy MAY handle sending messages only to the clients that wish for them, perhaps using a profile mechanism.</li>
</ol>
<p>
Messages being sent from MIX channel to MIX Proxy (which will be of type=groupchat) and presence information are sent to the bare JID. This means that the MIX Proxy will use a modification of the standard &rfc6121; rules.
</p>
<p>
The MIX standard specifies how the MIX channel interacts directly with XMPP clients and with the MIX Proxy.
</p>
<p>
The behaviour of a MIX Proxy and the protocol between MIX Proxy and MIX Client is not currently defined in this specification. It will be defined in one of three places.
It may be desirable in some situations to provide different service to different clients. For example, a mobile client may participate in a smaller set of MIX channels than a desktop client. This needs support from the server to which the client connects, so that MIX client and the connected server can negotiate which channels to send. This is not supported by the core MIX specification, but it is anticipated that this will be specified in one of the following ways:
</p>
<ol>
<li> In an extension to &xep0376; (PAM) which follows a model close to MIX Proxy; or</li>
<li>In a new XEP specifically to defined MIX Proxy behavior; or</li>
<li>As a new section in a future version of the MIX Specification.</li>
</ol>
</section2>
<section2 topic="User Presence in MIX" anchor="concepts-presence">
<p>
@ -260,10 +240,8 @@
<table caption="JID Visibility Modes">
<tr><th>Mode</th><th>Description</th></tr>
<tr><td>'JID Visible'</td><td>In these channels, some or all participant JIDs are visible to all channel participants.</td></tr>
<tr><td>'JID&nbsp;Hidden'</td><td>In these channels, no participant JIDs are visible to channel participants, but they are visible to channel administrators.</td></tr>
</table>
<p>
A channel participant may specify their preferences for JID visibility, with one of the following values:
</p>
@ -274,7 +252,6 @@
<tr><td>'Enforce Hidden'</td><td>The user's JID will never be shown and the user will be removed from channel if channel administrator enforces visibility.</td></tr>
<tr><td>'Enforce Visible'</td><td>The users JID will always be shown and the user will be removed from channel if mode is changed to 'JID Hidden'.</td></tr>
</table>
<p>
The primary representation of a participant in a MIX channel is a proxy JID, which is an anonymized JID using the same domain as the channel and with the name of the channel encoded, using the format "&lt;channel&gt;+&lt;generated identifier&gt;@&lt;mix domain&gt;". They generated identifier MUST NOT contain the '+' characters. The Channel name MAY contain the '+' character. For example in the channel 'coven@mix.shakespeare.example', the user 'hag66@shakespeare.example' might have a proxy JID of 'coven+123456@mix.shakespeare.example'. The reason for the proxy JID is to support JID Hidden channels. Proxy JIDs are also used in JID Visible channels, for consistency and to enable switching of JID visibility. The "urn:xmpp:mix:nodes:jidmap" node maps from proxy JID to real JID. While a user is a participant in a Channel, the mapping between real JID and proxy JID MUST NOT be changed,
</p>
@ -284,39 +261,25 @@
</section2>
<section2 topic="Standard Nodes" anchor="concepts-nodes">
<p>MIX defines a number standard nodes are as follows (although note that not every channel will necessarily use each node):</p>
<table caption="Standard MIX Nodes">
<tr><th>Name</th><th>Node</th><th>Description</th></tr>
<tr><td>Messages</td><td>'urn:xmpp:mix:nodes:messages'</td><td>For publishing messages. Each item of this node will contain a message sent to the channel.</td></tr>
<tr><td>Subject</td><td>'urn:xmpp:mix:nodes:subject'</td><td>For publishing the subject of the channels</td></tr>
<tr><td>Participants</td><td>'urn:xmpp:mix:nodes:participants'</td><td>For publishing the list of participants (identified by anonymized bare proxy JID), and identifying the nick. This is a list of users who would receive messages (by subscription to the messages node) and/or would receive presence (by subscription to the presence node).</td></tr>
<tr><td>JID Map</td><td>'urn:xmpp:mix:nodes:jidmap'</td><td>For publishing a list of anonymized bare JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs.</td></tr>
<tr><td>Presence</td><td>'urn:xmpp:mix:nodes:presence'</td><td>For publishing information about the availability status of online participants, which may include multiple clients for a single participant.</td></tr>
<tr><td>Information</td><td>'urn:xmpp:mix:nodes:info'</td><td>For storing general channel information, such as description. </td></tr>
<tr><td>Allowed</td><td>'urn:xmpp:mix:nodes:allowed'</td><td>For storing JIDs that are allowed to be channel participants.</td></tr>
<tr><td>Banned</td><td>'urn:xmpp:mix:nodes:banned'</td><td>For storing JIDs that are not allowed to be channel participants. </td></tr>
<tr><td>Configuration</td><td>'urn:xmpp:mix:nodes:config'</td><td>For storing channel configuration. This information will generally be restricted to the channel owners.</td></tr>
</table>
<p>
All of the standard nodes are optional. A channel providing a service similar to MUC will typically use all of the standard nodes.
MIX provides mechanisms to allow users to conveniently subscribe to a chosen set of nodes and to unsubscribe to all nodes with a single operation.
</p>
<p>
MIX also makes use of two nodes for support of Avatars. These nodes and their use is defined in &xep0084;. These nodes may be created as part of a MIX channel, where it is desired to publish an avatar associated with the channel.
</p>
<table caption="MIX Nodes for Avatar Support">
<tr><th>Name</th><th>Node</th><th>Description</th></tr>
<tr><td>Avatar Data</td><td>'urn:xmpp:avatar:data'</td><td>For publishing an Avatar</td></tr>
@ -331,23 +294,16 @@
</p>
<table caption="Channel Roles">
<tr><th>Role</th><th>Membership and Rights</th></tr>
<tr><td>Owners</td><td>These are owners of the list, as specified in the channel configuration node. Only owners are allowed to modify the channel configuration node.</td></tr>
<tr><td>Administrators</td><td>Administrators are defined in the channel configuration node. Administrators have update rights to the Allowed Node and Banned Node, so can control which users may participate in a channel. </td></tr>
<tr><td>Participants</td><td>Participants are users listed by JID in the participants node.</td></tr>
<tr><td>Allowed</td><td>Allowed is the set of JIDs that are participants or may be allowed to become participants. A JID is allowed if it does not match entry in the banned node and either it matches an entry in the allowed node or the allowed node is not present. </td></tr>
<tr><td>Anyone</td><td>Any user, including users in the banned node.</td></tr>
</table>
<p>
There will always be at lease one owner and "anyone" will always have role occupants. Other roles may not have any role occupants. Rights are defined in a strictly hierarchical manner, so that for example Owners will always have rights that Administrators have.
</p>
</section3>
<section3 topic="Messages Node" anchor="messages-node">
<p>Items in this node will contain a message identified by a unique ID. A MIX implementation SHOULD NOT make messages available for retrieval from this node using pubsub. The recommended approach is that zero history is held in the messages node, and that this node is used for publication only. The recommended approach to retrieve message history is MAM. Users subscribe to this node to receive messages.</p>
<p>Private Messages are not stored in the messages node.</p>
@ -415,19 +371,14 @@
<section3 topic="Information Node" anchor="info-node">
<p>The Information node holds information about the channel. The information node contains a single item with the current information. Information node history is held in MAM.
The information node is named by the date/time at which the item was created. Users MAY subscribe to this node to receive information updates. The Information node item may contain the following attributes, each of which is optional:
</p>
<ul>
<li>'Name'. A short string providing a name for the channel. The name and description values MUST contain a "text" element and MAY contain additional text elements. Where multiple text elements are provided, each MUST posses an xml:lang attribute that describes the natural language of the subject.</li>
<li>'Description'. A longer description of the channel.</li>
<li>'Contact'. The JID of the person or role responsible for the channel. This MAY be the JID of a MIX channel.</li>
</ul>
<p>The format of the Information node follows &xep0004;. This allows configuration to be updated by MIX defined commands and that the results of update commands are the same as the PubSub node.
The following example shows the format of a item in the information node for the example coven@mix.shakespeare.example channel.
</p>
@ -452,12 +403,10 @@
</items>
]]></example>
</section3>
<section3 topic="Allowed" anchor="allowed-node">
<p>
This node represents a list of JIDs that are allowed to become participants. If the allowed node is not present, all JIDs are allowed. The allowed list is always considered in conjunction with the banned list, stored in the banned node. Only Administrators and Owners have write permission to the allowed node and are also the only roles that are allows to subscribe to this node. Each item contains a real bare JID. The following example shows how the allowed list can specify single JIDs and domains.
</p>
<example caption="Allowed Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:allowed'>
<item id='@shakespeare.lit'/>
@ -465,14 +414,10 @@
</items>
]]></example>
</section3>
<section3 topic="Banned" anchor="banned-node">
<p>
This node represents a list of JIDs that are explicitly not allowed to become participants. The values in this list take priority over values in the allowed node. Only Administrators and Owners have write permission to the allowed node and are also the only roles that are allows to subscribe to this node. Each item contains a real bare JID.
</p>
<example caption="Banned Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:banned'>
<item id='lear@shakespeare.lit'/>
@ -480,71 +425,38 @@
</items>
]]></example>
</section3>
<section3 topic="Configuration Node" anchor="config-node">
<p>
The Configuration node holds the configuration of the channel as a single item, named by the date-time of the last update to the configuration. A single item is stored in the node, with previous configuration history accessed by MAM. Users MAY subscribe to the configuration node to get notification of configuration change. The configuration node is optional for a MIX channel. For example, configuration choices could be fixed and not exposed. A subset of the defined configuration options may be used and additional non-standard configuration options may be added. If configuration options to control functionality of the nature described here are provided, the options defined in this standard MUST be used. The following configuration options are defined:
</p>
<table caption="Configuration Node Options">
<tr><th>Name</th><th>Description</th><th>Field Type</th><th>Values</th><th>Default</th></tr>
<tr><td>'Last Change Made By'</td><td>Bare JID of the user making the last change.</td><td>jid-single</td><td>-</td><td>-</td></tr>
<tr><td>'Owner'</td><td>Dare JIDs with Owner rights as defined in ACL node. When a channel is created, the JID creating the channel is configured as an owner, unless this attribute is explicitly configured to another value.</td><td>jid-multi</td><td>-</td><td>-</td></tr>
<tr><td>'Administrator'</td><td>Bare JIDs with Administrator rights.</td><td>jid-multi</td><td>-</td><td>-</td></tr>
<tr><td>'End of Life'</td><td>The date and time at which the channel will be automatically removed by the server. If this is not set, the channel is permanent.</td><td>text-single</td><td>-</td><td>-</td></tr>
<tr><td>'Nodes Present'</td><td>Specifies which nodes are present. Presence of config nodes is implicit. Jidmap node MUST be present if participants node is present. 'avatar' means that both Avatar Data and Avatar Metadata nodes are present.</td><td>list-multi</td><td>'participants'; 'presence'; 'subject'; 'information'; 'allowed'; 'banned'; 'avatar'</td><td>-</td></tr>
<tr><td>'Message Node Subscription'</td><td>Controls who can subscribe to messages node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'</td><td>'participants'</td></tr>
<tr><td>'Presence Node Subscription'</td><td>Controls who can subscribe to presence node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'</td><td>'participants'</td></tr>
<tr><td>'Participants Node Subscription'</td><td>Controls who can subscribe to participants node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'; 'nobody'; 'admins'; 'owners'</td><td>'participants'</td></tr>
<tr><td>'Subject Node Subscription'</td><td>Controls who can subscribe to subject node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone' </td><td>'participants'</td></tr>
<tr><td>'Information Node Subscription'</td><td>Controls who can subscribe to the information node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'</td><td>'participants'</td></tr>
<tr><td>'Allowed Node Subscription'</td><td>Controls who can subscribe to allowed node.</td><td>list-single</td><td>'participants'; 'allowed'; 'nobody'; 'admins'; 'owners' </td><td>'admins'</td></tr>
<tr><td>'Banned Node Subscription'</td><td>Controls who can subscribe to banned node.</td><td>list-single</td><td>'participants'; 'allowed'; 'nobody'; 'admins'; 'owners' </td><td>'admins'</td></tr>
<tr><td>'Configuration Node Access'</td><td>Controls who can subscribe to configuration node and who has read access to it.</td><td>list-single</td><td>'participants'; 'allowed'; 'nobody'; 'admins'; 'owners' </td><td>'owners'</td></tr>
<tr><td>'Information Node Update Rights'</td><td>Controls who can make changes to the information node</td><td>list-single</td><td>'participants'; 'admins'; 'owners' </td><td>'admins'</td></tr>
<tr><td>'Avatar Nodes Update Rights'</td><td>Controls who can make changes to the avatar data and metadata nodes</td><td>list-single</td><td>'participants'; 'admins'; 'owners' </td><td>'admins'</td></tr>
<tr><td>'JID Visibility'</td><td>Controls JID visibility in the channel.</td><td>list-single</td><td>'jid-hidden'; 'jid-optionally-visible'; 'jid-mandatory-visible'</td><td>'jid-hidden'</td></tr>
<tr><td>'Open Presence'</td><td>If selected, any client may register presence. If not selected, only clients with bare JID in the participants list may register presence.</td><td>boolean</td><td>-</td><td>false</td></tr>
<tr><td>'Participants Must Provide Presence'</td><td>If selected, all channel participants are required to share presence information with the channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
<tr><td>'Allow User Message Retraction'</td><td>If this option is selected users will be able to retract messages sent to the MIX channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
<tr><td>'Administrator Message Retraction Rights'</td><td>This controls which group is able to retract messages sent to the MIX channel.</td><td>list-single</td><td>'nobody'; 'admins'; 'owners'</td><td>'owners'</td></tr>
<tr><td>'Participation Addition by Invitation from Participant'</td><td>This option extends a channel so that a channel participant has rights to invite and enable other users as participants.</td><td>boolean</td><td>-</td><td>false</td></tr>
<tr><td>'No Private Messages'</td><td>If this option is selected, private messages may not be used with the channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
</table>
<p>
The configuration node is in &xep0004; format and includes all of the options used by the channel, including values for options using default values. This means that the value in the form can be directly mapped with the form returned by configuration administration commands. Configuration nodes will typically have a large number of elements. The following short example is provided to illustrate the syntax of the configuration node.
</p>
<example caption="Configuration Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:config'>
<item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:0'>
@ -571,13 +483,8 @@
</item>
</items>
]]></example>
</section3>
</section2>
<section2 topic="Non-Standard Nodes" anchor="non-standard-nodes">
<p>
The MIX standard allows channels to use non-standard nodes, using names that do no conflict with the standard nodes. The capabilities of these nodes may be specified in a future XEP or be for private agreement. Non-Standard nodes MUST NOT duplicate or otherwise provide capability that can be provided by standard nodes.
@ -587,11 +494,9 @@
<section1 topic='Discovery' anchor='discovery'>
<section2 topic='Discovering a MIX service' anchor='disco-service'>
<p>
An entity may discover a MIX service or MIX services by sending a Service Discovery items ("disco#items") request to its own server.
</p>
<example caption="Entity queries Server for associated servvices" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
id='lx09df27'
@ -612,8 +517,6 @@
</query>
</iq>
]]></example>
<p>To determine if a domain hosts a MIX service, a &xep0030; info query should be sent in the usual manner to determine capabilities.</p>
<example caption="Entity queries a service" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
@ -624,7 +527,6 @@
</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'. </p>
<example caption="Service responds with Disco Info result" ><![CDATA[
<iq from='mix.shakespeare.example'
id='lx09df27'
@ -643,21 +545,15 @@
<p>
A MIX service may return the following features:
</p>
<ul>
<li>'urn:xmpp:mix:0': This indicates support of MIX, and is returned by all MIX services.</li>
<li>'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>'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. An end user client may need to create channels, perhaps for short term usage. This feature helps the client to identify an MIX channel 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>
<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 server MUST only return channel that exist and that the user making the query has rights to subscribe to. This query MAY be made directly by and XMPP client or by a MIX Proxy.</p>
<example caption='MIX Proxy Queries for Channels on MIX Service'><![CDATA[
<iq from='hag66@shakespeare.lit'
id='kl2fax27'
@ -678,8 +574,6 @@
</query>
</iq>
]]></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 by a MIX Proxy and not the end client.</p>
@ -738,11 +632,8 @@
</iq>
]]></example>
</section2>
<section2 topic="Determining Information about a Channel" anchor="find-channel-info">
<p>The Information Node contains various information about the channel that may be useful to the user. This can be read by the XMPP Client directly or by a MIX Proxy.</p>
<example caption='MIX Proxy Requests Channel Information'><![CDATA[
<iq from='hag66@shakespeare.lit'
id='kl2fax27'
@ -774,13 +665,10 @@
</query>
</iq>
]]></example>
</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.</p>
<example caption='MIX Proxy Requests Participant List'><![CDATA[
<iq from='hag66@shakespeare.lit'
id='kl2fax27'
@ -801,16 +689,11 @@
</items>
</iq>
]]></example>
</section2>
<section2 topic="Discovering Client MIX Capability" anchor="mix-client-discovery">
<p>
Where a client supports MIX, it MUST advertise this capability in response to a Disco request. This will enable other entities to determine if a client supports MIX. The following example shows a Disco response from a client that supports both MIX and MUC.
</p>
<example caption='Disco Response showing MIX support'><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='disco1'
@ -867,10 +750,6 @@
</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>
@ -902,11 +781,9 @@ the participant is not be subscribed to all nodes associated with the channel (i
</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. Each &lt;participant&gt; element will include the nick of the user being added, which will be how the user will typically be shown in the channel.</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.
</p>
<example caption="User Modifies Subscription Request"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
@ -927,18 +804,13 @@ the participant is not be subscribed to all nodes associated with the channel (i
</iq>
]]></example>
</section3>
<section3 topic="Roster Management" anchor="usecase-roster-management">
<p>
After the user has jointed the channel, the user's MIX Proxy 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 MIX Proxy 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.
</p>
<p>
A channel MAY publish an Avatar following &xep0084;. A client MAY make use of this information to associate an Avatar with the roster entry for a channel.
</p>
@ -966,18 +838,12 @@ the participant is not be subscribed to all nodes associated with the channel (i
</p>
<table caption="Standard User Preference Options">
<tr><th>Option</th> <th>Values</th><th>Default</th></tr>
<tr><td>'JID Visibility'</td> <td>'Default', 'Never', 'Prefer Not'</td> <td>'Use Channel Default'</td></tr>
<tr><td>'Private Messages'</td><td>'Allow', 'Block'</td> <td>'Allow'</td></tr>
<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>
<example caption="User Joins a Channel and Specifies a preference"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
@ -1023,7 +889,6 @@ 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>
<example caption="User Requests and Recieves Preferences Template Form"><![CDATA[
<iq type='get'
@ -1055,12 +920,9 @@ the participant is not be subscribed to all nodes associated with the channel (i
</user-preference>
</iq>
]]></example>
<p>
A user may modify preferences using the corresponding set operation. The set may specify values for some or all attributes. All attributes are returned in the result.
</p>
<example caption="User Updates Preferences"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
@ -1153,7 +1015,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
<li>The user explicitly sets the nick, as described in this section.</li>
<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. 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>
@ -1218,7 +1079,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
<p>
MIX services SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, as defined in &rfc7700;.
</p>
<example caption="Service Returns User of Nick"><![CDATA[
<iq type='result'
to='mix.shakespeare.example'
@ -1346,11 +1206,9 @@ the participant is not be subscribed to all nodes associated with the channel (i
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>
]]></example>
<p>The MIX channel then puts a copy of the message into the MAM archive for the channel and sends a copy of the message to each participant in
standard groupchat format. These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's MIX Proxy. The message from value is the full Proxy JID of the message sender. The id of the message is the ID from the MAM archive.</p>
<example caption="Channel Reflects Message to Participants"><![CDATA[
<message from='coven+12345@mix.shakespeare.example/678'
to='hecate@shakespeare.example'
@ -1359,12 +1217,9 @@ the participant is not be subscribed to all nodes associated with the channel (i
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>
]]></example>
<p>
The messages sent to participants have a different message id to the originally submitted message. This does not impact most recipients, but it does not allow the message originator to correlate the message with the submitted message. To address this the MIX channel MUST include an additional element of the message copy going back to the originator's bare JID that includes the original id. This enables the originator to correlate the received message with the message submitted.
</p>
<example caption="Channel Reflects Message back to Originator"><![CDATA[
<message from='coven+12345@mix.shakespeare.example/678'
to='hag66@shakespeare.example'
@ -1374,16 +1229,12 @@ the participant is not be subscribed to all nodes associated with the channel (i
<submission-id xmlns='urn:xmpp:mix:0'>92vax143g</submission-id>
</message>
]]></example>
</section3>
<section3 topic="Retracting a Message" anchor="usecase-retract">
<p>
A MIX channel MAY support message retraction, where the sender of a messages or an administrator deletes a message. If this is done the original message MUST be replaced by a tombstone. The protocol to request retraction does this by a message with a &lt;retract&gt; element as shown in the following example.
</p>
<example caption="User Retracts a Message"><![CDATA[
<message from='hag66@shakespeare.example/pda'
to='coven@mix.shakespeare.example'
@ -1391,7 +1242,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
<retract id='28482-98726-73623' xmlns='urn:xmpp:mix:0'/>
</message>
]]></example>
<p>
The MIX channel will allow a user to retract a message sent by the user if the 'Allow User Message Retraction' option is configured. The MIX channel will allow a user to retract any message if the user is in the group specified by the 'Administrator Message Retraction Rights' option.
</p>
@ -1401,7 +1251,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
<p>
When a message is retracted the original message &lt;body&gt; MUST be removed and MUST be replaced with a tombstone using the &lt;retracted&gt; element 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/chamber'>
<result xmlns='urn:xmpp:mam:1' queryid='f27' id='28482-98726-73623'>
@ -1414,12 +1263,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
</result>
</message>
]]></example>
</section3>
<section3 topic="Setting the Channel Subject" anchor="set-subject">
<p>
Setting the subject for a channel follows a similar procedure to sending a message. An XMPP client will send a message setting the subject directly to the MIX channel.
@ -1457,17 +1301,13 @@ the participant is not be subscribed to all nodes associated with the channel (i
When a new Participant joins a channel and subscribes to the Subject Node, the channel MUST send to the user's MIX Proxy a message with the current subject. An XMPP Client MAY directly read the Subject node using &xep0060;.
</p>
</section3>
<section3 topic='Telling another User about a Channel' anchor='usecase-user-tell'>
<p>
A convenient way to reference another channel is to use &xep0372; which enables the JID of a channel to be shared. This might be used simply to inform the message recipient about the channel or as mechanism to invite the user to join the channel. This is useful as an invitation mechanism to a channel that any user can join or where the invitee knows that the user may join (e.g., because the channel is for all users in an organization).
</p>
</section3>
<section3 topic='Inviting another User to join a Channel that the user does not have Permission to Join' anchor='usecase-user-invite'>
<p> Invitation by reference, as described in the previous section, is a convenient approach to invite a user to join a channel that the user has permission to join. This section describes the approach used when the inviter has permission to grant rights for the invitee to become a channel participant. This might be because the inviter is an administrator of the channel or the channel may have a special mode where channel participants may grant rights for other users to join a channel ('Participation Addition by Invitation from Participant' enabled). This approach is used to avoid cluttering the allowed node with JIDs of users who are invited to join, but do not accept the invitation.
When a channel participant(the inviter) invites another user (the invitee) to join a channel, the following sequence of steps is followed:
</p>
@ -1481,7 +1321,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
<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 has 'Participation Addition by Invitation from Participant' mode enable. 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.
</p>
<example caption='Inviter Requests and Receives Invitation'><![CDATA[
<iq from='hag66@shakespeare.lit/pda'
id='kl2fax27'
@ -1505,11 +1344,9 @@ the participant is not be subscribed to all nodes associated with the channel (i
</invitation>
</iq>
]]></example>
<p>
The inviter can now send the invitee a message containing the invitation, as shown in the following example.
</p>
<example caption='Inviter sends Invitation to Invitee'><![CDATA[
<message from='hag66@shakespeare.lit/pda'
id='foo'
@ -1523,11 +1360,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
</invitation>
</iq>
]]></example>
<p>The invitation can now be used by the invitee to join a channel. The invitation is simply added to the standard channel join, so that the channel can validate the invitation using the token. If the allowed node is present and the invitee is not matched against any item, the channel MUST add the invitee to the allowed node as part of the join.</p>
<example caption="User Joins a Channel with an Invitation"><![CDATA[
<iq type='set'
from='cat@shakespeare.example'
@ -1544,14 +1377,12 @@ the participant is not be subscribed to all nodes associated with the channel (i
</join>
</iq>
]]></example>
<p>The invitee may send an acknowledgement back to the inviter, noting the status of the invitation. Values are:</p>
<ul>
<li>'Joined': The invitee has joined the channel.</li>
<li>'Declined': The invitee is not taking up the invitation.</li>
<li>'Acknowledged': The invitation is acknowledged, without information on action taken or planned.</li>
</ul>
<example caption='Invitee sends Acknowledgement to Inviter'><![CDATA[
<message from='cat@shakespeare.lit/miaow'
id='bar'
@ -1568,7 +1399,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
</invitation-ack>
</iq>
]]></example>
</section3>
@ -1577,20 +1407,15 @@ the participant is not be subscribed to all nodes associated with the channel (i
<p>
Private Messages are used to provide communication with another channel participant through the MIX channel, without the initiating user knowing the real JID of the channel participant. A channel MAY support use of Private Messages. Private messages are standard XMPP messages. A message goes through a number of stages with different addressing. This is set out in the following table.
</p>
<table caption="Setting From and To when sending Private Messages">
<tr><th>Message</th><th>From</th><th>To</th></tr>
<tr><td>First Message from Client to MIX Channel</td><td>Full JID of initiator's client</td><td>Proxy bare JID of responder</td></tr>
<tr><td>First Message from MIX Channel to responder's MIX Proxy</td><td>Proxy full JID of initiator's client</td><td>Bare JID of responder</td></tr>
<tr><td>First Message from responder's MIX Proxy to one or more of the responder's clients</td><td>Proxy full JID of initiator</td><td>Full JID of responder's client</td></tr>
<tr><td>Messages from responder's client to MIX Channel</td><td>Full JID of responder's client</td><td>Proxy full JID of initiator's client</td></tr>
<tr><td>Messages from MIX channel to initiator's client</td><td>Proxy full JID of responder's client</td><td>Full JID of initiator's client</td></tr>
<tr><td>Messages from initiator's client to MIX Channel</td><td>Full JID of initiator's client</td><td>Proxy full JID of responder's client</td></tr>
<tr><td>Message from MIX Channel to responder's client</td><td>Proxy full JID of initiator's client</td><td>Full JID of responder's client</td></tr>
</table>
<p>Private Messages MAY be archived using MAM by the XMPP servers associated with initiator and responder. Private Messages MUST NOT be archived by the MIX channel.</p>
</section3>
@ -1599,10 +1424,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
<section3 topic="Requesting vCard" anchor="usecase-vcard">
<p>A user may request the vCard of a channel participant by sending a request through the channel. The request may be sent directly by the client or through a MIX Proxy. The MIX channel MAY pass this request on or may block it. In the following example, the requesting client sends a message to the anonymized bare JID of the channel participant for which the vCard is desired.</p>
<example caption="Client directly requests vCard through channel" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
id='lx09df27'
@ -1612,7 +1433,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
</iq>
]]></example>
<p>The MIX channel MAY pass on the vCard request or may reject with an error, dependent on channel policy. The MIX service will then address the vCard request to the MIX proxy (bare JID) using an anonymous full proxy JID to hide the requester. </p>
<example caption="Channel passes on vCard request to MIX Proxy" ><![CDATA[
<iq from='coven+123456@mix.shakespeare.example/6789'
id='lx09df27'
@ -1621,7 +1441,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
<vCard xmlns='vcard-temp'/>
</iq>
]]></example>
<p>
The MIX Proxy, on behalf of the user, MAY send a response or reject with an error. The MIX Proxy will send the vCard back to the channel.
</p>
@ -1640,15 +1459,12 @@ the participant is not be subscribed to all nodes associated with the channel (i
<NICKNAME>stpeter</NICKNAME>
<URL>http://www.xmpp.org/xsf/people/stpeter.shtml</URL>
</vCard>
<query xmlns='http://jabber.org/protocol/disco#info'>
</iq>
]]></example>
<p>
The MIX channel will then send the vCard response to the requesting client on behalf of the client sending the response.
</p>
<example caption="Service responds with Disco Info result" ><![CDATA[
<iq from='coven+989898@mix.shakespeare.example'
id='lx09df27'
@ -1666,8 +1482,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
</vCard>
</iq>
]]></example>
</section3>
</section2>
@ -1676,7 +1490,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
For an active MIX Channel, the presence node is updated as channel participants change status and presence information is sent to the channel. When a MIX channel starts, typically when the associated MIX Service and Server start, there is a need to initialize the presence node. This is done by the XMPP server associated with the MIX channel sending out a presence probe for each channel participant, following the presence probe process specified in &rfc6121;. A presence probe MUST NOT be sent for users who have set presence preference to not sharing.
</p>
</section2>
<section2 topic="Ensuring Message Delivery" anchor="use-ensure-delivery">
<p>
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.
@ -1684,7 +1497,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
<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.
</p>
<example caption="Channel Sends Marker Message" ><![CDATA[
<iq from='coven@mix.shakespeare.example'
id='lx09df27'
@ -1707,13 +1519,11 @@ the participant is not be subscribed to all nodes associated with the channel (i
<p>
All messages sent to a MIX channel MUST be archived using MAM in association with the MIX channel. All messages MUST also be archived on the server associated with each channel participant receiving the message, which enables clients to always retrieve messages from the clients MAM archive. Other channel nodes MAY be archived.
</p>
<section3 topic="Archive of Messages" anchor="use-mam-messages">
<p>
Messages sent to participants MUST be archived by both the MIX channel and by the user's server. This MUST include messages setting subject and MAY include presence messages. Correct MIX operation relies on messages being archived.
</p>
</section3>
<section3 topic="Retrieving Messages" anchor="use-mam-retrieve">
<p>
Clients will retrieve MIX messages using standard MAM protocol from the user's archive. The MAM query will filter based on the channel JID to enable access to messages from a given channel. This gives the user a simple mechanism to access all messages sent to the channel. MAM can be used to retrieve older messages that have not been cached by the client.
@ -1722,9 +1532,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
Messages may also be retrieved from the channel by addressing MAM queries to the channel JID. This will behave like a standard MAM archive. This can be useful for administrators to access archived messages. It can also be useful for new channel participants to access the historical archives.
</p>
</section3>
<section3 topic="MAM Use with other Channel Nodes" anchor="use-mam-other-nodes">
<p>
A MIX Channel MAY use MAM to archive nodes other than message nodes. Clients with rights to access these archives may use MAM to do this, specifying the PubSub node in the MAM query addressed to the channel.
@ -1739,7 +1546,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
<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 '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/intibo24'
id='lx09df27'
@ -1763,9 +1569,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
</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).
@ -1785,11 +1588,9 @@ A client creates a channel by sending a simple request to the MIX service. A c
<create channel='coven' xmlns='urn:xmpp:mix:0'/>
</iq>
]]></example>
<p>
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/intibo24'
id='lx09df27'
@ -1850,12 +1651,10 @@ A client creates a channel by sending a simple request to the MIX service. A c
</iq>
]]></example>
</section3>
<section3 topic="Converting a 1:1 Conversation to a Channel" anchor="usecase-admin-converting-chat">
<p>
A common use case for an ad hoc channel is where two users are engaged in a 1:1 chat and wish to broaden the discussion. Prior to bringing more users into a channel, using standard invitation process, there is a need to move a dialogue. The first step is for one of the two users to create an ad hoc channel, as described in the previous section. The other user will then be invited, and can switch to the new channel. It may also be useful to share some or all of the messages from the 1:1 discussion into the new channel. This is done by sending these messages to the channel. These messages are marked as &lt;resend&gt; which includes the original message time to facilitate appropriate display.
</p>
<example caption="Resending a message to create History" ><![CDATA[
<message from='hag66@shakespeare.example/pda'
to='A1B2C345@mix.shakespeare.example'
@ -1865,18 +1664,15 @@ A client creates a channel by sending a simple request to the MIX service. A c
<resend xmlns='urn:xmpp:mix:0' time='2010-07-10T23:08:25Z'/>
</message>
]]></example>
</section3>
<section3 topic='Destroying a Channel' anchor='usecase-admin-destroy'>
<p>
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 server. 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>
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/intibo24'
id='lx09df27'
@ -1891,21 +1687,15 @@ A client creates a channel by sending a simple request to the MIX service. A c
type='result'>
</iq>
]]></example>
</section3>
<section3 topic='Server Destroying a Channel' anchor='usecase-server-destroy'>
<p>
A server MUST destroy a channel that has exceeded its specified explicit lifetime.
Servers may destroy channels which have no participants and/or presence according to local policy. There will often be good reasons to not destroy rooms in these scenarios, in particular to facilitate channel re-use and history access.
</p>
</section3>
<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 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/intibo24'
id='lx09df27'
@ -1939,10 +1729,7 @@ A client creates a channel by sending a simple request to the MIX service. A c
</info>
</iq>
]]></example>
<p> Updating the information node is done using a set command of type info. 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/intibo24'
id='lx09df27'
@ -1974,13 +1761,8 @@ A client creates a channel by sending a simple request to the MIX service. A c
</iq>
]]></example>
</section3>
<section3 topic='Modifying Channel Configuration' anchor='usecase-admin-information'>
<p>Channel owners may modify the channel configuration. The client MAY issue a get command "config" 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 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. </p>
<example caption="Getting Configuration Form" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
id='lx09df27'
@ -2006,10 +1788,7 @@ A client creates a channel by sending a simple request to the MIX service. A c
</config>
</iq>
]]></example>
<p> Updating the information node is done using a set command of type config. 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/intibo24'
id='lx09df27'
@ -2047,8 +1826,6 @@ A client creates a channel by sending a simple request to the MIX service. A c
</iq>
]]></example>
</section3>
<section3 topic='Controlling Channel Partipcipants' anchor='usecase-admin-participants'>
<p>
Owners and Administrators may 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.
@ -2076,11 +1853,9 @@ A client creates a channel by sending a simple request to the MIX service. A c
</pubsub>
</iq>
]]></example>
<p>
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/intibo24'
id='lx09df27'
@ -2100,14 +1875,9 @@ A client creates a channel by sending a simple request to the MIX service. A c
<pubsub xmlns='http://jabber.org/protocol/pubsub'/>
</iq>
]]></example>
<p>
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/intibo24'
id='lx09df27'
@ -2127,11 +1897,9 @@ A client creates a channel by sending a simple request to the MIX service. A c
<pubsub xmlns='http://jabber.org/protocol/pubsub'/>
</iq>
]]></example>
<p>
When the MIX channel adds a JID to the banned node, other nodes in the MIX channel will be appropriately updated to reflect this change. In particular, the participants nodes and presence nodes will be updated to remove matching JIDs. This will have the effect of immediately removing the user from the channel. For this reason, there is no requirement to have the "kick" functionality of MUC, as this is achieved by banning the user.
</p>
</section3>
</section2>
@ -2145,14 +1913,10 @@ A client creates a channel by sending a simple request to the MIX service. A c
</p>
<ol>
<li>Entirely separate MIX and MUC implementation, with MIX and MUC using separate domains and MIX channels being completely separate from MUC rooms.</li>
<li>Fully integrated MIX and MUC implementation, with MIX and MUC sharing a single domain and rooms/channels equivalent.</li>
<li>Partially integrated MIX and MUC implementation, with MIX and MUC using separate domains, but rooms/channel are common. This means that each MIX channel will have MUC room of the same name and same participants.</li>
</ol>
<p>The fully integrated approach would be transparent to clients. Disco of a room or channel would show support for both MUC and MIX, which would enable a client to choose whether to use MUC or MIX. The following example shows how a MIX service that also supported MUC would respond:</p>
<example caption="Service responds with Disco Info result showing MIX and MUC support" ><![CDATA[
<iq from='mix.shakespeare.example'
id='lx09df27'
@ -2173,11 +1937,7 @@ A client creates a channel by sending a simple request to the MIX service. A c
</query>
</iq>
]]></example>
<p>For the partially integrated service, it will be useful for clients that support both MIX and MUC to be able to determine that the server supports both protocols. For a MIX client, it will be useful to know the MUC service, so that this information can be shared with a MUC client invitation. This information is provided by the initial service discovery:</p>
<example caption="MIX Service responds with Disco Info result sharing MUC service location" ><![CDATA[
<iq from='mix.shakespeare.example'
id='lx09df27'
@ -2202,11 +1962,8 @@ A client creates a channel by sending a simple request to the MIX service. A c
</query>
</iq>
]]></example>
<p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'. The field with var='muc-mirror' is the value of which is the mirrored MUC domain's JID. </p>
<p>Where a client supporting both MIX and MUC is given a reference to a MUC room, it is desirable that the client can determine the MIX channel and join using MIX. This is achieved by an equivalent extension to MUC service discover.</p>
<example caption="MUC Service responds with Disco Info result sharig MIX service location" ><![CDATA[
<iq from='chat.shakespeare.example'
id='lx09df27'
@ -2231,16 +1988,12 @@ A client creates a channel by sending a simple request to the MIX service. A c
</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>
<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
<link url='#mix-client-discovery'>Discovering Client MIX Capability</link>. If the client supports MIX a MIX invite SHOULD be sent.
</p>
</section2>
</section1>
@ -2260,14 +2013,10 @@ A client creates a channel by sending a simple request to the MIX service. A c
&xep0045; provides a mechanism to control access to MUC rooms using passwords. An equivalent mechanism is not included in MIX, as it has a number of security issues. Control of access to channels is better achieved using an explicit list of participants.
</p>
</section2>
<section2 topic="Voice Control" anchor="voice-control">
<p>
&xep0045; defines a mechanism so that MUC moderators can control who is able to send messages to a MUC room using a "voice" mechanism. The current version of MIX does not include this. This might be added to a future version of this XEP or as a separate XEP if this capability becomes an agreed requirement.
</p>
</section2>
</section1>