diff --git a/xep-0369.xml b/xep-0369.xml index b5ce09b2..c030d35c 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -45,6 +45,9 @@ Use MAM ID to identify message; Clarify use of the various channel names; Require all client operations to be direct or indirect (choice is just confusing); + Add description of implicit activation ; + MIX Domains must not contain users; + Clarification on identifying channels in rosters;

@@ -253,6 +256,7 @@
  • Each participant is addressable by a single bare JID, which is a proxy JID (not the user's real JID) to make it straightforward to hide the user's real JID from other channel participants. Full JIDs comprised of this bare JID plus a resource (also anonymized) are then constructed, allowing visibility into the number of online resources participating in a channel.
  • MIX requires client support and server support from the server providing the MIX service. Although some protocol is shared with MUC, MUC clients are not interoperable with a MIX service. This means that where a user chooses to use MIX, all of the users clients need to support MIX.
  • MIX requires the server to which the MIX client connects to provide functionality to support MIX. This functionality is defined in this specification and referenced as "MIX Participant's Server Behaviour".
    • +
  • MIX domains MUST NOT be used for end user JIDs.
    • @@ -639,7 +643,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    A MIX service MUST NOT advertise support for &xep0313;, as MAM is supported by the channels and not by the service. A MIX service MUST NOT advertise support for generic &xep0060;, as although MIX makes use of PubSub it is not a generic PubSub service.

     -

    The list of channels supported by a MIX service is obtained by a disco#items command. The MIX service MUST only return channel that exist and that the user making the query has rights to subscribe to. This query MUST be made dindirectly by the user's server.

    +

    The list of channels supported by a MIX service is obtained by a disco#items command. The MIX service MUST only return channel that exist and that the user making the query has rights to subscribe to. This query MUST be made indirectly by the user's server.

    + +

    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. @@ -1675,10 +1681,10 @@ the participant is not be subscribed to all nodes associated with the channel (i

    -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). + 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). Creating and destroying a channel MUST be done indirectly by the user's server using the user's bare JID.

    @@ -1687,7 +1693,7 @@ A client creates a channel by sending a simple request to the MIX service. A c @@ -1696,7 +1702,7 @@ A client creates a channel by sending a simple request to the MIX service. A c 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.

    @@ -1726,7 +1732,7 @@ A client creates a channel by sending a simple request to the MIX service. A c @@ -1740,7 +1746,7 @@ A client creates a channel by sending a simple request to the MIX service. A c 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.

    @@ -1749,7 +1755,7 @@ A client creates a channel by sending a simple request to the MIX service. A c @@ -1790,7 +1796,7 @@ A client creates a channel by sending a simple request to the MIX service. A c A client destroys a channel using a simple set operation, as shown in the following example.

    @@ -1799,7 +1805,7 @@ A client creates a channel by sending a simple request to the MIX service. A c ]]> @@ -1813,7 +1819,7 @@ A client creates a channel by sending a simple request to the MIX service. A c

    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.

    @@ -1824,7 +1830,7 @@ A client creates a channel by sending a simple request to the MIX service. A c @@ -1851,7 +1857,7 @@ A client creates a channel by sending a simple request to the MIX service. A c ]]>

    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.

    @@ -1877,7 +1883,7 @@ A client creates a channel by sending a simple request to the MIX service. A c @@ -1888,9 +1894,10 @@ A client creates a channel by sending a simple request to the MIX service. A c ]]>     -

    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.

    +

    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 MUST be done indirectly by the user's server. +

    @@ -1901,7 +1908,7 @@ A client creates a channel by sending a simple request to the MIX service. A c @@ -1920,7 +1927,7 @@ A client creates a channel by sending a simple request to the MIX service. A c ]]>

    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.

    @@ -1952,7 +1959,7 @@ A client creates a channel by sending a simple request to the MIX service. A c @@ -1965,10 +1972,10 @@ A client creates a channel by sending a simple request to the MIX service. A c

    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). + 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). This MUST be done indirectly by the user's server.

    @@ -1979,7 +1986,7 @@ A client creates a channel by sending a simple request to the MIX service. A c @@ -1993,7 +2000,7 @@ A client creates a channel by sending a simple request to the MIX service. A c 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.

    @@ -2006,7 +2013,7 @@ A client creates a channel by sending a simple request to the MIX service. A c @@ -2015,7 +2022,7 @@ A client creates a channel by sending a simple request to the MIX service. A c JIDs can be removed from the Allowed and Banned nodes by pubsub retract command.

    @@ -2028,7 +2035,7 @@ A client creates a channel by sending a simple request to the MIX service. A c @@ -2053,6 +2060,9 @@ A client creates a channel by sending a simple request to the MIX service. A c

    All messages from MIX channels to participants are sent to the participant's XMPP server. The participant's server will send on these messages to each of the user's clients that has activated the MIX service. MIX provides capabilities for an online client to activate and de-activate MIX for that client. A client MAY activate MIX for all the user's channels or for a selected list. This will enable a mobile client to choose to receive only messages from selected MIX channels. Activation uses an IQ set with an <activate> element to instruct the local server to activate the client. The server responds with a result to confirm activation. The client MAY include one or more <channel> elements, to identify an explicit list of channels that are activated for the client. If mo channels are specified, activation is for all channels where the user is a participant. A client supporting MIX will typically activate MIX as soon as it comes online, but a client MAY also choose to only activate MIX for specific periods.

    +

    + MIX Client activation implicitly verifies that the client's server support's MIX. If the server does not support MIX, it will reject the activation request and the client will not be able to use MIX. +

    Leaving MIX ChannelIndirect Nick SettingIndirect Nick RegistrationIndirect + Channel Creation and DestructionIndirect + Channel Configuration ManagementIndirect

    The rest of this section describes how indirect discovery is achieved, using channel join as an example.