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
The Mediated Information eXchange (MIX) protocol is intended as a replacement for Multi-User Chat (MUC). MUC is a major application of XMPP that was developed in 2002 and standardized in &xep0045;. MIX implements the same basic MUC patterns in a more flexible and extensible way in order to address requirements that have emerged since MUC was developed. MIX supports all of the core chatroom features that are familiar from MUC, such as discussion topics and invitations. Like MUC, it also defines a strong access control model, including the ability to kick and ban users, to name administrators, and to require membership in order to participate in channels.
+The Mediated Information eXchange (MIX) protocol is intended as a replacement for Multi-User Chat (MUC). MUC is a major application of XMPP that was developed in 2002 and standardized in &xep0045;. MIX implements the same basic MUC patterns in a more flexible and extensible way in order to address requirements that have emerged since MUC was developed. MIX supports all of the core chatroom features that are familiar from MUC, such as discussion topics and invitations. Like MUC, it also defines a strong access control model, including the ability to 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:
- Arriving MIX messages (which will be of type=groupchat) and presence information are sent to the bare JID. This means that the MIX Proxy will use a modification of the standard &rfc6121; rules. + Messages being sent from MIX channel to MIX Proxy (which will be of type=groupchat) and presence information are sent to the bare JID. This means that the MIX Proxy will use a modification of the standard &rfc6121; rules.
@@ -229,13 +239,13 @@
| Mode | Description |
|---|---|
| 'JID Visible' | In these channels, some or all participant JIDs are visible to all channel members. |
| '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 members, but they are visible to channel administrators. |
| 'JID Hidden' | In these channels, no participant JIDs are visible to channel participants, but they are visible to channel administrators. |
- A channel member may specify their preferences for JID visibility, with one of the following values: + A channel participant may specify their preferences for JID visibility, with one of the following values:
| Preference | Description |
|---|
| Node | Description | |
|---|---|---|
| Name | Node | Description |
| 'urn:xmpp:mix:nodes:messages' | For publishing messages. Each item of this node will contain a message sent to the channel. | |
| Messages | 'urn:xmpp:mix:nodes:messages' | For publishing messages. Each item of this node will contain a message sent to the channel. |
| 'urn:xmpp:mix:nodes:subject' | For publishing the subject of the channels | |
| Subject | 'urn:xmpp:mix:nodes:subject' | For publishing the subject of the channels |
| '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). | |
| 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). |
| '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. | |
| 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. |
| 'urn:xmpp:mix:nodes:presence' | For publishing information about the availability status of online participants, which may include multiple clients for a single participant. | |
| 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. |
| 'urn:xmpp:mix:nodes:config' | For storing configuration information. | |
| Information | 'urn:xmpp:mix:nodes:info' | For storing general channel information, such as description and avatar. |
| 'urn:xmpp:mix:nodes:acl' | For storing information about access control lists (such as the list of owners and administrators). This information will generally be restricted to authorized users. | |
| 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. |
- jidmap is the only node that will always be present for a MIX channel and all other nodes are optional. All channels will have either a message node, a presence node or both, because a channel will always share messages and/or presence. MIX provides mechanisms to allow users to conveniently subscribe to a chosen set of nodes and to unsubscribe to all nodes with a single operation. + 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 + The structure of each of the standard nodes is now considered in more detail in the rest of this section, after explaining 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. +
+| Role | Membership and Rights |
|---|---|
| Owners | These are owners of the list, as specified in the channel configuration node. Only owners are allowed to modify the channel configuration node. |
| Administrators | Administrators are defined in the channel configuration node. Administrators have update rights to the Allowed Node and Banned Node, so can control which users may participate in a channel. Administrators will usually be granted additional rights, such as the ability to kick users from a channel. |
| Participants | Participants are users listed by JID in the participants node. |
| Allowed | Allowed is the set of JIDs that are participants or may be allowed to become participants. A JID is allowed if it does not match entry in the banned node and either it matches an entry in the allowed node or the allowed node is not present. |
| Anyone | Any 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. +
+Items in this node will contain a message identified by a unique ID. A MIX implementation SHOULD NOT make messages available for retrieval from this node using pubsub. The recommended approach is that zero history is held in the messages node, and that this node is used for publication only. The recommended approach to retrieve message history is MAM. Users subscribe to this node to receive messages.
Private Messages are not stored in the messages node.
The subject node publishes the current subject of channel. Subject history is stored in MAM. A single item is stored in this node at a time which MUST contain a "text" element and MAY contain additional text elements. Where multiple text elements are provided, each MUST posses an xml:lang attribute that describes the natural language of the subject. Users subscribe to this node to receive subject updates. The following example shows the format of a item in the subject node.
+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.
+ 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. +
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 channel membership. + 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.
The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. +
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.
QUESTION: The current specification allows channels to be configured so that node subscription is not restricted to participants (although this restriction is the default). Is this flexibility desirable, or should we restrict to participants?
+- This node may be subscribed to by users using bare JID. So presence of online clients is sent to all users subscribed to this node, noting that presence is always sent using standard presence protocol. + 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.
The Configuration node holds the configuration of the channel as a single item, named by the date-time of the last update to the configuration. A single item is stored in the node at a time, with previous configuration history accessed by MAM. Users subscribed to the configuration node will enable notification of configuration change. The configuration node is optional for a MIX channel. For example, configuration choices could be fixed and not exposed. A subset of the defined configuration options may be used and additional non-standard configuration options may be added. If configuration options to control functionality of the nature described here are provided, the options defined in this standard MUST be used. The following configuration options are provided:
+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: +
TEMPORARY NOTE AND QUESTION: This is currently work in progress. Suggestions for other items to be included in configuration are welcome.
-The format of the Configuration node follows &xep0004;. This allows configuration to be updated by MIX defined commands and that the results of update commands can be directly written to the PubSub node. Updates to the Configuration may use these commands or direct writing to the PubSub node.
-The format of the Information node follows &xep0004;. This allows configuration to be updated by MIX defined commands and that the results of update commands 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. +
+The ACL node is closely related to the configuration node, and contains more information that will generally be more restricted as to who can access and modify. An anticipated configuration reflected in the defaults has ACL node configured so that it can be modified by channel owners and read only by channel owners and administrators. The default for the configuration node is update by owners or administrators and visibility to list members. Split of functionality has been made on the basis of this model.
-TEMPORARY NOTE AND QUESTION: The split of configuration/acl is arbitrary. It would be possible to merge them, or to split into more nodes, giving finer control granularity. Input is solicited on the split an detailed assignment of items to nodes.
- - -The ACL node holds access control related configuration of the channel as a single item, named by the date-time of the last update to the ACL. History MUST be set to 1. Previous ACL history is accessed by MAM. Users may subscribe to the ACL node if allowed using bare JID. The ACL node is optional for a MIX channel. For example, ACL choices could be fixed and not exposed. A subset of the defined ACL options may be used and additional non-standard ACL options may be added. If configuration options to control functionality of the nature described here are provided, the options defined in this standard MUST be used. The following ACL options are provided:
+ ++ 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. +
+ ++ 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. + +
+ ++ 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: +
+TEMPORARY NOTE: This is currently work in progress. Suggestions for other items to be included in ACL are welcome.
+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 &xep0004;.
-+ 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. +
+The MIX service then MUST return its identity and the features it supports, which MUST include the 'urn:xmpp:mix:0' feature, and the identity MUST have a category of 'conference' and a type of 'text'.
-- QUESTION: Is there a need for a different type than text? Provisional answer: no. -
+The list of channels supported by a MIX service is obtained by a disco command.
-AUTHOR'S NOTE: This version contains a number of AUTHOR NOTES, which are reminder instructions to the author as to editing actions to be taken, and also indicate where changes are anticipated in future versions.
-- AUTHOR'S NOTE: Need to add example. This standard disco approach is going to replace the earlier proposed "urn:xmpp:mix:nodes:channels", unless there are objections. -
+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.
+ +In order to find out more information about a given channel, a user can send a disco#info query to the channel.
+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.
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.
+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.
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.
+ + +- Online clients in the channel are determined from the presence node. Participants in the channel are determined from the "urn:xmpp:mix:nodes:participants" node which will give proxy JID and nick. The jidmap node is used to map to real JIDs.
-AUTHOR'S NOTE: Add example
+ + 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. + +The channel responds with an IQ-result. This stanza includes the nodes to which the user has been successfully subscribed, as well as the bare JID that will be used for the user in this channel and added to the participant list. If a user cannot be subscribed to one or more of the requested nodes (e.g., because the node does not exist), but can be subscribed to some the response simply lists the nodes successfully subscribed. If none of the nodes requested are successfully subscribed to, 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. A user may subsequently request subscription to nodes in a channel to which the user was not initially subscribed.
-As noted, the participant might not be subscribed to all nodes associated with the channel (in this case only messages, participants, and subject).
-The channel also adds the user to the participants node and sends a notification.
+The channel also adds the user to the participants node and sends a notification to subscribers to the participants node.
+ A user may subsequently modify subscription to nodes in a channel by sending a subscription modification request, as shown in the following example. +
+ +A channel may store additional user preferences and parameters. Where the channel requires a value to be explicitly a &xep0004; form will be returned in response to the join request with mandatory and optional fields. If parameters are optional, the user may request to set them.
+A channel MAY store user preferences and parameters with each user. There are two preference options. +
- A user may set their JID visibility preference to one of the following values: + A user JID visibility preference have the following values:
- AUTHOR'S NOTE AND QUESTION: Dave Cridland (+1) has suggested. I would prefer: - - a) User options be sent in the initial join/>. - b) Unknown options are ignored. - c) User options can be requested (as a form). If clients require an option to - be supported, they should request the form. - - + The user may specify that no Private Messages are to be sent from the channel, and allow vCard retrieval.
-AUTHOR'S NOTE AND QUESTION: Add protocol specifications and examples. Are there any other specific per user values that should be listed here?
++ The following table sets out the standardized user preference values. A MIX implementation may use other values. +
+| Option | Values | Default |
|---|---|---|
| '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 &xep0004; form. In the response, the server MUST specify all of the user preferences supported by the server, with default values if the user has not requested a different value. The following example shows joining a channel and setting a preference.
+ +The following example shows a successful join, which also reports all the user preferences.
+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.
++ A user may modify preferences using the corresponding set operation. +
+ + +Users generally remain in a channel for an extended period of time. In particular membership of the channel does not change when the user goes offline as happens with &xep0045;. 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.
+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 &xep0045;. 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.
- Each member 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: + 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:
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.
@@ -774,7 +1115,7 @@
- A user joins a channel over an extended period, and membership in a channel does not generally change when user goes online or offline. The users membership of the 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 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.
@@ -782,7 +1123,7 @@
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 members 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.
+ 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.
@@ -863,7 +1204,7 @@
A user sends a message to a MIX channel as a standard groupchat message, in exactly the same way as for &xep0045;. A client sends a message directly to a MIX channel as a standard groupchat message, in exactly the same way as for &xep0045;. Messages are sent directly to the channel and do not use the MIX Proxy.