moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

Changes around presence resulting from discussion with Sam Whited about "Presence Session"

Browse Source
This commit is contained in:
Steve Kille 2016-09-05 10:05:42 +01:00
parent 70fc09d0b6
commit e0f8251c75
1 changed files with 7 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
xep-0369.xml
View File

@ -131,7 +131,9 @@
<li>&xep0313; (MAM) is used for all history access, with each node being individually addressable for MAM queries. This simplifies implementation compared to MUC (which had a specialized and rather limited history retrieval mechanism).</li>
<li>A client can achieve a 'quick resync' of a node by requesting just those changes it has not yet received, using standard MAM protocol. This solves the old MUC issue of either receiving duplicate messages when rejoining a room or potentially missing messages.</li>
<li>Because MAM is used for history, only those nodes that have a 'current value' need to store any items in them &mdash; e.g., 'urn:xmpp:mix:nodes:presence' and 'urn:xmpp:mix:nodes:subject' would store their current values (with older values being queryable through MAM), while 'urn:xmpp:mix:nodes:messages' would store no items.</li>
<li>A user's participation in a channel outlives their session. A user who is offline will not share presence within the channel, but will still be listed as an participant. This too is a significant departure from MUC.</li>
<li>A user's participation in a channel outlives their client sessions. A client which is offline will not share presence within the channel, but the associatd user will still be listed as an participant. </li>
<li>Presence is sent to all participants using bare JID, whether or not the user has an online client. </li>
<li>Online clients MAY register presence, which is then shared with participants who have subscribed to presence.</li>
<li>MIX decouples addressing of occupants 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 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>
@ -159,7 +161,7 @@
<section2 topic="Advanced Delivery to Online Users" anchor="concepts-online-delivery">
<p>
It may be desirable in some situtations to provide different service to different clients. For example, a mobile client may participate in a smaller set of MIX channels than a desktop client. This needs support from the server to which the client connects, so that MIX client and the connected server can negotiate which channels to send. This is not supported by the core MIX specification, but it is anticipated that this will be supported by another specification.
It may be desirable in some situations to provide different service to different clients. For example, a mobile client may participate in a smaller set of MIX channels than a desktop client. This needs support from the server to which the client connects, so that MIX client and the connected server can negotiate which channels to send. This is not supported by the core MIX specification, but it is anticipated that this will be supported by another specification.
This may be &xep0376; (PAM) or a new specification similar to PAM developed specifically in support of MIX.
</p>
</section2>
@ -402,7 +404,7 @@
]]></example>
<p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'.
</p>
<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 adverstize support for generic &xep0060;, as although MIX makes use of PubSub it is not a generic PubSub service.</p>
<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'>
@ -1075,7 +1077,7 @@
</iq>
]]></example>
<p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'. THe field with var='muc-mirror' is the value of which is the mirrored MUC domain's JID. </p>
<p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'. The field with var='muc-mirror' is the value of which is the mirrored MUC domain's JID. </p>
<p>Where a client supporting both MIX and MUC is given a reference to a MUC room, it is desirable that the client can determine the MIX channel and join using MIX. This is achieved by an equivalent extension to MUC service discover.</p>
@ -1104,7 +1106,7 @@
</iq>
]]></example>
<p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'. THe field with var='mix-mirror' is the value of which is the mirrored MIX domain's JID. </p>
<p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'. The field with var='mix-mirror' is the value of which is the mirrored MIX domain's JID. </p>