Update after Brussels Summit; @@ -52,6 +52,7 @@ Use example JIDs aligned to anticipated BIND2 specification; Clarify PubSub Node Type; Add Error handling section; + Substantial Editorial Review;
Several reasons exist for replacing MUC:
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.
+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 following concepts underlie the design of MIX.
MIX is based upon domains providing a MIX service, such as 'mix.shakespeare.example'. Note that although PubSub communication is used, a domain used for MIX is a MIX domain and not a standard &xep0060; 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.
+MIX is based upon domains providing a MIX service, such as 'mix.shakespeare.example'. Note that although PubSub communication is used, a domain used for MIX is a MIX domain and not a standard &xep0060; domain. Like MUC, there is no requirement on the naming of these domains; the label 'mix' used in examples in this specification and the fact that it is a subdomain of a 'shakespeare.example' service are purely for example.
Every MIX channel is an addressable PubSub service (with additional MIX semantics) that will be addressed using a bare JID by other XMPP entities, for example coven@mix.shakespeare.example. While &xep0060; is used as the basis for the MIX model, MIX uses standard presence and groupchat messages to provide an interface to the MIX service that does not expose PubSub protocol for many of the more common functions.
@@ -318,7 +320,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
- 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.
+ MIX channels store presence in the presence node using the proxy JID of each online client for a user. User presence MAY be included 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.
@@ -332,9 +334,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
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.
-
@@ -379,7 +379,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
- All of the standard nodes are OPTIONAL. A channel providing a service similar to MUC will typically use all of the standard nodes, but other channels MAY use combinations of these nodes.
+ All of the standard nodes are OPTIONAL. A channel providing a service similar to MUC will typically use all of the standard nodes, but other channels MAY use any combination of these nodes.
MIX provides mechanisms to allow users to conveniently subscribe to a chosen set of nodes and to unsubscribe to all nodes with a single operation. Some nodes are accessed and managed with PubSub, whereas other nodes define MIX specific mechanisms for their use, shown in the last two columns of the table.
@@ -406,7 +406,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
- There will always be at least 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.
+ There MUST always be at least 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.
Configuration 'urn:xmpp:mix:nodes:config' For storing channel configuration. PubSub PubSub Anyone Any user, including users in the banned node.
Items in this node will contain a message identified by the MAM ID used for the message in the channels MAM archive. &xep0313; rules MUST be used to ensure this ID is unique. A MIX implementation SHOULD NOT make messages available for retrieval from this node using pubsub and MUST NOT allow direct pubsub publishing to this node. Messages are published by sending messages to the channel. The Messages node is a transient node and so no PubSub items are held. Message history is retrieved by use of MAM. Users subscribe to this node to indicate that messages from the channel are to be sent to them.
-Private Messages are not stored in the messages node.
++ The Message node is used to distribute messages. The Messages node is a transient node and so no PubSub items are held. Messages MUST go to the associated MAM archive and history is retrieved by use of MAM. Users subscribe to this node to indicate that messages from the channel are to be sent to them. Private Messages are not distributed by the messages node. + +
+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. This value is added when a user joins the channel and is removed when the user leaves the channel. Each item is identified by proxy bare JID, mapping to the real bare JID. This node is used to give administrator access to real JIDs and participant access to real JIDs in jid-visible channels. This node MUST NOT be modified directly using pubsub. - In JID visible channels, all participants MAY subscribe to this node. In JID hidden channels, only administrators can subscribe. The JID MAP node is a permanent node with one item per participant.
+ In JID visible channels, all participants MAY subscribe to this node. In JID hidden channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant.- 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 can be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list. + 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 proxy JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control MAY be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list.
@@ -516,7 +519,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
- An entity MAY discover a MIX service or MIX services by sending a Service Discovery items ("disco#items") request to its own server. This MUST come directly from a MIX client. + An entity MAY discover a MIX service or MIX services by sending a Service Discovery items ("disco#items") request to its own server.
To determine if a domain hosts a MIX service, a &xep0030; info query SHOULD be sent in the usual manner to determine capabilities.
+To determine if a domain hosts a MIX service, a &xep0030; info query is sent in the usual manner to determine capabilities.
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'.
+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', as shown in the following example:
- A MIX service MUST return the first feature listed and MAY return the other features listed: + A MIX service MUST return the 'urn:xmpp:mix:0' feature and MAY return the other features listed here:
A MIX service MUST NOT advertise support for &xep0313;, as MAM is supported by the channels and not by the service. A MIX service MUST NOT advertise support for generic &xep0060;, as although MIX makes use of PubSub it is not a generic PubSub service.
The list of channels supported by a MIX service is obtained by a disco#items command. The MIX service MUST only return channel that exist and that the user making the query has rights to subscribe to. This query MUST be made directly by a client.
-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 directly by a client.
+In order to find out more information about a given channel, a user can send a disco#info query to the channel.
The channel MUST return its identity and the features it supports. Note that a MIX channel MUST support MAM and so the response will always include both MIX and MAM support. All disco queries on a MIX channel rad results returned MUST include node='mix'. The reason for this is to facilitate MIX channels and &xep0045; MUC rooms sharing the same JID. This extra parameter will enable a server to return appropriate information.
+The channel MUST return its identity and the features it supports. Note that a MIX channel MUST support MAM and so the response will always include both MIX and MAM support. All disco queries on a MIX channel and results returned MUST include the attribute node='mix'. The reason for this is to facilitate MIX channels and &xep0045; MUC rooms sharing the same JID. This extra parameter will enable a server to return appropriate information.
Use disco#items to find the nodes associated with a channel. The MIX service MUST only return nodes that exist and that the user making the query has rights to subscribe to. This query MUST be made directly by a client.
+Use disco#items to find the nodes associated with a channel. Discovering nodes in MIX MUST user the node='mix; attribute. The MIX service MUST only return nodes that exist and that the user making the query has rights to subscribe to.
The Information Node contains various information about the channel that can be useful to the user. This query MUST be made directly by a client.
-- 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. This query MUST be made directly by a client.
+ Online clients in the channel are determined from the presence node using PubSub. 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. For JID Hidden channels, only the nicks are returned. For JID Visible channels, nicks and real JIDs are returned. This query MUST be made directly by a client.- Where a client supports MIX, it MUST advertise this capability in response to a Disco request. This will enable other entities to determine if a client supports MIX, and in particular it facilitates the client's server to determine client support. This can be optimized by use of CAPS. The following example shows a Disco response from a client that supports both MIX and MUC. + Where a client supports MIX, it MUST advertise this capability in response to a Disco request. This will enable other entities to determine if a client supports MIX, and in particular it facilitates the client's server to determine client support. This can be optimized by use of CAPS. The following example shows a Disco request to and response from a client that supports both MIX and MUC.
-- 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 information). The following example is the message from the MIX channel to the user's server, which will be modified and sent to the client.
+ 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 error response will also include other nodes requested where subscription failed for the same reason. + ++ The following response example shows a successful 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 information). This example shows the message from the MIX channel to the user's server, which will be modified and sent to the client. +
The channel also adds the user to the participants node and sends a notification to subscribers to the participants node. The following example shows such a notification.
+The channel also adds the user to the participants node and sends a notification to subscribers of the participants node. The following example shows such a notification.
- As part of the channel joining process, the user's server MAY add the MIX channel to the user's roster using standard XMPP to update the roster. This is done to share the user's presence status with the channel and so the MIX channel will get presence information from the user. This roster entry will lead to the user's server correctly sending user's presence from all clients to the MIX channel. The roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information is sent about the MIX channel. The user's server MUST remove this roster entry after the user leaves the channel. + As part of the channel joining process, the user's server MAY add the MIX channel to the user's roster using standard XMPP to update the roster. This is done to share the user's presence status with the channel and so the MIX channel will get presence information from the user. This roster entry will lead to the user's server correctly sending user's presence from all clients to the MIX channel. The roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information is sent about the MIX channel to the user. The user's server MUST remove this roster entry after the user leaves the channel.
If the user does not wish to publish presence information to the channel, the user will not add the roster entry. A channel MAY require presence to be provided by all channel participants, which is controlled by the 'Participants Must Provide Presence' option. The channel MAY check that channel participants have done this and MAY remove participants that do not do this. @@ -974,7 +1000,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
A channel MAY store user preferences and parameters with each user. There are two preference options. +
A channel MAY store user preferences and parameters with each user. There are several standard preference options.
A user JID visibility preference have the following values: @@ -1148,7 +1174,7 @@ the participant is not be subscribed to all nodes associated with the channel (i The user's server will then generate a matching request to the MIX channel.
-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. +
A nick MAY be associated with the user's bare JID. 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 channel MAY enforce use of a registered nick. A channel MUST NOT use a registered nick for any other participant.
In order to determine if a Nick is allowed to be registered, the user MAY use disco to determine capabilities of the MIX service. @@ -1327,20 +1353,20 @@ the participant is not be subscribed to all nodes associated with the channel (i 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 needed 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 service 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 needed by the channel, an XMPP client conforming to this specification MUST share presence with the channel by including the channel in the user's roster. Note that the MIX service 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 participants using standard presence stanzas. + Presence status and availability is set in a MIX channel by standard presence stanzas sent to the MIX channel by the user's server. Users wishing to receive presence updates will subscribe to the MIX channel presence node. Presence updates are sent out to subscribing participants using standard presence stanzas.
- A user setting status is now used as an example. Unlike in &xep0045; 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 service 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.
+ A user setting status is now used as an example. Unlike in &xep0045; 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 service 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.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. +
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 from the user's server.
- 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 can be viewed. + 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. The history of this node will be held as PubSub format in the MAM archive, so that presence history can be viewed.
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 has a special mode where channel participants are allowed to 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. +
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 has a special mode where channel participants are allowed to grant rights for other users to join a channel enabled ('Participation Addition by Invitation from Participant'). 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:
@@ -1518,15 +1544,16 @@ the participant is not be subscribed to all nodes associated with the channel (i- 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. + 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 enabled. 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.
@@ -1834,7 +1862,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
- 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. Here a channel is created without specifying the channel name. Parameters for the channel MAY also be specified.
+ Channels 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. Here a channel is created without specifying the channel name. Parameters for the channel MAY also be specified.
- A common use case for an ad hoc channel is where two users are engaged in a 1:1 chat and wish to broaden the discussion. Prior to bringing more users into a channel, using standard invitation process, there is a need to move a dialogue. The first step is for one of the two users to create an ad hoc channel, as described in the previous section. The other user will then be invited, and can switch to the new channel.
+ A common use case for an ad hoc channel is where two users are engaged in a 1:1 chat and wish to broaden the discussion. Prior to bringing more users into a channel, using standard invitation process, there is a need to create and populate a channel. The first step is for one of the two users to create an ad hoc channel, as described in the previous section. The other user will then be invited, and can switch to the new channel.
It can also be useful to share some or all of the messages from the 1:1 discussion into the new channel. The mechanism to do this is to forward messages to be shared in the MUC using &xep0297;. A body SHOULD NOT be used in the outer message.
@@ -2082,7 +2110,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
type='result'>
In the fully integrated service item discovery on the MIX/MUC service determines a list of channels. The protocol used for this is the same in MUC and MIX. Discovery actions on a channel in MIX will use 'node=mix' in the discovery which will lead to the return of MIX channel specific information. If is not set, MUC room specific information is returned.
+ In the fully integrated service item discovery on the MIX/MUC service determines a list of channels. The protocol used for this is the same in MUC and MIX. Discovery actions on a channel in MIX MUST use 'node=mix' attribute in the discovery which will lead to the return of MIX channel specific information, as mandated for this discovery in MIX. If is not set, MUC room specific information is returned.
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: