From 8e5e03168ad14c9b97dfc82a7448b7411eb3a179 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Tue, 20 Jun 2017 09:42:17 +0100 Subject: [PATCH] Namespace bump to mix:1 --- xep-0369.xml | 213 ++++++++++++++++++++++++++------------------------- 1 file changed, 107 insertions(+), 106 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 5e68193c..cf683589 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -50,6 +50,7 @@ Change mix_nick_register to nick-register; Separate namespace for roster information; rename jidmap2 to jidmap-visible; + version bump to urn:xmpp:mix:1;

@@ -503,7 +504,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa -

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:0' 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. +

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. @@ -515,7 +516,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - + thirdwitch @@ -526,11 +527,11 @@ 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. 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. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:0' namespace. The real JID is stored in a <jid/> child element of the <participant/> element.

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

- + hecate@mix.shakespeare.example @@ -590,7 +591,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - urn:xmpp:mix:0 + urn:xmpp:mix:1 Witches Coven @@ -670,7 +671,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - urn:xmpp:mix:0 + urn:xmpp:mix:1 hecate@shakespeare.lit @@ -742,7 +743,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]> -

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:

    -
  • 'urn:xmpp:mix:0': This indicates support of MIX, and is returned by all MIX services.
    • -
  • 'urn:xmpp:mix:0#searchable': This is shown in the above example and indicates that a the MIX Service MAY be searched for channels. This presence of this feature can be used by a client to guide the user to search for channels in a MIX service.
    • -
  • 'urn:xmpp:mix:0#create-channel': This is described in Checking for Permission to Create a Channel in support of channel administration. When an end user client needs to create channels, perhaps for short term usage, this feature helps the client to identify an MIX service to use. It enables a configuration where permanent (searchable) channels are placed in one MIX service and clients will be able to create channels in another MIX service which is not searchable.
    • +
  • 'urn:xmpp:mix:1': This indicates support of MIX, and is returned by all MIX services.
    • +
  • 'urn:xmpp:mix:1#searchable': This is shown in the above example and indicates that a the MIX Service MAY be searched for channels. This presence of this feature can be used by a client to guide the user to search for channels in a MIX service.
    • +
  • 'urn:xmpp:mix:1#create-channel': This is described in Checking for Permission to Create a Channel in support of channel administration. When an end user client needs to create channels, perhaps for short term usage, this feature helps the client to identify an MIX service to use. It enables a configuration where permanent (searchable) channels are placed in one MIX service and clients will be able to create channels in another MIX service which is not searchable.

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.

@@ -812,7 +813,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa category='conference' name='A Dark Cave' type='mix'/> - + @@ -866,10 +867,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa + - urn:xmpp:mix:0 + urn:xmpp:mix:1 Witches Coven @@ -909,12 +910,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa - + thirdwitch - + top witch @@ -949,7 +950,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - + ]]> @@ -959,7 +960,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa -

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. The <join/> is a child element of <iq/> element. The <join/> element is qualified by the 'urn:xmpp:mix:0' 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. +

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

@@ -975,7 +976,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'> - @@ -993,7 +994,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'> - + @@ -1007,7 +1008,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='coven@mix.shakespeare.example' to='hag66@shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + @@ -1025,7 +1026,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='coven@mix.shakespeare.example' to='hag66@shakespeare.example/UUID-a1j/7533' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + @@ -1045,7 +1046,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'> - + @@ -1060,7 +1061,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - + @@ -1071,14 +1072,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa At the same time the participant MUST be added to the JID Map node, to map from proxy JID to real JID. For a JID Maybe Visible channel, the participant MUST be added to the JID Maybe Visible Map node. The value in this node MUST reflect the user's visibility preference for the channel and MUST be updated to reflect any changes to this preference.

- 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:0' 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. + 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.

- + @@ -1087,7 +1088,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='coven@mix.shakespeare.example' to='hag66@shakespeare.example/UUID-a1j/7533' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + @@ -1143,12 +1144,12 @@ 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'> - + - urn:xmpp:mix:0 + urn:xmpp:mix:1 never @@ -1163,12 +1164,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='coven@mix.shakespeare.example' to='hag66@shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + - urn:xmpp:mix:0 + urn:xmpp:mix:1 never @@ -1183,23 +1184,23 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]> -

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:0' namespace. The result is encoded as a form child element in the <user-preference/> element.

+

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.

- + - + - urn:xmpp:mix:0 + urn:xmpp:mix:1 @@ -1226,10 +1227,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='hag66@shakespeare.example/UUID-a1j/7533' to='coven@mix.shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + - urn:xmpp:mix:0 + urn:xmpp:mix:1 never @@ -1247,10 +1248,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='coven@mix.shakespeare.example' to='hag66@shakespeare.example/UUID-a1j/7533' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + - urn:xmpp:mix:0 + urn:xmpp:mix:1 never @@ -1268,7 +1269,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa -

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

+

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.

- ]]> @@ -1290,7 +1291,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'> - + ]]> @@ -1302,7 +1303,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='coven@mix.shakespeare.example' to='hag66@shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + ]]> @@ -1316,7 +1317,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='coven@mix.shakespeare.example' to='hag66@shakespeare.example/UUID-a1j/7533' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + ]]>

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. @@ -1358,14 +1359,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa

  • The MIX service generates the nick. In this case it is RECOMMENDED that the assigned nick is a UUID following &rfc4122;.

    • - 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:0' 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. + 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.

    - + thirdwitch @@ -1380,7 +1381,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='coven@mix.shakespeare.example' to'hag66@shakespeare.example/UUID-a1j/7533' id='7nve413p'> - + thirdwitch @@ -1406,22 +1407,22 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='mix.shakespeare.example' id='7nve413p'> - + ]]>

    - 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#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. This is encoded as a <register/> child element of an <iq/> element. The <register/> element is qualified by the urn:xmpp:mix:0' namespace. The nick is encoded in a <nick/> child element of the <register/> element.

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

    - + thirdwitch @@ -1437,7 +1438,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa to='mix.shakespeare.example' from='hag66@shakespeare.example/UUID-a1j/7533' id='7nve413p'> - + thirdwitch @@ -1547,7 +1548,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - + hecate@mix.shakespeare.example @@ -1589,7 +1590,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - + hecate@mix.shakespeare.example @@ -1661,7 +1662,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]>

    - The MIX channel then adds information to the message using a <mix> element qualified by the 'urn:xmpp:mix:0' namespace. This element contains two child elements: + 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:

    1. A <nick> element that contains the Nick of the message sender, taken from the Participants Node.
      2. @@ -1676,7 +1677,7 @@ 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. - + thirdwitch 123456#coven@mix.shakespeare.example @@ -1689,7 +1690,7 @@ 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. - + thirdwitch 123456#coven@mix.shakespeare.example @@ -1704,7 +1705,7 @@ 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. - + thirdwitch 123456#coven@mix.shakespeare.example 92vax143g @@ -1715,13 +1716,13 @@ This approach enables flexible support of multiple clients for a MIX channel pa

      - 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:0' namespace 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 as shown in the following example.

      - + ]]>

      @@ -1735,7 +1736,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 qualified by the 'urn:xmpp:mix:0' namespace 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.

      @@ -1744,7 +1745,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - @@ -1772,14 +1773,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa
    2. The invitee MAY send a response to the inviter, indicating if the invitation was accepted or declined.

    - The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel 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:0' namespace. <invite/> contains an <invitation/> child element, which contain <inviter/>, <invitee/>, <channel/> and <token/> child elements. + 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.

    - + cat@shakespeare.lit @@ -1789,7 +1790,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='kl2fax27' to='hag66@shakespeare.lit/UUID-h5z/0253' type='result'> - + hag66@shakespeare.lit cat@shakespeare.lit @@ -1807,7 +1808,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='f5pp2toz' to='cat@shakespeare.lit'> Would you like to join the coven? - + hag66@shakespeare.lit cat@shakespeare.lit coven@mix.shakespeare.lit @@ -1821,7 +1822,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='cat@shakespeare.example' to='coven@mix.shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + hag66@shakespeare.lit @@ -1833,7 +1834,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]>

    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:0' 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. + 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:

    • 'Joined': The invitee has joined the channel.
      • @@ -1845,7 +1846,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='b6p9llze' to='hag66@shakespeare.lit/UUID-h5z/0253'> No Thanks - too busy chasing mice.... - + Declined hag66@shakespeare.lit @@ -1952,14 +1953,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa It is important that messages are all transferred from the MIX channel to the server associated with the each channel participant. Transfer between servers will typically happen quickly and &xep0198; will deal with short connection failures between servers. Longer connection failures could lead to message loss. This would lead to online users (who remain connected to their servers) missing messages, and to messages being missed out of the user archive. This section describes how MIX addresses this.

      - 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:0' namespace. + 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.

      - + @@ -1967,7 +1968,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='lx09df27' to='coven@mix.shakespeare.example' type='result'> - + ]]> @@ -2003,7 +2004,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

      - 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). The create is encoded as a <create/> child element of <iq/> element. The <create/> is qualified by the 'urn:xmpp:mix:0' namespace. The <create/> element MUST have a 'channel' attribute to specify the channel name. + 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.

      - + - + ]]>

      @@ -2055,10 +2056,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='lx09df27' to='mix.shakespeare.example' type='set'> - + - urn:xmpp:mix:0 + urn:xmpp:mix:1 hecate@shakespeare.lit @@ -2081,7 +2082,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='lx09df27' to='hag66@shakespeare.example/UUID-a1j/7533' type='result'> - + ]]> @@ -2097,14 +2098,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='lx09df27' to='mix.shakespeare.example' type='set'> - + - + ]]> @@ -2140,7 +2141,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa MIX channels are always explicitly destroyed by an owner of the channel or by a server operator. There is no concept of temporary channel, equivalent to &xep0045; temporary room which is automatically destroyed by the server when the users leave. However, channels MAY be configured with an explicit lifetime, after which the channel MUST be removed by the MIX service. Where a channel is created for ad hoc use, it MAY be desirable to keep the channel for history reference or for re-use by the same set of users. Note that the owner of the channel does not need to have presence registered in the channel in order to destroy it.

      - The destroy operation is encoded as a <destroy/> child element of an <iq/> element. The <destroy/> element is qualified by the 'urn:xmpp:mix:0' namespace. The <destroy/> element MUST have a 'channel' attribute to specify the channel to be destroyed. + 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.

      - + - urn:xmpp:mix:0 + urn:xmpp:mix:1 Information Node Modification - urn:xmpp:mix:0 + urn:xmpp:mix:1 Witches Coven @@ -2236,7 +2237,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='result'> - + @@ -2260,10 +2261,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa to='hag66@shakespeare.example/UUID-a1j/7533' type='result'> - + - urn:xmpp:mix:0 + urn:xmpp:mix:1 Configuration Node Modification - urn:xmpp:mix:0 + urn:xmpp:mix:1 hecate@shakespeare.lit @@ -2310,7 +2311,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='result'> - + @@ -2423,7 +2424,7 @@ 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. - + thirdwitch 123456#coven@mix.shakespeare.example @@ -2442,7 +2443,7 @@ 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. - + thirdwitch 123456#coven@mix.shakespeare.example @@ -2453,7 +2454,7 @@ 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. - + thirdwitch 123456#coven@mix.shakespeare.example @@ -2488,7 +2489,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'> - @@ -2505,7 +2506,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'> - + @@ -2587,11 +2588,11 @@ This approach enables flexible support of multiple clients for a MIX channel pa category='conference' name='Shakespearean Chat Service' type='text'/> - + - urn:xmpp:mix:0#serviceinfo + urn:xmpp:mix:1#serviceinfo @@ -2610,10 +2611,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa category='conference' name='Shakespearean Chat Service' type='text'/> - + - urn:xmpp:mix:0#serviceinfo + urn:xmpp:mix:1#serviceinfo ]]> -

      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.

      - urn:xmpp:mix:0#serviceinfo + urn:xmpp:mix:1#serviceinfo ]]> -

      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