<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>
<remark><p>Clarification of MIX Proxy concept; Clarify node definitions; Make all nodes optional; Merge ACL node into configuration node; Add information node including avatar; Resolve 4.1 question by accepting provisional answer; Add discovery examples; setting and sharing Subject; Protocol to request channel information and participants; vCard Request; Private Messages; Set user preferences with XEP-0004; Remove references to member and occupant; Add Role Definition; Add Banned and Allowed Nodes; Update Configuration Definition;Add information on original id to message reflected back to sender Add XEP-0372 mechanism to reference channel and informal invite; Channel Invitations </p></remark>
<p>The Mediated Information eXchange (MIX) protocol is intended as a replacement for Multi-User Chat (MUC). MUC is a major application of XMPP that was developed in 2002 and standardized in &xep0045;. MIX implements the same basic MUC patterns in a more flexible and extensible way in order to address requirements that have emerged since MUC was developed. MIX supports all of the core chatroom features that are familiar from MUC, such as discussion topics and invitations. Like MUC, it also defines a strong access control model, including the ability to ban users, to name administrators, and to provide controls as to which users can participate in channels.</p>
<li>Experience has shown that it is difficult to use MUC to build several kinds of communication applications (such as a multimedia conference) without undesirable adaptations.</li>
<li>In the years after MUC was designed, both &xep0060; and &xep0313; have been developed and it is desirable to reuse these building blocks (e.g., MAM can be used for message history) rather than using the less robust methods defined in &xep0045;.</li>
<p>If a server wishes to expose both MUC and MIX representations of chatrooms, it is RECOMMENDED to do so by serving MUC and MIX on different domains, but a server MAY serve them on the same domain.</p>
<li>A user's participation in a channel persists and is not modified by the user's client going online and offline.</li>
<li>Multiple devices associated with the same account can share the same nick in the channel, with well-defined rules making each client individually addressable.</li>
<li>A user can determine which channels they participate in.</li>
<li>Provide extensibility regarding data formats that can be sent within a channel (files, structured data, indications about media sources in multimedia conferences, etc.) as well as flexibility regarding which data formats a user wants to receive.</li>
<li>Enable federation of a channel across multiple servers, to provide a service equivalent to "federated MUC" &xep0289;.</li>
MIX will enable a wide range of auxiliary services. The goal of the MIX specification is to set out the core capabilities needed for MIX. It is anticipated that additional XEPs will be written to extend the core MIX, and the core MIX specification notes some areas where this may happen. This approach will avoid the core MIX specification becoming unduly large. Profiles referencing sets of related MIX XEPs may be developed in the future.
<li>MIX channels (roughly equivalent to MUC rooms) are hosted on one or more MIX domains, (examples: 'mix.example.com'; 'conference.example.com'; 'talk.example.com'), which are discoverable through &xep0030;. Each channel on a MIX service can then be discovered and queried.</li>
<li> In MIX each channel (e.g., 'channel@mix.example.com') is a specialized pubsub service. This is based on the model from &xep0163; where every user JID (e.g., 'user@example.com') is its own pubsub service. </li>
<li>A channel's pubsub service contains a number of nodes for different event types or data formats. As described below, this document defines several standard nodes; however, future specifications or proprietary services can define their own nodes for extensibility.</li>
<li>Affiliations with the nodes are managed by the MIX service by channel level operations, so that the user does not have to separately manage affiliations with the individual PubSub nodes.
<li>&xep0313; (MAM) is used for all history access, with each node being individually addressable for MAM queries. This simplifies implementation compared to MUC (which had a specialized and rather limited history retrieval mechanism).</li>
<li>A client can achieve a 'quick resync' of a node by requesting just those changes it has not yet received, using standard MAM protocol. This solves the MUC issue of either receiving duplicate messages when rejoining a room or potentially missing messages.</li>
<li>Because MAM is used for history, only those nodes that have a 'current value' need to store any items in them — e.g., 'urn:xmpp:mix:nodes:presence' and 'urn:xmpp:mix:nodes:information' would store their current values (with older values being queryable through MAM), while 'urn:xmpp:mix:nodes:messages' would store no items.</li>
<li>A user's participation in a channel outlives their client sessions. A client which is offline will not share presence within the channel, but the associated user will still be listed as an participant. </li>
<li>Each participant is addressable by a single bare JID, which is a proxy JID (not the user's real JID) to make it straightforward to hide the user's real JID from other channel participants. Full JIDs comprised of this bare JID plus a resource (also anonymized) are then constructed, allowing visibility into the number of online resources participating in a channel.</li>
<li> Although some protocol is shared with MUC, MUC clients are not interoperable with a MIX service. This means that where a user chooses to use MIX, all of the users clients need to support MIX.</li>
<li>MIX requires the server to which the MIX client connects to provide functionality to support MIX. This functionality is defined in this specification and referenced as "MIX Participant's Server Behaviour".</li>
<p>MIX is based upon domains providing a MIX service, such as 'mix.shakespeare.example'. Note that although PubSub communication is used, a domain used for MIX is a MIX domain and not a standard &xep0060; domain. Like MUC, there is no requirement on the naming of these domains; the label 'mix' used in examples in this specification and the fact that it is a subdomain of a 'shakespeare.example' service are purely for example.</p>
<p>Every MIX channel is an addressable PubSub service (with additional MIX semantics) that will be addressed using a bare JID by other XMPP entities, for example coven@mix.shakespeare.example. While &xep0060; is used as the basis for the MIX model, MIX uses standard presence and groupchat messages to provide an interface to the MIX service that does not expose PubSub protocol for many of the more common functions.
<p> Historical data (such as the messages sent to the channel) is stored in an archive supporting Message Archive Management (MAM) so that clients can subsequently access this data with MAM. Each node can be archived separately (e.g., the presence node or the configuration node). MIX messages are archived by both the MIX channel and the user's server, so that clients can generally use their local MAM archiver. MIX clients can retrieve archived information with MAM in order to quickly resync messages with regard to a channel, and can do so without providing presence information.</p>
A MIX channel does not send messages and presence directly to the MIX client of a channel participant, but addresses them to the participant using the participant's bare JID. The participant's server MUST then handle these messages and pass them on to zero, one or multiple clients. To enable MIX to work, this behaviour is necessary and so the server of every MIX client MUST follow the rules set out in this specification.
The MIX model is that a user will join a channel over an extended period, and that the user (not a specific client used by the user) joins the channel. The primary subscription is with the client's bare JID.
<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 participant's server (addressed by bare JID) and MUST be handled by the MIX participant's server.</li>
<li>The MIX participant's server will only forward messages to online clients and will not forward messages if no clients are online.
This means that a MIX client needs to resynchronize with all MIX channels 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 client will generally send management and other messages directly to the MIX channel and this MUST be done except where specifically noted. </li>
<li>The user's roster contains each MIX channel to which the user is subscribed. 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>
Messages from a MIX channel to a MIX participant (which will be of type=groupchat) and presence information are sent to the participant's server using the participant's bare JID. This means that the MIX participant's server MUST implement a modification of the standard &rfc6121; message processing rules.
The core MIX specification sets out how the MIX channel interacts directly with XMPP clients and with the MIX participant's server. Behaviour of the MIX participant's server is also specified in this MIX specification.
MIX channels store presence of each online client for a user that chooses to publish presence. Presence is stored in the presence node and is encoded using a full proxy JID. Where a user publishes presence for one or more clients, this information is available to all users subscribing to the channel presence.
Channel participants can send messages to clients publishing their presence by sending them to the full proxy JID published in the presence node. These stanzas MAY be routed to the client by the MIX channel. The choice to do this is dependent on MIX channel policy. For example, a disco request MAY be routed through the MIX channel to the client.
Presence updates are distributed by a channel to the bare JID of subscribers and then the subscriber's server will distribute to each of the subscriber's currently online clients.
Private messages MAY be sent to channel participants if allowed by channel policy. Private messages are
addressed to the user's bare proxy JID determined from the participants node, and routed by the MIX to the user's bare real JID, where standard distribution rules will apply.
<tr><td>'JID Visible'</td><td>In these channels all participant JIDs are visible to all channel participants.</td></tr>
<tr><td>'JID Maybe Visible'</td><td>In these channels, participant JIDs are visible to all channel participants when participant preference allows.</td></tr>
<tr><td>'JID Hidden'</td><td>In these channels, no participant JIDs are visible to channel participants, but they are visible to channel administrators.</td></tr>
<tr><td>'No JID Visibility Preference'</td><td>The users JID will be visible if the channel is JID Visible or JID Maybe Visible channels and hidden if the channel is JID Hidden. </td></tr>
<tr><td>'Prefer Hidden'</td><td>The user's JID will be hidden if the channel is JID Maybe Visible and shown if the channel is JID Visible .</td></tr>
<tr><td>'Enforce Hidden'</td><td>The user's JID will never be shown and the user will be removed from channel if channel mode is changed to JID Visible.</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>
For JID Visible and JID Hidden channels the default user visibility preference is No JID Visibility Preference. For JID Maybe Visible channels, the default user visibility preference is Prefer Hidden, so that JIDs will only be visible when users explicitly permit this.
</p>
<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 "<generated identifier>#<channel>@<mix domain>". The generated identifier MUST NOT contain the '#', '/' or '@' 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 '123456#coven@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. Servers and clients MUST determine that a JID is a proxy JID from context and MUST NOT infer that a JID is a proxy JID because it contains the '#' character.
The mapping of real bare JID to proxy JID is defined when a participant joins a channel. While a user is a participant in a Channel, the mapping between real JID and proxy JID MUST NOT be changed. This mapping must be maintained after the user leaves the channel. Proxy JID values MUST NOT be re-used. If a JID that left a channel joins the channel again the same proxy JID MAY be used again or a different new proxy JID MAY be assigned.
The example real full JIDs in this specification are aligned the anticipated new format that splits the resource into two parts. The first part is UUID that is a stable and fixed value for the client and is anticipated to be a fixed format which may well be UUID 4. The second part is server assigned and will vary with each session. A realistic JID with resource is: 'hag66@shakespeare.example/d104f6a7-97e9-477f-8947-e4a37691d7ee/7533375f2cd'. This specification uses examples of the style: 'hag66@shakespeare.example/UUID-a1j/7533' which are aligned to real resources, but more compact. CITATION TO BE ADDED. If the final specification differs from this, the examples will be updated.
The full JIDs held in the presence nodes are anonymized using a similar mechanism. First the bare JID is mapped to a bare proxy JID, using the mapping held in the "urn:xmpp:mix:nodes:jidmap" node for the bare JID. Then the resource is replaced with a generated value. For example, 'hag66@shakespeare.example/UUID-a1j/7533' in the channel coven might have a proxy JID of '123456#coven@mix.shakespeare.example/789'. There is no client visible mapping of proxy full JIDs maintained as this is not needed. The MIX channel will need to maintain a mapping, to support directly addressing clients, such as for client to client disco#info queries. While an full proxy JID is held in the presence node, the mapping to real JID MUST NOT be changed. When adding a client to the presence node, the server MAY add the same anonymized JID as used before by that client, or it MAY create a different anonymized JID.
<tr><td>Messages</td><td>'urn:xmpp:mix:nodes:messages'</td><td>For distributing messages to the channel. Each item of this node will contain a message sent to the channel.</td><td>Message</td><td>Message</td></tr>
<tr><td>Participants</td><td>'urn:xmpp:mix:nodes:participants'</td><td>For storing the list of participants and the associated nick. Channel participants are added when they join the channel and removed when they leave </td><td>Join/Leave/Set Nick</td><td>PubSub</td></tr>
<tr><td>JID Map</td><td>'urn:xmpp:mix:nodes:jidmap'</td><td>For storing a list of bare proxy JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs.</td><td>Automatic</td><td>PubSub</td></tr>
<tr><td>JID Maybe Visible Map</td><td>'urn:xmpp:mix:nodes:jidmap-visible'</td><td>For storing a list of bare proxy JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs for participants that choose to share real JIDs in a channel with JID Maybe Visible mode.</td><td>Automatic</td><td>PubSub</td></tr>
<tr><td>Presence</td><td>'urn:xmpp:mix:nodes:presence'</td><td>For storing information about the availability status of online participants, which MAY include multiple clients for a single participant.</td><td>Presence</td><td>Presence</td></tr>
<tr><td>Information</td><td>'urn:xmpp:mix:nodes:info'</td><td>For storing general channel information, such as description. </td><td>PubSub</td><td>PubSub</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><td>PubSub</td><td>PubSub</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><td>PubSub</td><td>PubSub</td></tr>
All of the standard nodes are OPTIONAL. A channel providing a service similar to MUC will typically use all of the standard nodes, but other channels MAY use any combination of these 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. Some nodes are accessed and managed with PubSub, whereas other nodes define MIX specific mechanisms for their use, as shown in the last two columns of the table.
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.
There are a number of MIX roles for each channel, listed in the following table. Rights will be assigned to the various roles in the channel configuration node.
</p>
<tablecaption="Channel Roles">
<tr><th>Role</th><th>Membership and Rights</th></tr>
<tr><td>Owners</td><td>These are owners of the channel, 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 they can control which users are allowed to participate in a channel. </td></tr>
<tr><td>Allowed</td><td>Allowed is the set of JIDs that are participants or are allowed to become participants. A JID is allowed if it does not match an entry in the banned node and either it matches an entry in the allowed node or the allowed node is not present. </td></tr>
There MUST always be at least one Owner. Administrators, Participants, and Allowed MAY NOT have any members. Rights are defined in a strictly hierarchical manner following the order of this table, so that for example Owners will always have rights that Administrators have.
Nodes MAY be archived and where this is done MAM MUST be used. Archiving of the Messages node MUST be done as part of the MIX specification. Archiving of other nodes is OPTIONAL.
The Messages node is used to distribute messages. The Messages node is a transient node and so no PubSub items are held. Messages MUST go to the associated MAM archive and history is retrieved by use of MAM. Users subscribe to this node to indicate that messages from the channel are to be sent to them. Private Messages are not distributed by the Messages node.
<p>Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the bare proxy JID of the participant. For example '123456#coven@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:1' namespace. The nick associated with the user is mandatory and is stored in a <nick/> child element of the <participant/> element. The nick for each channel participant MUST be different to the nick of other participants.
When a user joins a channel, the user's bare JID is added to the participants node by the MIX service. When a user leaves a channel, they are removed from the participants node. The participants node MUST NOT be directly modified using pubsub.
Users MAY subscribe to and read information this node, when permitted by the channel. Standard PubSub access will allow a full list of participants and associated nicks to be determined. By subscribing to the node, a user will be informed of changes to the Participants Node.
<p>The participants node is OPTIONAL. If the Participants Node is not used, information on channel participants is not shared. If there is no participants node, the access control value 'participants' MUST NOT be used. The Participants node is a permanent node with one item per participant.</p>
<p>The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap'. The JID Map node MUST have one entry for each entry in the Participants node. This value is added when a user joins the channel and is removed when the user leaves the channel.
Each item is identified by proxy bare JID, mapping to the real bare JID. This node is used to give administrator access to real JIDs and participant access to real JIDs in jid-visible channels. This node MUST NOT be modified directly using pubsub.
In JID Visible channels, all participants MAY subscribe to this node. In JID Hidden and JID Maybe Visible channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:1' namespace. The real JID is stored in a <jid/> child element of the <participant/> element. </p>
<p>The JID Maybe Visible Map node is a similar node to the JID Map node that is used in addition to the JID Map Node in JID Maybe Visible channels. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap-visible'. All participants may subscribe to and access this node. It uses the same encoding as JID Map node and all participant JIDs MUST be included. Where a participant's preference is to not share the JID, the encoded participant value is the proxy JID. This will enable a user looking up a JID to clearly determine that the user preference is to not share the JID and to clearly distinguish this case from an erroneous proxy JID.
The presence node contains the presence value for clients belonging to participants that choose to publish presence to the channel. A MIX channel MAY require that all participants publish presence. Each item in the presence node is identified by the full proxy JID, and contains the current presence value for that JID. The presence is encoded in the same way as data that would be sent in a presence stanza using a <presence/> element qualified by the 'jabber:client' namespace. The full proxy JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control MAY be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list.
This node MAY be subscribed to by users and this subscription MUST use the user's bare JID. So presence of online clients is sent to the user's server for each user subscribed to this node. Presence is always sent using standard presence protocol and NOT using pubsub protocol. Clients MUST NOT directly access the presence node using pubsub. The Presence node is a permanent PubSub node.
The information node is named by the date/time at which the item was created. The information node is accessed and managed using standard pubsub. The Information node is a permanent node with a maximum of one item. Users MAY subscribe to this node to receive information updates. The Information node item MAY contain the following attributes, each of which is OPTIONAL:
<tr><td>'Name'</td><td>A short string providing a name for the channel. For example "The Coven". Typical uses of this value will be to present a user with the name of this channel in a list of channels to select from or as the header of UI display of the channel. It is intended for use where a short string is needed to represent the channel.</td><td>text-single</td><td>-</td><td>-</td></tr>
<tr><td>'Description'</td><td>A longer description of the channel. For example "The Place where the Macbeth Witches Meet up". A typical use would be to provide a user with more information about the channel, for example in a tool tip.</td><td>text-single</td><td>-</td><td>-</td></tr>
<tr><td>'JID Visibility'</td><td>Specified JID visibility of the channel.</td><td>list-single</td><td>'jid-hidden'; 'jid-maybe-visible'; 'jid-visible'</td><td>'jid-hidden'</td></tr>
Name and Description of the channel apply to the whole channel and will usually be changed infrequently.
</p>
<p>
JID visibility is included in the Information Node as this is information that will be useful for participant clients and may also be important when choosing to join a channel.
<p>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 element. 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.
This node represents a list of JIDs that are allowed to become participants. If the Allowed node is not present, all JIDs are allowed. This node is accessed and managed using standard pubsub. 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 allowed to subscribe to this node. The Allowed node is a permanent node. Each item contains a real bare JID. The following example shows how the Allowed list can specify single JIDs and domains.
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. This node is accessed and managed using standard pubsub Only Administrators and Owners have write permission to the Banned node and are also the only roles that are allowed to subscribe to this node. Each item contains a real bare JID. The Banned node can contain bare JIDs and/or domains. The Banned node is a permanent node.
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. The Configuration node is a permanent node with a maximum of one item. Previous configuration history MAY be accessed by MAM. Users with read access to the configuration node MAY subscribe to the configuration node to get notification of configuration change. This node is accessed and managed using standard pubsub. 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. JIDs in the configuration MUST be real bare JIDs and not proxy JIDs. 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 attributes are defined:
<tr><td>'Owner'</td><td>Bare 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'; 'information'; 'allowed'; 'banned'; 'jidmap-visible'; 'avatar'</td><td>-</td></tr>
<tr><td>'Messages 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>'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>'Open Presence'</td><td>If selected, any client MAY register presence. If not selected, only clients with bare JID in the participants list are allowed to 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>'User Message Retraction'</td><td>If this option is selected users will be able to retract messages that they have 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 any message 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>'Private Messages'</td><td>If this option is selected, private messages MAY be used with the channel.</td><td>boolean</td><td>-</td><td>true</td></tr>
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.
The MIX standard allows channels to use non-standard nodes, using names that do no conflict with the standard nodes. Non-Standard nodes MUST NOT duplicate or otherwise provide capability that can be provided by standard nodes.
The MIX specification is built on layered services that have defined errors. This enables the core MIX specification to reflect primarily the successful use case, as in almost all cases the error reporting of the layer service provides what is needed. A message sender MUST be prepared to handle any valid error from the layer services. When a message receiver encounters an error situation, it MUST use the most appropriate layer server error to report this issue back to the sender. For example a receiving entity might use the "not authorized" error in response to a disco query that is not authorized. Errors for the following layer services need to be handled for MIX:
<li>Messages. If a message is received and an error situation is encountered, a message of type error MUST be sent back to the message sender. This message format is specified in &rfc6121; containing an error defined in &rfc6120;, which is the same error set as for IQs.</li>
<p>The MIX service then MUST return its identity and the features it supports, which MUST include the 'urn:xmpp:mix:1' feature, and the identity MUST have a category of 'conference' and a type of 'text', as shown in the following example: </p>
<li>'urn:xmpp:mix:1': This indicates support of MIX, and is returned by all MIX services.</li>
<li>'urn:xmpp:mix:1#searchable': This is shown in the above example and indicates that a the MIX Service MAY be searched for channels. This presence of this feature can be used by a client to guide the user to search for channels in a MIX service.</li>
<li>'urn:xmpp:mix:1#create-channel': This is described in <linkurl='#usecase-admin-check-create'> Checking for Permission to Create a Channel</link> in support of channel administration. When an end user client needs to create channels, perhaps for short term usage, this feature helps the client to identify an MIX service to use. It enables a configuration where permanent (searchable) channels are placed in one MIX service and clients will be able to create channels in another MIX service which is not searchable.</li>
<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>
<p>The list of channels supported by a MIX service is obtained by a disco#items command. The MIX service MUST only return channels that exist and that the user making the query has rights to subscribe to. </p>
<p>If the querying user is allowed to subscribe, 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 and results returned MUST include the attribute 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>Use disco#items to find the nodes associated with a channel. Discovering nodes in MIX MUST use the node='mix' attribute. The MIX service MUST only return nodes that exist and that the user making the query has rights to subscribe to. </p>
<p>The Information Node contains various information about the channel that can be useful to the user, that the client can access using PubSub, as shown below.</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, and in particular it facilitates the client's server to determine client support. This can be optimized by use of CAPS. The following example shows a Disco request to and response from a client that supports both MIX and MUC.
<p>A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to both messages and presence nodes. A user will typically subscribe to at least the message and/or presence nodes but MAY join and not subscribe to any nodes. The <join/> is a child element of <iq/> element. The <join/> element is qualified by the 'urn:xmpp:mix:1' namespace. The channel is specified by a 'channel' attribute in the <join/> element. The requested nodes are encoded as <subscribe/> child elements of the <join/> element.
The join leads to the server subscribing the user to each of the requested nodes associated with the channel. The MIX service will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.
<p>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>
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>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>
<examplecaption="Channel responds to User's Server"><