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

Add in description of MIX Proxy

This commit is contained in:
Steve Kille 2016-09-06 15:43:18 +01:00
parent b93e17bd2e
commit afad578d91
1 changed files with 53 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
xep-0369.xml
View File

@ -154,24 +154,49 @@
<section2 topic="MIX and MAM" anchor="concepts-mam">
<p> Historical data (such as the messages sent to the channel) is stored in an archive supporting Message Archive Management (MAM) so that clients can subsequently access this data with MAM. Each node can be archived separately (e.g., the presence node or the configuration node). MIX clients can retrieve archived information with MAM in order to quickly resync messages with regard to a channel, and can do so without providing presence information.</p>
</section2>
<section2 topic="Delivering Messages to Users" anchor="concepts-delivery">
<p>
The primary model is that a user will join a channel over an extended period, and that the user (not a specific client used by the user) joins the channel. The primary subscription is with the client's bare JID. The user will receive messages from the channel and/or access channel presence from time to time with one or more clients.
<section2 topic="MIX Proxy" anchor="concepts-mix-proxy">
<p>
A MIX channel does not send messages and presence directly to an XMPP MIX client. Instead it sends them to a MIX Proxy, which runs on the server which a MIX client accesses. MIX clients MUST make use of a MIX Proxy. Use of a MIX proxy enables flexible support of multiple clients for an XMPP user.
The primary model is that a user will join a channel over an extended period, and that the user (not a specific client used by the user) joins the channel. The primary subscription is with the client's bare JID. The MIX channel will send messages and presences to the MIX Proxy using the bare JID. The MIX Proxy will then send the messages and presence information to zero or more clients.
The MIX Proxy provides a number of functions.
</p>
<ol>
<li>Each MIX client will register with the MIX proxy. A key benefit of this approach is that MIX messages will only be sent to clients that support MIX. This enables use of clients that do not use MIX in conjunction with the MIX proxy.</li>
<li>MIX Service and Channel subscription and management is handled by the MIX proxy. This means that all messages to MIX from the user use bare JID. Because the MIX Proxy is aware of subscription information, it can provide integrated support to a set of MIX clients.</li>
<li>The MIX Proxy will only send messages to online clients and will discard messages if no clients are online.
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 provide a bookmark service to the MIX clients.</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 will handle sending messages only to the clients that wish for them.</li>
</ol>
<p>
Where a user has no clients active, the approach is that all messages will be archived by the MIX channel (on arrival at the MIX channel) so that when clients come online they will use MAM to communicate to the MIX channel to access messages that have not been delivered to the client. Following the rules of &rfc6121;, arriving MIX messages (which will be of type=groupchat) and presence information will be discarded if all clients are offline. Offline messages are not used with MIX. This means that a MIX client needs to resynchronize with the MIX service when it comes online.
Arriving MIX messages (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.
</p>
<p>
MIX delivery does not require any special support from the XMPP server to which the MIX client connects. When using a basic XMPP server for this service, all online clients for a user will receive the same set of messages and presence information, as MIX sends this information to the bare JID.
The MIX standard specifies how the MIX channel interacts directly with XMPP clients and with the MIX Proxy.
</p>
</section2>
<section2 topic="Advanced Delivery to Online Users" anchor="concepts-online-delivery">
<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 supported by another specification.
This may be &xep0376; (PAM) or a new specification similar to PAM developed specifically in support of MIX.
</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>
<p>QUESTION: Input is sought on the best place to standardize MIX Proxy.</p>
</section2>
<section2 topic="User Presence in MIX" anchor="concepts-presence">
<p>
@ -425,18 +450,18 @@
<section2 topic='Discovering Channel Information' anchor='disco-channel-info'>
<p>In order to find out more information about a given channel, a user can send a disco#info query to the channel.</p>
<example caption='Entity Queries for Information about a Specific Channel'><![CDATA[
<iq from='hag66@shakespeare.lit/pda'
<iq from='hag66@shakespeare.lit'
id='ik3vs715'
to='coven@mix.shakespeare.lit'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<p>The channel MUST return its identity and the features it supports. Note that a MIX channel MUST support MAM and so the response will always include both MIX and MAM support.</p>
<p>Note that this query comes from the bare JID to the MIX channel, as it will always be sent to the MIX service by a MIX proxy. The channel MUST return its identity and the features it supports. Note that a MIX channel MUST support MAM and so the response will always include both MIX and MAM support.</p>
<example caption='Channel Returns Disco Info Result'><![CDATA[
<iq from='coven@mix.shakespeare.lit'
id='ik3vs715'
to='hag66@shakespeare.lit/pda'
to='hag66@shakespeare.lit'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity
@ -452,7 +477,7 @@
<section2 topic='Discovering Nodes at a Channel' anchor='disco-channel-nodes'>
<p>Use disco#items to find the nodes associated with a channel. The MIX server MUST only return nodes that exist and that the user making the query has rights to subscribe to.</p>
<example caption='Entity Queries for Nodes at a Channel'><![CDATA[
<iq from='hag66@shakespeare.lit/pda'
<iq from='hag66@shakespeare.lit'
id='kl2fax27'
to='coven@mix.shakespeare.lit'
type='get'>
@ -462,7 +487,7 @@
<example caption='Room Returns Disco Items Result'><![CDATA[
<iq from='coven@mix.shakespeare.lit'
id='kl2fax27'
to='hag66@shakespeare.lit/pda'
to='hag66@shakespeare.lit'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#items'>
<item jid='coven@mix.shakespeare.example'
@ -496,7 +521,7 @@
<p>The default MIX model is that only channel participants may subscribe to nodes. A MIX channel MAY allow non-participant subscription. This will be handled by clients directly subscribing to the desired PubSub nodes.</p>
<example caption="User Joins a Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/pda'
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:0'>
@ -512,7 +537,7 @@
<example caption="Channel Successfully Processes Join"><![CDATA[
<iq type='result'
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example/pda'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:0' jid='hag66@shakespeare.example'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
@ -526,7 +551,7 @@
<p>As noted, the participant might not be subscribed to all nodes associated with the channel (in this case only messages, participants, and subject).</p>
<example caption="Channel Processes Join With Modifications"><![CDATA[
<iq type='result'
from='hag66@shakespeare.example/pda'
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:0' jid='hag66@shakespeare.example'>
@ -584,7 +609,7 @@
<p>Users generally remain in a channel for an extended period of time. In particular membership of the channel does not change when the user goes offline as happens with &xep0045;. So, leaving the channel is a permanent action for a user across all clients, not just a matter of telling the channel that the user is not currently available or for a single client. In order to leave a channel, a user sends a MIX "leave" command to the channel. When a user leaves the channel, the user's client will remove the channel from the user's roster.</p>
<example caption="User Leaves a Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/pda'
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<leave xmlns='urn:xmpp:mix:0'/>
@ -631,7 +656,7 @@
</p>
<example caption="User sets Nick on Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/pda'
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='7nve413p'>
<query xmlns='urn:xmpp:mix:0'>
@ -646,7 +671,7 @@
<example caption="Channel informs user of Nick"><![CDATA[
<iq type='result'
from='hag66@shakespeare.example/pda'
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='7nve413p'>
<query xmlns='urn:xmpp:mix:0'>
@ -663,7 +688,7 @@
</p>
<example caption="User Determines features of the MIX service"><![CDATA[
<iq type='get'
from='hag66@shakespeare.example/pda'
from='hag66@shakespeare.example'
to='mix.shakespeare.example'
id='7nve413p'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
@ -677,7 +702,7 @@
a &lt;register/&gt; command to the service. </p>
<example caption="User Registers with Service"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/pda'
from='hag66@shakespeare.example'
to='mix.shakespeare.example'
id='7nve413p'>
<register xmlns='urn:xmpp:mix:0'>
@ -693,7 +718,7 @@
<example caption="Service Returns User of Nick"><![CDATA[
<iq type='result'
to='mix.shakespeare.example'
from='hag66@shakespeare.example/pda'
from='hag66@shakespeare.example'
id='7nve413p'>
<register xmlns='urn:xmpp:mix:0'>
<nick>thirdwitch</nick>
@ -704,7 +729,7 @@
<example caption="Nick is Taken">
<![CDATA[<iq type='error'
to='mix.shakespeare.example'
from='hag66@shakespeare.example/pda'
from='hag66@shakespeare.example'
id='7nve413p'>
<error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@ -739,7 +764,8 @@
<show>dnd</show>
<status>Making a Brew</status>
</presence>]]></example>
<p>The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node, with the 'publisher' attribute set to the user's participant identifier (the proxy JID. The MIX channel then broadcasts the presence change to all users who are subscribed to the "urn:xmpp:mix:nodes:presence" node. The presence stanza is sent from the proxy (anonymized) full JID of the user. </p>
<p>The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node, with the 'publisher' attribute set to the user's participant identifier (the proxy JID. The MIX channel then broadcasts the presence change to all users who are subscribed to the "urn:xmpp:mix:nodes:presence" node. The presence stanza is sent from the proxy (anonymized) full JID of the user.
Note that presence is associated with a client and so will have a full JID as it comes directly from the client and not through the MIX Proxy.</p>
<example caption="Channel Distributes Presence">
<![CDATA[<presence from='coven+123435@mix.shakespeare.example/678'
to='coven@mix.shakespeare.example'
@ -816,7 +842,7 @@
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>
]]></example>
<p>The message comes from the channel as a standard groupchat message, compatible with MUC.</p>
<p>The message comes from the channel as a standard groupchat message, compatible with MUC. Messages are sent directly and do not use the MIX Proxy.</p>
<p>AUTHOR NOTE AND QUESTION: Message id coming back is different in example. This is because the reflected message uses MAM ID, which seems helpful. However, it makes it harder for sender to correlate reflections. Need to be explicit as to compliant behaviour. Input as to whether the ID should change is solicited. A more complex option would be to include both IDs in some way.</p>
<example caption="Channel Reflects Message to Participants"><![CDATA[
<message from='coven+12345@mix.shakespeare.example/678'