diff --git a/xep-0369.xml b/xep-0369.xml index a502450c..ad015aae 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -42,6 +42,7 @@ sek

Make example ids pseudo-random; + Shorten the example BIND2 resources;

@@ -378,10 +379,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa The primary representation of a participant in a MIX channel is a proxy JID, which is an anonymized JID using the same domain as the channel and with the name of the channel encoded, using the format "<channel>+<generated identifier>@<mix domain>". They generated identifier MUST NOT contain the '+' characters. The Channel name MAY contain the '+' character. For example in the channel 'coven@mix.shakespeare.example', the user 'hag66@shakespeare.example' might have a proxy JID of 'coven+123456@mix.shakespeare.example'. The reason for the proxy JID is to support JID Hidden channels. Proxy JIDs are also used in JID Visible channels, for consistency and to enable switching of JID visibility. The "urn:xmpp:mix:nodes:jidmap" node maps from proxy JID to real JID. While a user is a participant in a Channel, the mapping between real JID and proxy JID MUST NOT be changed.

- The example real full JIDs in this specification follow the anticipated new format that splits the resource into two parts. The first part is UUID that is a stable and fixed value for the client. The second part is server assigned and will vary with each session. For example: 'hag66@shakespeare.example/d104f6a7-97e9-477f-8947-e4a37691d7ee/7533375f-2cd1-4455-a311-494bab21f9f0'. CITATION TO BE ADDED. If the final specification differs from this, the examples will be updated. It is intended to use shorter values if possible, as long as this complies with recommendations of the specifications. + The example real full JIDs in this specification are aligned the anticipated new format that splits the resource into two parts. The first part is UUID that is a stable and fixed value for the client and is anticipated to be a fixed format which may well be UUID 4. The second part is server assigned and will vary with each session. A realistic JID with resource is: 'hag66@shakespeare.example/d104f6a7-97e9-477f-8947-e4a37691d7ee/7533375f2cd'. This specification uses examples of the style: 'hag66@shakespeare.example/UUID-a1j/7533' which are aligned to real resources, but more compact. CITATION TO BE ADDED. If the final specification differs from this, the examples will be updated.

- The full JIDs held in the presence nodes are anonymized using a similar mechanism. First the bare JID is mapped to a bare proxy JID, using the mapping held in the "urn:xmpp:mix:nodes:jidmap" node for the bare JID. Then the resource is replaced with a generated value. For example, 'hag66@shakespeare.example/d104f6a7-97e9-477f-8947-e4a37691d7ee/7533375f-2cd1-4455-a311-494bab21f9f0' in the channel coven might have a proxy JID of 'coven+123456@mix.shakespeare.example/789'. There is no client visible mapping of proxy full JIDs maintained as this is not needed. The MIX channel will need to maintain a mapping, to support directly addressing clients, such as for client to client disco#info queries. While an anonymized JID is held in the presence node, the mapping to real JID MUST NOT be changed. When an anonoymized full JID is added to the presence node, mapping to a real full JID that was previously in the presence node, the same anonymized JID as the previous time MAY be used or a different anonymized JID MAY be used. + The full JIDs held in the presence nodes are anonymized using a similar mechanism. First the bare JID is mapped to a bare proxy JID, using the mapping held in the "urn:xmpp:mix:nodes:jidmap" node for the bare JID. Then the resource is replaced with a generated value. For example, 'hag66@shakespeare.example/UUID-a1j/7533' in the channel coven might have a proxy JID of 'coven+123456@mix.shakespeare.example/789'. There is no client visible mapping of proxy full JIDs maintained as this is not needed. The MIX channel will need to maintain a mapping, to support directly addressing clients, such as for client to client disco#info queries. While an anonymized JID is held in the presence node, the mapping to real JID MUST NOT be changed. When an anonoymized full JID is added to the presence node, mapping to a real full JID that was previously in the presence node, the same anonymized JID as the previous time MAY be used or a different anonymized JID MAY be used.

@@ -638,7 +639,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa An entity MAY discover a MIX service or MIX services by sending a Service Discovery items ("disco#items") request to its own server.

@@ -647,7 +648,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

To determine if a domain hosts a MIX service, a &xep0030; info query is sent in the usual manner to determine capabilities.

@@ -670,7 +671,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

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.

@@ -705,7 +706,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -718,7 +719,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

In order to find out more information about a given channel, a user can send a disco#info query to the channel.

@@ -729,7 +730,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

Use disco#items to find the nodes associated with a channel. Discovering nodes in MIX MUST use the node='mix' attribute. The MIX service MUST only return nodes that exist and that the user making the query has rights to subscribe to.

@@ -755,7 +756,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

The Information Node contains various information about the channel that can be useful to the user, that the client can access using PubSub, as shown below.

@@ -785,7 +786,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -828,7 +829,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -845,17 +846,17 @@ This approach enables flexible support of multiple clients for a MIX channel pa Where a client supports MIX, it MUST advertise this capability in response to a Disco request. This will enable other entities to determine if a client supports MIX, and in particular it facilitates the client's server to determine client support. This can be optimized by use of CAPS. The following example shows a Disco request to and response from a client that supports both MIX and MUC.

- @@ -885,7 +886,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -985,7 +986,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

@@ -995,7 +996,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -1091,7 +1092,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

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. This query is direct from the client to the MIX channel.

@@ -1099,7 +1100,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -1128,7 +1129,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

@@ -1150,7 +1151,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -1178,7 +1179,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -1267,7 +1268,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

@@ -1283,7 +1284,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa thirdwitch @@ -1300,14 +1301,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa

@@ -1323,7 +1324,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa a <register/> command to the service.

@@ -1335,7 +1336,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa thirdwitch @@ -1346,7 +1347,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -1377,7 +1378,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

A user setting status is now used as an example. Unlike in &xep0045; where coming online is a special action, coming online in MIX is implicit when presence status is set. Going offline is a achieved by setting presence status to unavailable, which removes the client full JID entry from the presence node. When a user sets a presence status, the user's server sends updated presence to the MIX channel, and the MIX service then publishes the user's availability to the "urn:xmpp:mix:nodes:presence" node. If there is not an item named by the full JID of the client with updated presence status, this item is created.

- dnd Making a Brew @@ -1446,7 +1447,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

When a client goes offline, this presence update is sent by the client's server to the MIX channel. From the client perspective, this is the same as any other presence change. Handling by the MIX channel is slightly different.

]]>

The MIX channel will retract (remove) the item in the presence node of the MIX channel identified by the client's full JID. The MIX channel will notify subscribers to the presence node of the user going offline by sending a presence stanza to the full proxy JID of each client.

@@ -1469,7 +1470,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

A client sends a message directly to a MIX channel as a standard groupchat message, in exactly the same way as for &xep0045;. Messages are sent directly to the MIX channel from the user's client. The message id is selected by the client.

@@ -1510,7 +1511,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. If this is done the original message MAY be replaced by a tombstone. The protocol to request retraction does this by a message with a <retract> element as shown in the following example.

@@ -1530,7 +1531,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa With this approach, the original message <body> is removed and replaced with a tombstone using the <retracted> element that shows the JID of user performing the retraction and the time of the retraction.

+ @@ -1567,7 +1568,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa 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 has 'Participation Addition by Invitation from Participant' mode enabled. 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.

@@ -1579,7 +1580,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -1595,7 +1596,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa The inviter can now send the invitee a message containing the invitation, as shown in the following example.

Would you like to join the coven? @@ -1631,9 +1632,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
  • 'Acknowledged': The invitation is acknowledged, without information on action taken or planned.
    • + to='hag66@shakespeare.lit/UUID-h5z/0253'> No Thanks - too busy chasing mice.... Declined @@ -1672,7 +1673,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    A user MAY request the vCard of a channel participant by sending a request through the channel. The request MAY be sent directly by the client or MAY be sent by the user's server on behalf of the user. The MIX channel MAY pass this request on or MAY block it. vCard requests MAY use &xep0054; (vcard-temp) or &xep0292; (vCard4 over XMPP). Where a MIX service supports one or both of these protocols, the protocol MUST be advertised as a feature of the MIX service. In the following example, using vcard-temp, the requesting client sends a message to the anonymized bare JID of the channel participant for which the vCard is desired.

    @@ -1715,7 +1716,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa Peter Saint-Andre @@ -1796,7 +1797,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa 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.

    @@ -1805,7 +1806,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -1832,7 +1833,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -1841,7 +1842,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa 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.

    @@ -1871,7 +1872,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -1885,7 +1886,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa Channels 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.

    @@ -1894,7 +1895,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -1909,7 +1910,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa This will generally be done by the user creating the channel before the other user is invited, but MAY be sent by either the user creating the channel or the 1:1 chat partner at any time subsequently.

    @@ -1917,7 +1918,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa Harpier cries: 'tis time, 'tis time. @@ -1935,7 +1936,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa A client destroys a channel using a simple set operation, as shown in the following example.

    @@ -1944,7 +1945,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]> @@ -1958,7 +1959,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    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.

    @@ -1969,7 +1970,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -1996,7 +1997,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]>

    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.

    @@ -2023,7 +2024,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -2037,7 +2038,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    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.

    @@ -2048,7 +2049,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -2067,7 +2068,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]>

    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.

    @@ -2099,7 +2100,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -2115,7 +2116,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa 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).

    @@ -2126,7 +2127,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -2140,7 +2141,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa 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.

    @@ -2153,7 +2154,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -2162,7 +2163,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa JIDs can be removed from the Allowed and Banned nodes by pubsub retract command.

    @@ -2175,7 +2176,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -2227,7 +2228,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa Harpier cries: 'tis time, 'tis time. @@ -2236,7 +2237,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa     Harpier cries: 'tis time, 'tis time. @@ -2270,7 +2271,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa