moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

XEP-0369: Update MIX to 0.6

This commit is contained in:
Sam Whited 2016-12-02 09:15:30 -06:00
parent 441baf49eb f105ee040b
commit 9a9e7e54e5
2 changed files with 222 additions and 99 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

313
xep-0369.xml
View File

@ -28,30 +28,37 @@
<supersededby/>
<shortname>MIX</shortname>
&ksmithisode;
<!-- AUTHOR NOTE: replace withe xep.ent? -->
<author>
<firstname>Steve</firstname>
<surname>Kille</surname>
<email>Steve.Kille@isode.com</email>
<jid>Steve.Kille@isode.com</jid>
</author>
&skille;
&stpeter;
<revision>
<version>0.6</version>
<date>2016-12-02</date>
<initials>sek (XEP Editor: ssw)</initials>
<remark><p>
Added Internationalization Consideration section, and various I18n edits;
Added Security Considerations section;
Tombstoning of Redaction changes made optional;
Added a section specifying MIX Proxy;
Change configuration and information node management to directly use PubSub;
Provide for XEP-0202 (vCard4 over XMPP) in addition to vcard-temp support.
</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2016-11-04</date>
<initials>sek (XEP Editor: ssw)</initials>
<remark><p>
Complete and restructure Administration Section: Creating Channels and modifying configuration
Add avatar nodes
Add section on roster handling
Discovering MIX Services
Resolve questions on future capabilities
Administration of Allowed/Banned; clarify Kick functionality is replaced
User Presence Probes on Channel Start-up
Add user Presence preference
Clarify and Expand MAM Archiving
Sort Retraction
Add Marker IQ
Complete and restructure Administration Section: Creating Channels and modifying configuration;
Add avatar nodes;
Add section on roster handling;
Discovering MIX Services;
Resolve questions on future capabilities;
Administration of Allowed/Banned; clarify Kick functionality is replaced;
User Presence Probes on Channel Start-up;
Add user Presence preference;
Clarify and Expand MAM Archiving;
Sort Retraction;
Add Marker IQ;
Conversion 1:1
</p></remark>
</revision>
@ -195,7 +202,7 @@
This means that a MIX client needs to resynchronize with the MIX service when it comes online. This synchronization will happen directly between the MIX client and MIX channel.</li>
<li>The MIX Proxy will know which channels are subscribed to, and so can send this list to a MIX client. Because channel subscriptions are long term, this information will be used instead of the bookmark approach used with MUC.</li>
<li>The MIX Proxy will manage 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). The MIX Proxy MAY handle sending messages only to the clients that wish for them, perhaps using a profile mechanism.</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). The MIX Proxy enables a client to select only a subset of channels.</li>
</ol>
<p>
Messages being sent from MIX channel to MIX Proxy (which will be of type=groupchat) and presence information are sent to the bare JID. This means that the MIX Proxy will use a modification of the standard &rfc6121; rules.
@ -205,13 +212,9 @@
</p>
<p>
The behaviour of a MIX Proxy and the protocol between MIX Proxy and MIX Client is not currently defined in this specification. It will be defined in one of three places.
It may be desirable in some situations to provide different service to different clients. For example, a mobile client may participate in a smaller set of MIX channels than a desktop client. This needs support from the server to which the client connects, so that MIX client and the connected server can negotiate which channels to send. This is not supported by the core MIX specification, but it is anticipated that this will be specified in one of the following ways:
It may be desirable in some situations to provide different service to different clients. For example, a mobile client may participate in a smaller set of MIX channels than a desktop client. This needs support from the server to which the client connects, so that MIX client and the connected server can negotiate which channels to send. MIX Proxy behaviour is specified in this MIX specification.
</p>
<ol>
<li> In an extension to &xep0376; (PAM) which follows a model close to MIX Proxy; or</li>
<li>In a new XEP specifically to defined MIX Proxy behavior; or</li>
<li>As a new section in a future version of the MIX Specification.</li>
</ol>
</section2>
<section2 topic="User Presence in MIX" anchor="concepts-presence">
<p>
@ -373,13 +376,13 @@
<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. 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>
<ul>
<li>'Name'. A short string providing a name for the channel. The name and description values MUST contain a "text" element and MAY contain additional text elements. Where multiple text elements are provided, each MUST posses an xml:lang attribute that describes the natural language of the subject.</li>
<li>'Description'. A longer description of the channel.</li>
<li>'Contact'. The JID of the person or role responsible for the channel. This MAY be the JID of a MIX channel.</li>
</ul>
<p>The format of the Information node follows &xep0004;. This allows configuration to be updated by MIX defined commands and that the results of update commands are the same as the PubSub node.
<table caption="Information Node Attributes">
<tr><th>Name</th><th>Description</th><th>Field Type</th><th>Values</th><th>Default</th></tr>
<tr><td>'Name'</td><td>A short string providing a name for the channel.</td><td>text-single</td><td>-</td><td>-</td></tr>
<tr><td>'Description'</td><td>A longer description of the channel.</td><td>text-single</td><td>-</td><td>-</td></tr>
<tr><td>'Contact'</td><td>The JID or JIDs of the person or role responsible for the channel.</td><td>jid-multi</td><td>-</td><td>-</td></tr>
</table>
<p>The name and description values MUST contain a "text" element and MAY contain additional text elements. Where multiple text elements are provided, each MUST posses an xml:lang attribute that describes the natural language of the subject. The format of the Information node follows &xep0004;. This allows configuration to be updated by MIX defined commands and that the results of update commands are the same as the PubSub node.
The following example shows the format of a item in the information node for the example coven@mix.shakespeare.example channel.
</p>
<example caption="Information Node"><![CDATA[
@ -427,12 +430,12 @@
</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 MAY subscribe to the configuration node to get notification of configuration change. The configuration node is optional for a MIX channel. For example, configuration choices could be fixed and not exposed. A subset of the defined configuration options may be used and additional non-standard configuration options may be added. If configuration options to control functionality of the nature described here are provided, the options defined in this standard MUST be used. The following configuration options are 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 MAY subscribe to the configuration node to get notification of configuration change. The configuration node is optional for a MIX channel. For example, configuration choices could be fixed and not exposed. A subset of the defined configuration options may be used and additional non-standard configuration options may be added. If configuration options to control functionality of the nature described here are provided, the options defined in this standard MUST be used. The following configuration attributes are defined:
</p>
<table caption="Configuration Node Options">
<table caption="Configuration Node Attributes">
<tr><th>Name</th><th>Description</th><th>Field Type</th><th>Values</th><th>Default</th></tr>
<tr><td>'Last Change Made By'</td><td>Bare JID of the user making the last change.</td><td>jid-single</td><td>-</td><td>-</td></tr>
<tr><td>'Owner'</td><td>Dare JIDs with Owner rights as defined in ACL node. When a channel is created, the JID creating the channel is configured as an owner, unless this attribute is explicitly configured to another value.</td><td>jid-multi</td><td>-</td><td>-</td></tr>
<tr><td>'Owner'</td><td>Bare JIDs with Owner rights as defined in ACL node. When a channel is created, the JID creating the channel is configured as an owner, unless this attribute is explicitly configured to another value.</td><td>jid-multi</td><td>-</td><td>-</td></tr>
<tr><td>'Administrator'</td><td>Bare JIDs with Administrator rights.</td><td>jid-multi</td><td>-</td><td>-</td></tr>
<tr><td>'End of Life'</td><td>The date and time at which the channel will be automatically removed by the server. If this is not set, the channel is permanent.</td><td>text-single</td><td>-</td><td>-</td></tr>
<tr><td>'Nodes Present'</td><td>Specifies which nodes are present. Presence of config nodes is implicit. Jidmap node MUST be present if participants node is present. 'avatar' means that both Avatar Data and Avatar Metadata nodes are present.</td><td>list-multi</td><td>'participants'; 'presence'; 'subject'; 'information'; 'allowed'; 'banned'; 'avatar'</td><td>-</td></tr>
@ -497,7 +500,7 @@
<p>
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 servvices" ><![CDATA[
<example caption="Entity queries Server for associated services" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
id='lx09df27'
to='shakespeare.example'
@ -1053,11 +1056,20 @@ the participant is not be subscribed to all nodes associated with the channel (i
</p>
<example caption="User Determines features of the MIX service"><![CDATA[
<iq type='get'
from='hag66@shakespeare.example'
from='hag66@shakespeare.example/pda'
to='mix.shakespeare.example'
id='7nve413p'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
<iq type='result'
to='hag66@shakespeare.example/pda'
from='mix.shakespeare.example'
id='7nve413p'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
<feature xmlns='urn:xmpp:mix:0' var='mix_nick_register'/>
</query>
</iq>
]]></example>
<p>
The response will be a list of features of the MIX channel. If Nick Registration is supported, then the result set will include &lt;feature var="mix_nick_register"/&gt;.
@ -1075,10 +1087,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
</register>
</iq>
]]></example>
<p>On success, the service informs the user of its nick. The nick that is issued might be different from the nick that was requested, for example if the service completes normalization of nicknames for purposes of internationalization.</p>
<p>
MIX services SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, as defined in &rfc7700;.
</p>
<p>On success, the service informs the user of its nick. MIX SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, as defined in &rfc7700; to the requested nick. This means that nick that is issued might be different from the nick that was requested.</p>
<example caption="Service Returns User of Nick"><![CDATA[
<iq type='result'
to='mix.shakespeare.example'
@ -1197,7 +1206,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<section3 topic='Sending a Message' anchor='usecase-user-message'>
<p>A client sends a message directly to a MIX channel as a standard groupchat message, in exactly the same way as for &xep0045;. Messages are sent directly to the channel and do not use the MIX Proxy. </p>
<p>A client sends a message directly to a MIX channel as a standard groupchat message, in exactly the same way as for &xep0045;. Messages are sent directly to the channel and do not use the MIX Proxy. The message id is selected by the client.</p>
<example caption="User Sends Message to Channel"><![CDATA[
<message from='hag66@shakespeare.example/pda'
to='coven@mix.shakespeare.example'
@ -1207,7 +1216,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
</message>
]]></example>
<p>The MIX channel then puts a copy of the message into the MAM archive for the channel and sends a copy of the message to each participant in
standard groupchat format. These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's MIX Proxy. The message from value is the full Proxy JID of the message sender. The id of the message is the ID from the MAM archive.</p>
standard groupchat format. These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's MIX Proxy. The message from value is the full Proxy JID of the message sender. The id of the message is the ID from the MAM archive and NOT the id used by the sender.</p>
<example caption="Channel Reflects Message to Participants"><![CDATA[
<message from='coven+12345@mix.shakespeare.example/678'
@ -1233,7 +1242,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
<section3 topic="Retracting a Message" anchor="usecase-retract">
<p>
A MIX channel MAY support message retraction, where the sender of a messages or an administrator deletes a message. If this is done the original message MUST be replaced by a tombstone. The protocol to request retraction does this by a message with a &lt;retract&gt; element as shown in the following example.
A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. If this is done the original message MAY be replaced by a tombstone. The protocol to request retraction does this by a message with a &lt;retract&gt; element as shown in the following example.
</p>
<example caption="User Retracts a Message"><![CDATA[
<message from='hag66@shakespeare.example/pda'
@ -1243,13 +1252,17 @@ the participant is not be subscribed to all nodes associated with the channel (i
</message>
]]></example>
<p>
The MIX channel will allow a user to retract a message sent by the user if the 'Allow User Message Retraction' option is configured. The MIX channel will allow a user to retract any message if the user is in the group specified by the 'Administrator Message Retraction Rights' option.
The MIX channel will allow a user to retract a message sent by the user if the 'Allow User Message Retraction' option is configured. The MIX channel will allow an administrative user to retract any message if the user is in the group specified by the 'Administrator Message Retraction Rights' option.
</p>
<p>
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>
When a message is retracted the original message &lt;body&gt; MUST be removed and MUST be replaced with a tombstone using the &lt;retracted&gt; element that shows the JID of user performing the retraction and the time of the retraction.
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.
</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.
With this approach, the original message &lt;body&gt; is removed and replaced with a tombstone using the &lt;retracted&gt; element that shows the JID of user performing the retraction and the time of the retraction.
</p>
<example caption="Retracted message tombstone in a MAM result"><![CDATA[
<message id='aeb213' to='juliet@capulet.lit/chamber'>
@ -1423,7 +1436,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 through a MIX Proxy. The MIX channel MAY pass this request on or may block it. In the following example, 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 through a MIX Proxy. 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'
@ -1695,20 +1708,23 @@ A client creates a channel by sending a simple request to the MIX service. A c
</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 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'
to='mix.shakespeare.example'
type='get'>
<info xmlns='urn:xmpp:mix:0'/>
<pubsub xmlns='http://jabber.org/protocol/'>
<items node='urn:xmpp:mix:nodes:info'/>
</pubsub>
</iq>
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/intibo24'
type='result'>
<info xmlns='urn:xmpp:mix:0'/>
<pubsub xmlns='http://jabber.org/protocol/'>
<items node='urn:xmpp:mix:nodes:info'>
<x xmlns='jabber:x:data' type='form'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
@ -1726,16 +1742,18 @@ A client creates a channel by sending a simple request to the MIX service. A c
label='Channel Administrative Contact'
var='Contact'/>
</x>
</info>
</items>
</pubsub>
</iq>
]]></example>
<p> Updating the information node is done using a set command of type info. The MIX channel MUST update the fields with values provided, leaving other fields unchanged. The result returns the id used in the information node item, which is the date/time of the modification. </p>
<p> Updating the information node is done using a pubsub set command. The MIX channel MUST update the fields with values provided, leaving other fields unchanged. The result returns the id used in the information node item, which is the date/time of the modification. </p>
<example caption="Modifying Channel Information" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
<info xmlns='urn:xmpp:mix:0'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:mix:nodes:info'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
@ -1750,32 +1768,40 @@ A client creates a channel by sending a simple request to the MIX service. A c
<value>greymalkin@shakespeare.lit</value>
</field>
</x>
</info>
</publish>
</pubsub>
</iq>
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/intibo24'
type='result'>
<info id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:0'/>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:mix:nodes:info'>
<item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:0'/>
</publish>
</pubsub>
</iq>
]]></example>
</section3>
<section3 topic='Modifying Channel Configuration' anchor='usecase-admin-information'>
<p>Channel owners may modify the channel configuration. The client MAY issue a get command "config" 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 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>
<example caption="Getting Configuration Form" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
id='lx09df27'
to='mix.shakespeare.example'
type='get'>
<config xmlns='urn:xmpp:mix:0'/>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:mix:nodes:config'/>
</pubsub>
</iq>
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/intibo24'
type='result'>
<config xmlns='urn:xmpp:mix:0'/>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items xmlns='urn:xmpp:mix:0' node='urn:xmpp:mix:nodes:config'>
<x xmlns='jabber:x:data' type='form'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
@ -1785,16 +1811,18 @@ A client creates a channel by sending a simple request to the MIX service. A c
label='Channel Administrator'
var='Administrator'/>
</x>
</config>
</items>
</pubsub>
</iq>
]]></example>
<p> Updating the information node is done using a set command of type config. The MIX channel MUST update the fields with values provided, leaving other fields unchanged. The result returns the id used in the configuration node item, which is the date/time of the modification. </p>
<p> Updating the information node is done using a pubsub set command. The MIX channel MUST update the fields with values provided, leaving other fields unchanged. The result returns the id used in the configuration node item, which is the date/time of the modification. </p>
<example caption="Modifying Channel Configuration" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
<config xmlns='urn:xmpp:mix:0'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:mix:nodes:config'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:0</value>
@ -1815,14 +1843,19 @@ A client creates a channel by sending a simple request to the MIX service. A c
<value>true</value>
</field>
</x>
</config>
</publish>
</pubsub>
</iq>
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/intibo24'
type='result'>
<config id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:0'/>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:mix:nodes:config'>
<item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:0'/>
</publish>
</pubsub>
</iq>
]]></example>
</section3>
@ -1907,6 +1940,90 @@ A client creates a channel by sending a simple request to the MIX service. A c
</section1>
<section1 topic="MIX Proxy" anchor="mix-proxy">
<p>
This section defines behaviour of the MIX Proxy Service, so that the full MIX specification for clients and servers is set out in a single document. MIX Proxy support MUST be provided by servers used by clients that participate in MIX channels. In future, MIX Proxy specification may be moved to a separate XEP or it may be incorporated into
&xep0376; (PAM) which follows a model close to MIX Proxy.
</p>
<section2 topic="MIX Client Activation" anchor="proxy-activation">
<p>
All messages from MIX channels to users are sent to the user's MIX Proxy, which resides on the user's XMPP server. The MIX Proxy 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 MIX proxy 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 Proxy" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
id='lx09df27'
type='set'>
<activate xmlns='urn:xmpp:mix:0'>
<channel>coven@mix.shakespeare.lit</channel>
<channel>spells@mix.shakespeare.lit</channel>
</activate>
</iq>
<iq from='shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/intibo24'
type='result'>
<activate xmlns='urn:xmpp:mix:0'/>
</iq>
]]></example>
<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 MIX proxy to activate the client.
</p>
<example caption="Client Deactivates use of MIX Proxy" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
id='lx09df27'
type='set'>
<deactivate xmlns='urn:xmpp:mix:0'/>
</iq>
<iq from='shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/intibo24'
type='result'>
<deactivate xmlns='urn:xmpp:mix:0'/>
</iq>
]]></example>
<p>
If a client goes offline, the server's MIX Proxy MUST deactivate MIX immediately. This will mean that standard client behaviour will be to activate MIX when they come online.
</p>
</section2>
<section2 topic="Messages From MIX Channels" anchor="proxy-from">
<p>
Messages from a MIX channel will usually go to the MIX proxy. The only exception to this is where the MIX channel is responding directly to messages from the client. Messages and presence distributed but a MIX channel will always be sent to the MIX Proxy. The MIX Proxy will simply send on the messages from the channel to each of the user's clients which have activated the channel with the MIX Proxy. If there are no clients activated, the message is dropped.
</p>
<p>
Messages sent to the MIX Proxy will always be addressed to the user's bare JID. The MIX proxy will modify the recipient to the full JID of each client to which the message is forwarded. The MIX Proxy MUST NOT make any other modifications to each message.
</p>
</section2>
<section2 topic="Messages To MIX Channels" anchor="proxy-to"></section2>
<p>
The MIX specification requires that some messages are sent through the MIX Proxy and allows other messages to be sent through the MIX Proxy. This enables the MIX Proxy to use information from the client to improve the MIX Proxy function. The messages sent by the client to the MIX proxy will come from the client's full JID. The MIX proxy will modify the messages to come from the bare JID. This modification is transparent to the MIX client. The client will always send messages from the full JID and the MIX Proxy will modify the message to ensure MIX compliance.
</p>
<section2 topic="Roster Management" anchor="proxy-roster">
<p>
The MIX Proxy is responsible for ensuring that MIX channels are correctly entered into the user's roster. This is provided as a generic client independent service for the user.
</p>
<p>
The MIX Proxy SHOULD ensure that only presence information from activated MIX clients is sent to the MIX channel. So, if a user has two online clients, but only one is activated for a given MIX channel, then the channel SHOULD only receive presence information relating to the activated client.
</p>
</section2>
<section2 topic="MAM Archive Support" anchor="proxy-mam">
<p>
MAM Archive is not a part of the MIX Proxy. However, it is important to note that archive of channel information is done by the user's server. Where a message is sent to the MIX Proxy and discarded because there are no active clients, it will still be archived. This means that the messages will be available in the local archive and can be picked up by clients when they come online.
</p>
</section2>
</section1>
<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.
@ -1998,57 +2115,55 @@ A client creates a channel by sending a simple request to the MIX service. A c
</section1>
<section1 topic="Capabilities not provided in MIX" anchor="not-included-from45">
<p>This section lists a number of capabilities not specified in this version of MIX which were provided in &xep0045;. </p>
<section2 topic="Password Controlled Channels" anchor="password-control">
<p>
&xep0045; provides a mechanism to control access to MUC rooms using passwords. An equivalent mechanism is not included in MIX, as it has a number of security issues. Control of access to channels is better achieved using an explicit list of participants.
</p>
</section2>
<section2 topic="Voice Control" anchor="voice-control">
<p>
&xep0045; defines a mechanism so that MUC moderators can control who is able to send messages to a MUC room using a "voice" mechanism. The current version of MIX does not include this. This might be added to a future version of this XEP or as a separate XEP if this capability becomes an agreed requirement.
</p>
</section2>
<!--<section1 topic='Implementation Notes' anchor='impl'>
<p>OPTIONAL.</p>
</section1>
<section1 topic='Accessibility Considerations' anchor='access'>
<p>OPTIONAL.</p>
</section1>-->
<section1 topic="Capabilities not provided in MIX" anchor="not-included-from45">
<p>This section lists a number of capabilities not specified in this version of MIX which were provided in &xep0045;. </p>
<section2 topic="Password Controlled Channels" anchor="password-control">
<p>
&xep0045; provides a mechanism to control access to MUC rooms using passwords. An equivalent mechanism is not included in MIX, as it has a number of security issues. Control of access to channels is better achieved using an explicit list of participants.
</p>
</section2>
<section2 topic="Voice Control" anchor="voice-control">
<p>
&xep0045; defines a mechanism so that MUC moderators can control who is able to send messages to a MUC room using a "voice" mechanism. The current version of MIX does not include this. This might be added to a future version of this XEP or as a separate XEP if this capability becomes an agreed requirement.
</p>
</section2>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>TBD.</p>
<p>Discuss normalization of nicknames.</p>
<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>TBD.</p>
<p>Topics to cover:</p>
<ul>
<li>transparent vs. opaque channels</li>
<li>nickname registration and security implications of normalization</li>
</ul>
<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>
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.
</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>None.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>Register a namespace.</p>
<p>The urn:xmpp:mix namespace must be registered.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>TBD.</p>
<p>To be supplied when MIX progresses to proposed standard.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to the following who have made contributions: Dave Cridland, Philipp Hancke, Waqas Hussain, Georg Lukas, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Matthew Wild and one anonymous reviewer.</p>
<p>Thanks to the following who have made contributions: Dave Cridland, Philipp Hancke, Waqas Hussain, Timothée Jaussoin, Georg Lukas, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Matthew Wild and one anonymous reviewer.</p>
</section1>
</xep>
<!--TODO: Query whole service for MAM. Provide data form for filtering by node ID.
TODO: Two config nodes - one public read one private read?
TODO: Open Issue: How many config nodes do you need? Do you do different access to different items within a node for reading? Writing?
TODO: Subscription option to check channel config (e.g., transparency of JIDs) before join.
-->

8
xep.ent
View File

@ -886,6 +886,14 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates</link></span> <note>
<jid>kevin.smith@isode.com</jid>
</author>
" >
<!ENTITY skille "
<author>
<firstname>Steve</firstname>
<surname>Kille</surname>
<email>steve.kille@isode.com</email>
<jid>steve.kille@isode.com</jid>
</author>
" >
<!ENTITY remko "
<author>
<firstname>Remko</firstname>