Alternatively, the room could kick an "idle user" in order to free up space (whether the definition of "idle user" is up to the implementation).
+Alternatively, the room could kick an "idle user" in order to free up space (where the definition of "idle user" is up to the implementation).
If the room has reached its maximum number of occupants and a room admin or owner attempts to join, the room MUST allow the admin or owner to join, up to some reasonable number of additional occupants; this helps to prevent denial of service attacks caused by stuffing the room with non-admin users.
@@ -1754,7 +1754,7 @@After the room has optionally sent the discussion history to the new occupant, it SHALL send the current room subject (if any). This is a &MESSAGE; stanza from the room itself (or from the room JID of the entity that set the subject), with a &SUBJECT; element but no &BODY; element, as shown in the following example.
+After the room has optionally sent the discussion history to the new occupant, it SHALL send the current room subject. This is a &MESSAGE; stanza from the room itself (or from the room JID of the entity that set the subject), with a &SUBJECT; element but no &BODY; element, as shown in the following example.
After the room has optionally sent the room subject, it SHALL begin to send live messages, presence changes, occupant "joins" and "leaves", and other real-time traffic ot the new occupant, as described in other sections of this document.
+After the room has sent the room subject, it SHALL begin to send live messages, presence changes, occupant "joins" and "leaves", and other real-time traffic ot the new occupant, as described in other sections of this document.