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
516a1ae3f2
xeps/xep-0405.xml
Steve Kille 03b03ffd2c Reference latest core (core:1); 
Bump namespace to pam:2;
2019-09-30 11:32:00 +01:00

586 lines
33 KiB
XML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<?xml-stylesheet type="text/css" href="xmpp.css"?>
<xep>
<header>
<title>Mediated Information eXchange (MIX): Participant Server Requirements</title>
<abstract>This document defines an extension to Mediated Information eXchange (MIX) specified in XEP-0369. It specifies behaviour of an XMPP server to which MIX Clients connect in order to enable correct operation of these clients in conjunction with a MIX server. </abstract>
&LEGALNOTICE;
<number>0405</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>XEP-0004</spec>
<spec>XEP-0030</spec>
<spec>XEP-0054</spec>
<spec>XEP-0060</spec>
<spec>XEP-0084</spec>
<spec>XEP-0128</spec>
<spec>XEP-0198</spec>
<spec>XEP-0292</spec>
<spec>XEP-0297</spec>
<spec>XEP-0313</spec>
<spec>XEP-0372</spec>
<spec>XEP-0369</spec>
<spec>XEP-0403</spec>
<spec>XEP-0404</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>MIX-PAM</shortname>
&ksmithisode;
&skille;
<revision>
<version>0.5.0</version>
<date>2019-09-30</date>
<initials>sek</initials>
<remark>
Reference latest core (core:1);
Bump namespace to pam:2;
</remark>
</revision>
<revision>
<version>0.4.1</version>
<date>2019-04-30</date>
<initials>lnj</initials>
<remark>Fix typo in the #archive namespace</remark>
</revision>
<revision>
<version>0.4.0</version>
<date>2019-03-19</date>
<initials>sek</initials>
<remark>
Make Archiving Optional;
Bump namespace to pam:1;
</remark>
</revision>
<revision>
<version>0.3.1</version>
<date>2019-01-13</date>
<initials>lnj (Editor: jsc)</initials>
<remark>White space changes and XML syntax fixes</remark>
</revision>
<revision>
<version>0.3.0</version>
<date>2018-12-11</date>
<initials>sek</initials>
<remark>
Discovery on Account rather than Server;
Add participant ID to roster;
</remark>
</revision>
<revision>
<version>0.2.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.2.0</version>
<date>2018-06-06</date>
<initials>sek</initials>
<remark><p>
Add section on Blocking;
</p></remark>
</revision>
<revision>
<version>0.1.1</version>
<date>2018-06-05</date>
<initials>sek</initials>
<remark><p>
Align to MIX-CORE and MIX-PRESENCE changes;
</p></remark>
</revision>
<revision>
<version>0.1.0</version>
<date>2018-05-21</date>
<initials>sek</initials>
<remark><p>
Split out from MIX 0.10.0;
</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). MIX-CORE and &xep0403; define behaviour of a MIX server supporting MIX channels. In order for a MIX system to operate correctly, the XMPP server connecting MIX clients MUST follow the rules set out in this specification to achieve correct MIX operation. This specification also sets out requirements for XMPP clients, so a MIX client MUST follow both the rules of XMPP-CORE and this specification.
</p>
<p>
A MIX channel does not send messages and presence directly to the MIX client of a channel participant, but addresses them to the 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>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 participant's server (addressed by bare JID) and MUST be handled by the MIX participant's server.</li>
<li>All MIX messages received by the MIX participant's server for a participant MUST be stored using MAM in the participant's archive.</li>
<li>The MIX participant's server will only forward messages to online clients and will not forward messages if no clients are online.
This means that a MIX client needs to resynchronize with all MIX channels 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 client will generally send management and other messages directly to the MIX channel and this MUST be done except where this specification requires otherwise. </li>
<li>The user's roster contains each MIX channel to which the user is subscribed. To achieve this the user's server needs to manage the roster on behalf of the user. For this reason, MIX join and leave commands MUST be sent by a client to the user's server. This enables the user's server to correctly manage the roster on behalf of the user.</li>
</ol>
<p>
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.
</p>
</section1>
<section1 topic="Use Cases" anchor="pam-use-cases">
<p>
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
&xep0376; (PAM) which follows a similar model.
</p>
<section2 topic="Server Identification of MIX Capabable Clients" anchor="server-identification-mix-clients">
<p>
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 <link url="#mix-client-discovery">Discovering Client MIX Capability</link>.
</p>
</section2>
<section2 topic="Messages From MIX Channels" anchor="mix-from">
<p>
Messages from a MIX channel will usually be handled by 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 by 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 archive the message in MAM and 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 not sent to any clients.
</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 following example, repeated from &xep0369;, shows a message distributed by a MIX channel and directed to the participant’s server with the participant's bare JID.
</p>
<example caption="Channel Reflects Message to Participants"><![CDATA[
<message from='coven@mix.shakespeare.example/123456'
to='hecate@shakespeare.example'
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
<mix xmlns='urn:xmpp:mix:core:1'>
<nick>thirdwitch</nick>
<jid>hag66@shakespeare.example</jid>
</mix>
</message>
]]></example>
<p>
The server receiving the message will then deliver the messages to all online clients. Messages are delivered to all available online resources irrespective of
status and resource priority.
The following example shows how the participant's server modifies the inbound message to replace the bare JID in the 'to' with a full JID for each of two active MIX clients.
</p>
<example caption="Participant's Server Sends Modified Message to two Clients"><![CDATA[
<message from='coven@mix.shakespeare.example/123456'
to='hecate@shakespeare.example/UUID-x4r/2491'
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
<mix xmlns='urn:xmpp:mix:core:1'>
<nick>thirdwitch</nick>
<jid>hag66@shakespeare.example</jid>
</mix>
</message>
<message from='coven@mix.shakespeare.example/123456'
to='hecate@shakespeare.example/UUID-b5b/0114'
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
<mix xmlns='urn:xmpp:mix:core:1'>
<nick>thirdwitch</nick>
<jid>hag66@shakespeare.example</jid>
</mix>
</message>
]]></example>
</section2>
<section2 topic="Messages To MIX Channels" anchor="user-server-to">
<p>
Messages sent by a MIX channel participant to the MIX channel are always sent from a MIX client directly to the channel. The participant's server relays the message but does not modify the messages.
</p>
</section2>
<section2 topic="Client Determines MIX Capability of Client's Server" anchor="user-server-client-capability">
<p>
Servers supporting this specification MUST advertise this to clients for which they wish to support this specification. A client wishing to use MIX MUST check for this capability in the local server before using MIX, by verifying support for the client's account. The capability is represented by the 'urn:xmpp:mix:pam:2' feature. In addition to this the server MAY advertize the 'urn:xmpp:mix:pam:2#archive' feature, which shows that the local server archives MIX messages.
</p>
<example caption="Client Determines MIX Capability for Server Account"><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='lx09df27'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
<iq id='lx09df27'
to='hag66@shakespeare.example/UUID-c8y/1573'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='urn:xmpp:mix:pam:2'/>
<feature var='urn:xmpp:mix:pam:2#archive'/>
</query>
</iq>
]]></example>
</section2>
<section2 topic="MIX Management and Discovery" anchor="user-server-disco">
<p>
Most interaction between a MIX client and a MIX channel is directly between the client and the channel. The participant's server relays the message but does not modify the messages. In particular configuration management and discovery is direct. Interaction will be direct, unless explicitly stated otherwise in this specification.
</p>
</section2>
<section2 topic="MIX Join and Leave Support on Local Server" anchor="mix-join-leave">
<p>
Channel Join and Leave functions operate indirectly through the participant's server. The reason for this is that where a channel shares user presence, the channel is included in the user's roster which is managed in the local server. The Join and Leave functions lead to roster changes and so they MUST go through the participant's server. To achieve this, this specification wraps the operations so that the server can correctly route messages.
</p>
</section2>
<section2 topic='Joining a Channel' anchor='usecase-user-join'>
<p>A user joins a channel by sending a MIX "client-join" command from one of the user's clients, which wraps the "join" command specified in &xep0369;. &xep0369; specifies how the join command works, and so this specification considers only the wrapping and client actions.
The &lt;client-join/&gt; is a child element of &lt;iq/&gt; element. The &lt;client-join/&gt; element is qualified by the 'urn:xmpp:mix:pam:2' namespace. The channel being joined is specified by a 'channel' attribute in the &lt;client-join/&gt; element, which is used by the server to correctly address the join. The &lt;join&gt; is specified in &xep0369; and is a child element of &lt;client-join/&gt;.
</p>
<example caption="Client sends request to local server to Join a MIX Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/UUID-a1j/7533'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<client-join xmlns='urn:xmpp:mix:pam:2' channel='coven@mix.shakespeare.example'>
<join xmlns='urn:xmpp:mix:core:1'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
<subscribe node='urn:xmpp:mix:nodes:participants'/>
<subscribe node='urn:xmpp:mix:nodes:info'/>
</join>
</client-join>
</iq>
]]></example>
<p>The information in this message is used to derive the message sent to the MIX channel. The 'from' is the bare JID of the user. The 'to' is the channel from the client join 'channel' attribute. The 'id' is taken from the client join message. The &lt;join&gt; is taken from the client join message. This is shown in the following example, repeated from the earlier specification of channel behaviour. </p>
<example caption="Participant's Server sends Join to MIX Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:core:1'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
<subscribe node='urn:xmpp:mix:nodes:participants'/>
<subscribe node='urn:xmpp:mix:nodes:info'/>
</join>
</iq>
]]></example>
<p>
The MIX service will process this request and respond as specified by &xep0369;. An example response taken from &xep0369; is shown below.
</p>
<example caption="Channel responds to User's Server"><![CDATA[
<iq type='result'
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<join xmlns='urn:xmpp:mix:core:1' jid='123456#coven@mix.shakespeare.example'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
<subscribe node='urn:xmpp:mix:nodes:participants'/>
<subscribe node='urn:xmpp:mix:nodes:info'/>
</join>
</iq>
]]></example>
<p>
The user's server will then make roster modifications as set out in a later section of this specification.
After making these changes, the user's server will send the client-join response containing the server's join response back to the client that made the join request. This has the 'from' set to the user's bare JID and the 'to' set to the client's full JID. This is illustrated below:
</p>
<example caption="User's Server sends response to Client"><![CDATA[
<iq type='result'
from='hag66@shakespeare.example'
to='hag66@shakespeare.example/UUID-a1j/7533'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<client-join xmlns='urn:xmpp:mix:pam:2'>
<join xmlns='urn:xmpp:mix:core:1'
jid='123456#coven@mix.shakespeare.example'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<subscribe node='urn:xmpp:mix:nodes:presence'/>
<subscribe node='urn:xmpp:mix:nodes:participants'/>
<subscribe node='urn:xmpp:mix:nodes:info'/>
</join>
</client-join>
</iq>
]]></example>
</section2>
<section2 topic='Leaving a Channel' anchor='usecase-user-leaving'>
<p>Users generally remain in a channel for an extended period of time. The process for leaving a MIX channel is specified in &xep0369;. When a user desires to leave a channel, it will issue a client-leave request to the local server.
The &lt;client-leave/&gt; is a child element of &lt;iq/&gt; element. The &lt;client-leave/&gt; element is qualified by the 'urn:xmpp:mix:pam:2' namespace. The channel being left is specified by a 'channel' attribute in the &lt;client-leave/&gt; element, which is used by the server to correctly address the join. The &lt;leave&gt; is specified in &xep0369; and is a child element of &lt;client-leave/&gt;.
This shown in the following example.</p>
<example caption="Client Requests to Leave a Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/UUID-a1j/7533'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<client-leave xmlns='urn:xmpp:mix:pam:2'
channel='coven@mix.shakespeare.example'>
<leave xmlns='urn:xmpp:mix:core:1'/>
</client-leave>
</iq>
]]></example>
<p>
The user's server will then generate a matching leave request to the MIX channel based on this information. This example is taken from &xep0369;.
</p>
<example caption="User's Server sends Leave Request to a Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<leave xmlns='urn:xmpp:mix:core:1'/>
</iq>
]]></example>
<p>
The MIX channel will then process the leave and respond. The following example is taken from &xep0369;.
</p>
<example caption="Channel Confirms Leave to User's Server"><![CDATA[
<iq type='result'
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<leave xmlns='urn:xmpp:mix:core:1'/>
</iq>
]]></example>
<p>
After receiving the confirmation that the user has left the MIX channel, the user's server will remove the MIX channel entry from the user's roster and follow other processing as specified below. The user's server will then notify the client with the servers response.
This wraps the response from the server with a client-leave, with the 'from' set to the user's bare JID and the 'to' set to the client's full JID. This is illustrated below:
</p>
<example caption="User's Server Confirms Leave to Client"><![CDATA[
<iq type='result'
from='hag66@shakespeare.example'
to='hag66@shakespeare.example/UUID-a1j/7533'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<client-leave xmlns='urn:xmpp:mix:pam:2'>
<leave xmlns='urn:xmpp:mix:core:1'/>
</client-leave>
</iq>
]]></example>
</section2>
<section2 topic="Roster Management" anchor="usecase-roster">
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
The user's server MUST remove the user's roster entry when the user leaves the channel.
</p>
<p>
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.
</p>
<section3 topic='Setting User Presence' anchor='usecase-user-presence'>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.</p>
<example caption="Client Sets Presence Status on Server"><![CDATA[
<presence xmlns='jabber:client' from='hag66@shakespeare.example/UUID-a1j/7533'>
<show>dnd</show>
<status>Making a Brew</status>
</presence>]]></example>
<p>
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;.
</p>
<example caption="Server sends Presence Status to MIX Channel"><![CDATA[
<presence from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'>
<show>dnd</show>
<status>Making a Brew</status>
</presence>]]></example>
</section3>
<section3 topic='Receiving User Presence' anchor='usecase-user-presence-receive'>
<p>
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:
</p>
<example caption="User's Server Receives Presence"><![CDATA[
<presence from='123435#coven@mix.shakespeare.example/UUID-a1j/7533'
to='hag99@shakespeare.example'
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
<mix xmlns='urn:xmpp:presence:0'>
<jid>hecate@shakespeare.example/UUID-x4r/2491</jid>
<nick>thirdwitch</nick>
</mix>
<show>dnd</show>
<status>Making a Brew</status>
</presence>]]></example>
<p>
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:
</p>
<example caption="User's Server Sends Presence to Client"><![CDATA[
<presence from='123435#coven@mix.shakespeare.example/UUID-a1j/7533'
to='hag99@shakespeare.example/UUID-rrr/1234'
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
<mix xmlns='urn:xmpp:presence:0'>
<jid>hecate@shakespeare.example/UUID-x4r/2491</jid>
<nick>thirdwitch</nick>
</mix>
<show>dnd</show>
<status>Making a Brew</status>
</presence>]]></example>
<p>
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.
</p>
</section3>
<section3 topic="Client Coming Online and Obtaining Presence from the Local Server" anchor="usecase-obtaining-presence">
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</section3>
<section3 topic='Going Offline' anchor='usecase-user-offline'>
<p>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. </p>
<example caption="Client Goes Offline and Sends Presence to Channel"><![CDATA[
<presence type='unavailable'
from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'/>
]]></example>
<p>
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.
</p>
</section3>
</section2>
<section2 topic="MIX Roster Item Capability Sharing" anchor="mix-roster-capability-sharing">
<p>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 &lt;annotate/&gt; to the &lt;query/&gt; element. The &lt;annotate/&gt; element is qualified by the ‘urn:xmpp:mix:roster:0' namespace.</p>
<example caption="Roster Get Requesting MIX Information"><![CDATA[
<iq from='juliet@example.com/balcony'
id='bv1bs71f'
type='get'>
<query xmlns='jabber:iq:roster'>
<annotate xmlns='urn:xmpp:mix:roster:0'/>
</query>
</iq>
]]></example>
<p>A standard roster item is encoded as follows.</p>
<example caption="Standard Roster Item Encoding"><![CDATA[
<item jid='romeo@example.net'/>
]]></example>
<p>
MIX channels in the roster information returned in response to a request for this additional MIX information MUST have an element &lt;channel/&gt; qualified by the ‘urn:xmpp:mix:roster:0' namespace included in the roster item. The &lt;channel/&gt; element MUST also include a 'participant-id' attribute that is the stable ID of the client. This facilitates the client to match messages that reference this stable ID. A MIX extended roster item is shown in the following example.
</p>
<example caption="Roster Item Encoding of a MIX Channel"><![CDATA[
<item jid='balcony@example.net'>
<channel xmlns='urn:xmpp:mix:roster:0' participant-id='123456'/>
</item>
]]></example>
<p>
Once a client has made an IQ request to return additional MIX information, the server MUST return this information on all subsequent roster updates that are sent by the server to the client. The server MUST NOT send additional MIX information when this has not been explicitly requested. It is anticipated that a client will fetch the roster after connection has been established and will set its preference for this MIX capability information at that time.
</p>
</section2>
<section2 topic="MAM Archive Support" anchor="usecase-mam">
<p>
Archive of MIX channel messages MAY be performed by the participant's server. When this is done, the capability is advertized to MIX clients using the 'urn:xmpp:mix:pam:2#archive' feature. If archive is provided it MUST always be used, so that
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 when archiving is provided, the messages will be available in the local archive and can be picked up by clients when they come online.
</p>
</section2>
<section2 topic="Blocking Considerations" anchor="usecase-blocking">
<p>
This section describes an issue that needs to be addressed by servers that provide blocking capabilities based on JID. Messages distributed by a MIX channel come from JIDs containing the bare JID of the channel. For presence stanzas (specified in MIX-PRESENCE), IQ stanza relay (specified in MIX-PRESENCE), and private messages (specified in MIX-ANON) use an encoded JID, where the local part of the bare JID contains both the channel name and the senders Stable Participant ID, for example '123435#coven@mix.shakespeare.example'. A server implementing blocking and MIX-PAM needs to recognize this encoding, to prevent blocking these messages when this is not desired.
</p>
</section2>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>See considerations in &xep0369;.
</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>See considerations in &xep0369;.</p>
<p>
When converting a 1:1 conversation to a channel there is potential to expose sensitive information and to present invalid information.
</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>None.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The urn:xmpp:mix namespace needs to be registered.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>To be supplied when MIX progresses to proposed standard.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>See &xep0369; for a list of contributors to the MIX Family of specifications.</p>
</section1>
</xep>
Reference in New Issue View Git Blame Copy Permalink