moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00
Code Issues Releases Wiki Activity

XEP-0045: Move section about GC 1.0 further down

Browse Source 
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.
This commit is contained in:
Kim Alvefur 2019-04-17 22:41:32 +02:00 committed by Georg Lukas
parent 11bf5c82fb
commit 4a71e3b82b
1 changed files with 21 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
xep-0045.xml
View File

@ -1397,15 +1397,22 @@
</section2>
<section2 topic='Entering a Room' anchor='enter'>
<section3 topic='Groupchat 1.0 Protocol' anchor='enter-gc'>
<p>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:</p>
<example caption='User Seeks to Enter a Room (groupchat 1.0)'><![CDATA[
<section3 topic='Basic MUC Protocol' anchor='enter-muc'>
<p>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. </p>
<p>MUC clients MUST signal their ability to speak the MUC protocol by including in the initial presence stanza an empty &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc' namespace (note the absence of the '#user' fragment):</p>
<example caption='User Seeks to Enter a Room (Multi-User Chat)'><![CDATA[
<presence
from='hag66@shakespeare.lit/pda'
id='ng91xs69'
to='coven@chat.shakespeare.lit/thirdwitch'/>
id='n13mt3l'
to='coven@chat.shakespeare.lit/thirdwitch'>
<x xmlns='http://jabber.org/protocol/muc'/>
</presence>
]]></example>
<p>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".</p>
<p>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 <link url='#bizrules-presence'>Presence</link> business rules.</p>
<p>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:</p>
<example caption='No Nickname Specified'><![CDATA[
<presence
@ -1417,19 +1424,6 @@
<jid-malformed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
]]></example>
<p>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 <link url='#bizrules-presence'>Presence</link> business rules.</p>
</section3>
<section3 topic='Basic MUC Protocol' anchor='enter-muc'>
<p>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 &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc' namespace (note the absence of the '#user' fragment):</p>
<example caption='User Seeks to Enter a Room (Multi-User Chat)'><![CDATA[
<presence
from='hag66@shakespeare.lit/pda'
id='n13mt3l'
to='coven@chat.shakespeare.lit/thirdwitch'>
<x xmlns='http://jabber.org/protocol/muc'/>
</presence>
]]></example>
<p>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 <link url='#reservednick'>Discovering Reserved Room Nickname</link> section of this document.</p>
<p>When a MUC service receives an &lt;x/&gt; 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.</p>
@ -1903,6 +1897,15 @@
</tr>
</table>
</section3>
<section3 topic='Groupchat 1.0 Protocol' anchor='enter-gc'>
<p>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:</p>
<example caption='User Seeks to Enter a Room (groupchat 1.0)'><![CDATA[
<presence
from='hag66@shakespeare.lit/pda'
id='ng91xs69'
to='coven@chat.shakespeare.lit/thirdwitch'/>
]]></example>
</section3>
</section2>