moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

MIX Proxy Specification

This commit is contained in:
Steve Kille 2016-11-30 18:36:54 +00:00
parent f99b5cdf79
commit 7992c4cb5b
1 changed files with 87 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

94
xep-0369.xml
View File

@ -195,7 +195,7 @@
This means that a MIX client needs to resynchronize with the MIX service when it comes online. This synchronization will happen directly between the MIX client and MIX channel.</li>
<li>The MIX Proxy will know which channels are subscribed to, and so can send this list to a MIX client. Because channel subscriptions are long term, this information will be used instead of the bookmark approach used with MUC.</li>
<li>The MIX Proxy will manage channel registration and de-registration in the user's roster.</li>
<li>Different clients may wish to access different channels (e.g., a mobile client may only access a subset of the channels in which a user is interested). The MIX Proxy MAY handle sending messages only to the clients that wish for them, perhaps using a profile mechanism.</li>
<li>Different clients may wish to access different channels (e.g., a mobile client may only access a subset of the channels in which a user is interested). The MIX Proxy enables a client to select only a subset of channels.</li>
</ol>
<p>
Messages being sent from MIX channel to MIX Proxy (which will be of type=groupchat) and presence information are sent to the bare JID. This means that the MIX Proxy will use a modification of the standard &rfc6121; rules.
@ -205,13 +205,9 @@
</p>
<p>
The behaviour of a MIX Proxy and the protocol between MIX Proxy and MIX Client is not currently defined in this specification. It will be defined in one of three places.
It may be desirable in some situations to provide different service to different clients. For example, a mobile client may participate in a smaller set of MIX channels than a desktop client. This needs support from the server to which the client connects, so that MIX client and the connected server can negotiate which channels to send. This is not supported by the core MIX specification, but it is anticipated that this will be specified in one of the following ways:
It may be desirable in some situations to provide different service to different clients. For example, a mobile client may participate in a smaller set of MIX channels than a desktop client. This needs support from the server to which the client connects, so that MIX client and the connected server can negotiate which channels to send. MIX Proxy behaviour is specified in this MIX specification.
</p>
<ol>
<li> In an extension to &xep0376; (PAM) which follows a model close to MIX Proxy; or</li>
<li>In a new XEP specifically to defined MIX Proxy behavior; or</li>
<li>As a new section in a future version of the MIX Specification.</li>
</ol>
</section2>
<section2 topic="User Presence in MIX" anchor="concepts-presence">
<p>
@ -1912,6 +1908,90 @@ A client creates a channel by sending a simple request to the MIX service. A c
</section1>
<section1 topic="MIX Proxy" anchor="mix-proxy">
<p>
This section defines behaviour of the MIX Proxy Service, so that the full MIX specification for clients and servers is set out in a single document. MIX Proxy support MUST be provided by servers used by clients that participate in MIX channels. In future, MIX Proxy specification may be moved to a separate XEP or it may be incorporated into
&xep0376; (PAM) which follows a model close to MIX Proxy.
</p>
<section2 topic="MIX Client Activation" anchor="proxy-activation">
<p>
All messages from MIX channels to users are sent to the user's MIX Proxy, which resides on the user's XMPP server. The MIX Proxy 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 MIX proxy 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>
<example caption="Client Activates use of MIX Proxy" ><![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>
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 MIX proxy to activate the client.
</p>
<example caption="Client Deactivates use of MIX Proxy" ><![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's MIX Proxy MUST deactivate MIX immediately. This will mean that standard client behaviour will be to activate MIX when they come online.
</p>
</section2>
<section2 topic="Messages From MIX Channels" anchor="proxy-from">
<p>
Messages from a MIX channel will usually go to the MIX proxy. 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 MIX Proxy. The MIX Proxy will simply send on the messages from the channel to each of the user's clients which have activated the channel with the MIX Proxy. If there are no clients activated, the message is dropped.
</p>
<p>
Messages sent to the MIX Proxy will always be addressed to the user's bare JID. The MIX proxy will modify the recipient to the full JID of each client to which the message is forwarded. The MIX Proxy MUST NOT make any other modifications to each message.
</p>
</section2>
<section2 topic="Messages To MIX Channels" anchor="proxy-to"></section2>
<p>
The MIX specification requires that some messages are sent through the MIX Proxy and allows other messages to be sent through the MIX Proxy. This enables the MIX Proxy to use information from the client to improve the MIX Proxy function. The messages sent by the client to the MIX proxy will come from the client's full JID. The MIX proxy will modify the messages to come from the bare JID. This modification is transparent to the MIX client. The client will always send messages from the full JID and the MIX Proxy will modify the message to ensure MIX compliance.
</p>
<section2 topic="Roster Management" anchor="proxy-roster">
<p>
The MIX Proxy is responsible for ensuring that MIX channels are correctly entered into the user's roster. This is provided as a generic client independent service for the user.
</p>
<p>
The MIX Proxy SHOULD ensure that only presence information from activated MIX clients is sent to the MIX channel. So, if a user has two online clients, but only one is activated for a given MIX channel, then the channel SHOULD only receive presence information relating to the activated client.
</p>
</section2>
<section2 topic="MAM Archive Support" anchor="proxy-mam">
<p>
MAM Archive is not a part of the MIX Proxy. However, it is important to note that archive of channel information is done by the user's server. Where a message is sent to the MIX Proxy and discarded because there are no active clients, it will still be archived. This means that the messages will be available in the local archive and can be picked up by clients when they come online.
</p>
</section2>
</section1>
<section1 topic="Supporting MIX and MUC together" anchor="mix-and-muc-together">
<p>
MIX is specified as a service that can be used independent of MUC and a MIX service may be implemented without MUC. If both MIX and MUC are implemented, three approaches are noted.