mirror of https://github.com/moparisthebest/xeps
Updates to configuration and information description
Creating channels and modifying configuration and information
This commit is contained in:
Steve Kille
Sam Whited
parent
cfbcf553e9
commit
9ef9c942c7
572
xep-0369.xml
572
xep-0369.xml
|
|
@ -384,39 +384,45 @@
|
|||
</section3>
|
||||
<section3 topic="Information Node" anchor="info-node">
|
||||
|
||||
<p>The Information node holds information about the channel. The information node is named by the name of the node, which must be present. Other elements of the information node are optional. Information history is stored in MAM. 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. Users MAY subscribe to this node to receive information updates. The Information node has the following attributes:
|
||||
<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</li>
|
||||
<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>'Administrator'. The person or role responsible for the channel, using vCard format following &xep0054;.</li>
|
||||
<li>'Contact'. The JID of the person or role responsible for the channel. This MAY be the JID of a MIX channel.</li>
|
||||
|
||||
<li>'Avatar'. An Avatar associated with the channel. This MAY be used in rosters that hold information on the channel and MAY be displayed by clients using the channel. The avatar is stored using the format defined in &xep0084;</li>
|
||||
<li>'Avatar'. An Avatar associated with the channel. This MAY be used in rosters that hold information on the channel and MAY be displayed by clients using the channel. The avatar is stored using the base 64 encoded format defined in &xep0084;</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 can be directly written to the PubSub node.
|
||||
<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.
|
||||
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[
|
||||
<items node='urn:xmpp:mix:nodes:info'>
|
||||
<item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:0'>
|
||||
<name>Witches Coven</name>
|
||||
<description>A location not far from the blasted heath where the three witches meet</description>
|
||||
<administrator>
|
||||
<vCard xmlns='vcard-temp'>
|
||||
<FN>Hecate</FN>
|
||||
<TITLE>Chief Witch</TITLE>
|
||||
</vCard>
|
||||
</administrator>
|
||||
<avatar>
|
||||
<data xmlns='urn:xmpp:avatar:data'>
|
||||
qANQR1DBwU4DX7jmYZnncm...
|
||||
</data>
|
||||
</avatar>
|
||||
<x xmlns='jabber:x:data' type='result'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:mix: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.lit</value>
|
||||
</field>
|
||||
<field var='Avatar'>
|
||||
<value>base64-encoded-data</value>
|
||||
</field>
|
||||
</x>
|
||||
</item>
|
||||
</items>
|
||||
]]></example>
|
||||
|
|
@ -456,46 +462,84 @@
|
|||
|
||||
<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 at a time, 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 provided:
|
||||
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:
|
||||
</p>
|
||||
<table caption="Configuration Node Options">
|
||||
<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>'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.</td><td>list-multi</td><td>'participants'; 'presence'; 'subject'; 'information'; 'allowed'; 'banned'</td><td>-</td></tr>
|
||||
|
||||
<tr><td>'Message 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>'Subject Node Subscription'</td><td>Controls who can subscribe to subject node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone' </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>'Kick Rights'</td><td>Controls who can kick users from the channel.</td><td>list-single</td><td>'admins'; 'owners'; 'nobody' </td><td>'admins'</td></tr>
|
||||
|
||||
<tr><td>'JID Visibility'</td><td>Controls JID visibility in the channel.</td><td>list-single</td><td>'jid-hidden'; 'jid-optionally-visible'; 'jid-mandatory-visible'</td><td>'jid-hidden'</td></tr>
|
||||
|
||||
<tr><td>'Open Presence'</td><td>If selected, any client may register presence. If not selected, only clients with bare JID in the participants list may register presence.</td><td>boolean</td><td>-</td><td>false</td></tr>
|
||||
|
||||
<tr><td>'Allow Message Retraction</td><td>If this option is selected users will be able to retract messages sent to the MIX channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
|
||||
|
||||
<tr><td>'Participation Addition by Invitation from Participant'</td><td>This option extends a channel so that a channel participant has rights to invite and enable other users as participants.</td><td>boolean</td><td>-</td><td>false</td></tr>
|
||||
|
||||
<tr><td>'No Private Messages'</td><td>If this option is selected, private messages may not be used with the channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
|
||||
</table>
|
||||
|
||||
<ul>
|
||||
<li>'Date of Configuration Change'. Encoded as the item ID.</li>
|
||||
<li>'Last Change Made By'. Bare JID of the user making the last change.</li>
|
||||
<li>'Owners'. List of bare JIDs with Owner rights as defined in ACL node. When a list is created, the JID creating the list is configured as an owner, unless this attribute is explicitly configured to another value. Owners will generally have full rights to make changes to channel configuration and access control.</li>
|
||||
<li>'Administrators'. List of bare JIDs with Administrator rights. An Administrator has rights to make changes to channel access control and configuration as defined in ACL node. An Administrator also has operational right on a channel, such a kicking users out of the channel. These rights are analogous to moderator rights defined in &xep0045;.</li>
|
||||
|
||||
<li>'End of Life'. The date and time at which the channel will be automatically removed by the server. If this is not set, the channel is permanent.</li>
|
||||
<li>'Nodes Present'. Specifies which nodes are present: "participants"; "presence"; "subject"; "information"; "allowed"; "banned". Note that "config" is implicit, and "jidmap" is implied by "participants". </li>
|
||||
|
||||
<li>'Message Node Subscription'. Controls who can subscribe to messages node: "participants"; "allowed"; "anyone". Default "participants".</li>
|
||||
<li>'Participants Node Subscription'. Controls who can subscribe to participants node: "participants"; "allowed"; "anyone"; "nobody". Default "participants".</li>
|
||||
|
||||
<li>'Presence Node Subscription'. Controls who can subscribe to presence node: "participants"; "allowed"; "anyone"; "nobody". Default "participants".</li>
|
||||
<li>'Subject Node Subscription'. Controls who can subscribe to subject node: "participants"; "allowed"; "anyone"; "nobody". Default "participants".</li>
|
||||
<li>'Configuration Node Access'. Controls who can subscribe to and has read access configuration node: "participants"; "admins"; "owners"; "nobody". Default "admins".</li>
|
||||
|
||||
<li>'Kick Rights'. Controls who can kick users from the channel: "admins"; "owners"; "nobody". Default "admins".</li>
|
||||
|
||||
<li>'Information Node Update Rights'. Controls who can make changes to information node: "admins"; "owners". Default "owners".</li>
|
||||
|
||||
<li>'JID Visibility'. Choice of "jid-hidden", "jid-optionally-visible", "jid-mandatory-visible". </li>
|
||||
<li>'Open Presence'. If selected, any client may register presence. If not selected, only clients with bare JID in the participants list may register presence.</li>
|
||||
<li>'Allow Message Retraction'. If this option is selected users will be able to retract messages sent to the MIX channel.</li>
|
||||
<li>'Participation Addition by Invitation from Participant'. This option extends a channel so that a channel participant has rights to invite and enable other users as participants.
|
||||
</li>
|
||||
<li>'No Private Messages'. If this option is selected, private messages may not be used with the channel.</li>
|
||||
|
||||
</ul>
|
||||
<p>AUTHOR'S NOTE: This version contains a number of AUTHOR NOTES, which are reminder instructions to the author as to editing actions to be taken, and also indicate where changes are anticipated in future versions.</p>
|
||||
<p>AUTHOR'S NOTE AND QUESTION: Detailed review of this section is solicited, and requirements for any additional configuration control.</p>
|
||||
<p>The format of the ACL node follows &xep0004;. </p>
|
||||
<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'>
|
||||
*** TBS ****
|
||||
<item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:0'>
|
||||
<x xmlns='jabber:x:data' type='result'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:mix:0</value>
|
||||
</field>
|
||||
<field var='Owner'>
|
||||
<value>hecate@shakespeare.lit</value>
|
||||
</field>
|
||||
<field var='Owner'>
|
||||
<value>greymalkin@shakespeare.lit</value>
|
||||
</field>
|
||||
<field var='Message 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>
|
||||
</items>
|
||||
]]></example>
|
||||
|
||||
|
||||
|
|
@ -535,7 +579,6 @@
|
|||
name='Shakespearean Chat Service'
|
||||
type='text'/>
|
||||
<feature var='urn:xmpp:mix:0'/>
|
||||
</x>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
|
@ -646,19 +689,24 @@
|
|||
to='hag66@shakespeare.lit'
|
||||
type='result'>
|
||||
<query xmlns='urn:xmpp:mix:0#channel-info'>
|
||||
<name>Witches Coven</name>
|
||||
<description>A location not far from the blasted heath where the three witches meet</description>
|
||||
<administrator>
|
||||
<vCard xmlns='vcard-temp'>
|
||||
<FN>Hecate</FN>
|
||||
<TITLE>Chief Witch</TITLE>
|
||||
</vCard>
|
||||
</administrator>
|
||||
<avatar>
|
||||
<data xmlns='urn:xmpp:avatar:data'>
|
||||
qANQR1DBwU4DX7jmYZnncm...
|
||||
</data>
|
||||
</avatar>
|
||||
<x xmlns='jabber:x:data' type='result'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:mix: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.lit</value>
|
||||
</field>
|
||||
<field var='Avatar'>
|
||||
<value>base64-encoded-data</value>
|
||||
</field>
|
||||
</x>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
||||
|
|
@ -893,8 +941,44 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
</iq>
|
||||
]]></example>
|
||||
|
||||
<p>The client may also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard. The result is a form template.</p>
|
||||
<p>The client may also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard, by providing a form template in the result.</p>
|
||||
<example caption="User Requests and Recieves Preferences Template Form"><![CDATA[
|
||||
<iq type='get'
|
||||
from='hag66@shakespeare.example'
|
||||
to='coven@mix.shakespeare.example'
|
||||
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
|
||||
<user-preference xmlns='urn:xmpp:mix:0'/>
|
||||
</iq>
|
||||
|
||||
<iq type='result'
|
||||
from='coven@mix.shakespeare.example'
|
||||
to='hag66@shakespeare.example'
|
||||
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
|
||||
<user-preference xmlns='urn:xmpp:mix:0'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:mix:0</value>
|
||||
</field>
|
||||
<field type='list-single' label='Preference for JID Visibility' var='JID Visibility'>
|
||||
<option label='JID Never Shown'><value>Never</value></option>
|
||||
<option label='Default Behaviour'><value>Default</value></option>
|
||||
<option label='Try not to show JID'><value>Prefer Not</value></option>
|
||||
</field>
|
||||
<field type='list-single' label='Example Custom Preference' var='Custom Preference'>
|
||||
<option label='One Option'><value>A</value></option>
|
||||
<option label='Another Option'><value>B</value></option>
|
||||
</field>
|
||||
</x>
|
||||
</user-preference>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
||||
<p>
|
||||
A user may modify preferences using the corresponding set operation. The set may specify values for some or all attributes. All attributes are returned in the result.
|
||||
</p>
|
||||
|
||||
|
||||
<example caption="User Updates Preferences"><![CDATA[
|
||||
<iq type='set'
|
||||
from='hag66@shakespeare.example'
|
||||
to='coven@mix.shakespeare.example'
|
||||
|
|
@ -937,42 +1021,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
</x>
|
||||
</user-preference>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
||||
<p>
|
||||
A user may modify preferences using the corresponding set operation.
|
||||
</p>
|
||||
|
||||
|
||||
<example caption="User Updates Preferences"><![CDATA[
|
||||
<iq type='get'
|
||||
from='hag66@shakespeare.example'
|
||||
to='coven@mix.shakespeare.example'
|
||||
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
|
||||
<user-preference xmlns='urn:xmpp:mix:0'/>
|
||||
</iq>
|
||||
|
||||
<iq type='result'
|
||||
from='coven@mix.shakespeare.example'
|
||||
to='hag66@shakespeare.example'
|
||||
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
|
||||
<user-preference xmlns='urn:xmpp:mix:0'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:mix:0</value>
|
||||
</field>
|
||||
<field type='list-single' label='Preference for JID Visibility' var='JID Visibility'>
|
||||
<option label='JID Never Shown'><value>Never</value></option>
|
||||
<option label='Default Behaviour'><value>Default</value></option>
|
||||
<option label='Try not to show JID'><value>Prefer Not</value></option>
|
||||
</field>
|
||||
<field type='list-single' label='Example Custom Preference' var='Custom Preference'>
|
||||
<option label='One Option'><value>A</value></option>
|
||||
<option label='Another Option'><value>B</value></option>
|
||||
</field>
|
||||
</x>
|
||||
</user-preference>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section3>
|
||||
|
||||
|
|
@ -1533,43 +1581,117 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
<section2 topic='Administrative Use Cases' anchor='usecases-admin'>
|
||||
<section3 topic='Checking For Permission To Create a Channel' anchor='usecase-admin-check-create'>
|
||||
<p>
|
||||
MIX does not standardize an access control model for creating and deleting MIX channels. The choice is left to the MIX implementer, and could be a very simple or complex approach.
|
||||
|
||||
|
||||
MIX does not standardize an access control model for creating and deleting MIX channels. The choice is left to the MIX implementer, and could be a very simple or complex approach. A client can determine if it has permission to create a channel on a MIX service, which may be used to control options presented to the user. This is achieved by a disco command on the MIX service. If the 'create-channel' feature is returned, the user is able to create a channel.
|
||||
</p>
|
||||
<p>
|
||||
AUTHOR'S NOTE: MIX Protocol to be added to create channel; check for permission to create channel; delete channel
|
||||
</p>
|
||||
<example caption="" ><![CDATA[
|
||||
|
||||
<example caption="Client determines Capability to Create a Channel" ><![CDATA[
|
||||
<iq from='hag66@shakespeare.example/intibo24'
|
||||
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/intibo24'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
<identity
|
||||
category='conference'
|
||||
name='Shakespearean Chat Service'
|
||||
type='text'/>
|
||||
<feature var='urn:xmpp:mix:0'/>
|
||||
<feature var='create-channel' xmlns='urn:xmpp:mix:0'>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section3>
|
||||
|
||||
|
||||
|
||||
<section3 topic='Creating a Channel' anchor='usecase-admin-create'>
|
||||
<p>
|
||||
A client creates a channel by sending a simple request to the MIX service. A channel may be created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present).
|
||||
</p>
|
||||
<example caption="Creating a Channel with Default Parameters" ><![CDATA[
|
||||
<iq from='hag66@shakespeare.example/intibo24'
|
||||
id='lx09df27'
|
||||
to='mix.shakespeare.example'
|
||||
type='set'>
|
||||
<create channel='coven' xmlns='urn:xmpp:mix:0'/>
|
||||
</iq>
|
||||
|
||||
AUTHOR'S NOTE: Dave Cridland has suggested the following protocol.
|
||||
|
||||
<![CDATA[
|
||||
<iq to='mix.cridland.im' type='set'>
|
||||
<create channel='some-room-here@mix.cridland.im' xmlns='urn:xmpp:mix:0'>
|
||||
<optional-configuration-form/>
|
||||
<iq from='mix.shakespeare.example'
|
||||
id='lx09df27'
|
||||
to='hag66@shakespeare.example/intibo24'
|
||||
type='result'>
|
||||
<create channel='coven' xmlns='urn:xmpp:mix:0'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
||||
<p>
|
||||
The client may also include parameters in &xep0004; format as part of channel creation. If the client wishes to inspect configuration, channel administration procedures should be used.
|
||||
</p>
|
||||
|
||||
<example caption="Creating a Channel with Client Specified Parameters" ><![CDATA[
|
||||
<iq from='hag66@shakespeare.example/intibo24'
|
||||
id='lx09df27'
|
||||
to='mix.shakespeare.example'
|
||||
type='set'>
|
||||
<create channel='coven' xmlns='urn:xmpp:mix:0'>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:mix:0</value>
|
||||
</field>
|
||||
<field var='Owner'>
|
||||
<value>hecate@shakespeare.lit</value>
|
||||
</field>
|
||||
<field var='Owner'>
|
||||
<value>greymalkin@shakespeare.lit</value>
|
||||
</field>
|
||||
<field var='Message 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>
|
||||
]]>
|
||||
</p>
|
||||
<example caption="" ><![CDATA[
|
||||
|
||||
<iq from='mix.shakespeare.example'
|
||||
id='lx09df27'
|
||||
to='hag66@shakespeare.example/intibo24'
|
||||
type='result'>
|
||||
<create channel='coven' xmlns='urn:xmpp:mix:0'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
||||
</section3>
|
||||
|
||||
|
||||
<section3 topic='Creating a Channel for Ad Hoc User' anchor='usecase-admin-create-adhoc'>
|
||||
<section3 topic='Creating a Channel for Ad Hoc Use' anchor='usecase-admin-create-adhoc'>
|
||||
<p>
|
||||
Rooms may be created for ad hoc use between a set of users. Channels of this nature will have channel name created by the server and will not be addressable or discoverable.
|
||||
Rooms may be created for ad hoc use between a set of users. Channels of this nature will have channel name created by the server and will not be addressable or discoverable. Here a channel is created without specifying the channel name. Parameters for the channel may also be specified.
|
||||
</p>
|
||||
<example caption="" ><![CDATA[
|
||||
<example caption="Creating a Channel for Ad Hoc Use" ><![CDATA[
|
||||
<iq from='hag66@shakespeare.example/intibo24'
|
||||
id='lx09df27'
|
||||
to='mix.shakespeare.example'
|
||||
type='set'>
|
||||
<create xmlns='urn:xmpp:mix:0'/>
|
||||
</iq>
|
||||
|
||||
<iq from='mix.shakespeare.example'
|
||||
id='lx09df27'
|
||||
to='hag66@shakespeare.example/intibo24'
|
||||
type='result'>
|
||||
<create channel='A1B2C345' xmlns='urn:xmpp:mix:0'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
||||
</section3>
|
||||
|
|
@ -1577,64 +1699,192 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
|
||||
<section3 topic='Destroying a Channel' anchor='usecase-admin-destroy'>
|
||||
<p>
|
||||
MIX channels are always explicitly destroyed by an owner of the channel or by a server operator. There is no concept of temporary channel, equivalent to &xep0045; temporary room which is automatically destroyed by the server when the users leave. However, channels may be configured with an explicit lifetime, after which the channel MUST be removed by the MIX server. Where a channel is created for ad hoc use, it may be desirable to keep the channel for history reference or for re-use by the same set of users.
|
||||
|
||||
|
||||
</p>
|
||||
|
||||
<p>Note that the owner of the channel does not need to have presence registered in the channel in order to destroy it.</p>
|
||||
MIX channels are always explicitly destroyed by an owner of the channel or by a server operator. There is no concept of temporary channel, equivalent to &xep0045; temporary room which is automatically destroyed by the server when the users leave. However, channels MAY be configured with an explicit lifetime, after which the channel MUST be removed by the MIX server. Where a channel is created for ad hoc use, it may be desirable to keep the channel for history reference or for re-use by the same set of users. Note that the owner of the channel does not need to have presence registered in the channel in order to destroy it.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
AUTHOR'S NOTE: More TBS
|
||||
|
||||
|
||||
A client destroys a channel using a simple set operation, as shown in the following example.
|
||||
</p>
|
||||
|
||||
<example caption="" ><![CDATA[
|
||||
|
||||
<example caption="Client Destroys a Channel" ><![CDATA[
|
||||
<iq from='hag66@shakespeare.example/intibo24'
|
||||
id='lx09df27'
|
||||
to='mix.shakespeare.example'
|
||||
type='set'>
|
||||
<destroy channel='coven' xmlns='urn:xmpp:mix:0'/>
|
||||
</iq>
|
||||
|
||||
<iq from='mix.shakespeare.example'
|
||||
id='lx09df27'
|
||||
to='hag66@shakespeare.example/intibo24'
|
||||
type='result'>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
||||
</section3>
|
||||
|
||||
<section3 topic='Server Destroying a Channel' anchor='usecase-server-destroy'>
|
||||
<p>
|
||||
Servers may destroy channels which have no participants and/or presence according to local policy. There will often be good reasons to not destroy rooms in these scenarios.
|
||||
A server MUST destroy a channel that has exceeded its specified explicit lifetime.
|
||||
Servers may destroy channels which have no participants and/or presence according to local policy. There will often be good reasons to not destroy rooms in these scenarios, in particular to facilitate channel re-use and history access.
|
||||
|
||||
</p>
|
||||
|
||||
</section3>
|
||||
|
||||
<section3 topic='Modifying Channel Information' anchor='usecase-admin-information'>
|
||||
<p></p>
|
||||
<example caption="" ><![CDATA[
|
||||
|
||||
<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>
|
||||
|
||||
<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'/>
|
||||
</iq>
|
||||
|
||||
<iq from='mix.shakespeare.example'
|
||||
id='lx09df27'
|
||||
to='hag66@shakespeare.example/intibo24'
|
||||
type='result'>
|
||||
<info xmlns='urn:xmpp:mix:0'/>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:mix: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>
|
||||
</info>
|
||||
</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>
|
||||
|
||||
|
||||
<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'>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:mix: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.lit</value>
|
||||
</field>
|
||||
</x>
|
||||
</info>
|
||||
</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'/>
|
||||
</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>
|
||||
|
||||
<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'/>
|
||||
</iq>
|
||||
|
||||
<iq from='mix.shakespeare.example'
|
||||
id='lx09df27'
|
||||
to='hag66@shakespeare.example/intibo24'
|
||||
type='result'>
|
||||
<config xmlns='urn:xmpp:mix:0'/>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:mix:0</value>
|
||||
</field>
|
||||
<title>Configuration Node Modification</title>
|
||||
<field type=jid-multi'
|
||||
label='Channel Administrator'
|
||||
var='Administrator'/>
|
||||
</x>
|
||||
</config>
|
||||
</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>
|
||||
|
||||
|
||||
<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'>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:mix:0</value>
|
||||
</field>
|
||||
<field var='Owner'>
|
||||
<value>hecate@shakespeare.lit</value>
|
||||
</field>
|
||||
<field var='Owner'>
|
||||
<value>greymalkin@shakespeare.lit</value>
|
||||
</field>
|
||||
<field var='Message 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>
|
||||
</config>
|
||||
</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'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section3>
|
||||
|
||||
|
||||
<section3 topic='Controlling Channel Partipcipants' anchor='usecase-admin-participants'>
|
||||
<p>
|
||||
Admins.
|
||||
|
||||
Allowed and Banned lists.
|
||||
Owners and Administrators may control which users can participate in a channel by use of Allowed and Banned lists.
|
||||
Allowed and Banned lists may be read by PubSub query of the Banned and Allowed Nodes.
|
||||
</p>
|
||||
<example caption="" ><![CDATA[
|
||||
|
||||
]]></example>
|
||||
</section3>
|
||||
|
||||
|
||||
<section3 topic='Configuring a Channel' anchor='usecase-admin-'>
|
||||
<p>
|
||||
Channel jid is set on channel creation and may not be changed. All other channel may be changed if channel configuration allows.
|
||||
</p>
|
||||
<p>
|
||||
|
||||
AUTHOR'S NOTE: Allow configuration by direct writes to 'urn:xmpp:mix:nodes:config' . Also specify MIX XEP-0004 commands to achieve this.
|
||||
|
||||
|
||||
</p>
|
||||
<example caption="" ><![CDATA[
|
||||
|
||||
<example caption="Client Reads Allowed Node" ><![CDATA[
|
||||
*** AUTHOR TBS
|
||||
]]></example>
|
||||
|
||||
|
||||
|
|
@ -1643,12 +1893,10 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
<section3 topic='Removing a User From a Channel (Kicking)' anchor='usecase-admin-kick'>
|
||||
<p></p>
|
||||
<example caption="" ><![CDATA[
|
||||
|
||||
*** AUTHOR TBS
|
||||
]]></example>
|
||||
|
||||
|
||||
|
|
@ -1699,7 +1947,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
<p>For the partially integrated service, it will be useful for clients that support both MIX and MUC to be able to determine that the server supports both protocols. For a MIX client, it will be useful to know the MUC service, so that this information can be shared with a MUC client invitation. This information is provided by the initial service discovery:</p>
|
||||
|
||||
|
||||
<example caption="MIX Service responds with Disco Info result sharig MUC service location" ><![CDATA[
|
||||
<example caption="MIX Service responds with Disco Info result sharing MUC service location" ><![CDATA[
|
||||
<iq from='mix.shakespeare.example'
|
||||
id='lx09df27'
|
||||
to='hag66@shakespeare.example/intibo24'
|
||||
|
|
|
|||
Loading…
Reference in New Issue