The service then SHOULD forward the request to the room moderator(s) as described in the Approving Voice Requests section of this document.
+The service then proceeds as described in the Approving Voice Requests section of this document.
The service MUST remove the kicked occupant by sending a presence stanza of type "unavailable" to each kicked occupant, including status code 307 in the extended presence information, optionally along with the reason (if provided) and the bare JID of the user who initiated the kick.
The inclusion of the status code assists clients in presenting their own notification messages (e.g., information appropriate to the user's locality). The optional inclusion of the reason and actor enable the kicked user to understand why he or she was kicked, and by whom if the kicked occupant would like to discuss the matter.
After removing the kicked occupant(s), the service MUST then inform the moderator of success:
After informing the moderator, the service MUST then inform all of the remaining occupants that the kicked occupant is no longer in the room by sending presence stanzas of type "unavailable" from the individual's roomnick (&ROOMJID;) to all the remaining occupants (just as it does when occupants exit the room of their own volition), including the status code and optionally the reason and actor.
As noted in the Requesting Voice section of this document, when a service receives a request for voice from an occupant it SHOULD forward that request to the room moderator(s). To do so, the service sends a &MESSAGE; stanza to the room moderator(s), where the &MESSAGE; stanza contains a data form asking for approval or denial of the request, as shown below.
+As noted in the Requesting Voice section of this document, an occupant requests voice by sending a voice request data form to the service. The service then SHOULD use that voice request data form as the basis for a voice approval data form that it generates and sends to the room moderator(s). The voice approval data form is contained in a &MESSAGE; stanza, as shown below.
The service MUST add that bare JID to the ban list, MUST remove the outcast's nickname from the list of registered nicknames, and MUST inform the admin or owner of success:
The service MUST also remove any banned users who are in the room by sending a presence stanza of type "unavailable" to each banned occupant, including status code 301 in the extended presence information, optionally along with the reason (if provided) and the bare JID of the user who initiated the ban.
The service MUST then return the list of banned users to the admin; each item MUST include the 'affiliation' and 'jid' attributes but SHOULD NOT include the 'nick' and 'role' attributes:
After updating the ban list, the service MUST inform the admin of success:
In the context of a members-only room, the member list is essentially a "whitelist" of people who are allowed to enter the room. Anyone who is not a member is effectively banned from entering the room, even if their affiliation is not "outcast".
-In the context of an open room, the member list is simply a list of users (bare JID and reserved nick) who are registered with the room. Such users cacan appear in a room roster, have their room nickname reserved, be returned in search results or FAQ queries, and the like.
+In the context of an open room, the member list is simply a list of users (bare JID and reserved nick) who are registered with the room. Such users can appear in a room roster, have their room nickname reserved, be returned in search results or FAQ queries, and the like.
It is RECOMMENDED that only room admins have the privilege to modify the member list in members-only rooms. To do so, the admin first requests the member list by querying the room for all users with an affiliation of "member":
For any other configuration change, the room SHOULD send status code 104 so that interested occupants can retrieve the updated room configuration if desired.
@@ -5207,14 +5206,6 @@ Inform occupants that the room is now semi-anonymous -