<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>
<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>
<p>MIX is specified as a family of XEPs that address the full set of requirements. Only two of these XEPs are mandatory for providing a MIX service. The others provide additional services and are used when these additional services are required. Each of these specifications has a short name, which is used to refer the specific XEP. The term MIX is used to refer to the family of XEPs. MIX is extensible, and it is anticipated that further XEPs will be added to this family. The XEPs are: </p>
<li>MIX-CORE. &xep0369;. This specification is the central mandatory MIX specification. It sets out requirements addressed by MIX and general MIX concepts and framework. It defines joining channels and associated participant management. It defines discovery and sharing of MIX channels and information about them. It defines use of MIX to share messages with channel participants. </li>
<li>MIX-PRESENCE. &xep0403;. This optional specification adds the ability for MIX online clients to share presence, so that this can be seen by other MIX clients. It also specifies relay of IQ stanzas through a channel.</li>
<li>MIX-PAM. &xep0405;. This specification defines how a server supporting MIX clients behaves, to support servers implementing MIX-CORE and MIX-PRESENCE.</li>
<li>MIX-ANON. &xep0404;. This specifies a mechanism to hide real JIDs from MIX clients and related privacy controls. It also specifies private messages. </li>
<li>RELIABLE-DELIVERY. MIX-CORE needs messages to be distributed without loss. This specification is important for MIX, but may be useful in other places.</li>
The following table shows which of these specification is mandatory or optional for a MIX server, a server supporting MIX users, a general purpose end user client, and a client providing MIX channel administration.
</p>
<tablecaption="Optional/Mandatory Status of the MIX Specifications">
<tr><th>Specification</th><th>MIX Server</th><th>Server supporting MIX Clients</th><th>End User MIX Client</th><th>Administrative MIX Client</th></tr>
<section2topic="Comparsion to MUC"anchor="concepts-muc-comparison">
<p>
This section is written as an introduction to MIX for those with detailed knowledge of &xep0045;, to summarize key differences and some rationale for the differences. For those unfamiliar with MUC, this section should be ignored.
</p>
<p>
In MUC, a client joins a MUC room. After this, the client is sent history information, presences, and messages until the client leaves the room by going offline. Key MIX features as summarized below:
</p>
<ol>
<li>MIX has "channels", which are equivalent to MUC rooms.</li>
<li>MIX separates out various services, in particular messages and presence. A MIX channel is implemented as a set of PubSub nodes, and a user (not client) can subscribe to a set of nodes. This control means that users can subscribe to presence and/or messages, which gives useful flexibility. This addresses requirements 3 and 5. Subscribing to message and presence nodes gives a service broadly equivalent to MUC.</li>
<li>Users join MIX channels for an extended period and participation is not impacted by clients going online and offline (requirement 1). This means that a MIX client uses channel subscriptions as negotiated by the MIX user.</li>
<li>MIX messages and presence are always sent and are addressed to the user (bare JID). This addressing is a consequence of users (not clients) being the participants in a MIX channel; It is a key difference between MUC and MIX. This addressing change means that the user's server needs to have MIX-specific behaviour to correctly distribute arriving messages and presence appropriately to MIX clients; there may be zero or more online clients that support MIX. This server behaviour is specified by MIX. </li>
<li>MIX messages are archived using MAM on the user's server. This enables flexible access to channel history, independent of the MIX channel server. </li>
<li>A user's roster contains the MIX channels to which the user is subscribed. A client can use a MIX roster extension to determine which MIX channels the user is subscribed to. When a client comes online, this will lead to directed presence for the client to be sent to each MIX channel. A MIX channel can then share the user's presence with channel participants that have subscribed to the presence. The MIX channel will also return to the client a full list of presence information for the channel. This means that when a client comes online, it will receive presence updates for the participants in all subscribed MIX channels.</li>
MIX will enable a wide range of auxiliary services. The goal of the MIX family of specification is to set out the core capabilities needed for MIX. It is anticipated that additional XEPs will be written to extend the current MIX specification, and the MIX specification family notes some areas where this may happen. 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:info' 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 has a Stable Participant ID. This is used in some derived JIDs to provide a stable participant reference. It is used to hide JIDs in MIX-ANON.
<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 service based on PubSub (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>
Every channel participant is identified by a Stable Participant ID, which uniquely identifies a channel participant and never changes. The Stable Participant ID MUST NOT contain the '#', '/' or '@' characters.
A Participant's Stable Participant ID is defined when a participant joins a channel. While a user is a participant in a Channel, the Stable Participant ID MUST NOT be changed. This mapping between Participant and Stable Participant ID MUST be maintained after the participant leaves the channel. Stable Participant ID values MUST NOT be re-used. If a participant that left a channel joins the channel again, the same Stable Participant ID MAY be used again or a different Stable Participant ID MAY be assigned.
<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>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>
Participants is the only mandatory MIX node for a channel, which defines the set of clients that have joined the channel. All other nodes are OPTIONAL.
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.
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-CORE 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 Stable Participant ID of the participant. For example '123456' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:core:1' namespace.
A Nick MAY be associated with a participant, which provides a user-oriented description of the participant. The nick associated with the user 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 (where nicks have been assigned).
</p>
<p>
A channel MAY require nicks to be mandatory for all participants. This is the default behaviour, and nicks MUST only be optional when this is explicitly configured for a channel as specified in MIX-ADMIN.
Where a nick is provided for a user, it is generally recommended to use this nick to display the user. This enables consistent representation of participants for all participants in the channel.
The real JID of the user MAY be held in the participants node. When the real JID is not present, the procedures defined in MIX-ANON must be followed. Note that only the real JID may be held in participants node. Any JID derived from the stable ID MUST NOT be held.
When a user joins a channel, an item representing the user is added to the participants node by the MIX service. When a user leaves a channel, the user's item is removed from the participants node. The participants node MUST NOT be directly modified using pubsub.
It may be useful for clients to read the participants list. However it is not necessary for message and presence display, as both messages and presence contain sufficient information to enable display.
Users MAY subscribe to, and read information from 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 Information node holds information about the channel. It will often be helpful for MIX clients to be able to display this information. The information node contains a single item with the current information.
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>
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. 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 MIX standard allows channels to use non-standard nodes, using names that do not 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:core:1' feature, and the identity MUST have a category of 'conference' and a type of 'mix', as shown in the following example: </p>
<li>'urn:xmpp:mix:core:1#searchable': This is shown in the above example and indicates that a the MIX Service MAY be searched for channels. The 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:core: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 a 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. </p>
<p>Note that a node MAY be both a MIX channel and a MUC room. In this case, the node will return both MIX and MUC information. MIX and MUC clients MUST be able to handle this.</p>
<p>Use disco#items to find the nodes associated with a channel. The MIX service MUST only return nodes that exist and that the user making the query has rights to subscribe to. </p>
<p>
Discovering nodes in MIX MUST use a node='mix' attribute in this query. This is to facilitate server implementations that support a single node being both a MIX channel and a MUC room. MUC rooms use this query to return a list of occupants. The node='mix' attribute allows a server to support both MIX and MUC queries without requiring any change to MUC clients. Where a node only supports a MIX channel, the server MUST reject queries without a node='mix' attribute.
<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.
MIX Join and Leave communication goes through the clients server. The full specification of client interaction with the client's server is specified in MIX-PAM. This specification shows the protocol between the user's server and the MIX server and sets out behaviour of the MIX server.
<p>A user joins a channel by sending a MIX "join" command from one of the user's clients, which will be relayed to the server as specified in MIX-PAM. 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. Note that the presence node is specified in MIX-PRESENCE. The <join/> is a child element of <iq/> element. The <join/> element is qualified by the 'urn:xmpp:mix:core:1' namespace. The requested nodes are encoded as <subscribe/> child elements of the <join/> element. A nick MAY be specified as a <nick/> child elements of the <join/> element. </p>
<p>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>
<p>The default MIX model is that only channel participants are allowed to subscribe to nodes. A MIX channel MAY allow non-participant subscription to some nodes. This will be handled by clients directly subscribing to the desired PubSub nodes.</p>
<p>The user's server needs to make roster changes as part of the join functionality, as specified in MIX-PAM. This means that the join request to the MIX service will come from the user's server from the user's bare JID.</p>
<p>The channel responds to the user's sever with an IQ-result addressed to the user's bare JID, which will be processed as specified in MIX-PAM. 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 user's Stable Participant ID is returned as an 'id' attribute in the join.
The following example shows the result of the above request when the request is completed in full. </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 at least one node is requested and 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 error response will also include other nodes requested where subscription failed for the same reason. </p>
the participant is not subscribed to all nodes associated with the channel (in this case only messages, participants, and information). This example shows the message from the MIX channel to the user's server.
adds the user to the participants node. When these changes are made, the MIX channel MUST send a PubSub notification of the change to subscribers of the participants node. The following example shows such a notification.</p>
<p>The user that has been added to the channel is identified by the item id of the item added to the Participants node, which is the Stable Participant ID of the new channel participant. The <participant> element MUST include a <jid> element with the JID of the participant, unless MIX-ANON is being followed to hide participant JIDs. The <nick> element will not be included at this point, unless it is automatically generated by the channel. In the likely event that a Nick is subsequently added, an update with the <nick> element will be distributed.
A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a <update-subscription/> child element of <iq/> element. The <update-subscription/> element is qualified by the 'urn:xmpp:mix:core:1' namespace. The requested nodes are encoded as <subscribe/> and <unsubscribe/> child elements of the <update-subscription/> element with the node name encoded as a 'node' attribute. This modification goes directly from client to the MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification.
A user MAY specify a nick when joining the channel. Channels MAY have mandatory nicks, which is default behavior. Therefore it will generally be necessary to include a nick when joining an channel. If nick is missing on a channel where nick is mandatory, the join MUST be rejected. Other error cases are dealt with below with the nick management commands. Where a nick is specified, the join will only complete if the nick is accepted. The nick used MUST be reported back in the join result.
<p>Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, the user's server sends a MIX "leave" command to the channel, as specified in MIX-PAM. The leave command is encoded as a <leave/> child element of <iq/> element. The <leave/> element is qualified by the 'urn:xmpp:mix:core:1' namespace. The following example shows a leave request to a MIX channel. </p>
<p>When the user leaves the channel, the MIX service is responsible for unsubscribing the user from all nodes in the channel and for removing the user from the participants list. Presence removal is specified in MIX-PRESENCE.
Deletion from the participants node functions as if the item (channel participant) had been deleted using the PubSub retract mechanism with notification set to true. Notification of the participant deletion is sent to clients subscribed to the participants PubSub node using PubSub protocol, with the node identified by the stable id, as shown in the example below.
</p>
<examplecaption="Participant Node Subscriber is Notified of Participant Removal"><