moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

1.23pre2 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1206 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-09-10 17:32:19 +00:00
parent 28b99fc69f
commit c055c0f536
1 changed files with 6 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
xep-0045.xml
View File

@ -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>