moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-08-13 16:53:48 -04:00
Code Issues Releases Wiki Activity

Merge commit 'refs/pull/638/head' of https://github.com/xsf/xeps into feature/mixify

Browse Source
This commit is contained in:
Jonas Wielicki 2018-05-22 15:02:43 +02:00
commit b103ad86eb
4 changed files with 1556 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

492
xep-0406.html Normal file
View File

File diff suppressed because one or more lines are too long

472
xep-0406.xml Normal file
View File

@ -0,0 +1,472 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<?xml-stylesheet type="text/css" href="xmpp.css"?>
<xep>
<header>
<title>Mediated Information eXchange (MIX): MIX Administration</title>
<abstract>This document defines an extension to Mediated Information eXchange (MIX) specified in XEP-0369. This specification defines a framework for MIX administration and administration operations. </abstract>
&LEGALNOTICE;
<number>0406</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>XEP-0004</spec>
<spec>XEP-0030</spec>
<spec>XEP-0054</spec>
<spec>XEP-0060</spec>
<spec>XEP-0084</spec>
<spec>XEP-0128</spec>
<spec>XEP-0198</spec>
<spec>XEP-0292</spec>
<spec>XEP-0297</spec>
<spec>XEP-0313</spec>
<spec>XEP-0369</spec>
<spec>XEP-0372</spec>
<spec>XEP-0403</spec>
<spec>XEP-0404</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>MIX-ADMIN</shortname>
&ksmithisode;
&skille;
<revision>
<version>0.1.0</version>
<date>2018-05-21</date>
<initials>sek</initials>
<remark><p>
Split out from MIX 0.10.0;
</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). This document defines a framework for administering a MIX service, including MIX-CORE, MIX-PRESENCE and MIX-ANON. It defines MIX channel configuration in a standardized manner, to enable consistent MIX administration using standard capabilities.
</p>
</section1>
<section1 topic="Admininstrative MIX Nodes" anchor="concepts-nodes">
<p>This specification defines three standard nodes to support configuration. The configuration node is required to support this specification and the other two nodes are optional:</p>
<table caption="Administrative MIX Nodes">
<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>
<tr><td>Banned</td><td>'urn:xmpp:mix:nodes:banned'</td><td>For storing JIDs that are not allowed to be channel participants. </td><td>PubSub</td><td>PubSub</td></tr>
<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>
</p>
<section2 topic="Roles" anchor="roles">
<p>
There are a number of MIX roles for each channel, listed in the following table. Rights will be assigned to the various roles in the channel configuration node.
</p>
<table caption="Channel Roles">
<tr><th>Role</th><th>Membership and Rights</th></tr>
<tr><td>Owners</td><td>These are owners of the channel, 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 they 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 are allowed to become participants. A JID is allowed if it does not match an 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 MUST always be at least one Owner set for a Channel. Administrators are optional and do not need to be set. Administrators and Owners MAY be participants but are not required to be. Owners and Administrators are configured in the information node. Participants and Allowed are specified in separate nodes.
Rights are defined in a strictly hierarchical manner following the order of this table, so that for example Owners will always have rights that Administrators have.
</p>
</section2>
<section2 topic="Allowed" anchor="allowed-node">
<p>
This node represents a list of JIDs that are allowed to become participants. If the Allowed node is not present, all JIDs are allowed. This node is accessed and managed using standard pubsub. The Allowed list is always considered in conjunction with the banned list, stored in the banned node. Only Administrators and Owners have write permission to the Allowed node and are also the only roles that are allowed to subscribe to this node. The Allowed node is a permanent node. Each item contains a real bare JID. The following example shows how the Allowed list can specify single JIDs and domains.
</p>
<example caption="Allowed Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:allowed'>
<item id='shakespeare.example'/>
<item id='alice@wonderland.example'/>
</items>
]]></example>
</section2>
<section2 topic="Banned" anchor="banned-node">
<p>
This node represents a list of JIDs that are explicitly not allowed to become participants. The values in this list take priority over values in the Allowed node. This node is accessed and managed using standard pubsub Only Administrators and Owners have write permission to the Banned node and are also the only roles that are allowed to subscribe to this node. Each item contains a real bare JID. The Banned node can contain bare JIDs and/or domains. The Banned node is a permanent node.
</p>
<example caption="Banned Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:banned'>
<item id='lear@shakespeare.example'/>
<item id='macbeth@shakespeare.example'/>
</items>
]]></example>
</section2>
<section2 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. The Configuration node is a permanent node with a maximum of one item. Previous configuration history MAY be 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>
<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>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'; 'information'; 'allowed'; 'banned'; 'jidmap-visible'; 'avatar'</td><td>'participants'; 'presence'; 'information'; 'allowed'; 'banned'; 'jidmap-visible'; 'avatar'</td></tr>
<tr><td>'Messages Node Subscription'</td><td>Controls who can subscribe to messages node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'</td><td>'participants'</td></tr>
<tr><td>'Presence Node Subscription'</td><td>Controls who can subscribe to presence node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'</td><td>'participants'</td></tr>
<tr><td>'Participants Node Subscription'</td><td>Controls who can subscribe to participants node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'; 'nobody'; 'admins'; 'owners'</td><td>'participants'</td></tr>
<tr><td>'Information Node Subscription'</td><td>Controls who can subscribe to the information node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'</td><td>'participants'</td></tr>
<tr><td>'Allowed Node Subscription'</td><td>Controls who can subscribe to allowed node.</td><td>list-single</td><td>'participants'; 'allowed'; 'nobody'; 'admins'; 'owners' </td><td>'admins'</td></tr>
<tr><td>'Banned Node Subscription'</td><td>Controls who can subscribe to banned node.</td><td>list-single</td><td>'participants'; 'allowed'; 'nobody'; 'admins'; 'owners' </td><td>'admins'</td></tr>
<tr><td>'Configuration Node Access'</td><td>Controls who can subscribe to configuration node and who has read access to it.</td><td>list-single</td><td>'participants'; 'allowed'; 'nobody'; 'admins'; 'owners' </td><td>'owners'</td></tr>
<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>'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>'User Message Retraction'</td><td>If this option is selected users will be able to retract messages that they have 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 any message 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>'Private Messages'</td><td>If this option is selected, private messages MAY be used with the channel.</td><td>boolean</td><td>-</td><td>true</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.
</p>
<example caption="Configuration Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:config'>
<item id='2016-05-30T09:00:00'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:admin:0</value>
</field>
<field var='Owner'>
<value>hecate@shakespeare.example</value>
<value>greymalkin@shakespeare.example</value>
</field>
<field var='Messages Node Subscription'>
<value>allowed</value>
</field>
<field var='No Private Messages'>
<value>true</value>
</field>
</x>
</item>
</items>
]]></example>
</section2>
</section1>
<section1 topic='Administrative Use Cases' anchor='usecases-admin'>
<section2 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>
<example caption="Getting Information Form" ><![CDATA[
<iq from='hag66@shakespeare.example/UUID-a1j/7533'
id='lx09df27'
to='mix.shakespeare.example'
type='get'>
<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/UUID-a1j/7533'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/'>
<items node='urn:xmpp:mix:nodes:info'>
<item>
<x xmlns='jabber:x:data' type='form'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:core:0</value>
</field>
<title>Information Node Modification</title>
<field type='text-multi'
label='Channel Name'
var='Name'>
<value>Witches Coven</value>
</field>
<field type='text-multi'
label='Channel Description'
var='Description'/>
<field type='jid-single'
label='Channel Administrative Contact'
var='Contact'/>
</x>
</item>
</items>
</pubsub>
</iq>
]]></example>
<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/UUID-a1j/7533'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:mix:nodes:info'>
<items>
<item>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:core:0</value>
</field>
<field var='Name'>
<value>Witches Coven</value>
</field>
<field var='Description'>
<value>A location not far from the blasted heath where
the three witches meet</value>
</field>
<field var='Contact'>
<value>greymalkin@shakespeare.example</value>
</field>
</x>
</item>
</items>
</publish>
</pubsub>
</iq>
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/UUID-a1j/7533'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:mix:nodes:info'>
<items>
<item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:core:0'/>
</items>
</publish>
</pubsub>
</iq>
]]></example>
</section2>
<section2 topic='Modifying Channel Configuration' anchor='usecase-admin-information'>
<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. Modifying channel configuration is done directly by a client. Note that an Owner MUST be specified. When the configuration node is modified, the server MUST set the 'Last Change Made By' attribute to the JID of the user making the change.
</p>
<example caption="Getting Configuration Form" ><![CDATA[
<iq from='hag66@shakespeare.example/UUID-a1j/7533'
id='lx09df27'
to='mix.shakespeare.example'
type='get'>
<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/UUID-a1j/7533'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items xmlns='urn:xmpp:mix:admin:0' node='urn:xmpp:mix:nodes:config'>
<item>
<x xmlns='jabber:x:data' type='form'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:admin:0</value>
</field>
<title>Configuration Node Modification</title>
<field type='jid-multi'
label='Channel Administrator'
var='Administrator'/>
</x>
</item>
</items>
</pubsub>
</iq>
]]></example>
<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/UUID-a1j/7533'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:mix:nodes:config'>
<items>
<item>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:admin:0</value>
</field>
<field var='Owner'>
<value>hecate@shakespeare.example</value>
<value>greymalkin@shakespeare.example</value>
</field>
<field var='Messages Node Subscription'>
<value>allowed</value>
</field>
<field var='JID Visibility'>
<value>jid-mandatory-visible</value>
</field>
<field var='No Private Messages'>
<value>true</value>
</field>
</x>
<item/>
<items/>
</publish>
</pubsub>
</iq>
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/UUID-a1j/7533'
type='result'>
<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:admin:0'/>
</publish>
</pubsub>
</iq>
]]></example>
</section2>
<section2 topic='Controlling Channel Participants' anchor='usecase-admin-participants'>
<p>
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/UUID-a1j/7533'
id='lx09df27'
to='mix.shakespeare.example'
type='get'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:mix:nodes:allowed'/>
</pubsub>
</iq>
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/UUID-a1j/7533'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:mix:nodes:allowed'>
<item id='shakespeare.example'/>
<item id='alice@wonderland.example'/>
</items>
</pubsub>
</iq>
]]></example>
<p>
JIDs can be added to the Allowed and Banned nodes by a pubsub set command. This is used to add one item to a node.
</p>
<example caption="Client Adds a JID to the Allowed Node" ><![CDATA[
<iq from='hag66@shakespeare.example/UUID-a1j/7533'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:mix:nodes:allowed'>
<item id='marlow.example'/>
</publish>
</pubsub>
</iq>
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/UUID-a1j/7533'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'/>
</iq>
]]></example>
<p>
JIDs can be removed from the Allowed and Banned nodes by pubsub retract command.
</p>
<example caption="Client Removes a JID from the Banned Node" ><![CDATA[
<iq from='hag66@shakespeare.example/UUID-a1j/7533'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<retract node='urn:xmpp:mix:nodes:banned'>
<item id='lear@shakespeare.example'/>
</retract>
</pubsub>
</iq>
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/UUID-a1j/7533'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'/>
</iq>
]]></example>
<p>
When the MIX channel adds a JID to the banned node, other nodes in the MIX channel will be appropriately updated to reflect this change. In particular, the participants nodes and presence nodes will be updated to remove matching JIDs. This will have the effect of immediately removing the user from the channel. For this reason, there is no requirement to have the "kick" functionality of MUC, as this is achieved by banning the user.
</p>
</section2>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>See considerations in MIX-CORE.
</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>See considerations in MIX-CORE.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>None.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The urn:xmpp:mix namespace needs to be registered.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>To be supplied when MIX progresses to proposed standard.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>See MIX-CORE for a list of contributors to the MIX Family of specifications.</p>
</section1>
</xep>

385
xep-0407.xml Normal file
View File

@ -0,0 +1,385 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<?xml-stylesheet type="text/css" href="xmpp.css"?>
<xep>
<header>
<title>Mediated Information eXchange (MIX): Miscellaneous Capabilities</title>
<abstract>This document defines an extension to Mediated Information eXchange (MIX) specified in XEP-0369. It specifies a number of independent optional capabilities that MAY be used with MIX.</abstract>
&LEGALNOTICE;
<number>0407</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>XEP-0004</spec>
<spec>XEP-0030</spec>
<spec>XEP-0054</spec>
<spec>XEP-0060</spec>
<spec>XEP-0084</spec>
<spec>XEP-0128</spec>
<spec>XEP-0198</spec>
<spec>XEP-0292</spec>
<spec>XEP-0297</spec>
<spec>XEP-0313</spec>
<spec>XEP-0369</spec>
<spec>XEP-0372</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>MIX-MISC</shortname>
&ksmithisode;
&skille;
<revision>
<version>0.1.0</version>
<date>2018-05-14</date>
<initials>sek</initials>
<remark><p>
Split out from MIX 0.10.0;
</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). This specification defines six extensions to this core:
</p>
<ol>
<li>Avatar Publishing.</li>
<li>Nick Registration.</li>
<li>Retracting a Message. </li>
<li>Telling another user about a channel.</li>
<li>Invitation by reference.</li>
<li>Converting 1:1 conversation to a channel.</li>
</ol>
<p>These extensions are independent. An implementation of this specification should identify clearly which extensions are implemented.</p>
</section1>
<section1 topic="Avatar Publishing" anchor="avatar">
<p>
MIX-CORE defines a framework of nodes associated with each channel, where new nodes can be added to provide new services.
Two nodes defined in this specification MAY bey used to support 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>
<tr><td>Avatar Data</td><td>'urn:xmpp:avatar:data'</td><td>For publishing an Avatar</td></tr>
<tr><td>Avatar Metadata</td><td>'urn:xmpp:avatar:metadata'</td><td>For publishing Avatar metadata</td></tr>
</table>
</section1>
<section1 topic='Registering a Nick' anchor='usecase-user-register'>
<p>A nick MAY be associated with a user's bare JID. A user can register a nick with the MIX service. Nick registration can be used ensure that a user is able to use the same nick in all channels in the service and to prevent other users from using a registered nick. This can help achieve a consistent experience across a set of channels and prevent user confusion. Support for nick registration by a MIX service is OPTIONAL. Where nick registration is supported, nick registration MAY be OPTIONAL or MANDATORY.
Where a user has registered a Nick with the MIX service, it MAY be used by each channel according to policy for the channel. A channel MAY enforce use of a registered nick. A channel MUST NOT use a registered nick for any other participant.
</p>
<p>
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'
from='hag66@shakespeare.example/UUID-a1j/7533'
to='mix.shakespeare.example'
id='7nve413p'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
<iq type='result'
to='hag66@shakespeare.example/UUID-a1j/7533'
from='mix.shakespeare.example'
id='7nve413p'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
<feature var='urn:xmpp:mix:misc:0#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="urn:xmpp:mix:misc:0#nick-register"/&gt;.
</p>
<p>
To register a nick with the MIX service the user sends
a register command to the service. This is encoded as a &lt;register/&gt; child element of an &lt;iq/&gt; element. The &lt;register/&gt; element is qualified by the urn:xmpp:mix:misc:0' namespace. The nick is encoded in a &lt;nick/&gt; child element of the &lt;register/&gt; element. </p>
<example caption="User Registers with Service"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/UUID-a1j/7533'
to='mix.shakespeare.example'
id='7nve413p'>
<register xmlns='urn:xmpp:mix:misc:0'>
<nick>thirdwitch</nick>
</register>
</iq>
]]></example>
<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>
<p>
When an Nick is assigned, the MIX server MUST update the Participants Node in the channel to reflect this change. Any users subscribed to this node will be notified of the change of Nick.
</p>
<p>The following example shows an example of reporting successful Nick assignment.</p>
<example caption="Service Returns User of Nick"><![CDATA[
<iq type='result'
to='mix.shakespeare.example'
from='hag66@shakespeare.example/UUID-a1j/7533'
id='7nve413p'>
<register xmlns='urn:xmpp:mix:misc:0'>
<nick>thirdwitch</nick>
</register>
</iq>
]]></example>
<p>If the requested nick is already taken and the MIX service does not assign an alternate nick, the MIX service MUST return a &lt;conflict/&gt; error:</p>
<example caption="Nick is Taken">
<![CDATA[<iq type='error'
to='mix.shakespeare.example'
from='hag66@shakespeare.example/UUID-a1j/7533'
id='7nve413p'>
<error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
<p>If the register request does not contain a &lt;nick/&gt; element, then the MIX service MUST assign one. It is RECOMMENDED that the assigned nick is a UUID following &rfc4122;.
</p>
</section1>
<section1 topic="Retracting a Message" anchor="usecase-retract">
<p>
A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. A MIX channel MAY limit the time frame in which a message is allowed to be retracted, for example to prevent retraction of very old messages. When a messages is retracted the original message MAY be replaced by a tombstone. Message retraction is done by sending a special message that identifies the original message. This mechanism allows the retraction to be distributed on the same path as the original message so that all participating servers and clients MAY honour the retraction. The protocol to request retraction does this by adding to a message a &lt;retract&gt; element qualified by the 'urn:xmpp:mix:misc:0' namespace. A retract messages MUST NOT have a body. The &lt;retract&gt; element MUST include an 'id' attribute that holds the MAM-ID of the original message. The message sender will need to look up the MAM-ID. The MAM-ID is the convenient message identification for message recipients. A message and it's retraction shown in the following example.
</p>
<example caption="User Retracts a Message"><![CDATA[
<message from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'
id='abcde'>
<body> A Message I did not mean to send </body>
</message>
<message from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'
id='92vax143g'>
<retract id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' xmlns='urn:xmpp:mix:misc:0'/>
</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 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 MUST 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 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. It is recommended to use a tombstone, as simply deleting the message may cause confusion with MAM queries. Use of a tombstone 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 qualified by the 'urn:xmpp:mix:misc:0' namespace 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.example/UUID-e3r/9264'>
<result xmlns='urn:xmpp:mam:2' queryid='f27' id='28482-98726-73623'>
<forwarded xmlns='urn:xmpp:forward:0'>
<delay xmlns='urn:xmpp:delay' stamp='2010-07-10T23:08:25Z'/>
<message xmlns='jabber:client' from="hag66@shakespeare.example"
to="macbeth@shakespeare.example">
<retracted xmlns='urn:xmpp:mix:misc:0' by='hag66@shakespeare.example'
time='2010-07-10T23:08:25Z'/>
</message>
</forwarded>
</result>
</message>
]]></example>
</section1>
<section1 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 is allowed to join (e.g., because the channel is for all users in an organization).
</p>
</section1>
<section1 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 or if the inviter is a channel participant and the channel allows invitation by participants (this channel capability is controlled by the channel configuration variable 'Participation Addition by Invitation from Participant'). Invitation by reference 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>
<ol>
<li>The inviter checks using capability discovery that the invitee supports MIX.</li>
<li>The channel inviter sends to the channel requesting an invite for the invitee.</li>
<li>The channel sends an invitation to the inviter.</li>
<li>The inviter sends the invitation to the invitee.</li>
<li>The invitee MAY use the invitation to join the channel.</li>
<li>The invitee MAY send a response to the inviter, indicating if the invitation was accepted or declined.</li>
</ol>
<p>
The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time. The invitation request is encoded as an &lt;invite/&gt; child element of an &lt;iq/&gt; element. The &lt;invite/&gt; element is qualified by the 'urn:xmpp:mix:misc:0' namespace. &lt;invite/&gt; contains an &lt;invitation/&gt; child element, which contain &lt;inviter/&gt;, &lt;invitee/&gt;, &lt;channel/&gt; and &lt;token/&gt; child elements.
</p>
<example caption='Inviter Requests and Receives Invitation'><![CDATA[
<iq from='hag66@shakespeare.example/UUID-h5z/0253'
id='kl2fax27'
to='coven@mix.shakespeare.example'
type='get'>
<invite xmlns='urn:xmpp:mix:misc:0'>
<invitee>cat@shakespeare.example</invitee>
</invite>
</iq>
<iq from='coven@mix.shakespeare.example'
id='kl2fax27'
to='hag66@shakespeare.example/UUID-h5z/0253'
type='result'>
<invite xmlns='urn:xmpp:mix:misc:0'>
<invitation>
<inviter>hag66@shakespeare.example</inviter>
<invitee>cat@shakespeare.example</invitee>
<channel>coven@mix.shakespeare.example</channel>
<token>ABCDEF</token>
</invitation>
<invite/>
</iq>
]]></example>
<p>
The inviter can now send the invitee a message containing the invitation within the &lt;message/&gt; element, as shown in the following example.
</p>
<example caption='Inviter sends Invitation to Invitee'><![CDATA[
<message from='hag66@shakespeare.example/UUID-h5z/0253'
id='f5pp2toz'
to='cat@shakespeare.example'>
<body>Would you like to join the coven?<body>
<invitation xmlns='urn:xmpp:mix:misc:0'>
<inviter>hag66@shakespeare.example</inviter>
<invitee>cat@shakespeare.example</invitee>
<channel>coven@mix.shakespeare.example</channel>
<token>ABCDEF</token>
</invitation>
</iq>
]]></example>
<p>The invitation can now be used by the invitee to join a channel. The &lt;invitation/&gt; child element is simply added to the standard channel &lt;join/&gt; element, so that the channel can validate the invitation using the token. If the allowed node is present and the invitee is not matched against any item, the channel MUST add the invitee to the allowed node as part of the join.</p>
<example caption="User Joins a Channel with an Invitation"><![CDATA[
<iq type='set'
from='cat@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:misc:0'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<invitation>
<inviter>hag66@shakespeare.example</inviter>
<invitee>cat@shakespeare.example</invitee>
<channel>coven@mix.shakespeare.example</channel>
<token>ABCDEF</token>
</invitation>
</join>
</iq>
]]></example>
<p>The invitee MAY send an acknowledgement back to the inviter, noting the status of the invitation.
This is encoded as an &lt;invitation-ack/&gt; child element of &lt;message/&gt; element. The &lt;invitation-ack/&gt; element is qualified by the 'urn:xmpp:mix:misc:0' namespace. The &lt;invitation-ack/&gt; has an &lt;invitation/&gt; child element that encodes the invitation being acknowledged and a &lt;value/&gt; child element to encode the acknowledgement value.
&lt;value/&gt; has the following values:</p>
<ul>
<li>'Joined': The invitee has joined the channel.</li>
<li>'Declined': The invitee is not taking up the invitation.</li>
<li>'Acknowledged': The invitation is acknowledged, without information on action taken or planned.</li>
</ul>
<example caption='Invitee sends Acknowledgement to Inviter'><![CDATA[
<message from='cat@shakespeare.example/UUID-l1w/8813'
id='b6p9llze'
to='hag66@shakespeare.example/UUID-h5z/0253'>
<body>No Thanks - too busy chasing mice....<body>
<invitation-ack xmlns='urn:xmpp:mix:misc:0'>
<value>Declined</value>
<invitation>
<inviter>hag66@shakespeare.example</inviter>
<invitee>cat@shakespeare.example</invitee>
<channel>coven@mix.shakespeare.example</channel>
<token>ABCDEF</token>
</invitation>
</invitation-ack>
</iq>
]]></example>
</section1>
<section1 topic="Converting a 1:1 Conversation to a Channel" anchor="usecase-admin-converting-chat">
<p>
A common use case for an ad hoc channel is where two users are engaged in a 1:1 chat and wish to broaden the discussion. Prior to bringing more users into a channel, using standard invitation process, there is a need to create and populate a channel. The first step is for one of the two users to create an ad hoc channel, as described in the previous section. The other user will then be invited, and can switch to the new channel.
</p>
<p>
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 to the channel using &xep0297;. A body SHOULD NOT be used in the outer message.
Sharing history is optional. If history is shared, it MUST be done by the user creating the channel before the other user is invited. Any other use of forwarded messages MUST be treated as a channel participant forwarding a message to the channel and MUST NOT be treated as history sharing.
</p>
<example caption="Forwarding a message to create History" ><![CDATA[
<message from='hag66@shakespeare.example/UUID-a1j/7533'
to='A1B2C345@mix.shakespeare.example'
id='92vax143g'
type='groupchat'>
<forwarded xmlns='urn:xmpp:forward:0'>
<delay xmlns='urn:xmpp:delay' stamp='2010-07-10T23:08:25Z'/>
<message from='hag67@shakespeare.example/pda'
id='0202197'
to='hag66@shakespeare.example/UUID-a1j/7533'
type='chat'
xmlns='jabber:client'>
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>
</forwarded>
</message>
]]></example>
<p>
There are a number of security considerations with sharing 1:1 history in a channel. There may be sensitive information in the 1:1 history, and the user sharing this history should ensure that none of this is sensitive, prior to sharing in this way. The user creating the channel has potential to inject history messages which were not part of the history. It is recommended that the second user joining the channel to validate that the messages match the history and to take appropriate action if they do not.
</p>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>See considerations in MIX-CORE.
</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>See considerations in MIX-CORE.</p>
<p>
When converting a 1:1 conversation to a channel there is potential to expose sensitive information and to present invalid information.
</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>None.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The urn:xmpp:mix namespace needs to be registered.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>To be supplied when MIX progresses to proposed standard.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>See MIX-CORE for a list of contributors to the MIX Family of specifications.</p>
</section1>
</xep>

207
xep-0408.xml Normal file
View File

@ -0,0 +1,207 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<?xml-stylesheet type="text/css" href="xmpp.css"?>
<xep>
<header>
<title>Mediated Information eXchange (MIX): Co-existence with MUC</title>
<abstract>This document defines an extension to Mediated Information eXchange (MIX) specified in XEP-0369. It specifies how MIX and MUC can be operated together. </abstract>
&LEGALNOTICE;
<number>0408</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>XEP-0004</spec>
<spec>XEP-0030</spec>
<spec>XEP-0054</spec>
<spec>XEP-0060</spec>
<spec>XEP-0084</spec>
<spec>XEP-0128</spec>
<spec>XEP-0198</spec>
<spec>XEP-0292</spec>
<spec>XEP-0297</spec>
<spec>XEP-0313</spec>
<spec>XEP-0372</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>MIX-PRESENCE</shortname>
&ksmithisode;
&skille;
<revision>
<version>0.1.0</version>
<date>2018-05-21</date>
<initials>sek</initials>
<remark><p>
Split out from MIX 0.10.0;
</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE).
MIX can be used independently of &xep0045; (MUC).
</p>
<p>
It may be desirable to operate a service that provides MIX and MUC together. This specification specifies three options for achieving this.
</p>
</section1>
<section1 topic="Supporting MIX and MUC together" anchor="mix-and-muc-together">
<p>
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>
<li>Fully integrated MIX and MUC implementation, with MIX and MUC sharing a single domain and rooms/channels equivalent.</li>
<li>Partially integrated MIX and MUC implementation, with MIX and MUC using separate domains, but all rooms/channel are common. This means that each MIX channel will have MUC room of the same name and same participants. </li>
</ol>
<p>The fully integrated approach would be transparent to clients. The following example shows how a service that supports MIX and MUC in a fully integrated manner would respond following the specification of MIX-CORE:</p>
<example caption="Client uses Disco to show fully integrated MIX and MUC support" ><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='lx09df27'
to='mix.shakespeare.example'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'>
</iq>
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/UUID-c8y/1573'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity
category='conference'
name='Shakespearean Chat Service'
type='text'/>
<feature var='urn:xmpp:mix:core:0'/>
<feature var='http://jabber.org/protocol/muc'/>
<feature var='urn:xmpp:mix:core:0#searchable'>
</query>
</iq>
]]></example>
<p>In the fully integrated service item discovery on the MIX/MUC service determines a list of channels. The protocol used for this is the same in MUC and MIX. Discovery actions on a channel in MIX MUST use 'node=mix' attribute in the discovery which will lead to the return of MIX channel specific information, as mandated for this discovery in MIX-CORE. If is not set, MUC room specific information is returned.
</p>
<p>For the partially integrated service, MIX servers will reference the associated MUC server and MUC servers will reference the associated MIX service. This will allow a client that only support MUC or only supports MIX to find the right server if it is given a reference to the other one. For a client that supports both MUC and MIX, it will enable the client to select its preferred service.
For a MIX client, it will also be useful to know the MUC service, so that this information can be shared with a MUC client invitation.
The following example shows how a MIX server identifies the associated MUC server:
</p>
<example caption="Client uses Disco to find MUC server assocated with MIX server" ><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='lx09df27'
to='mix.shakespeare.example'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'>
</iq>
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/UUID-c8y/1573'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity
category='conference'
name='Shakespearean Chat Service'
type='text'/>
<feature var='urn:xmpp:mix:1'/>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:muc:0#muc-mirror</value>
</field>
<field var='muc-mirror'
type='jid-single'
label='Location of MUC mirror service'>
<value>chat.shakespeare.example</value>
</field>
</x>
</query>
</iq>
]]></example>
<p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:muc:0#muc-mirror'. The field with var='muc-mirror' is the value of which is the mirrored MUC domain's JID. </p>
<p>Similarly, a MUC service can advertise an associated MIX doming. The following example shows discovery of a MUC domain.</p>
<example caption="Client uses Disco to find MIX server assocated with MUC server" ><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='lx09df27'
to='mix.shakespeare.example'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'>
</iq>
<iq from='chat.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/UUID-c8y/1573'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity
category='conference'
name='Shakespearean Chat Service'
type='text'/>
<feature var='http://jabber.org/protocol/muc'/>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:muc:0#mix-mirror</value>
</field>
<field var='mix-mirror'
type='jid-single'
label='Location of MUC mirror service'>
<value>mix.shakespeare.example</value>
</field>
</x>
</query>
</iq>
]]></example>
<p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:muc:0#mux-mirror'. The field with var='mix-mirror' is the value of which is the mirrored MIX domain's JID. </p>
<section2 topic="Choosing Which Invite to Send" anchor="mix-muc-invite-choice">
<p>
Where a client supports MUC and MIX and has determined that for a channel that the server also supports a MUC room, the client has a choice as to which type of invite to send. This SHOULD be done by determining if the client support MIX using the mechanism specified in
MIX-CORE. If the client supports MIX a MIX invite SHOULD be sent.
</p>
</section2>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>See considerations in MIX-CORE.
</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>See considerations in MIX-CORE.</p>
<p>
When converting a 1:1 conversation to a channel there is potential to expose sensitive information and to present invalid information.
</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>None.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The urn:xmpp:mix namespace needs to be registered.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>To be supplied when MIX progresses to proposed standard.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>See MIX-CORE for a list of contributors to the MIX Family of specifications.</p>
</section1>
</xep>