moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 18:22:24 -05:00
Code Issues Releases Wiki Activity

Edits

Browse Source
This commit is contained in:
Steve Kille 2018-05-21 13:53:59 +01:00
parent 20f836899f
commit e54557ea17
1 changed files with 30 additions and 71 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

101
xep-0406.xml
View File

@ -49,27 +49,23 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The Mediated Information eXchange (MIX) protocol framework and core capbilities 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>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='Requirements' anchor='reqs'>
<p></p>
</section1>
<section1 topic='Concepts' anchor='concepts'>
<section2 topic="Admin 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>
<table caption="Standard MIX Nodes">
<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>
@ -78,7 +74,7 @@
<p>
</p>
<section3 topic="Roles" anchor="roles">
<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>
@ -94,11 +90,11 @@
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>
</section3>
</section2>
<section3 topic="Allowed" anchor="allowed-node">
<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>
@ -108,8 +104,8 @@
<item id='alice@wonderland.example'/>
</items>
]]></example>
</section3>
<section3 topic="Banned" anchor="banned-node">
</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>
@ -119,8 +115,8 @@
<item id='macbeth@shakespeare.example'/>
</items>
]]></example>
</section3>
<section3 topic="Configuration Node" anchor="config-node">
</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>
@ -173,67 +169,30 @@
</item>
</items>
]]></example>
</section3>
</section2>
</section1>
</section2>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Administrative Use Cases' anchor='usecases-admin'>
<section1 topic='Administrative Use Cases' anchor='usecases-admin'>
<section3 topic='Creating a Channel' anchor='usecase-admin-create'>
<example caption="Creating a Channel with Client Specified Parameters" ><![CDATA[
<iq from='hag66@shakespeare.example/UUID-a1j/7533'
id='lx09df27'
to='mix.shakespeare.example'
type='set'>
<create channel='coven' xmlns='urn:xmpp:mix:admin:0'>
<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>
</create>
</iq>
<iq from='mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/UUID-a1j/7533'
type='result'>
<create channel='coven' xmlns='urn:xmpp:mix:admin:0'/>
</iq>
]]></example>
</section3>
<section3 topic='Modifying Channel Information' anchor='usecase-admin-information'>
<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'
@ -254,7 +213,7 @@
<item>
<x xmlns='jabber:x:data' type='form'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:admin:0</value>
<value>urn:xmpp:mix:core:0</value>
</field>
<title>Information Node Modification</title>
<field type='text-multi'
@ -286,7 +245,7 @@
<item>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:admin:0</value>
<value>urn:xmpp:mix:core:0</value>
</field>
<field var='Name'>
<value>Witches Coven</value>
@ -312,14 +271,14 @@
<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:admin:0'/>
<item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:core:0'/>
</items>
</publish>
</pubsub>
</iq>
]]></example>
</section3>
<section3 topic='Modifying Channel Configuration' anchor='usecase-admin-information'>
</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[
@ -398,8 +357,8 @@
</pubsub>
</iq>
]]></example>
</section3>
<section3 topic='Controlling Channel Participants' anchor='usecase-admin-participants'>
</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).
@ -473,11 +432,11 @@
<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>
</section3>
</section2>
</section1>
</section2>
</section1>