1.25rc5

xep-0045.xml

@@ -47,8 +47,8 @@
   <registry/>
   &stpeter;
   <revision>
-    <version>1.25rc4</version>
+    <version>1.25rc5</version>
-    <date>in progress, last updated 2011-08-15</date>
+    <date>in progress, last updated 2011-08-16</date>
     <initials>psa</initials>
     <remark>
       <ul>
@@ -1423,7 +1423,7 @@
 
 [ ... ]
       ]]></example>
-      <p>If the user is entering a room that is non-anonymous (i.e., which informs all occupants of each occupant's full JID as shown above), the service SHOULD allow the user to enter the room but MUST also warn the user that the room is not anonymous. Subject to local security policies, this MUST be done by including a status code of "100" in the initial presence that the room sends to the new occupant:</p>
+      <p>If the user is entering a room that is non-anonymous (i.e., which informs all occupants of each occupant's full JID as shown above), the service MUST warn the user by including a status code of "100" in the initial presence that the room sends to the new occupant:</p>
       <example caption="Service Sends New Occupant's Presence to New Occupant"><![CDATA[
 <presence
     from='coven@chat.shakespeare.lit/thirdwitch'
@@ -2575,8 +2575,9 @@
     <li>modify the list of occupants who have voice in a moderated room</li>
   </ol>
   <p>These features are implemented with a request/response exchange using &lt;iq/&gt; elements that contain child elements qualified by the 'http://jabber.org/protocol/muc#admin' namespace. The examples below illustrate the protocol interactions to implement the desired functionality. (Except where explicitly noted below, any of the following administrative requests MUST be denied if the &lt;user@host&gt; of the 'from' address of the request does not match the bare JID portion of one of the moderators; in this case, the service MUST return a &forbidden; error.)</p>
+
   <section2 topic='Modifying the Room Subject' anchor='subject-mod'>
-    <p>A common feature of multi-user chat rooms is the ability to change the subject within the room. By default, only users with a role of "moderator" SHOULD be allowed to change the subject in a room (although this is configurable, with the result that a mere participant or even visitor might be allowed to change the subject, as controlled by the "muc#roomconfig_changesubject" option). The subject is changed by sending a message of type "groupchat" to the &ROOM;, where the &MESSAGE; MUST contain a &lt;subject/&gt; element that specifies the new subject but MUST NOT contain any other element (e.g., no &BODY; element or &THREAD; element).</p>
+    <p>A common feature of multi-user chat rooms is the ability to change the subject within the room. By default, only users with a role of "moderator" SHOULD be allowed to change the subject in a room (although this is configurable, with the result that a mere participant or even visitor might be allowed to change the subject, as controlled by the "muc#roomconfig_changesubject" option). The subject is changed by sending a message of type "groupchat" to the &ROOM;, where the &MESSAGE; MUST contain a &lt;subject/&gt; element that specifies the new subject but MUST NOT contain any other element (e.g., no &BODY; element or &THREAD; element). (A message with a &SUBJECT; and a &BODY; is a legitimate message, but it SHALL NOT be interpreted as a subject change.)</p>
     <example caption='Moderator Changes Subject'><![CDATA[
 <message
     from='wiccarocks@shakespeare.lit/laptop'
@@ -3490,9 +3491,9 @@
     to='coven@chat.shakespeare.lit'
     type='set'>
   <query xmlns='http://jabber.org/protocol/muc#admin'>
-    <item jid='hag66@shakespeare.lit/pda'
+    <item nick='thirdwitch'
           role='participant'/>
-    <item jid='hecate@shakespeare.lit/broom'
+    <item nick='Hecate'
           role='moderator'/>
   </query>
 </iq>
@@ -3950,7 +3951,7 @@
   </query>
 </iq>
       ]]></example>
-      <p>If the room owner cancels the initial configuration, the service SHOULD destroy the room, making sure to send unavailable presence to the room owner (see the "Destroying a Room" use case for protocol details).</p>
+      <p>If the room owner cancels the initial configuration, the service MUST destroy the room, making sure to send unavailable presence to the room owner (see the "Destroying a Room" use case for protocol details).</p>
       <p>If the room owner becomes unavailable for any reason before submitting the form (e.g., a lost connection), the service will receive a presence stanza of type "unavailable" from the owner to the owner's &ROOMJID;. The service MUST then destroy the room, sending a presence stanza of type "unavailable" from the room to the owner including a &lt;destroy/&gt; element and reason (if provided) as defined in the <link url='#destroyroom'>Destroying a Room</link> section of this document.</p>
     </section3>