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 model group communication applications such as chatrooms, although with greater flexibility and extensibility than existing groupchat technologies such as Multi-User Chat (MUC). MIX supports standard groupchat features such as discussion topics and invitations, and defines a strong access control model similar to that of MUC. MIX also enables users to participate without sharing presence, allows communication of any structured data (not only textual messages). MIX uses Publish-Subscribe to provide flexible access and publication, and uses Message Archive Management (MAM) to provide storage and archiving. |
Authors: | Kevin Smith, Steve Kille, Peter Saint-Andre |
Copyright: | © 1999 - 2016 XMPP Standards Foundation. SEE LEGAL NOTICES. |
Status: | Experimental |
Type: | Standards Track |
Version: | 0.2.3 |
Last Updated: | 2016-09-01 |
WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.
1. Introduction
2. Requirements
3. Concepts
3.1. MIX and PubSub
3.2. MIX and MAM
3.3. Delivering Messages to Users
3.4. User Presence in MIX
3.5. Proxy JIDs and JID Visibility
3.6. Standard Nodes
3.6.1. Messages Node
3.6.2. Subject Node
3.6.3. Participants Node
3.6.4. JID Map Node
3.6.5. Presence Node
3.6.6. Configuration Node
3.6.7. ACL Node
4. Discovery
4.1. Discovering a MIX service
4.2. Discovering the Channels on a Service
4.3. Discovering Channel Information
4.4. Discovering Nodes at a Channel
4.5. Discovering Participants in a Channel
5. Use Cases
5.1. Common User Use Cases
5.1.1. Joining a Channel
5.1.2. User Preferences and Additional Information
5.1.3. Leaving a Channel
5.1.4. Setting a Nick
5.1.5. Registering a Nick
5.1.6. Setting User Presence
5.1.7. Coming Online: Obtaining Presence
5.1.8. Determining Real JIDs
5.1.9. Coming Online: Synchronizing Message History
5.1.10. Going Offline
5.1.11. Sending a Message
5.1.12. Retracting a Message
5.1.13. Inviting another user to join a Channel
5.1.14. Sending Private Messages
5.1.15. Requesting vCard
5.2. Use of MAM
5.3. Administrative Use Cases
5.3.1. Checking For Permission To Create a Channel
5.3.2. Creating a Channel
5.3.3. Creating a Channel for Ad Hoc User
5.3.4. Configuring a Channel
5.3.5. Destroying a Channel
5.3.6. Server Destroying a Channel
5.3.7. Modifying User Affiliations
5.3.8. Removing a User From a Channel (Kicking)
6. Capabilities not provided in MIX
6.1. Password Controlled Channels
6.2. Conversion from 1:1 Chat
6.3. Voice Control
7. Internationalization Considerations
8. Security Considerations
9. IANA Considerations
10. XMPP Registrar Considerations
11. XML Schema
12. Acknowledgements
Appendices
A: Document Information
B: Author Information
C: Legal Notices
D: Relation to XMPP
E: Discussion Venue
F: Requirements Conformance
G: Notes
H: Revision History
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 Multi-User Chat (XEP-0045) [1]. 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 kick and ban users, to name administrators, and to require membership in order to participate in channels.
Several reasons exist for replacing MUC:
Because it is anticipated that there will significant co-existence between MUC and MIX, this specification is designed so that:
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. The MIX service SHOULD include a reference to the MUC mirror, so that clients understanding both protocols can choose to show only one copy of the service.
The following concepts underlie the design of MIX.
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 Publish-Subscribe (XEP-0060) [9] domain. Like MUC, there is no requirement on the naming of these domains; the label 'mix' and the fact that it is a subdomain of a 'shakespeare.example' service are purely for example.
Every MIX channel is an addressable PubSub service (with additional MIX semantics) that will be addressed by an XMPP client using a bare JID, for example coven@mix.shakespeare.example. While Publish-Subscribe (XEP-0060) [10] 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 for many of the more common functions.
Message Archive Management is used for all storage of historical data (such as the history of messages sent within the channel). Each node can be archived separately (e.g., the presence node or the configuration node). MIX clients can retrieve archived information with MAM in order to quickly resync messages with regard to a channel, and may do so without providing presence information.
The primary 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. The user will receive messages from the channel and/or access channel presence from time to time with one or more clients.
Where a user has no clients active, the approach expected by MIX is that messages will be archived using MAM and that when clients come online they will use MAM to access messages that have not been delivered to the client. Following the rules of RFC 6121 [11], arriving MIX messages (which will be of type=groupchat) will be discarded if all clients are offline. Offline messages are not used with MIX.
Online clients are handled use Pubsub Account Management (XEP-0376) [12]. The model is that the server will know which of the user's clients are interested in MIX messages, possibly filtered by MIX channel, and will deliver messages appropriately to these clients. MIX will send messages to the user's server addressed with the bare JID of the user. The user's server will then deliver messages to the user's clients, in a manner that is transparent to the MIX server. The same approach is used for sending presence updates to the user, noting that presence information is distributed by a channel to the bare JID of subscribers and then the user's server will distribute to clients as appropriate.
MIX channels store presence in the presence node using the proxy JID of each online client for a user. User presence may be included for all or selected clients of a given user, based on client choice to publish presence. Where a user publishes presence for multiple clients, this information is available to all users subscribing to the channel presence. Queries such as disco requests will be directed to a specific client, routing through the MIX channel, while private messaging will be addressed to the user's bare proxy JID, and routed by the MIX to the user's bare real JID, where standard distribution rules will apply.
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.
MIX channels have two modes controlling JID visibility:
A channel member may specify their preferences for JID visibility, with one of the following values:
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 "<channel>+<generated identifier>@<mix domain>". 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.
The full JIDs held in presence 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' in the channel coven might have a proxy JID of 'coven+123456@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.
The standard nodes are as follows (although note that not every channel will necessarily use each node):
jidmap is the only node that will always be present for a MIX channel and all other nodes are optional. All channels will have either a message node, a presence node or both, because a channel will always share messages and/or presence. 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.
The structure of each of the standard nodes is now considered in more detail
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.
Private Messages are not stored in the messages node.
The subject node publishes the current subject of channel. Subject history is stored in MAM. A single item is stored in this node at a time which MUST contain a "text" element and MAY contain additional text elements. Where multiple text elements are provided, each MUST posess an xml:lang attribute that describes the natural language of the subject. Users subscribe to this node to receive subject updates. The following example shows the format of a item in the subject node.
<items node='urn:xmpp:mix:nodes:subject'> <item> <text xml:lang="en">How to use Toads</text> <text xml:lang="de">Wie benutzt man Kröten</text> </item> </items>
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 'coven+123456@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. The nick associated with the user is mandatory and is stored in the item. This node may be subscribed to for jid-visible channels that permit subscription to this node - this will allow users to see changes to channel membership.
<items node='urn:xmpp:mix:nodes:participants'> <item id='coven+123456@mix.shakespeare.example/8765'> <participant xmlns='urn:xmpp:mix:0' nick='thirdwitch'/> </item> </items>
The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. 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. In JID visible channels, all participants may subscribe to this node. In JID hidden channels, only administrators can subscribe.
<items node='urn:xmpp:mix:nodes:jidmap'> <item id='coven+123456@mix.shakespeare.example'> <participant xmlns='urn:xmpp:mix:0' jid='hecate@mix.shakespeare.example'/> </item> </items>
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. The full 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.
QUESTION: The current specification allows channels to be configured so that node subscription is not restricted to participants (although this restriction is the default). Is this flexibility desirable, or should we restrict to participants?
This node may be subscribed to by users using bare JID. So presence of online clients is sent to all users subscribed to this node, noting that presence is always sent using standard presence protocol.
<items node='urn:xmpp:mix:nodes:presence'> <item id='coven+123456@mix.shakespeare.example/8765'> <presence xmlns='jabber:client'> <show>dnd</show> <status>Making a Brew</status> </presence> </item> </items>
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 at a time, with previous configuration history accessed by MAM. Users subscribed to the configuration node will enable 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 provided:
TEMPORARY NOTE AND QUESTION: This is currently work in progress. Suggestions for other items to be included in configuration are welcome.
The format of the Configuration node follows Data Forms (XEP-0004) [13]. This allows configuration to be updated by MIX defined commands and that the results of update commands can be directly written to the PubSub node. Updates to the Configuration may use these commands or direct writing to the PubSub node.
<items node='urn:xmpp:mix:nodes:config'> <item id='2016-05-30T09:00:00' name='A Dark Cave'> *** TBS **** </item> </items>
The ACL node is closely related to the configuration node, and contains more information that will generally be more restricted as to who can access and modify. An anticipated configuration reflected in the defaults has ACL node configured so that it can be modified by channel owners and read only by channel owners and administrators. The default for the configuration node is update by owners or administrators and visibility to list members. Split of functionality has been made on the basis of this model.
TEMPORARY NOTE AND QUESTION: The split of configuration/acl is arbitrary. It would be possible to merge them, or to split into more nodes, giving finer control granularity. Input is solicited on the split an detailed assignment of items to nodes.
The ACL node holds access control related configuration of the channel as a single item, named by the date-time of the last update to the ACL. History MUST be set to 1. Previous ACL history is accessed by MAM. Users may subscribe to the ACL node if allowed using bare JID. The ACL node is optional for a MIX channel. For example, ACL choices could be fixed and not exposed. A subset of the defined ACL options may be used and additional non-standard ACL 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 ACL options are provided:
TEMPORARY NOTE: This is currently work in progress. Suggestions for other items to be included in ACL are welcome.
The format of the ACL node follows Data Forms (XEP-0004) [14].
<items node='urn:xmpp:mix:nodes:acl'> <item id='2016-05-30T09:00:00'> *** TBS **** </item> </items>
To determine if a domain hosts a MIX service, a Service Discovery (XEP-0030) [15] info query should be sent in the usual manner
<iq from='hag66@shakespeare.example/intibo24' id='lx09df27' to='mix.shakespeare.example' type='get'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq>
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'.
QUESTION: Is there a need for a different type than text? Provisional answer: no.
<iq from='mix.shakespeare.example' id='lx09df27' to='hag66@shakespeare.example/intibo24' type='result'> <query xmlns='http://jabber.org/protocol/disco#info'> <identity category='conference' name='Shakespearean Chat Service' type='text'/> <feature var='urn:xmpp:mix:0'/> <x xmlns='jabber:x:data' type='result'> <field var='FORM_TYPE' type='hidden'> <value>urn:xmpp:mix:0#serviceinfo</value> </field> <field var='muc-mirror' type='jid-single' label='Location of MUC mirror service'> <value>chat.shakespeare.example</value> </field> </x> </query> </iq>
The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'. If the MIX service is mirrored to a MUC service for backwards-compatibility, this SHOULD be signaled by the inclusion of field with var='muc-mirror', the value of which is the mirrored MUC domain's JID. Where a MIX server supports MIX channels as Multi-User Chat (XEP-0045) [16] rooms, the domain used for MUC may be different to the MIX domain or it MAY be the same.
Note that the MIX service doesn't advertise support for Message Archive Management (XEP-0313) [17], nor is support for generic Publish-Subscribe (XEP-0060) [18] advertised.
The list of channels supported by a MIX service is obtained by a disco command.
AUTHOR'S NOTE: This version contains a number of AUTHOR NOTES, which are reminder instructions to the author as to editing actions to be taken, and also indicate where changes are anticipated in future versions.
AUTHOR'S NOTE: Need to add example. This standard disco approach is going to replace the earlier proposed "urn:xmpp:mix:nodes:channels", unless there are objections.
In order to find out more information about a given channel, a user can send a disco#info query to the channel.
<iq from='hag66@shakespeare.lit/pda' id='ik3vs715' to='coven@mix.shakespeare.lit' type='get'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq>
The channel MUST return its identity and the features it supports:
<iq from='coven@mix.shakespeare.lit' id='ik3vs715' to='hag66@shakespeare.lit/pda' type='result'> <query xmlns='http://jabber.org/protocol/disco#info'> <identity category='conference' name='A Dark Cave' type='mix'/> <feature var='urn:xmpp:mix:0'/> </query> </iq>
Use disco#items to find the nodes associated with a channel. The MIX server MUST only return nodes that exist and that the user making the query has rights to subscribe to.
<iq from='hag66@shakespeare.lit/pda' id='kl2fax27' to='coven@mix.shakespeare.lit' type='get'> <query xmlns='http://jabber.org/protocol/disco#items'/> </iq>
<iq from='coven@mix.shakespeare.lit' id='kl2fax27' to='hag66@shakespeare.lit/pda' type='result'> <query xmlns='http://jabber.org/protocol/disco#items'> <item jid='coven@mix.shakespeare.example' node='urn:xmpp:mix:nodes:presence'/> <item jid='coven@mix.shakespeare.example' node='urn:xmpp:mix:nodes:participants'/> <item jid='coven@mix.shakespeare.example' node='urn:xmpp:mix:nodes:messages'/> <item jid='coven@mix.shakespeare.example' node='urn:xmpp:mix:nodes:subject'/> <item jid='coven@mix.shakespeare.example' node='urn:xmpp:mix:nodes:config'/> </query> </iq>
Online clients in the channel are determined from the presence node. Participants in the channel are determined from the "urn:xmpp:mix:nodes:participants" node which will give proxy JID and nick. The jidmap node is used to map to real JIDs.
AUTHOR'S NOTE: Add example
A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to messages, presence and subject. This will lead to the server subscribing the user to each of the requested nodes associated with the channel. The MIX server will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.
The default MIX model is that only channel participants may subscribe to nodes. A MIX channel MAY allow non-participant subscription. This will be handled by clients directly subscribing to the desired PubSub nodes.
<iq type='set' from='hag66@shakespeare.example/pda' to='coven@mix.shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> <join xmlns='urn:xmpp:mix:0'> <subscribe node='urn:xmpp:mix:nodes:messages'/> <subscribe node='urn:xmpp:mix:nodes:presence'/> <subscribe node='urn:xmpp:mix:nodes:participants'/> <subscribe node='urn:xmpp:mix:nodes:subject'/> <subscribe node='urn:xmpp:mix:nodes:config'/> </join> </iq>
The channel must process the join atomically. The channel responds with an IQ-result. This stanza includes the nodes to which the user has been successfully subscribed, as well as the bare JID that will be used for the user in this channel and added to the participant list. 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, and 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. A user may subsequently request subscription to nodes in a channel to which the user was not initially subscribed.
<iq type='result' from='coven@mix.shakespeare.example' to='hag66@shakespeare.example/pda' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> <join xmlns='urn:xmpp:mix:0' jid='hag66@shakespeare.example'> <subscribe node='urn:xmpp:mix:nodes:messages'/> <subscribe node='urn:xmpp:mix:nodes:presence'/> <subscribe node='urn:xmpp:mix:nodes:participants'/> <subscribe node='urn:xmpp:mix:nodes:subject'/> <subscribe node='urn:xmpp:mix:nodes:config'/> </join> </iq>
As noted, the participant might not be subscribed to all nodes associated with the channel (in this case only messages, participants, and subject).
<iq type='result' from='hag66@shakespeare.example/pda' to='coven@mix.shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> <join xmlns='urn:xmpp:mix:0' jid='hag66@shakespeare.example'> <subscribe node='urn:xmpp:mix:nodes:messages'/> <subscribe node='urn:xmpp:mix:nodes:participants'/> <subscribe node='urn:xmpp:mix:nodes:subject'/> </join> </iq>
The channel also adds the user to the participants node and sends a notification.
<message from='coven@mix.shakespeare.example' to='hecate@shakespeare.example' id='5A9C7398-DB13-4BFA-A091-2D466C710AAF'> <event xmlns='http://jabber.org/protocol/pubsub#event'> <items node='urn:xmpp:mix:nodes:participants'> <item id='coven+123456@mix.shakespeare.example'> <participant xmlns='urn:xmpp:mix:0' nick='thirdwitch'/> </item> </items> </event> </message>
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 <participant> element will include the nick of the user being added, which will be how the user will typically be shown in the channel.
Following the MIX server side processing, the user's server will usually add the MIX channel to the user's roster using one way presence. This means that the MIX channel will get presence information from the user. This roster entry will lead to correct handling of the user's presence in the MIX channel. If the user does not wish to publish presence and the channel permits this, then this roster addition does not happen. If the channel requires presence and the user removes the channel from the user's roster, the channel MAY remove the user as a channel participant.
A channel may store additional user preferences and parameters. Where the channel requires a value to be explicitly a Data Forms (XEP-0004) [19] form will be returned in response to the join request with mandatory and optional fields. If parameters are optional, the user may request to set them.
}Xao6\ _ vE,iѠ]S$}%"I1;R8bw{wq}ŋnd}4)UA3yiwU_FJ]/VޱUħjr|.&_RY90^=yտ !TǗmc]Ǖ~|T}\:oZۥ 6qtX\ɅtN\jWv&l CX$0pY|3!.TMCXjEWoܪq6+Bc, tmߕ49@BS Zl5VLcycyR>ƕ9 VKMEVJ>aVJ`mc7s>RtetY)$.:(ieb]Ɇ Q~ѷd4&3/7+ Jm&ofZ7gXN^c#Hq`Ɣd(K[x-r82TbkG~7H!*סs"Λb<{qG](V4koZ{; 2*Gkƺ{^rV'6HW i-`ch'+H3ʺ7gbaA].7g1|=XܳMt}w73+Kz+xJ6*Da wZB':LSH̗CCDq>h +GΓ8d}|Fs0˱a0u%dlI$H+ O*ɑDŽdߠ TyO(=Aƈ5mJJBK9#%g`ـ}| ǡ {hCS"-9eJpwi#)SnGs]*8"s>/jvlK YmC=?;QCϪЛP0SWrJYN]yYߨS CyQrԉ8yl T@?!SA^6 ԠW6xx"j@q%H3Y"čkhnEV t*" 5&J &LdoI{fqG}P-$W4R8Ծ<:j\84_+;f8 "˃ + ADAih o4s4Ett߄Zץ~Drˎ܍hG%@O0Q1\N3\B~dฑ Cu£'4sb?L ;W]fMYzZcgDt Uqw_z{2Dv:A.h_C.Xr==͞ں~,LGhze~Wn@̲]kX $PmGj@pl*жteG/770?_@ T]q4i贯5֫/FPal+H,oyޠyza LvgMqEeC+rK%-pagI,S*aq}N+RzV6