From 96e928fb97c159530af64360da07919448d32913 Mon Sep 17 00:00:00 2001 From: LNJ Date: Sat, 5 Jan 2019 13:13:42 +0100 Subject: [PATCH] XEP-405: Fix style and XML-syntax issues --- xep-0405.xml | 120 +++++++++++++++------------------------------------ 1 file changed, 34 insertions(+), 86 deletions(-) diff --git a/xep-0405.xml b/xep-0405.xml index acd89ff6..50c70a5c 100644 --- a/xep-0405.xml +++ b/xep-0405.xml @@ -105,17 +105,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa

Messages from a MIX channel to a MIX participant (which will be of type=groupchat), presence information, and other information sent as a result of MIX channel subscription are sent to the participant's server using the participant's bare JID. This means that the MIX participant's server MUST implement the modification of the standard &rfc6121; message processing rules specified here.

- - - - - - - - -

This section defines behaviour REQUIRED by MIX for servers supporting MIX participants. This functionality MUST be provided by servers used by clients that participate in MIX channels. In future, this specification MAY be incorporated into @@ -126,7 +117,6 @@ This approach enables flexible support of multiple clients for a MIX channel pa

A MIX User's server MUST determine which online clients support MIX. This will enable the server to send MIX traffic to all MIX capable clients, but not to other clients. A MIX capable client MAY choose to come online and not advertise MIX capability. The mechanism for a server to discover client capability is described in Discovering Client MIX Capability.

- @@ -143,8 +133,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='groupchat'> Harpier cries: 'tis time, 'tis time. - thirdwitch - hag66@shakespeare.example + thirdwitch + hag66@shakespeare.example ]]> @@ -162,8 +152,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='groupchat'> Harpier cries: 'tis time, 'tis time. - thirdwitch - hag66@shakespeare.example + thirdwitch + hag66@shakespeare.example @@ -173,8 +163,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='groupchat'> Harpier cries: 'tis time, 'tis time. - thirdwitch - hag66@shakespeare.example + thirdwitch + hag66@shakespeare.example @@ -321,10 +311,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='hag66@shakespeare.example/UUID-a1j/7533' to='hag66@shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - - - + + + ]]> @@ -364,70 +354,48 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='hag66@shakespeare.example' to='hag66@shakespeare.example/UUID-a1j/7533' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - - - + + + ]]> - - - - - -

As part of the channel joining process, the user's server MUST add the MIX channel to the user's roster. This is done to share the user's presence status with the channel and channel participants subscribing to presence, when the user wishes this presence to be shared. These roster entries also enables the user's client to quickly determine which channels the user has joined. The user's server will need to record those roster entries that are associated with MIX channels in order to correctly handle MIX processing. This roster entry will lead to the user's server correctly sending user's presence from all the user's MIX clients to the MIX channel. Where the user wishes to share presence, the roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information about the MIX channel is sent to the user.

-

The participant's server MUST ensure that only presence information from clients that advertise MIX capability is sent to the MIX channel. So, if a user has two online clients, but only one is MIX capable, then the channel will only receive presence information relating to the MIX client.

- -

If the user does not wish to publish presence information to the channel, the user's server will add the roster entry with mode subscription=none. The roster entry will be present to record that the user has joined the channel, but it will not send presence information to the channel. The user's server MUST do this when the user has chosen Presence preference of 'not share' as specified in &xep0404;. If the user changes the value of the preference, the server MUST modify subscription mode to reflect this. -

+

The user's server MUST remove the user's roster entry when the user leaves the channel.

- -

A channel MAY publish an Avatar following &xep0084;. A client MAY make use of this information to associate an Avatar with the roster entry for a channel.

- - - -

- A user joins a channel over an extended period, and participation in a channel does not generally change when a user clients go online or offline. The user's participation in a channel is reflected by the user's bare JID in the participant node. When a user subscribes to presence as specified in &xep0403;, all presence messages are sent to this JID. Presence updates are sent out to subscribing participants using standard presence stanzas. -

-

- A user MAY share presence information with the channel, for the user's online clients. This is achieved by a roster entry for the channel configured with one way presence, which will cause all presence changes for the user's MIX clients to be sent to the channel. When an XMPP client comes online or changes presence status, this will be communicated by the user to the user's server using broadcast presence. The user's XMPP server is then responsible to share this presence information to each entry in the roster and in particular to each MIX channel in the roster.

- - -

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 presence node. If there is not an item named by the full JID of the client with updated presence status, this item is created. The sequence is shown in the following examples, starting with a client setting presences status on the connected server.

- - + dnd Making a Brew ]]> @@ -435,26 +403,25 @@ This approach enables flexible support of multiple clients for a MIX channel pa

The server then sends the presence information to roster entries. The following example then shows the presence message from the client's server to the MIX channel. The presence is then handled as specified in &xep0369;.

- - + dnd Making a Brew ]]> -

A MIX channel will send out presence information to participants that subscribe to the presence node, as specified in &xep0403;. An example is shown below:

- - hecate@shakespeare.example/UUID-x4r/2491 - thirdwitch + thirdwitch dnd Making a Brew @@ -462,13 +429,13 @@ This approach enables flexible support of multiple clients for a MIX channel pa

The user's server will then pass this on to all online clients, with 'from' unchanged and 'to' set to the client receiving presence. An example is shown below:

- - hecate@shakespeare.example/UUID-x4r/2491 - thirdwitch + thirdwitch dnd Making a Brew @@ -478,31 +445,20 @@ This approach enables flexible support of multiple clients for a MIX channel pa The user's local server will receive a flow of all presence updates for the user. It will pass this presence information on to all online clients. This ensures that an online client is kept updated with presence. When a client goes offline, it will cease getting presence updates. Presence updates will continue to flow to the user's local server, and so the local server is able maintain up to date presence state for the channel, even when there are no online clients. When a user had no online clients the user's server MAY continue to maintain MIX presence status for the user or MAY discard inbound MIX presence information.

- - - - -

When the client comes online, it will activate use of the MIX. When the user's server has been maintaining MIX presence, it will then send full presence status to the client using standard presence messages. This will enable the client to update presence information for the subscribed MIX channels. Note that this does not need any interaction with MIX servers.

- -

- - There are two situations where a MIX participant's server will need to get presence status from the channel, before it can send presence to the client. The first time is when a user joins the channel as a participant and subscribes to presence. Upon this subscription the MIX channel will send to the participant's server (using the user's bare JID) presence for all of the items in the presence node using standard presence stanzas. This will give the participant's full current presence for the channel.

The second scenario is when the MIX participant's server needs to load or refresh presence status for a channel. This will be needed when the participant's server is started or when the server chooses to not maintain presence for a user when all clients go offline. This MIX participant's server requests presence update by sending a directed presence stanza to the MIX channel from the user's bare JID. The MIX channel can distinguish this from a presence update, which will always be sent from the clients full JID. This will cause the MIX channel to send a full presence update for the channel.

- -

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. Going online and offline will simply be presence updates.

@@ -511,8 +467,6 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='hag66@shakespeare.example/UUID-a1j/7533' to='coven@mix.shakespeare.example'/> ]]> - -

It is desirable to prevent clients from going offline briefly and then coming back online again, as this will lead to "flapping presence". The RECOMMENDED approach to achieve this is use of &xep0198; to maintain an XMPP client connection in the event of short term TCP failure.

@@ -520,20 +474,16 @@ This approach enables flexible support of multiple clients for a MIX channel pa - - - -

It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A MIX client MAY request that the server return this additional information that annotates roster elements with MIX capability. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a child element <annotate/> to the <query/> element. The <annotate/> element is qualified by the ‘urn:xmpp:mix:roster:0' namespace.

- - - - + id='bv1bs71f' + type='get'> + + + + ]]>

A standard roster item is encoded as follows.

@@ -546,9 +496,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa

- - + + + ]]>

@@ -569,8 +519,6 @@ This approach enables flexible support of multiple clients for a MIX channel pa - -

See considerations in &xep0369;.