mirror of https://github.com/moparisthebest/xeps
More edits
This commit is contained in:
Steve Kille
parent
dd7d6ab757
commit
7f44878178
430
xep-0369-PAM.xml
430
xep-0369-PAM.xml
|
|
@ -8,7 +8,7 @@
|
|||
<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. XXXX </abstract>
|
||||
<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>0404</number>
|
||||
<status>Experimental</status>
|
||||
|
|
@ -48,23 +48,10 @@
|
|||
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>The Mediated Information eXchange (MIX) protocol framework and core capbilities are specified in &xep0369; (MIX-CORE).
|
||||
|
||||
<p>The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). MIX-CORE and MIX-PRESENCE 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>
|
||||
|
||||
</section1>
|
||||
|
||||
<section1 topic='Requirements' anchor='reqs'>
|
||||
|
||||
<p></p>
|
||||
|
||||
</section1>
|
||||
|
||||
<section1 topic='Concepts' anchor='concepts'>
|
||||
|
||||
|
||||
|
||||
<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 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.
|
||||
|
|
@ -80,266 +67,42 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
|||
<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 specifically noted. </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) and presence information are sent to the participant's server using the participant's bare JID. This means that the MIX participant's server MUST implement a modification of the standard &rfc6121; message processing rules.
|
||||
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>
|
||||
<p>
|
||||
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>
|
||||
|
||||
|
||||
</section1>
|
||||
|
||||
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
<section2 topic='Common User Use Cases' anchor='usecases-user'>
|
||||
|
||||
<section3 topic="Roster Management" anchor="usecase-roster-management">
|
||||
<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>
|
||||
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 described below. 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 this 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>
|
||||
|
||||
|
||||
|
||||
|
||||
<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 user goes online or offline. The user's participation in a channel is reflected by the user's bare JID in the participant node. All messages to the channel are sent to this JID.
|
||||
|
||||
</p>
|
||||
<p>
|
||||
|
||||
A user MAY share presence information with the channel, for one or more online clients. Where a user shares presence information with a channel, the channel is entered by the user's server into the user's roster when the user subscribes 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. The MIX channel will update the "urn:xmpp:mix:nodes:presence" node with any change of status and the updated presence information and then share this updated presence with users subscribed to this node, as described below. When the user sets an explicit status, this is used to modify the presence node in the channel. When a client being used by the user goes offline, the associated server will send presence status "unavailable" to the MIX channel, which will cause the full JID for that client to be removed from the presence node.
|
||||
</p>
|
||||
<p>
|
||||
A channel MAY require that all channel participants share presence information with the channel, which is represented in the "urn:xmpp:mix:nodes:presence" node. If sharing presences is needed by the channel, an XMPP client conforming to this specification MUST share presence with the channel by including the channel in the user's roster. Note that the MIX service cannot generally enforce this, but it can require and enforce that when a message is sent to the channel, that the sender of the message is in the presence list.
|
||||
</p>
|
||||
<p>
|
||||
Presence status and availability is set in a MIX channel by standard presence stanzas sent to the MIX channel by the user's server. Users wishing to receive presence updates will subscribe to the MIX channel presence node. Presence updates are sent out to subscribing participants using standard presence stanzas.
|
||||
</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 "urn:xmpp:mix:nodes: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.
|
||||
</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>
|
||||
<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 full proxy JID of the client updating status.
|
||||
Note that presence is associated with a client and so will have a full JID. The following example shows a presence message as distributed by the server to a presences subscriber.</p>
|
||||
<example caption="Channel Distributes Presence">
|
||||
<![CDATA[<presence from='123435#coven@mix.shakespeare.example/678'
|
||||
to='hag99@shakespeare.example'
|
||||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
|
||||
<nick xmlns='http://jabber.org/protocol/nick'>thirdwitch</nick>
|
||||
<show>dnd</show>
|
||||
<status>Making a Brew</status>
|
||||
</presence>]]></example>
|
||||
<p>
|
||||
The presence is distributed to those subscribing to the MIX channel presence node using a standard XMPP presence stanza. The presence change is recorded on the "urn:xmpp:mix:nodes:presence" node. The history of this node will be held as PubSub format in the MAM archive, so that presence history can be viewed.
|
||||
</p>
|
||||
</section3>
|
||||
|
||||
<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 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. The user's server MAY cache this presence information to optimize performance or MAY discard it.
|
||||
</p>
|
||||
<p>
|
||||
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="Updating Presence on User's Server" anchor="usecase-server-presence-update">
|
||||
<p>
|
||||
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 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 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">
|
||||
<p>
|
||||
Presence information will provide a MIX client with the nicks and proxy JIDs for participants in a channel. Messages sent to a channel and retrieved from MAM archives will show the proxy JID and nick of the sender. It is sometimes useful to determine the real JID associated with proxy JID. This can always be done for JID Visible channels and can sometimes be done for JID Maybe Visible channels.
|
||||
|
||||
</p>
|
||||
<p>
|
||||
For current users JID visible rooms, the real JID is found by a PubSub lookup on the JID Map node. This is shown in the following example:
|
||||
</p>
|
||||
|
||||
<example caption='Client looks up Real JID from Proxy JID'><![CDATA[
|
||||
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
|
||||
id='kl2fax27'
|
||||
to='coven@mix.shakespeare.example'
|
||||
type='get'>
|
||||
<pubsub xlns='http://jabber.org/protocol/pubsub'>
|
||||
<items node='urn:xmpp:mix:nodes:jidmap'>
|
||||
<item id='123456#coven@mix.shakespeare.example'/>
|
||||
</items>
|
||||
</pubsub>
|
||||
</iq>
|
||||
|
||||
<iq from='coven@mix.shakespeare.example'
|
||||
id='kl2fax27'
|
||||
to='hag66@shakespeare.example/UUID-c8y/1573'
|
||||
type='result'>
|
||||
<pubsub xlns='http://jabber.org/protocol/pubsub'>
|
||||
<items node='urn:xmpp:mix:nodes:jidmap'>
|
||||
<item id='123456#coven@mix.shakespeare.example'>
|
||||
<participant xmlns='urn:xmpp:mix:1'>
|
||||
<jid>hecate@mix.shakespeare.example</jid>
|
||||
</participant>
|
||||
</item>
|
||||
</items>
|
||||
</pubsub>
|
||||
<items>
|
||||
</iq>]]> </example>
|
||||
|
||||
|
||||
<p>For JID Maybe Visible rooms the lookup is performed on the JID Maybe Visible Map node. Note that where a user prefers to not share real JID, the result of this lookup of proxy JID will be the (same) proxy JID. </p>
|
||||
|
||||
<p>
|
||||
When an older message is considered, it is possible that the proxy JID of the sender is not current. Such a JID can be looked up in the MAM Archive of the JID Map Node. This is shown in the following example:
|
||||
</p>
|
||||
<example caption='Client looks up Real JID from Proxy JID in MAM Archive'><![CDATA[
|
||||
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
|
||||
id='kl2fax27'
|
||||
to='coven@mix.shakespeare.example'
|
||||
type='set'>
|
||||
<query xlns='urn:xmpp:mam:2'
|
||||
queryid='f28'
|
||||
node='urn:xmpp:mix:nodes:jidmap'>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:mam:2</value>
|
||||
</field>
|
||||
<field var='id'>
|
||||
<value>123456#coven@mix.shakespeare.example</value>
|
||||
</field>
|
||||
</x>
|
||||
</query>
|
||||
</iq>
|
||||
|
||||
<message id='iasd208' to='hag66@shakespeare.example/UUID-c8y/1573'>
|
||||
<result xmlns='urn:xmpp:mam:2' queryid='f28' id='28482-20987-73623'>
|
||||
<forwarded xmlns='urn:xmpp:forward:0'>
|
||||
<delay xmlns='urn:xmpp:delay' stamp='2010-07-10T23:08:25Z'/>
|
||||
<message xmlns="jabber:client">
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='urn:xmpp:mix:nodes:jidmap'>
|
||||
<item id='123456#coven@mix.shakespeare.example'>
|
||||
<participant xmlns='urn:xmpp:mix:1'>
|
||||
<jid>hecate@mix.shakespeare.example</jid>
|
||||
</participant>
|
||||
</item>
|
||||
</items>
|
||||
</event>
|
||||
</message>
|
||||
</forwarded>
|
||||
</result>
|
||||
</message>
|
||||
|
||||
<iq from='coven@mix.shakespeare.example'
|
||||
to='hag66@shakespeare.example/UUID-c8y/1573'
|
||||
id='kl2fax27'
|
||||
type='result'>
|
||||
</iq>]]> </example>
|
||||
|
||||
|
||||
|
||||
</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. Handling by the MIX channel is slightly different.</p>
|
||||
<example caption="Client Goes Offline in the Channel"><![CDATA[
|
||||
<presence type='unavailable'
|
||||
from='hag66@shakespeare.example/UUID-a1j/7533'
|
||||
to='coven@mix.shakespeare.example'/>
|
||||
]]></example>
|
||||
<p>The MIX channel will retract (remove) the item in the presence node of the MIX channel identified by the client's full JID. The MIX channel will notify subscribers to the presence node of the user going offline by sending a presence stanza to the full JID of each client. The presence stanza will reference the full proxy JID of the client that is going offline, as shown in the following example:</p>
|
||||
|
||||
<example caption="Channel Distributes Notification of Client going Offline">
|
||||
<![CDATA[<presence from='12345#coven@mix.shakespeare.example/678'
|
||||
to='hecate@shakespeare.example'
|
||||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
|
||||
type='unavailable'/>]]></example>
|
||||
|
||||
<p>
|
||||
There is the possibility that the message associated with the user going offline will be lost. If this happens, "ghost" entries will appear in the presence node. A MIX service MAY take steps to address this, for example by probing client with a disco for presence items that remain unchanged for a long period.
|
||||
</p>
|
||||
<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="Presence Initializion" anchor="use-presence-initialize">
|
||||
<section1 topic="Use Cases" anchor="pam-use-cases">
|
||||
<p>
|
||||
For an active MIX Channel, the presence node is updated as channel participants change status and presence information is sent to the channel. When a MIX channel starts, typically when the associated MIX Service and Server start, there is a need to initialize the presence node. This is done by the XMPP server associated with the MIX channel sending out a presence probe for each channel participant, following the presence probe process specified in &rfc6121;. A presence probe MUST NOT be sent for users who have set presence preference to not sharing.
|
||||
</p>
|
||||
</section2>
|
||||
|
||||
|
||||
|
||||
|
||||
</section1>
|
||||
|
||||
<section1 topic="MIX Requirements on Participant's Server" anchor="mix-requirements-participant-server">
|
||||
<p>
|
||||
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
|
||||
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, 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. 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>.
|
||||
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 go to the participant's server. The only exception to this is where the MIX channel is responding directly to messages from the client. Messages and presence distributed but a MIX channel will always be sent to the participant's server and addressed to the user's bare JID. The participant's server will simply send on the messages from the channel to each of the user's online clients which advertise MIX capability. If there are no such clients activated, the message is dropped.
|
||||
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 but a MIX channel will always be sent to the participant's server and addressed to the user's bare JID. The participant's server will simply send on the messages from the channel to each of the user's online clients which advertise MIX capability. If there are no such clients activated, the message is dropped.
|
||||
</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 earlier, shows a message distributed by a MIX channel and directed to the participant’s server with the participant's bare JID.
|
||||
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 MIX-CORE, 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'
|
||||
|
|
@ -347,9 +110,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
|||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
|
||||
type='groupchat'>
|
||||
<body>Harpier cries: 'tis time, 'tis time.</body>
|
||||
<mix xmlns='urn:xmpp:mix:1'>
|
||||
<mix xmlns='urn:xmpp:mix:core:0'>
|
||||
<nick>thirdwitch</nick>
|
||||
<jid>123456#coven@mix.shakespeare.example</jid>
|
||||
<jid>hag66@shakespeare.example</jid>
|
||||
</mix>
|
||||
</message>
|
||||
]]></example>
|
||||
|
|
@ -366,9 +129,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
|||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
|
||||
type='groupchat'>
|
||||
<body>Harpier cries: 'tis time, 'tis time.</body>
|
||||
<mix xmlns='urn:xmpp:mix:1'>
|
||||
<mix xmlns='urn:xmpp:mix:core:0'>
|
||||
<nick>thirdwitch</nick>
|
||||
<jid>123456#coven@mix.shakespeare.example</jid>
|
||||
<jid>hag66@shakespeare.example</jid>
|
||||
</mix>
|
||||
</message>
|
||||
|
||||
|
|
@ -377,9 +140,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
|||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
|
||||
type='groupchat'>
|
||||
<body>Harpier cries: 'tis time, 'tis time.</body>
|
||||
<mix xmlns='urn:xmpp:mix:1'>
|
||||
<mix xmlns='urn:xmpp:mix:core:0'>
|
||||
<nick>thirdwitch</nick>
|
||||
<jid>123456#coven@mix.shakespeare.example</jid>
|
||||
<jid>hag66@shakespeare.example</jid>
|
||||
</mix>
|
||||
</message>
|
||||
|
||||
|
|
@ -395,7 +158,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
|||
|
||||
<section2 topic="Client Determines MIX Capability of Local Server" anchor="user-server-client-capability">
|
||||
<p>
|
||||
Servers supporting the capabilities necessary to enable MIX clients MUST advertise this. A client wishing to use MIX MUST check for this capability in the server before using MIX. The capability is represented by the 'urn:xmpp:mix:account:0' feature.
|
||||
Servers supporting this specification MUST advertise this to clients. A client wishing to use MIX MUST check for this capability in the local server before using MIX. The capability is represented by the 'urn:xmpp:mix:account:0' feature.
|
||||
</p>
|
||||
<example caption="Client Determines MIX Capability of Local Server"><![CDATA[
|
||||
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
|
||||
|
|
@ -421,7 +184,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
|||
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.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic="IQ Support on Local Server" anchor="mix-diso">
|
||||
<section2 topic="MIX Join and Leave Support on Local Server" anchor="mix-diso">
|
||||
<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. This is included in each of the operations that work in this manner. The general mechanism to achieve this is illustrated by example in this section.
|
||||
The client addresses indirect messages to the user's own bare JID, indicating the channel with the channel attribute. This is illustrated below.
|
||||
|
|
@ -435,12 +198,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
|||
from='hag66@shakespeare.example/UUID-a1j/7533'
|
||||
to='hag66@shakespeare.example'
|
||||
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
|
||||
<join xmlns='urn:xmpp:mix:1'
|
||||
<join xmlns='urn:xmpp:mix:core:0'
|
||||
channel='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:config'/>
|
||||
<subscribe node='urn:xmpp:mix:nodes:info'/>
|
||||
</join>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
|
@ -452,11 +215,11 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
|||
from='hag66@shakespeare.example'
|
||||
to='coven@mix.shakespeare.example'
|
||||
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
|
||||
<join xmlns='urn:xmpp:mix:1'>
|
||||
<join xmlns='urn:xmpp:mix:core:0'>
|
||||
<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:config'/>
|
||||
<subscribe node='urn:xmpp:mix:nodes:info'/>
|
||||
</join>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
|
@ -468,14 +231,157 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
|||
|
||||
|
||||
<section2 topic="Roster Management" anchor="proxy-roster">
|
||||
<p>
|
||||
The participant's server is responsible for ensuring that MIX channels are correctly entered into the user's roster when user's join MIX channels and for removing them when they leave.
|
||||
</p>
|
||||
|
||||
|
||||
|
||||
<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 described below. 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 user goes online or offline. The user's participation in a channel is reflected by the user's bare JID in the participant node. All messages to the channel are sent to this JID.
|
||||
|
||||
</p>
|
||||
|
||||
|
||||
<p>
|
||||
|
||||
A user MAY share presence information with the channel, for one or more online clients. The channel is entered by the user's server into the user's roster when the user subscribes to the channel as specified in MIX-PAM. Where a user shares presence information with a channel, the subscription is configured with one way presence, which will cause all presence changes for the client 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>
|
||||
The MIX channel will update the presence node with any change of status and the updated presence information and then share this updated presence with users subscribed to this node, as specified in MIX-CORE. When the user sets an explicit status, this is used to modify the presence node in the channel. When a client being used by the user goes offline, the associated server will send presence status "unavailable" to the MIX channel, which will cause the node item for that client to be removed from the presence node.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A channel MAY require that all channel participants share presence information with the channel, which is represented in the "urn:xmpp:mix:nodes:presence" node. If sharing presences is mandated by the channel, a server complying to this specification MUST set the presence subscription to "one way" and MUST NOT set it to "none".
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Presence status and availability is set in a MIX channel by standard presence stanzas sent to the MIX channel by the user's server. Users wishing to receive presence updates will subscribe to the MIX channel presence node. Presence updates are sent out to subscribing participants using standard presence stanzas.
|
||||
</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.
|
||||
</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>
|
||||
<p>The user's presence information is then published by the service to the presence node. The MIX channel then broadcasts the presence change to all users who are subscribed to the presence node. The presence stanza is sent from a JID comprising the bare proxy JID of the client that is assigned by the MIX channel and the resource provided by the client.
|
||||
The following example shows a presence message as distributed by the server to a presences subscriber.</p>
|
||||
<example caption="Channel Distributes Presence">
|
||||
<![CDATA[<presence from='123435#coven@mix.shakespeare.example/UUID-a1j/7533'
|
||||
to='hag99@shakespeare.example'
|
||||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
|
||||
<nick xmlns='http://jabber.org/protocol/nick'>thirdwitch</nick>
|
||||
<show>dnd</show>
|
||||
<status>Making a Brew</status>
|
||||
</presence>]]></example>
|
||||
<p>
|
||||
The presence is distributed to those subscribing to the MIX channel presence node using a standard XMPP presence stanza. The presence change is recorded on the presence node. The history of this node MAY be held as PubSub format in the MAM archive, so that presence history can be viewed.
|
||||
</p>
|
||||
</section3>
|
||||
|
||||
<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 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, 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>
|
||||
<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>
|
||||
|
||||
</section3>
|
||||
|
||||
<section3 topic="Updating Presence on User's Server" anchor="usecase-server-presence-update">
|
||||
<p>
|
||||
The previous section notes how client update works when the local server is keeping MIX presence up to date.
|
||||
|
||||
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 participant's server needs to load or refresh presence status for a channel. This will be needed when the participant's server is started and 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="Determining Real JIDs" anchor="usecase-real-jids">
|
||||
<p>
|
||||
Presence information is provided with a proxy JID. A MIX client will usually wish to map this to the real JID. This will be done using the participants node, which has a list of all participants identified by proxy JID with real JIDs where this can be shared. Where real JIDs are not available, the Nick will be available. Clients will typically load the participants node on start-up and use a subscription to the participants node to keep this up to date.
|
||||
|
||||
|
||||
</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. Handling by the MIX channel is slightly different.</p>
|
||||
<example caption="Client Goes Offline in the Channel"><![CDATA[
|
||||
<presence type='unavailable'
|
||||
from='hag66@shakespeare.example/UUID-a1j/7533'
|
||||
to='coven@mix.shakespeare.example'/>
|
||||
]]></example>
|
||||
<p>The MIX channel will retract (remove) the item in the presence node of the MIX channel identified by the client's full JID. The MIX channel will notify subscribers to the presence node of the user going offline by sending a presence stanza to the full JID of each client. The presence stanza will reference the full proxy JID of the client that is going offline, as shown in the following example:</p>
|
||||
|
||||
<example caption="Channel Distributes Notification of Client going Offline">
|
||||
<![CDATA[<presence from='12345#coven@mix.shakespeare.example/678'
|
||||
to='hecate@shakespeare.example'
|
||||
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
|
||||
type='unavailable'/>]]></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="Presence Initializion" anchor="use-presence-initialize">
|
||||
<p>
|
||||
For an active MIX Channel, the presence node is updated as channel participants change status and presence information is sent to the channel. When a MIX channel starts, typically when the associated MIX Service and Server start, there is a need to initialize the presence node. This is done by the XMPP server associated with the MIX channel sending out a presence probe for each channel participant, following the presence probe process specified in &rfc6121;. A presence probe MUST NOT be sent for users who have set presence preference to not sharing as specified in MIX-ANON.
|
||||
</p>
|
||||
</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 <annotate/> to the <query/> element. The <annotate/> element is qualified by the ‘urn:xmpp:mix:roster:0' namespace.</p>
|
||||
|
|
|
|||
Loading…
Reference in New Issue