<abstract>This specification defines an XMPP protocol extension for multi-user text chat, whereby multiple XMPP users can exchange messages in the context of a room or channel, similar to Internet Relay Chat (IRC). In addition to standard chatroom features such as room topics and invitations, the protocol defines a strong room control model, including the ability to kick and ban users, to name room moderators and administrators, to require membership or passwords in order to join the room, etc.</abstract>
<remark><p>Added more examples of the reason element; removed mention of nick inclusion with regard to ban lists; added denial of service considerations.</p></remark>
<li>Corrected logic regarding admission of room owner/admin when room is full</li>
<li>Defined service discovery extension field for associated LDAP group</li>
<li>Specified that room config fields can be listed in extended room information</li>
<li>Specified message format for affiliation change notifications if user is not in the room</li>
<li>Added example showing use of Result Set Management</li>
<li>Recommended inclusion of MUC child element in presence errors</li>
<li>Described use of ThreadID for continuity between one-to-one chat and multi-user chat, including definition of thread attribute for continue element in invitations.</li>
<li>Clarified that inclusion of MUC extension in room join/create request triggers Data Forms flow but that absence of MUC extension leads to automatic room creation for backwards compatibility with older groupchat 1.0 protocol.</li>
<li>Specified use of <not-acceptable/> error on nickname change if nicks are locked down.</li>
<li>Required clients to discover room configuration prior to entering room and specified related security considerations, including use of privacy-related status codes 170, 171, 172, 173, and 174.</li>
<li>Specified use of <not-acceptable/> error if room configuration options cannot be processed or violate service policies.</li>
<li>Made explicit that roomnicks must not consist only of spaces.</li>
<li>Moved all service discovery use cases into dedicated section.</li>
<li>Specified that changing role to moderator upon affiliation change to admin or owner is recommended, not required.</li>
<li>Added internationalization consideration about localization of field labels for various data forms.</li>
<li>Specified that implementations may persist roles across visits and should do so for moderated rooms.</li>
<li>Added protocol and service discovery feature for requesting a unique room name prior to room creation.</li>
<li>Further clarified nature of reserved room nicknames and nickname lockdown.</li>
<li>Defined data forms for requesting voice and approving voice requests.</li>
<li>Added multiple invitee example for XMPP URI.</li>
<li>Clarified order of presence, discussion history, etc.</li>
<li>Added status codes for occupant's own roomnick, service-modified roomnick, and warning that room discussion is publicly logged.</li>
<li>Clarified privacy and anonymity considerations regarding room logging and non-anonymous rooms.</li>
</ul>
</remark>
</revision>
<revision>
<version>1.20</version>
<date>2005-09-08</date>
<initials>psa</initials>
<remark><p>Harmonized ability to kick and ban users, and clarified that a user cannot be kicked or banned by a moderator or admin with a lower affiliation.</p></remark>
</revision>
<revision>
<version>1.19</version>
<date>2005-04-21</date>
<initials>psa</initials>
<remark><p>Specified how to send multiple invitations simultaneously; corrected some errors regarding consistency of affiliation state changes; changed message events prohibition from MUST NOT to SHOULD NOT; corrected error handling related to the #traffic disco node; allowed <password/> as a child of <destroy/>; changed max users error from ¬allowed; to &unavailable;; specified that the maxchars attribute counts characters in complete XML stanzas; added disco features for FORM_TYPEs; defined registry for status codes; split Create Instant Room into separate use case for protocol compliance purposes; adjusted XML schemas to reflect the foregoing changes; re-wrote the introduction; clarified small textual matters throughout.</p></remark>
</revision>
<revision>
<version>1.18</version>
<date>2004-11-02</date>
<initials>psa</initials>
<remark><p>Corrected several errors in the affiliation state chart and in the examples (wrong FORM_TYPE values); mentioned /me command.</p></remark>
</revision>
<revision>
<version>1.17</version>
<date>2004-10-04</date>
<initials>psa</initials>
<remark><p>Added text about allowable extension namespaces and related service discovery mechanisms; specified well-known service discovery nodes; added conformance terms to clarify some descriptions; modified affiliation state chart to allow more flexible state changes; per list dicussion, added ability to convert a one-to-one chat into a conference, including sending of history; specified error to use when max users limit is reached; specified form for admin approval of user registration requests and modified FORM_TYPE from http://jabber.org/protocol/muc#user to http://jabber.org/protocol/muc#register; modified FORM_TYPE for room configuration from http://jabber.org/protocol/muc#owner to http://jabber.org/protocol/muc#roomconfig.</p></remark>
</revision>
<revision>
<version>1.16</version>
<date>2004-06-30</date>
<initials>psa</initials>
<remark><p>Added example and registry submission for service discovery extension.</p></remark>
</revision>
<revision>
<version>1.15</version>
<date>2004-06-24</date>
<initials>psa</initials>
<remark><p>Removed jabber:iq:browse references; clarified order of presence stanzas sent to new occupant on entering room; specified format of in-room messages (type='groupchat', from='room@service'); clarified allowable attributes in various list-related operations; made admin/owner revocation text and examples consistent with state chart; clarified ownership revocation conflict scenarios; changed the 'muc#roomconfig_inviteonly' field to 'muc#roomconfig_membersonly'; changed attribute order in examples to match XML canonicalization rules; corrected several errors in the schemas.</p></remark>
</revision>
<revision>
<version>1.14</version>
<date>2004-05-03</date>
<initials>psa</initials>
<remark><p>Corrected discovery of registered roomnicks; added note about error to return if nicks are locked down.</p></remark>
</revision>
<revision>
<version>1.13</version>
<date>2004-03-31</date>
<initials>psa</initials>
<remark><p>Fixed an error in the muc#user schema.</p></remark>
</revision>
<revision>
<version>1.12</version>
<date>2004-03-01</date>
<initials>psa</initials>
<remark><p>Corrected a few errors in the examples; added IQ results in order to clarify workflows.</p></remark>
</revision>
<revision>
<version>1.11</version>
<date>2004-02-05</date>
<initials>psa</initials>
<remark><p>Clarified JID matching rules (same as for privacy lists in XMPP IM).</p></remark>
</revision>
<revision>
<version>1.10</version>
<date>2004-01-07</date>
<initials>psa</initials>
<remark><p>Added XMPP error handling; fully specified all conformance terms.</p></remark>
</revision>
<revision>
<version>1.9</version>
<date>2003-12-14</date>
<initials>psa</initials>
<remark><p>Removed protocol for requesting voice in a moderated room (should be performed using Ad-Hoc Commands).</p></remark>
</revision>
<revision>
<version>1.8</version>
<date>2003-12-04</date>
<initials>psa</initials>
<remark><p>Added protocol for requesting voice in a moderated room; added (informational) mapping of IRC commands to MUC protocols.</p></remark>
</revision>
<revision>
<version>1.7</version>
<date>2003-10-21</date>
<initials>psa</initials>
<remark><p>Added room configuration option for restricting presence broadcast to certain roles.</p></remark>
</revision>
<revision>
<version>1.6</version>
<date>2003-10-03</date>
<initials>psa</initials>
<remark><p>Added history management protocol on entering a room.</p></remark>
<remark><p>Specified that ban occurs by JID, not roomnick; allowed privileged users to send messages to the room even if not present in the room; added note that service should remove occupant if a delivery-related stanza error occurs; enabled user to disco the room in order to discover registered roomnick; specified that "banning" by domain or regex is a service-level configuration matter and therefore out of scope for MUC; specified that role should be decremented as appropriate if affiliation is lowered; added some clarifying text to room creation workflow; added implementation note about sending an out-of-band message if a user's affiliation changes while the user is not in the room; fixed stringprep references (room nicks use Resourceprep); clarified relationship between Room ID (i.e., node identifier of Room JID, which may be opaque) and natural-language Room Name; specified Field Standardization profile per XEP-0068; defined XMPP Registrar submissions; added schema locations.</p></remark>
<remark><p>Added reference to nodeprep Internet-Draft.</p></remark>
</revision>
<revision>
<version>1.2</version>
<date>2003-01-30</date>
<initials>psa</initials>
<remark><p>Commented out revision history prior to version 1.0 (too long); clarified business rules regarding when nicks, full JIDs, and bare JIDs are used in reference to roles and affiliations; consistently specified that extended presence information in the muc#user namespace must include the full JID as the value of the 'jid' attribute in all cases; cleaned up text and examples throughout; added open issue regarding syntax of room nicknames.</p></remark>
</revision>
<revision>
<version>1.1</version>
<date>2002-12-16</date>
<initials>psa</initials>
<remark><p>Added protocol for declining an invitation; replaced <created/> element with status code 201; modified the destroy room protocol so that <destroy/> is a child of <query/>; clarified usage of 'nick' attribute when adding members; prohibited use of message events.</p></remark>
</revision>
<revision>
<version>1.0</version>
<date>2002-11-21</date>
<initials>psa</initials>
<remark><p>Per a vote of the Jabber Council, revision 0.23 was advanced to Draft on 2002-11-21. (For earlier revision history, refer to XML source.)</p></remark>
<remark><p>Added examples for disco#items queries sent to a room; prohibited 'type' attribute on invite messages sent from client to room; added dependencies on browse and disco; changed 'room user' to 'occupant'; fixed many small errors throughout.</p></remark>
<remark><p>Added example for disco#items; added support for cancellation of room configuration using type='cancel' from XEP-0004; noted 403 error for invites sent by non-admins in members-only room.</p></remark>
<remark><p>Clarified several small ambiguities; made <body/> optional on invites sent from the service to the invitee; added error scenarios for changing nickname and for destroying the room; specified that the service must return the full member list for a members-only room (not only the members in the room); updated the disco examples to track protocol changes.</p></remark>
<remark><p>Specified that messages sent to change the room subject must be of type "groupchat"; updated the legal notice to conform to the XSF IPR policy.</p></remark>
<remark><p>Added ability to create an instant room within MUC (not by using gc-1.0 protocol); cleaned up disco examples.</p></remark>
</revision>
<revision>
<version>0.18</version>
<date>2002-10-27</date>
<initials>psa</initials>
<remark><p>Added experimental support for disco; added sections for security, IANA, and JANA considerations; corrected typographical errors; cleaned up some DocBook formatting.</p></remark>
</revision>
<revision>
<version>0.17</version>
<date>2002-10-23</date>
<initials>psa</initials>
<remark><p>Added the optional <actor/> element (with 'jid' attribute) to <item/> elements inside presence stanzas of type "unavailable" that are sent to users who are kicked or banned, as well as within IQs for tracking purposes; reverted all list editing use cases (ban, voice, member, moderator, admin, owner) to use of MUC format rather than 'jabber:x:data' namespace; added several guidelines regarding generation and handling of XML stanzas; cleaned up the change room subject use case; changed several ambiguous uses of 'would', 'can', and 'will' to 'should', 'may', or 'must'; fixed several small errors in the text, examples, and DTDs.</p></remark>
</revision>
<revision>
<version>0.16</version>
<date>2002-10-20</date>
<initials>psa</initials>
<remark><p>Added the <item/> element to presence stanzas of type "unavailable" in order to improve the tracking of user states in the room; consolidated <invitee/> and <invitor/> elements into an <invite/> element with 'from' and 'to' attributes; made <reason/> element always a child of <item/> or <invite/> in the muc#user namespace; moved the alternate room location in room destruction to a 'jid' attribute of the <alt/> element; further specified several error messages; disallowed simultaneous modifications of both affiliations and roles by a moderator or admin; added several more rules regarding handling of XML stanzas; added use cases for granting and revoking administrative privileges; adjusted DTD to track all changes.</p></remark>
</revision>
<revision>
<version>0.15</version>
<date>2002-10-18</date>
<initials>psa</initials>
<remark><p>Fully incorporated the change to affiliations + roles; moved a number of admin use cases to a new section for moderator use cases; added participant use case for requesting membership; added admin use cases for adding members, removing members, granting and revoking moderator privileges, and modifying the moderator list; organized the sections in a more logical manner.</p></remark>
</revision>
<revision>
<version>0.14</version>
<date>2002-10-17</date>
<initials>psa</initials>
<remark><p>Significantly modified the privileges model by distinguishing between in-room "roles" and long-lived "affiliations"; specified the privileges of the various roles and affiliations; included state transition charts for both roles and affiliations; removed use of MUC protocol for editing ban, voice, and admin lists (but not for the actions of banning users and granting/revoking voice); added delivery rule regarding IQ stanzas; changed kick so that the action is based on changing the role to "none".</p></remark>
</revision>
<revision>
<version>0.13</version>
<date>2002-10-16</date>
<initials>psa</initials>
<remark><p>Corrected the change nickname examples (newnick sent on unavailable, no nick sent on available).</p></remark>
</revision>
<revision>
<version>0.12</version>
<date>2002-10-16</date>
<initials>psa</initials>
<remark><p>Removed SHA1 passwords; specified that room shall add passwords on invitations to password-protected rooms (not supplied by invitor).</p></remark>
</revision>
<revision>
<version>0.11</version>
<date>2002-10-16</date>
<initials>psa</initials>
<remark><p>Changed 'participant' to 'room user' and 'discussant' to 'participant'; clarified presence rule about client generation of extended presence information; added role of 'none'.</p></remark>
</revision>
<revision>
<version>0.10</version>
<date>2002-10-15</date>
<initials>psa</initials>
<remark><p>Fixed extended presence on entering or creating a room (plain '...muc' with no fragment); harmonized #user with #admin regarding the use of the <item/> element and associated attributes (jid, nick, etc.), and added 'role' attribute; modified management of voice, ban, admin, and member lists to use <query/> wrapper and new <item/> structure; changed the 'member' role to 'discussant', added 'outcast' role for banned users, and added new 'member' role to enable management of member lists; changed invitation-only rooms to members-only rooms and made appropriate adjustments to apply member lists to both members-only rooms and open rooms; modified nickname change protocol slightly to send the old nickname in the unavailable presence and the new nickname in the available presence; removed prohibition on members-only rooms that are password-protected; removed the <query/> wrapper for the <destroy/> element; updated the DTDs.</p></remark>
</revision>
<revision>
<version>0.9</version>
<date>2002-10-13</date>
<initials>psa</initials>
<remark><p>Added extended presence ('...#user') on entering a room for MUC clients; changed namespace on room creation request to '...#owner'; added a service discovery example using jabber:iq:browse; added information about discussion history; made small fixes to several examples; further defined the presence rules; transferred all implementation notes to a dedicated section; added a Terminology section.</p></remark>
</revision>
<revision>
<version>0.8</version>
<date>2002-10-10</date>
<initials>psa</initials>
<remark><p>Made further changes to the room creation workflow (finally correct); removed feature discovery use case (this needs to be addressed by a real service discovery protocol!); added ability for room owners to edit the admin list; removed <body/> from invitations generated by the service; removed messages sent to kicked and banned users (handled by unavailable presence with status code); added a number of implementation notes; converted all examples to Shakespeare style.</p></remark>
</revision>
<revision>
<version>0.7.6</version>
<date>2002-10-09</date>
<initials>psa</initials>
<remark><p>Fixed the room creation workflow; changed some terminology ("join" to "enter" and "leave" to "exit").</p></remark>
</revision>
<revision>
<version>0.7.5</version>
<date>2002-10-08</date>
<initials>psa</initials>
<remark><p>Specified and improved the handling of invitation-only rooms. In particular, added the ability for room admins to edit the invitation list and added a configuration option that limits the ability to send invitations to room admins only.</p></remark>
</revision>
<revision>
<version>0.7.4</version>
<date>2002-10-07</date>
<initials>psa</initials>
<remark><p>Changed namespaces from http://jabber.org/protocol/muc/owner etc. to http://jabber.org/protocol/muc#owner etc. per Jabber Council discussion.</p></remark>
</revision>
<revision>
<version>0.7.3</version>
<date>2002-10-07</date>
<initials>psa</initials>
<remark><p>Changed namespaces to HTTP URIs; left role handling up to the implementation; further clarified presence rules.</p></remark>
</revision>
<revision>
<version>0.7.2</version>
<date>2002-10-06</date>
<initials>psa</initials>
<remark><p>Disallowed kicking, banning, and revoking voice with respect to room admins and room owners; replaced <x/> with <query/> in the Discovering Room Features and Destroying a Room use cases; corrected some small errors and made many clarifications throughout.</p></remark>
</revision>
<revision>
<version>0.7.1</version>
<date>2002-10-04</date>
<initials>psa</initials>
<remark><p>Removed <whois/> command (unnecessary since participants with appropriate privileges receive the full JID of all participants in presence stanzas); completed many small fixes throughout.</p></remark>
</revision>
<revision>
<version>0.7</version>
<date>2002-10-03</date>
<initials>psa</initials>
<remark><p>More clearly delineated participant roles and defined the hierarchy thereof (owner, admin, member, visitor); replaced <voice/> element in extended presence with <item role='member'/>; changed initial room configuration to use IQ rather than message; adjusted presence rules (especially regarding extended presence information); cleaned up examples throughout; updated DTD to track changes.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2002-09-21</date>
<initials>psa</initials>
<remark><p>More clearly defined the scope; removed fully anonymous rooms; changed meaning of semi-anonymous rooms and of non-anonymous rooms; added mechanism for notification of full JIDs in non-anonymous rooms; replaced the <admin/> element in extended presence with a <role/> element (more extensible); changed room passwords to cleartext; added status codes for various messages received from the service; added lists of valid error and status codes associated with the 'http://jabber.org/protocol/muc#user' namespace; added a <reason/> element for invitations; made kick and ban reasons child elements rather than attributes; replaced stopgap feature discovery mechanism with jabber:iq:negotiate; added extended presence element to room creation request and clarified the room creation process; specified presence reflection rules; added method for destroying a room; adjusted DTDs to track all changes.</p></remark>
<remark><p>Added DTDs; changed feature discovery to use <x/> element rather than query and made service response come in IQ result; fixed reference to JID spec; changed 'grant' to 'add' and 'revoke' to 'remove' for consistency in the item attributes; made several other small changes.</p></remark>
<remark><p>Changed the kick, ban, and voice protocols; added a few more configuration options; specified the restrictions for roomnicks; and added a stopgap service discovery protocol.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2002-09-18</date>
<initials>psa</initials>
<remark><p>Changed all non-GC-1.0 use cases to jabber:gc:* namespaces or jabber:x:data; added use cases for ban list management and room moderation; added protocol for sending notice of admin and voice privileges in presence; cleaned up text and many examples.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2002-09-17</date>
<initials>psa</initials>
<remark><p>Changed admin use cases; cleaned up participant and owner use cases.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2002-09-12</date>
<initials>psa</initials>
<remark><p>Broke content out into three actors (participant, owner, and admin) and added more detail to owner and admin use cases.</p></remark>
<p>Traditionally, instant messaging is thought to consist of one-to-one chat rather than many-to-many chat, which is called variously "groupchat" or "text conferencing". Groupchat functionality is familiar from systems such as Internet Relay Chat (IRC) and the chatroom functionality offered by popular consumer IM services. The Jabber community developed and implemented a basic groupchat protocol as long ago as 1999. This "groupchat 1.0" protocol provided a minimal feature set for chat rooms but was rather limited in scope. This specification (Multi-User Chat or MUC) builds on the older "groupchat 1.0" protocol in a backwards-compatible manner but provides advanced features such as invitations, room moderation and administration, and specialized room types.</p>
<p>This document addresses common requirements related to configuration of, participation in, and administration of individual text-based conference rooms. All of the requirements addressed herein apply at the level of the individual room and are "common" in the sense that they have been widely discussed within the Jabber community or are familiar from existing text-based conference environments outside of Jabber (e.g., Internet Relay Chat as defined in &rfc1459; and its successors: &rfc2810;, &rfc2811;, &rfc2812;, &rfc2813;).</p>
<li>Management of multi-user chat services (e.g., managing permissions across an entire service or registering a global room nickname); such use cases are specified in &xep0133;</li>
<p>This limited scope is not meant to disparage such topics, which are of inherent interest; however, it is meant to focus the discussion in this document and to present a comprehensible protocol that can be implemented by Jabber client and component developers alike. Future specifications may of course address the topics mentioned above.</p>
</section1>
<section1topic='Requirements'anchor='reqs'>
<p>This document addresses the minimal functionality provided by existing multi-user chat services in Jabber. For the sake of backwards-compatibility, this document uses the original "groupchat 1.0" protocol for this baseline functionality, with the result that:</p>
<ul>
<li>Each room is identified as &ROOM; (e.g., <jdev@conference.jabber.org>), where "room" is the name of the room and "service" is the hostname at which the multi-user chat service is running.</li>
<li>Each occupant in a room is identified as &ROOMJID;, where "nick" is the room nickname of the occupant as specified on entering the room or subsequently changed during the occupant's visit.</li>
<li>A user enters a room (i.e., becomes an occupant) by sending presence to &ROOMJID;.</li>
<li>Messages sent within multi-user chat rooms are of a special type "groupchat" and are addressed to the room itself (room@service), then reflected to all occupants.</li>
<li>An occupant can change his or her room nickname and availability status within the room by sending presence information to <room@service/newnick>.</li>
<li>An occupant exits a room by sending presence of type "unavailable" to its current &ROOMJID;.</li>
</ul>
<p>The additional features and functionality addressed in this document include the following:</p>
<olstart='1'>
<li>native conversation logging (no in-room bot required)</li>
<li>enabling users to request membership in a room</li>
<li>enabling occupants to view an occupant's full JID in a non-anonymous room</li>
<li>enabling moderators to view an occupant's full JID in a semi-anonymous room</li>
<li>allowing only moderators to change the room subject</li>
<li>enabling moderators to kick participants and visitors from the room</li>
<li>enabling moderators to grant and revoke voice (i.e., the privilege to speak) in a moderated room, and to manage the voice list</li>
<li>enabling admins to grant and revoke moderator privileges, and to manage the moderator list</li>
<li>enabling admins to ban users from the room, and to manage the ban list</li>
<li>enabling admins to grant and revoke membership privileges, and to manage the member list for a members-only room</li>
<li>enabling owners to limit the number of occupants</li>
<li>enabling owners to specify other owners</li>
<li>enabling owners to grant and revoke administrative privileges, and to manage the admin list</li>
<li>enabling owners to destroy the room</li>
</ol>
<p>In addition, this document provides protocol elements for supporting the following room types:</p>
<p>The extensions needed to implement these requirements are qualified by the 'http://jabber.org/protocol/muc' namespace (and the #owner, #admin, and #user fragments on the main namespace URI).</p>
<p>Affiliation -- a long-lived association or connection with a room; the possible affiliations are "owner", "admin", "member", and "outcast" (naturally it is also possible to have no affiliation); affiliation is distinct from role. An affiliation lasts across a user's visits to a room.</p>
<p>Ban -- to remove a user from a room such that the user is not allowed to re-enter the room (until and unless the ban has been removed). A banned user has an affiliation of "outcast".</p>
<p>Bare JID -- the <user@host> by which a user is identified outside the context of any existing session or resource; contrast with Full JID and Room JID.</p>
<p>Full JID -- the <user@host/resource> by which an online user is identified outside the context of a room; contrast with Bare JID and Room JID.</p>
<p>GC -- the minimal "groupchat 1.0" protocol <note><linkurl='http://www.jabber.org/protocol/groupchat.html'>http://www.jabber.org/protocol/groupchat.html</link></note> developed within the Jabber community in 1999; MUC is backwards-compatible with GC.</p>
<p>History -- a limited number of message stanzas sent to a new occupant to provide the context of current discussion.</p>
<p>Invitation -- a special message sent from one user to another asking the recipient to join a room.</p>
<p>IRC -- Internet Relay Chat.</p>
<p>Kick -- to temporarily remove a participant or visitor from a room; the user is allowed to re-enter the room at any time. A kicked user has a role of "none".</p>
<p>Logging -- storage of discussions that occur within a room for public retrieval outside the context of the room.</p>
<p>Member -- a user who is on the "whitelist" for a members-only room or who is registered with an open room. A member has an affiliation of "member".</p>
<p>Moderator -- a room role that is usually associated with room admins but that may be granted to non-admins; is allowed to kick users, grant and revoke voice, etc. A moderator has a role of "moderator".</p>
<p>MUC -- the multi-user chat protocol for text-based conferencing specified in this document.</p>
<p>Occupant -- any Jabber user who is in a room (this is an "abstract class" and does not correspond to any specific role).</p>
<p>Outcast -- a user who has been banned from a room. An outcast has an affiliation of "outcast".</p>
<p>Participant -- an occupant who does not have administrative privileges; in a moderated room, a participant is further defined as having voice (in contrast to a visitor). A participant has a role of "participant".</p>
<p>Private Message -- a message sent from one occupant directly to another's room JID (not to the room itself for broadcasting to all occupants).</p>
<p>Role -- a temporary position or privilege level within a room, distinct from a user's long-lived affiliation with the room; the possible roles are "moderator", "participant", and "visitor" (it is also possible to have no defined role). A role lasts only for the duration of an occupant's visit to a room.</p>
<p>Room -- a virtual space that Jabber users figuratively enter in order to participate in real-time, text-based conferencing with other users.</p>
<p>Room Administrator -- a user empowered by the room owner to perform administrative functions such as banning users; however, is not allowed to change defining room features. An admin has an affiliation of "admin".</p>
<p>Room ID -- the node identifier portion of a Room JID, which may be opaque and thus lack meaning for human users (see Business Rules for syntax); contrast with Room Name.</p>
<p>Room JID -- the &ROOMJID; by which an occupant is identified within the context of a room; contrast with Bare JID and Full JID.</p>
<p>Room Name -- a user-friendly, natural-language name for a room, configured by the room owner and presented in Service Discovery queries; contrast with Room ID.</p>
<p>Room Nickname -- the resource identifier portion of a Room JID (see Business Rules for syntax); this is the "friendly name" by which an occupant is known in the room.</p>
<p>Room Owner -- the Jabber user who created the room or a Jabber user who has been designated by the room creator or owner as someone with owner privileges (if allowed); is allowed to change defining room features as well as perform all administrative functions. An owner has an affiliation of "owner".</p>
<p>Room Roster -- a Jabber client's representation of the occupants in a room.</p>
<p>Server -- a Jabber server that may or may not have associated with it a text-based conferencing service.</p>
<p>Service -- a host that offers text-based conferencing capabilities; often but not necessarily a sub-domain of a Jabber server (e.g., conference.jabber.org).</p>
<p>Subject -- a temporary discussion topic within a room.</p>
<p>Visit -- a user's "session" in a room, beginning when the user enters the room (i.e., becomes an occupant) and ending when the user exits the room.</p>
<p>Visitor -- in a moderated room, an occupant who does not have voice (in contrast to a participant). A visitor has a role of "visitor".</p>
<p>Voice -- in a moderated room, the privilege to send messages to all occupants.</p>
</section2>
<section2topic='Room Types'anchor='terms-rooms'>
<p>Fully-Anonymous Room -- a room in which the full JIDs or bare JIDs of occupants cannot be discovered by anyone, including room admins and room owners; such rooms are NOT RECOMMENDED or explicitly supported by MUC, but are possible using this protocol if a service implementation offers the appropriate configuration options; contrast with Non-Anonymous Room and Semi-Anonymous Room.</p>
<p>Hidden Room -- a room that cannot be found by any user through normal means such as searching and service discovery; antonym: Public Room.</p>
<p>Members-Only Room -- a room that a user cannot enter without being on the member list; antonym: Open Room.</p>
<p>Moderated Room -- a room in which only those with "voice" may send messages to all occupants; antonym: Unmoderated Room.</p>
<p>Non-Anonymous Room -- a room in which an occupant's full JID is exposed to all other occupants, although the occupant may choose any desired room nickname; contrast with Semi-Anonymous Room and Fully-Anonymous Room.</p>
<p>Open Room -- a room that anyone may enter without being on the member list; antonym: Members-Only Room.</p>
<p>Password-Protected Room -- a room that a user cannot enter without first providing the correct password; antonym: Unsecured Room.</p>
<p>Persistent Room -- a room that is not destroyed if the last occupant exits; antonym: Temporary Room.</p>
<p>Public Room -- a room that can be found by any user through normal means such as searching and service discovery; antonym: Hidden Room.</p>
<p>Semi-Anonymous Room -- a room in which an occupant's full JID can be discovered by room admins only; contrast with Fully-Anonymous Room and Non-Anonymous Room.</p>
<p>Temporary Room -- a room that is destroyed if the last occupant exits; antonym: Persistent Room.</p>
<p>Unmoderated Room -- a room in which any occupant is allowed to send messages to all occupants; antonym: Moderated Room.</p>
<p>Unsecured Room -- a room that anyone is allowed to enter without first providing the correct password; antonym: Password-Protected Room.</p>
<p>Most of the examples in this document use the scenario of the witches' meeting held in a dark cave at the beginning of Act IV, Scene I of Shakespeare's <cite>Macbeth</cite>, represented here as the "darkcave@chat.shakespeare.lit" chatroom. The characters are as follows:</p>
<section1topic='Roles and Affiliations'anchor='connections'>
<p>There are two dimensions along which we can measure a user's connection with or position in a room. One is the user's long-lived affiliation with a room -- e.g., a user's status as an owner or an outcast. The other is a user's role while an occupant of a room -- e.g., an occupant's position as a moderator with the ability to kick visitors and participants. These two dimensions are distinct from each other, since an affiliation lasts across visits, while a role lasts only for the duration of a visit. In addition, there is no one-to-one correspondence between roles and affiliations; for example, someone who is not affiliated with a room may be a (temporary) moderator, and a member may be a participant or a visitor in a moderated room. These concepts are explained more fully below.</p>
<p>Roles are temporary in that they do not necessarily persist across a user's visits to the room and MAY change during the course of an occupant's visit to the room. An implementation MAY persist roles across visits and SHOULD do so for moderated rooms (since the distinction between visitor and participant is critical to the functioning of a moderated room).</p>
<p>There is no one-to-one mapping between roles and affiliations (e.g., a member could be a participant or a visitor).</p>
<p>A moderator is the most powerful occupant within the context of the room, and can to some extent manage other occupants' roles in the room. A participant has fewer privileges than a moderator, although he or she always has the right to speak. A visitor is a more restricted role within the context of a moderated room, since visitors are not allowed to send messages to all occupants.</p>
<p>Roles are granted, revoked, and maintained based on the occupant's room nickname or full JID rather than bare JID. The privileges associated with these roles, as well as the actions that trigger changes in roles, are defined below.</p>
<p>Information about roles MUST be sent in all presence stanzas generated or reflected by the room and thus sent to occupants.</p>
<section3topic='Privileges'anchor='roles-priv'>
<p>For the most part, roles exist in a hierarchy. For instance, a participant can do anything a visitor can do, and a moderator can do anything a participant can do. Each role has privileges not possessed by the next-lowest role; these privileges are specified in the following table as defaults (an implementation MAY provide configuration options that override these defaults).</p>
<p>The ways in which an occupant's role changes are well-defined. Sometimes the change results from the occupant's own action (e.g., entering or exiting the room), whereas sometimes the change results from an action taken by a moderator, admin, or owner. If an occupant's role changes, a MUC service implementation MUST change the occupant's role to reflect the change and communicate the change to all occupants. Role changes and their triggering actions are specified in the following table.</p>
<tablecaption='Role State Chart'>
<tr>
<th>></th>
<th>None</th>
<th>Visitor</th>
<th>Participant</th>
<th>Moderator</th>
</tr>
<tr>
<td>None</td>
<td>--</td>
<td>Enter moderated room</td>
<td>Enter unmoderated room</td>
<td>Admin or owner enters room</td>
</tr>
<tr>
<td>Visitor</td>
<td>Exit room or be kicked by a moderator</td>
<td>--</td>
<td>Moderator grants voice</td>
<td>Admin or owner grants moderator privileges</td>
</tr>
<tr>
<td>Participant</td>
<td>Exit room or be kicked by a moderator</td>
<td>Moderator revokes voice</td>
<td>--</td>
<td>Admin or owner grants moderator privileges</td>
</tr>
<tr>
<td>Moderator</td>
<td>Exit room</td>
<td>Admin or owner changes role to visitor *</td>
<td>Admin or owner changes role to participant or revokes moderator privileges *</td>
<td>--</td>
</tr>
</table>
<p>* A moderator MUST NOT be able to revoke moderator privileges from an occupant who is equal to or above the moderator in the hierarchy of affiliations.</p>
<pclass='box'>Note: Certain roles are typically implicit in certain privileges. For example, an admin or owner is automatically a moderator, so if an occupant is granted admin status then the occupant will by that fact be granted moderator privileges; similarly, when an occupant is made a member in a moderated room, the occupant automatically has a role of participant. However, the loss of admin status does not necessarily mean that the occupant is no longer a moderator (since a "mere" participant can be a moderator). Therefore, the roles that are gained when an occupant is granted a certain affiliation are stable, whereas the roles that are lost when an occupant loses a certain affilitation are no hardcoded and are left up to the implementation. Since a client cannot predict what the role will be after revoking a certain affiliation, if it wants to remove both admin/owner privileges and the moderator role at the same time then it must specifically request the role change in addition to the affiliation change.</p>
<p>Support for the Owner affiliation is REQUIRED. Support for the Admin, Member, and Outcast affiliations is RECOMMENDED. (The "None" affiliation is the absence of an affiliation.)</p>
<p>These affiliations are long-lived in that they persist across a user's visits to the room and are not affected by happenings in the room. In addition, there is no one-to-one mapping between these affiliations and an occupant's role within the room. Affiliations are granted, revoked, and maintained based on the user's bare JID.</p>
<p>If a user without a defined affiliation enters a room, the user's affiliation is defined as "none"; however, this affiliation does not persist across visits (i.e., a service does not maintain a "none list" across visits).</p>
<p>The member affiliation provides a way for a room owner or admin to specify a "whitelist" of users who are allowed to enter a members-only room. When a member enters a members-only room, his or her affiliation does not change, no matter what his or her role is. The member affiliation also provides a way for users to effectively register with an open room and thus be lastingly associated with that room in some way (one result may be that the user's nickname is reserved in the room).</p>
<p>An outcast is a user who has been banned from a room and who is not allowed to enter the room.</p>
<p>Information about affiliations MUST be sent in all presence stanzas generated or reflected by the room and sent to occupants.</p>
<section3topic='Privileges'anchor='affil-priv'>
<p>For the most part, affiliations exist in a hierarchy. For instance, an owner can do anything an admin can do, and an admin can do anything a member can do. Each affiliation has privileges not possessed by the next-lowest affiliation; these privileges are specified in the following table.</p>
<tablecaption='Privileges Associated With Affiliations'>
<p>* As a default, an unaffiliated user enters a moderated room as a visitor, and enters an open room as a participant. A member enters a room as a participant. An admin or owner enters a room as a moderator.</p>
<p>The ways in which a user's affiliation changes are well-defined. Sometimes the change results from the user's own action (e.g., registering as a member of the room), whereas sometimes the change results from an action taken by an admin or owner. If a user's affiliation changes, a MUC service implementation MUST change the user's affiliation to reflect the change and communicate that to all occupants. Affiliation changes and their triggering actions are specified in the following table.</p>
<tablecaption='Affiliation State Chart'>
<tr>
<th>></th>
<th>Outcast</th>
<th>None</th>
<th>Member</th>
<th>Admin</th>
<th>Owner</th>
</tr>
<tr>
<td>Outcast</td>
<td>--</td>
<td>Admin or owner removes ban</td>
<td>Admin or owner adds user to member list</td>
<td>Owner adds user to admin list</td>
<td>Owner adds user to owner list</td>
</tr>
<tr>
<td>None</td>
<td>Admin or owner applies ban</td>
<td>--</td>
<td>Admin or owner adds user to member list, or user registers as member (if allowed)</td>
<td>Owner adds user to admin list</td>
<td>Owner adds user to owner list</td>
</tr>
<tr>
<td>Member</td>
<td>Admin or owner applies ban</td>
<td>Admin or owner changes affiliation to "none"</td>
<section2topic='Discovering Component Support for MUC'anchor='disco-component'>
<p>A Jabber entity may wish to discover if a service implements the Multi-User Chat protocol; in order to do so, it sends a service discovery information ("disco#info") query to the component's JID:</p>
<examplecaption='User Queries Chat Service for MUC Support via Disco'><![CDATA[
<p>Note: Because MUC is a superset of the old "groupchat 1.0" protocol, a MUC service SHOULD NOT return a <feature var='gc-1.0'/> entry in a disco#info result.</p>
<p>The service discovery items ("disco#items") protocol enables a user to query a service for a list of associated items, which in the case of a chat service would consist of the specific chat rooms hosted by the service.</p>
<examplecaption='User Queries Chat Service for Rooms'><![CDATA[
<p>If the full list of rooms is large (see <cite>XEP-0030</cite> for details), the service MAY return only a partial list of rooms. If it does so, it SHOULD include a <set/> element (as defined in &xep0059;) to indicate that the list not the full result set.</p>
<examplecaption='Service Returns Limited List of Disco Item Results'><![CDATA[
<p>Using the disco#info protocol, a user may also query a specific chat room for more detailed information about the room. A user SHOULD do so before entering a room in order to determine the privacy and security profile of the room configuration (see the <linkurl='#security'>Security Considerations</link> for details).</p>
<p>Note: Because MUC is a superset of the old "groupchat 1.0" protocol, a MUC room SHOULD NOT return a <feature var='gc-1.0'/> entry in a disco#info result. The room SHOULD return the materially-relevant features it supports, such as password protection and room moderation (these are listed fully in the feature registry maintained by the XMPP Registrar; see also the <linkurl='#registrar'>XMPP Registrar</link> section of this document).</p>
<p>A chatroom MAY return more detailed information in its disco#info response using &xep0128;, identified by inclusion of a hidden FORM_TYPE field whose value is "http://jabber.org/protocol/muc#roominfo". Such information might include a more verbose description of the room, the current room subject, and the current number of occupants in the room:</p>
<p>Some extended room information may be dynamically generated (e.g., the URL for discussion logs, which may be based on service-wide configuration). Other information may be based on the room configuration, which is why any field defined for the <linkurl='#registrar-formtype-owner'>muc#roomconfig FORM_TYPE</link> can be included in the extended service discovery fields (as shown above for the muc#roomconfig_changesubject field).</p>
<p>Note: The foregoing extended service discovery fields for the 'http://jabber.org/protocol/muc#roominfo' FORM_TYPE may be supplemented in the future via the mechanisms described in the <linkurl="#registrar-formtype">Field Standardization</link> section of this document.</p>
</section2>
<section2topic='Querying for Room Items'anchor='disco-roomitems'>
<p>A user MAY also query a specific chat room for its associated items:</p>
<examplecaption='User Queries for Items Associated with a Specific Chat Room'><![CDATA[
<p>An implementation MAY return a list of existing occupants if that information is publicly available, or return no list at all if this information is kept private.</p>
<examplecaption='Room Returns Disco Item Results (Items are Public)'><![CDATA[
<p>Note: These <item/> elements are qualified by the disco#items namespace, not the muc namespace; this means that they cannot possess 'affiliation' or 'role' attributes, for example.</p>
<examplecaption='Room Returns Empty Disco Item Results (Items are Private)'><![CDATA[
<section2topic='Querying a Room Occupant'anchor='disco-occupant'>
<p>If a non-occupant attempts to send a disco request to an address of the form &ROOMJID;, a MUC service SHOULD return the request to the entity and specify a &badrequest; error condition. If an occupant sends such a request, the service MAY pass it through the intended recipient; see the <linkurl='#impl'>Implementation Guidelines</link> section of this document for details.</p>
</section2>
<section2topic='Discovering Client Support for MUC'anchor='disco-client'>
<p>A Jabber user may want to discover if one of the user's contacts supports the Multi-User Chat protocol. This is done using Service Discovery.</p>
<p>A user may also query a contact regarding which rooms the contact is in. This is done by querying the contact's full JID (<user@host/resource>) while specifying the well-known Service Discovery node 'http://jabber.org/protocol/muc#rooms':</p>
<examplecaption='User Queries Contact for Current Rooms'><![CDATA[
<p>The main actor in a multi-user chat environment is the occupant, who can be said to be located "in" a multi-user chat room and to participate in the discussions held in that room (for the purposes of this specification, participants and visitors are considered to be "mere" occupants, since they possess no administrative privileges). As will become clear, the protocol elements proposed in this document to fulfill the occupant use cases fall into three categories:</p>
<olstart='1'>
<li><p>existing "groupchat 1.0" protocol for minimal functionality</p></li>
<li><p>straightforward applications of the "groupchat 1.0" protocol, for example to handle some of the errors related to new room types</p></li>
<li><p>additional protocol elements to handle functionality not covered by "groupchat 1.0" (room invites, room passwords, extended presence related to room roles and affiliations); these are qualified by the 'http://jabber.org/protocol/muc#user' namespace</p></li>
</ol>
<p>Note: All client-generated examples herein are presented from the perspective of the service, with the result that all stanzas received by a service contain a 'from' attribute corresponding to the sender's full JID as added by a normal Jabber router or session manager. In addition, normal IQ result stanzas sent upon successful completion of a request (as required by &rfc3920;) are not shown.</p>
<p>In order to participate in the discussions held in a multi-user chat room, a Jabber user MUST first become an occupant by entering the room. In the old "groupchat 1.0" protocol, this was done by sending presence to &ROOMJID;, where "room" is the room ID, "service" is the hostname of the chat service, and "nick" is the user's desired nickname within the room:</p>
<examplecaption='Jabber User Seeks to Enter a Room (Groupchat 1.0)'><![CDATA[
<p>In this example, a user with a full JID of "hag66@shakespeare.lit/pda" has requested to enter the room "darkcave" on the "chat.shakespeare.lit" chat service with a room nickname of "thirdwitch".</p>
<p>Compliant multi-user chat services MUST accept the foregoing as a request to enter a room from any Jabber client that knows either the "groupchat 1.0" (GC) protocol or the multi-user chat (MUC) protocol; however, MUC clients SHOULD signal their ability to speak the MUC protocol by including in the initial presence stanza an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace (note the absence of the '#user' fragment):</p>
<examplecaption='Jabber User Seeks to Enter a Room (Multi-User Chat)'><![CDATA[
<p>Note: If an error occurs in relation to joining a room, the service SHOULD include the MUC child element (i.e., <x xmlns='http://jabber.org/protocol/muc'/>) in the &PRESENCE; stanza of type "error".</p>
<p>Before attempting to enter the room, a MUC-compliant client SHOULD first discover its reserved room nickname (if any) by following the protocol defined in the <linkurl='#reservednick'>Discovering Reserved Room Nickname</link> section of this document.</p>
<p>If the service is able to add the user to the room, it MUST send presence from all the existing occupants' room JIDs to the new occupant's full JID, including extended presence information about roles in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "moderator", "participant", or "visitor", and with the 'affiliation' attribute set to a value of "owner", "admin", "member", or "none" as appropriate:</p>
<examplecaption='Service Sends Presence from Existing Occupants to New Occupant'><![CDATA[
<p>In this example, the user from the previous example has entered the room, by which time two other people had already entered the room: a user with a room nickname of "firstwitch" (who is a room owner) and a user with a room nickname of "secondwitch" (who is a room admin).</p>
<p>The service MUST also send presence from the new occupant's room JID to the full JIDs of all the occupants (including the new occupant):</p>
<examplecaption="Service Sends New Occupant's Presence to All Occupants"><![CDATA[
<p>In this example, initial room presence is being sent from the new occupant (thirdwitch) to all occupants, including the new occupant. As shown in the last stanza, the presence sent by the room to a user from itself as an occupant SHOULD include a status code of 110 so that the user knows this presence refers to itself as an occupant.</p>
<p>The service MAY rewrite the new occupant's roomnick (e.g., if roomnicks are locked down). If the service does not accept the new occupant's requested roomnick but instead assigns a new roomnick, it MUST include a status code of "210" in the presence broadcast that it sends to the new occupant.</p>
<examplecaption="Service Sends New Occupant's Presence to New Occupant"><![CDATA[
<p>Note: The order of the presence stanzas sent to the new occupant is important. The service MUST first send the complete list of the existing occupants to the new occupant and only then send the new occupant's own presence to the new occupant. This helps the client know when it has received the complete "room roster".</p>
<p>After sending the presence broadcast (and only after doing so), the service may then send discussion history, live messages, presence updates, and other in-room traffic.</p>
<p>The following table summarizes the initial default roles that a service should set based on the user's affiliation (there is no role associated with the "outcast" affiliation, since such users are not allowed to enter the room).</p>
<tablecaption='Initial Role Based on Affiliation'>
<p>If the room is non-anonymous, the service MUST send the new occupant's full JID to all occupants using extended presence information in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with a 'jid' attribute specifying the occupant's full JID:</p>
<examplecaption="Service Sends Full JID to All Occupants"><![CDATA[
<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. This SHOULD be done by including a status code of "100" in the initial presence that the room sends to the new occupant:</p>
<examplecaption="Service Sends New Occupant's Presence to New Occupant"><![CDATA[
<p>However, it MAY be done by sending a message of type "groupchat" to the new occupant containing an <x/> child with a <status/> element that has the 'code' attribute set to a value of "100":</p>
<p>The inclusion of the status code assists clients in presenting their own notification messages (e.g., information appropriate to the user's locality).</p>
<p>If the room is semi-anonymous, the service MUST send presence from the new occupant to all occupants as specified above, but MUST include the new occupant's full JID only in the presence notifications it sends to occupants with a role of "moderator" and not to non-moderator occupants.</p>
<p>(Note: All subsequent examples include the 'jid' attribute for each <item/> element, even though this information is not sent to non-moderators in semi-anonymous rooms.)</p>
<p>If the room requires a password and the user did not supply one (or the password provided is incorrect), the service MUST deny access to the room and inform the user that they are unauthorized; this is done by returning a presence stanza of type "error" specifying a ¬authorized; error:</p>
<examplecaption='Service Denies Access Because No Password Provided'><![CDATA[
<p>Passwords SHOULD be supplied with the presence stanza sent when entering the room, contained within an <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace and containing a <password/> child. Passwords are to be sent as cleartext; no other authentication methods are supported at this time, and any such authentication or authorization methods shall be defined in a separate specification (see the <linkurl='#security'>Security Considerations</link> section of this document).</p>
<examplecaption='User Provides Password On Entering a Room'><![CDATA[
<p>If the room is members-only but the user is not on the member list, the service MUST deny access to the room and inform the user that they are not allowed to enter the room; this is done by returning a presence stanza of type "error" specifying a ®istration; error condition:</p>
<examplecaption='Service Denies Access Because User Is Not on Member List'><![CDATA[
<p>If the user has been banned from the room (i.e., has an affiliation of "outcast"), the service MUST deny access to the room and inform the user of the fact that he or she is banned; this is done by returning a presence stanza of type "error" specifying a &forbidden; error condition:</p>
<examplecaption='Service Denies Access Because User is Banned'><![CDATA[
<p>If the room already contains another user with the nickname desired by the user seeking to enter the room (or if the nickname is reserved by another user on the member list), the service MUST deny access to the room and inform the user of the conflict; this is done by returning a presence stanza of type "error" specifying a &conflict; error condition:</p>
<examplecaption='Service Denies Access Because of Nick Conflict'><![CDATA[
<p>However, if the bare JID &LOCALBARE; 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>
<p>How nickname conflicts are determined is up to the implementation (e.g., whether the service applies a case folding routine, a stringprep profile such as Resourceprep or Nodeprep, etc.).</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>
<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>
<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 ¬found; error to the user:</p>
<examplecaption='Service Denies Access Because Room Does Not Exist'><![CDATA[
<p>If the room does not already exist when the user seeks to enter it, the service SHOULD create it; however, this is not required, since an implementation or deployment MAY choose to restrict the privilege of creating rooms. For details, see the <linkurl='#createroom'>Creating a Room</link> section of this document.</p>
<p>If the user is entering a room in which the discussions are logged to a public archive (often accessible via HTTP), the service SHOULD allow the user to enter the room but MUST also warn the user that the discussions are logged. This SHOULD be done by including a status code of "170" in the initial presence that the room sends to the new occupant:</p>
<examplecaption="Service Sends New Occupant's Presence to New Occupant"><![CDATA[
<p>After sending initial presence as shown above, a room MAY send discussion history to the new occupant. (The room MUST NOT send any discussion history before it finishes sending room presence as specified in the <linkurl='#enter-pres'>Presence Broadcast</link> section of this document.) Whether such history is sent, and how many messages comprise the history, shall be determined by the chat service implementation or specific deployment.</p>
<examplecaption='Delivery of Discussion History'><![CDATA[
<p>Discussion history messages MUST be stamped with &xep0203; information qualified by the 'urn:xmpp:delay' namespace to indicate that they are sent with delayed delivery and to specify the times at which they were originally sent. (Note: The 'urn:xmpp:delay' namespace defined in <cite>XEP-0203</cite> supersedes the older 'jabber:x:delay' namespace defined in &xep0091;; until the status of <cite>XEP-0091</cite> is changed to Obsolete, implementations SHOULD include both datetime formats.) The 'from' attribute SHOULD be the full JID of the original sender in non-anonymous rooms, but MUST NOT be in semi-anonymous rooms (where the 'from' attribute SHOULD be set to the JID of the room itself). The service SHOULD send all discussion history messages before delivering any "live" messages sent after the user enters the room.</p>
<p>A user MAY want to manage the amount of discussion history provided on entering a room (perhaps because the user is on a low-bandwidth connection or is using a small-footprint client). This MUST be accomplished by including a <history/> child in the initial presence stanza sent when joining the room. There are four allowable attributes for this element:</p>
<tablecaption='History Management Attributes'>
<tr>
<th>Attribute</th>
<th>Datatype</th>
<th>Meaning</th>
</tr>
<tr>
<td>maxchars</td>
<td>int</td>
<td>Limit the total number of characters in the history to "X" (where the character count is the characters of the complete XML stanzas, not only their XML character data).</td>
</tr>
<tr>
<td>maxstanzas</td>
<td>int</td>
<td>Limit the total number of messages in the history to "X".</td>
</tr>
<tr>
<td>seconds</td>
<td>int</td>
<td>Send only the messages received in the last "X" seconds.</td>
<p>The service MUST send the smallest amount of traffic that meets any combination of the above criteria, taking into account service-level and room-level defaults. The service MUST send complete message stanzas only (i.e., it MUST not literally truncate the history at a certain number of characters, but MUST send the largest number of complete stanzas that results in a number of characters less than or equal to the 'maxchars' value specified). If the client wishes to receive no history, it MUST set the 'maxchars' attribute to a value of "0" (zero).</p>
<p>The following examples illustrate the use of this protocol.</p>
<examplecaption='User Requests Limit on Number of Messages in History'><![CDATA[
<p>Obviously the service SHOULD NOT return all messages sent in the room since the beginning of the Unix era, and SHOULD appropriately limit the amount of history sent to the user based on service or room defaults.</p>
<examplecaption='User Requests No History'><![CDATA[
<p>In order to exit a multi-user chat room, an occupant sends a presence stanza of type "unavailable" to the &ROOMJID; it is currently using in the room.</p>
<p>The service MUST then send presence stanzas of type "unavailable" from the departing occupant's room JID to the full JIDs of the departing occupant and of the remaining occupants:</p>
<examplecaption='Service Sends Presence Related to Departure of Occupant'><![CDATA[
<p>Presence stanzas of type "unavailable" reflected by the room MUST contain extended presence information about roles and affiliations; the 'role' attribute SHOULD be set to a value of "none" to denote that the individual is no longer an occupant.</p>
<p>The occupant MAY include normal <status/> information in the unavailable presence stanzas; this enables the occupant to provide a custom exit message if desired:</p>
<p>Normal presence stanza generation rules apply as defined in &xmppim;, so that if the user sends a general unavailable presence stanza, the user's server will broadcast that stanza to the &ROOMJID; to which the user's client has sent directed presence.</p>
<p>It is possible that a user may not be able to gracefully exit the room by sending unavailable presence directly to the room. If the user goes offline without sending unavailable presence, the user's server is responsible for sending unavailable presence on behalf of the user (in accordance with <cite>RFC 3921</cite>). If the user's server goes offline or connectivity is lost between the user's server and the MUC service to which the user is connected (e.g., in federated communications), the MUC service is responsible for monitoring error stanzas it receives in order to determine if the user has gone offline. If the MUC service determines that the user has gone offline, it must treat the user as if the user had itself sent unavailable presence.</p>
<p>Note: If the room is not persistent and this occupant is the last to exit, the service is responsible for destroying the room.</p>
<p>A common feature of multi-user chat rooms is the ability for an occupant to change his or her nickname within the room. In MUC this is done by sending updated presence information to the room, specifically by sending presence to a new room JID in the same room (changing only the resource identifier in the room JID).</p>
<p>The service then sends two presence stanzas to the full JID of each occupant (including the occupant who is changing his or her room nickname), one of type "unavailable" for the old nickname and one indicating availability for the new nickname.</p>
<p>The unavailable presence MUST contain the following as extended presence information in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace:</p>
<ul>
<li>The new nickname (in this case, nick='oldhag')</li>
<li>A status code of 303</li>
</ul>
<p>This enables the recipients to correlate the old roomnick with the new roomnick.</p>
<p>If the user attempts to change his or her room nickname to a room nickname that is already in use by another user (or that is reserved by another user affiliated with the room, e.g., a member or owner), the service MUST deny the nickname change request and inform the user of the conflict; this is done by returning a presence stanza of type "error" specifying a &conflict; error condition:</p>
<examplecaption='Service Denies Nickname Change Because of Nick Conflict'><![CDATA[
<p>However, if the bare JID &LOCALBARE; of the present occupant matches the bare JID of the user seeking to change his or her nickname, then the service MAY allow the nickname change. See the <linkurl='#enter-conflict'>Nickname Conflict</link> section of this document for details.</p>
<p>If the user attempts to change his or her room nickname but room nicknames are "locked down", the service MUST deny the nickname change request and return a presence stanza of type "error" specifying a ¬acceptable; error condition:</p>
<examplecaption='Service Denies Nickname Change Because Roomnicks Are Locked Down'><![CDATA[
<p>The user SHOULD then discover its reserved nickname as specified in the <linkurl='#reservednick'>Discovering Reserved Room Nickname</link> section of this document.</p>
<p>In multi-user chat systems such as IRC, one common use for changing one's room nickname is to indicate a change in one's availability (e.g., changing one's room nickname to "thirdwitch|away"). In Jabber, availability is of course noted by a change in presence (specifically the <show/> and <status/> elements), which can provide important context within a chatroom. An occupant changes availability status within the room by sending the updated presence to its &ROOMJID;.</p>
<p>The service then sends a presence stanza from the occupant changing his or her presence to the full JID of each occupant, including extended presence information about the occupant's role and full JID to those with privileges to view such information:</p>
<examplecaption='Service Passes Along Changed Presence to All Occupants'><![CDATA[
<p>A method for sending a direct invitation (not mediated by the room itself) is defined in another specification. Sending the invitation directly can help to work around communications blocking on the part of the invitee (which might refuse communication with entities not in its roster).</p>
<p>It can be useful to invite another user to a room in which one is an occupant. To do this, a MUC client MUST send XML of the following form to the &ROOM; itself (the reason is OPTIONAL and the message MUST be explicitly or implicitly of type "normal"):</p>
<examplecaption='Occupant Sends an Invitation by Way of Room'><![CDATA[
<p>The &ROOM; itself MUST then add a 'from' address to the <invite/> element whose value is the bare JID, full JID, or room JID of the invitor and send the invitation to the invitee specified in the 'to' address (the service MAY include a message body explaining the invitation or containing the reason, for the sake of older clients; in addition, the room SHOULD add the password if the room is password-protected):</p>
<examplecaption='Room Sends Invitation to Invitee on Behalf of Invitor'><![CDATA[
<p>If the room is members-only, the service MAY also add the invitee to the member list. (Note: Invitation privileges in members-only rooms SHOULD be restricted to room admins; if a member without privileges to edit the member list attempts to invite another user, the service SHOULD return a &forbidden; error to the occupant; for details, see the <linkurl='#modifymember'>Modifying the Member List</link> section of this document.)</p>
<p>If the invitor supplies a non-existent JID, the room SHOULD return an ¬found; error to the invitor.</p>
<p>The invitee MAY choose to formally decline (as opposed to ignore) the invitation; and this is something that the sender may want to be informed about. In order to decline the invitation, the invitee MUST send a message of the following form to the &ROOM; itself:</p>
<p>It may be wondered why the invitee does not send the decline message directly to the invitor. The main reason is that certain implementations MAY choose to base invitations on room JIDs rather than bare JIDs (so that, for example, an occupant could invite someone from one room to another without knowing that person's bare JID). Thus the service MUST handle both the invites and declines.</p>
<li>Sends an invitation to the second person and the third person, including a <continue/> element (optionally including a 'thread' attribute).</li>
<p>Note: The new room SHOULD be non-anonymous, MAY be an instant room as specified in the <linkurl='#createroom-instant'>Creating an Instant Room</link> section of this document, and MAY have a unique room name received from the service as specified in the <linkurl='#createroom-instant-unique'>Requesting a Unique Room Name</link> section of this document.</p>
<p>Note: If the one-to-one chat messages included a &THREAD; element, the person who creates the room SHOULD include the ThreadID with the history messages, specify the ThreadID in the invitations as the value of the <continue/> element's 'thread' attribute, and include the ThreadID in any new messages sent to the room. Use of ThreadIDs is RECOMMENDED because it helps to provide continuity between the one-to-one chat and the multi-user chat.</p>
<p>Note: Use of the <cite>Delayed Delivery</cite> protocol enables the room creator to specify the datetime of each message from the one-to-one chat history (via the 'stamp' attribute), as well as the JID of the original sender of each message (via the 'from' attribute). The room creator SHOULD send the complete one-to-one chat history before inviting additional users to the room, and SHOULD also send as history any messages appearing in the one-to-one chat interface after joining the room and before the second person joins the room; if the one-to-one history is especially large, the sending client may want to send the history over a few seconds rather than all at once (to avoid triggering rate limits). The service SHOULD NOT add its own delay elements (as described in the <linkurl='#enter-history'>Discussion History</link> section of this document) to prior chat history messages received from the room owner.</p>
<examplecaption='Continuing the Discussion III: Owner Sends Invitations, Including Continue Flag'><![CDATA[
<p>Note: Since the invitor's client knows the full JID of the person with whom the invitor was having a one-to-one chat, it SHOULD include the full JID (rather than the bare JID) in the invitation.</p>
<p>The invitations are delivered to the invitees:</p>
<p>When the client being used by <wiccarocks@shakespeare.lit/laptop> receives the invitation, it SHOULD auto-join the room or prompt the user whether to join (subject to user preferences) and then seamlessly convert the existing one-to-one chat window into a multi-user conferencing window:</p>
<examplecaption='Invitee Accepts Invitation, Joins Room, and Receives Presence and History'><![CDATA[
<p>Note: The fact that the messages come from the &ROOM; itself rather than &ROOMJID; is a clue to the receiving client that these messages are prior chat history, since any message from a room occupant will have a 'from' address equal to the sender's room JID.</p>
</section2>
<section2topic='Occupant Modification of the Room Subject'anchor='subject-occupant'>
<p>If allowed in accordance with room configuration, a mere occupant MAY be allowed to change the subject in a room. For details, see the <linkurl='#subject-mod'>Modifying the Room Subject</link> section of this document.</p>
</section2>
<section2topic='Sending a Private Message'anchor='privatemessage'>
<p>Since each occupant has a unique room JID, an occupant MAY send a "private message" to a selected occupant via the service by sending a message to the occupant's room JID. The message type SHOULD be "chat" and MUST NOT be "groupchat", but MAY be left unspecified (i.e., a normal message). This privilege SHOULD be allowed to any occupant (even a visitor in a moderated room).</p>
<p>The service is responsible for changing the 'from' address to the sender's room JID and delivering the message to the intended recipient's full JID.</p>
<examplecaption='Recipient Receives the Private Message'><![CDATA[
<p>If the sender attempts to send a private message of type "groupchat" to a particular occupant, the service MUST refuse to deliver the message (since the recipient's client would expect in-room messages to be of type "groupchat") and return a &badrequest; error to the sender:</p>
<examplecaption='Occupant Attempts to Send a Message of Type "Groupchat" to a Particular Occupant'><![CDATA[
<p>If the sender attempts to send a private message to a room JID that does not exist, the service MUST return an ¬found; error to the sender.</p>
<p>If the sender is not an occupant of the room in which the intended recipient is visiting, the service MUST return a ¬acceptable; error to the sender.</p>
</section2>
<section2topic='Sending a Message to All Occupants'anchor='message'>
<p>An occupant sends a message to all other occupants in the room by sending a message of type "groupchat" to the &ROOM; itself (a service MAY ignore or reject messages that do not have a type of "groupchat"). In a moderated room, this privilege is restricted to occupants with a role of participant or higher.</p>
<examplecaption='Occupant Sends a Message to All Occupants'><![CDATA[
<p>If the sender has voice in the room (this is the default except in moderated rooms), the service MUST change the 'from' attribute to the sender's room JID and reflect the message out to the full JID of each occupant.</p>
<examplecaption='Service Reflects Message to All Occupants'><![CDATA[
<p>If the sender is a visitor (i.e., does not have voice in a moderated room), the service MAY return a &forbidden; error to the sender and MUST NOT reflect the message to all occupants. If the sender is not an occupant of the room, the service SHOULD return a ¬acceptable; error to the sender and SHOULD NOT reflect the message to all occupants; the only exception to this rule is that an implementation MAY allow users with certain privileges (e.g., a room owner, room admin, or service-level admin) to send messages to the room even if those users are not occupants.</p>
<section2topic='Registering with a Room'anchor='register'>
<p>An implementation MAY allow an unaffiliated user (in a moderated room, normally a participant) to register with a room and thus become a member of the room (conversely, an implementation MAY restrict this privilege and allow only room admins to add new members). In particular, it is not possible to join a members-only room without being on the member list, so an entity may need to request membership in order to join such a room.</p>
<p>If allowed, this functionality SHOULD be implemented by enabling a user to send a request for registration requirements to the room qualified by the 'jabber:iq:register' namespace as described in &xep0077;:</p>
<p>If the user requesting registration requirements is not allowed to register with the room (e.g., because that privilege has been restricted), the room MUST return a ¬allowed; error to the user. If the user is already registered, the room MUST reply with an IQ stanza of type "result" that contains an empty <register/> element as described in <cite>XEP-0077</cite>. If the room does not exist, the service MUST return an ¬found; error.</p>
<p>Otherwise, the room MUST then return a Data Form to the user (as described in &xep0004;). The information required to register MAY vary by implementation or deployment and is not fully specified in this document (e.g., the fields registered by this document for the 'http://jabber.org/protocol/muc#register' FORM_TYPE may be supplemented in the future via the mechanisms described in the <linkurl="#registrar-formtype">Field Standardization</link> section of this document). The following can be taken as a fairly typical example:</p>
<p>After the user submits the form, the service MAY request that the submission be approved by a room admin/owner (see the <linkurl='#regapprove'>Approving Registration Requests</link> section of this document) or MAY immediately add the user to the member list by changing the user's affiliation from "none" to "member". If the service changes the user's affiliation and the user is in the room, it MUST send updated presence from this individual to all occupants, indicating the change in affiliation by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member".</p>
<examplecaption="Service Sends Notice of Membership to All Occupants"><![CDATA[
<p>If a user has registered with a room, the room MAY choose to restrict the user to use of the registered nickname only in that room. If it does so, it SHOULD return a ¬acceptable; error to the user if the user attempts to join the room with a roomnick other than the user's registered roomnick (this enables a room to "lock down" roomnicks for consistent identification of occupants).</p>
<p>If allowed in accordance with room configuration, an occupant MAY be allowed to retrieve the list of room members. For details, see the <linkurl='#modifymember'>Modifying the Member List</link> section of this document.</p>
<p>A user MAY have a reserved room nickname, for example through explicit room registration, database integration, or nickname "lockdown". A user SHOULD discover his or her reserved nickname before attempting to enter the room. This is done by sending a Service Discovery information request to the room JID while specifying a well-known Service Discovery node of "x-roomuser-item".</p>
<p>It is OPTIONAL for a multi-user chat service to support the foregoing service discovery node. If the room or service does not support the foregoing service discovery node, it MUST return a &feature; error to the user. If it does and the user has a registered nickname, it MUST return the nickname to the user as the value of the 'name' attribute of a Service Discovery <identity/> element (for which the category/type SHOULD be "conference/text"):</p>
<p>If the user does not have a registered nickname, the room MUST return a service discovery &QUERY; element that is empty (in accordance with <cite>XEP-0030</cite>).</p>
<p>Even if a user has registered one room nickname, the service SHOULD allow the user to specify a different nickname on entering the room (e.g., in order to join from different client resources), although the service MAY choose to "lock down" nicknames and therefore deny entry to the user, including a ¬acceptable; error. The service MUST NOT return an error to the user if his or her client sends the foregoing request after having already joined the room, but instead SHOULD reply as described above.</p>
<p>If another user attempts to join the room with a nickname reserved by the first user, the service MUST deny entry to the second user and return a &conflict; error as previously described.</p>
<p>It is not possible for a visitor to speak (i.e., send a message to all occupants) in a moderated room. To request voice, a visitor SHOULD send a &MESSAGE; stanza containing a data form to the room itself, where data form contains only a 'muc#role' field with a value of "participant".</p>
<p>The service then SHOULD forward the request to the room moderator(s) as described in the <linkurl='#voiceapprove'>Approving Voice Requests</link> section of this document.</p>
</section2>
</section1>
<section1topic='Moderator Use Cases'anchor='moderator'>
<p>A moderator has privileges to perform certain actions within the room (e.g., to change the roles of some occupants) but does not have rights to change persistent information about affiliations (which may be changed only by an admin or owner) or defining information about the room. Exactly which actions may be performed by a moderator is subject to configuration. However, for the purposes of the MUC framework, moderators are stipulated to have privileges to perform the following actions:</p>
<olstart='1'>
<li>discover an occupant's full JID in a semi-anonymous room (occurs by default as shown above)</li>
<li>modify the subject</li>
<li>kick a participant or visitor from the room</li>
<li>grant or revoke voice in a moderated room</li>
<li>modify the list of occupants who have voice in a moderated room</li>
</ol>
<p>These features shall be implemented with a request/response exchange using <iq/> elements that contain children 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 <user@host> 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>
<section2topic='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 SHOULD be configurable, with the result that a mere participant or even visitor may be allowed to change the subject if desired). The subject is changed by sending a message of type "groupchat" to the &ROOM;, where the &MESSAGE; MUST contain a <subject/> element that specifies the new subject but SHOULD NOT contain any other element (e.g., no &BODY; element or &THREAD; element).</p>
<p>If a MUC service receives such a message, it MUST reflect the message to all other occupants with a 'from' address equal to the room JID that corresponds to the sender of the subject change:</p>
<examplecaption='Service Informs All Occupants of Subject Change'><![CDATA[
* secondwitch has changed the subject to: Fire Burn and Cauldron Bubble!
]]></example>
<p>If someone without appropriate privileges attempts to change the room subject, the service MUST return a message of type "error" specifying a &forbidden; error condition:</p>
<examplecaption='Service Returns Error Related to Unauthorized Subject Change'><![CDATA[
<p>In order to remove the existing subject but not provide a new subject (i.e., set the subject to be empty), the client shall send an empty <subject/> element (i.e., either "<subject/>" or "<subject></subject>").</p>
<section2topic='Kicking an Occupant'anchor='kick'>
<p>A moderator has permissions kick certain kinds of occupants from a room (which occupants are "kickable" depends on service provisioning, room configuration, and the moderator's affiliation -- see below). The kick is normally performed based on the occupant's room nickname (though it MAY be based on the full JID) and is completed by setting the role of a participant or visitor to a value of "none".</p>
<p>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.</p>
<p>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. <note>Some commentors have complained that this opens room owners and administrators up to potential abuse; unfortunately, with great power comes great responsibility.</note></p>
<p>After removing the kicked occupant(s), the service MUST then inform the moderator of success:</p>
<examplecaption='Service Informs Moderator of Success'><![CDATA[
<iqfrom='harfleur@henryv.shakespeare.lit'
id='kick1'
to='fluellen@shakespeare.lit/pda'
type='result'/>
]]></example>
<p>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.</p>
<p>A user cannot be kicked by a moderator with a lower affiliation. Therefore, if a moderator who is a participant attempts to kick an admin or a moderator who is a participant or admin attempts to kick an owner, the service MUST deny the request and return a ¬allowed; error to the sender:</p>
<examplecaption='Service Returns Error on Attempt to Kick User With Higher Affiliation'><![CDATA[
<p>If a moderator attempts to kick himself, the service MAY deny the request and return a &conflict; error to the sender. (Although the act of kicking oneself may seem odd, it is common in IRC as a way of apologizing for one's actions in the room.)</p>
</section2>
<section2topic='Granting Voice to a Visitor'anchor='grantvoice'>
<p>In a moderated room, a moderator may want to manage who does and does not have "voice" in the room (i.e., the ability to send messages to all occupants). Voice is granted based on the visitor's room nickname, which the service will convert into the visitor's full JID internally. The moderator grants voice to a visitor by changing the visitor's role to "participant".</p>
<p>The service MUST then send updated presence from this individual's &ROOMJID; to all occupants, indicating the addition of voice privileges by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "participant".</p>
<examplecaption="Service Sends Notice of Voice to All Occupants"><![CDATA[
<section2topic='Revoking Voice from a Participant'anchor='revokevoice'>
<p>In a moderated room, a moderator may want to revoke a participant's privileges to speak. The moderator can revoke voice from a participant by changing the participant's role to "visitor":</p>
<examplecaption='Moderator Revokes Voice from a Participant'><![CDATA[
<p>The service MUST then send updated presence from this individual to all occupants, indicating the removal of voice privileges by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "visitor".</p>
<examplecaption="Service Notes Loss of Voice"><![CDATA[
<p>A moderator MUST NOT be able to revoke voice from a user whose affiliation is at or above the moderator's level. In addition, a service MUST NOT allow the voice privileges of an admin or owner to be removed by anyone. If a moderator attempts to revoke voice privileges from such a user, the service MUST deny the request and return a ¬allowed; error to the sender along with the offending item(s):</p>
<examplecaption='Service Returns Error on Attempt to Revoke Voice from an Admin, Owner, or User with a Higher Affiliation'><![CDATA[
<section2topic='Modifying the Voice List'anchor='modifyvoice'>
<p>A moderator in a moderated room may want to modify the voice list. To do so, the moderator first requests the voice list by querying the room for all occupants with a role of 'participant'.</p>
<p>The service MUST then return the voice list to the moderator; each item MUST include the 'nick' and 'role' attributes and SHOULD include the 'affiliation' and 'jid' attributes:</p>
<examplecaption='Service Sends Voice List to Moderator'><![CDATA[
<p>The moderator MAY then modify the voice list. In order to do so, the moderator MUST send the changed items (i.e., only the "delta") back to the service; each item MUST include the 'nick' attribute and 'role' attribute (normally set to a value of "participant" or "visitor") but SHOULD NOT include the 'jid' attribute and MUST NOT include the 'affiliation' attribute (which is used to manage affiliations such as owner rather than the participant role):</p>
<examplecaption='Moderator Sends Modified Voice List to Service'><![CDATA[
<p>The service MUST then inform the moderator of success:</p>
<examplecaption='Service Informs Moderator of Success'><![CDATA[
<iqfrom='goodfolk@chat.shakespeare.lit'
id='voice1'
to='bard@shakespeare.lit/globe'
type='result'/>
]]></example>
<p>The service MUST then send updated presence for any affected individuals to all occupants, indicating the change in voice privileges by sending the appropriate extended presence stanzas as described in the foregoing use cases.</p>
<p>As noted, voice privileges cannot be revoked from a room owner or room admin, nor from any user with a higher affiliation than the moderator making the request. If a room admin attempts to revoke voice privileges from such a user by modifying the voice list, the service MUST deny the request and return a ¬allowed; error to the sender:</p>
<examplecaption='Service Returns Error on Attempt to Revoke Voice from an Admin, Owner, or User with a Higher Affiliation'><![CDATA[
<p>As noted in the <linkurl='#requestvoice'>Requesting Voice</link> 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 SHOULD send 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.</p>
<p>If a moderator approves the voice request, the service shall grant voice to the occupant and send a presence update as described in the <linkurl='#grantvoice'>Granting Voice to a Visitor</link> section of this document.</p>
</section2>
</section1>
<section1topic='Admin Use Cases'anchor='admin'>
<p>A room administrator has privileges to modify persistent information about user affiliations (e.g., by banning users) and to grant and revoke moderator privileges, but does not have rights to change the defining features of the room, which are the sole province of the room owner(s). Exactly which actions may be performed by a room admin will be subject to configuration. However, for the purposes of the MUC framework, room admins are stipulated to at a minimum have privileges to perform the following actions:</p>
<olstart='1'>
<li>ban a user from the room</li>
<li>modify the list of users who are banned from the room</li>
<li>grant or revoke membership</li>
<li>modify the member list</li>
<li>grant or revoke moderator privileges</li>
<li>modify the list of moderators</li>
</ol>
<p>These features shall be implemented with a request/response exchange using <iq/> elements that contain children qualified by the 'http://jabber.org/protocol/muc#admin' namespace. The examples below illustrate the protocol interactions that implement the desired functionality. (Except where explicitly noted below, any of the following administrative requests MUST be denied if the <user@host> of the 'from' address of the request does not match the bare JID of one of the room admins; in this case, the service MUST return a &forbidden; error.)</p>
<section2topic='Banning a User'anchor='ban'>
<p>An admin or owner can ban one or more users from a room. The ban MUST be performed based on the occupant's bare JID. In order to ban a user, an admin MUST change the user's affiliation to "outcast".</p>
<p>The service MUST add that bare JID to the ban list, SHOULD remove the outcast's nickname from the list of registered nicknames, and MUST inform the admin or owner of success:</p>
<examplecaption='Service Informs Admin or Owner of Success'><![CDATA[
<iqfrom='southampton@henryv.shakespeare.lit'
id='ban1'
to='kinghenryv@shakespeare.lit/throne'
type='result'/>
]]></example>
<p>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.</p>
<p>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 banned user to understand why he or she was banned, and by whom if the banned user would like to discuss the matter.</p>
<p>The service MUST then inform all of the remaining occupants that the banned user is no longer in the room by sending presence stanzas of type "unavailable" from the banned user to all 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:</p>
<p>As with <linkurl='#kick'>Kicking an Occupant</link>, a user cannot be banned by an admin with a lower affiliation. Therefore, if an admin attempts to ban an owner, the service MUST deny the request and return a ¬allowed; error to the sender:</p>
<examplecaption='Service Returns Error on Attempt to Ban User With Higher Affiliation'><![CDATA[
<p>If an admin or owner attempts to ban himself, the service MUST deny the request and return a &conflict; error to the sender. (Note: This is different from the recommended service behavior on kicking oneself, which a service may allow.)</p>
</section2>
<section2topic='Modifying the Ban List'anchor='modifyban'>
<p>A room admin may want to modify the ban list. Note: The ban list is always based on a user's bare JID. To modify the list of banned JIDs, the admin first requests the ban list by querying the room for all users with an affiliation of 'outcast'.</p>
<p>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:</p>
<examplecaption='Service Sends Ban List to Admin'><![CDATA[
<p>The admin MAY then modify the ban list. In order to do so, the admin MUST send the changed items (i.e., only the "delta") back to the service; each item MUST include the 'affiliation' attribute (normally set to a value of "outcast" to ban or "none" to remove ban) and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than the outcast affiliation); in addition, the reason and actor elements are OPTIONAL:</p>
<examplecaption='Admin Sends Modified Ban List to Service'><![CDATA[
<p>After updating the ban list, the service MUST inform the admin of success:</p>
<examplecaption='Service Informs Admin of Success'><![CDATA[
<iqfrom='southampton@henryv.shakespeare.lit'
id='ban3'
to='kinghenryv@shakespeare.lit/throne'
type='result'/>
]]></example>
<p>The service MUST then remove the affected occupants (if they are in the room) and send updated presence (including the appropriate status code) from them to all the remaining occupants as described in the "Banning a User" use case. (The service SHOULD also remove each banned user's reserved nickname from the list of reserved roomnicks, if appropriate.)</p>
<p>When an entity is banned from a room, an implementation SHOULD match JIDs in the following order (these matching rules are the same as those defined for privacy lists in <cite>RFC 3921</cite>):</p>
<olstart='1'>
<li><user@domain/resource> (only that resource matches)</li>
<p>Some administrators may wish to ban all users associated with a specific domain from all rooms hosted by a MUC service. Such functionality is a service-level feature and is therefore out of scope for this document, instead being defined in <cite>XEP-0133</cite>.</p>
<p>An admin can grant membership to a user; this is done by changing the user's affiliation to "member" (normally based on nick if the user is in the room, or on bare JID if not; in either case, if the nick is provided, that nick becomes the user's default nick in the room if that functionality is supported by the implementation):</p>
<p>If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the granting of membership by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member".</p>
<examplecaption="Service Sends Notice of Membership to All Occupants"><![CDATA[
<p>If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the granting of membership by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member".</p>
<examplecaption="Service Sends Notice of Membership to All Occupants"><![CDATA[
<p>The service MUST then send updated presence from this individual to all occupants, indicating the loss of membership by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "none".</p>
<examplecaption="Service Notes Loss of Membership"><![CDATA[
<p>If the room is members-only, the service MUST remove the user from the room, including a status code of 321 to indicate that the user was removed because of an affiliation change, and inform all remaining occupants:</p>
<section2topic='Modifying the Member List'anchor='modifymember'>
<p>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".</p>
<p>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 may appear in a room roster, have their room nickname reserved, be returned in search results or FAQ queries, and the like.</p>
<p>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":</p>
<examplecaption='Admin Requests Member List'><![CDATA[
<p>Note: A service SHOULD also return the member list to any occupant in a members-only room; i.e., it SHOULD NOT generate a &forbidden; error when a member in the room requests the member list. This functionality may assist clients in showing all the existing members even if some of them are not in the room, e.g. to help a member determine if another user should be invited. A service SHOULD also allow any member to retrieve the member list even if not yet an occupant.</p>
<p>The service MUST then return the full member list to the admin qualified by the 'http://jabber.org/protocol/muc#admin' namespace; each item MUST include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and 'role' attributes for each members that is currently an occupant.</p>
<examplecaption='Service Sends Member List to Admin'><![CDATA[
<p>The admin MAY then modify the member list. In order to do so, the admin MUST send the changed items (i.e., only the "delta") to the service; each item MUST include the 'affiliation' attribute (normally set to a value of "member" or "none") and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than the member affiliation):</p>
<examplecaption='Admin Sends Modified Member List to Service'><![CDATA[
<p>The service MUST change the affiliation of any affected user. If the user has been removed from the member list, the service MUST change the user's affiliation from "member" to "none". If the user has been added to the member list, the service MUST change the user's affiliation to "member".</p>
<p>If a removed member is currently in a members-only room, the service SHOULD kick the occupant by changing the removed member's role to "none" and send appropriate presence to the removed member as previously described. No matter whether the removed member was in or out of a members-only room, the service MUST subsequently refuse entry to the user.</p>
<p>For all room types, the service MUST send updated presence from this individual to all occupants, indicating the change in affiliation by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "none".</p>
<examplecaption="Service Sends Notice of Loss of Membership to All Occupants"><![CDATA[
<p>In addition, the service SHOULD send an invitation to any user who has been added to the member list of a members-only room if the user is not currently affiliated with the room, for example as an admin or owner (such a user would by definition not be in the room; note also that this example includes a password but not a reason -- both child elements are OPTIONAL):</p>
<examplecaption='Room Sends Invitation to New Member'><![CDATA[
<p>While only admins and owners SHOULD be allowed to modify the member list, an implementation MAY provide a configuration option that opens invitation privileges to any member of a members-only room. In such a situation, any invitation sent SHOULD automatically trigger the addition of the invitee to the member list. However, if invitation privileges are restricted to admins and a mere member attempts to a send an invitation, the service MUST deny the invitation request and return a &forbidden; error to the sender:</p>
<examplecaption='Service Returns Error on Attempt by Mere Member to Invite Others to a Members-Only Room'><![CDATA[
<p>Invitations sent through an open room MUST NOT trigger the addition of the invitee to the member list.</p>
<p>If a user is added to the member list of an open room and the user is in the room, the service MUST send updated presence from this individual to all occupants, indicating the change in affiliation by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member".</p>
<examplecaption="Service Sends Notice of Membership to All Occupants"><![CDATA[
<p>The service MUST then send updated presence from this individual to all occupants, indicating the addition of moderator privileges by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "moderator".</p>
<examplecaption="Service Sends Notice of Moderator Privileges to All Occupants"><![CDATA[
<section2topic='Revoking Moderator Privileges'anchor='revokemod'>
<p>An admin may want to revoke a user's moderator privileges. An admin MAY revoke moderator privileges only from a user whose affiliation is "member" or "none" (i.e., not from an owner or admin). The privilege is revoked by changing the user's role to "participant":</p>
<examplecaption='Admin Revokes Moderator Privileges'><![CDATA[
<p>The service MUST then send updated presence from this individual to all occupants, indicating the removal of moderator privileges by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "participant".</p>
<examplecaption="Service Notes Loss of Moderator Privileges"><![CDATA[
<p>As noted, an admin MUST NOT be allowed to revoke moderator privileges from a user whose affiliation is "owner" or "admin". If an admin attempts to revoke moderator privileges from such a user, the service MUST deny the request and return a ¬allowed; error to the sender:</p>
<examplecaption='Service Returns Error on Attempt to Revoke Moderator Privileges from an Admin or Owner'><![CDATA[
<section2topic='Modifying the Moderator List'anchor='modifymod'>
<p>An admin may want to modify the moderator list. To do so, the admin first requests the moderator list by querying the room for all users with a role of 'moderator'.</p>
<examplecaption='Admin Requests Moderator List'><![CDATA[
<p>The service MUST then return the moderator list to the admin; each item MUST include the 'jid', 'nick', and 'role' attributes and SHOULD include the 'affiliation' attribute:</p>
<examplecaption='Service Sends Moderator List to Admin'><![CDATA[
<p>The admin MAY then modify the moderator list. In order to do so, the admin MUST send the changed items (i.e., only the "delta") back to the service; each item MUST include the 'jid' attribute and 'role' attribute (normally set to a value of "member" or "participant") but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'affiliation' attribute (which is used to manage affiliations such as admin rather than the moderator role):</p>
<examplecaption='Admin Sends Modified Moderator List to Service'><![CDATA[
<p>The service MUST then send updated presence for any affected individuals to all occupants, indicating the change in moderator privileges by sending the appropriate extended presence stanzas as described in the foregoing use cases.</p>
<p>As noted, moderator privileges cannot be revoked from a room owner or room admin. If a room admin attempts to revoke moderator privileges from such a user by modifying the moderator list, the service MUST deny the request and return a ¬allowed; error to the sender:</p>
<examplecaption='Service Returns Error on Attempt to Revoke Moderator Privileges from an Admin or Owner'><![CDATA[
<p>If a service does not automatically accept requests to register with a room, it MAY provide a way for room admins to approve or deny registration requests over Jabber (alternatively, it could provide a web interface or some other admin tool). The simplest way to do so is for the service to send a &MESSAGE; stanza to the room admin(s) when the registration request is received, where the &MESSAGE; stanza contains a Data Form asking for approval or denial of the request. The following Data Form is RECOMMENDED but implementations MAY use a different form entirely, or supplement the following form with additional fields.</p>
<p>More advanced registration approval mechanisms (e.g., retrieving a list of registration requests using &xep0050; as is done in &xep0060;) are out of scope for this document.</p>
<p>Every room MUST have at least one owner, and that owner (or a successor) is a long-lived attribute of the room for as long as the room exists (e.g., the owner does not lose ownership on exiting a persistent room). This document assumes that the (initial) room owner is the individual who creates the room and that only a room owner has the right to change defining room configuration settings such as the room type. Ideally, room owners will be able to specify not only the room types (password-protected, members-only, etc.) but also certain attributes of the room as listed in the <linkurl='#reqs'>Requirements</link> section of this document. In addition, it would be good if an owner were able to specify the JIDs of other owners, but that shall be determined by the implementation.</p>
<p>In order to provide the necessary flexibility for a wide range of configuration options, Data Forms (<cite>XEP-0004</cite>) shall be used for room configuration, triggered by use of the 'http://jabber.org/protocol/muc' namespace. That is, if an entity does not include the MUC namespace in its room join/create request, then the service shall create the room and not wait for configuration via Data Forms before creating the room (this ensures backwards-compatibility with the old "groupchat 1.0" protocol); however, if the room join/create request includes the MUC extension, then the service shall require configuration via Data Forms before creating and unlocking the room.</p>
<p>Note: The configuration options shown below address all of the features and room types listed in the requirements section of this document; however, the exact configuration options and form layout shall be determined by the implementation or specific deployment. Also, these are examples only and are not intended to define the only allowed or required configuration options for rooms. A given implementation or deployment MAY choose to provide additional configuration options (profanity filters, setting the default language for a room, message logging, etc.), which is why the use of the 'jabber:x:data' protocol is valuable here.</p>
<section2topic='Creating a Room'anchor='createroom'>
<p>The privilege to create rooms MAY be restricted to certain users or MAY be reserved to an administrator of the service. If access is restricted and a user attempts to create a room, the service MUST return a ¬allowed; error:</p>
<examplecaption='Service Informs User of Inability to Create a Room'><![CDATA[
<p>If access is not restricted, the service MUST allow the user to create a room as described below.</p>
<p>From the perspective of room creation, there are in essence two kinds of rooms:</p>
<ul>
<li><p>"Instant rooms" -- these are available for immediate access and are automatically created based on some default configuration.</p></li>
<li><p>"Reserved rooms" -- these are manually configured by the room creator before anyone is allowed to enter.</p></li>
</ul>
<p>The workflow for creating and configuring such rooms is as follows:</p>
<olstart='1'>
<li><p>The user MUST send presence to &ROOMJID; and signal his or her support for the Multi-User Chat protocol by including extended presence information in an empty <x/> child element qualified by the 'http://jabber.org/protocol/muc' namespace (note the lack of an '#owner' or '#user' fragment).</p></li>
<li><p>If this user is allowed to create a room and the room does not yet exist, the service MUST create the room according to some default configuration, assign the requesting user as the initial room owner, and add the owner to the room but not allow anyone else to enter the room (effectively "locking" the room). The initial presence stanza received by the owner from the room MUST include extended presence information indicating the user's status as an owner and acknowledging that the room has been created (via status code 201) and is awaiting configuration.</p></li>
<li><p>If the initial room owner would like to create and configure a reserved room, the room owner MUST then request a configuration form by sending an IQ stanza of type "get" to the room containing an empty <query/> element qualified by the 'http://jabber.org/protocol/muc#owner' namespace, then complete Steps 4 and 5. If the room owner would prefer to create an instant room, the room owner MUST send a query element qualified by the 'http://jabber.org/protocol/muc#owner' namespace and containing an empty <x/> element of type "submit" qualified by the 'jabber:x:data' namespace, then skip to Step 6.</p></li>
<li><p>If the room owner requested a configuration form, the service MUST send an IQ to the room owner containing a configuration form qualified by the 'jabber:x:data' namespace. If there are no configuration options available, the room MUST return an empty query element to the room owner.</p></li>
<li><p>The initial room owner SHOULD provide a starting configuration for the room (or accept the default configuration) by sending an IQ of type "set" containing the completed configuration form. Alternatively, the room owner MAY cancel the configuration process. (An implementation MAY set a timeout for initial configuration, such that if the room owner does not configure the room within the timeout period, the room owner is assumed to have accepted the default configuration or to have cancelled the configuration process.)</p></li>
<li><p>Once the service receives the completed configuration form from the initial room owner (or receives a request for an instant room), the service MUST "unlock" the room (i.e., allow other users to enter the room) and send an IQ of type "result" to the room owner. If the service receives a cancellation, it MUST destroy the room.</p></li>
</ol>
<p>The protocol for this workflow is shown in the examples below.</p>
<p>First, the Jabber user MUST send presence to the room, including an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace (this is the same stanza sent when seeking to enter a room).</p>
<p>If the room does not yet exist, the service SHOULD create the room (subject to local policies regarding room creation), assign the bare JID of the requesting user as the owner, add the owner to the room, and acknowledge successful creation of the room by sending a presence stanza of the following form:</p>
<p>After receiving notification that the room has been created, the room owner needs to decide whether to accept the default room configuration (i.e., create an "instant room") or configure the room to have something other than the default room configuration (i.e., create a "reserved room"). The protocol flows for completing those two use cases are shown in the following sections.</p>
<p>Note: If the presence stanza sent to a nonexistent room does not include an &X; element qualified by the 'http://jabber.org/protocol/muc' namespace as shown above, the service SHOULD create a default room without delay (i.e., it MUST assume that the client supports "groupchat 1.0" rather than Multi-User Chat and therefore it MUST NOT lock the room while waiting for the room creator to either accept an instant room or configure a reserved room).</p>
</section3>
<section3topic='Creating an Instant Room'anchor='createroom-instant'>
<p>If the initial room owner wants to accept the default room configuration (i.e., create an "instant room"), the room owner MUST decline an initial configuration form by sending an IQ set to the &ROOM; itself containing a &QUERY; element qualified by the 'http://jabber.org/protocol/muc#owner' namespace, where the only child of the &QUERY; is an empty &X; element that is qualified by the 'jabber:x:data' namespace and that possesses a 'type' attribute whose value is "submit":</p>
<p>The service MUST then unlock the room and allow other entities to join it.</p>
</section3>
<section3topic='Creating a Reserved Room'anchor='createroom-reserved'>
<p>If the initial room owner wants to create and configure a reserved room, the room owner MUST request an initial configuration form by sending an IQ get to the &ROOM; itself containing an empty &QUERY; element qualified by the 'http://jabber.org/protocol/muc#owner' namespace:</p>
<p>If the room does not already exist, the service MUST return an initial room configuration form to the user. (Note: The following example shows a representative sample of configuration options. A full list of x:data fields registered for use in room creation and configuration is maintained by the XMPP Registrar; see the <linkurl="#registrar">XMPP Registrar Considerations</link> section of this document.)</p>
<p>Note: The _whois configuration option specifies whether the room is non-anonymous (a value of "anyone"), semi-anonymous (a value of "moderators"), or fully anonmyous (a value of "none", not shown here).</p>
<p>If there are no configuration options available, the service MUST return an empty query element to the room owner:</p>
<examplecaption='Service Informs Owner that No Configuration is Possible'><![CDATA[
<p>If the room creation fails because the specified room configuration options violate one or more service policies (e.g., because the password for a password-protected room is blank), the service MUST return a ¬acceptable; error.</p>
<examplecaption='Service Informs Owner that Requested Configuration Options Are Unacceptable'><![CDATA[
<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 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; or to &ROOM; (or both). The service MUST then destroy the room, sending a presence stanza of type "unavailable" from the room to the owner including a <destroy/> element and reason (if provided) as defined in the <linkurl='#destroyroom'>Destroying a Room</link> section of this document.</p>
<section3topic='Requesting a Unique Room Name'anchor='createroom-unique'>
<p>In some situations (e.g., when <linkurl='#continue'>Converting a One-to-One Chat Into a Conference</link>), the room creator may want to request a unique room name before attempting to create the room (e.g., to avoid the possibility of a room conflict). In order to facilitate this, a service MAY support the feature described in this section. (If a service does support this feature, it MUST return a feature of "http://jabber.org/protocol/muc#unique" in its response to service discovery information requests.)</p>
<p>The room creator requests a unique room name by sending an IQ-get to the service itself, containing an empty <unique/> element qualified by the 'http://jabber.org/protocol/muc#unique' namespace:</p>
<p>If the service supports this feature, it SHOULD return a unique room name as the XML character data of the <unique/> element (but not create the room):</p>
<p>The service MAY refuse to return a unique room name to entities that are not entitled to create rooms, entities that have sent an excessive number of requests for unique room names, etc.</p>
<p>The service MAY use any algorithm that ensures the creation of a room name that will be permanently unique in the context of the service (e.g., a SHA-1 hash of the requesting JID, datetime, and random salt).</p>
<p>The room creator would then use the XML character data of the <unique/> element as the node identifier portion of the room JID it requests:</p>
<examplecaption='Owner Creates Room With Unique Name'><![CDATA[
<p>At any time after specifying the initial configuration of the room, a room owner may want to change the configuration. In order to initiate this process, a room owner MUST request a new configuration form from the room by sending an IQ to &ROOM; containing an empty <query/> element qualified by the 'http://jabber.org/protocol/muc#owner' namespace.</p>
<p>If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender:</p>
<examplecaption='Service Denies Configuration Access to Non-Owner'><![CDATA[
<p>If there are no configuration options available, the service MUST return an empty query element to the room owner as shown in the previous use case.</p>
<p>The room owner SHOULD then submit the form with updated configuration information.</p>
<p>Alternatively, the room owner MAY cancel the configuration process:</p>
<p>If the room owner cancels the subsequent configuration, the service MUST leave the configuration of the room as it was before the room owner initiated the subsequent configuration process.</p>
<p>If as a result of a change in the room configuration a room admin loses administrative privileges while the admin is in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member" and the 'role' attribute set to a value of "participant" or "visitor" as appropriate for the affiliation level and the room type:</p>
<examplecaption="Service Notes Loss of Admin Affiliation"><![CDATA[
<p>If as a result of a change in the room configuration a user gains administrative privileges while the user is in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to a value of "admin":</p>
<examplecaption="Service Notes Gain of Admin Affiliation to All Users"><![CDATA[
<p>If as a result of a change in the room configuration a room owner loses owner privileges while that owner is in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to an appropriate value given the affiliation and room type ("moderator" is recommended).</p>
<examplecaption="Service Notes Loss of Owner Affiliation"><![CDATA[
<p>A service MUST NOT allow an owner to revoke his or her own ownership privileges if there are no other owners; if an owner attempts to do this, the service MUST return a &conflict; error to the owner. However, a service SHOULD allow an owner to revoke his or her own ownership privileges if there are other owners.</p>
<p>If as a result of a change in the room configuration a user gains ownership privileges while the user is in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "owner" and the 'role' attribute set to an appropriate value given the affiliation and room type ("moderator" is recommended).</p>
<examplecaption="Service Notes Gain of Owner Affiliation to All Users"><![CDATA[
<p>If as a result of a change in the room configuration the room type is changed to members-only but there are non-members in the room, the service MUST remove any non-members from the room and include a status code of 322 in the presence unavailable stanzas sent to those users as well as any remaining occupants.</p>
<section3topic='Notification of Configuration Changes'anchor='roomconfig-notify'>
<p>A room MUST send notification to all occupants when the room configuration changes in a way that has an impact on the privacy or security profile of the room. This notification shall consist of a &MESSAGE; stanza containing an &X; element qualified by the 'http://jabber.org/protocol/muc#user' namespace, which shall contain only a <status/> element with an appropriate value for the 'code' attribute. Here is an example:</p>
<examplecaption='Configuration Status Code'><![CDATA[
<p>The codes to be generated as a result of a privacy-related change in room configuration are as follows:</p>
<ul>
<li>If room logging is now enabled, status code 170.</li>
<li>If room logging is now disabled, status code 171.</li>
<li>If the room is now non-anonymous, status code 172.</li>
<li>If the room is now semi-anonymous, status code 173.</li>
<li>If the room is now fully-anonymous, status code 174.</li>
</ul>
<p>For any other configuration change, the room SHOULD send status code 104 so that interested occupants can retrieve the updated room configuration if desired.</p>
<p>If allowed by an implementation, an owner MAY grant ownership privileges to another user; this is done by changing the user's affiliation to "owner":</p>
<p>If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the granting of ownership privileges by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "owner" and the 'role' attribute set to an appropriate value given the affiliation and room type ("moderator" is recommended).</p>
<examplecaption="Service Sends Notice of Ownership Privileges to All Occupants"><![CDATA[
<p>If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the granting of ownership privileges by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "owner".</p>
<examplecaption="Service Sends Notice of Ownership Privileges to All Occupants"><![CDATA[
<p>An implementation MAY allow an owner to revoke another user's ownership privileges; this is done by changing the user's affiliation to something other than "owner":</p>
<p>A service MUST NOT allow an owner to revoke his or her own ownership privileges if there are no other owners; if an owner attempts to do this, the service MUST return a &conflict; error to the owner. However, a service SHOULD allow an owner to revoke his or her own ownership privileges if there are other owners.</p>
<p>If an implementation does not allow one owner to revoke another user's ownership privileges, the implementation MUST return a ¬authorized; error to the owner who made the request.</p>
<p>Note: Allowing an owner to remove another user's ownership privileges can compromise the control model for room management; therefore this feature is OPTIONAL, and implementations are encouraged to support owner removal through an interface that is open only to individuals with service-wide administrative privileges.</p>
<p>If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the loss of ownership privileges by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value other than "owner" and the 'role' attribute set to an appropriate value:</p>
<examplecaption="Service Notes Loss of Owner Affiliation"><![CDATA[
<p>If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the loss of ownership privileges by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value other than "owner".</p>
<examplecaption="Service Notes Loss of Owner Affiliation"><![CDATA[
<section2topic='Modifying the Owner List'anchor='modifyowner'>
<p>If allowed by an implementation, a room owner may want to modify the owner list. To do so, the owner first requests the owner list by querying the room for all users with an affiliation of 'owner'.</p>
<p>If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender.</p>
<p>Otherwise, the service MUST then return the owner list to the owner; each item MUST include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and 'role' attributes for any owner that is currently an occupant:</p>
<examplecaption='Service Sends Owner List to Owner'><![CDATA[
<p>The owner MAY then modify the owner list. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; <note>This is different from the behavior of room configuration, wherein the 'muc#roomconfig_roomowners' field specifies the full list of room owners, not the delta.</note> each item MUST include the 'affiliation' and 'jid' attributes but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than the owner affiliation):</p>
<examplecaption='Owner Sends Modified Owner List to Service'><![CDATA[
<p>Only owners shall be allowed to modify the owner list. If a non-owner attempts to view or modify the owner list, the service MUST deny the request and return a &forbidden; error to the sender:</p>
<examplecaption='Service Returns Error on Attempt by Non-Owner to Modify Owner List'><![CDATA[
<p>A service MUST NOT allow an owner to revoke his or her own ownership privileges if there are no other owners; if an owner attempts to do this, the service MUST return a &conflict; error to the owner. However, a service SHOULD allow an owner to revoke his or her own ownership privileges if there are other owners.</p>
<p>In all other cases, the service MUST modify owner list and then inform the owner of success:</p>
<examplecaption='Service Informs Owner of Success'><![CDATA[
<p>The service MUST also send presence notifications related to any affiliation changes that result from modifying the owner list as previously described.</p>
<p>If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the granting of administrative privileges by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to an appropriate value given the affiliation and room type.</p>
<examplecaption="Service Sends Notice of Administrative Privileges to All Occupants"><![CDATA[
<p>If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the granting of administrative privileges by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "admin".</p>
<examplecaption="Service Sends Notice of Administrative Privileges to All Occupants"><![CDATA[
<p>An owner may want to revoke a user's administrative privileges; this is done by changing the user's affiliation to something other than "admin" or "owner":</p>
<p>If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the loss of administrative privileges by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value other than "admin" or "owner" and the 'role' attribute set to an appropriate value given the affiliation level and the room type:</p>
<p>If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the loss of administrative privileges by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value other than "admin".</p>
<examplecaption="Service Notes Loss of Admin Affiliation"><![CDATA[
<section2topic='Modifying the Admin List'anchor='modifyadmin'>
<p>A room owner may want to modify the admin list. To do so, the owner first requests the admin list by querying the room for all users with an affiliation of 'admin'.</p>
<p>If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender.</p>
<p>Otherwise, the service MUST then return the admin list to the owner; each item MUST include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and 'role' attributes for any admin that is currently an occupant:</p>
<examplecaption='Service Sends Admin List to Owner'><![CDATA[
<p>The owner MAY then modify the admin list. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; <note>This is different from the behavior of room configuration, wherein the 'muc#roomconfig_roomadmins' field specifies the full list of room admins, not the delta.</note> each item MUST include the 'affiliation' attribute (normally set to a value of "admin" or "none") and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than the admin affiliation):</p>
<examplecaption='Owner Sends Modified Admin List to Service'><![CDATA[
<p>Only owners shall be allowed to modify the admin list. If a non-owner attempts to view or modify the admin list, the service MUST deny the request and return a &forbidden; error to the sender:</p>
<examplecaption='Service Returns Error on Attempt by Non-Owner to Modify Admin List'><![CDATA[
<p>The service MUST also send presence notifications related to any affiliation changes that result from modifying the admin list as previously described.</p>
</section2>
<section2topic='Destroying a Room'anchor='destroyroom'>
<p>A room owner MUST be able to destroy a room, especially if the room is persistent. The workflow is as follows:</p>
<olstart='1'>
<li><p>The room owner requests that the room be destroyed, specifying a reason and an alternate venue if desired.</p></li>
<li><p>The room removes all users from the room (including appropriate information about the alternate location and the reason for being removed) and destroys the room, even if it was defined as persistent.</p></li>
</ol>
<p>Other than the foregoing, this document does not specify what (if anything) a MUC service implementation shall do as a result of a room destruction request. For example, if the room was defined as persistent, an implementation MAY choose to lock the room ID so that it cannot be re-used, redirect enter requests to the alternate venue, or invite the current participants to the new room; however, such behavior is OPTIONAL.</p>
<p>In order to destroy a room, the room owner MUST send an IQ set to the address of the room to be destroyed. The &IQ; stanza shall contain a &QUERY; element qualified by the 'http://jabber.org/protocol/muc#owner' namespace, which in turn shall contain a <destroy/> element. The address of the alternate venue MAY be provided as the value of the <destroy/> element's 'jid' attribute. A password for the alternate venue MAY be provided as the XML character data of a <password/> child element of the <destroy/> element. The reason for the room destruction MAY be provided as the XML character data of a <reason/> child element of the <destroy/> element.</p>
<p>The following examples illustrate the protocol elements to be sent and received:</p>
<p>The service is responsible for removing all the occupants. It SHOULD NOT broadcast presence stanzas of type "unavailable" from all occupants, instead sending only one presence stanza of type "unavailable" to each occupant so that the user knows he or she has been removed from the room. If extended presence information specifying the JID of an alternate location and the reason for the room destruction was provided by the room owner, the presence stanza MUST include that information.</p>
<examplecaption='Service Removes Each Occupant'><![CDATA[
<p>If the <user@host> of the 'from' address received on a destroy request does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender:</p>
<examplecaption='Service Denies Destroy Request Submitted by Non-Owner'><![CDATA[
<p>The error codes associated with the 'http://jabber.org/protocol/muc#user' namespace are fairly straightforward, as summarized in the following table. For detailed information about mapping legacy error codes to XMPP-style error types and conditions, refer to &xep0086;; implementations SHOULD support both legacy and XMPP error handling.</p>
<p>Multi-User Chat uses a <status/> element (specifically, the 'code' attribute of the <status/> element) to communicate information about a user's status in a room. Over time, the number of status codes has grown quite large, and new status codes continue to be requested of the author. Therefore, these codes are now documented in a registry maintained by the XMPP Registrar. For details, refer to the <linkurl='#registrar-statuscodes'>Status Codes Registry</link> section of this document.</p>
<p>Note: In general, MUC status codes tend to follow the "philosophy" of status codes that is implicit in &rfc2616; and &rfc1893; (1xx codes are informational, 2xx codes specify that it is fine to continue, 3xx codes specify redirects such as being kicked or banned, x3x codes refer to system status, x7x codes refer to security or policy matters, etc.).</p>
<p>Note: If the MUC protocol were being designed today, it would specify a more flexible, XML-friendly approach rather than hardcoded status numbers; however, at this point the pain of changing the status reporting system would be greater than the benefit of doing so, which is why the status code numbers remain in use. A future version of this document may define a more XMPP-like approach to status conditions, retaining the code numbers but supplementing them with more descriptive child elements as is done in <cite>RFC 3920</cite>.</p>
<p>As specified in <cite>RFC 3920</cite>, XMPP entities (including MUC rooms and MUC services) SHOULD respect the value of the 'xml:lang' attribute provided with any given stanza. However, simultaneous translation of groupchat messages is out of scope for this document.</p>
<p>The status and error codes defined herein enable a client implementation to present a localized interface; however, definition of the localized text strings for any given language community is out of scope for this document.</p>
<p>Although the labels for various data form fields are shown here in English, MUC clients SHOULD present localized text for these fields rather than the English text.</p>
<section2topic='User Authentication and Authorization'anchor='security-auth'>
<p>No room entrance authentication or authorization method more secure than cleartext passwords is defined or required by this document. However, the risks involved can mitigated by the use of channel encryption and strong authentication via TLS and SASL as described in <cite>RFC 3920</cite>.</p>
<p>No end-to-end message or session encryption method is specified herein. Users SHOULD NOT trust a service to keep secret any text sent through a room.</p>
<p>Depending on room configuration, a room may publicly log all discussions held in the room. A service MUST warn the user that the room is publicly logged by returning a status code of "170" with the user's initial presence, and the user's client MUST so warn the user if the room discussion is logged (a user's client SHOULD also query the room for its configuration prior to allowing the user to enter in order to "pre-discover" whether the room is logged). A client MUST also warn the user if the room's configuration is subsequently modified to allow room logging (which the client will discover when the room sends status code 170). Note: In-room history is different from public room logging, and naturally a room cannot effectively prevent occupants from separately maintaining their own room logs, which may become public; users SHOULD exercise due caution and consider any room discussions to be effectively public.</p>
<p>Depending on room configuration, a room MAY expose each occupant's real JID to other occupants (if the room is non-anonymous) and will almost certainly expose each occupant's real JID to the room owners and administrators (if the room is not fully-anonymous). A service MUST warn the user that real JIDs are exposed in the room by returning a status code of "100" with the user's initial presence, and the user's client MUST so warn the user (a user's client SHOULD also query the room for its configuration prior to allowing the user to enter in order to "pre-discover" whether real JIDs are exposed in the room). A client MUST also warn the user if the room's configuration is subsequently modified from semi-anonymous or fully-anonymous to non-anonymous (which the client will discover when the room sends status code 172) and SHOULD warn the user if the room's configuration is subsequently modified from fully-anonymous to semi-anonymous (which the client will discover when the room sends status code 173).</p>
<section2topic='Denial of Service'anchor='security-dos'>
<p>Public MUC rooms can be subject to a number of attacks, most of which reduce to denial of service attacks. Such attacks include but are not limited to:</p>
<ol>
<li>Stuffing the room with a large number of illegitimate occupants and therefore preventing legitimate users from joining the room.</li>
<li>Sending abusive messages and then leaving the room before a kick or ban can be applied; such abusive messages include but are not limited to large messages that prevent participants from following the conversation thread or room history, personal attacks on participants (especially room administrators and moderators), offensive text, and links to spam sites.</li>
<li>Making rapid and repeated presence changes.</li>
<li>Using long nicknames to route around lack of voice.</li>
<li>Abusing the room administrators or other room occupants.</li>
<li>Registering multiple nicknames across a service and therefore denying the use of those nicknames.</li>
<li>Mimicking another occupant's roomnick (e.g., by adding a space at the end or substituting visually similar characters), then sending messages from that roomnick in an effort to confuse the occupants.</li>
</ol>
<p>These attacks can be mitigated but not completely prevented through the liberal use of administrative actions such as banning, the presence of automated room bots with administrative privileges, implementation of intelligent content filtering, checking the IP addresses of connected users (not always possible in a distributed system), applying voice rules to presence as well as messaging, matching room nicks using more stringent rules than the Resourceprep profile of stringprep, etc. However, experience has shown that it is impossible to fully prevent attacks of this kind.</p>
<p>There are many features related to a MUC service or room that can be discovered by means of Service Discovery. The most fundamental of these is the 'http://jabber.org/protocol/muc' namespace. In addition, a MUC room SHOULD provide information about the specific room features it implements, such as password protection and room moderation.</p>
<p>The well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' enables discovery of the namespaces that are allowed in traffic sent through a room (see the <linkurl='#impl-service-traffic'>Allowable Traffic</link> section of this document).</p>
<p>&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. Within MUC, there are four uses of such forms: room registration (the "muc#register" FORM_TYPE), requesting voice and approving voice requests ("muc#request"), room configuration ("muc#roomconfig"), and service discovery extensions for room information ("muc#roominfo"). The reserved fields are defined below.</p>
<p>The XMPP Registrar maintains a registry of values for the 'code' attribute of the <status/> element when qualified by the 'http://jabber.org/protocol/muc#user' namespace.</p>
<p>The application MUST either present an interface enabling the user to provide a room nickname or populate the room nickname based on configured preferences or nickname discovery.</p>
<p>If the joining user is not yet in the room, the application MUST send two stanzas: the first to join the room and the second to invite the other individual. If the joining user is in the room already, the application shall send only the invitation stanza.</p>
<p>If the joining user is not yet in the room, the application MUST send two stanzas: the first to join the room and the second to invite the other individual. If the joining user is in the room already, the application shall send only the invitation stanza.</p>
<examplecaption='Invite Action With Password: Resulting Stanza(s)'><![CDATA[
<desc>the password required to enter a multi-user chat room</desc>
</key>
</keys>
</querytype>
]]></code>
</section3>
</section2>
</section1>
<section1topic='Business Rules'anchor='bizrules'>
<section2topic='Addresses'anchor='bizrules-jids'>
<p>In order to provide consistency regarding the addresses captured in room JIDs, Room IDs MUST match the Nodeprep profile of Stringprep and Room Nicknames MUST match the Resourceprep profile of Stringprep (both of these are defined in <cite>RFC 3920</cite>). Although not explicitly stated in <cite>RFC 3920</cite>, both the Room ID (node) and Room Nickname (resource) portions of a Room JID MUST be of non-zero length. In addition, a MUC service MUST NOT allow empty or invisible Room Nicknames (i.e., Room Nicknames that consist only of one or more space characters).</p>
<p>It is up to the service implementation whether it will further restrict roomnicks (e.g., by applying case folding routines, the Nodeprep profile of stringprep, or other restrictions).</p>
<li><p>If an occupant wants to send a message to all other occupants, a MUC client MUST set the 'type' attribute to a value of "groupchat". A service MAY ignore messages that are improperly typed, or reject them with a &badrequest; error.</p></li>
<li><p>If a MUC service receives a message directed to the room or to a single occupant from a Jabber user who has a role of "none", the service MUST NOT deliver the message and SHOULD return the message to the sender with a &forbidden; error.</p></li>
<li><p>If a MUC service receives a message directed to a room that does not exist or is not yet unlocked, the service SHOULD return the message to the sender with an ¬found; error.</p></li>
<li><p>A MUC service SHOULD pass extended information (e.g., an XHTML version of the message body) through to occupants unchanged; however, a MUC service MAY disallow message specific extensions (see the <linkurl='#impl-service-traffic'>Allowable Traffic</link> section of this document).</p></li>
<li><p>A MUC client MAY generate extensions that conform to the &xep0022; or &xep0085; specification; however, a MUC service MAY disallow these extensions (see the <linkurl='#impl-service-traffic'>Allowable Traffic</link> section of this document).</p></li>
<li><p>A room MUST silently ignore unavailable presence received from a user who has a role of "none".</p></li>
<li><p>Only the MUC service itself SHOULD generate extended presence information about roles, affiliations, full JIDs, or status codes qualified by the 'http://jabber.org/protocol/muc#user' namespace (based on information the service knows about occupants, e.g., roles, or as a result of actions taken by a moderator or room administrator). A client SHOULD NOT presume to generate such information. If a MUC service receives such extended presence information from an occupant, it MUST NOT reflect it to other occupants. (A client MAY generate extended presence information qualified by the 'http://jabber.org/protocol/muc#user' namespace in order to supply a password, but naturally this is not reflected to other occupants.)</p></li>
<li><p>A MUC service SHOULD allow all other presence information to pass through, although it MAY choose to block extended presence information; see the <linkurl='#impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
<li><p>In order to appropriately inform occupants of room roles and affiliations, and to make it easier for Jabber clients to track the current state of all users in the room, MUC service implementations MUST provide extended presence information about roles and affiliations in all presence stanzas, including presence stanzas of type "unavailable" sent when a user exits the room for any reason.</p></li>
<li><p>If a privilege is revoked, the service MUST note that by sending an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child element with the 'role' and/or 'affiliation' attributes set to a value that indicates the loss of the relevant privilege. All future presence stanzas for the occupant MUST include the updated role and affiliation, until and unless they change again.</p></li>
<li><p>A MUC service MUST send extended presence to a client even if the client did not send an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace on entering the room; naturally, a client MUST ignore such information if it does not understand it (in accordance with <cite>RFC 3920</cite>).</p></li>
<li><p>Extended presence about roles and affiliations sent in the muc#user namespace MUST include the full JID (not the bare JID) as the value of the 'jid' attribute.</p></li>
<li><p>A client MAY send a custom exit message if desired (as is often done in IRC channels) by including a <status/> element in the presence stanza of type "unavailable" sent when exiting a room.</p></li>
</ol>
</section2>
<section2topic='IQ'anchor='bizrules-iq'>
<olstart='1'>
<li><p>If an occupant wants to send an IQ stanza to another user in a non-anonymous room, the sender SHOULD send the request directly to the recipient's bare JID or full JID, rather than attempting to send the request through the room (i.e., via the recipient's room JID).</p></li>
<li><p>If an occupant wants to send an IQ stanza to another user in a semi-anonymous room, the sender can direct the stanza to the recipient's room JID and the service MAY forward the stanza to the recipient's real JID. However, a MUC service MUST NOT reveal the sender's real JID to the recipient at any time, nor reveal the recipient's real JID to the sender.</p></li>
<li><p>A MUC client MUST send only the 'affiliation' attribute or the 'role' attribute in the <item/> element contained within an IQ set qualified by the 'http://jabber.org/protocol/muc#admin' namespace; if a moderator, admin, or owner attempts to modify both the affiliation and role of the same item in the same IQ set, the service MUST return a &badrequest; error to the sender. However, a MUC service MAY modify a role based on a change to an affiliation and thus MAY send presence updates that include both a modified role and a modified affiliation.</p></li>
<li><p>In IQ sets regarding roles, a MUC client MUST include the 'nick' attribute only; in IQ results regarding roles, a MUC service MUST include the 'nick', 'role', 'affiliation', and 'jid' attributes (with the value of the latter set to the user's full JID).</p></li>
<li><p>In IQ sets regarding affiliations, a MUC client MUST include the 'jid' attribute only (with the value set to the bare JID); in IQ results regarding affiliations, a MUC service MUST NOT include the 'role' attribute, MUST include the 'affiliation' attribute and the 'jid' attribute (with the value set to the bare JID), and SHOULD include the 'nick' attribute (except if the affiliation is "outcast", since outcasts SHOULD NOT have reserved nicknames).</p></li>
<li><p>In handling messages sent by visitors in a moderated room, a MUC service MAY queue each message for approval by a moderator and MAY inform the sender that the message is being held for approval; however, such behavior is OPTIONAL, and definition of a message approval protocol (e.g., using Data Forms as defined in <cite>XEP-0004</cite>) is out of scope for this document.</p></li>
<li><p>It is common for MUC services to provide in-room messages when certain events occur, such as when the subject changes, when an occupant enters or exits, or when a room is destroyed. Such messages are entirely OPTIONAL and are left up to the implementation or deployment, but if used MUST be messages of type "groupchat" sent from the room JID itself (&ROOM;) rather than a specific occupant (&ROOMJID;). However, in general it is preferable for the receiving client to generate such messages based on events in the room (e.g., user entrances and exits) as well as specific status codes provided in MUC; this will help ensure correct localization of such messages.</p></li>
<li><p>Out of courtesy, a MUC service MAY send an out-of-room <message/> to an occupant who is kicked or banned, and MAY broadcast an in-room <message/> to all remaining occupants informing them that the occupant has been kicked or banned from the room. However, such messages are OPTIONAL, and indeed are unnecessary since the information required for a receiving client to generate such messages is communicated in the presence stanzas (specifically the status codes) sent by a MUC service.</p></li>
<li><p>Out of courtesy, a MUC service MAY send an out-of-room <message/> if a user's affiliation changes while the user is not in the room; the message SHOULD be sent from the room to the user's bare JID, MAY contain a <body/> element describing the affiliation change, and MUST contain a status code of 101.</p></li>
<li><p>There is no requirement that a MUC service shall provide special treatment for users of the older "groupchat 1.0" protocol, such as messages that contain equivalents to the extended presence information that is qualified by the 'http://jabber.org/protocol/muc#user' namespace.</p></li>
<li><p>Room types MAY be configured in any combination. A MUC service MAY support or allow any desired room types or combinations thereof.</p></li>
<li><p>A MUC service MAY limit the number of configuration options presented to an owner after initial configuration has been completed, e.g. because certain options cannot take effect without restarting the service.</p></li>
<li><p>A MUC service MAY provide an interface to room creation and configuration (e.g., in the form of a special Jabber user or a Web page), so that the ostensible room owner is actually the application instead of a human user.</p></li>
<li><p>A MUC service MAY choose to make available a special in-room resource that provides an interface to administrative functionality (e.g., a "user" named "ChatBot"), which occupants could interact with directly, thus enabling admins to type <tt>'/command parameter'</tt> in a private message to that "user". Obviously this kind of implementation would require the service to add a 'ChatBot' user to the room when it is created, and to prevent any occupant from having the nickname 'ChatBot' in the room. This might be difficult to ensure in some implementations or deployments. In any case, any such interface is OPTIONAL.</p></li>
<li><p>A MUC service SHOULD remove a user if the service receives a delivery-related error in relation to a stanza it has previously sent to the user; the delivery-related errors are &gone;, ¬found;, &recipient;, &redirect;, &remoteserver;, and &timeout;.</p></li>
<li><p>A MUC service MAY choose to discard extended presence information that is attached to a &PRESENCE; stanza before reflecting the presence change to the occupants of a room. That is, an implementation MAY choose to reflect only the <show/>, <status/>, and <priority/> child elements of the presence element as specified in the XML schema for the 'jabber:client' namespace, with the result that presence "changes" in extended namespaces (e.g., gabber:x:music:info) are not passed through to occupants. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the <linkurl='#impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
<li><p>A MUC service MAY choose to discard extended information attached to &MESSAGE; stanzas before reflecting the message to the occupants of a room. An example of such extended information is the lightweight text markup specified by &xep0071;. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the <linkurl='#impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
<li><p>A MUC service MAY choose to "lock down" room nicknames (e.g., hardcoding the room nickname to the bare JID of the occupant). If so, the service MUST treat the locked down nickname as a reserved room nickname and MUST support the protocol specified in the <linkurl='#reservednick'>Discovering Reserved Room Nickname</link> section of this document.</p></li>
<p>As noted, a service (more precisely, a properly-configured room) MAY discard some or all extended namespaces attached to &MESSAGE; and &PRESENCE; stanzas that are intended for reflection from the sender through the room to all of the room occupants. If the room does so, it SHOULD enable senders to discover the list of allowable extensions by sending a disco#info query to the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic', returning one <feature/> element for each namespace supported in the result. If the room does not allow any extended namespaces, it MUST return an empty query as specified in <cite>XEP-0030</cite>. If the room does not support the "#traffic" node, it MUST return a &feature; error in response to queries sent to the 'http://jabber.org/protocol/muc#traffic' node.</p>
<p>The following example shows a room that allows the 'http://jabber.org/protocol/xhtml-im' and 'http://jabber.org/protocol/rosterx' namespaces only, but no other extended namespaces.</p>
<examplecaption='User Queries Service Regarding Allowable Namespaces'><![CDATA[
<li><p>Jabber clients MAY present room roles by showing ad-hoc groups for each role within a room roster. This will enable occupants to clearly visualize which occupants are moderators, participants, and visitors. However, such a representation is OPTIONAL.</p></li>
<li><p>Jabber clients MAY implement a variety of interface styles that provide "shortcuts" to functionality such as changing one's nickname, kicking or banning users, discovering an occupant's full JID, or changing the subject. One option consists of IRC-style commands such as '/nick', '/kick', '/ban', and '/whois'; another is to enable a user to right-click items in a room roster. All such interface styles are OPTIONAL. However, for convenience, a mapping of IRC commands to MUC protocols is provided below.</p></li>
<p>Internet Relay Chat clients use a number of common "shortcut" commands that begin with a forward slash, such as '/nick' and '/ban'. The following table provides a mapping of IRC-style commands to MUC protocols, for use by Jabber clients that wish to support such functionality.</p>
<tablecaption='IRC Command Mapping'>
<tr>
<th>Command</th>
<th>Function</th>
<th>MUC protocol</th>
</tr>
<tr>
<td>/ban <roomnick> [comment]</td>
<td>bans user with that roomnick from this room (client translates roomnick to bare JID)</td>
<td>exits this room (some IRC clients also support /leave)</td>
<td><code><![CDATA[
<presenceto='room@service/nick'
type='unavailable'>
<status>comment</status>
</presence>
]]></code></td>
</tr>
<tr>
<td>/topic <foo></td>
<td>changes subject of this room to "foo"</td>
<td><code><![CDATA[
<messageto='room@service'type='groupchat'>
<subject>foo</subject>
</message>
]]></code></td>
</tr>
</table>
<p>Note: Because MUC roomnicks follow the Resourceprep profile of stringprep, they are allowed to contain a space character, whereas IRC nicknames do not. Although a given client MAY support quotation characters for this purpose (resulting in commands such as '/ban "king lear" insanity is no defense'), most common quotation characters (such as " and ') are also allowed by Resourceprep, thus leading to added complexity and potential problems with quotation of roomnicks that contain both spaces and quotation characters. Therefore it is NOT RECOMMENDED for Jabber clients to support IRC-style shortcut commands with roomnicks that contain space characters.</p>
<p>Note: Many Jabber clients also implement a '/me ' command as described in &xep0245;. This command does not result in any MUC or IRC protocol action and is therefore not shown in the foregoing table.</p>
<p>The author would like to thank the following individuals for their many helpful comments on various drafts of this proposal: David Sutton, Peter Millard, Joe Hildebrand, Craig Kaes, Alexey Shchepin, David Waite, Jean-Louis Seguineau, Jacek Konieczny, Gaston Dombiak, and many others in the jdev@conference.jabber.org conference room and on the Standards mailing list.</p>
