moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

RFC 2119 compliance

Browse Source
This commit is contained in:
Steve Kille 2017-01-30 14:21:13 +00:00 committed by Sam Whited
parent 448f4c66e2
commit 1e93c5efd6
1 changed files with 100 additions and 92 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

192
xep-0369.xml
View File

@ -36,6 +36,14 @@
&ksmithisode;
&skille;
&stpeter;
<revision>
<version>0.7.1</version>
<date>2017-01-30</date>
<initials>sek</initials>
<remark><p>
Ensure all RFC 2119 keywords are capitalized and used correctly
</p></remark>
</revision>
<revision>
<version>0.7</version>
<date>2017-01-27</date>
@ -199,7 +207,7 @@
<li>XMPP clients can implement MUC and this specification in a way that provides a coherent user experience.</li>
<li>XMPP servers can implement this specification and also provide a MUC interface in order to support clients that only implement MUC.</li>
</ul>
<p>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.</p>
<p>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.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
@ -208,12 +216,12 @@
<ol>
<li>A user's participation in a channel persists and is not modified by the user's client going online and offline.</li>
<li>Multiple devices associated with the same account can share the same nick in the channel, with well-defined rules making each client individually addressable.</li>
<li>Channels are not required to support or reflect presence for participants.</li>
<li>Channels are NOT REQUIRED to support or reflect presence for participants.</li>
<li>A reconnecting client can quickly resync with respect to messages and presence.</li>
<li>A user may (subject to configuration) receive messages from a channel as an invisible observer.</li>
<li>A user MAY (subject to configuration) receive messages from a channel as an invisible observer.</li>
<li>Configuration can be observed externally to the channel (e.g., list of participants, access control rights, etc.).</li>
<li>MIX services should provide mechanisms to prevent JIDs from being harvested.</li>
<li>MIX and Message Archive Management (MAM) should work well together.</li>
<li>MIX services SHOULD provide mechanisms to prevent JIDs from being harvested.</li>
<li>MIX and Message Archive Management (MAM) MUST work well together.</li>
<li>A user can determine which channels they participate in.</li>
<li>Provide extensibility regarding data formats that can be sent within a channel (files, structured data, indications about media sources in multimedia conferences, etc.) as well as flexibility regarding which data formats a user wants to receive.</li>
<li>Enable federation of a channel across multiple servers, to provide a service equivalent to "federated MUC" &xep0289;.</li>
@ -227,7 +235,7 @@
<section2 topic="Core Concepts" anchor="concepts-core">
<p>The following concepts underlie the design of MIX.</p>
<ol>
<li>MIX channels (roughly equivalent to MUC rooms) are hosted on one or more MIX domains, (examples: 'mix.example.com'; 'conference.example.com'; 'talk.example.com'), which are discoverable through &xep0030;. Each channel on a MIX service may then be discovered and queried.</li>
<li>MIX channels (roughly equivalent to MUC rooms) are hosted on one or more MIX domains, (examples: 'mix.example.com'; 'conference.example.com'; 'talk.example.com'), which are discoverable through &xep0030;. Each channel on a MIX service can then be discovered and queried.</li>
<li> In MIX each channel (e.g., 'channel@mix.example.com') is a pubsub service. This is based on the model from &xep0163; where every user JID (e.g., 'user@example.com') is its own pubsub service. </li>
<li>A channel's pubsub service contains a number of nodes for different event types or data formats. As described below, this document defines several standard nodes; however, future specifications or proprietary services can define their own nodes for extensibility.</li>
<li>Affiliations with the nodes are managed by the MIX service by channel level operations, so that the user does not have to separately manage affiliations with the individual PubSub nodes.
@ -254,7 +262,7 @@
</section2>
<section2 topic="Behaviour of MIX Participant's Server" anchor="concepts-mix-participant-server">
<p>
A MIX channel does not send messages and presence directly to an XMPP MIX client of a channel participant, but addresses them to participant using the participant's bare JID. The participant's server must then handle these messages and pass them on to zero, one or multiple clients. To enable MIX to work, this behaviour is necessary and so the server of every MIX client must follow the rules set out in this specification.
A MIX channel does not send messages and presence directly to an XMPP MIX client of a channel participant, but addresses them to participant using the participant's bare JID. The participant's server MUST then handle these messages and pass them on to zero, one or multiple clients. To enable MIX to work, this behaviour is necessary and so the server of every MIX client MUST follow the rules set out in this specification.
This approach enables flexible support of multiple clients for a MIX channel participant.
The MIX model is that a user will join a channel over an extended period, and that the user (not a specific client used by the user) joins the channel. The primary subscription is with the client's bare JID.
There are a number of MIX requirements on behaviour of the MIX Participant's server, which are summarized here:
@ -268,7 +276,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<li>The MIX participant's server will only send messages to online clients and will discard messages if no clients are online.
This means that a MIX client needs to resynchronize with the MIX service when it comes online. This message synchronization will happen between the MIX client and the MAM archive held on the MIX participant's server.</li>
<li>The MIX participant's server handles channel registration and de-registration in the user's roster.</li>
<li>Different clients may wish to access different channels (e.g., a mobile client may only access a subset of the channels in which a user is interested). MIX Client Activation allows the participant's server to support this.</li>
<li>Enabling different clients to access different sets of channels (e.g., a mobile client only accesses a subset of the channels in which a user is interested). MIX Client Activation allows the participant's server to support this.</li>
</ol>
<p>
Messages being sent from MIX channel to a MIX participant’s server (which will be of type=groupchat) and presence information are sent to the bare JID. This means that the MIX participant's server MUST support a modification of the standard &rfc6121; rules.
@ -279,7 +287,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</section2>
<section2 topic="User Presence in MIX" anchor="concepts-presence">
<p>
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 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.
</p>
<p>
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.
@ -307,7 +315,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<tr><td>'JID&nbsp;Hidden'</td><td>In these channels, no participant JIDs are visible to channel participants, but they are visible to channel administrators.</td></tr>
</table>
<p>
A channel participant may specify their preferences for JID visibility, with one of the following values:
A channel participant MAY specify their preferences for JID visibility, with one of the following values:
</p>
<table caption="JID Visibility Preference Options">
<tr><th>Preference</th><th>Description</th></tr>
@ -324,13 +332,13 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</p>
</section2>
<section2 topic="Standard Nodes" anchor="concepts-nodes">
<p>MIX defines a number standard nodes are as follows. Note that all nodes are optional and that not every channel will necessarily use each node:</p>
<p>MIX defines a number standard nodes are as follows. Note that all nodes are OPTIONAL and that not every channel will necessarily use each node:</p>
<table caption="Standard MIX Nodes">
<tr><th>Name</th><th>Node</th><th>Description</th><th>Update</th><th>Distribution</th></tr>
<tr><td>Messages</td><td>'urn:xmpp:mix:nodes:messages'</td><td>For distributing messages to the channel. Each item of this node will contain a message sent to the channel.</td><td>Message</td><td>Message</td></tr>
<tr><td>Participants</td><td>'urn:xmpp:mix:nodes:participants'</td><td>For storing the list of participants and the associated nick. Channel participants are added when they join the channel and removed when they leave </td><td>Join/Leave/Set Nick</td><td>PubSub</td></tr>
<tr><td>JID Map</td><td>'urn:xmpp:mix:nodes:jidmap'</td><td>For storing a list of anonymized bare JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs.</td><td>Automatic</td><td>PubSub</td></tr>
<tr><td>Presence</td><td>'urn:xmpp:mix:nodes:presence'</td><td>For storing information about the availability status of online participants, which may include multiple clients for a single participant.</td><td>Presence</td><td>Presence</td></tr>
<tr><td>Presence</td><td>'urn:xmpp:mix:nodes:presence'</td><td>For storing information about the availability status of online participants, which MAY include multiple clients for a single participant.</td><td>Presence</td><td>Presence</td></tr>
<tr><td>Information</td><td>'urn:xmpp:mix:nodes:info'</td><td>For storing general channel information, such as description. </td><td>PubSub</td><td>PubSub</td></tr>
<tr><td>Subject</td><td>'urn:xmpp:mix:nodes:subject'</td><td>For storing and sharing the current subject of a channel</td><td>Message</td><td>Message</td></tr>
<tr><td>Allowed</td><td>'urn:xmpp:mix:nodes:allowed'</td><td>For storing JIDs that are allowed to be channel participants.</td><td>PubSub</td><td>PubSub</td></tr>
@ -338,11 +346,11 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<tr><td>Configuration</td><td>'urn:xmpp:mix:nodes:config'</td><td>For storing channel configuration. </td><td>PubSub</td><td>PubSub</td></tr>
</table>
<p>
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 combinations 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.
</p>
<p>
MIX also makes use of two nodes for support of Avatars. These nodes and their use is defined in &xep0084;. These nodes may be created as part of a MIX channel, where it is desired to publish an avatar associated with the channel.
MIX also makes use of two nodes for support of Avatars. These nodes and their use is defined in &xep0084;. These nodes MAY be created as part of a MIX channel, where it is desired to publish an avatar associated with the channel.
</p>
<table caption="MIX Nodes for Avatar Support">
<tr><th>Name</th><th>Node</th><th>Description</th></tr>
@ -359,13 +367,13 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<table caption="Channel Roles">
<tr><th>Role</th><th>Membership and Rights</th></tr>
<tr><td>Owners</td><td>These are owners of the list, as specified in the channel configuration node. Only owners are allowed to modify the channel configuration node.</td></tr>
<tr><td>Administrators</td><td>Administrators are defined in the channel configuration node. Administrators have update rights to the Allowed Node and Banned Node, so can control which users may participate in a channel. </td></tr>
<tr><td>Administrators</td><td>Administrators are defined in the channel configuration node. Administrators have update rights to the Allowed Node and Banned Node, so can control which users are allowed to participate in a channel. </td></tr>
<tr><td>Participants</td><td>Participants are users listed by JID in the participants node.</td></tr>
<tr><td>Allowed</td><td>Allowed is the set of JIDs that are participants or may be allowed to become participants. A JID is allowed if it does not match entry in the banned node and either it matches an entry in the allowed node or the allowed node is not present. </td></tr>
<tr><td>Allowed</td><td>Allowed is the set of JIDs that are participants or are allowed to become participants. A JID is allowed if it does not match entry in the banned node and either it matches an entry in the allowed node or the allowed node is not present. </td></tr>
<tr><td>Anyone</td><td>Any user, including users in the banned node.</td></tr>
</table>
<p>
There will always be at lease one owner and "anyone" will always have role occupants. Other roles may not have any role occupants. Rights are defined in a strictly hierarchical manner, so that for example Owners will always have rights that Administrators have.
There will always be at lease one owner and "anyone" will always have role occupants. Other roles MAY NOT have any role occupants. Rights are defined in a strictly hierarchical manner, so that for example Owners will always have rights that Administrators have.
</p>
</section3>
<section3 topic="Messages Node" anchor="messages-node">
@ -380,7 +388,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
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.
This node MAY be subscribed to for jid-visible channels that permit subscription to this node - this will allow users to see changes to the channel participants.
</p>
<p>The participants node is optional. If the Participants Node is not used, information on channel participants is not shared. If there is no participants node, the access control value 'participants' MUST NOT be used.</p>
<p>The participants node is OPTIONAL. If the Participants Node is not used, information on channel participants is not shared. If there is no participants node, the access control value 'participants' MUST NOT be used.</p>
<example caption="Value of Participants Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:participants'>
<item id='coven+123456@mix.shakespeare.example'>
@ -394,7 +402,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<p>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. </p>
In JID visible channels, all participants MAY subscribe to this node. In JID hidden channels, only administrators can subscribe. </p>
<example caption="Value of JID Map Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:jidmap'>
<item id='coven+123456@mix.shakespeare.example'>
@ -406,11 +414,11 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</section3>
<section3 topic="Presence Node" anchor="presence-node">
<p>
The presence node contains the presence value for clients belonging to participants that choose to publish presence to the channel. A MIX channel MAY require that all participants publish presence. Each item in the presence node is identified by the full proxy JID, and contains the current presence value for that JID. The presence is encoded in the same way as data that would be sent in a presence stanza. The full JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control may be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list.
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.
</p>
<p>
This node may be subscribed to by users and this subscription MUST use the users bare JID. So presence of online clients is sent to the user's server for each user subscribed to this node. Presence is always sent using standard presence protocol and NOT using pubsub protocol. Clients MUST NOT directly access the presence node using pubsub.
This node MAY be subscribed to by users and this subscription MUST use the users bare JID. So presence of online clients is sent to the user's server for each user subscribed to this node. Presence is always sent using standard presence protocol and NOT using pubsub protocol. Clients MUST NOT directly access the presence node using pubsub.
</p>
<example caption="Value of Presence Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:presence'>
@ -426,7 +434,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section3 topic="Information Node" anchor="info-node">
<p>The Information node holds information about the channel. The information node contains a single item with the current information. Information node history is held in MAM.
The information node is named by the date/time at which the item was created. The information node is accessed and managed using standard pubsub. Users MAY subscribe to this node to receive information updates. The Information node item may contain the following attributes, each of which is optional:
The information node is named by the date/time at which the item was created. The information node is accessed and managed using standard pubsub. Users MAY subscribe to this node to receive information updates. The Information node item MAY contain the following attributes, each of which is OPTIONAL:
</p>
<table caption="Information Node Attributes">
<tr><th>Name</th><th>Description</th><th>Field Type</th><th>Values</th><th>Default</th></tr>
@ -461,7 +469,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section3 topic="Subject Node" anchor="subject-node">
<p>The subject node publishes the current subject of channel. Subject history is stored in MAM. A single item is stored in this node at a time which MUST contain a "text" element and MAY contain additional text elements. Where multiple text elements are provided, each MUST posses an xml:lang attribute that describes the natural language of the subject. </p>
<p>
Setting and sharing subject uses a message with subject element, in a manner compatible with &xep0045;. Clients MAY also write or access this node using pubsub. Writes to this node will lead to update of subject by sending messages. Setting the subject is controlled by configuration; in some channels it may be set by all users and in others restricted to administrators.
Setting and sharing subject uses a message with subject element, in a manner compatible with &xep0045;. Clients MAY also write or access this node using pubsub. Writes to this node will lead to update of subject by sending messages. Setting the subject is controlled by configuration; in some channels it MAY be set by all users and in others restricted to administrators.
The following example shows the format of a item in the subject node.
</p>
<example caption="Subject Node">
@ -499,7 +507,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</section3>
<section3 topic="Configuration Node" anchor="config-node">
<p>
The Configuration node holds the configuration of the channel as a single item, named by the date-time of the last update to the configuration. A single item is stored in the node, with previous configuration history accessed by MAM. Users with read access to the configuration node MAY subscribe to the configuration node to get notification of configuration change. This node is accessed and managed using standard pubsub. The configuration node is optional for a MIX channel. For example, configuration choices could be fixed and not exposed. A subset of the defined configuration options may be used and additional non-standard configuration options may be added. JIDs in the configuration MUST be real bare JIDs and not proxy JIDs. If configuration options to control functionality of the nature described here are provided, the options defined in this standard MUST be used. The following configuration attributes are defined:
The Configuration node holds the configuration of the channel as a single item, named by the date-time of the last update to the configuration. A single item is stored in the node, with previous configuration history accessed by MAM. Users with read access to the configuration node MAY subscribe to the configuration node to get notification of configuration change. This node is accessed and managed using standard pubsub. The configuration node is OPTIONAL for a MIX channel. For example, configuration choices could be fixed and not exposed. A subset of the defined configuration options MAY be used and additional non-standard configuration options MAY be added. JIDs in the configuration MUST be real bare JIDs and not proxy JIDs. If configuration options to control functionality of the nature described here are provided, the options defined in this standard MUST be used. The following configuration attributes are defined:
</p>
<table caption="Configuration Node Attributes">
<tr><th>Name</th><th>Description</th><th>Field Type</th><th>Values</th><th>Default</th></tr>
@ -519,12 +527,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<tr><td>'Information Node Update Rights'</td><td>Controls who can make changes to the information node</td><td>list-single</td><td>'participants'; 'admins'; 'owners' </td><td>'admins'</td></tr>
<tr><td>'Avatar Nodes Update Rights'</td><td>Controls who can make changes to the avatar data and metadata nodes</td><td>list-single</td><td>'participants'; 'admins'; 'owners' </td><td>'admins'</td></tr>
<tr><td>'JID Visibility'</td><td>Controls JID visibility in the channel.</td><td>list-single</td><td>'jid-hidden'; 'jid-optionally-visible'; 'jid-mandatory-visible'</td><td>'jid-hidden'</td></tr>
<tr><td>'Open Presence'</td><td>If selected, any client may register presence. If not selected, only clients with bare JID in the participants list may register presence.</td><td>boolean</td><td>-</td><td>false</td></tr>
<tr><td>'Participants Must Provide Presence'</td><td>If selected, all channel participants are required to share presence information with the channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
<tr><td>'Open Presence'</td><td>If selected, any client MAY register presence. If not selected, only clients with bare JID in the participants list are allowed to register presence.</td><td>boolean</td><td>-</td><td>false</td></tr>
<tr><td>'Participants Must Provide Presence'</td><td>If selected, all channel participants are REQUIRED to share presence information with the channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
<tr><td>'Allow User Message Retraction'</td><td>If this option is selected users will be able to retract messages sent to the MIX channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
<tr><td>'Administrator Message Retraction Rights'</td><td>This controls which group is able to retract messages sent to the MIX channel.</td><td>list-single</td><td>'nobody'; 'admins'; 'owners'</td><td>'owners'</td></tr>
<tr><td>'Participation Addition by Invitation from Participant'</td><td>This option extends a channel so that a channel participant has rights to invite and enable other users as participants.</td><td>boolean</td><td>-</td><td>false</td></tr>
<tr><td>'No Private Messages'</td><td>If this option is selected, private messages may not be used with the channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
<tr><td>'No Private Messages'</td><td>If this option is selected, private messages MUST NOT be used with the channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
</table>
<p>
The configuration node is in &xep0004; format and includes all of the options used by the channel, including values for options using default values. This means that the value in the form can be directly mapped with the form returned by configuration administration commands. Configuration nodes will typically have a large number of elements. The following short example is provided to illustrate the syntax of the configuration node.
@ -559,7 +567,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</section2>
<section2 topic="Non-Standard Nodes" anchor="non-standard-nodes">
<p>
The MIX standard allows channels to use non-standard nodes, using names that do no conflict with the standard nodes. The capabilities of these nodes may be specified in a future XEP or be for private agreement. Non-Standard nodes MUST NOT duplicate or otherwise provide capability that can be provided by standard nodes.
The MIX standard allows channels to use non-standard nodes, using names that do no conflict with the standard nodes. Non-Standard nodes MUST NOT duplicate or otherwise provide capability that can be provided by standard nodes.
</p>
</section2>
</section1>
@ -567,7 +575,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section1 topic='Discovery' anchor='discovery'>
<section2 topic='Discovering a MIX service' anchor='disco-service'>
<p>
An entity may discover a MIX service or MIX services by sending a Service Discovery items ("disco#items") request to its own server.
An entity MAY discover a MIX service or MIX services by sending a Service Discovery items ("disco#items") request to its own server.
</p>
<example caption="Entity queries Server for associated services" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
@ -589,7 +597,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</query>
</iq>
]]></example>
<p>To determine if a domain hosts a MIX service, a &xep0030; info query should be sent in the usual manner to determine capabilities.</p>
<p>To determine if a domain hosts a MIX service, a &xep0030; info query SHOULD be sent in the usual manner to determine capabilities.</p>
<example caption="Entity queries a service" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
id='lx09df27'
@ -615,12 +623,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</iq>
]]></example>
<p>
A MIX service may return the following features:
A MIX service MUST return the first feature listed and MAY return the other features listed:
</p>
<ul>
<li>'urn:xmpp:mix:0': This indicates support of MIX, and is returned by all MIX services.</li>
<li>'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.</li>
<li>'create-channel': This is described in <link url='#usecase-admin-check-create'> Checking for Permission to Create a Channel</link> in support of channel administration. An end user client may need to create channels, perhaps for short term usage. This feature helps the client to identify an MIX channel 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.</li>
<li>'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.</li>
<li>'create-channel': This is described in <link url='#usecase-admin-check-create'> Checking for Permission to Create a Channel</link> 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.</li>
</ul>
<p>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.</p>
</section2>
@ -705,7 +713,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
]]></example>
</section2>
<section2 topic="Determining Information about a Channel" anchor="find-channel-info">
<p>The Information Node contains various information about the channel that may be useful to the user. This can be read by the XMPP Client directly or by the user's server.</p>
<p>The Information Node contains various information about the channel that can be useful to the user. This can be read by the XMPP Client directly or by the user's server.</p>
<example caption='User&apos;s Server Requests Channel Information'><![CDATA[
<iq from='hag66@shakespeare.lit'
id='kl2fax27'
@ -792,7 +800,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
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.
</p>
<p>The default MIX model is that only channel participants may subscribe to nodes. A MIX channel MAY allow non-participant subscription. This will be handled by clients directly subscribing to the desired PubSub nodes.</p>
<p>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.</p>
<example caption="User Joins a Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
@ -853,7 +861,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
]]></example>
<p>The user that has been added to the channel is identified by the item id of the item added to the pubsub node, which is the proxy JID of the new channel participant. Note that the &lt;participant&gt; element does not include a nick of the user being added. The nick MAY be set after the join.</p>
<p>
A user may subsequently modify subscription to nodes in a channel by sending a subscription modification request, as shown in the following example.
A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request, as shown in the following example.
</p>
<example caption="User Modifies Subscription Request"><![CDATA[
<iq type='set'
@ -880,7 +888,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
After the user has jointed the channel, 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.
</p>
<p>
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.
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.
</p>
<p>
A channel MAY publish an Avatar following &xep0084;. A client MAY make use of this information to associate an Avatar with the roster entry for a channel.
@ -899,13 +907,13 @@ the participant is not be subscribed to all nodes associated with the channel (i
<li>'Prefer Not'. If this is set, JID will only be shared if mode is JID-visible-mandatory.</li>
</ol>
<p>
The user may specify that no Private Messages are to be sent from the channel, and allow vCard retrieval.
The user MAY specify that no Private Messages are to be sent from the channel, and allow vCard retrieval.
</p>
<p>
The user may specify that presence is not to be shared, which will prevent the MIX Channel from sending a presence probe for the user on channel start-up. The user will also choose to not include the MIX channel in the user's roster, so that presence will not be updated. Where the channel configuration sets 'Participants Must Provide Presence', this variable MUST be set to 'Share'.
The user MAY specify that presence is not to be shared, which will prevent the MIX Channel from sending a presence probe for the user on channel start-up. The user will also choose to not include the MIX channel in the user's roster, so that presence will not be updated. Where the channel configuration sets 'Participants Must Provide Presence', this variable MUST be set to 'Share'.
</p>
<p>
The following table sets out the standardized user preference values. A MIX implementation may use other values.
The following table sets out the standardized user preference values. A MIX implementation MAY use other values.
</p>
<table caption="Standard User Preference Options">
<tr><th>Option</th> <th>Values</th><th>Default</th></tr>
@ -914,7 +922,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<tr><td>'vCard'</td><td>'Allow', 'Block'</td> <td>'Block'</td></tr>
<tr><td>'Presence'</td><td>'Share', 'Not Share'</td><td>'Share'</td></tr>
</table>
<p>When joining a channel, the client may specify one or more preference options as a &xep0004; form. In the response, the server MUST specify all of the user preferences supported by the server, with default values if the user has not requested a different value. The following example shows joining a channel and setting a preference.</p>
<p>When joining a channel, the client MAY specify one or more preference options as a &xep0004; form. In the response, the server MUST specify all of the user preferences supported by the server, with default values if the user has not requested a different value. The following example shows joining a channel and setting a preference.</p>
<example caption="User Joins a Channel and Specifies a preference"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
@ -960,7 +968,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
</join>
</iq>
]]></example>
<p>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.</p>
<p>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.</p>
<example caption="User Requests and Recieves Preferences Template Form"><![CDATA[
<iq type='get'
from='hag66@shakespeare.example'
@ -992,7 +1000,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
</iq>
]]></example>
<p>
A user may modify preferences using the corresponding set operation. The set may specify values for some or all attributes. All attributes are returned in the result.
A user MAY modify preferences using the corresponding set operation. The set MAY specify values for some or all attributes. All attributes are returned in the result.
</p>
<example caption="User Updates Preferences"><![CDATA[
<iq type='set'
@ -1078,16 +1086,16 @@ the participant is not be subscribed to all nodes associated with the channel (i
<section3 topic="Setting a Nick" anchor="usecase-setting-nick">
<p>
Each participant of a channel may have a nick, which is how other users in the channel will see the user. In some cases a nick is not needed, for example where a user reads messages in a channel but does not send messages or share presence information. A nick MUST be present for a user to send a message to a channel or for a user's presence to be shared on a channel. There are four ways that a user's nick can be obtained. The choice of mechanism or mechanisms is dependent on channel policy:
Each participant of a channel MAY have a nick, which is how other users in the channel will see the user. In some cases a nick is not needed, for example where a user reads messages in a channel but does not send messages or share presence information. A nick MUST be present for a user to send a message to a channel or for a user's presence to be shared on a channel. There are four ways that a user's nick can be obtained. The choice of mechanism or mechanisms is dependent on channel policy:
</p>
<ol>
<li>The nick is registered with the user account in some way, for example as part of user provisioning with nick configured as an attribute in a directory service. This may be chosen by corporate services that wish to ensure consistent nick values for a set of users and channels.</li>
<li>The nick is registered with the user account in some way, for example as part of user provisioning with nick configured as an attribute in a directory service. For example, this could be chosen by corporate services that wish to ensure consistent nick values for a set of users and channels.</li>
<li>The nick is registered with the MIX service, as described in <link url='#usecase-user-register'> Registering a Nick </link>.</li>
<li>The user explicitly sets the nick, as described in this section.</li>
<li>The MIX service generates the nick. In this case it is recommended that the assigned nick is a UUID following &rfc4122;.</li>
<li>The MIX service generates the nick. In this case it is RECOMMENDED that the assigned nick is a UUID following &rfc4122;.</li>
</ol>
<p>
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. 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.
</p>
<example caption="User sets Nick on Channel"><![CDATA[
<iq type='set'
@ -1101,7 +1109,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
]]></example>
<p>
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 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;.
</p>
<example caption="Channel informs user of Nick"><![CDATA[
@ -1116,11 +1124,11 @@ the participant is not be subscribed to all nodes associated with the channel (i
]]></example>
</section3>
<section3 topic='Registering a Nick' anchor='usecase-user-register'>
<p>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.
<p>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.
</p>
<p>
In order to determine if a Nick may be registered, the user may use disco to determine capabilities of the MIX service.
In order to determine if a Nick is allowed to be registered, the user MAY use disco to determine capabilities of the MIX service.
</p>
<example caption="User Determines features of the MIX service"><![CDATA[
<iq type='get'
@ -1177,7 +1185,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
</error>
</iq>
]]></example>
<p>If the register request does not contain a &lt;nick/&gt; element, then the MIX service assigns one. It is recommended that the assigned nick is a UUID following &rfc4122;.
<p>If the register request does not contain a &lt;nick/&gt; element, then the MIX service assigns one. It is RECOMMENDED that the assigned nick is a UUID following &rfc4122;.
</p>
@ -1190,10 +1198,10 @@ the participant is not be subscribed to all nodes associated with the channel (i
</p>
<p>
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 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.
</p>
<p>
A channel may require that all channel participants share presence information with the channel, which is represented in the "urn:xmpp:mix:nodes:presence" node. If sharing presences is required by the channel, an XMPP client conforming to this specification SHALL share presence with the channel by including the channel in the user's roster. Note that the MIX 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 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.
</p>
<p>
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.
@ -1216,7 +1224,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<status>Making a Brew</status>
</presence>]]></example>
<p>
The presence is distributed to those subscribing to the MIX channel presence node using a standard XMPP presence stanza. The presence change is recorded on the "urn:xmpp:mix:nodes:presence" node in the item for the full JID of the client to which the presence relates. The history of this node will be held as PubSub format in the MAM archive, so that presence history may be viewed.
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.
</p>
</section3>
@ -1244,7 +1252,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
</section3>
<section3 topic="Determining Real JIDs" anchor="usecase-real-jids">
<p>
Presence information will provide a MIX client with the nicks and anonymized proxy JIDs for participants. For JID visible rooms, the user may look up the real JID using the "urn:xmpp:mix:nodes:jidmap" node. The items in this node are identified by proxy JID, and so the real JID can be retrieved using a straightforward PubSub query. While a user may subscribe to the jidmap node, it is more likely to be used to directly look up JIDs as and when needed.
Presence information will provide a MIX client with the nicks and anonymized proxy JIDs for participants. For JID visible rooms, the user MAY look up the real JID using the "urn:xmpp:mix:nodes:jidmap" node. The items in this node are identified by proxy JID, and so the real JID can be retrieved using a straightforward PubSub query. While a user MAY subscribe to the jidmap node, it is more likely to be used to directly look up JIDs as and when needed.
</p>
</section3>
@ -1254,9 +1262,9 @@ the participant is not be subscribed to all nodes associated with the channel (i
A MIX client will typically display message history of the channel to the user. When a client comes online it will need to obtain this message history from the MAM archive associated with the channel. There are three basic approaches a client will take:
</p>
<ol>
<li>If the client has previously displayed message history and has been offline for a reasonably small time, the client will wish to retrieve all messages since the last one displayed to the user.</li>
<li>The client may wish to display a fixed number of messages, perhaps finding more messages if the client subsequently requests.</li>
<li>The client may wish to display messages from a recent time period, perhaps finding more messages if the client subsequently requests.</li>
<li>If the client has previously displayed message history and has been offline for a reasonably small time, the client MAY wish to retrieve all messages since the last one displayed to the user.</li>
<li>The client MAY wish to display a fixed number of messages, perhaps finding more messages if the client subsequently requests.</li>
<li>The client MAY wish to display messages from a recent time period, perhaps finding more messages if the client subsequently requests.</li>
</ol>
<p>To achieve this, the client will query the user's own MAM archive using &xep0313;, with the query filtered by the channel JID. This gives the client flexibility to retrieve and display message history in a manner appropriate to the client implementation.</p>
</section3>
@ -1277,10 +1285,10 @@ the participant is not be subscribed to all nodes associated with the channel (i
type='unavailable'/>]]></example>
<p>
There is the possibility that the message associated with the user going offline will be lost. If this happens, "ghost" entries will appear in the presence node. A MIX service may take steps to address this, for example by probing client with a disco for presence items that remain unchanged for a long period.
There is the possibility that the message associated with the user going offline will be lost. If this happens, "ghost" entries will appear in the presence node. A MIX service MAY take steps to address this, for example by probing client with a disco for presence items that remain unchanged for a long period.
</p>
<p>
It is desirable to prevent clients from going offline briefly and then coming back online again, as this will lead to "flapping presence". The recommended approach to achieve this is use of &xep0198; to maintain an XMPP client connection in the event of short term TCP failure.
It is desirable to prevent clients from going offline briefly and then coming back online again, as this will lead to "flapping presence". The RECOMMENDED approach to achieve this is use of &xep0198; to maintain an XMPP client connection in the event of short term TCP failure.
</p>
</section3>
@ -1343,7 +1351,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
If the retraction message is accepted, it will be distributed to channel participants. This will allow retraction to happen in the MAM archive of each channel participant and to reflect the retraction in client GUI. A client receiving a retraction message SHOULD ensure that the retracted message is no longer displayed to the end user.
</p>
<p>
Two approaches to message retraction may be used. In the first approach, the retracted message is simply removed. This is appropriate where retraction is provided as a user service and the user has rights to remove messages sent from the record.
Two approaches to message retraction can be used. In the first approach, the retracted message is simply removed. This is appropriate where retraction is provided as a user service and the user has rights to remove messages sent from the record.
</p>
<p>
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.
@ -1393,11 +1401,11 @@ the participant is not be subscribed to all nodes associated with the channel (i
</section3>
<section3 topic='Telling another User about a Channel' anchor='usecase-user-tell'>
<p>
A convenient way to reference another channel is to use &xep0372; which enables the JID of a channel to be shared. This might be used simply to inform the message recipient about the channel or as mechanism to invite the user to join the channel. This is useful as an invitation mechanism to a channel that any user can join or where the invitee knows that the user may join (e.g., because the channel is for all users in an organization).
A convenient way to reference another channel is to use &xep0372; which enables the JID of a channel to be shared. This might be used simply to inform the message recipient about the channel or as mechanism to invite the user to join the channel. This is useful as an invitation mechanism to a channel that any user can join or where the invitee knows that the user is allowed to join (e.g., because the channel is for all users in an organization).
</p>
</section3>
<section3 topic='Inviting another User to join a Channel that the user does not have Permission to Join' anchor='usecase-user-invite'>
<p> Invitation by reference, as described in the previous section, is a convenient approach to invite a user to join a channel that the user has permission to join. This section describes the approach used when the inviter has permission to grant rights for the invitee to become a channel participant. This might be because the inviter is an administrator of the channel or the channel may have a special mode where channel participants may grant rights for other users to join a channel ('Participation Addition by Invitation from Participant' enabled). This approach is used to avoid cluttering the allowed node with JIDs of users who are invited to join, but do not accept the invitation.
<p> 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.
When a channel participant(the inviter) invites another user (the invitee) to join a channel, the following sequence of steps is followed:
</p>
@ -1467,7 +1475,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
</join>
</iq>
]]></example>
<p>The invitee may send an acknowledgement back to the inviter, noting the status of the invitation. Values are:</p>
<p>The invitee MAY send an acknowledgement back to the inviter, noting the status of the invitation. Values are:</p>
<ul>
<li>'Joined': The invitee has joined the channel.</li>
<li>'Declined': The invitee is not taking up the invitation.</li>
@ -1513,7 +1521,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<section3 topic="Requesting vCard" anchor="usecase-vcard">
<p>A user may request the vCard of a channel participant by sending a request through the channel. The request MAY be sent directly by the client or MAY be sent by the user's server on behalf of the user. The MIX channel MAY pass this request on or may block it. vCard requests MAY use &xep0054; (vcard-temp) or &xep0292; (vCard4 over XMPP). Where a MIX service supports one or both of these protocols, the protocol MUST be advertized as a feature of the MIX service. In the following example, using vcard-temp, the requesting client sends a message to the anonymized bare JID of the channel participant for which the vCard is desired.</p>
<p>A user MAY request the vCard of a channel participant by sending a request through the channel. The request MAY be sent directly by the client or MAY be sent by the user's server on behalf of the user. The MIX channel MAY pass this request on or MAY block it. vCard requests MAY use &xep0054; (vcard-temp) or &xep0292; (vCard4 over XMPP). Where a MIX service supports one or both of these protocols, the protocol MUST be advertized as a feature of the MIX service. In the following example, using vcard-temp, the requesting client sends a message to the anonymized bare JID of the channel participant for which the vCard is desired.</p>
<example caption="Client directly requests vCard through channel" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
id='lx09df27'
@ -1522,7 +1530,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<vCard xmlns='vcard-temp'/>
</iq>
]]></example>
<p>The MIX channel MAY pass on the vCard request or may reject with an error, dependent on channel policy. The MIX service will then address the vCard request to the user's server (using bare JID) using an anonymous full proxy JID to hide the requester. </p>
<p>The MIX channel MAY pass on the vCard request or MAY reject with an error, dependent on channel policy. The MIX service will then address the vCard request to the user's server (using bare JID) using an anonymous full proxy JID to hide the requester. </p>
<example caption="Channel passes on vCard request to the User&apos;s Server" ><![CDATA[
<iq from='coven+123456@mix.shakespeare.example/6789'
id='lx09df27'
@ -1585,7 +1593,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
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.
</p>
<p>
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.
</p>
<example caption="Channel Sends Marker Message" ><![CDATA[
<iq from='coven@mix.shakespeare.example'
@ -1619,12 +1627,12 @@ the participant is not be subscribed to all nodes associated with the channel (i
Clients will retrieve MIX messages using standard MAM protocol from the user's archive. The MAM query will filter based on the channel JID to enable access to messages from a given channel. This gives the user a simple mechanism to access all messages sent to the channel. MAM can be used to retrieve older messages that have not been cached by the client.
</p>
<p>
Messages may also be retrieved from the channel by addressing MAM queries to the channel JID. This will behave like a standard MAM archive. This can be useful for administrators to access archived messages. It can also be useful for new channel participants to access the historical archives.
Messages can also be retrieved from the channel by addressing MAM queries to the channel JID. This will behave like a standard MAM archive. This can be useful for administrators to access archived messages. It can also be useful for new channel participants to access the historical archives.
</p>
</section3>
<section3 topic="MAM Use with other Channel Nodes" anchor="use-mam-other-nodes">
<p>
A MIX Channel MAY use MAM to archive nodes other than message nodes. Clients with rights to access these archives may use MAM to do this, specifying the PubSub node in the MAM query addressed to the channel.
A MIX Channel MAY use MAM to archive nodes other than message nodes. Clients with rights to access these archives MAY use MAM to do this, specifying the PubSub node in the MAM query addressed to the channel.
</p>
</section3>
@ -1634,7 +1642,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<section2 topic='Administrative Use Cases' anchor='usecases-admin'>
<section3 topic='Checking For Permission To Create a Channel' anchor='usecase-admin-check-create'>
<p>
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 '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 'create-channel' feature is returned, the user is able to create a channel.
</p>
<example caption="Client determines Capability to Create a Channel" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
@ -1661,7 +1669,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
</section3>
<section3 topic='Creating a Channel' anchor='usecase-admin-create'>
<p>
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).
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).
</p>
<example caption="Creating a Channel with Default Parameters" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
@ -1679,7 +1687,7 @@ A client creates a channel by sending a simple request to the MIX service. A c
</iq>
]]></example>
<p>
The client may also include parameters in &xep0004; format as part of channel creation. If the client wishes to inspect configuration, channel administration procedures should be used.
The client MAY also include parameters in &xep0004; format as part of channel creation. If the client wishes to inspect configuration, channel administration procedures SHOULD be used.
</p>
<example caption="Creating a Channel with Client Specified Parameters" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
@ -1723,7 +1731,7 @@ A client creates a channel by sending a simple request to the MIX service. A c
<section3 topic='Creating a Channel for Ad Hoc Use' anchor='usecase-admin-create-adhoc'>
<p>
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.
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.
</p>
<example caption="Creating a Channel for Ad Hoc Use" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
@ -1746,8 +1754,8 @@ A client creates a channel by sending a simple request to the MIX service. A c
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.
</p>
<p>
It may 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//
This will generally be done by the user creating the channel before the other user is invited, but may be sent by either the user creating the channel or the 1:1 chat partner at any time subsequently.
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.
This will generally be done by the user creating the channel before the other user is invited, but MAY be sent by either the user creating the channel or the 1:1 chat partner at any time subsequently.
</p>
<example caption="Forwarding a message to create History" ><![CDATA[
<message from='hag66@shakespeare.example/pda'
@ -1770,7 +1778,7 @@ A client creates a channel by sending a simple request to the MIX service. A c
<section3 topic='Destroying a Channel' anchor='usecase-admin-destroy'>
<p>
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.
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.
</p>
<p>
A client destroys a channel using a simple set operation, as shown in the following example.
@ -1793,11 +1801,11 @@ A client creates a channel by sending a simple request to the MIX service. A c
<section3 topic='Server Destroying a Channel' anchor='usecase-server-destroy'>
<p>
A server MUST destroy a channel that has exceeded its specified explicit lifetime.
Servers may destroy channels which have no participants and/or presence according to local policy. There will often be good reasons to not destroy rooms in these scenarios, in particular to facilitate channel re-use and history access.
Servers MAY destroy channels which have no participants and/or presence according to local policy. There will often be good reasons to not destroy rooms in these scenarios, in particular to facilitate channel re-use and history access.
</p>
</section3>
<section3 topic='Modifying Channel Information' anchor='usecase-admin-information'>
<p>Authorized users, typically owners and sometimes administrators, may modify the channel information. The client MAY issue a pubsub get command to obtain a form that will facilitate update of the information node. The values in the form show current values, which be defaults or may have been explicitly set. In the following example, the channel name was previously set, but other values were not. </p>
<p>Authorized users, typically owners and sometimes administrators, MAY modify the channel information. The client MAY issue a pubsub get command to obtain a form that will facilitate update of the information node. The values in the form show current values, which be defaults or MAY have been explicitly set. In the following example, the channel name was previously set, but other values were not. </p>
<example caption="Getting Information Form" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
id='lx09df27'
@ -1874,7 +1882,7 @@ A client creates a channel by sending a simple request to the MIX service. A c
]]></example>
</section3>
<section3 topic='Modifying Channel Configuration' anchor='usecase-admin-information'>
<p>Channel owners may modify the channel configuration. The client MAY issue a pubsub get command to obtain a form that will facilitate update of the configuration node. Other clients MAY be authorized to use this command to see the channel configuration, but only owners may update the configuration. The values in the form show current values, which be defaults or may have been explicitly set. The following example shows a short form returned to illustrate the syntax. A typical configuration form will be much larger with many fields. </p>
<p>Channel owners are allowed to modify the channel configuration. The client MAY issue a pubsub get command to obtain a form that will facilitate update of the configuration node. Other clients MAY be authorized to use this command to see the channel configuration, but only owners MAY update the configuration. The values in the form show current values, which MAY be defaults or MAY have been explicitly set. The following example shows a short form returned to illustrate the syntax. A typical configuration form will be much larger with many fields. </p>
<example caption="Getting Configuration Form" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
id='lx09df27'
@ -1950,8 +1958,8 @@ A client creates a channel by sending a simple request to the MIX service. A c
</section3>
<section3 topic='Controlling Channel Partipcipants' anchor='usecase-admin-participants'>
<p>
Owners and Administrators may control which users can participate in a channel by use of Allowed and Banned lists using PubSub. These operations follow &xep0060; which sets out detailed protocol use and error handling.
Allowed and Banned lists may be read by PubSub get of the Banned and Allowed Nodes. This operation may be used by users as controlled by 'Allowed Node Subscription' and 'Banned Node Subscription' configuration node options (default Administrators).
Owners and Administrators are allowed to control which users can participate in a channel by use of Allowed and Banned lists using PubSub. These operations follow &xep0060; which sets out detailed protocol use and error handling.
Allowed and Banned lists MAY be read by PubSub get of the Banned and Allowed Nodes. This operation MAY be used by users as controlled by 'Allowed Node Subscription' and 'Banned Node Subscription' configuration node options (default Administrators).
</p>
<example caption="Client Reads Allowed Node" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
@ -2031,13 +2039,13 @@ A client creates a channel by sending a simple request to the MIX service. A c
<section1 topic="MIX Requirements on Participant's Server" anchor="mix-requirements-participant-server">
<p>
This section defines behaviour required by MIX for servers supporting MIX participants. This provides the full MIX specification for clients and servers is set out in a single document. This functionality MUST be provided by servers used by clients that participate in MIX channels. In future, the specifications in this section may be moved to a separate XEP or it may be incorporated into
This section defines behaviour REQUIRED by MIX for servers supporting MIX participants. This provides the full MIX specification for clients and servers is set out in a single document. This functionality MUST be provided by servers used by clients that participate in MIX channels. In future, the specifications in this section MAY be moved to a separate XEP or it MAY be incorporated into
&xep0376; (PAM) which follows a similar model.
</p>
<section2 topic="MIX Client Activation" anchor="proxy-activation">
<p>
All messages from MIX channels to participants are sent to the participant's XMPP server. The participant's server will send on these messages to each of the user's clients that has activated the MIX service. MIX provides capabilities for an online client to activate and de-activate MIX for that client. A client may activate MIX for all the user's channels or for a selected list. This will enable a mobile client to choose to receive only messages from selected MIX channels. Activation uses an IQ set with an &lt;activate&gt; element to instruct the local server to activate the client. The server responds with a result to confirm activation. The client may include one or more &lt;channel&gt; elements, to identify an explicit list of channels that are activated for the client. If mo channels are specified, activation is for all channels where the user is a participant. A client supporting MIX will typically activate MIX as soon as it comes online, but a client may also choose to only activate MIX for specific periods.
All messages from MIX channels to participants are sent to the participant's XMPP server. The participant's server will send on these messages to each of the user's clients that has activated the MIX service. MIX provides capabilities for an online client to activate and de-activate MIX for that client. A client MAY activate MIX for all the user's channels or for a selected list. This will enable a mobile client to choose to receive only messages from selected MIX channels. Activation uses an IQ set with an &lt;activate&gt; element to instruct the local server to activate the client. The server responds with a result to confirm activation. The client MAY include one or more &lt;channel&gt; elements, to identify an explicit list of channels that are activated for the client. If mo channels are specified, activation is for all channels where the user is a participant. A client supporting MIX will typically activate MIX as soon as it comes online, but a client MAY also choose to only activate MIX for specific periods.
</p>
<example caption="Client Activates use of MIX" ><![CDATA[
@ -2063,7 +2071,7 @@ A client creates a channel by sending a simple request to the MIX service. A c
Following MIX activation, the participant's server will send presence status for all activated channels to the client using standard presence protocol. This will give the client current presence status for the channel.
</p>
<p>
A client will deactivate MIX using a corresponding deactivate command. This will deactivate all MIX channels. This will often be done when the client closes down, but may also be done at other times the client chooses. Deactivation uses an IQ set with an &lt;deactivate&gt; element to instruct the local server to deactivate the client.
A client will deactivate MIX using a corresponding deactivate command. This will deactivate all MIX channels. This will often be done when the client closes down, but MAY also be done at other times the client chooses. Deactivation uses an IQ set with an &lt;deactivate&gt; element to instruct the local server to deactivate the client.
</p>
<example caption="Client Deactivates use of MIX" ><![CDATA[
@ -2141,7 +2149,7 @@ A client creates a channel by sending a simple request to the MIX service. A c
<p>
The MIX specification requires that some IQ messages MUST or MAY come from the participant's server, and not directly from the client.
This indirect operation enables the participant's server to use information from the client to improve the service provided to the client.
The following table shows which IQs are direct from client, indirect through the local server or may be either.
The following table shows which IQs are direct from client, indirect through the local server or MAY be either.
</p>
<table caption="IQ Direct vs Indirect">
@ -2223,7 +2231,7 @@ A client creates a channel by sending a simple request to the MIX service. A c
<section1 topic="Supporting MIX and MUC together" anchor="mix-and-muc-together">
<p>
MIX is specified as a service that can be used independent of MUC and a MIX service may be implemented without MUC. If both MIX and MUC are implemented, three approaches are noted.
MIX is specified as a service that can be used independent of MUC and a MIX service MAY be implemented without MUC. If both MIX and MUC are implemented, three approaches are noted.
</p>
<ol>
<li>Entirely separate MIX and MUC implementation, with MIX and MUC using separate domains and MIX channels being completely separate from MUC rooms.</li>
@ -2330,20 +2338,20 @@ A client creates a channel by sending a simple request to the MIX service. A c
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>MIX allows specification of a number of human readable strings associated with a MIX channel, in particular the subject of a MIX channel and name and description information. These strings may have language set using an xml:lang attribute, and multiple values may be set provided that each one is distinguished using xml:lang.
<p>MIX allows specification of a number of human readable strings associated with a MIX channel, in particular the subject of a MIX channel and name and description information. These strings MAY have language set using an xml:lang attribute, and multiple values MAY be set provided that each one is distinguished using xml:lang.
</p>
<p>Nicknames SHOULD be normalized using the "nickname" profile of the PRECIS OpaqueString class, as defined in &rfc7700;. </p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>MIX is built over MAM and PubSub and the security considerations of &xep0313; and &xep0060; should be considered. These services protect MIX channel information, which may be sensitive and needs appropriate protection.</p>
<p>MIX channels may be JID Hidden, in order to hide the JIDs of channel participants from those accessing the channel. Care must be taken to ensure that JIDs are fully hidden. In particular when proxy JIDs are prepared, this MUST be done in a manner which ensure that the real JIDs cannot be determined. Where nicks are assigned by a channel, this MUST be done in a way that does not expose the JID.</p>
<p>MIX is built over MAM and PubSub and the security considerations of &xep0313; and &xep0060; MUST be considered. These services protect MIX channel information, which can be sensitive and needs appropriate protection.</p>
<p>MIX channels MAY be JID Hidden, in order to hide the JIDs of channel participants from those accessing the channel. Care MUST be taken to ensure that JIDs are fully hidden. In particular when proxy JIDs are prepared, this MUST be done in a manner which ensure that the real JIDs cannot be determined. Where nicks are assigned by a channel, this MUST be done in a way that does not expose the JID.</p>
<p>
There is no MIX equivalent to &xep0045; password controlled rooms, which avoids a number of security issues.
</p>
<p>
MIX provides flexible access control options, which should be used in a manner appropriate to the security requirements of MIX users and services.
MIX provides flexible access control options, which MUST be used in a manner appropriate to the security requirements of MIX users and services.
</p>
</section1>
@ -2353,7 +2361,7 @@ A client creates a channel by sending a simple request to the MIX service. A c
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The urn:xmpp:mix namespace must be registered.</p>
<p>The urn:xmpp:mix namespace needs to be registered.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>