+ Remove Legacy MIX Namespace; + Add mix element in message to hold MIX additional information; + Roster Update Clarifications; + Clarify when messages are delivered to clients; + Extend Roster Get to select format; + Ensure that text defining attributes and elements reference the namespace; + Change mix_nick_register to nick-register; + Separate namespace for roster information; + rename jidmap2 to jidmap-visible; + Namespace bump to mix:1; + Correct from in response of join/leave IQs; + Add capability for MIX in client's server; +
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 '123456#coven@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. +
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 '123456#coven@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:1' namespace. The nick associated with the user is mandatory and is stored in a <nick/> child element of the <participant/> element. The nick for each channel participant MUST be different to the nick of other participants.
When a user joins a channel, the user's bare JID is added to the participants node by the MIX service. When a user leaves a channel, they are removed from the participants node. The participants node MUST NOT be directly modified using pubsub.
@@ -499,7 +518,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
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. +
The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap'. 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 and JID Maybe Visible 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 and JID Maybe Visible channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:1' namespace. The real JID is stored in a <jid/> child element of the <participant/> element.The JID Maybe Visible Map node is a similar node to the JID Map node that is used in addition to the JID Map Node in JID Maybe Visible channels. All participants may subscribe to and access this node. It uses the same encoding as JID Map node and all participant JIDs MUST be included. Where a participant's preference is to not share the JID, the encoded participant value is the proxy JID. This will enable a user looking up a JID to clearly determine that the user preference is to not share the JID and to clearly distinguish this case from an erroneous proxy JID. +
The JID Maybe Visible Map node is a similar node to the JID Map node that is used in addition to the JID Map Node in JID Maybe Visible channels. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap-visible'. All participants may subscribe to and access this node. It uses the same encoding as JID Map node and all participant JIDs MUST be included. Where a participant's preference is to not share the JID, the encoded participant value is the proxy JID. This will enable a user looking up a JID to clearly determine that the user preference is to not share the JID and to clearly distinguish this case from an erroneous proxy JID.
- 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. + 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 using a <presence/> element qualified by the 'jabber:client' namespace. 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.
@@ -574,7 +592,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
- The MIX specification is built on layered services that have defined errors. This enables the core MIX specification to reflect primarily the successful use case, as in almost all cases the error reporting of the layer service provides what is needed. A message sender MUST be prepared to handle any valid error from the layer services. When a message receiver encounters an error situation, it MUST use the most appropriate layer server error to report this issue back to the sender. For example a message receiver might use the "not authorized" IQ error in response to a MIX disco that is not authorized. Errors for the following layer services need to be handled for MIX:
+ The MIX specification is built on layered services that have defined errors. This enables the core MIX specification to reflect primarily the successful use case, as in almost all cases the error reporting of the layer service provides what is needed. A message sender MUST be prepared to handle any valid error from the layer services. When a message receiver encounters an error situation, it MUST use the most appropriate layer server error to report this issue back to the sender. For example a receiving entity might use the "not authorized" error in response to a disco query that is not authorized. Errors for the following layer services need to be handled for MIX:
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: The MIX service then MUST return its identity and the features it supports, which MUST include the 'urn:xmpp:mix:1' 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 'urn:xmpp:mix:0' feature and MAY return the other features listed here:
+ A MIX service MUST return the 'urn:xmpp:mix:1' 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. A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to messages, and presence.
- This will lead to the server subscribing the user to each of the requested nodes associated with the channel. The MIX service will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.
+ A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to both messages and presence nodes. A user will typically subscribe to at least the message and/or presence nodes but MAY join and not subscribe to any nodes. The <join/> is a child element of <iq/> element. The <join/> element is qualified by the 'urn:xmpp:mix:1' namespace. The channel is specified by a 'channel' attribute in the <join/> element. The requested nodes are encoded as <subscribe/> child elements of the <join/> element.
+ The join leads to the server subscribing the user to each of the requested nodes associated with the channel. The MIX service will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.
The default MIX model is that only channel participants are allowed to subscribe to nodes. A MIX channel MAY allow non-participant subscription. This will be handled by clients directly subscribing to the desired PubSub nodes.
- 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. 'Owner' Bare JIDs with Owner rights as defined in ACL node. When a channel is created, the JID creating the channel is configured as an owner, unless this attribute is explicitly configured to another value. jid-multi - - 'Administrator' Bare JIDs with Administrator rights. jid-multi - - 'End of Life' The date and time at which the channel will be automatically removed by the server. If this is not set, the channel is permanent. text-single - - 'Nodes Present' Specifies which nodes are present. Presence of config nodes is implicit. Jidmap node MUST be present if participants node is present. 'avatar' means that both Avatar Data and Avatar Metadata nodes are present. list-multi 'participants'; 'presence'; 'information'; 'allowed'; 'banned'; 'jidmap2'; 'avatar' - 'Nodes Present' Specifies which nodes are present. Presence of config nodes is implicit. Jidmap node MUST be present if participants node is present. 'avatar' means that both Avatar Data and Avatar Metadata nodes are present. list-multi 'participants'; 'presence'; 'information'; 'allowed'; 'banned'; 'jidmap-visible'; 'avatar' - 'Messages Node Subscription' Controls who can subscribe to messages node. list-single 'participants'; 'allowed'; 'anyone' 'participants' 'Presence Node Subscription' Controls who can subscribe to presence node. list-single 'participants'; 'allowed'; 'anyone' 'participants' 'Participants Node Subscription' Controls who can subscribe to participants node. list-single 'participants'; 'allowed'; 'anyone'; 'nobody'; 'admins'; 'owners' 'participants'
-
The following response example shows a successful response to the initial request example where
@@ -1029,7 +1047,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
-
- A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request, as shown in the following example. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. + A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a <update-subscription/$gt; child element of <iq/> element. The <update-subscription/$gt; element is qualified by the 'urn:xmpp:mix:1' namespace. The requested notes are encoded as <subscribe/> child elements of the <update-subscription/$gt; element with the node name encoded as a 'node' attribute. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification.
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, by providing a form template in the result. This query is direct from the client to the MIX channel.
+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, by providing a form template in the result. The request is encoded as a <user-preference/> child element of <iq/>. <user-preference/> is qualified by the 'urn:xmpp:mix:1' namespace. The result is encoded as a form child element in the <user-preference/> element.
Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, a user sends a MIX "leave" command to the channel. When a user leaves the channel, the user's server will remove the channel from the user's roster. Leave commands are sent indirectly through the user's server, to enable roster removal. Leaving is initiated by a client request, as shown in the following example.
+Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, a user sends a MIX "leave" command to the channel. The leave command is encoded as a <leave/> child element of <iq/> element. The <leave/> element is qualified by the 'urn:xmpp:mix:1' namespace, with the channel specified as a 'channel" attribute. When a user leaves the channel, the user's server will remove the channel from the user's roster. Leave commands are sent indirectly through the user's server, to enable roster removal. Leaving is initiated by a client request, as shown in the following example.
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. @@ -1342,21 +1360,21 @@ This approach enables flexible support of multiple clients for a MIX channel pa
- 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. + 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. This command is a <setnick/> child element of <iq/> element. The <setnick/> element is qualified by the 'urn:xmpp:mix:1' namespace. The nick is encoded as a <nick/> child element of the <setnick/> element. 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.
- 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 &rfc7700;. + On successful nick assignment, 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 &rfc7700;. The channel MAY return a conflict error or other appropriate error.
- 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="urn:xmpp:mix:0#mix_nick_register"/>. + 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="urn:xmpp:mix:1#nick-register"/>.
To register a nick with the MIX service the user sends - a <register/> command to the service.
+ a register command to the service. This is encoded as a <register/> child element of an <iq/> element. The <register/> element is qualified by the urn:xmpp:mix:1' namespace. The nick is encoded in a <nick/> child element of the <register/> element.If the requested nick is already taken, the MIX service returns a <conflict/> error:
+If the requested nick is already taken and the MIX service does not assign an alternate nick, the MIX service MUST return a <conflict/> error:
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 &rfc4122;. +
If the register request does not contain a <nick/> element, then the MIX service MUST assign one. It is RECOMMENDED that the assigned nick is a UUID following &rfc4122;.
@@ -1459,18 +1477,27 @@ This approach enables flexible support of multiple clients for a MIX channel pa 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.
-+ The server then sends the presence information to roster entries. The following example then shows the presence message from the client's server to the MIX channel. +
+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 full proxy 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 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 full proxy JID of the client updating status. + Note that presence is associated with a client and so will have a full JID. The following example shows a presence message as distributed by the server to a presences subscriber.
+ The MIX channel then adds information to the message using a <mix> element qualified by the 'urn:xmpp:mix:1' namespace. This element contains two child elements: +
+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 local server. The message from value is the JID of the channel. To enable sender identification, the Nick and bare proxy JID of the sender are included in the message as MIX parameters. The id of the message is the ID from the MAM archive and NOT the id used by the sender. The message placed in the MAM archive is the reflected message without a 'to' element.
+ 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 local server. The message 'from' attribute is the JID of the channel. The id of the message is the ID from the MAM archive and NOT the id used by the sender. The message placed in the MAM archive is the reflected message without a 'to' attribute.- 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. + 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 <submission-id> element in the <mix> element of the message copy going back to the originator's bare JID. The <submission-id> element holds the original id provided by the sender. This enables the originator to correlate the received message with the message submitted.
- A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. If this is done the original message MAY be replaced by a tombstone. The protocol to request retraction does this by a message with a <retract> element as shown in the following example. + A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. If this is done the original message MAY be replaced by a tombstone. The protocol to request retraction does this by adding to the message a <retract> element qualified by the 'urn:xmpp:mix:1' namespace. The <retract> element MUST include an <id> attribute that holds the id of the original message. A message and it's retraction shown in the following example.
@@ -1706,7 +1753,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
The second approach is to leave a tombstone, which if taken MUST be done in the following manner. This is appropriate where it is desired to leave a record of the message that was redacted. - With this approach, the original message <body> is removed and replaced with a tombstone using the <retracted> element that shows the JID of user performing the retraction and the time of the retraction. + With this approach, the original message <body> is removed and replaced with a tombstone using the <retracted> element qualified by the 'urn:xmpp:mix:1' namespace that shows the JID of user performing the retraction and the time of the retraction.
- 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 allows invitation by participants. 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 allows invitation by participants. 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 invitation request is encoded as an <invite/> child element of an <iq/> element. The <invite/> element is qualified by the 'urn:xmpp:mix:1' namespace. <invite/> contains an <invitation/> child element, which contain <inviter/>, <invitee/>, <channel/> and <token/> child elements.
- The inviter can now send the invitee a message containing the invitation, as shown in the following example. + The inviter can now send the invitee a message containing the invitation within the <message/> element, as shown in the following example.
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.
+The invitation can now be used by the invitee to join a channel. The <invitation/> child element is simply added to the standard channel <join/> element, 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.
The invitee MAY send an acknowledgement back to the inviter, noting the status of the invitation. Values are:
+The invitee MAY send an acknowledgement back to the inviter, noting the status of the invitation. + This is encoded as an <invitation-ack/> child element of <message/> element. The <invitation-ack/> element is qualified by the 'urn:xmpp:mix:1' namespace. The <invitation-ack/> has an <invitation/> child element that encodes the invitation being acknowledged and a <value/> child element to encode the acknowledgement value. + <value/> has the following values:
- When there is a long term connection failure, the MIX channel will receive an error from the XMPP server indicating that a message failed to transfer to a recipient. When this happens, the MIX channel MUST take responsibility to ensure that the message is retransmitted and delivered. When the MIX channel detects a failure it will make use of an IQ Marker message to determine when the connection to the peer server is working again. Once the channel has received a response to the marker IQ it will retransmit the pending messages. + When there is a long term connection failure, the MIX channel will receive an error from the XMPP server indicating that a message failed to transfer to a recipient. When this happens, the MIX channel MUST take responsibility to ensure that the message is retransmitted and delivered. When the MIX channel detects a failure it will make use of an IQ Marker message to determine when the connection to the peer server is working again. Once the channel has received a response to the marker IQ it will retransmit the pending messages. The marker is encoded as a <marker/> child element of an <iq/> element. The <marker/> element is qualified by the 'urn:xmpp:mix:1' namespace.
- 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. A client can determine if it has permission to create a channel on a MIX service, which MAY be used to control options presented to the user. This is achieved by a disco command on the MIX service. If the 'urn:xmpp:mix:0#create-channel' feature is returned, the user is able 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. A client can determine if it has permission to create a channel on a MIX service, which MAY be used to control options presented to the user. This is achieved by a disco command on the MIX service. If the 'urn:xmpp:mix:1#create-channel' feature is returned, the user is able to create a channel.
- A client creates a channel by sending a simple request to the MIX service. A channel MAY be created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). Creating and destroying a channel is done direct from a client. + A client creates a channel by sending a simple request to the MIX service. A channel MAY be created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). The create is encoded as a <create/> child element of <iq/> element. The <create/> is qualified by the 'urn:xmpp:mix:1' namespace. The <create/> element MUST have a 'channel' attribute to specify the channel name.
@@ -2024,10 +2073,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
-
+ The destroy operation is encoded as a <destroy/> child element of an <iq/> element. The <destroy/> element is qualified by the 'urn:xmpp:mix:1' namespace. The <destroy/> element MUST have a 'channel' attribute to specify the channel to be destroyed. A client destroys a channel using a simple set operation, as shown in the following example.
+ The server receiving the message will then deliver the messages to all online clients. Messages are delivered to all available online resources irrespective of + status and resource priority. The following example shows how the participant's server modifies the inbound message to replace the bare JID in the 'to' with a full JID for each of two active MIX clients.
@@ -2406,8 +2460,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' type='groupchat'> Harpier cries: 'tis time, 'tis time. -+ Servers supporting the capabilities necessary to enable MIX clients MUST advertise this. A client wishing to use MIX MUST check for this capability in the server before using MIX. The capability is represented by the 'urn:xmpp:mix:account:0' feature. +
+
Most interaction between a MIX client and a MIX channel is directly between the client and the channel. The participant's server relays the message but does not modify the messages. In particular configuration management and discovery is direct. Interaction will be direct, unless explicitly stated otherwise.
@@ -2448,7 +2529,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example/UUID-a1j/7533'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
-
It will be useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A standard roster item is encoded as follows.
+It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A MIX client MAY request that the server return this additional information that annotates roster elements with MIX capability. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a child element <annotate/> to the <query/> element. The <annotate/> element is qualified by the ‘urn:xmpp:mix:roster:0' namespace.
+A standard roster item is encoded as follows.
- MIX channels in the roster have an attribute 'channel' set to true. + MIX channels in the roster information returned in response to a request for this additional MIX information MUST have an element <channel/> qualified by the ‘urn:xmpp:mix:roster:0' namespace included in the roster item, as shown inf the following example.
- When sending roster information to a client that advertises MIX capability, the server MUST return all MIX channels and MUST use this encoding. Presence of MIX roster items MUST be set to offline (unavailable). -
- -- Where a client does not advertise MIX capability, the server MAY choose to not return MIX channels as roster items. If this is done care needs to be taken, in particular around support of roster versioning &xep0237;. -
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.
+The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:1#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.
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.
+The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:1#serviceinfo'. The field with var='mix-mirror' is the value of which is the mirrored MIX domain's JID.
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
@@ -2668,7 +2753,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
Thanks to the following who have made contributions: Dave Cridland, Philipp Hancke, Waqas Hussain, Timothée Jaussoin, Evgeny Khramtsov, Georg Lukas, Tobias Markmann, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Jonas Wielicki, Matthew Wild and one anonymous reviewer. Thanks to the following who have made contributions: Dave Cridland, Tarun Gupta, Philipp Hancke, Waqas Hussain, Timothée Jaussoin, Evgeny Khramtsov, Georg Lukas, Tobias Markmann, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Jonas Wielicki, Matthew Wild and one anonymous reviewer.