From c055c0f536856251d64a9eb63829679c4b4c2a9c Mon Sep 17 00:00:00 2001
From: Peter Saint-Andre <stpeter@jabber.org>
Date: Mon, 10 Sep 2007 17:32:19 +0000
Subject: [PATCH] 1.23pre2

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1206 4b5297f7-1745-476d-ba37-a9c6900126ab
---
 xep-0045.xml | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/xep-0045.xml b/xep-0045.xml
index bae70104..4d8c265b 100644
--- a/xep-0045.xml
+++ b/xep-0045.xml
@@ -50,10 +50,10 @@
   <registry/>
   &stpeter;
   <revision>
-    <version>1.23pre1</version>
-    <date>in progress, updated 2007-08-20</date>
+    <version>1.23pre2</version>
+    <date>in progress, updated 2007-09-10</date>
     <initials>psa</initials>
-    <remark><p>Added outsider role, including outsider use cases and admin management of outsider role; defined "getmemberlist" room configuration option.</p></remark>
+    <remark><p>Added outsider role, including outsider use cases and admin management of outsider role; defined "getmemberlist" room configuration option; added direct invitation protoocol; corrected logic regarding admission of room owner/admin when room is full.</p></remark>
   </revision>
   <revision>
     <version>1.22</version>
@@ -1523,7 +1523,7 @@
       <p>However, if the bare JID (&BAREJID;) of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource. If a service allows more than one occupant with the same bare JID and the same room nickname, it SHOULD route in-room messages to all of the user's resources and allow all of the user's resources to send messages to the room; it is up to the implementation to determine how to appropriately handle presence from the user's resources and how to route private messages to all or only one resource (based on presence priority or some other algorithm).</p>
     </section3>
     <section3 topic='Max Users' anchor='enter-maxusers'>
-      <p>If the room has reached its maximum number of users, the service SHOULD deny access to the room and inform the user of the restriction; this is done by returning a presence stanza of type "error" specifying a &unavailable; error condition:</p>
+      <p>If the room has reached its maximum number of occupants, the service SHOULD deny access to the room and inform the user of the restriction; this is done by returning a presence stanza of type "error" specifying a &unavailable; error condition:</p>
       <example caption='Service Informs User that Room Occupant Limit Has Been Reached'><![CDATA[
 <presence
     from='darkcave@macbeth.shakespeare.lit'
@@ -1534,7 +1534,8 @@
   </error>
 </presence>
       ]]></example>
-      <p>Alternatively, the room could kick an "idle user" in order to free up space. Also, a room MUST always allow entry by a room admin or owner.</p>
+      <p>Alternatively, the room could kick an "idle user" in order to free up space.</p>
+      <p>If the room has reached its maximum number of occupants and a room admin or owner attempts to join, the room SHOULD allow the admin or owner to join, up to some reasonable number of additional occupants, which number MAY be configurable.</p>
     </section3>
     <section3 topic='Locked Room' anchor='enter-locked'>
       <p>If a user attempts to enter a room while it is "locked" (i.e., before the room creator provides an initial configuration and therefore before the room officially exists), the service MUST refuse entry and return an &notfound; error to the user:</p>