<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>
<li>Corrected some examples of presence and message errors so that the 'from' and 'to' addresses are merely swapped, in accordance with RFC 6120; also added 'by' attribute to show that the room itself generated the error.</li>
<li>Added 'nick' attribute to <actor/> element so that an action can be attributed either to a real JID or to a roomnick.</li>
<li>Clarified the meaning of status code 100.</li>
<li>Corrected delayed delivery text and examples so that the 'from' address is that of the room, and specified optional inclusion of the XEP-0033 'ofrom' address to note original sender.</li>
<li>Added 'id' attributes to most examples, especially message and presence stanzas generated by the room since IDs can be used for tracking purposes and ghost detection.</li>
<li>Added term "Occupant JID" to differentiate between the JID of a <room@service> and the JID of a <room@service/nick>.</li>
<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 or Occupant 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>
<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 <inviter/> 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 admin status; adjusted DTD to track all changes.</p></remark>
<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 status, and modifying the moderator list; organized the sections in a more logical manner.</p></remark>
<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>
<remark><p>Removed SHA1 passwords; specified that room shall add passwords on invitations to password-protected rooms (not supplied by inviter).</p></remark>
<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>
<remark><p>Changed all non-groupchat-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>
<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/XMPP community developed and implemented a basic groupchat protocol as long ago as 1999. That "groupchat 1.0" (GC) protocol provided a minimal feature set for chat rooms but was rather limited in scope. This specification (Multi-User Chat or MUC) is not compatible to the groupchat 1.0 protocol, 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/XMPP community or are familiar from existing text-based conference environments (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>
<li>Advanced features such as attaching files to a room, integrating whiteboards, and using MUC rooms as a way to manage the signalling for multi-user audio or video conferencing (see &xep0272;)</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 client and service developers alike. Future specifications might address the topics mentioned above.</p>
<p>This document addresses the minimal functionality provided by Jabber-based multi-user chat services that existed in 2002 when development of MUC began. This design is based on the original groupchat 1.0 protocol, with the result that:</p>
<li>Each room is identified as a "room JID" &ROOMJID; (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 an "occupant JID" &OCCUPANTJID;, 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>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>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>
<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>
<di><dt>Affiliation</dt><dd>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.</dd></di>
<di><dt>Ban</dt><dd>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".</dd></di>
<di><dt>Bare JID</dt><dd>The <user@host> by which a user is identified outside the context of any existing session or resource; contrast with Full JID and Occupant JID.</dd></di>
<di><dt>Full JID</dt><dd>The <user@host/resource> by which an online user is identified outside the context of a room; contrast with Bare JID and Occupant JID.</dd></di>
<di><dt>GC</dt><dd>The minimal "groupchat 1.0" protocol developed within the Jabber community in 1999; Old versions of MUC were backwards-compatible with GC.</dd></di>
<di><dt>Invitation</dt><dd>A special message sent from one user to another asking the recipient to join a room; the invitation can be sent directly (see &xep0249;) or mediated through the room (as described under <linkurl='#invite'>Inviting Another User to a Room</link>).</dd></di>
<di><dt>Kick</dt><dd>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".</dd></di>
<di><dt>Logging</dt><dd>Storage of discussions that occur within a room for public retrieval outside the context of the room.</dd></di>
<di><dt>Member</dt><dd>A user who is on the "permitted" list for a members-only room or who is registered with an open room. A member has an affiliation of "member".</dd></di>
<di><dt>Moderator</dt><dd>A room role that is usually associated with room admins but that can be granted to non-admins; is allowed to kick users, grant and revoke voice, etc. A moderator has a role of "moderator".</dd></di>
<di><dt>Multi-Session Nick</dt><dd>If allowed by the service, a user can associate more than one full JID with the same occupant JID (e.g., the user juliet@capulet.lit is allowed to log in simultaneously as the nick "JuliC" in the characters@chat.shakespeare.lit chatroom from both juliet@capulet.lit/balcony and juliet@capulet.lit/chamber). Multi-session nicks are not currently defined in this document.</dd></di>
<di><dt>Occupant JID</dt><dd>The <room@service/nick> by which an occupant is identified within the context of a room; contrast with Bare JID and Full JID.</dd></di>
<di><dt>Participant</dt><dd>An occupant who does not have admin status; in a moderated room, a participant is further defined as having voice (in contrast to a visitor). A participant has a role of "participant".</dd></di>
<di><dt>Private Message</dt><dd>A message sent from one occupant directly to another's occupant JID (not to the room itself for broadcasting to all occupants).</dd></di>
<di><dt>Role</dt><dd>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.</dd></di>
<di><dt>Room</dt><dd>A virtual space that users figuratively enter in order to participate in real-time, text-based conferencing with other users.</dd></di>
<di><dt>Room Administrator</dt><dd>A user empowered by the room owner to perform administrative functions such as banning users; however, a room administrator is not allowed to change the room configuration or to destroy the room. An admin has an affiliation of "admin".</dd></di>
<di><dt>Room ID</dt><dd>The localpart of a Room JID, which might be opaque and thus lack meaning for human users (see under <linkurl='#bizrules'>Business Rules</link> for syntax); contrast with Room Name.</dd></di>
<di><dt>Room Name</dt><dd>A user-friendly, natural-language name for a room, configured by the room owner and presented in Service Discovery queries; contrast with Room ID.</dd></di>
<di><dt>Room Nickname</dt><dd>The resourcepart of an Occupant JID (see <linkurl='#bizrules'>Business Rules</link> for syntax); this is the "friendly name" by which an occupant is known in the room.</dd></di>
<di><dt>Room Owner</dt><dd>The user who created the room or a user who has been designated by the room creator or owner as someone with owner status (if allowed); an owner is allowed to change the room configuration and destroy the room, in addition to all admin status. An owner has an affiliation of "owner".</dd></di>
<di><dt>Room Roster</dt><dd>A client's representation of the occupants in a room.</dd></di>
<di><dt>Server</dt><dd>An XMPP server that may or may not have associated with it a text-based conferencing service.</dd></di>
<di><dt>Service</dt><dd>A host that offers text-based conferencing capabilities; often but not necessarily a sub-domain of an XMPP server (e.g., conference.jabber.org).</dd></di>
<di><dt>Subject</dt><dd>A temporary discussion topic within a room.</dd></di>
<di><dt>Visit</dt><dd>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.</dd></di>
<di><dt>Visitor</dt><dd>In a moderated room, an occupant who does not have voice (in contrast to a participant). A visitor has a role of "visitor".</dd></di>
<di><dt>Voice</dt><dd>In a moderated room, the privilege to send messages to all occupants.</dd></di>
<di><dt>Hidden Room</dt><dd>A room that cannot be found by any user through normal means such as searching and service discovery; antonym: Public Room.</dd></di>
<di><dt>Members-Only Room</dt><dd>A room that a user cannot enter without being on the member list; antonym: Open Room.</dd></di>
<di><dt>Moderated Room</dt><dd>A room in which only those with "voice" are allowed to send messages to all occupants; antonym: Unmoderated Room.</dd></di>
<di><dt>Non-Anonymous Room</dt><dd>A room in which an occupant's full JID is exposed to all other occupants, although the occupant can request any desired room nickname; contrast with Semi-Anonymous Room.</dd></di>
<di><dt>Open Room</dt><dd>A room that non-banned entities are allowed to enter without being on the member list; antonym: Members-Only Room.</dd></di>
<di><dt>Password-Protected Room</dt><dd>A room that a user cannot enter without first providing the correct password; antonym: Unsecured Room.</dd></di>
<di><dt>Persistent Room</dt><dd>A room that is not destroyed if the last occupant exits; antonym: Temporary Room.</dd></di>
<di><dt>Public Room</dt><dd>A room that can be found by any user through normal means such as searching and service discovery; antonym: Hidden Room.</dd></di>
<di><dt>Semi-Anonymous Room</dt><dd>A room in which an occupant's full JID can be discovered by room admins only; contrast with Non-Anonymous Room.</dd></di>
<di><dt>Temporary Room</dt><dd>A room that is destroyed if the last occupant exits; antonym: Persistent Room.</dd></di>
<di><dt>Unmoderated Room</dt><dd>A room in which any occupant is allowed to send messages to all occupants; antonym: Moderated Room.</dd></di>
<di><dt>Unsecured Room</dt><dd>A room that anyone is allowed to enter without first providing the correct password; antonym: Password-Protected Room.</dd></di>
<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 "coven@chat.shakespeare.lit" chatroom. The characters are as follows:</p>
<section1topic='Roles, Affiliations, and Privileges'anchor='associations'>
<p>A user might be allowed to perform any number of actions in a room, from joining or sending a message to changing configuration options or destroying the room altogether. We call each permitted action a "privilege". There are two ways we might structure privileges:</p>
<ol>
<li><p>Define each privilege atomically and explicitly define each user's particular privileges; this is flexible but can be confusing to manage.</p></li>
<li><p>Define bundles of privileges that are generally applicable and assign a user-friendly "shortcut" to each bundle (e.g., "moderator" or "admin").</p></li>
</ol>
<p>MUC takes the second approach.</p>
<p>MUC also defines two different associations: long-lived affiliations and session-specific roles. These two association types are distinct from each other in MUC, 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 role 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 (depending on room configuration, it is even possible that visitors' presence will not be broadcasted to the room).</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 (if the room is configured to broadcast presence for a given role).</p>
<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 all the privileges possessed by the next-lowest role, plus additional privileges; these privileges are specified in the following table as defaults (an implementation MAY provide configuration options that override these defaults).</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>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 (if the room is configured to broadcast presence from entities with a given role). Role changes and their triggering actions are specified in the following table.</p>
<p>* A moderator SHOULD NOT be allowed to revoke moderation privileges from someone with a higher affiliation than themselves (i.e., an unaffiliated moderator SHOULD NOT be allowed to revoke moderation privileges from an admin or an owner, and an admin SHOULD NOT be allowed to revoke moderation privileges from an owner).</p>
<pclass='box'>Note: Certain roles are typically implicit in certain affiliations. For example, an admin or owner is automatically a moderator, so if an occupant is granted an affiliation of admin then the occupant will by that fact be granted a role of moderator; similarly, when an occupant is granted an affiliation of member in a moderated room, the occupant automatically has a role of participant. However, the loss of the admin affiliation does not necessarily mean that the occupant no longer has a role of moderator (since a "mere" occupant can be a moderator). Therefore, the role that is gained when an occupant is granted a certain affiliation is stable, whereas the role that is lost when an occupant loses a certain affilitation is not hardcoded and is left up to the implementation.</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, not the nick as with roles.</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 "permitted" list 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 register with an open room and thus be lastingly associated with that room in some way (one result might be that the service could reserve the user's nickname in the room).</p>
<p>Information about affiliations MUST be sent in all presence stanzas generated or reflected by the room and sent to occupants (if the room is configured to broadcast presence from entities with a given role).</p>
<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 all the privileges possessed by the next-lowest affiliation, plus additional privileges; these privileges are specified in the following table.</p>
<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>** As noted, a moderator SHOULD NOT be allowed to revoke moderation privileges from someone with a higher affiliation than themselves (i.e., an unaffiliated moderator SHOULD NOT be allowed to revoke moderation privileges from an admin or an owner, and an admin SHOULD NOT be allowed to revoke moderation privileges from an owner).</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 (if the room is configured to broadcast presence from entities with a given role). Affiliation changes and their triggering actions are specified in the following table.</p>
<section2topic='Discovering the Features Supported by a MUC Service'anchor='disco-service-features'>
<p>An 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 MUC service's JID.</p>
<p>The service discovery items ("disco#items") protocol enables an entity 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='Entity Queries Chat Service for Rooms'><