From 4a71e3b82b6e15c39051d3295bfaf65cc223c37e Mon Sep 17 00:00:00 2001 From: Kim Alvefur Date: Wed, 17 Apr 2019 22:41:32 +0200 Subject: [PATCH] XEP-0045: Move section about GC 1.0 further down It's weird that the first thing you see under "Entering a room" is how to do it in the old way, instead of the new way, which might mislead implementers and make them miss the new way entirely. --- xep-0045.xml | 39 +++++++++++++++++++++------------------ 1 file changed, 21 insertions(+), 18 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index 048675d9..ce60cd8e 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -1397,15 +1397,22 @@ - -

In order to participate in the discussions held in a multi-user chat room, a user MUST first become an occupant by entering the room. In the old groupchat 1.0 protocol, this was done by sending presence with no 'type' attribute to &OCCUPANTJID;, where "room" is the room ID, "service" is the hostname of the chat service, and "nick" is the user's desired nickname within the room:

- +

In order to participate in the discussions held in a multi-user chat room, a user MUST first become an occupant by entering the room.

+ +

MUC clients MUST signal their ability to speak the MUC protocol by including in the initial presence stanza an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace (note the absence of the '#user' fragment):

+ + id='n13mt3l' + to='coven@chat.shakespeare.lit/thirdwitch'> + + ]]> +

In this example, a user with a full JID of "hag66@shakespeare.lit/pda" has requested to enter the room "coven" on the "chat.shakespeare.lit" chat service with a room nickname of "thirdwitch".

+

Note: The presence stanza used to join a room MUST NOT possess a 'type' attribute, i.e., it must be available presence. For further discussion, see the Presence business rules.

+

If the user does not specify a room nickname (note the bare JID on the 'from' address in the following example), the service MUST return a &badjid; error:

-]]> -

Note: The presence stanza used to join a room MUST NOT possess a 'type' attribute, i.e., it must be available presence. For further discussion, see the Presence business rules.

- - - -

Compliant multi-user chat services MUST accept the foregoing as a request to enter a room from any client that knows either the groupchat 1.0 protocol or the multi-user chat (MUC) protocol; however, MUC clients SHOULD signal their ability to speak the MUC protocol by including in the initial presence stanza an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace (note the absence of the '#user' fragment):

- - - ]]>

Before attempting to enter the room, a MUC-compliant client SHOULD first discover its reserved room nickname (if any) by following the protocol defined in the Discovering Reserved Room Nickname section of this document.

When a MUC service receives an <x/> tagged join stanza from an already-joined client (as identified by the client's full JID), the service should assume that the client lost its synchronization, and therefore it SHOULD send exactly the same stanzas to the client as if it actually just joined the MUC. The server MAY also send a presence update to the other participants according to the received join presence.

@@ -1903,6 +1897,15 @@ + +

In the old groupchat 1.0 protocol, this was done by sending presence with no 'type' attribute to &OCCUPANTJID;, where "room" is the room ID, "service" is the hostname of the chat service, and "nick" is the user's desired nickname within the room:

+ +]]> +