moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 15:18:51 -05:00
Code Issues Releases Wiki Activity

Replace client activation with client capability discovery

Browse Source
This commit is contained in:
Steve Kille 2017-02-08 11:08:00 +00:00 committed by Sam Whited
parent dfdbca1f81
commit 528e4d269c
1 changed files with 5 additions and 53 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
xep-0369.xml
View File

@ -42,7 +42,7 @@
<initials>sek</initials>
<remark><p>
Update after Brussels Summit;
Remove Explicit Client Activation;
Remove Explicit Client Activation and replace with client capability discovery;
Limit Indirect to Join/Leave;
Clarify Server use of Disco of Client;
</p></remark>
@ -796,7 +796,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</section2>
<section2 topic="Discovering Client MIX Capability" anchor="mix-client-discovery">
<p>
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. The following example shows a Disco response from a client that supports both MIX and MUC.
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 response from a client that supports both MIX and MUC.
</p>
<example caption='Disco Response showing MIX support'><![CDATA[
<iq from='romeo@montague.lit/orchard'
@ -2163,64 +2163,16 @@ the participant is not be subscribed to all nodes associated with the channel (i
&xep0376; (PAM) which follows a similar model.
</p>
<section2 topic="MIX Client Activation" anchor="proxy-activation">
<section2 topic="Server Identification of MIX Capabable Clients" anchor="server-identification-mix-clients">
<p>
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 &lt;activate&gt; 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 &lt;channel&gt; 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.
</p>
<p>
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.
</p>
<example caption="Client Activates use of MIX" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
id='lx09df27'
type='set'>
<activate xmlns='urn:xmpp:mix:0'>
<channel>coven@mix.shakespeare.lit</channel>
<channel>spells@mix.shakespeare.lit</channel>
</activate>
</iq>
<iq from='shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/intibo24'
type='result'>
<activate xmlns='urn:xmpp:mix:0'/>
</iq>
]]></example>
<p>
Following MIX activation, the participant's server will send presence status for all activated channels to the client using standard presence protocol. This will give the client current presence status for the channel.
</p>
<p>
A client will deactivate MIX using a corresponding deactivate command. This will deactivate all MIX channels. This will often be done when the client closes down, but MAY also be done at other times the client chooses. Deactivation uses an IQ set with an &lt;deactivate&gt; element to instruct the local server to deactivate the client.
</p>
<example caption="Client Deactivates use of MIX" ><![CDATA[
<iq from='hag66@shakespeare.example/intibo24'
id='lx09df27'
type='set'>
<deactivate xmlns='urn:xmpp:mix:0'/>
</iq>
<iq from='shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example/intibo24'
type='result'>
<deactivate xmlns='urn:xmpp:mix:0'/>
</iq>
]]></example>
<p>
If a client goes offline, the server MUST deactivate MIX immediately for that client. This will mean that standard client behaviour will be to activate MIX when they come online.
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. A MIX capable client MAY choose to come online an not advertize MIX capability.
</p>
</section2>
<section2 topic="Messages From MIX Channels" anchor="mix-from">
<p>
Messages from a MIX channel will usually go to the participant's server. The only exception to this is where the MIX channel is responding directly to messages from the client. Messages and presence distributed but a MIX channel will always be sent to the participant's server. The participant's server will simply send on the messages from the channel to each of the user's clients which have activated the channel. If there are no clients activated, the message is dropped.
Messages from a MIX channel will usually go to the participant's server. The only exception to this is where the MIX channel is responding directly to messages from the client. Messages and presence distributed but a MIX channel will always be sent to the participant's server and addressed to the user's bare JID. The participant's server will simply send on the messages from the channel to each of the user's online clients which advertise MIX capability. If there are no such clients activated, the message is dropped. The mechanism for a server to discover client capability is described in <link url="#mix-client-discovery">Discovering Client MIX Capability</link>.
</p>
<p>
Messages sent to the participant's sever will always be addressed to the user's bare JID. The participant’s server will modify the recipient to the full JID of each client to which the message is forwarded. The participant's server MUST NOT make any other modifications to each message. The following example, repeated from earlier, shows a message distributed by a MIX channel and directed to the participant’s server with the participant's bare JID.