From 37c506023373ef8c924303ac27882eba766a2f91 Mon Sep 17 00:00:00 2001 From: JC Brand Date: Sun, 10 May 2020 15:39:22 +0200 Subject: [PATCH] XEP-0436: Updates based on list feedback - Create a separate tag for sending the version number - Include a reset token - Remove the "additional measures" section and merge parts into "Requirements" - Mandate that presences are always sent for affiliated users --- xep-0436.xml | 137 ++++++++++++++++++++++++++++++++------------------- 1 file changed, 86 insertions(+), 51 deletions(-) diff --git a/xep-0436.xml b/xep-0436.xml index b7ba45e2..91801464 100644 --- a/xep-0436.xml +++ b/xep-0436.xml @@ -24,6 +24,20 @@ omnipresent-muc-affiliates &jcbrand; &mwild; + + 0.2.0 + 2020-05-10 + jcb + +

Incorporate feedback from the standards list

+
    +
  • Create a separate tag for sending the version number.
    • +
  • Include a reset token.
    • +
  • Remove the "Additional measures" section and merge parts into "Requirements".
    • +
  • Mandate that presences are always sent for affiliated users.
    • +
+ + 0.1.0 2020-05-05 @@ -48,47 +62,48 @@ The notion of "room presence" is therefore less relevant than before, and in some cases can be done away with entirely.

- 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. + 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.

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 their &xep0317;. + <presence/> stanzas might still contain useful metadata, such as the user's affiliation or &xep0317;.

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. - It also describes additional measures which may be taken to further reduce the amount of presence traffic.

- A client that supports presence versioning needs to keep track and store the presence statuses 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 presence states. + 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.

Before the client enters a MUC, it SHOULD use service discovery to check whether presence versioning is supported (see determining support below.). - If presence versioning is supported, the client MAY include a 'ver' attribute set to the last known presence version - in the <{http://jabber.org/protocol/muc}x> tag of the <presence/> stanza, which it sends to join the MUC. -

-

- If presence versioning is not supported by the server, the client MUST NOT include a 'ver' attribute. + 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.

+ If MUC presence versioning is not supported by the server, the client MUST NOT include a 'ver' attribute.

- - + + + ]]>

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 - 'ver' attribute with the latest version number on the <{http://jabber.org/protocol/muc}x> tag. The client must save the version number and use it next time it joins the MUC. + <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.

- + + @@ -104,12 +120,14 @@ ]]>

- 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. + 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.

-

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;.

+

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;.

... - + ... ]]> + + +

+ A MUC that supports presence versioning MUST broadcast presence for all affiliated users, including those who are currently 'unavailable'. + XEP-0045 documents the status code '102', which is used to indicate that a MUC shows unavailable members. +

+

+ The only exception is when a MUC has been explicitly configured to only broadcast presence from occupants above a certain affiliation, + (see the presence broadcast section of XEP-0045). +

+

+ 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. + XEP-0045 describes in section 7.10 "Registering with a Room + how a user may register themselves with a room, thereby receiving the "member" affiliation and having their preferred nickname reserved in that room. +

+ + + +

+ 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. +

+ + + + + + +]]> + + + -

If a MUC receives a presence version number that's so old, so that it no longer has the corresponding state available, it needs to send all presence statuses back to the client.

+

+ 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. +

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="").

+

- Even if the client did not include a 'ver' attribute in its "join" <presence/> stanza, the server SHOULD still set a 'ver' attribute on the relevant <presence/> stanzas. + 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.

- +

- There are a number of &xep0045; features that a client and server may decide to configure and/or implement in order to further reduce the number of presence stanzas being sent around. + 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.

- - - -

- A MUC MAY be configured to only broadcast presence from occupants above a certain affiliation, - (see the presence broadcast section of XEP-0045), - for example in a MUC where non-affiliated users are allowed to view the discussion but aren't allowed to send messages. -

- -

- This step can be taken in addition to letting users register themselves as members in the MUC. - XEP-45 describes in section 7.10 "Registering with a Room how a user may register themselves with a room, - thereby receiving the "member" affiliation and having their preferred nickname reserved in that room. -

- - - - -

- In some cases, it makes sense to reduce the number of presence statuses to only a subset, in order to reduce to total amount of states the server needs to keep track off. - In the simplest case, this would mean keeping track only of two statuses, 'available' and 'unavailable'. -

- -

- XEP-0045 documents the status code 102, which is used to indicate that a room shows unavailable members. - By also sending to newly joined users the presence stanzas of unavailable members, - it's possible to provide any necessary presence metadata of all relevant users in a groupchat and not just the currently "present" users. -

- -