From 9ef9c942c7d83a5dca4bcb3002cd576a3ffd1840 Mon Sep 17 00:00:00 2001
From: Steve Kille 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:
+ 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:
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.
+ 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.
- 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:
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. AUTHOR'S NOTE AND QUESTION: Detailed review of this section is solicited, and requirements for any additional configuration control. The format of the ACL node follows &xep0004;.
+ 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.
+ 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. 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.
+ A user may modify preferences using the corresponding set operation. The set may specify values for some or all attributes. All attributes are returned in the result.
+
- A user may modify preferences using the corresponding set operation.
-
- 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.
- AUTHOR'S NOTE: MIX Protocol to be added to create channel; check for permission to create channel; delete channel
-
+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).
+
+ 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.
+
-
-
+
-
+
+ Name Description Field Type Values Default
+
+ 'Last Change Made By' Bare JID of the user making the last change. jid-single - -
+
+ 'Owner' 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. jid-multi - -
+
+ 'Administrator' Bare JIDs with Administrator rights. jid-multi - -
+
+ '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. text-single - -
+
+ 'Nodes Present' Specifies which nodes are present. Presence of config nodes is implicit. Jidmap node MUST be present if participants node is present. list-multi 'participants'; 'presence'; 'subject'; 'information'; 'allowed'; 'banned' -
+
+ 'Message Node Subscription' Controls who can subscribe to messages node. list-single 'participants'; 'allowed'; 'anyone' 'participants'
+
+ 'Presence Node Subscription' Controls who can subscribe to presence node. list-single 'participants'; 'allowed'; 'anyone' 'participants'
+
+ 'Participants Node Subscription' Controls who can subscribe to participants node. list-single 'participants'; 'allowed'; 'anyone'; 'nobody'; 'admins'; 'owners' 'participants'
+
+ 'Subject Node Subscription' Controls who can subscribe to subject node. list-single 'participants'; 'allowed'; 'anyone' 'participants'
+
+ 'Information Node Subscription' Controls who can subscribe to the information node. list-single 'participants'; 'allowed'; 'anyone' 'participants'
+
+ 'Allowed Node Subscription' Controls who can subscribe to allowed node. list-single 'participants'; 'allowed'; 'nobody'; 'admins'; 'owners' 'admins'
+
+ 'Banned Node Subscription' Controls who can subscribe to banned node. list-single 'participants'; 'allowed'; 'nobody'; 'admins'; 'owners' 'admins'
+
+ 'Configuration Node Access' Controls who can subscribe to configuration node and who has read access to it. list-single 'participants'; 'allowed'; 'nobody'; 'admins'; 'owners' 'owners'
+
+ 'Information Node Update Rights' Controls who can make changes to the information node list-single 'participants'; 'admins'; 'owners' 'admins'
+
+ 'Kick Rights' Controls who can kick users from the channel. list-single 'admins'; 'owners'; 'nobody' 'admins'
+
+ 'JID Visibility' Controls JID visibility in the channel. list-single 'jid-hidden'; 'jid-optionally-visible'; 'jid-mandatory-visible' 'jid-hidden'
+
+ 'Open Presence' If selected, any client may register presence. If not selected, only clients with bare JID in the participants list may register presence. boolean - false
+
+ 'Allow Message Retraction If this option is selected users will be able to retract messages sent to the MIX channel. boolean - false
+
+ '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. boolean - false
+ 'No Private Messages' If this option is selected, private messages may not be used with the channel. boolean - false
-
-
- 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.
-- 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.
+ 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. + +- AUTHOR'S NOTE: More TBS - - + A client destroys a channel using a simple set operation, as shown in the following example.
-- 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.
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.
+ + +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.
+ +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.
+ + +- 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.
-- Channel jid is set on channel creation and may not be changed. All other channel may be changed if channel configuration allows. -
-- - AUTHOR'S NOTE: Allow configuration by direct writes to 'urn:xmpp:mix:nodes:config' . Also specify MIX XEP-0004 commands to achieve this. - - -
-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:
-