Merge branches 'feature/xep-0045', 'feature/xep-0308' and 'feature/xep-0184'

xep-0045.xml

@@ -45,6 +45,12 @@
   </schemaloc>
   <registry/>
   &stpeter;
+  <revision>
+    <version>1.32.0</version>
+    <date>2019-05-15</date>
+    <initials>gl</initials>
+    <remark><p>Remove Group Chat 1.0 compatibility due to operational issues.</p></remark>
+  </revision>
   <revision>
     <version>1.31.2</version>
     <date>2018-07-31</date>
@@ -515,7 +521,7 @@
   </revision>
 </header>
 <section1 topic='Introduction' anchor='intro'>
-  <p>Traditionally, instant messaging is thought to consist of one-to-one chat rather than many-to-many chat, which is called variously "groupchat" or "text conferencing". Groupchat functionality is familiar from systems such as Internet Relay Chat (IRC) and the chatroom functionality offered by popular consumer IM services. The Jabber/XMPP community developed and implemented a basic groupchat protocol as long ago as 1999. That "groupchat 1.0" (GC) protocol provided a minimal feature set for chat rooms but was rather limited in scope. This specification (Multi-User Chat or MUC) builds on the older groupchat 1.0 protocol in a backwards-compatible manner but provides advanced features such as invitations, room moderation and administration, and specialized room types.</p>
+  <p>Traditionally, instant messaging is thought to consist of one-to-one chat rather than many-to-many chat, which is called variously "groupchat" or "text conferencing". Groupchat functionality is familiar from systems such as Internet Relay Chat (IRC) and the chatroom functionality offered by popular consumer IM services. The Jabber/XMPP community developed and implemented a basic groupchat protocol as long ago as 1999. That "groupchat 1.0" (GC) protocol provided a minimal feature set for chat rooms but was rather limited in scope. This specification (Multi-User Chat or MUC) is not compatible to the groupchat 1.0 protocol, but provides advanced features such as invitations, room moderation and administration, and specialized room types.</p>
 </section1>
 
 <section1 topic='Scope' anchor='scope'>
@@ -534,7 +540,7 @@
 </section1>
 
 <section1 topic='Requirements' anchor='reqs'>
-  <p>This document addresses the minimal functionality provided by Jabber-based multi-user chat services that existed in 2002 when development of MUC began. For the sake of backwards-compatibility, this document uses the original groupchat 1.0 protocol for this baseline functionality, with the result that:</p>
+  <p>This document addresses the minimal functionality provided by Jabber-based multi-user chat services that existed in 2002 when development of MUC began. This design is based on the original groupchat 1.0 protocol, with the result that:</p>
   <ul>
     <li>Each room is identified as a "room JID" &ROOMJID; (e.g., &lt;jdev@conference.jabber.org&gt;), where "room" is the name of the room and "service" is the hostname at which the multi-user chat service is running.</li>
     <li>Each occupant in a room is identified as an "occupant JID" &OCCUPANTJID;, where "nick" is the room nickname of the occupant as specified on entering the room or subsequently changed during the occupant's visit.</li>
@@ -579,7 +585,7 @@
       <di><dt>Ban</dt><dd>To remove a user from a room such that the user is not allowed to re-enter the room (until and unless the ban has been removed). A banned user has an affiliation of "outcast".</dd></di>
       <di><dt>Bare JID</dt><dd>The &lt;user@host&gt; by which a user is identified outside the context of any existing session or resource; contrast with Full JID and Occupant JID.</dd></di>
       <di><dt>Full JID</dt><dd>The &lt;user@host/resource&gt; by which an online user is identified outside the context of a room; contrast with Bare JID and Occupant JID.</dd></di>
-      <di><dt>GC</dt><dd>The minimal "groupchat 1.0" protocol developed within the Jabber community in 1999; MUC is backwards-compatible with GC.</dd></di>
+      <di><dt>GC</dt><dd>The minimal "groupchat 1.0" protocol developed within the Jabber community in 1999; Old versions of MUC were backwards-compatible with GC.</dd></di>
       <di><dt>History</dt><dd>A limited number of message stanzas sent to a new occupant to provide the context of current discussion.</dd></di>
       <di><dt>Invitation</dt><dd>A special message sent from one user to another asking the recipient to join a room; the invitation can be sent directly (see &xep0249;) or mediated through the room (as described under <link url='#invite'>Inviting Another User to a Room</link>).</dd></di>
       <di><dt>IRC</dt><dd>Internet Relay Chat.</dd></di>
@@ -1397,15 +1403,22 @@
   </section2>
 
   <section2 topic='Entering a Room' anchor='enter'>
-    <section3 topic='Groupchat 1.0 Protocol' anchor='enter-gc'>
+    <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. 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>
+      <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>
-      <example caption='User Seeks to Enter a Room (groupchat 1.0)'><![CDATA[
+
+      <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'
+    id='n13mt3l'
-    to='coven@chat.shakespeare.lit/thirdwitch'/>
+    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 +1430,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 +1903,31 @@
         </tr>
       </table>
     </section3>
+    <section3 topic='Groupchat 1.0 Protocol' anchor='enter-gc'>
+      <p>In the old groupchat 1.0 protocol, entering a room 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>
+      <p>This behavior can not be distinguished from a presence update from a MUC-supporting client that was desynchronized from the room. Treating this as a groupchat 1.0 join will mask the error and leave the client in a partially-synchronized state. Therefore, starting with version 1.32 of this specification, it is RECOMMENDED that a service receiving a &lt;presence&gt; without an &lt;x&gt; element from a non-occupant full-JID responds with an explicit kick to that client. The kick MUST contain the status codes 110 (occupant's presence), 307 (kick), and 333 (kick due to technical problems).</p>
+      <example caption='Service Response to groupchat 1.0 join / non-occupant presence update'><![CDATA[
+<presence
+    from='coven@chat.shakespeare.lit/thirdwitch'
+    to='hag66@shakespeare.lit/pda'
+    type='unavailable'>
+  <x xmlns='http://jabber.org/protocol/muc#user'>
+    <item affiliation='none' role='none'>
+      <reason>You are not in the room.</reason>
+    </item>
+    <status code='110'/>
+    <status code='307'/>
+    <status code='333'/>
+  </x>
+</presence>
+]]></example>
+</section3>
 
   </section2>
 

xep-0184.xml

@@ -27,6 +27,12 @@
   </schemaloc>
   &stpeter;
   &hildjj;
+  <revision>
+    <version>1.3.0</version>
+    <date>2019-05-15</date>
+    <initials>gl</initials>
+    <remark><p>Suggest a message type to use for replies.</p></remark>
+  </revision>
   <revision>
     <version>1.2</version>
     <date>2011-03-01</date>
@@ -204,6 +210,7 @@
 </message>
 ]]></example>
   <p>When the recipient sends an ack message, it SHOULD ensure that the message stanza contains only one child element, namely the &lt;received/&gt; element qualified by the 'urn:xmpp:receipts' namespace. In addition, it SHOULD include an 'id' attribute that echoes the 'id' attribute of the content message. Naturally, intermediate entities might add other extension elements to the message when routing or delivering the receipt message, e.g., a &lt;delay/&gt; element as specified in &xep0203;.</p>
+  <p class='box'>Note: It is a good practice to use the same message type as the message that requested the receipt, however a client SHOULD also accept receipts with a different message type. When sending a Receipt for a type='groupchat' message (which is NOT RECOMMENDED), the Receipt must be sent to the bare JID of the room and not to the full JID of the sender.</p>
 </section1>
 
 <section1 topic='Security Considerations' anchor='security'>

xep-0308.xml

@@ -21,6 +21,12 @@
   <supersededby/>
   <shortname>message-correct</shortname>
   &ksmith;
+  <revision>
+    <version>1.1.0</version>
+    <date>2019-05-15</date>
+    <initials>kis, gl</initials>
+    <remark><p>Clear up confusion about subsequent corrections and ids (it's the payloads getting replaced, not the message identity). Allow corrections from the bare JID unless for group chats.</p></remark>
+  </revision>
   <revision>
     <version>1.0</version>
     <date>2013-04-08</date>
@@ -96,9 +102,10 @@
   <p>To deal with multiple payloads, the sender MUST re-send the entire stanza, only altering id and the payloads being corrected and adding the 'replace' payload. It is expected that the receiver SHOULD then treat the new stanza as complete replacement for all the payloads received in the original stanza.</p>
   <p>The Sender MUST NOT include a correction for a message with non-messaging payloads. For example, a sender MUST NOT include a correction for a roster item exchange request or a file transfer part.</p>
   <p>A single message may be corrected multiple times by subsequent edits.</p>
-  <p>A correction MUST only be allowed when both the original message and correction are received from the same full-JID.</p>
+  <p>A correction MUST only be allowed when both the original message and correction originate from the same sender<note>In direct conversations, this means the bare-JID must match the original bare-JID, in MUCs and MUC-PMs the correction's full-JID must match the original full-JID, and the recipient needs to ensure that the real bare JID of the sending occupant didn't change in between, e.g. by keeping track of leave/join presences.</note>.</p>
   <p>While it's not possible to prevent this protocol from being used in such a way, it is not intended that it provides a way to continue expanding a previous message indefinitely and clients, in as much as it is sensible, should present use of this extension only for correction rather than for providing a continuous stream, for which &xep0301; can be used instead.</p>
-  <p>Correction MUST only be used to change the details of a stanza (e.g. the message body) and not to change the nature of the stanza (e.g. correction MUST NOT be used to turn a chat message into a pubsub notification)</p>
+  <p>If the same message is to be corrected several times, the id of the original message is used in each case (e.g. If a message of id 1 is corrected by a message of id 2, a subsequent correction should correct 1, not 2).</p>
+  <p>Correction MUST only be used to change the logical content details of a stanza (e.g. the message body) and not to change the nature of the stanza or its metadata (e.g. correction MUST NOT be used to turn a chat message into a pubsub notification). Where a correction stanza includes metadata, for example stanza or MAM ids, these are properties of the correction stanza, and do not correct aspects of the original stanza.</p>
   <p>While it is possible to use this protocol to correct messages older than the most recent received from a full JID, such use is out of scope for this document and support for this SHOULD NOT be assumed without further negotiation.</p>
 </section1>
 <section1 topic='Security Considerations' anchor='security'>