moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-28 04:02:20 -05:00
Code Issues Releases Wiki Activity

XEP-0045: Business Rule for client-requested full resync

Browse Source 
As discussed on the ML [0]: When a client re-joins a MUC where the MUC
service did not notice the client leaving, the client will end up with
an incomplete list of participants and no room subject.

This patch adds a sentence to the business rules section that explicitly
requires a MUC service to send a full sync whenever it receives a MUC
join presence (as opposed to the old groupchat protocol).

In my eyes, this is only a clarification of the existing standard
definition, so we do not need to bump the version.

Georg

[0] http://mail.jabber.org/pipermail/standards/2016-June/031180.html
This commit is contained in:
Georg Lukas 2016-07-29 16:23:32 +02:00 committed by Sam Whited
parent d93f9c5fd5
commit cee524dbde
1 changed files with 1 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
xep-0045.xml
View File

@ -5536,6 +5536,7 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld
<ol start='1'>
<li><p>The presence stanza used to join a room MUST NOT possess a 'type' attribute, i.e., it must be available presence. A MUC service MUST NOT treat a presence stanza with a 'type' attribute (e.g., a presence probe) as a request to join the room.</p></li>
<li><p>The presence stanza used to exit a room MUST possess a 'type' attribute whose value is "unavailable". A MUC service MUST NOT treat a presence stanza with a 'type' attribute whose value is other than "unavailable" (e.g., a presence probe) as a request to exit the room.</p></li>
<li><p>If a MUC service receives a Basic MUC Protocol join request from a client that is already joined, it MUST treat it as a full synchronization request, and send to the client everything that would be sent to it on a normal join. The MUC service SHOULD send a presence update to the other participants if the join presence is different from the client's previous presence.</p></li>
<li><p>A MUC service MAY handle presence probes sent to the room JID &ROOMJID; or an occupant JID &OCCUPANTJID; (e.g, these might be sent by an occupant's home server to determine if the room is still online or to synchronize presence information if the user or the user's server has gone offline temporarily or has started sharing presence again, as for instance when &xep0273; is used).</p></li>
<li><p>A room MUST silently ignore unavailable presence received from a user who has a role of "none".</p></li>
<li><p>Only the MUC service itself SHOULD generate data about roles, affiliations, full JIDs, or status codes qualified by the 'http://jabber.org/protocol/muc#user' namespace (based on information the service knows about occupants, e.g., roles, or as a result of actions taken by a moderator or room administrator). A client SHOULD NOT presume to generate such information. If a MUC service receives such extended presence information from an occupant, it MUST NOT reflect it to other occupants. (A client MAY generate extended presence information qualified by the 'http://jabber.org/protocol/muc#user' namespace in order to supply a password, but naturally this is not reflected to other occupants.)</p></li>