1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-27 19:52:18 -05:00

Editorial (Georg)

Sort out MIX Proxy and Presence Update
This commit is contained in:
Steve Kille 2016-12-21 09:10:33 +00:00
parent 8930133cb1
commit 9e67e42df1

View File

@ -171,6 +171,7 @@
</section1>
<section1 topic='Concepts' anchor='concepts'>
<section2 topic="Core Concepts" anchor="concepts-core">
<p>The following concepts underlie the design of MIX.</p>
<ol>
<li>MIX channels (roughly equivalent to MUC rooms) are hosted on one or more MIX domains, (examples: 'mix.example.com'; 'conference.example.com'; 'talk.example.com'), which are discoverable through &xep0030;. Each channel on a MIX service may then be discovered and queried.</li>
@ -187,7 +188,9 @@
<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 MIX servers. 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>
</ol>
</section2>
<section2 topic="MIX and PubSub" anchor="concepts-pubsub">
<p>MIX is based upon domains providing a MIX service, such as 'mix.shakespeare.example'. Note that although PubSub communication is used, a domain used for MIX is a MIX domain and not a standard &xep0060; domain. Like MUC, there is no requirement on the naming of these domains; the label 'mix' and the fact that it is a subdomain of a 'shakespeare.example' service are purely for example.</p>
<p>Every MIX channel is an addressable PubSub service (with additional MIX semantics) that will be addressed using a bare JID by other XMPP entities, for example coven@mix.shakespeare.example. While &xep0060; is used as the basis for the MIX model, MIX uses standard presence and groupchat messages to provide an interface to the MIX service that does not expose PubSub protocol for many of the more common functions.
@ -1173,15 +1176,30 @@ the participant is not be subscribed to all nodes associated with the channel (i
</p>
</section3>
<section3 topic="Coming Online: Obtaining Presence" anchor="usecase-obtaining-presence">
<section3 topic="Client Coming Online and Obtaining Presence from MIX Proxy" 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 users subscribing to this presence node. The user's server will then pass this presence information on to all online clients. When a client goes offline, it will lose synchronization with the presence node. When the client comes online, the clients server will send a directed presence stanza to the MIX channel. This will happen as a consequence of the MIX channel being in the user's roster and the MIX channel sending a presence update to the MIX channel. When the MIX channel adds or modifies presence for a client to the roster, this presence change will be distributed to all users subscribing to the presence node.
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.
</p>
<p>
When the full JID of a client is added to the MIX channel presence node and that full JID is not in the presence list, the MIX channel will send to the client presence for all of the items in the presence node using standard presence stanzas. This will give the client full current presence.
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.
</p>
</section3>
<section3 topic="MIX Proxy Presence Update" anchor="usecase-proxy-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.
</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.
</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.
</p>
</section3>
<section3 topic="Determining Real JIDs" anchor="usecase-real-jids">
<p>
Presence information will provide a MIX client with the nicks and anonymized proxy JIDs for participants. For JID visible rooms, the user may look up the real JID using the "urn:xmpp:mix:nodes:jidmap" node. The items in this node are identified by proxy JID, and so the real JID can be retrieved using a straightforward PubSub query. While a user may subscribe to the jidmap node, it is more likely to be used to directly look up JIDs as and when needed.
@ -1990,6 +2008,10 @@ A client creates a channel by sending a simple request to the MIX service. A c
</iq>
]]></example>
<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.
</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 &lt;deactivate&gt; element to instruct the MIX proxy to activate the client.
</p>