mirror of https://github.com/moparisthebest/xeps
Remove MIX Proxy terminology
This commit is contained in:
Steve Kille
Sam Whited
parent
fa5fac8fc1
commit
30cd35b610
138
xep-0369.xml
138
xep-0369.xml
|
|
@ -241,7 +241,7 @@
|
|||
<li>MIX decouples addressing of channel participants from their nicknames, so that nickname changes do not affect addressing.</li>
|
||||
<li>Each participant is addressable by a single bare JID, which is a proxy JID (not the user's real JID) to make it straightforward to hide the user's real JID from other channel participants. Full JIDs comprised of this bare JID plus a resource (also anonymized) are then constructed, allowing visibility into the number of online resources participating in a channel.</li>
|
||||
<li>MIX requires client support and server support from the server providing the MIX service. Although some protocol is shared with MUC, MUC clients are not interoperable with a MIX service. This means that where a user chooses to use MIX, all of the users clients need to support MIX.</li>
|
||||
<li>MIX requires the server to which the MIX client connects to provide functionality to support MIX. This functionality is termed "MIX Proxy" and is defined in this specification.</li>
|
||||
<li>MIX requires the server to which the MIX client connects to provide functionality to support MIX. This functionality is defined in this specification and referenced as "MIX Participant's Server Behaviour".</li>
|
||||
</ol>
|
||||
</section2>
|
||||
<section2 topic="MIX and PubSub" anchor="concepts-pubsub">
|
||||
|
|
@ -252,28 +252,29 @@
|
|||
<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="MIX Proxy" anchor="concepts-mix-proxy">
|
||||
<section2 topic="Behaviour of MIX Participant's Server" anchor="concepts-mix-participant-server">
|
||||
<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.
|
||||
A MIX channel does not send messages and presence directly to an XMPP MIX client of a channel participant, but addresses them to participant using the participant's bare JID. The participant's server must then handle these messages and pass them on to zero, one or multiple clients. To enable MIX to work, this behaviour is necessary and so the server of every MIX client must follow the rules set out in this specification.
|
||||
This approach enables flexible support of multiple clients for a MIX channel participant.
|
||||
The MIX 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.
|
||||
There are a number of MIX requirements on behaviour of the MIX Participant's server, which are summarized here:
|
||||
</p>
|
||||
<ol>
|
||||
<li>Each MIX client will register with the MIX Proxy when it comes online. 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 through the MIX proxy so that the MIX Proxy can track all subscription changes and share subscription information between MIX clients. To achieve this, a MIX client sends these MIX management queries to the MIX Proxy using the clients full JID in the from and receives responses back from the MIX Proxy. The MIX Proxy will communicate these requests to a MIX channel from the MIX using the user's bare JID. Because the MIX Proxy is aware of subscription information, it can provide integrated support to a set of MIX clients.</li>
|
||||
<li>Messages from a MIX client to a MIX channel will go direct to the MIX service and not through the MIX Proxy.</li>
|
||||
<li>Messages from a MIX channel to a MIX client MUST be handled by a MIX Proxy.</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 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 enables a client to select only a subset of channels.</li>
|
||||
<li>Each MIX client will activate MIX capability with the local server when it comes online. A key benefit of this approach is that MIX messages will only be sent to clients that support MIX. This enables a user to use of clients that do not use MIX in conjunction with clients that use MIX.</li>
|
||||
<li>MIX Service and Channel subscription and management is handled through the participant's server so that the participant's server can track all subscription changes and share subscription information between MIX clients. To achieve this, a MIX client of a MIX channel participant sends these MIX management queries to the participant's server and received responses back from the participant’s server. The MIX participant’s server will communicate these requests to a MIX channel with messages from the user's bare JID. Because the participant's server is aware of subscription information, it can provide integrated support to a set of MIX clients.</li>
|
||||
<li>Messages from a MIX client to a MIX channel will go direct to the MIX service. They are relayed, but not modified, by the participant's server.</li>
|
||||
<li>Messages from a MIX channel to a MIX client are always sent to the MIX participants server (addressed by bare JID) and MUST be handled by the MIX participant's server.</li>
|
||||
<li>All messages received by the MIX participant's server MUST be stored using MAM.</li>
|
||||
<li>The MIX participant's server 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 message synchronization will happen between the MIX client and the MAM archive held on the MIX participant's server.</li>
|
||||
<li>The MIX participant's server handles 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). MIX Client Activation allows the participant's server to support this.</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.
|
||||
Messages being sent from MIX channel to a MIX participant’s server (which will be of type=groupchat) and presence information are sent to the bare JID. This means that the MIX participant's server MUST support a modification of the standard &rfc6121; rules.
|
||||
</p>
|
||||
<p>
|
||||
The MIX standard specifies how the MIX channel interacts directly with XMPP clients and with the MIX Proxy. MIX Proxy behaviour is also specified in this MIX specification.
|
||||
The core MIX specification sets out how the MIX channel interacts directly with XMPP clients and with the MIX participant's server. Behaviour of the MIX participant's server is also specified in this MIX specification.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic="User Presence in MIX" anchor="concepts-presence">
|
||||
|
|
@ -409,7 +410,7 @@
|
|||
</p>
|
||||
|
||||
<p>
|
||||
This node may be subscribed to by users and this subscription MUST use the users bare JID. So presence of online clients is sent to the MIX Proxy for each user subscribed to this node. Presence is always sent using standard presence protocol and NOT using pubsub protocol. Clients MUST NOT directly access the presence node using pubsub.
|
||||
This node may be subscribed to by users and this subscription MUST use the users bare JID. So presence of online clients is sent to the user's server for each user subscribed to this node. Presence is always sent using standard presence protocol and NOT using pubsub protocol. Clients MUST NOT directly access the presence node using pubsub.
|
||||
</p>
|
||||
<example caption="Value of Presence Node"><![CDATA[
|
||||
<items node='urn:xmpp:mix:nodes:presence'>
|
||||
|
|
@ -471,7 +472,7 @@
|
|||
</item>
|
||||
</items>]]></example>
|
||||
<p>
|
||||
When a user subscribes to the Subject Node, this will cause the channel to send Subject messages to the user through the MIX Proxy. This is done on initial user subscription and on subject change. Clients MAY directly read the channel subject from the Subject Node using PubSub.
|
||||
When a user subscribes to the Subject Node, this will cause the channel to send Subject messages to the user's server using the user's bare JID. This is done on initial user subscription and on subject change. Clients MAY directly read the channel subject from the Subject Node using PubSub.
|
||||
</p>
|
||||
</section3>
|
||||
<section3 topic="Allowed" anchor="allowed-node">
|
||||
|
|
@ -624,8 +625,8 @@
|
|||
<p>A MIX service MUST NOT advertise support for &xep0313;, as MAM is supported by the channels and not by the service. A MIX service MUST NOT advertise support for generic &xep0060;, as although MIX makes use of PubSub it is not a generic PubSub service.</p>
|
||||
</section2>
|
||||
<section2 topic='Discovering the Channels on a Service' anchor='disco-channel-list'>
|
||||
<p>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. This query MAY be made directly by and XMPP client or by a MIX Proxy.</p>
|
||||
<example caption='MIX Proxy Queries for Channels on MIX Service'><![CDATA[
|
||||
<p>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. This query MAY be made directly by and XMPP client or indirectly by the user's server.</p>
|
||||
<example caption='User's Server Queries for Channels on MIX Service'><![CDATA[
|
||||
<iq from='hag66@shakespeare.lit'
|
||||
id='kl2fax27'
|
||||
to='mix.shakespeare.lit'
|
||||
|
|
@ -647,7 +648,7 @@
|
|||
]]></example>
|
||||
</section2>
|
||||
<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. This query MUST be made by a MIX Proxy and not the end client.</p>
|
||||
<p>In order to find out more information about a given channel, a user can send a disco#info query to the channel. This query MUST be made by the user's server and not the end client.</p>
|
||||
<example caption='Entity Queries for Information about a Specific Channel'><![CDATA[
|
||||
<iq from='hag66@shakespeare.lit'
|
||||
id='ik3vs715'
|
||||
|
|
@ -656,7 +657,7 @@
|
|||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<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. All disco queries on a MIX channel rad results returned MUST include node='mix'. The reason for this is to facilitate MIX channels and &xep0045; MUC rooms sharing the same JID. This extra parameter will enable a server to return appropriate information.</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 the user's server. 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. All disco queries on a MIX channel rad results returned MUST include node='mix'. The reason for this is to facilitate MIX channels and &xep0045; MUC rooms sharing the same JID. This extra parameter will enable a server to return appropriate information.</p>
|
||||
<example caption='Channel Returns Disco Info Result'><![CDATA[
|
||||
<iq from='coven@mix.shakespeare.lit'
|
||||
id='ik3vs715'
|
||||
|
|
@ -674,7 +675,7 @@
|
|||
]]></example>
|
||||
</section2>
|
||||
<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 service MUST only return nodes that exist and that the user making the query has rights to subscribe to. This query MUST be made by a MIX Proxy and not the end client.</p>
|
||||
<p>Use disco#items to find the nodes associated with a channel. The MIX service MUST only return nodes that exist and that the user making the query has rights to subscribe to. This query MUST be made by the user's server and not the end client.</p>
|
||||
<example caption='Entity Queries for Nodes at a Channel'><![CDATA[
|
||||
<iq from='hag66@shakespeare.lit'
|
||||
id='kl2fax27'
|
||||
|
|
@ -704,8 +705,8 @@
|
|||
]]></example>
|
||||
</section2>
|
||||
<section2 topic="Determining Information about a Channel" anchor="find-channel-info">
|
||||
<p>The Information Node contains various information about the channel that may be useful to the user. This can be read by the XMPP Client directly or by a MIX Proxy.</p>
|
||||
<example caption='MIX Proxy Requests Channel Information'><![CDATA[
|
||||
<p>The Information Node contains various information about the channel that may be useful to the user. This can be read by the XMPP Client directly or by the user's server.</p>
|
||||
<example caption='User's Server Requests Channel Information'><![CDATA[
|
||||
<iq from='hag66@shakespeare.lit'
|
||||
id='kl2fax27'
|
||||
to='coven@mix.shakespeare.lit'
|
||||
|
|
@ -740,7 +741,7 @@
|
|||
<section2 topic='Determining the Participants in a Channel' anchor='find-channel-participants'>
|
||||
<p>
|
||||
Online clients in the channel are determined from the presence node. Participants in the channel are determined from the Participants Node which will give proxy JID and nick. The jidmap node is used to map to real JIDs. An operation is provided to list channel participants. For JID Hidden channels, only the nicks are returned. For JID Visible channels, nicks and real JIDs are returned.</p>
|
||||
<example caption='MIX Proxy Requests Participant List'><![CDATA[
|
||||
<example caption='User's Server Requests Participant List'><![CDATA[
|
||||
<iq from='hag66@shakespeare.lit'
|
||||
id='kl2fax27'
|
||||
to='coven@mix.shakespeare.lit'
|
||||
|
|
@ -876,7 +877,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
</section3>
|
||||
<section3 topic="Roster Management" anchor="usecase-roster-management">
|
||||
<p>
|
||||
After the user has jointed the channel, the user's MIX Proxy MAY add the MIX channel to the user's roster using standard XMPP to update the roster. This is done to share the user's presence status with the channel and so the MIX channel will get presence information from the user. This roster entry will lead to the user's server correctly sending user's presence from all clients to the MIX channel. The roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information is sent about the MIX channel. The user's MIX Proxy MUST remove this roster entry after the user leaves the channel.
|
||||
After the user has jointed the channel, the user's server MAY add the MIX channel to the user's roster using standard XMPP to update the roster. This is done to share the user's presence status with the channel and so the MIX channel will get presence information from the user. This roster entry will lead to the user's server correctly sending user's presence from all clients to the MIX channel. The roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information is sent about the MIX channel. The user's server MUST remove this roster entry after the user leaves the channel.
|
||||
</p>
|
||||
<p>
|
||||
If the user does not wish to publish presence information to the channel, the user will not add the roster entry. A channel may require presence to be provided by all channel participants, which is controlled by the 'Participants Must Provide Presence' option. The channel MAY check that channel participants have done this and MAY remove participants that do not do this.
|
||||
|
|
@ -1205,7 +1206,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
<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.
|
||||
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>
|
||||
Note that presence is associated with a client and so will have a full JID as it comes directly from the client and not from the user's server.</p>
|
||||
<example caption="Channel Distributes Presence">
|
||||
<![CDATA[<presence from='coven+123435@mix.shakespeare.example/678'
|
||||
to='coven@mix.shakespeare.example'
|
||||
|
|
@ -1219,26 +1220,26 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
</p>
|
||||
</section3>
|
||||
|
||||
<section3 topic="Client Coming Online and Obtaining Presence from MIX Proxy" anchor="usecase-obtaining-presence">
|
||||
<section3 topic="Client Coming Online and Obtaining Presence from the Local Server" anchor="usecase-obtaining-presence">
|
||||
<p>
|
||||
The presence information for a channel is stored in the urn:xmpp:mix:nodes:presence node and distributed using standard presence stanzas to the MIX Proxy of users subscribing to this presence node. The user's MIX Proxy will then 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 MIX Proxy, and so the MIX Proxy will maintain up to date presence state for the channel.
|
||||
The presence information for a channel is stored in the urn:xmpp:mix:nodes:presence node and distributed using standard presence stanzas to the server of each user subscribing to this presence node. The user's local server will then 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.
|
||||
</p>
|
||||
<p>
|
||||
When the client comes online, it will activate use of the MIX Proxy. The MIX Proxy will then send full presence status to the client using standard presence messages. This will enable the client to update presence information for the channel. Note that this does not need any interaction with the channel.
|
||||
When the client comes online, it will activate use of the MIX. The user's server will then send full presence status to the client using standard presence messages. This will enable the client to update presence information for the channel. Note that this does not need any interaction with the channel.
|
||||
</p>
|
||||
|
||||
</section3>
|
||||
|
||||
<section3 topic="MIX Proxy Presence Update" anchor="usecase-proxy-presence-update">
|
||||
<section3 topic="Updating Presence on User's Server" anchor="usecase-server-presence-update">
|
||||
<p>
|
||||
In normal operation the MIX Proxy will hold accurate presence status for the channel which it provides to clients when they are activated. Incoming presence updates are immediately sent to active MIX clients.
|
||||
In normal operation a MIX participant's server will hold accurate presence status for the channel which it provides to clients when they are activated. Incoming presence updates are immediately sent to active MIX clients.
|
||||
</p>
|
||||
<p>
|
||||
There are two situations where the MIX Proxy will need to get presence status from the channel. 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 MIX Proxy (the user's bare JID) presence for all of the items in the presence node using standard presence stanzas. This will give the MIX Proxy full current presence for the channel.
|
||||
There are two situations where a MIX participant's server will need to get presence status from the channel. 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.
|
||||
</p>
|
||||
<p>
|
||||
The second scenario is when the MIX Proxy needs to load or refresh presence status for a channel. This will be needed when the MIX Proxy and associated server are started. This MIX Proxy 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 special presence stanza will send to the MIX Proxy (the user's bare JID) presence for all of the items in the presence node using standard presence stanzas.
|
||||
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. 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 special presence stanza 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.
|
||||
</p>
|
||||
</section3>
|
||||
<section3 topic="Determining Real JIDs" anchor="usecase-real-jids">
|
||||
|
|
@ -1286,7 +1287,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
|
||||
|
||||
<section3 topic='Sending a Message' anchor='usecase-user-message'>
|
||||
<p>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 channel and do not use the MIX Proxy. The message id is selected by the client.</p>
|
||||
<p>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.</p>
|
||||
<example caption="User Sends Message to Channel"><![CDATA[
|
||||
<message from='hag66@shakespeare.example/pda'
|
||||
to='coven@mix.shakespeare.example'
|
||||
|
|
@ -1296,7 +1297,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
</message>
|
||||
]]></example>
|
||||
<p>The MIX channel then puts a copy of the message into the MAM archive for the channel and sends a copy of the message to each participant in
|
||||
standard groupchat format. These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's MIX Proxy. The message from value is the JID of the channel. To enable sender identification, the Nick and bare proxy JID of the sender are included in the message as MIX parameters. The id of the message is the ID from the MAM archive and NOT the id used by the sender.</p>
|
||||
standard groupchat format. These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's local server. The message from value is the JID of the channel. To enable sender identification, the Nick and bare proxy JID of the sender are included in the message as MIX parameters. The id of the message is the ID from the MAM archive and NOT the id used by the sender.</p>
|
||||
|
||||
<example caption="Channel Reflects Message to Participants"><![CDATA[
|
||||
<message from='coven@mix.shakespeare.example'
|
||||
|
|
@ -1375,7 +1376,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
</message>
|
||||
]]></example>
|
||||
<p>
|
||||
This message is received by the MIX channel, which will set the Subject Node for the channel, and then distribute the message to participants that are subscribed to the Subject Node, with the message addressed to the MIX Proxy.
|
||||
This message is received by the MIX channel, which will set the Subject Node for the channel, and then distribute the message to participants that are subscribed to the Subject Node, with the message addressed to the participant’s server using the participant's bare JID.
|
||||
</p>
|
||||
<example caption="Channel Reflects New Subject to Participants"><![CDATA[
|
||||
<message from='coven+12345@mix.shakespeare.example/678'
|
||||
|
|
@ -1387,7 +1388,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
</message>
|
||||
]]></example>
|
||||
<p>
|
||||
When a new Participant joins a channel and subscribes to the Subject Node, the channel MUST send to the user's MIX Proxy a message with the current subject. An XMPP Client MAY directly read the Subject node using &xep0060;.
|
||||
When a new Participant joins a channel and subscribes to the Subject Node, the channel MUST send to the participant's server (using the participant's bare JID) a message with the current subject. An XMPP Client MAY directly read the Subject node using &xep0060;.
|
||||
</p>
|
||||
</section3>
|
||||
<section3 topic='Telling another User about a Channel' anchor='usecase-user-tell'>
|
||||
|
|
@ -1499,8 +1500,8 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
<table caption="Setting From and To when sending Private Messages">
|
||||
<tr><th>Message</th><th>From</th><th>To</th></tr>
|
||||
<tr><td>First Message from Client to MIX Channel</td><td>Full JID of initiator's client</td><td>Proxy bare JID of responder</td></tr>
|
||||
<tr><td>First Message from MIX Channel to responder's MIX Proxy</td><td>Proxy full JID of initiator's client</td><td>Bare JID of responder</td></tr>
|
||||
<tr><td>First Message from responder's MIX Proxy to one or more of the responder's clients</td><td>Proxy full JID of initiator</td><td>Full JID of responder's client</td></tr>
|
||||
<tr><td>First Message from MIX Channel to responder's server</td><td>Proxy full JID of initiator's client</td><td>Bare JID of responder</td></tr>
|
||||
<tr><td>First Message from responder's server to one or more of the responder's clients</td><td>Proxy full JID of initiator</td><td>Full JID of responder's client</td></tr>
|
||||
<tr><td>Messages from responder's client to MIX Channel</td><td>Full JID of responder's client</td><td>Proxy full JID of initiator's client</td></tr>
|
||||
<tr><td>Messages from MIX channel to initiator's client</td><td>Proxy full JID of responder's client</td><td>Full JID of initiator's client</td></tr>
|
||||
<tr><td>Messages from initiator's client to MIX Channel</td><td>Full JID of initiator's client</td><td>Proxy full JID of responder's client</td></tr>
|
||||
|
|
@ -1512,7 +1513,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
|
||||
|
||||
<section3 topic="Requesting vCard" anchor="usecase-vcard">
|
||||
<p>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 through a MIX Proxy. 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 advertized 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.</p>
|
||||
<p>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 advertized 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.</p>
|
||||
<example caption="Client directly requests vCard through channel" ><![CDATA[
|
||||
<iq from='hag66@shakespeare.example/intibo24'
|
||||
id='lx09df27'
|
||||
|
|
@ -1521,8 +1522,8 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
<vCard xmlns='vcard-temp'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The MIX channel MAY pass on the vCard request or may reject with an error, dependent on channel policy. The MIX service will then address the vCard request to the MIX proxy (bare JID) using an anonymous full proxy JID to hide the requester. </p>
|
||||
<example caption="Channel passes on vCard request to MIX Proxy" ><![CDATA[
|
||||
<p>The MIX channel MAY pass on the vCard request or may reject with an error, dependent on channel policy. The MIX service will then address the vCard request to the user's server (using bare JID) using an anonymous full proxy JID to hide the requester. </p>
|
||||
<example caption="Channel passes on vCard request to the User's Server" ><![CDATA[
|
||||
<iq from='coven+123456@mix.shakespeare.example/6789'
|
||||
id='lx09df27'
|
||||
to='peter@shakespeare.lit'
|
||||
|
|
@ -1531,9 +1532,9 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
</iq>
|
||||
]]></example>
|
||||
<p>
|
||||
The MIX Proxy, on behalf of the user, MAY send a response or reject with an error. The MIX Proxy will send the vCard back to the channel.
|
||||
The user's server, on behalf of the user, MAY send a response or reject with an error. The user's server will send the vCard back to the channel.
|
||||
</p>
|
||||
<example caption="Service responds with Disco Info result" ><![CDATA[
|
||||
<example caption="User's Server sends vCard Response via MIX channel" ><![CDATA[
|
||||
<iq from='peter@shakespeare.lit'
|
||||
id='lx09df27'
|
||||
to='coven+123456@mix.shakespeare.example/6789'
|
||||
|
|
@ -1554,7 +1555,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
<p>
|
||||
The MIX channel will then send the vCard response to the requesting client on behalf of the client sending the response.
|
||||
</p>
|
||||
<example caption="Service responds with Disco Info result" ><![CDATA[
|
||||
<example caption="MIX Channel sends vCard responst to Client" ><![CDATA[
|
||||
<iq from='coven+989898@mix.shakespeare.example'
|
||||
id='lx09df27'
|
||||
to='hag66@shakespeare.example/intibo24'
|
||||
|
|
@ -2028,18 +2029,18 @@ A client creates a channel by sending a simple request to the MIX service. A c
|
|||
</section1>
|
||||
|
||||
|
||||
<section1 topic="MIX Proxy" anchor="mix-proxy">
|
||||
<section1 topic="MIX Requirements on Participant's Server" anchor="mix-requirements-participant-server">
|
||||
<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.
|
||||
This section defines behaviour required by MIX for servers supporting MIX participants. This provides the full MIX specification for clients and servers is set out in a single document. This functionality MUST be provided by servers used by clients that participate in MIX channels. In future, the specifications in this section may be moved to a separate XEP or it may be incorporated into
|
||||
&xep0376; (PAM) which follows a similar model.
|
||||
</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 <activate> 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 <channel> 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.
|
||||
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 <activate> 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 <channel> 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[
|
||||
<example caption="Client Activates use of MIX" ><![CDATA[
|
||||
<iq from='hag66@shakespeare.example/intibo24'
|
||||
id='lx09df27'
|
||||
type='set'>
|
||||
|
|
@ -2059,13 +2060,13 @@ A client creates a channel by sending a simple request to the MIX service. A c
|
|||
|
||||
|
||||
<p>
|
||||
Following MIX activation, the MIX Proxy 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.
|
||||
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 <deactivate> element to instruct the MIX proxy to activate the client.
|
||||
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 <deactivate> element to instruct the local server to deactivate the client.
|
||||
</p>
|
||||
|
||||
<example caption="Client Deactivates use of MIX Proxy" ><![CDATA[
|
||||
<example caption="Client Deactivates use of MIX" ><![CDATA[
|
||||
<iq from='hag66@shakespeare.example/intibo24'
|
||||
id='lx09df27'
|
||||
type='set'>
|
||||
|
|
@ -2081,26 +2082,27 @@ A client creates a channel by sending a simple request to the MIX service. A c
|
|||
]]></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.
|
||||
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.
|
||||
</p>
|
||||
|
||||
</section2>
|
||||
|
||||
<section2 topic="Messages From MIX Channels" anchor="proxy-from">
|
||||
<section2 topic="Messages From MIX Channels" anchor="mix-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.
|
||||
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.
|
||||
</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.
|
||||
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.
|
||||
</p>
|
||||
</section2>
|
||||
|
||||
<section2 topic="Messages To MIX Channels" anchor="proxy-to">
|
||||
<section2 topic="Messages To MIX Channels" anchor="mix-to">
|
||||
<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 client addresses the MIX proxy by sending the message to the user's own bare JID, indicating the channel with the channel attribute. This is illustrated below.
|
||||
The MIX specification requires that some messages MUST or MAY come from the participant's server, and that the MIX client sends these messages to the local server rather than directly to the MIX channel.
|
||||
This enables the participant's server to use information from the client to improve the service provided to the client. The client addresses these messages by sending them to the user's own bare JID, indicating the channel with the channel attribute. This is illustrated below.
|
||||
|
||||
</p>
|
||||
<example caption="Client sends request to MIX Proxy to Join a Channel"><![CDATA[
|
||||
<example caption="Client sends request to local server to Join a MIX Channel"><![CDATA[
|
||||
<iq type='set'
|
||||
from='hag66@shakespeare.example/pda'
|
||||
to='hag66@shakespeare.example'
|
||||
|
|
@ -2116,9 +2118,9 @@ A client creates a channel by sending a simple request to the MIX service. A c
|
|||
</iq>
|
||||
]]></example>
|
||||
|
||||
<p>This is then modified by the MIX Proxy and sent to the channel as shown earlier in the core MIX specification. This is shown again in the following example. </p>
|
||||
<p>This is then modified by the local server and sent to the MIX channel as shown earlier in the core MIX specification. This is shown again in the following example. </p>
|
||||
|
||||
<example caption="MIX Proxy sends Join to MIX Channel"><![CDATA[
|
||||
<example caption="Participant's Server sends Join to MIX Channel"><![CDATA[
|
||||
<iq type='set'
|
||||
from='hag66@shakespeare.example'
|
||||
to='coven@mix.shakespeare.example'
|
||||
|
|
@ -2139,16 +2141,16 @@ A client creates a channel by sending a simple request to the MIX service. A c
|
|||
|
||||
<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.
|
||||
The participant's server 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.
|
||||
The participant's server 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.
|
||||
Archive of MIX channel messages is done by the participant's server. Where a message is sent to the participant's server 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>
|
||||
|
|
|
|||
Loading…
Reference in New Issue