mirror of https://github.com/moparisthebest/xeps
232 lines
11 KiB
XML
232 lines
11 KiB
XML
<?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'?>
|
|
<xep>
|
|
<header>
|
|
<title>MUC presence versioning</title>
|
|
<abstract>This specification defines a versioning mechanism which reduces the amount of presence traffic in a XEP-0045 MUC</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0436</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-0045</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>omnipresent-muc-affiliates</shortname>
|
|
&jcbrand;
|
|
&mwild;
|
|
<revision>
|
|
<version>0.2.0</version>
|
|
<date>2020-05-10</date>
|
|
<initials>jcb</initials>
|
|
<remark>
|
|
<p>Incorporate feedback from the standards list</p>
|
|
<ul>
|
|
<li>Create a separate tag for sending the version number.</li>
|
|
<li>Include a reset token.</li>
|
|
<li>Remove the "Additional measures" section and merge parts into "Requirements".</li>
|
|
<li>Mandate that presences are always sent for affiliated users.</li>
|
|
</ul>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1.0</version>
|
|
<date>2020-05-05</date>
|
|
<initials>XEP Editor (jsc)</initials>
|
|
<remark>Accepted by vote of Council on 2020-04-01.</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.1</version>
|
|
<date>2020-03-30</date>
|
|
<initials>jcb</initials>
|
|
<remark><p>First draft</p></remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<p>
|
|
Many modern-day non-XMPP groupchat implementations have discarded the metaphor of physical presence inside a room that a user must enter and exit, as implemented by &xep0045;.
|
|
The newer &xep0369; has therefore made presence subscriptions optional.
|
|
</p>
|
|
<p>
|
|
Often it no longer makes sense for a chat service to require that a user is "present" in order for them to be addressed by other occupants or to receive messages,
|
|
especially if the chat implementation will inform you out-of-band, for example via push notifications or email.
|
|
The notion of "room presence" is therefore less relevant than before, and in some cases can be done away with entirely.
|
|
</p>
|
|
<p>
|
|
Broadcasting all XEP-0045 MUC participants' presences to one another scales quadratically (O(n^2)) and can greatly increase the amount of network traffic,
|
|
for potentially negligable gain.
|
|
</p>
|
|
<p>
|
|
Even though the metaphorical concept of presence inside a room might no longer be relevant for a groupchat implementation,
|
|
<presence/> stanzas might still contain useful metadata, such as the user's affiliation or &xep0317;.
|
|
</p>
|
|
<p>
|
|
This XEP defines a versioning mechanism (similar to roster versioning in &rfc6121;) whereby the amount of presence traffic in a MUC may be greatly reduced.
|
|
</p>
|
|
</section1>
|
|
|
|
<section1 topic="How it works">
|
|
<p>
|
|
A client that supports MUC presence versioning needs to keep track and store the presence states of all MUC occupants, across multiple MUC sessions.
|
|
Similarly, a MUC service which supports presence versioning will also need to maintain a changelog of version numbers and corresponding presence states.
|
|
</p>
|
|
<p>
|
|
Before the client enters a MUC, it SHOULD use service discovery to check whether presence versioning is supported
|
|
(see <link url="#disco">determining support</link> below.).
|
|
If MUC presence versioning is supported, the client MAY include a <version> tag with a 'ver' attribute set to the last known version
|
|
inside the <{http://jabber.org/protocol/muc#user}x> tag of the <presence/> stanza, which it sends to join the MUC.
|
|
</p>
|
|
<p>
|
|
If MUC presence versioning is not supported by the server, the client MUST NOT include a 'ver' attribute.
|
|
</p>
|
|
|
|
<example caption='User specifies the last known version when seeking to enter a MUC'><![CDATA[
|
|
<presence
|
|
from='hag66@shakespeare.lit/pda'
|
|
id='n13mt3l'
|
|
to='coven@chat.shakespeare.lit/thirdwitch'>
|
|
<x xmlns='http://jabber.org/protocol/muc#user'>
|
|
<version xmlns='urn:xmpp:muc-presence-versioning:0' ver='ver16' />
|
|
</x>
|
|
</presence>
|
|
]]></example>
|
|
|
|
<p>
|
|
The MUC will return only those presences that have changed since the version indicated by the client, and in the self-presence of the joining user it will add a
|
|
<version> tag with a 'ver' attribute set to the latest version number inside the <{http://jabber.org/protocol/muc#user}x> tag.
|
|
The client must save the version number (and continuously update with never versions as they're received) and use that next time it joins the MUC.
|
|
</p>
|
|
|
|
<example caption="Service Sends New Occupant's Presence to New Occupant"><![CDATA[
|
|
<presence
|
|
from='coven@chat.shakespeare.lit/thirdwitch'
|
|
id='n13mt3l'
|
|
to='hag66@shakespeare.lit/pda'>
|
|
<x xmlns='http://jabber.org/protocol/muc#user'>
|
|
<version xmlns='urn:xmpp:muc-presence-versioning:0' ver='ver17' />
|
|
<item affiliation='member' role='participant'/>
|
|
<status code='110'/>
|
|
</x>
|
|
</presence>
|
|
]]></example>
|
|
|
|
<p>
|
|
When presence versioning is enabled, every subsequent <presence/> stanza sent by the server MUST include a new version number,
|
|
which replaces the existing one saved by the client.
|
|
</p>
|
|
</section1>
|
|
|
|
<section1 topic='Determining support' anchor='disco'>
|
|
<p>If a MUC implements presence versioning, it MUST specify the 'urn:xmpp:muc-presence-versioning:0' feature in its service discovery information features,
|
|
as specified in &xep0030;.</p>
|
|
<example caption='Client queries for information about a specific MUC'><![CDATA[
|
|
<iq type='get'
|
|
from='romeo@montague.example/orchard'
|
|
to='room@muc.shakespeare.example'
|
|
id='info1'>
|
|
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
|
</iq>]]></example>
|
|
|
|
<example caption='The MUC advertises support for presence versioning'><![CDATA[
|
|
<iq type='result'
|
|
to='romeo@montague.example/home'
|
|
from='room@muc.shakespeare.example'
|
|
id='info1'>
|
|
<query xmlns='http://jabber.org/protocol/disco#info'>
|
|
...
|
|
<feature var='urn:xmpp:muc-presence-versioning:0'/>
|
|
...
|
|
</query>
|
|
</iq>]]></example>
|
|
</section1>
|
|
|
|
<section1 topic='Requirements' anchor='requirements'>
|
|
<section2 topic='Always broadcast presence for affiliated users' anchor='affiliate-presence'>
|
|
<p>
|
|
A MUC that supports presence versioning MUST broadcast presence for all affiliated users, including those who are currently 'unavailable'.
|
|
<cite>XEP-0045</cite> documents the status code '102', which is used to indicate that a MUC shows unavailable members.
|
|
</p>
|
|
<p>
|
|
The only exception is when a MUC has been explicitly configured to only broadcast presence from occupants above a certain affiliation,
|
|
(see the <link url='https://xmpp.org/extensions/xep-0045.html#enter-pres'>presence broadcast</link> section of <cite>XEP-0045</cite>).
|
|
</p>
|
|
<p>
|
|
In order for a user to permanently join a room, and therefore become affiliated so that they are included in presence broadcasts,
|
|
they MAY be allowed to register themselves as members in the MUC.
|
|
<cite>XEP-0045</cite> describes in <link url='https://xmpp.org/extensions/xep-0045.html#register'>section 7.10 "Registering with a Room</link>
|
|
how a user may register themselves with a room, thereby receiving the "member" affiliation and having their preferred nickname reserved in that room.
|
|
</p>
|
|
</section2>
|
|
|
|
<section2 topic="Include a reset token when the client's version number has expired" anchor='reset-token'>
|
|
<p>
|
|
If a MUC receives a presence version number that's so old, that it no longer has the corresponding state available,
|
|
it MUST include a <reset> token in the first <presence> stanza it sends (regardless of whom in the MUC the presence relates to).
|
|
The first presence stanza MAY be from the MUC itself (as shown in the example below).
|
|
Afterwards, the MUC MUST then send all presences (including 'unavailable' for affiliated users) as if the client is starting from a blank slate.
|
|
</p>
|
|
|
|
<example caption="Service Sends a Reset Token"><![CDATA[
|
|
<presence from='coven@chat.shakespeare.lit'
|
|
id='r3s3t-m3'
|
|
to='hag66@shakespeare.lit/pda'>
|
|
<x xmlns='http://jabber.org/protocol/muc#user'>
|
|
<reset xmlns='urn:xmpp:muc-presence-versioning:0' ver='ver36' />
|
|
</x>
|
|
</presence>
|
|
]]></example>
|
|
</section2>
|
|
</section1>
|
|
|
|
<section1 topic='Business Rules' anchor='rules'>
|
|
<p>
|
|
Even if the client did not include a <version> tag with a 'ver' attribute in its "join" <presence/> stanza,
|
|
the server SHOULD still return a <version> tag with 'ver' attribute (set to the latest version number)
|
|
on all relevant <presence/> stanzas.
|
|
This allows clients to bootstrap MUC presence versioning without having to do a service discovery query first.
|
|
</p>
|
|
<p>
|
|
If the client has not yet saved a presence version number and the corresponding presence states,
|
|
then it MUST bootstrap presence versioning by sending a 'ver' attribute set to the empty string (i.e., ver="").
|
|
</p>
|
|
|
|
<p>
|
|
In some cases, the presence states being kept track of by the MUC service MAY be reduced to a minimum of only two states, 'available' and 'unavailable'.
|
|
This can drastically reduce the number of states the server needs to keep track off, at the cost of not allowing users to provide more fine-grained
|
|
reporting of their level of availability.
|
|
</p>
|
|
</section1>
|
|
|
|
<section1 topic="Security Considerations">
|
|
<p>
|
|
The MUC service should strip the <version> tag from the user's <presence> before relaying it to other occupants,
|
|
to avoid leaking information on when last the user joined the MUC.
|
|
</p>
|
|
</section1>
|
|
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>None.</p>
|
|
</section1>
|
|
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
<section2 topic='Protocol Namespaces' anchor='ns'>
|
|
<p>The ®ISTRAR; includes 'urn:xmpp:muc-presence-versioning:0' in its registry of protocol namespaces (see &NAMESPACES;).</p>
|
|
<ul>
|
|
<li>urn:xmpp:muc-presence-versioning:0</li>
|
|
</ul>
|
|
</section2>
|
|
<section2 topic='Protocol Versioning' anchor='registrar-versioning'>
|
|
&NSVER;
|
|
</section2>
|
|
</section1>
|
|
</xep>
|