<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE xep SYSTEM 'xep.dtd' [

<!ENTITY % ents SYSTEM 'xep.ent'>

%ents;

<!ENTITY ROOMJID "&lt;room@service&gt;">

<!ENTITY OCCUPANTJID "&lt;room@service/nick&gt;">

]>

<?xml-stylesheet type='text/xsl' href='xep.xsl'?>

<xep>

<header>

<title>Multi-User Chat</title>

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

&LEGALNOTICE;

<number>0045</number>

<status>Draft</status>

<type>Standards Track</type>

<sig>Standards</sig>

<approver>Council</approver>

<dependencies>

<spec>XMPP Core</spec>

<spec>XMPP IM</spec>

<spec>XEP-0004</spec>

<spec>XEP-0030</spec>

<spec>XEP-0068</spec>

<spec>XEP-0082</spec>

<spec>XEP-0128</spec>

</dependencies>

<supersedes/>

<supersededby/>

<shortname>muc</shortname>

<schemaloc>

<ns>muc</ns>

<url>http://www.xmpp.org/schemas/muc.xsd</url>

</schemaloc>

<schemaloc>

<ns>muc#admin</ns>

<url>http://www.xmpp.org/schemas/muc-admin.xsd</url>

</schemaloc>

<schemaloc>

<ns>muc#owner</ns>

<url>http://www.xmpp.org/schemas/muc-owner.xsd</url>

</schemaloc>

<schemaloc>

<ns>muc#user</ns>

<url>http://www.xmpp.org/schemas/muc-user.xsd</url>

</schemaloc>

<registry/>

&stpeter;

<revision>

<version>1.35.1</version>

<date>2024-09-17</date>

<initials>gk</initials>

<remark><p>Add explicit error definition when non-owners attempt to use owner-specific functionality.</p></remark>

</revision>

<revision>

<version>1.35.0</version>

<date>2024-08-14</date>

<initials>gk</initials>

<remark>

<ul>

<li>Remove references to using resourceparts when banning users.</li>

<li>Explicitly disallow Ban List modifications that clash with 'Banning a User' conditions.</li>

<li>Status code purpose no longer hints that recipient is the affected user</li>

<li>Improved 'Service Removes Non-Member' example.</li>

<li>Clarify usage of presence stanzas when removing a non-member from a members-only room.</li>

<li>Replace inappropriate RFC 2119 key word usage in §9.7.</li>

<li>Presence sent to occupants of a destroyed room includes a &lt;destroy/&gt; element.</li>

<li>Explicitly use bare JIDs when operating on affiliations.</li>

<li>Allow non-owners to retrieve owner and admin lists in non-anonymous rooms.</li>

<li>Members should be allowed to retrieve the member list only in non-anonymous rooms.</li>

</ul>

</remark>

</revision>

<revision>

<version>1.34.6</version>

<date>2024-05-01</date>

<initials>pep</initials>

<remark><p>Remove contradicting keyword on sending subject in §7.2.2.</p></remark>

</revision>

<revision>

<version>1.34.5</version>

<date>2022-12-01</date>

<initials>NC</initials>

<remark><p>Add MUC service shut down example.</p></remark>

</revision>

<revision>

<version>1.34.4</version>

<date>2022-10-05</date>

<initials>pep</initials>

<remark><p>Remove more mentions of Group Chat 1.0.</p></remark>

</revision>

<revision>

<version>1.34.3</version>

<date>2022-03-08</date>

<initials>egp</initials>

<remark><p>Remove more mentions of Group Chat 1.0.</p></remark>

</revision>

<revision>

<version>1.34.2</version>

<date>2021-06-24</date>

<initials>lk</initials>

<remark><p>Clean up anonymous types values.</p></remark>

</revision>

<revision>

<version>1.34.1</version>

<date>2021-03-04</date>

<initials>mw</initials>

<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>

</revision>

<revision>

<version>1.34.0</version>

<date>2020-10-28</date>

<initials>jsc</initials>

<remark><p>Specify the use of a delay element in the initial subject message.</p></remark>

</revision>

<revision>

<version>1.33.0</version>

<date>2020-04-15</date>

<initials>mw</initials>

<remark><p>Clarify that the 307 status code should not be used alongside 333 for user disconnects.</p></remark>

</revision>

<revision>

<version>1.32.0</version>

<date>2019-05-15</date>

<initials>gl</initials>

<remark><p>Remove Group Chat 1.0 compatibility due to operational issues.</p></remark>

</revision>

<revision>

<version>1.31.2</version>

<date>2018-07-31</date>

<initials>jwi</initials>

<remark><p>Add implementation note about legacy invitations.</p></remark>

</revision>

<revision>

<version>1.31.1</version>

<date>2018-03-12</date>

<initials>kis</initials>

<remark>

<p>Fix the wrong JID in an example.</p>

</remark>

</revision>

<revision>

<version>1.31</version>

<date>2018-03-06</date>

<initials>gl</initials>

<remark>

<p>Require the service to maintain the 'id' attribute on message reflections.</p>

</remark>

</revision>

<revision>

<version>1.30</version>

<date>2018-02-23</date>

<initials>jwi</initials>

<remark>

<p>Add 333 status code with OPTIONAL feature.</p>

</remark>

</revision>

<revision>

<version>1.29</version>

<date>2017-09-01</date>

<initials>gl</initials>

<remark>

<p>Clarify wording for a client re-syncing to a MUC</p>

</remark>

</revision>

<revision>

<version>1.28</version>

<date>2017-05-31</date>

<initials>gl</initials>

<remark>

<p>Introduce &lt;x/&gt; tag in MUC-PMs to support better Carbon delivery.</p>

</remark>

</revision>

<revision>

<version>1.27.1</version>

<date>2016-12-03</date>

<initials>XEP Editor: ssw</initials>

<remark>

<p>Editorial typo and whitespace fixes.</p>

</remark>

</revision>

<revision>

<version>1.27</version>

<date>2016-10-29</date>

<initials>XEP Editor: ssw</initials>

<remark>

<ul>

<li>Clarify behavior on MUC join.</li>

</ul>

</remark>

</revision>

<revision>

<version>1.26</version>

<date>2016-05-16</date>

<initials>XEP Editor (ssw)</initials>

<remark>

<ul>

<li>Add status code to self-presence example.</li>

<li>muc#roomconfig_allowpm should be list-single.</li>

<li>muc#roomconfig_allowinvites should be boolean.</li>

<li>Typo: Publish-Subscribe.</li>

<li>15.6.2 Initial Submission: Status code 174 is missing.</li>

<li>muc#role should be list-single</li>

<li>muc#register_faqentry: mixed occurrences of text-single and text-multi</li>

</ul>

</remark>

</revision>

<revision>

<version>1.25</version>

<date>2012-02-08</date>

<initials>psa</initials>

<remark>

<ul>

<li>Clarified the fact that room roles and affiliations are shortcuts to bundles of privileges.</li>

<li>Removed references to service discovery feature for "gc-1.0" since it is now obsolete.</li>

<li>Added security consideration about information leaks related to service discovery.</li>

<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 &lt;actor/&gt; 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 &lt;room@service&gt; and the JID of a &lt;room@service/nick&gt;.</li>

<li>Added "muc#maxhistoryfetch" form field.</li>

<li>Loosened handling of room joins when nicks are locked down, so that the service should modify the roomnick instead of returning an error.</li>

<li>Specified that the room must return a room subject, even if the subject is empty.</li>

<li>Removed feature for requesting a unique room name (the client can simply use a UUID).</li>

<li>Removed any mention of fully-anonymous rooms, which are not supported by this specification.</li>

<li>Clarified many small points in the text and examples.</li>

</ul>

</remark>

</revision>

<revision>

<version>1.24</version>

<date>2008-07-16</date>

<initials>psa</initials>

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

</revision>

<revision>

<version>1.23</version>

<date>2008-01-14</date>

<initials>psa</initials>

<remark>

<ul>

<li>Defined getmemberlist room configuration option</li>

<li>Added direct invitation protocol</li>

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

</ul>

</remark>

</revision>

<revision>

<version>1.22</version>

<date>2007-04-10</date>

<initials>psa</initials>

<remark><p>Updated delayed delivery reference to reflect advancement of XEP-0203 to Draft and deprecation of XEP-0091.</p></remark>

</revision>

<revision>

<version>1.21</version>

<date>2006-09-13</date>

<initials>psa</initials>

<remark>

<ul>

<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 &lt;not-acceptable/&gt; 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 &lt;not-acceptable/&gt; 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>Changed urn:xmpp:delay support from SHOULD to MUST.</li>

<li>Clarified that _whois room configuration option specifies room type.</li>

<li>Defined XEP-0128 room information fields for discussion logs, associated pubsub node, and contact JID.</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 &lt;password/&gt; as a child of &lt;destroy/&gt;; changed max users error from &notallowed; 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>

</revision>

<revision>

<version>1.5</version>

<date>2003-09-11</date>

<initials>psa</initials>

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

</revision>

<revision>

<version>1.4</version>

<date>2003-02-16</date>

<initials>psa</initials>

<remark><p>Added XML schemas.</p></remark>

</revision>

<revision>

<version>1.3</version>

<date>2003-02-11</date>

<initials>psa</initials>

<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 &lt;created/&gt; element with status code 201; modified the destroy room protocol so that &lt;destroy/&gt; is a child of &lt;query/&gt;; 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>

</revision>

<revision>

<version>0.23</version>

<date>2002-11-06</date>

<initials>psa</initials>

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

</revision>

<revision>

<version>0.22</version>

<date>2002-11-04</date>

<initials>psa</initials>

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

</revision>

<revision>

<version>0.21</version>

<date>2002-11-01</date>

<initials>psa</initials>

<remark><p>Clarified several small ambiguities; made &lt;body/&gt; 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>

</revision>

<revision>

<version>0.20</version>

<date>2002-10-29</date>

<initials>psa</initials>

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

</revision>

<revision>

<version>0.19</version>

<date>2002-10-28</date>

<initials>psa</initials>

<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 &lt;actor/&gt; element (with 'jid' attribute) to &lt;item/&gt; 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 &lt;item/&gt; element to presence stanzas of type "unavailable" in order to improve the tracking of user states in the room; consolidated &lt;invitee/&gt; and &lt;inviter/&gt; elements into an &lt;invite/&gt; element with 'from' and 'to' attributes; made &lt;reason/&gt; element always a child of &lt;item/&gt; or &lt;invite/&gt; in the muc#user namespace; moved the alternate room location in room destruction to a 'jid' attribute of the &lt;alt/&gt; 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>

</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 status, 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 inviter).</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 &lt;item/&gt; element and associated attributes (jid, nick, etc.), and added 'role' attribute; modified management of voice, ban, admin, and member lists to use &lt;query/&gt; wrapper and new &lt;item/&gt; 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 &lt;query/&gt; wrapper for the &lt;destroy/&gt; 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 &lt;body/&gt; 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 &lt;x/&gt; with &lt;query/&gt; 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 &lt;whois/&gt; 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 &lt;voice/&gt; element in extended presence with &lt;item role='member'/&gt;; 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 &lt;admin/&gt; element in extended presence with a &lt;role/&gt; 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 &lt;reason/&gt; 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>

</revision>

<revision>

<version>0.5.1</version>

<date>2002-09-20</date>

<initials>psa</initials>

<remark><p>Added DTDs; changed feature discovery to use &lt;x/&gt; 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>

</revision>

<revision>

<version>0.5</version>

<date>2002-09-19</date>

<initials>psa</initials>

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

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

</revision>

<revision>

<version>0.1</version>

<date>2002-09-09</date>

<initials>psa</initials>

<remark><p>Initial version.</p></remark>

</revision>

</header>

<section1 topic='Introduction' anchor='intro'>

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

</section1>

<section1 topic='Scope' anchor='scope'>

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

<p>This document explicitly does <em>not</em> address the following:</p>

<ul>

<li>Relationships between rooms (e.g., hierarchies of rooms)</li>

<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>Moderation of individual messages</li>

<li>Encryption of messages sent through a room</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>

<li>Interaction between MUC deployments and foreign chat systems (e.g., gateways to IRC or to legacy IM systems)</li>

<li>Mirroring or replication of rooms among multiple MUC deployments</li>

</ul>

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

</section1>

<section1 topic='Requirements' anchor='reqs'>

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

<ul>

<li>Each room is identified as a "room JID" &ROOMJID; (e.g., &lt;[email protected]&gt;), 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>A user enters a room (i.e., becomes an occupant) by sending directed presence to &OCCUPANTJID;.</li>

<li>An occupant can change his or her room nickname and availability status within the room by sending presence information to &lt;room@service/newnick&gt;.</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 exits a room by sending presence of type "unavailable" to its current &OCCUPANTJID;.</li>

</ul>

<p>The additional features and functionality addressed in MUC include the following:</p>

<ol start='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 status, 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 configure various room parameters (e.g., limiting the number of occupants)</li>

<li>enabling owners to specify other owners</li>

<li>enabling owners to grant and revoke admin status, 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>

<ol start='1'>

<li>public vs. hidden</li>

<li>persistent vs. temporary</li>

<li>password-protected vs. unsecured</li>

<li>members-only vs. open</li>

<li>moderated vs. unmoderated</li>

<li>non-anonymous vs. semi-anonymous</li>

</ol>

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

</section1>

<section1 topic='Terminology' anchor='terms'>

<section2 topic='General Terms' anchor='terms-general'>

<dl>

<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 &lt;user@host&gt; 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 &lt;user@host/resource&gt; 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>History</dt><dd>A limited number of message stanzas sent to a new occupant to provide the context of current discussion.</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 <link url='#invite'>Inviting Another User to a Room</link>).</dd></di>

<di><dt>IRC</dt><dd>Internet Relay Chat.</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>MUC</dt><dd>The multi-user chat protocol for text-based conferencing specified in this document.</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 [email protected] is allowed to log in simultaneously as the nick "JuliC" in the [email protected] chatroom from both [email protected]/balcony and [email protected]/chamber). Multi-session nicks are not currently defined in this document.</dd></di>

<di><dt>Occupant</dt><dd>Any user who is in a room (this is an "abstract class" and does not correspond to any specific role).</dd></di>

<di><dt>Occupant JID</dt><dd>The &lt;room@service/nick&gt; by which an occupant is identified within the context of a room; contrast with Bare JID and Full JID.</dd></di>

<di><dt>Outcast</dt><dd>A user who has been banned from a room. An outcast has an affiliation of "outcast".</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 <link url='#bizrules'>Business Rules</link> for syntax); contrast with Room Name.</dd></di>

<di><dt>Room JID</dt><dd>The &lt;room@service&gt; address of a room.</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 <link url='#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>

</dl>

</section2>

<section2 topic='Room Types' anchor='terms-rooms'>

<dl>

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

</dl>

</section2>

<section2 topic='Dramatis Personae' anchor='terms-personae'>

<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 "[email protected]" chatroom. The characters are as follows:</p>

<table caption='Dramatis Personae'>

<tr>

<th>Room Nickname</th>

<th>Full JID</th>

<th>Affiliation</th>

</tr>

<tr>

<td>firstwitch</td>

<td>[email protected]/desktop</td>

<td>Owner</td>

</tr>

<tr>

<td>secondwitch</td>

<td>[email protected]/laptop</td>

<td>Admin</td>

</tr>

<tr>

<td>thirdwitch</td>

<td>[email protected]/pda</td>

<td>None</td>

</tr>

</table>

</section2>

</section1>

<section1 topic='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>

<section2 topic='Roles' anchor='roles'>

<p>The following roles are defined:</p>

<table caption='Roles'>

<tr>

<th>Name</th>

<th>Support</th>

</tr>

<tr>

<td>Moderator</td>

<td>REQUIRED</td>

</tr>

<tr>

<td>None</td>

<td>N/A (the absence of a role)</td>

</tr>

<tr>

<td>Participant</td>

<td>REQUIRED</td>

</tr>

<tr>

<td>Visitor</td>

<td>RECOMMENDED</td>

</tr>

</table>

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

<section3 topic='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 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>

<table caption='Privileges Associated With Roles'>

<tr>

<th>Privilege</th>

<th>None</th>

<th>Visitor</th>

<th>Participant</th>

<th>Moderator</th>

</tr>

<tr>

<td>Present in Room</td>

<td>No</td>

<td>Yes</td>

<td>Yes</td>

<td>Yes</td>

</tr>

<tr>

<td>Receive Messages</td>

<td>No</td>

<td>Yes</td>

<td>Yes</td>

<td>Yes</td>

</tr>

<tr>

<td>Receive Occupant Presence</td>

<td>No</td>

<td>Yes</td>

<td>Yes</td>

<td>Yes</td>

</tr>

<tr>

<td>Broadcast Presence to All Occupants</td>

<td>No</td>

<td>Yes*</td>

<td>Yes</td>

<td>Yes</td>

</tr>

<tr>

<td>Change Availability Status</td>

<td>No</td>

<td>Yes*</td>

<td>Yes</td>

<td>Yes</td>

</tr>

<tr>

<td>Change Room Nickname</td>

<td>No</td>

<td>Yes*</td>

<td>Yes</td>

<td>Yes</td>

</tr>

<tr>

<td>Send Private Messages</td>

<td>No</td>

<td>Yes*</td>

<td>Yes</td>

<td>Yes</td>

</tr>

<tr>

<td>Invite Other Users</td>

<td>No</td>

<td>Yes*</td>

<td>Yes*</td>

<td>Yes</td>

</tr>

<tr>

<td>Send Messages to All</td>

<td>No</td>

<td>No**</td>

<td>Yes</td>

<td>Yes</td>

</tr>

<tr>

<td>Modify Subject</td>

<td>No</td>

<td>No*</td>

<td>Yes*</td>

<td>Yes</td>

</tr>

<tr>

<td>Kick Participants and Visitors</td>

<td>No</td>

<td>No</td>

<td>No</td>

<td>Yes</td>

</tr>

<tr>

<td>Grant Voice</td>

<td>No</td>

<td>No</td>

<td>No</td>

<td>Yes</td>

</tr>

<tr>

<td>Revoke Voice</td>

<td>No</td>

<td>No</td>

<td>No</td>

<td>Yes***</td>

</tr>

</table>

<p>* Default; configuration settings MAY modify this privilege.</p>

<p>** An implementation MAY grant voice by default to visitors in unmoderated rooms.</p>

<p>*** A moderator MUST NOT be able to revoke voice privileges from an admin or owner.</p>

</section3>

<section3 topic='Default Roles' anchor='roles-default'>

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

<table caption='Initial Role Based on Affiliation'>

<tr>

<th>Room Type</th>

<th>None</th>

<th>Member</th>

<th>Admin</th>

<th>Owner</th>

</tr>

<tr>

<td>Moderated</td>

<td>Visitor</td>

<td>Participant</td>

<td>Moderator</td>

<td>Moderator</td>

</tr>

<tr>

<td>Unmoderated</td>

<td>Participant</td>

<td>Participant</td>

<td>Moderator</td>

<td>Moderator</td>

</tr>

<tr>

<td>Members-Only</td>

<td>N/A *</td>

<td>Participant</td>

<td>Moderator</td>

<td>Moderator</td>

</tr>

<tr>

<td>Open</td>

<td>Participant</td>

<td>Participant</td>

<td>Moderator</td>

<td>Moderator</td>

</tr>

</table>

<p>* Entry is not permitted.</p>

</section3>

<section3 topic='Changing Roles' anchor='roles-change'>

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

<table caption='Role State Chart'>

<tr>

<th>&gt;</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 status</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 status</td>

</tr>

<tr>

<td>Moderator</td>

<td>Exit room or be kicked by an admin or owner *</td>

<td>Admin or owner changes role to visitor *</td>

<td>Admin or owner changes role to participant or revokes moderator status *</td>

<td>--</td>

</tr>

</table>

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

<p class='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>

</section3>

</section2>

<section2 topic='Affiliations' anchor='affil'>

<p>The following affiliations are defined:</p>

<ol start='1'>

<li>Owner</li>

<li>Admin</li>

<li>Member</li>

<li>Outcast</li>

<li>None (the absence of an affiliation)</li>

</ol>

<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>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 (if the room is configured to broadcast presence from entities with a given role).</p>

<section3 topic='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 all the privileges possessed by the next-lowest affiliation, plus additional privileges; these privileges are specified in the following table.</p>

<table caption='Privileges Associated With Affiliations'>

<tr>

<th>Privilege</th>

<th>Outcast</th>

<th>None</th>

<th>Member</th>

<th>Admin</th>

<th>Owner</th>

</tr>

<tr>

<td>Enter Open Room</td>

<td>No</td>

<td>Yes*</td>