XEP-0369: Mediated Information eXchange (MIX)

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.
Authors:Kevin Smith, Steve Kille, Peter Saint-Andre
Copyright:© 1999 - 2016 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:Experimental
Type:Standards Track
Version:0.4
Last Updated:2016-09-21

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.


Table of Contents


1. Introduction
2. Requirements
3. Concepts
    3.1. MIX and PubSub
    3.2. MIX and MAM
    3.3. MIX Proxy
    3.4. User Presence in MIX
    3.5. Private Messages
    3.6. Proxy JIDs and JID Visibility
    3.7. Standard Nodes
       3.7.1. Roles
       3.7.2. Messages Node
       3.7.3. Subject Node
       3.7.4. Participants Node
       3.7.5. JID Map Node
       3.7.6. Presence Node
       3.7.7. Information Node
       3.7.8. Allowed
       3.7.9. Banned
       3.7.10. Configuration Node
    3.8. Non-Standard Nodes
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. Determining Information about a Channel
    4.6. Determining the Participants in a Channel
    4.7. Discovering Client MIX Capability
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. Setting the Channel Subject
       5.1.14. Telling another User about a Channel
       5.1.15. Inviting another User to join a Channel that the user does not have Permission to Join
       5.1.16. Sending Private Messages
       5.1.17. 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. Supporting MIX and MUC together
    6.1. Choosing Which Invite to Send
7. Capabilities not provided in MIX
    7.1. Password Controlled Channels
    7.2. Conversion from 1:1 Chat
    7.3. Voice Control
8. Internationalization Considerations
9. Security Considerations
10. IANA Considerations
11. XMPP Registrar Considerations
12. XML Schema
13. 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


1. Introduction

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 provide controls as to which users can 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.

2. Requirements

The following requirements have been identified, which MIX aims to address.

  1. A user's participation in a channel persists and is not modified by the user's client going online and offline.
  2. Multiple devices associated with the same account can share the same nick in the channel, with well-defined rules making each client individually addressable.
  3. Channels are not required to support or reflect presence for participants.
  4. A reconnecting client can quickly resync with respect to messages and presence.
  5. A user may (subject to configuration) receive messages from a channel as an invisible observer.
  6. Configuration can be observed externally to the channel (e.g., list of participants, access control rights, etc.).
  7. MIX services should provide mechanisms to prevent JIDs from being harvested.
  8. MIX and Message Archive Management (MAM) should work well together.
  9. A user can determine which channels they participate in.
  10. 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.
  11. Enable federation of a channel across multiple servers, to provide a service equivalent to "federated MUC" Federated MUC for Constrained Environments (XEP-0289) [5].
  12. To enable sharing of messages on a channel without requiring sharing of presence.
  13. To enable sharing of presence without requiring message sending.
  14. (Desirable) Make it easier to reduce duplicate traffic.

3. Concepts

The following concepts underlie the design of MIX.

  1. 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 Service Discovery (XEP-0030) [6]. Each channel on a MIX service may then be discovered and queried.
  2. In MIX each channel (e.g., 'channel@mix.example.com') is a pubsub service. This is based on the model from Personal Eventing Protocol (XEP-0163) [7] where every user JID (e.g., 'user@example.com') is its own pubsub service.
  3. 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.
  4. 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.
  5. Message Archive Management (XEP-0313) [8] (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).
  6. 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 old MUC issue of either receiving duplicate messages when rejoining a room or potentially missing messages.
  7. 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:subject' would store their current values (with older values being queryable through MAM), while 'urn:xmpp:mix:nodes:messages' would store no items.
  8. 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.
  9. Presence is sent to all participants using bare JID, whether or not the user has an online client.
  10. Online clients MAY register presence, which is then shared with participants who have subscribed to presence.
  11. MIX decouples addressing of channel participants from their nicknames, so that nickname changes do not affect addressing.
  12. 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.
  13. MIX requires client support and server support from the server providing the MIX service. Although some protocol is shared with MUC, MUC clients are not interoperable with MIX servers. This means that where a user chooses to use MIX, all of the users clients need to support MIX.

3.1 MIX and PubSub

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 using a bare JID by other XMPP entities, 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 protocol for many of the more common functions.

3.2 MIX and MAM

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 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.

3.3 MIX Proxy

A MIX channel does not send messages and presence directly to an XMPP MIX client. Instead it sends them to a MIX Proxy, which runs on the server which a MIX client accesses. MIX clients MUST make use of a MIX Proxy. Use of a MIX proxy enables flexible support of multiple clients for an XMPP user. 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 MIX channel will send messages and presences to the MIX Proxy using the bare JID. The MIX Proxy will then send the messages and presence information to zero or more clients. The MIX Proxy provides a number of functions.

  1. Each MIX client will register with the MIX Proxy when it comes online. A key benefit of this approach is that MIX messages will only be sent to clients that support MIX. This enables use of clients that do not use MIX in conjunction with the MIX proxy.
  2. MIX Service and Channel subscription and management is handled through the MIX proxy so that the MIX Proxy can track all subscription changes and share subscription information between MIX clients. To achieve this, a MIX client sends these MIX management queries to the MIX Proxy using the clients full JID and receives responses back from the MIX Proxy. The MIX Proxy will communicate these requests to a MIX channel from the MIX using the user's bare JID. Because the MIX Proxy is aware of subscription information, it can provide integrated support to a set of MIX clients.
  3. Messages from a MIX client to a MIX channel will go direct to the MIX service and not through the MIX Proxy.
  4. Messages from a MIX channel to a MIX client MUST be handled by a MIX Proxy.
  5. The MIX Proxy will only send messages to online clients and will discard messages if no clients are online. This means that a MIX client needs to resynchronize with the MIX service when it comes online. This synchronization will happen directly between the MIX client and MIX channel.
  6. The MIX Proxy will know which channels are subscribed to, and so can send this list to a MIX client. Because channel subscriptions are long term, this information will be used instead of the bookmark approach used with MUC.
  7. The MIX Proxy will manage channel registration and de-registration in the user's roster.
  8. Different clients may wish to access different channels (e.g., a mobile client may only access a subset of the channels in which a user is interested). The MIX Proxy MAY handle sending messages only to the clients that wish for them, perhaps using a profile mechanism.

Messages being sent from MIX channel to MIX Proxy (which will be of type=groupchat) and presence information are sent to the bare JID. This means that the MIX Proxy will use a modification of the standard RFC 6121 [11] rules.

The MIX standard specifies how the MIX channel interacts directly with XMPP clients and with the MIX Proxy.

The behaviour of a MIX Proxy and the protocol between MIX Proxy and MIX Client is not currently defined in this specification. It will be defined in one of three places. It may be desirable in some situations to provide different service to different clients. For example, a mobile client may participate in a smaller set of MIX channels than a desktop client. This needs support from the server to which the client connects, so that MIX client and the connected server can negotiate which channels to send. This is not supported by the core MIX specification, but it is anticipated that this will be supported by another specification.

  1. In an extension to Pubsub Account Management (XEP-0376) [12] (PAM) which follows a model close to MIX Proxy; or
  2. In a new XEP specifically to defined MIX Proxy behavior; or
  3. As a new section in a future version of the MIX Specification.

QUESTION: Input is sought on the best place to standardize MIX Proxy.

3.4 User Presence in MIX

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.

External XMPP entities can direct stanzas to clients publishing their presence by sending them to the appropriate full proxy JID 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.

3.5 Private Messages

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.

Private messages MAY also be sent to specific clients identified by the full proxy JID of the client in the participants list, if allowed by channel policy.

3.6 Proxy JIDs and JID Visibility

MIX channels have two modes controlling JID visibility:

Table 1: JID Visibility Modes

ModeDescription
'JID Visible'In these channels, some or all participant JIDs are visible to all channel participants.
'JID Hidden'In these channels, no participant JIDs are visible to channel participants, but they are visible to channel administrators.

A channel participant may specify their preferences for JID visibility, with one of the following values:

Table 2: JID Visibility Preference Options

PreferenceDescription
'No JID Visibility Preference'The users JID will be visible in JID Visible channels and hidden in JID Hidden channels.
'Prefer Hidden'The user's JID will be hidden in JID Visible channels if the channel policy allows this.
'Enforce Hidden'The user's JID will never be shown and the user will be removed from channel if channel administrator enforces visibility.
'Enforce Visible'The users JID will always be shown and the user will be removed from channel if mode is changed to 'JID Hidden'.

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>". They generated identifier MUST NOT contain the '+' characters. The Channel name MAY contain the '+' character. For example in the channel 'coven@mix.shakespeare.example', the user 'hag66@shakespeare.example' might have a proxy JID of 'coven+123456@mix.shakespeare.example'. The reason for the proxy JID is to support JID Hidden channels. Proxy JIDs are also used in JID Visible channels, for consistency and to enable switching of JID visibility. The "urn:xmpp:mix:nodes:jidmap" node maps from proxy JID to real JID. While a user is a participant in a Channel, the mapping between real JID and proxy JID MUST NOT be changed,

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' 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. While an anonymized JID is held in the presence node, the mapping to real JID MUST NOT be changed. When an anonoymized full JID is added to the presence node, mapping to a real full JID that was previously in the presence node, the same anonymized JID as the previous time MAY be used or a different anonymized JID MAY be used.

3.7 Standard Nodes

The standard nodes are as follows (although note that not every channel will necessarily use each node):

Table 3: Standard Nodes

NameNodeDescription
Messages'urn:xmpp:mix:nodes:messages'For publishing messages. Each item of this node will contain a message sent to the channel.
Subject'urn:xmpp:mix:nodes:subject'For publishing the subject of the channels
Participants'urn:xmpp:mix:nodes:participants'For publishing the list of participants (identified by anonymized bare proxy JID), and identifying the nick. This is a list of users who would receive messages (by subscription to the messages node) and/or would receive presence (by subscription to the presence node).
JID Map'urn:xmpp:mix:nodes:jidmap'For publishing a list of anonymized bare JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs.
Presence'urn:xmpp:mix:nodes:presence'For publishing information about the availability status of online participants, which may include multiple clients for a single participant.
Information'urn:xmpp:mix:nodes:info'For storing general channel information, such as description and avatar.
Allowed'urn:xmpp:mix:nodes:allowed'For storing JIDs that are allowed to be channel participants.
Banned'urn:xmpp:mix:nodes:banned'For storing JIDs that are not allowed to be channel participants.
Configuration'urn:xmpp:mix:nodes:config'For storing channel configuration. This information will generally be restricted to the channel owners.

All of the standard nodes are optional. A channel providing a service similar to MUC will typically use all of the standard nodes. MIX provides mechanisms to allow users to conveniently subscribe to a chosen set of nodes and to unsubscribe to all nodes with a single operation.

The structure of each of the standard nodes is now considered in more detail in the rest of this section, after explaining roles.

3.7.1 Roles

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.

Table 4: Channel Roles

RoleMembership and Rights
OwnersThese are owners of the list, as specified in the channel configuration node. Only owners are allowed to modify the channel configuration node.
AdministratorsAdministrators are defined in the channel configuration node. Administrators have update rights to the Allowed Node and Banned Node, so can control which users may participate in a channel. Administrators will usually be granted additional rights, such as the ability to kick users from a channel.
ParticipantsParticipants are users listed by JID in the participants node.
AllowedAllowed is the set of JIDs that are participants or may be allowed to become participants. A JID is allowed if it does not match entry in the banned node and either it matches an entry in the allowed node or the allowed node is not present.
AnyoneAny user, including users in the banned node.

There will always be at lease one owner and "anyone" will always have role occupants. Other roles may not have any role occupants. Rights are defined in a strictly hierarchical manner, so that for example Owners will always have rights that Administrators have.

3.7.2 Messages Node

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.

3.7.3 Subject 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 posses an xml:lang attribute that describes the natural language of the subject. The following example shows the format of a item in the subject node.

Example 1. 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>

When a user subscribes to the Subject Node, this will cause the channel to send Subject messages to the user through the MIX Proxy. This is done on initial user subscription and on subject change. Clients MAY directly read the channel subject from the Subject Node using PubSub.

3.7.4 Participants Node

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. The nick for each channel participant MUST be different to the nick of other participants. This node MAY be subscribed to for jid-visible channels that permit subscription to this node - this will allow users to see changes to the channel participants.

If the Participants Node is not used, information on channel participants is not shared.

Example 2. Value of Participants Node

<items node='urn:xmpp:mix:nodes:participants'>
  <item id='coven+123456@mix.shakespeare.example'>
    <participant xmlns='urn:xmpp:mix:0'
                 nick='thirdwitch'/>
  </item>
</items>

3.7.5 JID Map Node

The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. The JID Map node MUST have one entry for each entry in the Participants node. 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.

Example 3. Value of JID Map Node

<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>

3.7.6 Presence Node

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.

This node may be subscribed to by users and this subscription MUST use the users bare JID. So presence of online clients is sent to the MIX Proxy for each user subscribed to this node. Presence is always sent using standard presence protocol.

Example 4. Value of Presence Node

<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>

3.7.7 Information Node

The Information node holds information about the channel. The information node is named by the name of the node, which must be present. Other elements of the information node are optional. Information history is stored in MAM. The name and description values MUST contain a "text" element and MAY contain additional text elements. Where multiple text elements are provided, each MUST posses an xml:lang attribute that describes the natural language of the subject. Users MAY subscribe to this node to receive information updates. The Information node has the following attributes:

The format of the Information node follows Data Forms (XEP-0004) [15]. 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. The following example shows the format of a item in the information node for the example coven@mix.shakespeare.example channel.

Example 5. Information Node

<items node='urn:xmpp:mix:nodes:info'>
  <item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:0'>
        <name>Witches Coven</name>
        <description>A location not far from the blasted heath where the three witches meet</description>
        <administrator>
           <vCard xmlns='vcard-temp'>
              <FN>Hecate</FN>
              <TITLE>Chief Witch</TITLE>
           </vCard>
        </administrator>
        <avatar>
             <data xmlns='urn:xmpp:avatar:data'>
          qANQR1DBwU4DX7jmYZnncm...
            </data>
        </avatar>
  </item>
</items>

3.7.8 Allowed

This node represents a list of JIDs that are allowed to become participants. If the allowed node is not present, all JIDs are allowed. The allowed list is always considered in conjunction with the banned list, stored in the banned node. Only Administrators and Owners have write permission to the allowed node and are also the only roles that are allows to subscribe to this node. Each item contains a real bare JID. The following example shows how the allowed list can specify single JIDs and domains.

Example 6. Allowed Node

<items node='urn:xmpp:mix:nodes:allowed'>
  <item id='@shakespeare.lit'>
  <item id='alice@wonderland.lit'>
  </item>
</items>

3.7.9 Banned

This node represents a list of JIDs that are explicitly not allowed to become participants. The values in this list take priority over values in the allowed node. Only Administrators and Owners have write permission to the allowed node and are also the only roles that are allows to subscribe to this node. Each item contains a real bare JID.

Example 7. Banned Node

<items node='urn:xmpp:mix:nodes:banned'>
  <item id='lear@shakespeare.lit'>
  <item id='macbeth@shakespeare.lit'>
  </item>
</items>

3.7.10 Configuration 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. A single item is stored in the node at a time, with previous configuration history accessed by MAM. Users MAY subscribe to the configuration node to get notification of configuration change. The configuration node is optional for a MIX channel. For example, configuration choices could be fixed and not exposed. A subset of the defined configuration options may be used and additional non-standard configuration options may be added. If configuration options to control functionality of the nature described here are provided, the options defined in this standard MUST be used. The following configuration options are provided:

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 AND QUESTION: Detailed review of this section is solicited, and requirements for any additional configuration control.

The format of the ACL node follows Data Forms (XEP-0004) [17].

Example 8. Configuration Node

<items node='urn:xmpp:mix:nodes:config'>
  <item id='2016-05-30T09:00:00'>
    *** TBS ****
  </item>
</items>

3.8 Non-Standard Nodes

The MIX standard allows channels to use non-standard nodes, using names that do no conflict with the standard nodes. The capabilities of these nodes may be specified in a future XEP or be for private agreement. Non-Standard nodes MUST NOT duplicate or otherwise provide capability that can be provided by standard nodes.

4. Discovery

4.1 Discovering a MIX service

To determine if a domain hosts a MIX service, a Service Discovery (XEP-0030) [18] info query should be sent in the usual manner

Example 9. Entity queries a service

<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'.

Example 10. Service responds with Disco Info result

<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>
  </query>
</iq>

The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'.

A MIX service MUST NOT advertise support for Message Archive Management (XEP-0313) [19], as MAM is supported by the channels and not by the service. A MIX service MUST NOT advertise support for generic Publish-Subscribe (XEP-0060) [20], as although MIX makes use of PubSub it is not a generic PubSub service.

4.2 Discovering the Channels on a Service

The list of channels supported by a MIX service is obtained by a disco#items command. The MIX server MUST only return channel that exist and that the user making the query has rights to subscribe to. This query MAY be made directly by and XMPP client or by a MIX Proxy.

Example 11. MIX Proxy Queries for Channels on MIX Service

<iq from='hag66@shakespeare.lit'
    id='kl2fax27'
    to='mix.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>

Example 12. MIX Service Returns Disco Items Result

<iq from='mix.shakespeare.lit'
    id='kl2fax27'
    to='hag66@shakespeare.lit'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='coven@mix.shakespeare.example' />
    <item jid='spells@mix.shakespeare.example' />
    <item jid='wizards@mix.shakespeare.example' />
  </query>
</iq>

4.3 Discovering Channel Information

In order to find out more information about a given channel, a user can send a disco#info query to the channel. This query MUST be made by a MIX Proxy and not the end client.

Example 13. Entity Queries for Information about a Specific Channel

<iq from='hag66@shakespeare.lit'
    id='ik3vs715'
    to='coven@mix.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

Note that this query comes from the bare JID to the MIX channel, as it will always be sent to the MIX service by a MIX proxy. 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.

Example 14. Channel Returns Disco Info Result

<iq from='coven@mix.shakespeare.lit'
    id='ik3vs715'
    to='hag66@shakespeare.lit'
    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'/>
    <feature var='urn:xmpp:mam:1'/>
  </query>
</iq>

4.4 Discovering Nodes at a Channel

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. This query MUST be made by a MIX Proxy and not the end client.

Example 15. Entity Queries for Nodes at a Channel

<iq from='hag66@shakespeare.lit'
    id='kl2fax27'
    to='coven@mix.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>

Example 16. Channel Returns Disco Items Result

<iq from='coven@mix.shakespeare.lit'
    id='kl2fax27'
    to='hag66@shakespeare.lit'
    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>

4.5 Determining Information about a Channel

The Information Node contains various information about the channel that may be useful to the user. This can be read by the XMPP Client directly or by a MIX Proxy.

Example 17. MIX Proxy Requests Channel Information

<iq from='hag66@shakespeare.lit'
    id='kl2fax27'
    to='coven@mix.shakespeare.lit'
    type='get'>
  <query xmlns='urn:xmpp:mix:0#channel-info'/>
</iq>

Example 18. MIX Service Returns Channel Information

<iq from='coven@mix.shakespeare.lit'
    id='kl2fax27'
    to='hag66@shakespeare.lit'
    type='result'>
  <query xmlns='urn:xmpp:mix:0#channel-info'>
        <name>Witches Coven</name>
        <description>A location not far from the blasted heath where the three witches meet</description>
        <administrator>
           <vCard xmlns='vcard-temp'>
              <FN>Hecate</FN>
              <TITLE>Chief Witch</TITLE>
           </vCard>
        </administrator>
        <avatar>
             <data xmlns='urn:xmpp:avatar:data'>
          qANQR1DBwU4DX7jmYZnncm...
            </data>
        </avatar>
</iq>

4.6 Determining the Participants in a Channel

Online clients in the channel are determined from the presence node. Participants in the channel are determined from the Participants Node which will give proxy JID and nick. The jidmap node is used to map to real JIDs. An operation is provided to list channel participants. For JID Hidden channels, only the nicks are returned. For JID Visible channels, nicks and real JIDs are returned.

Example 19. MIX Proxy Requests Participant List

<iq from='hag66@shakespeare.lit'
    id='kl2fax27'
    to='coven@mix.shakespeare.lit'
    type='get'>
  <query xmlns='urn:xmpp:mix:0#get-participants'/>
</iq>

Example 20. MIX Service Returns Participant List for JID Visible Room

<iq from='coven@mix.shakespeare.lit'
    id='kl2fax27'
    to='hag66@shakespeare.lit'
    type='result'>
  <query xmlns='urn:xmpp:mix:0#get-participants'> 
  <items>
      <item jid='hag66@shakespeare.lit' nick='thirdwitch'>
      <item jid='hag01@shakespeare.lit' nick='top witch'> 
</items>
</iq>

4.7 Discovering Client MIX Capability

Where a client supports MIX, it MUST advertise this capability in response to a Disco request. This will enable other entities to determine if a client supports MIX. The following example shows a Disco response from a client that supports both MIX and MUC.

Example 21. Disco Response showing MIX support

<iq from='romeo@montague.lit/orchard' 
    id='disco1'
    to='juliet@capulet.lit/chamber' 
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='>
    <identity category='client' name='Exodus 0.9.1' type='pc'/>
    <feature var='http://jabber.org/protocol/caps'/>
    <feature var='http://jabber.org/protocol/disco#info'/>
    <feature var='http://jabber.org/protocol/disco#items'/>
    <feature var='http://jabber.org/protocol/muc'/>
    <feature var='http://jabber.org/protocol/mix'/>
  </query>
</iq>

5. Use Cases

5.1 Common User Use Cases

5.1.1 Joining a Channel

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.

Example 22. User Joins a Channel

<iq type='set'
    from='hag66@shakespeare.example'
    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 responds with an IQ-result. This stanza includes the nodes to which the user has been successfully subscribed, as well as the bare JID that will be used for the user in this channel and added to the participant list. The following example shows the result of the above request when the request is completed in full.

Example 23. Channel Processes Join Request in Full

<iq type='result'
    from='coven@mix.shakespeare.example'
    to='hag66@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:presence'/>
    <subscribe node='urn:xmpp:mix:nodes:participants'/>
    <subscribe node='urn:xmpp:mix:nodes:subject'/>
    <subscribe node='urn:xmpp:mix:nodes:config'/>
  </join>
</iq>

If a user cannot be subscribed to one or more of the requested nodes (e.g., because the node does not exist), but can be subscribed to some the response simply lists the nodes successfully subscribed. If none of the nodes requested are successfully subscribed to, an error response is sent indicating the reason that the first node requested was not subscribed to. This response will also include other nodes requested where subscription failed for the same reason. The following response example shows a response to the initial request example where the participant is not be subscribed to all nodes associated with the channel (in this case only messages, participants, and subject).

Example 24. Channel Processes Join With Some Nodes Not Subscribed To

<iq type='result'
    from='hag66@shakespeare.example'
    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 to subscribers to the participants node.

Example 25. Channel Adds User to Participants Node

<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 user may subsequently modify subscription to nodes in a channel by sending a subscription modification request, as shown in the following example.

Example 26. User Modifies Subscription Request

<iq type='set'
    from='hag66@shakespeare.example'
    to='coven@mix.shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
  <update-subscription xmlns='urn:xmpp:mix:0'>
    <subscribe node='urn:xmpp:mix:nodes:messages'/>
  </update-subscription>
</iq>

<iq type='result'
    from='hag66@shakespeare.example'
    to='coven@mix.shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
  <update-subscription xmlns='urn:xmpp:mix:0' jid='hag66@shakespeare.example'>
    <subscribe node='urn:xmpp:mix:nodes:messages'/>
  </update-subscription>
</iq>

5.1.2 User Preferences and Additional Information

A channel MAY store user preferences and parameters with each user. There are two preference options.

A user JID visibility preference have the following values:

  1. 'Default'. In this setting, the channel default value will be used. This value is used if another value is not explicitly set.
  2. 'Never'. If this is set, JID will never be shared and user will be removed from the channel if its mode changes to JID-visible-mandatory.
  3. 'Prefer Not'. If this is set, JID will only be shared if mode is JID-visible-mandatory.

The user may specify that no Private Messages are to be sent from the channel, and allow vCard retrieval.

The following table sets out the standardized user preference values. A MIX implementation may use other values.

Table 5: Standard User Preference Options

Option ValuesDefault
'JID Visibility' 'Default', 'Never', 'Prefer Not' 'Use Channel Default'
'Private Messages''Allow', 'Block' 'Allow'
'vCard''Allow', 'Block' 'Block'

When joining a channel, the client may specify one or more preference options as a Data Forms (XEP-0004) [21] form. In the response, the server MUST specify all of the user preferences supported by the server, with default values if the user has not requested a different value. The following example shows joining a channel and setting a preference.

Example 27. User Joins a Channel and Specifies a preference

<iq type='set'
    from='hag66@shakespeare.example'
    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'/>
    <x xmlns='jabber:x:data' type='submit'>
        <field var='FORM_TYPE' type='hidden'>
             <value>urn:xmpp:mix:0</value>
        </field>
        <field var='JID Visibility'>
            <value>Never</value>
        </field>
     </x>
  </join>
</iq>

The following example shows a successful join, which also reports all the user preferences.

Example 28. Channel Successfully Processes Join and returns the preferences set

<iq type='result'
    from='coven@mix.shakespeare.example'
    to='hag66@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:presence'/>
    <x xmlns='jabber:x:data' type='result'>
        <field var='FORM_TYPE' type='hidden'>
             <value>urn:xmpp:mix:0</value>
        </field>
        <field var='JID Visibility'>
            <value>Never</value>
        </field>
        <field var='Private Messages'>
           <value>Allow</value>
         </field>
        <field var='vCard'>
          <value>Block</value>
         </field>
     </x>
  </join>
</iq>

The client may also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard. The result is a form template.

Example 29. User Requests and Recieves Preferences Template Form

<iq type='set'
    from='hag66@shakespeare.example'
    to='coven@mix.shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
    <user-preference xmlns='urn:xmpp:mix:0'/>
     <x xmlns='jabber:x:data' type='submit'>
        <field var='FORM_TYPE' type='hidden'>
             <value>urn:xmpp:mix:0</value>
        </field>
        <field var='JID Visibility'>
            <value>Never</value>
        </field>
        <field var='Private Messages'>
           <value>Allow</value>
         </field>
        <field var='vCard'>
          <value>Block</value>
         </field>
     </x>
</iq>

<iq type='result'
    from='coven@mix.shakespeare.example'
    to='hag66@shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
    <user-preference xmlns='urn:xmpp:mix:0'>
    <x xmlns='jabber:x:data' type='result'>
        <field var='FORM_TYPE' type='hidden'>
             <value>urn:xmpp:mix:0</value>
        </field>
        <field var='JID Visibility'>
            <value>Never</value>
        </field>
        <field var='Private Messages'>
           <value>Allow</value>
         </field>
        <field var='vCard'>
          <value>Block</value>
         </field>
     </x>
  </user-preference>
</iq>

A user may modify preferences using the corresponding set operation.

Example 30. User Updates Preferences

<iq type='get'
    from='hag66@shakespeare.example'
    to='coven@mix.shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
    <user-preference xmlns='urn:xmpp:mix:0'/>
</iq>

<iq type='result'
    from='coven@mix.shakespeare.example'
    to='hag66@shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
    <user-preference xmlns='urn:xmpp:mix:0'>
    <x xmlns='jabber:x:data' type='form'>
        <field var='FORM_TYPE' type='hidden'>
             <value>urn:xmpp:mix:0</value>
        </field>
        <field type='list-single' label='Preference for JID Visibility' var='JID Visibility'>
            <option label='JID Never Shown'><value>Never</value></option>
            <option label='Default Behaviour'><value>Default</value></option>
            <option label='Try not to show JID'><value>Prefer Not</value></option>
         </field>
         <field type='list-single' label='Example Custom Preference' var='Custom Preference'>
            <option label='One Option'><value>A</value></option>
            <option label='Another Option'><value>B</value></option>
         </field>  
     </x>
  </user-preference>
</iq>

5.1.3 Leaving a Channel

Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel does not change when the user goes offline as happens with Multi-User Chat (XEP-0045) [22]. So, leaving the channel is a permanent action for a user across all clients, not just a matter of telling the channel that the user is not currently available or for a single client. In order to leave a channel, a user sends a MIX "leave" command to the channel. When a user leaves the channel, the user's client will remove the channel from the user's roster.

Example 31. User Leaves a Channel

<iq type='set'
    from='hag66@shakespeare.example'
    to='coven@mix.shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
  <leave xmlns='urn:xmpp:mix:0'/>
</iq>

When the user leaves the channel, the MIX service is responsible for unsubscribing the user from all nodes in the channel and for removing the user from the participants and presence list. If the user has online presence when the user leaves the channel, the change of presence status caused by removing the user's entry or entries from the presence node will ensure that subscribers to the presence node are correctly updated on presence status. Deletion from the participants and presence functions as if the item (channel participant) had been deleted using the PubSub retract mechanism with notification set to true. Notification of the deletion is sent to clients subscribed to the participants PubSub nodes, as shown in the example below.

Example 32. Reporting when User Leaves a Channel

<message from='coven@mix.shakespeare.example' to='hecate@shakespeare.example' id='foo'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='urn:xmpp:mix:nodes:participants'>
      <retract id='coven+123456@mix.shakespeare.example'/>
    </items>
  </event>
</message>

<message from='coven@mix.shakespeare.example' to='hecate@shakespeare.example' id='bar'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='urn:xmpp:mix:nodes:presence'>
      <retract id='coven+123456@mix.shakespeare.example/8765'/>
    </items>
  </event>
</message>

5.1.4 Setting a Nick

Each participant of a channel may have a nick, which is how other users in the channel will see the user. In some cases a nick is not needed, for example where a user reads messages in a channel but does not send messages or share presence information. A nick MUST be present for a user to send a message to a channel or for a user's presence to be shared on a channel. There are four ways that a user's nick can be obtained. The choice of mechanism or mechanisms is dependent on channel policy:

  1. The nick is registered with the user account in some way, for example as part of user provisioning with nick configured as an attribute in a directory service. This may be chosen by corporate services that wish to ensure consistent nick values for a set of users and channels.
  2. The nick is registered with the MIX service, as described in Registering a Nick .
  3. The user explicitly sets the nick, as described in this section.
  4. The MIX service generates the nick. In this case it is recommended that the assigned nick is a UUID following RFC 4122 [23].

A user will typically set a nick when joining a channel and may update this nick from time to time. The user does this by sending a command to the channel to set the nick. If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result.

Example 33. User sets Nick on Channel

<iq type='set'
    from='hag66@shakespeare.example'
    to='coven@mix.shakespeare.example'
    id='7nve413p'>
  <query xmlns='urn:xmpp:mix:0'>
    <nick>thirdwitch</nick>
  </query>
</iq>

The channel will return the nick that is to be used, noting that this may be different to the requested nick. MIX services SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, as defined in RFC 7700 [24].

Example 34. Channel informs user of Nick

<iq type='result'
    from='hag66@shakespeare.example'
    to='coven@mix.shakespeare.example'
    id='7nve413p'>
  <query xmlns='urn:xmpp:mix:0'>
    <nick>thirdwitch</nick>
  </query>
</iq>

5.1.5 Registering a Nick

A user can register a nick with the MIX service. Nick registration can be used ensure that a user is able to use the same nick in all channels in the service and to prevent other users from using a registered nick. This can help achieve a consistent experience across a set of channels and prevent user confusion. Support for nick registration by a MIX service is optional. Where nick registration is supported, nick registration may be optional or mandatory. Where a user has registered a Nick with the MIX service, it may be used by each channel according to policy for the channel. A nick is associated with the user's bare JID.

In order to determine if a Nick may be registered, the user may use disco to determine capabilities of the MIX service.

Example 35. User Determines features of the MIX service

<iq type='get'
    from='hag66@shakespeare.example'
    to='mix.shakespeare.example'
    id='7nve413p'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

The response will be a list of features of the MIX channel. If Nick Registration is supported, then the result set will include <feature var="mix_nick_register"/>.

To register a nick with the MIX service the user sends a <register/> command to the service.

Example 36. User Registers with Service

<iq type='set'
    from='hag66@shakespeare.example'
    to='mix.shakespeare.example'
    id='7nve413p'>
  <register xmlns='urn:xmpp:mix:0'>
    <nick>thirdwitch</nick>
  </register>
</iq>

On success, the service informs the user of its nick. The nick that is issued might be different from the nick that was requested, for example if the service completes normalization of nicknames for purposes of internationalization.

MIX services SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, as defined in RFC 7700 [25].

Example 37. Service Returns User of Nick

<iq type='result'
    to='mix.shakespeare.example'
    from='hag66@shakespeare.example'
    id='7nve413p'>
  <register xmlns='urn:xmpp:mix:0'>
    <nick>thirdwitch</nick>
  </register>
</iq>

If the requested nick is already taken, the MIX service returns a <conflict/> error:

Example 38. Nick is Taken

<iq type='error'
    to='mix.shakespeare.example'
    from='hag66@shakespeare.example'
    id='7nve413p'>
  <error type='cancel'>
    <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

If the register request does not contain a <nick/> element, then the MIX service assigns one. It is recommended that the assigned nick is a UUID following RFC 4122 [26].

5.1.6 Setting User Presence

A user joins a channel over an extended period, and participation in a channel does not generally change when user goes online or offline. The user's participation in a channel is reflected by the user's bare JID in the participant node. All messages to the channel are sent to this JID.

A user may share presence information with the channel, for one or more online clients. Where a user shares presence information with a channel, the channel is entered by the user's server into the user's roster when the user subscribes to the channel. When an XMPP client comes online or changes presence status, this will be communicated by the user to the user's server using broadcast presence. The user's XMPP server is then responsible to share this presence information to each entry in the roster and in particular to each MIX channel in the roster. The MIX channel will update the "urn:xmpp:mix:nodes:presence" node with any change of status and the updated presence information and then share this updated presence with users subscribed to this node, as described below. When the user sets an explicit status, this is used to modify the presence node in the channel. When a client being used by the user goes offline, the associated server will send presence status "unavailable" to the MIX channel, which will cause the full JID for that client to be removed from the presence node.

A channel may require that all channel participants share presence information with the channel, which is represented in the "urn:xmpp:mix:nodes:presence" node. If sharing presences is required by the channel, an XMPP client conforming to this specification SHALL share presence with the channel by including the channel in the user's roster. Note that the MIX server cannot generally enforce this, but it can require and enforce that when a message is sent to the channel, that the sender of the message is in the presence list.

Presence status and availability is set in a MIX channel by standard presence stanzas sent to the MIX channel by the user's server. User's wishing to receive presence updates will subscribe to the MIX channel presence node. Presence updates are sent out to subscribing using standard XEP-0045 compatible presence stanzas.

A user setting status is now used as an example. Unlike in Multi-User Chat (XEP-0045) [27] where coming online is a special action, coming online in MIX is implicit when presence status is set. Going offline is a achieved by setting presence status to unavailable, which removes the client full JID entry from the presence node. When a user sets a presence status, the user's server sends updated presence to the MIX channel, and the MIX server then publishes the user's availability to the "urn:xmpp:mix:nodes:presence" node. If there is not an item named by the full JID of the client with updated presence status, this item is created. If there is not an item named by the full JID of the client with updated presence status, then an item is created.

Example 39. User Setting Presence Status

<presence xmlns='jabber:client' from=‘hag66@shakespeare.example/pda’ to='coven@mix.shakespeare.example'>
  <show>dnd</show>
  <status>Making a Brew</status>
</presence>

The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node, with the 'publisher' attribute set to the user's participant identifier (the proxy JID. The MIX channel then broadcasts the presence change to all users who are subscribed to the "urn:xmpp:mix:nodes:presence" node. The presence stanza is sent from the proxy (anonymized) full JID of the user. Note that presence is associated with a client and so will have a full JID as it comes directly from the client and not through the MIX Proxy.

Example 40. Channel Distributes Presence

<presence from='coven+123435@mix.shakespeare.example/678'
          to='coven@mix.shakespeare.example'
          id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
  <nick xmlns='http://jabber.org/protocol/nick'>thirdwitch</nick>
  <show>dnd</show>
  <status>Making a Brew</status>
</presence>

The presence is distributed to those subscribing to the MIX channel presence node using a standard XMPP presence stanza. The presence change is recorded on the "urn:xmpp:mix:nodes:presence" node in the item for the full JID of the client to which the presence relates. The history of this node will be held as PubSub format in the MAM archive, so that presence history may be viewed.

5.1.7 Coming Online: Obtaining Presence

The presence information for a channel is stored in the urn:xmpp:mix:nodes:presence node and distributed using standard presence stanzas to users subscribing to this presence node. The user's server will then pass this presence information on to all online clients. When a client goes offline, it will lose synchronization with the presence node. When the client comes online, the clients server will send a directed presence stanza to the MIX channel. This will happen as a consequence of the MIX channel being in the user's roster and the MIX channel sending a presence update to the MIX channel. When the MIX channel adds or modifies presence for a client to the roster, this presence change will be distributed to all users subscribing to the presence node.

When the full JID of a client is added to the MIX channel presence node and that full JID is not in the presence list, the MIX channel will send to the client presence for all of the items in the presence node using standard presence stanzas. This will give the client full current presence.

5.1.8 Determining Real JIDs

Presence information will provide a MIX client with the nicks and anonymized proxy JIDs for participants. For JID visible rooms, the user may look up the real JID using the "urn:xmpp:mix:nodes:jidmap" node. The items in this node are identified by proxy JID, and so the real JID can be retrieved using a straightforward PubSub query. While a user may subscribe to the jidmap node, it is more likely to be used to directly look up JIDs as and when needed.

5.1.9 Coming Online: Synchronizing Message History

A MIX client will typically display message history of the channel to the user. When a client comes online it will need to obtain this message history from the MAM archive associated with the channel. There are three basic approaches a client will take:

  1. If the client has previously displayed message history and has been offline for a reasonably small time, the client will wish to retrieve all messages since the last one displayed to the user.
  2. The client may wish to display a fixed number of messages, perhaps finding more messages if the client subsequently requests.
  3. The client may wish to display messages from a recent time period, perhaps finding more messages if the client subsequently requests.

AUTHOR'S NOTE: Examples to be added

5.1.10 Going Offline

When a client goes offline, this presence update is sent by the client's server to the MIX channel. From the client perspective, this is the same as any other presence change. Handling by the MIX channel is slightly different.

Example 41. Client Goes Offline in the Channel

<presence type='unavailable'
          from='hag66@shakespeare.example/pda'
          to='coven@mix.shakespeare.example'/>

The MIX channel will retract (remove) the item in the presence node of the MIX channel identified by the client's full JID. The MIX channel will notify subscribers to the presence node of the user going offline by sending a presence stanza to the full proxy JID of each client.

Example 42. Channel Distributes Notification of Client going Offline

<presence from='coven+12345@mix.shakespeare.example/678'
          to='hecate@shakespeare.example'
          id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
          type='unavailable'/>

There is the possibility that the message associated with the user going offline will be lost. If this happens, "ghost" entries will appear in the presence node. A MIX server may take steps to address this, for example by probing client with a disco for presence items that remain unchanged for a long period.

It is desirable to prevent clients from going offline briefly and then coming back online again, as this will lead to "flapping presence". The recommended approach to achieve this is use of Stream Management (XEP-0198) [28] to maintain an XMPP client connection in the event of short term TCP failure.

5.1.11 Sending a Message

A client sends a message directly to a MIX channel as a standard groupchat message, in exactly the same way as for Multi-User Chat (XEP-0045) [29]. Messages are sent directly to the channel and do not use the MIX Proxy.

Example 43. User Sends Message to Channel

<message from='hag66@shakespeare.example/pda'
         to='coven@mix.shakespeare.example'
         id='92vax143g'
         type='groupchat'>
  <body>Harpier cries: 'tis time, 'tis time.</body>
</message>

The MIX channel then puts a copy of the message into the MAM archive for the channel and sends a copy of the message to each participant in standard groupchat format. These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's MIX Proxy. The message from value is the full Proxy JID of the message sender. The id of the message is the ID from the MAM archive.

Example 44. Channel Reflects Message to Participants

<message from='coven+12345@mix.shakespeare.example/678'
         to='hecate@shakespeare.example'
         id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
         type='groupchat'>
  <body>Harpier cries: 'tis time, 'tis time.</body>
</message>

The messages sent to participants have a different message id to the originally submitted message. This does not impact most recipients, but it does not allow the message originator to correlate the message with the submitted message. To address this the MIX channel MUST include an additional element of the message copy going back to the originator's bare JID that includes the original id. This enables the originator to correlate the received message with the message submitted.

Example 45. Channel Reflects Message back to Originator

<message from='coven+12345@mix.shakespeare.example/678'
         to='hag66@shakespeare.example'
         id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
         type='groupchat'>
  <body>Harpier cries: 'tis time, 'tis time.</body>
  <submission-id xmlns='urn:xmpp:mix:0'>92vax143g</submission-id>
</message>

5.1.12 Retracting a Message

A MIX channel MAY support message retraction, where the sender of a messages deletes a messages from the message history and optionally replace it with another message. This retraction mechanism will be based on the Publish-Subscribe (XEP-0060) [30] retract operation. A client looking at message history may choose to look at "current state" which will show status after the retraction or "full history" which will include the message that was retracted.

AUTHOR'S NOTE: Define new protocol to support this and add example.

5.1.13 Setting the Channel Subject

Setting the subject for a channel follows a similar procedure to sending a message. An XMPP client will send a message setting the subject directly to the MIX channel.

Example 46. User Sets Channel Subject

<message from='hag66@shakespeare.example/pda'
         to='coven@mix.shakespeare.example'
         id='92vax143g'
         type='groupchat'>
  <subject>
   <item>
    <text xml:lang="en">How to use Toads</text>
    <text xml:lang="de">Wie benutzt man Kröten</text>
  </item>
  </subject>
</message>

This message is received by the MIX channel, which will set the Subject Node for the channel, and then distribute the message to participants that are subscribed to the Subject Node, with the message addressed to the MIX Proxy.

Example 47. Channel Reflects New Subject to Participants

<message from='coven+12345@mix.shakespeare.example/678'
         to='hecate@shakespeare.example'
         id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
         type='groupchat'>
           <subject>
            <item>
                <text xml:lang="en">How to use Toads</text>
               <text xml:lang="de">Wie benutzt man Kröten</text>
            </item>
          </subject>
</message>

When a new Participant joins a channel and subscribes to the Subject Node, the channel MUST send to the user's MIX Proxy a message with the current subject. An XMPP Client MAY directly read the Subject node using Publish-Subscribe (XEP-0060) [31].

5.1.14 Telling another User about a Channel

A convenient way to reference another channel is to use References (XEP-0372) [32] which enables the JID of a channel to be shared. This might be used simply to inform the message recipient about the channel or as mechanism to invite the user to join the channel. This is useful as an invitation mechanism to a channel that any user can join or where the invitee knows that the user may join (e.g., because the channel is for all users in an organization).

5.1.15 Inviting another User to join a Channel that the user does not have Permission to Join

Invitation by reference, as described in the previous section, is a convenient approach to invite a user to join a channel that the user has permission to join. This section describes the approach used when the inviter has permission to grant rights for the invitee to become a channel participant. This might be because the inviter is an administrator of the channel or the channel may have a special mode where channel participants may grant rights for other users to join a channel ('Participation Addition by Invitation from Participant' enabled). This approach is used to avoid cluttering the allowed node with JIDs of users who are invited to join, but do not accept the invitation. When a channel participant(the inviter) invites another user (the invitee) to join a channel, the following sequence of steps is followed:

  1. The channel inviter sends to the channel requesting an invite for the invitee.
  2. The channel sends an invitation to the inviter.
  3. The inviter sends the invitation to the invitee.
  4. The invitee MAY use the invitation to join the channel.
  5. The invitee MAY send a response to the inviter, indicating if the invitation was accepted or declined.

The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel has 'Participation Addition by Invitation from Participant' mode enable. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time.

Example 48. Inviter Requests and Receives Invitation

<iq from='hag66@shakespeare.lit/pda'
    id='kl2fax27'
    to='coven@mix.shakespeare.lit'
    type='get'>
  <query xmlns='urn:xmpp:mix:0#request-invitation'/>
  <invitee>cat@shakespeare.lit</invitee>
</iq>


<iq from='coven@mix.shakespeare.lit'
    id='kl2fax27'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='urn:xmpp:mix:0#request-invitation'>
        <invitation>
           <inviter>hag66@shakespeare.lit</inviter>
           <invitee>cat@shakespeare.lit</invitee>
           <channel>coven@mix.shakespeare.lit</channel>
           <token>ABCDEF</token>
        </invitation>
</iq>

The inviter can now send the invitee a message containing the invitation, as shown in the following example.

Example 49. Inviter sends Invitation to Invitee

<message from='hag66@shakespeare.lit/pda'
    id='foo'
    to='cat@shakespeare.lit'>
    <body>Would you like to join the coven?<body>
    <invitation xmlns='urn:xmpp:mix:0'> 
        <inviter>hag66@shakespeare.lit</inviter>
        <invitee>cat@shakespeare.lit</invitee>
        <channel>coven@mix.shakespeare.lit</channel>
        <token>ABCDEF</token>
   </invitation>
</iq>

The invitation can now be used by the invitee to join a channel. The invitation is simply added to the standard channel join, so that the channel can validate the invitation using the token. If the allowed node is present and the invitee is not matched against any item, the channel MUST add the invitee to the allowed node as part of the join.

Example 50. User Joins a Channel with an Invitation

<iq type='set'
    from='cat@shakespeare.example'
    to='coven@mix.shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
  <join xmlns='urn:xmpp:mix:0'>
    <subscribe node='urn:xmpp:mix:nodes:messages'/>
    <invitation> 
        <inviter>hag66@shakespeare.lit</inviter>
        <invitee>cat@shakespeare.lit</invitee>
        <channel>coven@mix.shakespeare.lit</channel>
        <token>ABCDEF</token>
   </invitation>
  </join>
</iq>

The invitee may send an acknowledgement back to the inviter, noting the status of the invitation. Values are:

Example 51. Invitee sends Acknowledgement to Inviter

<message from='cat@shakespeare.lit/miaow'
    id='bar'
    to='hag66@shakespeare.lit/pda'>
    <body>No Thanks - too busy chasing mice....<body>
    <invitation-ack xmlns='urn:xmpp:mix:0'>
        <value>Declined</value>
        <invitation> 
             <inviter>hag66@shakespeare.lit</inviter>
             <invitee>cat@shakespeare.lit</invitee>
              <channel>coven@mix.shakespeare.lit</channel>
              <token>ABCDEF</token>
         </invitation>
     </invitation-ack>
</iq>

5.1.16 Sending Private Messages

Private Messages are used to provide communication with another channel participant through the MIX channel, without the initiating user knowing the real JID of the channel participant. A channel MAY support use of Private Messages. Private messages are standard XMPP messages. A message goes through a number of stages with different addressing. This is set out in the following table.

Table 6: Setting From and To when sending Private Messages

MessageFromTo
First Message from Client to MIX ChannelFull JID of initiator's clientProxy bare JID of responder
First Message from MIX Channel to responder's MIX ProxyProxy full JID of initiator's clientBare JID of responder
First Message from responder's MIX Proxy to one or more of the responder's clientsProxy full JID of initiatorFull JID of responder's client
Messages from responder's client to MIX ChannelFull JID of responder's clientProxy full JID of initiator's client
Messages from MIX channel to initiator's clientProxy full JID of responder's clientFull JID of initiator's client
Messages from initiator's client to MIX ChannelFull JID of initiator's clientProxy full JID of responder's client
Message from MIX Channel to responder's clientProxy full JID of initiator's clientFull JID of responder's client

Private Messages MAY be archived using MAM by the XMPP servers associated with initiator and responder. Private Messages MUST NOT be archived by the MIX channel.

5.1.17 Requesting vCard

A user may request the vCard of a channel participant by sending a request through the channel. The request may be sent directly by the client or through a MIX Proxy. The MIX channel MAY pass this request on or may block it. In the following example, the requesting client sends a message to the anonymized bare JID of the channel participant for which the vCard is desired.

Example 52. Client directly requests vCard through channel

<iq from='hag66@shakespeare.example/intibo24'
    id='lx09df27'
    to='coven+989898@mix.shakespeare.example'
    type='get'>
  <vCard xmlns='vcard-temp'/>
</iq>

The MIX channel MAY pass on the vCard request or may reject with an error, dependent on channel policy. The MIX service will then address the vCard request to the MIX proxy (bare JID) using an anonymous full proxy JID to hide the requester.

Example 53. Channel passes on vCard request to MIX Proxy

<iq from='coven+123456@mix.shakespeare.example/6789'
    id='lx09df27'
    to='peter@shakespeare.lit'
    type='get'>
  <vCard xmlns='vcard-temp'/>
</iq>

The MIX Proxy, on behalf of the user, MAY send a response or reject with an error. The MIX Proxy will send the vCard back to the channel.

Example 54. Service responds with Disco Info result

<iq from='peter@shakespeare.lit'
    id='lx09df27'
    to='coven+123456@mix.shakespeare.example/6789'
    type='result'>
    <vCard xmlns='vcard-temp'>
    <FN>Peter Saint-Andre</FN>
    <N>
      <FAMILY>Saint-Andre</FAMILY>
      <GIVEN>Peter</GIVEN>
      <MIDDLE/>
    </N>
    <NICKNAME>stpeter</NICKNAME>
    <URL>http://www.xmpp.org/xsf/people/stpeter.shtml</URL>
  </vCard>
    
  <query xmlns='http://jabber.org/protocol/disco#info'>
</iq>

The MIX channel will then send the vCard response to the requesting client on behalf of the client sending the response.

Example 55. Service responds with Disco Info result

<iq from='coven+989898@mix.shakespeare.example'
    id='lx09df27'
    to='hag66@shakespeare.example/intibo24'
    type='result'>
 <vCard xmlns='vcard-temp'>
    <FN>Peter Saint-Andre</FN>
    <N>
      <FAMILY>Saint-Andre</FAMILY>
      <GIVEN>Peter</GIVEN>
      <MIDDLE/>
    </N>
    <NICKNAME>stpeter</NICKNAME>
    <URL>http://www.xmpp.org/xsf/people/stpeter.shtml</URL>
  </vCard>   
</iq>

5.2 Use of MAM

All nodes of each MIX channel are archived using MAM. Access to history in these nodes uses standard MAM protocol to access the channel nodes and to retrieve information from the nodes. Information retrieved using MAM will be of the format stored on the node and will include Publish-Subscribe (XEP-0060) [33] PubSub wrapping. MAM is the MIX mechanism to get at this information, in preference to direct use of PubSub.

AUTHOR'S NOTE: Add example of message retrieved using MAM, showing XEP-0060 wrapping

There are XEPs that extend MAM and in some cases modify core MAM requirements. Such XEPs may be used in conjunction with MAM, provided that they are supported by the MIX channel. If such XEPs are used, the requirements specified MUST be followed.

PubSub provides the ability to modify the state of the node, and distinguishes between current state and full history. It is anticipated that MAM will be extended with an option to choose between "current state" and "full history". This capability will be useful for and used by MIX.

AUTHOR'S NOTE: This specification will be updated to reference this MAM extension when it is written.

5.3 Administrative Use Cases

5.3.1 Checking For Permission To Create a Channel

MIX does not standardize an access control model for creating and deleting MIX channels. The choice is left to the MIX implementer, and could be a very simple or complex approach.

AUTHOR'S NOTE: MIX Protocol to be added to create channel; check for permission to create channel; delete channel

Example 56.


5.3.2 Creating a Channel

AUTHOR'S NOTE: Dave Cridland has suggested the following protocol. <iq to='mix.cridland.im' type='set'> <create channel='some-room-here@mix.cridland.im' xmlns='urn:xmpp:mix:0'> <optional-configuration-form/> </create> </iq>

Example 57.


5.3.3 Creating a Channel for Ad Hoc User

Rooms may be created for ad hoc use between a set of users. Channels of this nature will have channel name created by the server and will not be addressable or discoverable.

Example 58.


5.3.4 Configuring a Channel

Channel jid is set on channel creation and may not be changed. All other channel may be changed if channel configuration allows.

AUTHOR'S NOTE: Allow configuration by direct writes to 'urn:xmpp:mix:nodes:config' . Also specify MIX XEP-0004 commands to achieve this.

Example 59.


5.3.5 Destroying a Channel

MIX channels are always explicitly destroyed by an owner of the channel or by a server operator. There is no concept of temporary channel, equivalent to Multi-User Chat (XEP-0045) [34] temporary room which is automatically destroyed by the server when the users leave. However, channels may be configured with an explicit lifetime, after which the channel MUST be removed by the MIX server. Where a channel is created for ad hoc use, it may be desirable to keep the channel for history reference or for re-use by the same set of users.

Note that the owner of the channel does not need to have presence registered in the channel in order to destroy it.

AUTHOR'S NOTE: More TBS

Example 60.


5.3.6 Server Destroying a Channel

Servers may destroy channels which have no participants and/or presence according to local policy. There will often be good reasons to not destroy rooms in these scenarios.

5.3.7 Modifying User Affiliations

Example 61.


5.3.8 Removing a User From a Channel (Kicking)

Example 62.


6. Supporting MIX and MUC together

MIX is specified as a service that can be used independent of MUC and a MIX service may be implemented without MUC. If both MIX and MUC are implemented, three approaches are noted.

  1. Entirely separate MIX and MUC implementation, with MIX and MUC using separate domains and MIX channels being completely separate from MUC rooms.
  2. Fully integrated MIX and MUC implementation, with MIX and MUC sharing a single domain and rooms/channels equivalent.
  3. Partially integrated MIX and MUC implementation, with MIX and MUC using separate domains, but rooms/channel are common. This means that each MIX channel will have MUC room of the same name and same participants.

The fully integrated approach would be transparent to clients. Disco of a room or channel would show support for both MUC and MIX, which would enable a client to choose whether to use MUC or MIX. The following example shows how a MIX service that also supported MUC would respond:

Example 63. Service responds with Disco Info result showing MIX and MUC support

<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'/>
    <feature var='http://jabber.org/protocol/muc'/>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:mix:0#serviceinfo</value>
      </field>
    </x>
  </query>
</iq>

For the partially integrated service, it will be useful for clients that support both MIX and MUC to be able to determine that the server supports both protocols. For a MIX client, it will be useful to know the MUC service, so that this information can be shared with a MUC client invitation. This information is provided by the initial service discovery:

Example 64. MIX Service responds with Disco Info result sharig MUC service location

<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'. The field with var='muc-mirror' is the value of which is the mirrored MUC domain's JID.

Where a client supporting both MIX and MUC is given a reference to a MUC room, it is desirable that the client can determine the MIX channel and join using MIX. This is achieved by an equivalent extension to MUC service discover.

Example 65. MUC Service responds with Disco Info result sharig MIX service location

<iq from='chat.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='http://jabber.org/protocol/muc'/>    
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:mix:0#serviceinfo</value>
      </field>
      <field var='mix-mirror'
             type='jid-single'
             label='Location of MUC mirror service'>
        <value>mix.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'. The field with var='mix-mirror' is the value of which is the mirrored MIX domain's JID.

6.1 Choosing Which Invite to Send

Where a client supports MUC and MIX and has determined that for a channel that the server also supports a MUC room, the client has a choice as to which type of invite to send. This SHOULD be done by determining if the client support MIX using the mechanism specified in Discovering Client MIX Capability. If the client supports MIX a MIX invite SHOULD be sent.

7. Capabilities not provided in MIX

This section lists a number of capabilities not specified in this version of MIX which were provided in Multi-User Chat (XEP-0045) [35].

7.1 Password Controlled Channels

Multi-User Chat (XEP-0045) [36] provides a mechanism to control access to MUC rooms using passwords. An equivalent mechanism is not included in MIX, as it has a number of security issues. Control of access to channels is better achieved using an explicit list of participants.

7.2 Conversion from 1:1 Chat

Multi-User Chat (XEP-0045) [37] describes how to convert from a 1:1 chat to a MUC room. Conversion from 1:1 chat is a straightforward and useful capability, that is not described in this version of the MIX specification. Options that may be considered in the future are:

  1. Describe in a new separate XEP.
  2. Describe in an updated version of this XEP.
  3. Do not specify in a XEP and leave to implementer.

QUESTION: Input on these choices is solicited. Dave Cridland votes for new XEP.

7.3 Voice Control

Multi-User Chat (XEP-0045) [38] defines a mechanism so that MUC moderators can control who is able to send messages to a MUC room using a "voice" mechanism. The current version of MIX does not include this.

AUTHOR'S NOTE AND QUESTION: Input on the desirability of adding voice control to MIX is solicited. It would appear reasonably straightforward, and probably be achieved by adding two additional nodes to the MIX channel.

8. Internationalization Considerations

TBD.

Discuss normalization of nicknames.

9. Security Considerations

TBD.

Topics to cover:

10. IANA Considerations

None.

11. XMPP Registrar Considerations

Register a namespace.

12. XML Schema

TBD.

13. Acknowledgements

Thanks to the following who have made contributions: Dave Cridland, Philipp Hancke, Waqas Hussain, Georg Lukas, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Matthew Wild and one anonymous reviewer.


Appendices


Appendix A: Document Information

Series: XEP
Number: 0369
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.4
Last Updated: 2016-09-21
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM, XEP-0004, XEP-0030, XEP-0060, XEP-0128, XEP-0313
Supersedes: None
Superseded By: None
Short Name: MIX
Source Control: HTML
This document in other formats: XML  PDF


Appendix B: Author Information

Kevin Smith

Email: kevin.smith@isode.com
JabberID: kevin.smith@isode.com

Steve Kille

Email: Steve.Kille@isode.com
JabberID: Steve.Kille@isode.com

Peter Saint-Andre

Email: peter@andyet.net
JabberID: stpeter@stpeter.im
URI: https://stpeter.im/


Appendix C: Legal Notices

Copyright

This XMPP Extension Protocol is copyright © 1999 - 2016 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.


Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.


Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


Appendix G: Notes

1. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

2. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

3. XEP-0313: Message Archive Management <http://xmpp.org/extensions/xep-0313.html>.

4. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

5. XEP-0289: Federated MUC for Constrained Environments <http://xmpp.org/extensions/xep-0289.html>.

6. XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.

7. XEP-0163: Personal Eventing Protocol <http://xmpp.org/extensions/xep-0163.html>.

8. XEP-0313: Message Archive Management <http://xmpp.org/extensions/xep-0313.html>.

9. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

10. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

11. RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>.

12. XEP-0376: Pubsub Account Management <http://xmpp.org/extensions/xep-0376.html>.

13. XEP-0054: vcard-temp <http://xmpp.org/extensions/xep-0054.html>.

14. XEP-0084: User Avatar <http://xmpp.org/extensions/xep-0084.html>.

15. XEP-0004: Data Forms <http://xmpp.org/extensions/xep-0004.html>.

16. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

17. XEP-0004: Data Forms <http://xmpp.org/extensions/xep-0004.html>.

18. XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.

19. XEP-0313: Message Archive Management <http://xmpp.org/extensions/xep-0313.html>.

20. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

21. XEP-0004: Data Forms <http://xmpp.org/extensions/xep-0004.html>.

22. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

23. RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace <http://tools.ietf.org/html/rfc4122>.

24. RFC 7700: Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames<http://tools.ietf.org/html/rfc7700>.

25. RFC 7700: Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames<http://tools.ietf.org/html/rfc7700>.

26. RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace <http://tools.ietf.org/html/rfc4122>.

27. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

28. XEP-0198: Stream Management <http://xmpp.org/extensions/xep-0198.html>.

29. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

30. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

31. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

32. XEP-0372: References <http://xmpp.org/extensions/xep-0372.html>.

33. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

34. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

35. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

36. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

37. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

38. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.


Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 0.4 (2016-09-21)

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

(sek)

Version 0.3.1 (2016-09-07)

Introduce MIX Proxy concept. Add MIX capability in client discovery.

(sek)

Version 0.3 (2016-09-05)

Addressing comments from review of 0.2 and expansion/clarification of MUC/MIX dual working

(sek)

Version 0.2.3 (2016-09-01)

Cleanup, use precis nickname for nicknames, and allow multiple subject languages.

(ssw, ks)

Version 0.2.2 (2016-08-26)

Phrasing and grammar.

(ssw)

Version 0.2.1 (2016-08-25)

Includes Link Mauve (Emmanuel Gil PEYROT) editorial changes

(sek, egp)

Version 0.2 (2016-08-16)

Significant update based on XMPP Summit discussions

(sek, ks)

Version 0.1.1 (2016-03-17)

Fix XML in join example.

(XEP Editor (ssw))

Version 0.1 (2016-01-07)

Initial published version approved by the XMPP Council.

(XEP Editor (asw))

Version 0.0.1 (2015-10-12)

First draft.

(kis/psa)

END