XEP-0045: Multi-User Chat

Affiliation

A long-lived association or connection with a room; the possible affiliations are "owner", "admin", "member", and "outcast" (naturally it is also possible to have no affiliation); affiliation is distinct from role. An affiliation lasts across a user's visits to a room.

Ban

To remove a user from a room such that the user is not allowed to re-enter the room (until and unless the ban has been removed). A banned user has an affiliation of "outcast".

Bare JID

The <user@host> by which a user is identified outside the context of any existing session or resource; contrast with Full JID and Room JID.

Full JID

The <user@host/resource> by which an online user is identified outside the context of a room; contrast with Bare JID and Room JID.

GC

The minimal "groupchat 1.0" protocol [7] developed within the Jabber community in 1999; MUC is backwards-compatible with GC.

History

A limited number of message stanzas sent to a new occupant to provide the context of current discussion.

Invitation

A special message sent from one user to another asking the recipient to join a room.

IRC

Internet Relay Chat.

Kick

To temporarily remove a participant or visitor from a room; the user is allowed to re-enter the room at any time. A kicked user has a role of "none".

Logging

Storage of discussions that occur within a room for public retrieval outside the context of the room.

Member

A user who is on the "whitelist" for a members-only room or who is registered with an open room. A member has an affiliation of "member".

Moderator

A room role that is usually associated with room admins but that may be granted to non-admins; is allowed to kick users, grant and revoke voice, etc. A moderator has a role of "moderator".

MUC

The multi-user chat protocol for text-based conferencing specified in this document.

Occupant

Any Jabber user who is in a room (this is an "abstract class" and does not correspond to any specific role).

Outcast

A user who has been banned from a room. An outcast has an affiliation of "outcast".

Participant

An occupant who does not have administrative privileges; in a moderated room, a participant is further defined as having voice (in contrast to a visitor). A participant has a role of "participant".

Private Message

A message sent from one occupant directly to another's room JID (not to the room itself for broadcasting to all occupants).

Role

A temporary position or privilege level within a room, distinct from a user's long-lived affiliation with the room; the possible roles are "moderator", "participant", and "visitor" (it is also possible to have no defined role). A role lasts only for the duration of an occupant's visit to a room.

Room

A virtual space that Jabber users figuratively enter in order to participate in real-time, text-based conferencing with other users.

Room Administrator

A user empowered by the room owner to perform administrative functions such as banning users; however, is not allowed to change defining room features. An admin has an affiliation of "admin".

Room ID

The node identifier portion of a Room JID, which may be opaque and thus lack meaning for human users (see Business Rules for syntax); contrast with Room Name.

Room JID

The <room@service/nick> by which an occupant is identified within the context of a room; contrast with Bare JID and Full JID.

Room Name

A user-friendly, natural-language name for a room, configured by the room owner and presented in Service Discovery queries; contrast with Room ID.

Room Nickname

The resource identifier portion of a Room JID (see Business Rules for syntax); this is the "friendly name" by which an occupant is known in the room.

Room Owner

The Jabber user who created the room or a Jabber user who has been designated by the room creator or owner as someone with owner privileges (if allowed); is allowed to change defining room features as well as perform all administrative functions. An owner has an affiliation of "owner".

Room Roster

A Jabber client's representation of the occupants in a room.

Server

A Jabber server that may or may not have associated with it a text-based conferencing service.

Service

A host that offers text-based conferencing capabilities; often but not necessarily a sub-domain of a Jabber server (e.g., conference.jabber.org).

Subject

A temporary discussion topic within a room.

Visit

A user's "session" in a room, beginning when the user enters the room (i.e., becomes an occupant) and ending when the user exits the room.

Visitor

In a moderated room, an occupant who does not have voice (in contrast to a participant). A visitor has a role of "visitor".

Voice

In a moderated room, the privilege to send messages to all occupants.

Fully-Anonymous Room

A room in which the full JIDs or bare JIDs of occupants cannot be discovered by anyone, including room admins and room owners; such rooms are NOT RECOMMENDED or explicitly supported by MUC, but are possible using this protocol if a service implementation offers the appropriate configuration options; contrast with Non-Anonymous Room and Semi-Anonymous Room.

Hidden Room

A room that cannot be found by any user through normal means such as searching and service discovery; antonym: Public Room.

Members-Only Room

A room that a user cannot enter without being on the member list; antonym: Open Room.

Moderated Room

A room in which only those with "voice" may send messages to all occupants; antonym: Unmoderated Room.

Non-Anonymous Room

A room in which an occupant's full JID is exposed to all other occupants, although the occupant may choose any desired room nickname; contrast with Semi-Anonymous Room and Fully-Anonymous Room.

Open Room

A room that anyone may enter without being on the member list; antonym: Members-Only Room.

Password-Protected Room

A room that a user cannot enter without first providing the correct password; antonym: Unsecured Room.

Persistent Room

A room that is not destroyed if the last occupant exits; antonym: Temporary Room.

Public Room

A room that can be found by any user through normal means such as searching and service discovery; antonym: Hidden Room.

Semi-Anonymous Room

A room in which an occupant's full JID can be discovered by room admins only; contrast with Fully-Anonymous Room and Non-Anonymous Room.

Temporary Room

A room that is destroyed if the last occupant exits; antonym: Persistent Room.

Unmoderated Room

A room in which any occupant is allowed to send messages to all occupants; antonym: Moderated Room.

Unsecured Room

A room that anyone is allowed to enter without first providing the correct password; antonym: Password-Protected Room.

Table 1: Dramatis Personae

Table 2: Roles

5.1.1 Privileges

For the most part, roles exist in a hierarchy. For instance, a participant can do anything a visitor can do, and a moderator can do anything a participant can do. Each role has privileges not possessed by the next-lowest role; these privileges are specified in the following table as defaults (an implementation MAY provide configuration options that override these defaults).

* Default; configuration settings MAY modify this privilege.

** An implementation MAY grant voice by default to visitors in unmoderated rooms.

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

5.1.2 Changing Roles

The ways in which an occupant's role changes are well-defined. Sometimes the change results from the occupant's own action (e.g., entering or exiting the room), whereas sometimes the change results from an action taken by a moderator, admin, or owner. If an occupant's role changes, a MUC service implementation MUST change the occupant's role to reflect the change and communicate the change to all occupants. Role changes and their triggering actions are specified in the following table.

* A moderator MUST NOT be able to revoke moderator privileges from an occupant who is equal to or above the moderator in the hierarchy of affiliations.

Note: Certain roles are typically implicit in certain privileges. For example, an admin or owner is automatically a moderator, so if an occupant is granted admin status then the occupant will by that fact be granted moderator privileges; similarly, when an occupant is made a member in a moderated room, the occupant automatically has a role of participant. However, the loss of admin status does not necessarily mean that the occupant is no longer a moderator (since a "mere" participant can be a moderator). Therefore, the roles that are gained when an occupant is granted a certain affiliation are stable, whereas the roles that are lost when an occupant loses a certain affilitation are no hardcoded and are left up to the implementation. Since a client cannot predict what the role will be after revoking a certain affiliation, if it wants to remove both admin/owner privileges and the moderator role at the same time then it must specifically request the role change in addition to the affiliation change.

5.2.1 Privileges

For the most part, affiliations exist in a hierarchy. For instance, an owner can do anything an admin can do, and an admin can do anything a member can do. Each affiliation has privileges not possessed by the next-lowest affiliation; these privileges are specified in the following table.

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

** An admin or owner MUST NOT be able to revoke moderation privileges from another admin or owner.

5.2.2 Changing Affiliations

The ways in which a user's affiliation changes are well-defined. Sometimes the change results from the user's own action (e.g., registering as a member of the room), whereas sometimes the change results from an action taken by an admin or owner. If a user's affiliation changes, a MUC service implementation MUST change the user's affiliation to reflect the change and communicate that to all occupants. Affiliation changes and their triggering actions are specified in the following table.

<iq from='hag66@shakespeare.lit/pda'
    id='disco1'
    to='chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    

<iq from='chat.shakespeare.lit'
    id='disco1'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='conference'
        name='Macbeth Chat Service'
        type='text'/>
    <feature var='http://jabber.org/protocol/muc'/>
  </query>
</iq>
    

<iq from='hag66@shakespeare.lit/pda'
    id='disco2'
    to='chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
    

<iq from='chat.shakespeare.lit'
    id='disco2'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='heath@chat.shakespeare.lit'
          name='A Lonely Heath'/>
    <item jid='darkcave@chat.shakespeare.lit'
          name='A Dark Cave'/>
    <item jid='forres@chat.shakespeare.lit'
          name='The Palace'/>
    <item jid='inverness@chat.shakespeare.lit'
          name='Macbeth&apos;s Castle'/>
  </query>
</iq>
    

<iq from='rooms.shakespeare.lit'
    id='disco-rsm-1'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='alls-well-that-ends-well@rooms.shakespeare.lit'/>
    <item jid='as-you-like-it@rooms.shakespeare.lit'/>
    <item jid='cleopatra@rooms.shakespeare.lit'/>
    <item jid='comedy-of-errors@rooms.shakespeare.lit'/>
    <item jid='coriolanus@rooms.shakespeare.lit'/>
    <item jid='cymbeline@rooms.shakespeare.lit'/>
    <item jid='hamlet@rooms.shakespeare.lit'/>
    <item jid='henry-the-fourth-one@rooms.shakespeare.lit'/>
    <item jid='henry-the-fourth-two@rooms.shakespeare.lit'/>
    <item jid='henry-the-fifth@rooms.shakespeare.lit'/>
    <set xmlns='http://jabber.org/protocol/rsm'>
      <first index='0'>alls-well-that-ends-well@rooms.shakespeare.lit</first>
      <last>henry-the-fifth@rooms.shakespeare.lit</last>
      <count>37</count>
    </set>
  </query>
</iq>
    

<iq from='hag66@shakespeare.lit/pda'
    id='disco3'
    to='darkcave@chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='disco3'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='conference'
        name='A Dark Cave'
        type='text'/>
    <feature var='http://jabber.org/protocol/muc'/>
    <feature var='muc_passwordprotected'/>
    <feature var='muc_hidden'/>
    <feature var='muc_temporary'/>
    <feature var='muc_open'/>
    <feature var='muc_unmoderated'/>
    <feature var='muc_nonanonymous'/>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='disco3a'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='conference'
        name='A Dark Cave'
        type='text'/>
    <feature var='http://jabber.org/protocol/muc'/>
    <feature var='muc_passwordprotected'/>
    <feature var='muc_hidden'/>
    <feature var='muc_temporary'/>
    <feature var='muc_open'/>
    <feature var='muc_unmoderated'/>
    <feature var='muc_nonanonymous'/>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>http://jabber.org/protocol/muc#roominfo</value>
      </field>
      <field var='muc#roominfo_description' label='Description'>
        <value>The place for all good witches!</value>
      </field>
      <field var='muc#roominfo_changesubject' label='Whether Occupants May Change the Subject'>
        <value>true</value>
      </field>
      <field var='muc#roominfo_contactjid' label='Contact Addresses'>
        <value>crone1@shakespeare.lit</value>
      </field>
      <field var='muc#roominfo_subject' label='Subject'>
        <value>Spells</value>
      </field>
      <field var='muc#roomconfig_changesubject' label='Subject can be modified'>
        <value>true</value>
      </field>
      <field var='muc#roominfo_occupants' label='Number of occupants'>
        <value>3</value>
      </field>
      <field var='muc#roominfo_ldapgroup' label='Associated LDAP Group'>
        <value>dc=lit,dc=shakespeare,cn=witches</value>
      </field>
      <field var='muc#roominfo_lang' label='Language of discussion'>
        <value>en</value>
      </field>
      <field var='muc#roominfo_logs' label='URL for discussion logs'>
        <value>http://www.shakespeare.lit/chatlogs/darkcave/</value>
      </field>
      <field var='muc#roominfo_pubsub' label='Associated pubsub node'>
        <value>xmpp:pubsub.shakespeare.lit?;node=the-darkcave-node</value>
      </field>
    </x>
  </query>
</iq>
    

<iq from='hag66@shakespeare.lit/pda'
    id='disco4'
    to='darkcave@chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='disco4'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='darkcave@chat.shakespeare.lit/firstwitch'/>
    <item jid='darkcave@chat.shakespeare.lit/secondwitch'/>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='disco4'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
    

<iq from='hag66@shakespeare.lit/pda'
    id='disco5'
    to='wiccarocks@shakespeare.lit/laptop'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    

<iq from='wiccarocks@shakespeare.lit/laptop'
    id='disco5'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='client'
        type='pc'/>
    ...
    <feature var='http://jabber.org/protocol/muc'/>
    ...
  </query>
</iq>
    

<iq from='hag66@shakespeare.lit/pda'
    id='rooms1'
    to='wiccarocks@shakespeare.lit/laptop'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'
         node='http://jabber.org/protocol/muc#rooms'/>
</iq>
    

<iq from='wiccarocks@shakespeare.lit/laptop'
    id='rooms1'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'
         node='http://jabber.org/protocol/muc#rooms'>
    <item jid='darkcave@chat.shakespeare.lit'/>
    <item jid='characters@conference.shakespeare.lit'/>
  </query>
</iq>
    

    ...
    <item jid='darkcave@chat.shakespeare.lit'
          name='secondwitch'/>
    ...
    

7.1.1 Groupchat 1.0 Protocol

In order to participate in the discussions held in a multi-user chat room, a Jabber user MUST first become an occupant by entering the room. In the old "groupchat 1.0" protocol, this was done by sending presence to <room@service/nick>, where "room" is the room ID, "service" is the hostname of the chat service, and "nick" is the user's desired nickname within the room:

Example 16. Jabber User Seeks to Enter a Room (Groupchat 1.0)

<presence
    from='hag66@shakespeare.lit/pda'
    to='darkcave@chat.shakespeare.lit/thirdwitch'/>
      

In this example, a user with a full JID of "hag66@shakespeare.lit/pda" has requested to enter the room "darkcave" on the "chat.shakespeare.lit" chat service with a room nickname of "thirdwitch".

If the user does not specify a room nickname, the service MUST return a <jid-malformed/> error:

Example 17. No Nickname Specified

<presence
    from='darkcave@chat.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <error type='modify'>
    <jid-malformed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
      

7.1.2 Basic MUC Protocol

Compliant multi-user chat services MUST accept the foregoing as a request to enter a room from any Jabber client that knows either the "groupchat 1.0" (GC) protocol or the multi-user chat (MUC) protocol; however, MUC clients SHOULD signal their ability to speak the MUC protocol by including in the initial presence stanza an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace (note the absence of the '#user' fragment):

Example 18. Jabber User Seeks to Enter a Room (Multi-User Chat)

<presence
    from='hag66@shakespeare.lit/pda'
    to='darkcave@chat.shakespeare.lit/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>
      

Note: If an error occurs in relation to joining a room, the service SHOULD include the MUC child element (i.e., <x xmlns='http://jabber.org/protocol/muc'/>) in the <presence/> stanza of type "error".

Before attempting to enter the room, a MUC-compliant client SHOULD first discover its reserved room nickname (if any) by following the protocol defined in the Discovering Reserved Room Nickname section of this document.

7.1.3 Presence Broadcast

If the service is able to add the user to the room, it MUST send presence from all the existing occupants' room JIDs to the new occupant's full JID, including extended presence information about roles in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "moderator", "participant", or "visitor", and with the 'affiliation' attribute set to a value of "owner", "admin", "member", or "none" as appropriate:

Example 19. Service Sends Presence from Existing Occupants to New Occupant

<presence
    from='darkcave@chat.shakespeare.lit/firstwitch'
    to='hag66@shakespeare.lit/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='owner' role='moderator'/>
  </x>
</presence>

<presence
    from='darkcave@chat.shakespeare.lit/secondwitch'
    to='hag66@shakespeare.lit/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin' role='moderator'/>
  </x>
</presence>
      

In this example, the user from the previous example has entered the room, by which time two other people had already entered the room: a user with a room nickname of "firstwitch" (who is a room owner) and a user with a room nickname of "secondwitch" (who is a room admin).

The service MUST also send presence from the new occupant's room JID to the full JIDs of all the occupants (including the new occupant):

Example 20. Service Sends New Occupant's Presence to All Occupants

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
  </x>
</presence>

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='wiccarocks@shakespeare.lit/laptop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
  </x>
</presence>

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='hag66@shakespeare.lit/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
    <status code='110'/>
  </x>
</presence>
      

In this example, initial room presence is being sent from the new occupant (thirdwitch) to all occupants, including the new occupant. As shown in the last stanza, the presence sent by the room to a user from itself as an occupant SHOULD include a status code of 110 so that the user knows this presence refers to itself as an occupant.

The service MAY rewrite the new occupant's roomnick (e.g., if roomnicks are locked down). If the service does not accept the new occupant's requested roomnick but instead assigns a new roomnick, it MUST include a status code of "210" in the presence broadcast that it sends to the new occupant.

Example 21. Service Sends New Occupant's Presence to New Occupant

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='hag66@shakespeare.lit/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
    <status code='110'/>
    <status code='210'/>
  </x>
</presence>
      

Note: The order of the presence stanzas sent to the new occupant is important. The service MUST first send the complete list of the existing occupants to the new occupant and only then send the new occupant's own presence to the new occupant. This helps the client know when it has received the complete "room roster".

After sending the presence broadcast (and only after doing so), the service may then send discussion history, live messages, presence updates, and other in-room traffic.

7.1.4 Default Roles

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

* Entry is not permitted.

7.1.5 Non-Anonymous Rooms

If the room is non-anonymous, the service MUST send the new occupant's full JID to all occupants using extended presence information in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with a 'jid' attribute specifying the occupant's full JID:

Example 22. Service Sends Full JID to All Occupants

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none'
          jid='hag66@shakespeare.lit/pda'
          role='participant'/>
  </x>
</presence>

[ ... ]
      

If the user is entering a room that is non-anonymous (i.e., which informs all occupants of each occupant's full JID as shown above), the service SHOULD allow the user to enter the room but MUST also warn the user that the room is not anonymous. This SHOULD be done by including a status code of "100" in the initial presence that the room sends to the new occupant:

Example 23. Service Sends New Occupant's Presence to New Occupant

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='hag66@shakespeare.lit/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
    <status code='100'/>
    <status code='110'/>
    <status code='210'/>
  </x>
</presence>
      

However, it MAY be done by sending a message of type "groupchat" to the new occupant containing an <x/> child with a <status/> element that has the 'code' attribute set to a value of "100":

Example 24. Service Warns New Occupant About Lack of Anonymity

<message
    from='darkcave@chat.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='groupchat'>
  <body>This room is not anonymous.</body>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <status code='100'/>
  </x>
</message>
      

The inclusion of the status code assists clients in presenting their own notification messages (e.g., information appropriate to the user's locality).

7.1.6 Semi-Anonymous Rooms

If the room is semi-anonymous, the service MUST send presence from the new occupant to all occupants as specified above, but MUST include the new occupant's full JID only in the presence notifications it sends to occupants with a role of "moderator" and not to non-moderator occupants.

(Note: All subsequent examples include the 'jid' attribute for each <item/> element, even though this information is not sent to non-moderators in semi-anonymous rooms.)

7.1.7 Password-Protected Rooms

If the room requires a password and the user did not supply one (or the password provided is incorrect), the service MUST deny access to the room and inform the user that they are unauthorized; this is done by returning a presence stanza of type "error" specifying a <not-authorized/> error:

Example 25. Service Denies Access Because No Password Provided

<presence
    from='darkcave@chat.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error type='auth'>
    <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
      

Passwords SHOULD be supplied with the presence stanza sent when entering the room, contained within an <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace and containing a <password/> child. Passwords are to be sent as cleartext; no other authentication methods are supported at this time, and any such authentication or authorization methods shall be defined in a separate specification (see the Security Considerations section of this document).

Example 26. User Provides Password On Entering a Room

<presence
    from='hag66@shakespeare.lit/pda'
    to='darkcave@chat.shakespeare.lit/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <password>cauldronburn</password>
  </x>
</presence>
      

7.1.8 Members-Only Rooms

If the room is members-only but the user is not on the member list, the service MUST deny access to the room and inform the user that they are not allowed to enter the room; this is done by returning a presence stanza of type "error" specifying a <registration-required/> error condition:

Example 27. Service Denies Access Because User Is Not on Member List

<presence
    from='darkcave@chat.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error type='auth'>
    <registration-required xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
      

7.1.9 Banned Users

If the user has been banned from the room (i.e., has an affiliation of "outcast"), the service MUST deny access to the room and inform the user of the fact that he or she is banned; this is done by returning a presence stanza of type "error" specifying a <forbidden/> error condition:

Example 28. Service Denies Access Because User is Banned

<presence
    from='darkcave@chat.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
      

7.1.10 Nickname Conflict

If the room already contains another user with the nickname desired by the user seeking to enter the room (or if the nickname is reserved by another user on the member list), the service MUST deny access to the room and inform the user of the conflict; this is done by returning a presence stanza of type "error" specifying a <conflict/> error condition:

Example 29. Service Denies Access Because of Nick Conflict

<presence
    from='darkcave@chat.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error type='cancel'>
    <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
      

However, if the bare JID <localpart@domain.tld> of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource. If a service allows more than one occupant with the same bare JID and the same room nickname, it SHOULD route in-room messages to all of the user's resources and allow all of the user's resources to send messages to the room; it is up to the implementation to determine how to appropriately handle presence from the user's resources and how to route private messages to all or only one resource (based on presence priority or some other algorithm).

How nickname conflicts are determined is up to the implementation (e.g., whether the service applies a case folding routine, a stringprep profile such as Resourceprep or Nodeprep, etc.).

7.1.11 Max Users

If the room has reached its maximum number of occupants, the service SHOULD deny access to the room and inform the user of the restriction; this is done by returning a presence stanza of type "error" specifying a <service-unavailable/> error condition:

Example 30. Service Informs User that Room Occupant Limit Has Been Reached

<presence
    from='darkcave@chat.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error type='wait'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
      

Alternatively, the room could kick an "idle user" in order to free up space.

If the room has reached its maximum number of occupants and a room admin or owner attempts to join, the room SHOULD allow the admin or owner to join, up to some reasonable number of additional occupants, which number MAY be configurable.

7.1.12 Locked Room

If a user attempts to enter a room while it is "locked" (i.e., before the room creator provides an initial configuration and therefore before the room officially exists), the service MUST refuse entry and return an <item-not-found/> error to the user:

Example 31. Service Denies Access Because Room Does Not Exist

<presence
    from='darkcave@chat.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error type='cancel'>
    <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
      

7.1.13 Nonexistent Room

If the room does not already exist when the user seeks to enter it, the service SHOULD create it; however, this is not required, since an implementation or deployment MAY choose to restrict the privilege of creating rooms. For details, see the Creating a Room section of this document.

7.1.14 Room Logging

If the user is entering a room in which the discussions are logged to a public archive (often accessible via HTTP), the service SHOULD allow the user to enter the room but MUST also warn the user that the discussions are logged. This SHOULD be done by including a status code of "170" in the initial presence that the room sends to the new occupant:

Example 32. Service Sends New Occupant's Presence to New Occupant

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='hag66@shakespeare.lit/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
    <status code='100'/>
    <status code='110'/>
    <status code='170'/>
    <status code='210'/>
  </x>
</presence>
      

7.1.15 Discussion History

After sending initial presence as shown above, a room MAY send discussion history to the new occupant. (The room MUST NOT send any discussion history before it finishes sending room presence as specified in the Presence Broadcast section of this document.) Whether such history is sent, and how many messages comprise the history, shall be determined by the chat service implementation or specific deployment.

Example 33. Delivery of Discussion History

<message
    from='darkcave@chat.shakespeare.lit/firstwitch'
    to='hecate@shakespeare.lit/broom'
    type='groupchat'>
  <body>Thrice the brinded cat hath mew'd.</body>
  <delay xmlns='urn:xmpp:delay'
     from='crone1@shakespeare.lit/desktop'
     stamp='2002-10-13T23:58:37Z'/>
</message>

<message
    from='darkcave@chat.shakespeare.lit/secondwitch'
    to='hecate@shakespeare.lit/broom'
    type='groupchat'>
  <body>Thrice and once the hedge-pig whined.</body>
  <delay xmlns='urn:xmpp:delay'
     from='wiccarocks@shakespeare.lit/laptop'
     stamp='2002-10-13T23:58:43Z'/>
</message>

<message
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='hecate@shakespeare.lit/broom'
    type='groupchat'>
  <body>Harpier cries 'Tis time, 'tis time.</body>
  <delay xmlns='urn:xmpp:delay'
     from='hag66@shakespeare.lit/pda'
     stamp='2002-10-13T23:58:49Z'/>
</message>
      

Discussion history messages MUST be stamped with Delayed Delivery [11] information qualified by the 'urn:xmpp:delay' namespace to indicate that they are sent with delayed delivery and to specify the times at which they were originally sent. (Note: The 'urn:xmpp:delay' namespace defined in XEP-0203 supersedes the older 'jabber:x:delay' namespace defined in Legacy Delayed Delivery [12]; until the status of XEP-0091 is changed to Obsolete, implementations SHOULD include both datetime formats.) The 'from' attribute SHOULD be the full JID of the original sender in non-anonymous rooms, but MUST NOT be in semi-anonymous rooms (where the 'from' attribute SHOULD be set to the JID of the room itself). The service SHOULD send all discussion history messages before delivering any "live" messages sent after the user enters the room.

7.1.16 Managing Discussion History

A user MAY want to manage the amount of discussion history provided on entering a room (perhaps because the user is on a low-bandwidth connection or is using a small-footprint client). This MUST be accomplished by including a <history/> child in the initial presence stanza sent when joining the room. There are four allowable attributes for this element:

The service MUST send the smallest amount of traffic that meets any combination of the above criteria, taking into account service-level and room-level defaults. The service MUST send complete message stanzas only (i.e., it MUST not literally truncate the history at a certain number of characters, but MUST send the largest number of complete stanzas that results in a number of characters less than or equal to the 'maxchars' value specified). If the client wishes to receive no history, it MUST set the 'maxchars' attribute to a value of "0" (zero).

The following examples illustrate the use of this protocol.

Example 34. User Requests Limit on Number of Messages in History

<presence
    from='hag66@shakespeare.lit/pda'
    to='darkcave@chat.shakespeare.lit/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <history maxstanzas='20'/>
  </x>
</presence>
      

Example 35. User Requests History in Last 3 Minutes

<presence
    from='hag66@shakespeare.lit/pda'
    to='darkcave@chat.shakespeare.lit/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <history seconds='180'/>
  </x>
</presence>
      

Example 36. User Requests All History Since the Beginning of the Unix Era

<presence
    from='hag66@shakespeare.lit/pda'
    to='darkcave@chat.shakespeare.lit/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <history since='1970-01-01T00:00:00Z'/>
  </x>
</presence>
      

Obviously the service SHOULD NOT return all messages sent in the room since the beginning of the Unix era, and SHOULD appropriately limit the amount of history sent to the user based on service or room defaults.

Example 37. User Requests No History

<presence
    from='hag66@shakespeare.lit/pda'
    to='darkcave@chat.shakespeare.lit/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <history maxchars='0'/>
  </x>
</presence>
      

<presence
    from='hag66@shakespeare.lit/pda'
    to='darkcave@chat.shakespeare.lit/thirdwitch'
    type='unavailable'/>
    

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='hag66@shakespeare.lit/pda'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='none'/>
    <status code='110'/>
  </x>
</presence>
<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='none'/>
  </x>
</presence>
<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='wiccarocks@shakespeare.lit/laptop'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='none'/>
  </x>
</presence>
    

<presence
    from='wiccarocks@shakespeare.lit/laptop'
    to='darkcave@chat.shakespeare.lit/oldhag'
    type='unavailable'>
  <status>gone where the goblins go</status>
</presence>
    

<presence
    from='hag66@shakespeare.lit/pda'
    to='darkcave@chat.shakespeare.lit/oldhag'/>
    

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit/pda'
          nick='oldhag'
          role='participant'/>
    <status code='303'/>
  </x>
</presence>
<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='wiccarocks@shakespeare.lit/laptop'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit/pda'
          nick='oldhag'
          role='participant'/>
    <status code='303'/>
  </x>
</presence>
<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='hag66@shakespeare.lit/pda'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit/pda'
          nick='oldhag'
          role='participant'/>
    <status code='303'/>
    <status code='110'/>
  </x>
</presence>

<presence
    from='darkcave@chat.shakespeare.lit/oldhag'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit/pda'
          role='participant'/>
  </x>
</presence>
<presence
    from='darkcave@chat.shakespeare.lit/oldhag'
    to='wiccarocks@shakespeare.lit/laptop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit/pda'
          role='participant'/>
  </x>
</presence>
<presence
    from='darkcave@chat.shakespeare.lit/oldhag'
    to='hag66@shakespeare.lit/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit/pda'
          role='participant'/>
    <status code='110'/>
  </x>
</presence>
    

<presence
    from='darkcave@chat.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error type='cancel'>
    <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
    

<presence
    from='darkcave@chat.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error type='cancel'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
    

<presence
    from='wiccarocks@shakespeare.lit/laptop'
    to='darkcave@chat.shakespeare.lit/oldhag'>
  <show>xa</show>
  <status>gone where the goblins go</status>
</presence>
    

<presence
    from='darkcave@chat.shakespeare.lit/secondwitch'
    to='crone1@shakespeare.lit/desktop'>
  <show>xa</show>
  <status>gone where the goblins go</status>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin'
          jid='wiccarocks@shakespeare.lit/laptop'
          role='moderator'/>
  </x>
</presence>

[ ... ]
    

7.5.1 Direct Invitation

A method for sending a direct invitation (not mediated by the room itself) is defined in Direct MUC Invitations [15]. Sending the invitation directly can help to work around communications blocking on the part of the invitee (which might refuse communication with entities not in its roster).

7.5.2 Mediated Invitation

It can be useful to invite another user to a room in which one is an occupant. To do this, a MUC client MUST send XML of the following form to the <room@service> itself (the reason is OPTIONAL and the message MUST be explicitly or implicitly of type "normal"):

Example 47. Occupant Sends an Invitation by Way of Room

<message
    from='crone1@shakespeare.lit/desktop'
    to='darkcave@chat.shakespeare.lit'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite to='hecate@shakespeare.lit'>
      <reason>
        Hey Hecate, this is the place for all good witches!
      </reason>
    </invite>
  </x>
</message>
      

The <room@service> itself MUST then add a 'from' address to the <invite/> element whose value is the bare JID, full JID, or room JID of the invitor and send the invitation to the invitee specified in the 'to' address (the service MAY include a message body explaining the invitation or containing the reason, for the sake of older clients; in addition, the room SHOULD add the password if the room is password-protected):

Example 48. Room Sends Invitation to Invitee on Behalf of Invitor

<message
    from='darkcave@chat.shakespeare.lit'
    to='hecate@shakespeare.lit'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite from='crone1@shakespeare.lit/desktop'>
      <reason>
        Hey Hecate, this is the place for all good witches!
      </reason>
    </invite>
    <password>cauldronburn</password>
  </x>
</message>
      

If the room is members-only, the service MAY also add the invitee to the member list. (Note: Invitation privileges in members-only rooms SHOULD be restricted to room admins; if a member without privileges to edit the member list attempts to invite another user, the service SHOULD return a <forbidden/> error to the occupant; for details, see the Modifying the Member List section of this document.)

If the invitor supplies a non-existent JID, the room SHOULD return an <item-not-found/> error to the invitor.

The invitee MAY choose to formally decline (as opposed to ignore) the invitation; and this is something that the sender may want to be informed about. In order to decline the invitation, the invitee MUST send a message of the following form to the <room@service> itself:

Example 49. Invitee Declines Invitation

<message
    from='hecate@shakespeare.lit/broom'
    to='darkcave@chat.shakespeare.lit'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <decline to='crone1@shakespeare.lit'>
      <reason>
        Sorry, I'm too busy right now.
      </reason>
    </decline>
  </x>
</message>
      

Example 50. Room Informs Invitor that Invitation Was Declined

<message
    from='darkcave@chat.shakespeare.lit'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <decline from='hecate@shakespeare.lit'>
      <reason>
        Sorry, I'm too busy right now.
      </reason>
    </decline>
  </x>
</message>
      

It may be wondered why the invitee does not send the decline message directly to the invitor. The main reason is that certain implementations MAY choose to base invitations on room JIDs rather than bare JIDs (so that, for example, an occupant could invite someone from one room to another without knowing that person's bare JID). Thus the service MUST handle both the invites and declines.

<message
    from='crone1@shakespeare.lit/desktop'
    to='wiccarocks@shakespeare.lit/laptop'
    type='chat'>
  <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
  <body>Thrice the brinded cat hath mew'd.</body>
</message>

<message
    from='wiccarocks@shakespeare.lit/laptop'
    to='crone1@shakespeare.lit/desktop'
    type='chat'>
  <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
  <body>Thrice and once the hedge-pig whined.</body>
</message>
    

<presence
    from='crone1@shakespeare.lit/desktop'
    to='darkcave@chat.shakespeare.lit/firstwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

<presence
    from='darkcave@chat.shakespeare.lit/firstwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='owner' role='moderator'/>
    <status code='110'/>
  </x>
</presence>
    

<message
    from='crone1@shakespeare.lit/desktop'
    to='darkcave@chat.shakespeare.lit'
    type='groupchat'>
  <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
  <body>Thrice the brinded cat hath mew'd.</body>
  <delay xmlns='urn:xmpp:delay'
     from='crone1@shakespeare.lit/desktop'
     stamp='2004-09-29T01:54:37Z'/>
</message>

<message
    from='crone1@shakespeare.lit/desktop'
    to='darkcave@chat.shakespeare.lit'
    type='groupchat'>
  <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
  <body>Thrice and once the hedge-pig whined.</body>
  <delay xmlns='urn:xmpp:delay'
     from='wiccarocks@shakespeare.lit/laptop'
     stamp='2004-09-29T01:55:21Z'/>
</message>
    

<message
    from='crone1@shakespeare.lit/desktop'
    to='darkcave@chat.shakespeare.lit'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite to='wiccarocks@shakespeare.lit/laptop'>
      <reason>This coven needs both wiccarocks and hag66.</reason>
      <continue thread='e0ffe42b28561960c6b12b944a092794b9683a38'/>
    </invite>
    <invite to='hag66@shakespeare.lit'>
      <reason>This coven needs both wiccarocks and hag66.</reason>
      <continue thread='e0ffe42b28561960c6b12b944a092794b9683a38'/>
    </invite>
  </x>
</message>
    

<message
    from='darkcave@chat.shakespeare.lit'>
    to='wiccarocks@shakespeare.lit/laptop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite from='crone1@shakespeare.lit'>
      <reason>This coven needs both wiccarocks and hag66.</reason>
      <continue thread='e0ffe42b28561960c6b12b944a092794b9683a38'/>
    </invite>
  </x>
</message>

<message
    from='darkcave@chat.shakespeare.lit'>
    to='hag66@shakespeare.lit'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite from='crone1@shakespeare.lit'>
      <reason>This coven needs both wiccarocks and hag66.</reason>
      <continue thread='e0ffe42b28561960c6b12b944a092794b9683a38'/>
    </invite>
  </x>
</message>
    

<presence
    from='wiccarocks@shakespeare.lit/laptop'
    to='darkcave@chat.shakespeare.lit/secondwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

<presence
    from='darkcave@chat.shakespeare.lit/firstwitch'
    to='wiccarocks@shakespeare.lit/laptop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='owner' role='moderator'/>
  </x>
</presence>

<presence
    from='darkcave@chat.shakespeare.lit/secondwitch'
    to='wiccarocks@shakespeare.lit/laptop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
  </x>
</presence>

<message
    from='darkcave@chat.shakespeare.lit'
    to='wiccarocks@shakespeare.lit/laptop'
    type='groupchat'>
  <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
  <body>Thrice the brinded cat hath mew'd.</body>
  <delay xmlns='urn:xmpp:delay'
     from='crone1@shakespeare.lit/desktop'
     stamp='2004-09-29T01:54:37Z'/>
</message>

<message
    from='darkcave@chat.shakespeare.lit'
    to='wiccarocks@shakespeare.lit/laptop'
    type='groupchat'>
  <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
  <body>Thrice and once the hedge-pig whined.</body>
  <delay xmlns='urn:xmpp:delay'
     from='wiccarocks@shakespeare.lit/laptop'
     stamp='2004-09-29T01:55:21Z'/>
</message>
    

<message
    from='wiccarocks@shakespeare.lit/laptop'
    to='darkcave@chat.shakespeare.lit/firstwitch'
    type='chat'>
  <body>I'll give thee a wind.</body>
</message>
    

<message
    from='darkcave@chat.shakespeare.lit/secondwitch'
    to='crone1@shakespeare.lit/desktop'
    type='chat'>
  <body>I'll give thee a wind.</body>
</message>
    

<message
    from='wiccarocks@shakespeare.lit/laptop'
    to='darkcave@chat.shakespeare.lit/firstwitch'
    type='groupchat'>
  <body>I'll give thee a wind.</body>
</message>

<message
    from='darkcave@chat.shakespeare.lit'
    to='wiccarocks@shakespeare.lit/laptop'
    type='error'>
  <body>I'll give thee a wind.</body>
  <error type='modify'>
    <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</message>
    

<message
    from='hag66@shakespeare.lit/pda'
    to='darkcave@chat.shakespeare.lit'
    type='groupchat'>
  <body>Harpier cries: 'tis time, 'tis time.</body>
</message>
    

<message
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'
    type='groupchat'>
  <body>Harpier cries: 'tis time, 'tis time.</body>
</message>
<message
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='wiccarocks@shakespeare.lit/laptop'
    type='groupchat'>
  <body>Harpier cries: 'tis time, 'tis time.</body>
</message>
<message
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='hag66@shakespeare.lit/pda'
    type='groupchat'>
  <body>Harpier cries: 'tis time, 'tis time.</body>
</message>
    

<iq from='hag66@shakespeare.lit/pda'
    id='reg1'
    to='darkcave@chat.shakespeare.lit'
    type='get'>
  <query xmlns='jabber:iq:register'/>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='reg1'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='jabber:iq:register'>
    <instructions>
      To register on the web, visit http://shakespeare.lit/
    </instructions>
    <x xmlns='jabber:x:data' type='form'>
      <title>Dark Cave Registration</title>
      <instructions>
        Please provide the following information
        to register with this room.
      </instructions>
      <field
          type='hidden'
          var='FORM_TYPE'>
        <value>http://jabber.org/protocol/muc#register</value>
      </field>
      <field
          label='Given Name'
          type='text-single'
          var='muc#register_first'>
        <required/>
      </field>
      <field
          label='Family Name'
          type='text-single'
          var='muc#register_last'>
        <required/>
      </field>
      <field
          label='Desired Nickname'
          type='text-single'
          var='muc#register_roomnick'>
        <required/>
      </field>
      <field
          label='Your URL'
          type='text-single'
          var='muc#register_url'/>
      <field
          label='Email Address'
          type='text-single'
          var='muc#register_email'/>
      <field
          label='FAQ Entry'
          type='text-multi'
          var='muc#register_faqentry'/>
    </x>
  </query>
</iq>
    

<iq from='hag66@shakespeare.lit/pda'
    id='reg2'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='jabber:iq:register'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE'>
        <value>http://jabber.org/protocol/muc#register</value>
      </field>
      <field var='muc#register_first'>
        <value>Brunhilde</value>
      </field>
      <field var='muc#register_last'>
        <value>Entwhistle-Throckmorton</value>
      </field>
      <field var='muc#register_roomnick'>
        <value>thirdwitch</value>
      </field>
      <field var='muc#register_url'>
        <value>http://witchesonline/~hag66/</value>
      </field>
      <field var='muc#register_email'>
        <value>hag66@witchesonline</value>
      </field>
      <field var='muc#register_faqentry'>
        <value>Just another witch.</value>
      </field>
    </x>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='reg2'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <error type='cancel'>
    <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='reg2'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <error type='cancel'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='reg2'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <error type='modify'>
    <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='reg2'
    to='hag66@shakespeare.lit/pda'
    type='result'/>
    

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit/pda'
          role='participant'/>
  </x>
</presence>

[ ... ]
    

<iq from='hag66@shakespeare.lit/pda'
    id='getnick1'
    to='darkcave@chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='x-roomuser-item'/>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='getnick1'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='x-roomuser-item'>
    <identity
        category='conference'
        name='thirdwitch'
        type='text'/>
  </query>
</iq>
    

<message from='hag66@shakespeare.lit/pda'
         to='darkcave@chat.shakespeare.lit'>
  <x xmlns='jabber:x:data' type='submit'>
    <field var='FORM_TYPE'>
      <value>http://jabber.org/protocol/muc#request</value>
    </field>
    <field var='muc#role'
           type='text-single'
           label='Requested role'>
      <value>participant</value>
    </field>
  </x>
</message>
    

<message
    from='wiccarocks@shakespeare.lit/laptop'
    to='darkcave@chat.shakespeare.lit'
    type='groupchat'>
  <subject>Fire Burn and Cauldron Bubble!</subject>
</message>
    

<message
    from='darkcave@chat.shakespeare.lit/secondwitch'
    to='crone1@shakespeare.lit/desktop'
    type='groupchat'>
  <subject>Fire Burn and Cauldron Bubble!</subject>
</message>

[ ... ]
    

* secondwitch has changed the subject to: Fire Burn and Cauldron Bubble!
    

<message
    from='darkcave@chat.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <subject>Fire Burn and Cauldron Bubble!</subject>
  <error type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</message>
    

<message
    from='wiccarocks@shakespeare.lit/laptop'
    to='darkcave@chat.shakespeare.lit'
    type='groupchat'>
  <subject></subject>
</message>
    

<iq from='fluellen@shakespeare.lit/pda'
    id='kick1'
    to='harfleur@henryv.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='pistol' role='none'>
      <reason>Avaunt, you cullion!</reason>
    </item>
  </query>
</iq>
    

<presence
    from='harfleur@henryv.shakespeare.lit/pistol'
    to='pistol@shakespeare.lit/harfleur'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'>
      <actor jid='fluellen@shakespeare.lit'/>
      <reason>Avaunt, you cullion!</reason>
    </item>
    <status code='307'/>
  </x>
</presence>
    

<iq from='harfleur@henryv.shakespeare.lit'
    id='kick1'
    to='fluellen@shakespeare.lit/pda'
    type='result'/>
    

<presence
    from='harfleur@henryv.shakespeare.lit/pistol'
    to='gower@shakespeare.lit/cell'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'/>
    <status code='307'/>
  </x>
</presence>

[ ... ]
    

<iq from='darkcave@chat.shakespeare.lit'
    id='kicktest'
    to='wiccarocks@shakespeare.lit/laptop'
    type='error'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='firstwitch' role='none'>
      <reason>Be gone!</reason>
    </item>
  </query>
  <error type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='voice1'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='participant'/>
  </query>
</iq>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='voice1'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='participant'>
      <reason>A worthy witch indeed!</reason>
    </item>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='voice1'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>
    

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          nick='thirdwitch'
          role='participant'>
      <reason>A worthy witch indeed!</reason>
    </item>
  </x>
</presence>

[ ... ]
    

<iq from='crone1@shakespeare.lit/desktop'
    id='voice2'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='visitor'/>
  </query>
</iq>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='voice2'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='visitor'>
      <reason>Not so worthy after all!</reason>
    </item>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='voice2'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>
    

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit/pda'
          role='visitor'/>
  </x>
</presence>

[ ... ]
    

<iq from='darkcave@chat.shakespeare.lit'
    id='voicetest'
    to='crone1@shakespeare.lit/desktop'
    type='error'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='secondwitch' role='visitor'/>
  </query>
  <error type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

<iq from='bard@shakespeare.lit/globe'
    id='voice3'
    to='goodfolk@chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item role='participant'/>
  </query>
</iq>
    

<iq from='goodfolk@chat.shakespeare.lit'
    id='voice3'
    to='bard@shakespeare.lit/globe'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='none'
          jid='polonius@hamlet/castle'
          nick='Polo'
          role='participant'/>
    <item affiliation='none'
          jid='horatio@hamlet/castle'
          nick='horotoro'
          role='participant'/>
    <item affiliation='member'
          jid='hecate@shakespeare.lit/broom'
          nick='Hecate'
          role='participant'/>
  </query>
</iq>
    

<iq from='bard@shakespeare.lit/globe'
    id='voice4'
    to='goodfolk@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='Hecate'
          role='visitor'/>
    <item nick='rosencrantz'
          role='participant'>
      <reason>A worthy fellow.</reason>
    </item>
    <item nick='guildenstern'
          role='participant'>
      <reason>A worthy fellow.</reason>
    </item>
  </query>
</iq>
    

<iq from='goodfolk@chat.shakespeare.lit'
    id='voice1'
    to='bard@shakespeare.lit/globe'
    type='result'/>
    

<iq from='goodfolk@chat.shakespeare.lit'
    id='voicetest'
    to='bard@shakespeare.lit/globe'
    type='error'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item jid='hecate@shakespeare.lit'
          nick='Hecate'
          role='visitor'/>
  </query>
  <error type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

<message from='darkcave@chat.shakespeare.lit'
         id='approve'
         to='crone1@shakespeare.lit/pda'>
  <x xmlns='jabber:x:data' type='form'>
    <title>Voice request</title>
    <instructions>
      To approve this request for voice, select 
      the &quot;Grant voice to this person?&quot;
      checkbox and click OK. To skip this request, 
      click the cancel button.
    </instructions>
    <field var='FORM_TYPE' type='hidden'>
        <value>http://jabber.org/protocol/muc#request</value>
    </field>
    <field var='muc#role'
           type='text-single'
           label='Requested role'>
      <value>participant</value>
    </field>
    <field var='muc#jid'
           type='text-single'
           label='User ID'>
      <value>hag66@shakespeare.lit/pda</value>
    </field>
    <field var='muc#roomnick'
           type='text-single'
           label='Room Nickname'>
      <value>thirdwitch</value>
    </field>
    <field var='muc#request_allow'
           type='boolean'
           label='Grant voice to this person?'>
      <value>false</value>
    </field>
  </x>
</message>
    

<message from='crone1@shakespeare.lit/pda'
         id='approve'
         to='darkcave@chat.shakespeare.lit'>
  <x xmlns='jabber:x:data' type='submit'>
    <field var='FORM_TYPE' type='hidden'>
        <value>http://jabber.org/protocol/muc#request</value>
    </field>
    <field var='muc#role'>
      <value>participant</value>
    </field>
    <field var='muc#jid'>
      <value>hag66@shakespeare.lit/pda</value>
    </field>
    <field var='muc#roomnick'>
      <value>thirdwitch</value>
    </field>
    <field var='muc#request_allow'>
      <value>true</value>
    </field>
  </x>
</message>
    

<iq from='kinghenryv@shakespeare.lit/throne'
    id='ban1'
    to='southampton@henryv.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='outcast'
          jid='earlofcambridge@shakespeare.lit'/>
  </query>
</iq>
    

<iq from='kinghenryv@shakespeare.lit/throne'
    id='ban1'
    to='southampton@henryv.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='outcast'
          jid='earlofcambridge@shakespeare.lit'>
      <reason>Treason</reason>
    </item>
  </query>
</iq>
    

<iq from='southampton@henryv.shakespeare.lit'
    id='ban1'
    to='kinghenryv@shakespeare.lit/throne'
    type='result'/>
    

<presence
    from='southampton@henryv.shakespeare.lit/cambridge'
    to='earlofcambridge@shakespeare.lit/stabber'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='outcast' role='none'>
      <actor jid='kinghenryv@shakespeare.lit'/>
      <reason>Treason</reason>
    </item>
    <status code='301'/>
  </x>
</presence>
    

<presence
    type='unavailable'
    from='southampton@henryv.shakespeare.lit/cambridge'
    to='exeter@shakespeare.lit/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='outcast'
          jid='earlofcambridge@shakespeare.lit/stabber'
          role='none'/>
    <status code='301'/>
  </x>
</presence>

[ ... ]
    

<iq from='kinghenryv@shakespeare.lit/throne'
    id='ban1'
    to='southampton@henryv.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='outcast'
          jid='earlofcambridge@shakespeare.lit'>
      <reason>Treason</reason>
    </item>
  </query>
  <error type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

<iq from='kinghenryv@shakespeare.lit/throne'
    id='ban2'
    to='southampton@henryv.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='outcast'/>
  </query>
</iq>
    

<iq from='southampton@henryv.shakespeare.lit'
    id='ban2'
    to='kinghenryv@shakespeare.lit/throne'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='outcast'
          jid='earlofcambridge@shakespeare.lit'>
      <reason>Treason</reason>
    </item>
  </query>
</iq>
    

<iq from='kinghenryv@shakespeare.lit/throne'
    id='ban3'
    to='southampton@henryv.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='outcast'
          jid='earlofcambridge@shakespeare.lit'>
      <reason>Treason</reason>
    </item>
    <item affiliation='outcast'>
          jid='lordscroop@shakespeare.lit'>
      <reason>Treason</reason>
    </item>
    <item affiliation='outcast'
          jid='sirthomasgrey@shakespeare.lit'>
      <reason>Treason</reason>
    </item>
  </query>
</iq>
    

<iq from='southampton@henryv.shakespeare.lit'
    id='ban3'
    to='kinghenryv@shakespeare.lit/throne'
    type='result'/>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='member1'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit'/>
  </query>
</iq>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='member1'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit'>
      <reason>A worthy witch indeed!</reason>
    </item>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='member1'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>
    

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit/pda'
          role='participant'/>
  </x>
</presence>

[ ... ]
    

<message
    from='chat.shakespeare.lit'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit'
          role='none'/>
  </x>
</message>

[ ... ]
    

<iq from='crone1@shakespeare.lit/desktop'
    id='member2'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='none'
          jid='hag66@shakespeare.lit'/>
  </query>
</iq>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='member2'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='none'
          jid='hag66@shakespeare.lit'>
      <reason>Not so worthy after all!</reason> 
    </item>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='member2'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>
    

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none'
          jid='hag66@shakespeare.lit/pda'
          role='participant'/>
  </x>
</presence>

[ ... ]
    

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'>
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'>
      <actor jid='bard@shakespeare.lit'/>
    </item>
    <status code='321'/>
  </x>
</presence>

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'>
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'/>
    <status code='321'/>
  </x>
</presence>

[ ... ]
    

<iq from='crone1@shakespeare.lit/desktop'
    id='member3'
    to='darkcave@chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'/>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='member3'
    to='crone1@shakespeare.lit/desktop'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit'
          nick='thirdwitch'
          role='participant'/>
  </query>
</iq>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='member4'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='none'
          jid='hag66@shakespeare.lit'/>
    <item affiliation='member'
          jid='hecate@shakespeare.lit'/>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='member4'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>
    

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none'
          jid='hag66@shakespeare.lit/pda'
          role='participant'/>
  </x>
</presence>

[ ... ]
    

<message
    from='darkcave@chat.shakespeare.lit'
    to='hecate@shakespeare.lit'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite from='bard@shakespeare.lit'/>
    <password>cauldronburn</password>
  </x>
</message>
    

<message
    from='darkcave@chat.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite to='hecate@shakespeare.lit'>
      <reason>
        Hey Hecate, this is the place for all good witches!
      </reason>
    </invite>
  </x>
  <error type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</message>
    

<presence
    from='darkcave@chat.shakespeare.lit/hecate'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='hecate@shakespeare.lit/broom'
          role='participant'/>
  </x>
</presence>

[ ... ]
    

<iq from='crone1@shakespeare.lit/desktop'
    id='mod1'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='moderator'/>
  </query>
</iq>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='mod1'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='moderator'>
      <reason>A worthy witch indeed!</reason> 
    </item>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='mod1'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>
    

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit/pda'
          role='moderator'/>
  </x>
</presence>

[ ... ]
    

<iq from='crone1@shakespeare.lit/desktop'
    id='mod2'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='participant'/>
  </query>
</iq>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='mod2'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='participant'>
      <reason>Not so worthy after all!</reason> 
    </item>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='mod2'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>
    

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit/pda'
          role='participant'/>
  </x>
</presence>

[ ... ]
    

<iq from='darkcave@chat.shakespeare.lit'
    id='modtest'
    to='crone1@shakespeare.lit/desktop'
    type='error'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='secondwitch' role='participant'/>
  </query>
  <error type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='mod3'
    to='darkcave@chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item role='moderator'/>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='mod3'
    to='crone1@shakespeare.lit/desktop'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit/pda'
          nick='thirdwitch'
          role='moderator'/>
  </query>
</iq>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='mod4'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item jid='hag66@shakespeare.lit/pda'
          role='participant'/>
    <item jid='hecate@shakespeare.lit/broom'
          role='moderator'/>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='mod4'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='modtest'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item jid='hecate@shakespeare.lit/broom'
          nick='Hecate'
          role='participant'/>
  </query>
  <error type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

<message from='darkcave@chat.shakespeare.lit'
         id='approve'
         to='crone1@shakespeare.lit/pda'>
  <x xmlns='jabber:x:data' type='form'>
    <title>Registration request</title>
    <instructions>
      To approve this registration request, select the
      &quot;Allow this person to register with the room?&quot;
      checkbox and click OK. To skip this request, click the 
      cancel button.
    </instructions>
    <field var='FORM_TYPE' type='hidden'>
        <value>http://jabber.org/protocol/muc#register</value>
    </field>
    <field var='muc#register_first'
           type='text-single'
           label='Given Name'>
      <value>Brunhilde</value>
    </field>
    <field var='muc#register_last'
           type="text-single"
           label="Family Name">
      <value>Entwhistle-Throckmorton</value>
    </field>
    <field var='muc#register_roomnick'
           type="text-single"
           label="Desired Nickname">
      <value>thirdwitch</value>
    </field>
    <field var='muc#register_url'
           type="text-single"
           label="User URL">
      <value>http://witchesonline/~hag66/</value>
    </field>
    <field var='muc#register_email'
           type="text-single"
           label="Email Address">
      <value>hag66@witchesonline</value>
    </field>
    <field var='muc#register_faqentry'
           type="text-single"
           label="FAQ Entry">
      <value>Just another witch.</value>
    </field>
    <field var='muc#register_allow'
           type='boolean'
           label='Allow this person to register with the room?'>
      <value>0</value>
    </field>
  </x>
</message>
    

10.1.1 General Considerations

The privilege to create rooms MAY be restricted to certain users or MAY be reserved to an administrator of the service. If access is restricted and a user attempts to create a room, the service MUST return a <not-allowed/> error:

Example 142. Service Informs User of Inability to Create a Room

<presence
    from='darkcave@chat.shakespeare.lit/thirdwitch'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
      

If access is not restricted, the service MUST allow the user to create a room as described below.

From the perspective of room creation, there are in essence two kinds of rooms:

• "Instant rooms" -- these are available for immediate access and are automatically created based on some default configuration.

• "Reserved rooms" -- these are manually configured by the room creator before anyone is allowed to enter.

The workflow for creating and configuring such rooms is as follows:

1. The user MUST send presence to <room@service/nick> and signal his or her support for the Multi-User Chat protocol by including extended presence information in an empty <x/> child element qualified by the 'http://jabber.org/protocol/muc' namespace (note the lack of an '#owner' or '#user' fragment).

2. If this user is allowed to create a room and the room does not yet exist, the service MUST create the room according to some default configuration, assign the requesting user as the initial room owner, and add the owner to the room but not allow anyone else to enter the room (effectively "locking" the room). The initial presence stanza received by the owner from the room MUST include extended presence information indicating the user's status as an owner and acknowledging that the room has been created (via status code 201) and is awaiting configuration.

3. If the initial room owner would like to create and configure a reserved room, the room owner MUST then request a configuration form by sending an IQ stanza of type "get" to the room containing an empty <query/> element qualified by the 'http://jabber.org/protocol/muc#owner' namespace, then complete Steps 4 and 5. If the room owner would prefer to create an instant room, the room owner MUST send a query element qualified by the 'http://jabber.org/protocol/muc#owner' namespace and containing an empty <x/> element of type "submit" qualified by the 'jabber:x:data' namespace, then skip to Step 6.

4. If the room owner requested a configuration form, the service MUST send an IQ to the room owner containing a configuration form qualified by the 'jabber:x:data' namespace. If there are no configuration options available, the room MUST return an empty query element to the room owner.

5. The initial room owner SHOULD provide a starting configuration for the room (or accept the default configuration) by sending an IQ of type "set" containing the completed configuration form. Alternatively, the room owner MAY cancel the configuration process. (An implementation MAY set a timeout for initial configuration, such that if the room owner does not configure the room within the timeout period, the room owner is assumed to have accepted the default configuration or to have cancelled the configuration process.)

6. Once the service receives the completed configuration form from the initial room owner (or receives a request for an instant room), the service MUST "unlock" the room (i.e., allow other users to enter the room) and send an IQ of type "result" to the room owner. If the service receives a cancellation, it MUST destroy the room.

The protocol for this workflow is shown in the examples below.

First, the Jabber user MUST send presence to the room, including an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace (this is the same stanza sent when seeking to enter a room).

Example 143. Jabber User Creates a Room and Signals Support for Multi-User Chat

<presence
    from='crone1@shakespeare.lit/desktop'
    to='darkcave@chat.shakespeare.lit/firstwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>
      

If the room does not yet exist, the service SHOULD create the room (subject to local policies regarding room creation), assign the bare JID of the requesting user as the owner, add the owner to the room, and acknowledge successful creation of the room by sending a presence stanza of the following form:

Example 144. Service Acknowledges Room Creation

<presence
    from='darkcave@chat.shakespeare.lit/firstwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='owner'
          role='moderator'/>
    <status code='110'/>
    <status code='201'/>
  </x>
</presence>
      

After receiving notification that the room has been created, the room owner needs to decide whether to accept the default room configuration (i.e., create an "instant room") or configure the room to have something other than the default room configuration (i.e., create a "reserved room"). The protocol flows for completing those two use cases are shown in the following sections.

Note: If the presence stanza sent to a nonexistent room does not include an <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace as shown above, the service SHOULD create a default room without delay (i.e., it MUST assume that the client supports "groupchat 1.0" rather than Multi-User Chat and therefore it MUST NOT lock the room while waiting for the room creator to either accept an instant room or configure a reserved room).

10.1.2 Creating an Instant Room

If the initial room owner wants to accept the default room configuration (i.e., create an "instant room"), the room owner MUST decline an initial configuration form by sending an IQ set to the <room@service> itself containing a <query/> element qualified by the 'http://jabber.org/protocol/muc#owner' namespace, where the only child of the <query/> is an empty <x/> element that is qualified by the 'jabber:x:data' namespace and that possesses a 'type' attribute whose value is "submit":

Example 145. Owner Requests Instant Room

<iq from='crone1@shakespeare.lit/desktop'
    id='create1'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <x xmlns='jabber:x:data' type='submit'/>
  </query>
</iq>
      

The service MUST then unlock the room and allow other entities to join it.

10.1.3 Creating a Reserved Room

If the initial room owner wants to create and configure a reserved room, the room owner MUST request an initial configuration form by sending an IQ get to the <room@service> itself containing an empty <query/> element qualified by the 'http://jabber.org/protocol/muc#owner' namespace:

Example 146. Owner Requests Configuration Form

<iq from='crone1@shakespeare.lit/desktop'
    id='create1'
    to='darkcave@chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#owner'/>
</iq>
      

If the room does not already exist, the service MUST return an initial room configuration form to the user. (Note: The following example shows a representative sample of configuration options. A full list of x:data fields registered for use in room creation and configuration is maintained by the XMPP Registrar; see the XMPP Registrar Considerations section of this document.)

Example 147. Service Sends Configuration Form

<iq from='darkcave@chat.shakespeare.lit'
    id='create1'
    to='crone1@shakespeare.lit/desktop'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <x xmlns='jabber:x:data' type='form'>
      <title>Configuration for "darkcave" Room</title>
      <instructions>
          Your room darkcave@macbeth has been created!
          The default configuration is as follows:
            - No logging
            - No moderation
            - Up to 20 occupants
            - No password required
            - No invitation required
            - Room is not persistent
            - Only admins may change the subject
            - Presence broadcasted for all users
          To accept the default configuration, click OK. To
          select a different configuration, please complete
          this form.
      </instructions>
      <field
          type='hidden'
          var='FORM_TYPE'>
        <value>http://jabber.org/protocol/muc#roomconfig</value>
      </field>
      <field
          label='Natural-Language Room Name'
          type='text-single'
          var='muc#roomconfig_roomname'/>
      <field
          label='Short Description of Room'
          type='text-single'
          var='muc#roomconfig_roomdesc'/>
      <field
          label='Natural Language for Room Discussions'
          type='text-single'
          var='muc#roomconfig_lang'/>
      <field
          label='Enable Public Logging?'
          type='boolean'
          var='muc#roomconfig_enablelogging'>
        <value>0</value>
      </field>
      <field
          label='Allow Occupants to Change Subject?'
          type='boolean'
          var='muc#roomconfig_changesubject'>
        <value>0</value>
      </field>
      <field
          label='Allow Occupants to Invite Others?'
          type='boolean'
          var='muc#roomconfig_allowinvites'>
        <value>0</value>
      </field>
      <field
          label='Maximum Number of Occupants'
          type='list-single'
          var='muc#roomconfig_maxusers'>
        <value>20</value>
        <option label='10'><value>10</value></option>
        <option label='20'><value>20</value></option>
        <option label='30'><value>30</value></option>
        <option label='50'><value>50</value></option>
        <option label='100'><value>100</value></option>
        <option label='None'><value>none</value></option>
      </field>
      <field
          label='Roles for which Presence is Broadcast'
          type='list-multi'
          var='muc#roomconfig_presencebroadcast'>
        <value>moderator</value>
        <value>participant</value>
        <value>visitor</value>
        <option label='Moderator'><value>moderator</value></option>
        <option label='Participant'><value>participant</value></option>
        <option label='Visitor'><value>visitor</value></option>
      </field>
      <field
          label='Roles and Affiliations that May Retrieve Member List'
          type='list-multi'
          var='muc#roomconfig_getmemberlist'>
        <value>moderator</value>
        <value>participant</value>
        <value>visitor</value>
        <option label='Moderator'><value>moderator</value></option>
        <option label='Participant'><value>participant</value></option>
        <option label='Visitor'><value>visitor</value></option>
      </field>
      <field
          label='Make Room Publicly Searchable?'
          type='boolean'
          var='muc#roomconfig_publicroom'>
        <value>1</value>
      </field>
      <field
          label='Make Room Persistent?'
          type='boolean'
          var='muc#roomconfig_persistentroom'>
        <value>0</value>
      </field>
      <field
          label='Make Room Moderated?'
          type='boolean'
          var='muc#roomconfig_moderatedroom'>
        <value>0</value>
      </field>
      <field
          label='Make Room Members-Only?'
          type='boolean'
          var='muc#roomconfig_membersonly'>
        <value>0</value>
      </field>
      <field
          label='Password Required to Enter?'
          type='boolean'
          var='muc#roomconfig_passwordprotectedroom'>
        <value>0</value>
      </field>
      <field type='fixed'>
        <value>
          If a password is required to enter this room,
          you must specify the password below.
        </value>
      </field>
      <field
          label='Password'
          type='text-private'
          var='muc#roomconfig_roomsecret'/>
      <field
          label='Who May Discover Real JIDs?'
          type='list-single'
          var='muc#roomconfig_whois'>
        <option label='Moderators Only'>
          <value>moderators</value>
        </option>
        <option label='Anyone'>
          <value>anyone</value>
        </option>
      </field>
      <field type='fixed'>
        <value>
          You may specify additional people who have
          administrative privileges in the room. Please
          provide one Jabber ID per line.
        </value>
      </field>
      <field
          label='Room Admins'
          type='jid-multi'
          var='muc#roomconfig_roomadmins'/>
      <field type='fixed'>
        <value>
          You may specify additional owners for this
          room. Please provide one Jabber ID per line.
        </value>
      </field>
      <field
          label='Room Owners'
          type='jid-multi'
          var='muc#roomconfig_roomowners'/>
    </x>
  </query>
</iq>
      

Note: The _whois configuration option specifies whether the room is non-anonymous (a value of "anyone"), semi-anonymous (a value of "moderators"), or fully anonmyous (a value of "none", not shown here).

If there are no configuration options available, the service MUST return an empty query element to the room owner:

Example 148. Service Informs Owner that No Configuration is Possible

<iq from='darkcave@chat.shakespeare.lit'
    id='create1'
    to='crone1@shakespeare.lit/desktop'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#owner'/>
</iq>
      

The room owner SHOULD then fill out the form and submit it to the service.

Example 149. Owner Submits Configuration Form

<iq from='crone1@shakespeare.lit/desktop'
    id='create2'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE'>
        <value>http://jabber.org/protocol/muc#roomconfig</value>
      </field>
      <field var='muc#roomconfig_roomname'>
        <value>A Dark Cave</value>
      </field>
      <field var='muc#roomconfig_roomdesc'>
        <value>The place for all good witches!</value>
      </field>
      <field var='muc#roomconfig_enablelogging'>
        <value>0</value>
      </field>
      <field var='muc#roomconfig_changesubject'>
        <value>1</value>
      </field>
      <field var='muc#roomconfig_allowinvites'>
        <value>0</value>
      </field>
      <field var='muc#roomconfig_maxusers'>
        <value>10</value>
      </field>
      <field var='muc#roomconfig_publicroom'>
        <value>0</value>
      </field>
      <field var='muc#roomconfig_persistentroom'>
        <value>0</value>
      </field>
      <field var='muc#roomconfig_moderatedroom'>
        <value>0</value>
      </field>
      <field var='muc#roomconfig_membersonly'>
        <value>0</value>
      </field>
      <field var='muc#roomconfig_passwordprotectedroom'>
        <value>1</value>
      </field>
      <field var='muc#roomconfig_roomsecret'>
        <value>cauldronburn</value>
      </field>
      <field var='muc#roomconfig_whois'>
        <value>moderators</value>
      </field>
      <field var='muc#roomconfig_roomadmins'>
        <value>wiccarocks@shakespeare.lit</value>
        <value>hecate@shakespeare.lit</value>
      </field>
    </x>
  </query>
</iq>
      

If room creation is successful, the service MUST inform the new room owner of success:

Example 150. Service Informs New Room Owner of Success

<iq from='darkcave@chat.shakespeare.lit'
    id='create2'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>
      

If the room creation fails because the specified room configuration options violate one or more service policies (e.g., because the password for a password-protected room is blank), the service MUST return a <not-acceptable/> error.

Example 151. Service Informs Owner that Requested Configuration Options Are Unacceptable

<iq from='darkcave@chat.shakespeare.lit'
    id='create2'
    to='crone1@shakespeare.lit/desktop'
    type='error'>
  <error type='modify'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
      

Alternatively, the room owner MAY cancel the configuration process:

Example 152. Owner Cancels Initial Configuration

<iq from='crone1@shakespeare.lit/desktop'
    id='create2'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <x xmlns='jabber:x:data' type='cancel'/>
  </query>
</iq>
      

If the room owner cancels the initial configuration, the service SHOULD destroy the room, making sure to send unavailable presence to the room owner (see the "Destroying a Room" use case for protocol details).

If the room owner becomes unavailable for any reason before submitting the form (e.g., a lost connection), the service will receive a presence stanza of type "unavailable" from the owner to the owner's <room@service/nick> or to <room@service> (or both). The service MUST then destroy the room, sending a presence stanza of type "unavailable" from the room to the owner including a <destroy/> element and reason (if provided) as defined in the Destroying a Room section of this document.

10.1.4 Requesting a Unique Room Name

In some situations (e.g., when Converting a One-to-One Chat Into a Conference), the room creator may want to request a unique room name before attempting to create the room (e.g., to avoid the possibility of a room conflict). In order to facilitate this, a service MAY support the feature described in this section. (If a service does support this feature, it MUST return a feature of "http://jabber.org/protocol/muc#unique" in its response to service discovery information requests.)

The room creator requests a unique room name by sending an IQ-get to the service itself, containing an empty <unique/> element qualified by the 'http://jabber.org/protocol/muc#unique' namespace:

Example 153. Entity Requests Unique Room Name

<iq from='crone1@shakespeare.lit/desktop'
    id='unique1'
    to='chat.shakespeare.lit'
    type='get'>
  <unique xmlns='http://jabber.org/protocol/muc#unique'/>
</iq>
      

If the service supports this feature, it SHOULD return a unique room name as the XML character data of the <unique/> element (but not create the room):

Example 154. Service Returns Unique Room Name

<iq from='chat.shakespeare.lit'
    id='unique1'
    to='crone1@shakespeare.lit/desktop'
    type='result'>
  <unique xmlns='http://jabber.org/protocol/muc#unique'>
    6d9423a55f499b29ad20bf7b2bdea4f4b885ead1
  </unique>
</iq>
      

The service MAY refuse to return a unique room name to entities that are not entitled to create rooms, entities that have sent an excessive number of requests for unique room names, etc.

The service MAY use any algorithm that ensures the creation of a room name that will be permanently unique in the context of the service (e.g., a SHA-1 hash of the requesting JID, datetime, and random salt).

The room creator would then use the XML character data of the <unique/> element as the node identifier portion of the room JID it requests:

Example 155. Owner Creates Room With Unique Name

<presence 
    from='crone1@shakespeare.lit/desktop'
    to='6d9423a55f499b29ad20bf7b2bdea4f4b885ead1@chat.shakespeare.lit/firstwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>
      

<iq from='crone1@shakespeare.lit/desktop'
    id='config1'
    to='darkcave@chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#owner'/>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='configures'
    to='wiccarocks@shakespeare.lit/laptop'
    type='error'>
  <query xmlns='http://jabber.org/protocol/muc#owner'/>
  <error type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='config1'
    to='crone1@shakespeare.lit/desktop'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <x xmlns='jabber:x:data' type='form'>
      <title>Configuration for "darkcave" Room</title>
      <instructions>
        Complete this form to make changes to
        the configuration of your room.
      </instructions>
      <field
          type='hidden'
          var='FORM_TYPE'>
        <value>http://jabber.org/protocol/muc#roomconfig</value>
      </field>
      <field
          label='Natural-Language Room Name'
          type='text-single'
          var='muc#roomconfig_roomname'>
        <value>A Dark Cave</value>
      </field>
      <field
          label='Short Description of Room'
          type='text-single'
          var='muc#roomconfig_roomdesc'>
        <value>The place for all good witches!</value>
      </field>
      <field
          label='Enable Public Logging?'
          type='boolean'
          var='muc#roomconfig_enablelogging'>
        <value>0</value>
      </field>
      <field
          label='Allow Occupants to Change Subject?'
          type='boolean'
          var='muc#roomconfig_changesubject'>
        <value>0</value>
      </field>
      <field
          label='Allow Occupants to Invite Others?'
          type='boolean'
          var='muc#roomconfig_allowinvites'>
        <value>0</value>
      </field>
      <field
          label='Maximum Number of Occupants'
          type='list-single'
          var='muc#roomconfig_maxusers'>
        <value>10</value>
        <option label='10'><value>10</value></option>
        <option label='20'><value>20</value></option>
        <option label='30'><value>30</value></option>
        <option label='50'><value>50</value></option>
        <option label='100'><value>100</value></option>
        <option label='None'><value>none</value></option>
      </field>
      <field
          label='Roles for which Presence is Broadcast'
          type='list-multi'
          var='muc#roomconfig_presencebroadcast'>
        <value>moderator</value>
        <value>participant</value>
        <value>visitor</value>
        <option label='Moderator'><value>moderator</value></option>
        <option label='Participant'><value>participant</value></option>
        <option label='Visitor'><value>visitor</value></option>
      </field>
      <field
          label='Roles and Affiliations that May Retrieve Member List'
          type='list-multi'
          var='muc#roomconfig_getmemberlist'>
        <value>moderator</value>
        <value>participant</value>
        <value>visitor</value>
        <option label='Moderator'><value>moderator</value></option>
        <option label='Participant'><value>participant</value></option>
        <option label='Visitor'><value>visitor</value></option>
      </field>
      <field
          label='Make Room Publicly Searchable?'
          type='boolean'
          var='muc#roomconfig_publicroom'>
        <value>0</value>
      </field>
      <field
          label='Make Room Persistent?'
          type='boolean'
          var='muc#roomconfig_persistentroom'>
        <value>0</value>
      </field>
      <field
          label='Make Room Moderated?'
          type='boolean'
          var='muc#roomconfig_moderatedroom'>
        <value>0</value>
      </field>
      <field
          label='Make Room Members Only?'
          type='boolean'
          var='muc#roomconfig_membersonly'>
        <value>0</value>
      </field>
      <field
          label='Password Required for Entry?'
          type='boolean'
          var='muc#roomconfig_passwordprotectedroom'>
        <value>1</value>
      </field>
      <field type='fixed'>
        <value>
          If a password is required to enter this room,
          you must specify the password below.
        </value>
      </field>
      <field
          label='Password'
          type='text-private'
          var='muc#roomconfig_roomsecret'>
        <value>cauldronburn</value>
      </field>
      <field
          label='Who May Discover Real JIDs?'
          type='list-single'
          var='muc#roomconfig_whois'>
        <value>moderators</value>
        <option label='Moderators Only'>
          <value>moderators</value>
        </option>
        <option label='Anyone'>
          <value>anyone</value>
        </option>
      </field>
      <field type='fixed'>
        <value>
          You may specify additional people who have
          administrative privileges in the room. Please
          provide one Jabber ID per line.
        </value>
      </field>
      <field
          label='Room Admins'
          type='jid-multi'
          var='muc#roomconfig_roomadmins'>
        <value>wiccarocks@shakespeare.lit</value>
        <value>hecate@shakespeare.lit</value>
      </field>
      <field type='fixed'>
        <value>
          You may specify additional owners for this
          room. Please provide one Jabber ID per line.
        </value>
      </field>
      <field
          label='Room Owners'
          type='jid-multi'
          var='muc#roomconfig_roomowners'/>
    </x>
  </query>
</iq>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='config2'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <x xmlns='jabber:x:data' type='cancel'/>
  </query>
</iq>
    

<presence
    from='darkcave@chat.shakespeare.lit/secondwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='wiccarocks@shakespeare.lit/laptop'
          role='participant'/>
  </x>
</presence>

[ ... ]
    

<presence
    from='darkcave@chat.shakespeare.lit/secondwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin'
          jid='wiccarocks@shakespeare.lit/laptop'
          role='moderator'/>
  </x>
</presence>

[ ... ]
    

<presence
    from='darkcave@chat.shakespeare.lit/secondwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin'
          jid='wiccarocks@shakespeare.lit/laptop'
          role='moderator'/>
  </x>
</presence>

[ ... ]
    

<presence
    from='darkcave@chat.shakespeare.lit/secondwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='owner'
          jid='wiccarocks@shakespeare.lit/laptop'
          role='moderator'/>
  </x>
</presence>

[ ... ]
    

10.2.1 Notification of Configuration Changes

A room MUST send notification to all occupants when the room configuration changes in a way that has an impact on the privacy or security profile of the room. This notification shall consist of a <message/> stanza containing an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace, which shall contain only a <status/> element with an appropriate value for the 'code' attribute. Here is an example:

Example 164. Configuration Status Code

<message from='darkcave@chat.shakespeare.lit'
         to='crone1@shakespeare.lit/desktop'
         type='groupchat'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <status code='170'/>
  </x>
</message>
      

The codes to be generated as a result of a privacy-related change in room configuration are as follows:

• If room logging is now enabled, status code 170.
• If room logging is now disabled, status code 171.
• If the room is now non-anonymous, status code 172.
• If the room is now semi-anonymous, status code 173.
• If the room is now fully-anonymous, status code 174.

For any other configuration change, the room SHOULD send status code 104 so that interested occupants can retrieve the updated room configuration if desired.

<iq from='crone1@shakespeare.lit/desktop'
    id='owner1'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='owner'
          jid='hecate@shakespeare.lit'/>
  </query>
</iq>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='owner1'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='owner'
          jid='hecate@shakespeare.lit'>
      <reason>A worthy witch indeed!</reason>
    </item>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='owner1'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>
    

<presence
    from='darkcave@chat.shakespeare.lit/hecate'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='owner'
          jid='hecate@shakespeare.lit'
          role='moderator'/>
  </x>
</presence>

[ ... ]
    

<message
    from='chat.shakespeare.lit'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='hecate@shakespeare.lit'
          role='none'/>
  </x>
</message>

[ ... ]
    

<iq from='crone1@shakespeare.lit/desktop'
    id='owner2'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='admin'
          jid='hecate@shakespeare.lit'/>
  </query>
</iq>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='owner2'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='admin'
          jid='hecate@shakespeare.lit'>
      <reason>Not so worthy after all!</reason> 
    </item>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='owner2'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>
    

<presence
    from='darkcave@chat.shakespeare.lit/secondwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin'
          jid='hecate@shakespeare.lit'
          role='moderator'/>
  </x>
</presence>

[ ... ]
    

<message
    from='chat.shakespeare.lit'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin'
          jid='hecate@shakespeare.lit'
          role='none'/>
  </x>
</message>

[ ... ]
    

<iq from='bard@shakespeare.lit/globe'
    id='owner3'
    to='darkcave@chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='owner'/>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='owner3'
    to='bard@shakespeare.lit/globe'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='owner'
          jid='crone1@shakespeare.lit'/>
  </query>
</iq>
    

<iq from='bard@shakespeare.lit/globe'
    id='owner4'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='owner'
          jid='hecate@shakespeare.lit'/>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='ownertest'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='owner' 
          jid='hecate@shakespeare.lit'/>
  </query>
  <error type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='owner4'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='admin1'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='admin'
          jid='wiccarocks@shakespeare.lit'/>
  </query>
</iq>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='admin1'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='admin'
          jid='wiccarocks@shakespeare.lit'>
      <reason>A worthy witch indeed!</reason>
    </item>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='admin1'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>
    

<presence
    from='darkcave@chat.shakespeare.lit/secondwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin'
          jid='wiccarocks@shakespeare.lit'
          role='moderator'/>
  </x>
</presence>

[ ... ]
    

<message
    from='chat.shakespeare.lit'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin'
          jid='wiccarocks@shakespeare.lit'
          role='none'/>
  </x>
</message>

[ ... ]
    

<iq from='crone1@shakespeare.lit/desktop'
    id='admin2'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'
          jid='wiccarocks@shakespeare.lit'/>
  </query>
</iq>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='admin2'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'
          jid='wiccarocks@shakespeare.lit'>
      <reason>Not so worthy after all!</reason> 
    </item>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='admin2'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>
    

<presence
    from='darkcave@chat.shakespeare.lit/secondwitch'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='wiccarocks@shakespeare.lit'
          role='participant'/>
  </x>
</presence>

[ ... ]
    

<message
    from='chat.shakespeare.lit'
    to='crone1@shakespeare.lit/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='wiccarocks@shakespeare.lit'
          role='none'/>
  </x>
</message>

[ ... ]
    

<iq from='bard@shakespeare.lit/desktopaffiliation
    id='admin3'
    to='darkcave@chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='admin'/>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='admin3'
    to='bard@shakespeare.lit/globe'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='admin'
          jid='wiccarocks@shakespeare.lit'
          nick='secondwitch'/>
    <item affiliation='admin'
          jid='hag66@shakespeare.lit'/>
  </query>
</iq>
    

<iq from='bard@shakespeare.lit/globe'
    id='admin4'
    to='darkcave@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='none'
          jid='hag66@shakespeare.lit'>
    </item>
    <item affiliation='admin'
          jid='hecate@shakespeare.lit'>
    </item>
  </query>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='admintest'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='admin' 
          jid='hecate@shakespeare.lit'/>
  </query>
  <error type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

<iq from='darkcave@chat.shakespeare.lit'
    id='admin4'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>
    

<iq from='crone1@shakespeare.lit/desktop'
    id='begone'
    to='heath@chat.shakespeare.lit'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <destroy jid='darkcave@chat.shakespeare.lit'>
      <reason>Macbeth doth come.</reason>
    </destroy>
  </query>
</iq>
    

<presence
    from='heath@chat.shakespeare.lit/firstwitch'
    to='crone1@shakespeare.lit/desktop'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'/>
    <destroy jid='darkcave@chat.shakespeare.lit'>
      <reason>Macbeth doth come.</reason>
    </destroy>
  </x>
</presence>

<presence
    from='heath@chat.shakespeare.lit/secondwitch'
    to='wiccarocks@shakespeare.lit/laptop'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'/>
    <destroy jid='darkcave@chat.shakespeare.lit'>
      <reason>Macbeth doth come.</reason>
    </destroy>
  </x>
</presence>

<presence
    from='heath@chat.shakespeare.lit/thirdwitch'
    to='hag66@shakespeare.lit/pda'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'/>
    <destroy jid='darkcave@chat.shakespeare.lit'>
      <reason>Macbeth doth come.</reason>
    </destroy>
  </x>
</presence>
    

<iq from='heath@chat.shakespeare.lit'
    id='begone'
    to='crone1@shakespeare.lit/desktop'
    type='result'/>
    

<iq from='heath@chat.shakespeare.lit'
    id='destroytest'
    to='wiccarocks@shakespeare.lit/laptop'
    type='error'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <destroy jid='darkcave@chat.shakespeare.lit'>
      <reason>Macbeth doth come.</reason>
    </destroy>
  </query>
  <error type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

Table 9: Error Codes for http://jabber.org/protocol/muc#user Namespace

<var>
  <name>http://jabber.org/protocol/muc#register</name>
  <desc>Support for the muc#register FORM_TYPE</desc>
  <doc>XEP-0045</doc>
</var>
<var>
  <name>http://jabber.org/protocol/muc#roomconfig</name>
  <desc>Support for the muc#roomconfig FORM_TYPE</desc>
  <doc>XEP-0045</doc>
</var>
<var>
  <name>http://jabber.org/protocol/muc#roominfo</name>
  <desc>Support for the muc#roominfo FORM_TYPE</desc>
  <doc>XEP-0045</doc>
</var>
<var>
  <name>muc_hidden</name>
  <desc>Hidden room in Multi-User Chat (MUC)</desc>
  <doc>XEP-0045</doc>
</var>
<var>
  <name>muc_membersonly</name>
  <desc>Members-only room in Multi-User Chat (MUC)</desc>
  <doc>XEP-0045</doc>
</var>
<var>
  <name>muc_moderated</name>
  <desc>Moderated room in Multi-User Chat (MUC)</desc>
  <doc>XEP-0045</doc>
</var>
<var>
  <name>muc_nonanonymous</name>
  <desc>Non-anonymous room in Multi-User Chat (MUC)</desc>
  <doc>XEP-0045</doc>
</var>
<var>
  <name>muc_open</name>
  <desc>Open room in Multi-User Chat (MUC)</desc>
  <doc>XEP-0045</doc>
</var>
<var>
  <name>muc_passwordprotected</name>
  <desc>Password-protected room in Multi-User Chat (MUC)</desc>
  <doc>XEP-0045</doc>
</var>
<var>
  <name>muc_persistent</name>
  <desc>Persistent room in Multi-User Chat (MUC)</desc>
  <doc>XEP-0045</doc>
</var>
<var>
  <name>muc_public</name>
  <desc>Public room in Multi-User Chat (MUC)</desc>
  <doc>XEP-0045</doc>
</var>
<var>
  <name>muc_rooms</name>
  <desc>List of MUC rooms (each as a separate item)</desc>
  <doc>XEP-0045</doc>
</var>
<var>
  <name>muc_semianonymous</name>
  <desc>Semi-anonymous room in Multi-User Chat (MUC)</desc>
  <doc>XEP-0045</doc>
</var>
<var>
  <name>muc_temporary</name>
  <desc>Temporary room in Multi-User Chat (MUC)</desc>
  <doc>XEP-0045</doc>
</var>
<var>
  <name>muc_unmoderated</name>
  <desc>Unmoderated room in Multi-User Chat (MUC)</desc>
  <doc>XEP-0045</doc>
</var>
<var>
  <name>muc_unsecured</name>
  <desc>Unsecured room in Multi-User Chat (MUC)</desc>
  <doc>XEP-0045</doc>
</var>
    

15.5.1 muc#register FORM_TYPE

Registry Submission

<form_type>
  <name>http://jabber.org/protocol/muc#register</name>
  <doc>XEP-0045</doc>
  <desc>
    Forms enabling user registration with a
    Multi-User Chat (MUC) room or admin approval
    of user registration requests.
  </desc>
  <field 
     var='muc#register_allow'
     type='boolean'
     label='Allow this person to register with the room?'/>
  <field
      var='muc#register_email'
      type='text-single'
      label='Email Address'/>
  <field
      var='muc#register_faqentry'
      type='text-multi'
      label='FAQ Entry'/>
  <field
      var='muc#register_first'
      type='text-single'
      label='Given Name'/>
  <field
      var='muc#register_last'
      type='text-single'
      label='Family Name'/>
  <field
      var='muc#register_roomnick'
      type='text-single'
      label='Desired Nickname'/>
  <field
      var='muc#register_url'
      type='text-single'
      label='Your URL'/>
</form_type>
      

15.5.2 muc#request FORM_TYPE

Registry Submission

<form_type>
  <name>http://jabber.org/protocol/muc#request</name>
  <doc>XEP-0045</doc>
  <desc>
    Forms enabling voice requests in a 
    Multi-User Chat (MUC) room or admin
    approval of such requests.
  </desc>
  <field var='muc#role'
         type='text-single'
         label='Requested role'/>
  <field var='muc#jid'
         type='text-single'
         label='User ID'/>
  <field var='muc#roomnick'
         type='text-single'
         label='Room Nickname'/>
  <field var='muc#request_allow'
         type='boolean'
         label='Whether to grant voice'/>
</form_type>
      

15.5.3 muc#roomconfig FORM_TYPE

Registry Submission

<form_type>
  <name>http://jabber.org/protocol/muc#roomconfig</name>
  <doc>XEP-0045</doc>
  <desc>
    Forms enabling creation and configuration of
    a Multi-User Chat (MUC) room.
  </desc>
  <field
      var='muc#roomconfig_allowinvites'
      type='boolean'
      label='Whether to Allow Occupants to Invite Others'/>
  <field
      var='muc#roomconfig_changesubject'
      type='boolean'
      label='Whether to Allow Occupants to Change Subject'/>
  <field
      var='muc#roomconfig_enablelogging'
      type='boolean'
      label='Whether to Enable Public Logging of Room Conversations'/>
  <field
      var='muc#roomconfig_getmemberlist'
      type='list-multi'
      label='Roles and Affiliations that May Retrieve Member List'/>
  <field
      var='muc#roomconfig_lang'
      type='text-single'
      label='Natural Language for Room Discussions'/>
  <field
      var='muc#roomconfig_pubsub'
      type='text-single'
      label='XMPP URI of Associated Publish-Subcribe Node'/>
  <field
      var='muc#roomconfig_maxusers'
      type='list-single'
      label='Maximum Number of Room Occupants'/>
  <field
      var='muc#roomconfig_membersonly'
      type='boolean'
      label='Whether an Make Room Members-Only'/>
  <field
      var='muc#roomconfig_moderatedroom'
      type='boolean'
      label='Whether to Make Room Moderated'/>
  <field
      var='muc#roomconfig_passwordprotectedroom'
      type='boolean'
      label='Whether a Password is Required to Enter'/>
  <field
      var='muc#roomconfig_persistentroom'
      type='boolean'
      label='Whether to Make Room Persistent'/>
  <field
      var='muc#roomconfig_presencebroadcast'
      type='list-multi'
      label='Roles for which Presence is Broadcast'/>
  <field
      var='muc#roomconfig_publicroom'
      type='boolean'
      label='Whether to Allow Public Searching for Room'/>
  <field
      var='muc#roomconfig_roomadmins'
      type='jid-multi'
      label='Full List of Room Admins'/>
  <field
      var='muc#roomconfig_roomdesc'
      type='text-single'
      label='Short Description of Room'/>
  <field
      var='muc#roomconfig_roomname'
      type='text-single'
      label='Natural-Language Room Name'/>
  <field
      var='muc#roomconfig_roomowners'
      type='jid-multi'
      label='Full List of Room Owners'/>
  <field
      var='muc#roomconfig_roomsecret'
      type='text-private'
      label='The Room Password'/>
  <field
      var='muc#roomconfig_whois'
      type='list-single'
      label='Affiliations that May Discover Real JIDs of Occupants'/>
</form_type>
      

15.5.4 muc#roominfo FORM_TYPE

Registry Submission

<form_type>
  <name>http://jabber.org/protocol/muc#roominfo</name>
  <doc>XEP-0045</doc>
  <desc>
    Forms enabling the communication of extended service discovery
    information about a Multi-User Chat (MUC) room.
  </desc>
  <field
      var='muc#roominfo_contactjid'
      type='jid-multi'
      label='Contact Addresses (normally, room owner or owners)'/>
  <field
      var='muc#roominfo_description'
      type='text-single'
      label='Short Description of Room'/>
  <field
      var='muc#roominfo_lang'
      type='text-single'
      label='Natural Language for Room Discussions'/>
  <field
      var='muc#roominfo_ldapgroup'
      type='text-single'
      label='An associated LDAP group that defines room membership; 
             this should be an LDAP Distinguished Name according to an
             implementation-specific or deployment-specific definition
             of a group.'/>
  <field
      var='muc#roominfo_logs'
      type='text-single'
      label='URL for Archived Discussion Logs'/>
  <field
      var='muc#roominfo_occupants'
      type='text-single'
      label='Current Number of Occupants in Room'/>
  <field
      var='muc#roominfo_subject'
      type='text-single'
      label='Current Subject or Discussion Topic in Room'/>
  <field
      var='muc#roominfo_subjectmod'
      type='boolean'
      label='The room subject can be modified by participants'/>
</form_type>
      

15.6.1 Process

The XMPP Registrar maintains a registry of values for the 'code' attribute of the <status/> element when qualified by the 'http://jabber.org/protocol/muc#user' namespace.

In order to submit new values to this registry, the registrant shall define an XML fragment of the following form and either include it in the relevant XMPP Extension Protocol or send it to the email address <registrar@xmpp.org>:

<statuscode>
  <number>the three-digit code number</number>
  <stanza>the stanza type of which it is a child (message or presence)</stanza>
  <context>the use case or situation in which the status is used</context>
  <purpose>a natural-language description of the meaning</purpose>
  <child>the descriptive child element (reserved for future use)</child>
</statuscode>
      

The registrant may register more than one status code at a time, each contained in a separate <statuscode/> element.

15.6.2 Initial Submission

As part of this document, the following status codes are registered:

<statuscode>
  <number>100</number>
  <stanza>message or presence</stanza>
  <context>Entering a room</context>
  <purpose>Inform user that any occupant is allowed to see the user's full JID</purpose>
</statuscode>
<statuscode>
  <number>101</number>
  <stanza>message (out of band)</stanza>
  <context>Affiliation change</context>
  <purpose>Inform user that his or her affiliation changed while not in the room</purpose>
</statuscode>
<statuscode>
  <number>102</number>
  <stanza>message</stanza>
  <context>Configuration change</context>
  <purpose>Inform occupants that room now shows unavailable members</purpose>
</statuscode>
<statuscode>
  <number>103</number>
  <stanza>message</stanza>
  <context>Configuration change</context>
  <purpose>Inform occupants that room now does not show unavailable members</purpose>
</statuscode>
<statuscode>
  <number>104</number>
  <stanza>message</stanza>
  <context>Configuration change</context>
  <purpose>
    Inform occupants that a non-privacy-related room configuration change has occurred
  </purpose>
</statuscode>
<statuscode>
  <number>110</number>
  <stanza>presence</stanza>
  <context>Any room presence</context>
  <purpose>Inform user that presence refers to one of its own room occupants</purpose>
</statuscode>
<statuscode>
  <number>170</number>
  <stanza>message or initial presence</stanza>
  <context>Configuration change</context>
  <purpose>Inform occupants that room logging is now enabled</purpose>
</statuscode>
<statuscode>
  <number>171</number>
  <stanza>message</stanza>
  <context>Configuration change</context>
  <purpose>Inform occupants that room logging is now disabled</purpose>
</statuscode>
<statuscode>
  <number>172</number>
  <stanza>message</stanza>
  <context>Configuration change</context>
  <purpose>Inform occupants that the room is now non-anonymous</purpose>
</statuscode>
<statuscode>
  <number>173</number>
  <stanza>message</stanza>
  <context>Configuration change</context>
  <purpose>Inform occupants that the room is now semi-anonymous</purpose>
</statuscode>
<statuscode>
  <number>174</number>
  <stanza>message</stanza>
  <context>Configuration change</context>
  <purpose>Inform occupants that the room is now fully-anonymous</purpose>
</statuscode>
<statuscode>
  <number>201</number>
  <stanza>presence</stanza>
  <context>Entering a room</context>
  <purpose>Inform user that a new room has been created</purpose>
</statuscode>
<statuscode>
  <number>210</number>
  <stanza>presence</stanza>
  <context>Entering a room</context>
  <purpose>Inform user that service has assigned or modified occupant's roomnick</purpose>
</statuscode>
<statuscode>
  <number>301</number>
  <stanza>presence</stanza>
  <context>Removal from room</context>
  <purpose>Inform user that he or she has been banned from the room</purpose>
</statuscode>
<statuscode>
  <number>303</number>
  <stanza>presence</stanza>
  <context>Exiting a room</context>
  <purpose>Inform all occupants of new room nickname</purpose>
</statuscode>
<statuscode>
  <number>307</number>
  <stanza>presence</stanza>
  <context>Removal from room</context>
  <purpose>Inform user that he or she has been kicked from the room</purpose>
</statuscode>
<statuscode>
  <number>321</number>
  <stanza>presence</stanza>
  <context>Removal from room</context>
  <purpose>Inform user that he or she is being removed from the room 
    because of an affiliation change</purpose>
</statuscode>
<statuscode>
  <number>322</number>
  <stanza>presence</stanza>
  <context>Removal from room</context>
  <purpose>Inform user that he or she is being removed from the room 
    because the room has been changed to members-only and the user 
    is not a member</purpose>
</statuscode>
<statuscode>
  <number>332</number>
  <stanza>presence</stanza>
  <context>Removal from room</context>
  <purpose>Inform user that he or she is being removed from the room 
    because of a system shutdown</purpose>
</statuscode>
      

15.7.1 join

The "join" querytype is registered as a MUC-related action, with an optional key of "password".

Example 199. Join Action: IRI/URI

xmpp:darkcave@chat.shakespeare.lit?join
      

The application MUST either present an interface enabling the user to provide a room nickname or populate the room nickname based on configured preferences or nickname discovery.

Example 200. Join Action: Resulting Stanza

<presence to='darkcave@chat.shakespeare.lit/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>
      

The join action MAY include a password for the room. Naturally, access to a URI that includes a room password MUST be appropriately controlled.

Example 201. Join Action with Password: IRI/URI

xmpp:darkcave@chat.shakespeare.lit?join;password=cauldronburn
      

Example 202. Join Action with Password: Resulting Stanza

<presence to='darkcave@chat.shakespeare.lit/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <password>cauldronburn</password>
  </x>
</presence>
      

The following submission registers the "join" querytype.

<querytype>
  <name>join</name>
  <proto>http://jabber.org/protocol/muc</proto>
  <desc>enables joining a multi-user chat room</desc>
  <doc>XEP-0045</doc>
  <keys>
    <key>
      <name>password</name>
      <desc>the password required to enter a multi-user chat room</desc>
    </key>
  </keys>
</querytype>
      

15.7.2 invite

The "invite" querytype is registered as a MUC-related action, with an optional key of "jid".

Example 203. Invite Action: IRI/URI

xmpp:darkcave@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit
      

If the joining user is not yet in the room, the application MUST send two stanzas: the first to join the room and the second to invite the other individual. If the joining user is in the room already, the application shall send only the invitation stanza.

Example 204. Invite Action: Resulting Stanza(s)

<presence to='darkcave@chat.shakespeare.lit/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

<message to='darkcave@chat.shakespeare.lit'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite to='hecate@shakespeare.lit'/>
  </x>
</message>
      

The URI may include multiple invitees:

Example 205. Invite Action With Multiple Invitees: IRI/URI

xmpp:darkcave@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;jid=bard@shakespeare.lit
      

Example 206. Invite Action With Multiple Invitees: Resulting Stanza

<message to='darkcave@chat.shakespeare.lit'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite to='hecate@shakespeare.lit'/>
    <invite to='bard@shakespeare.lit'/>
  </x>
</message>
      

The URI may also include a password:

Example 207. Invite Action With Password: IRI/URI

xmpp:darkcave@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauldronburn
      

If the joining user is not yet in the room, the application MUST send two stanzas: the first to join the room and the second to invite the other individual. If the joining user is in the room already, the application shall send only the invitation stanza.

Example 208. Invite Action With Password: Resulting Stanza(s)

<presence to='darkcave@chat.shakespeare.lit/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

<message to='darkcave@chat.shakespeare.lit'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite to='hecate@shakespeare.lit'/>
    <password>cauldronburn</password>
  </x>
</message>
      

The following submission registers the "invite" querytype.

<querytype>
  <name>invite</name>
  <proto>http://jabber.org/protocol/muc</proto>
  <desc>enables simultaneously joining a groupchat room and inviting others</desc>
  <doc>XEP-0045</doc>
  <keys>
    <key>
      <name>jid</name>
      <desc>the Jabber ID of the invitee</desc>
    </key>
    <key>
      <name>password</name>
      <desc>the password required to enter a multi-user chat room</desc>
    </key>
  </keys>
</querytype>
      

17.1.1 Allowable Traffic

As noted, a service (more precisely, a properly-configured room) MAY discard some or all extended namespaces attached to <message/> and <presence/> stanzas that are intended for reflection from the sender through the room to all of the room occupants. If the room does so, it SHOULD enable senders to discover the list of allowable extensions by sending a disco#info query to the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic', returning one <feature/> element for each namespace supported in the result. If the room does not allow any extended namespaces, it MUST return an empty query as specified in XEP-0030. If the room does not support the "#traffic" node, it MUST return a <feature-not-implemented/> error in response to queries sent to the 'http://jabber.org/protocol/muc#traffic' node.

The following example shows a room that allows the 'http://jabber.org/protocol/xhtml-im' and 'http://jabber.org/protocol/rosterx' namespaces only, but no other extended namespaces.

Example 209. User Queries Service Regarding Allowable Namespaces

<iq from='wiccarocks@shakespeare.lit/laptop'
    to='heath@chat.shakespeare.lit'
    id='allow1'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://jabber.org/protocol/muc#traffic'/>
</iq>
      

Example 210. Service Returns Allowable Namespaces

<iq from='heath@chat.shakespeare.lit'
    to='wiccarocks@shakespeare.lit/laptop'
    id='allow1'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://jabber.org/protocol/muc#traffic'>
    <feature var='http://jabber.org/protocol/xhtml-im'/>
    <feature var='http://jabber.org/protocol/rosterx'/>
  </query>
</iq>
      

If a service does not discard any namespaces or does not implement this feature, it MUST return a <service-unavailable/> error:

Example 211. Service Returns Service Unavailable

<iq from='heath@chat.shakespeare.lit'
    to='wiccarocks@shakespeare.lit/laptop'
    id='allow1'
    type='error'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://jabber.org/protocol/muc#traffic'/>
  <error type='cancel'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
      

17.2.1 IRC Command Mapping

Internet Relay Chat clients use a number of common "shortcut" commands that begin with a forward slash, such as '/nick' and '/ban'. The following table provides a mapping of IRC-style commands to MUC protocols, for use by Jabber clients that wish to support such functionality.

<iq id='someid'
    to='room@service'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='outcast'
          jid='bare-jid-of-user'>
      <reason>comment</reason>
    </item>
  </query>
</iq>
          

<message to='room@service'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite to='jid'>
      <reason>comment</reason>
    </invite>
  </x>
</message>
          

<presence to='room@service/nick'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <password>pass</password>
  </x>
</presence>
          

<iq id='someid'
    to='room@service'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='roomnick' role='none'>
      <reason>comment</reason>
    </item>
  </query>
</iq>
          

<message to='room@service/nick' type='chat'>
  <body>foo</body>
</message>
          

<presence to='room@service/newnick'/>
          

<presence to='room@service/nick'
          type='unavailable'>
  <status>comment</status>
</presence>
          

<message to='room@service' type='groupchat'>
  <subject>foo</subject>
</message>
          

Note: Because MUC roomnicks follow the Resourceprep profile of stringprep, they are allowed to contain a space character, whereas IRC nicknames do not. Although a given client MAY support quotation characters for this purpose (resulting in commands such as '/ban "king lear" insanity is no defense'), most common quotation characters (such as " and ') are also allowed by Resourceprep, thus leading to added complexity and potential problems with quotation of roomnicks that contain both spaces and quotation characters. Therefore it is NOT RECOMMENDED for Jabber clients to support IRC-style shortcut commands with roomnicks that contain space characters.

Note: Many Jabber clients also implement a '/me ' command as described in The /me Command [33]. This command does not result in any MUC or IRC protocol action and is therefore not shown in the foregoing table.

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

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/muc'
    xmlns='http://jabber.org/protocol/muc'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0045: http://www.xmpp.org/extensions/xep-0045.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='x'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='history' minOccurs='0'/>
        <xs:element name='password' type='xs:string' minOccurs='0'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='history'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='maxchars' type='xs:int' use='optional'/>
          <xs:attribute name='maxstanzas' type='xs:int' use='optional'/>
          <xs:attribute name='seconds' type='xs:int' use='optional'/>
          <xs:attribute name='since' type='xs:dateTime' use='optional'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
    

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

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/muc#user'
    xmlns='http://jabber.org/protocol/muc#user'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0045: http://www.xmpp.org/extensions/xep-0045.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='x'>
    <xs:complexType>
      <xs:choice minOccurs='0' maxOccurs='unbounded'>
        <xs:element ref='decline' minOccurs='0'/>
        <xs:element ref='destroy' minOccurs='0'/>
        <xs:element ref='invite' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='item' minOccurs='0'/>
        <xs:element name='password' type='xs:string' minOccurs='0'/>
        <xs:element ref='status' minOccurs='0' maxOccurs='unbounded'/>
      </xs:choice>
    </xs:complexType>
  </xs:element>

  <xs:element name='decline'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='reason' minOccurs='0'/>
      </xs:sequence>
      <xs:attribute name='from' type='xs:string' use='optional'/>
      <xs:attribute name='to' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='destroy'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='reason' minOccurs='0'/>
      </xs:sequence>
      <xs:attribute name='jid' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='invite'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='reason' minOccurs='0'/>
      </xs:sequence>
      <xs:attribute name='from' type='xs:string' use='optional'/>
      <xs:attribute name='to' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='item'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='actor' minOccurs='0'/>
        <xs:element ref='reason' minOccurs='0'/>
        <xs:element ref='continue' minOccurs='0'/>
      </xs:sequence>
      <xs:attribute name='affiliation' use='optional'>
        <xs:simpleType>
          <xs:restriction base='xs:NCName'>
            <xs:enumeration value='admin'/>
            <xs:enumeration value='member'/>
            <xs:enumeration value='none'/>
            <xs:enumeration value='outcast'/>
            <xs:enumeration value='owner'/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
      <xs:attribute name='jid' type='xs:string' use='optional'/>
      <xs:attribute name='nick' type='xs:string' use='optional'/>
      <xs:attribute name='role' use='optional'>
        <xs:simpleType>
          <xs:restriction base='xs:NCName'>
            <xs:enumeration value='moderator'/>
            <xs:enumeration value='none'/>
            <xs:enumeration value='participant'/>
            <xs:enumeration value='visitor'/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
    </xs:complexType>
  </xs:element>

  <xs:element name='actor'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='jid' type='xs:string' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='continue'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='thread' type='xs:string' use='optional'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='status'>
    <xs:complexType>
      <xs:attribute name='code' use='required'>
        <xs:simpleType>
          <xs:restriction base='xs:int'>
            <xs:minInclusive value='100'/>
            <xs:maxInclusive value='999'/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
    </xs:complexType>
  </xs:element>

  <xs:element name='reason' type='xs:string'/>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
    

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

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/muc#admin'
    xmlns='http://jabber.org/protocol/muc#admin'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0045: http://www.xmpp.org/extensions/xep-0045.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='query'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='item' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='item'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='actor' minOccurs='0'/>
        <xs:element ref='reason' minOccurs='0'/>
      </xs:sequence>
      <xs:attribute name='affiliation' use='optional'>
        <xs:simpleType>
          <xs:restriction base='xs:NCName'>
            <xs:enumeration value='admin'/>
            <xs:enumeration value='member'/>
            <xs:enumeration value='none'/>
            <xs:enumeration value='outcast'/>
            <xs:enumeration value='owner'/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
      <xs:attribute name='jid' type='xs:string' use='optional'/>
      <xs:attribute name='nick' type='xs:string' use='optional'/>
      <xs:attribute name='role' use='optional'>
        <xs:simpleType>
          <xs:restriction base='xs:NCName'>
            <xs:enumeration value='moderator'/>
            <xs:enumeration value='none'/>
            <xs:enumeration value='participant'/>
            <xs:enumeration value='visitor'/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
    </xs:complexType>
  </xs:element>

  <xs:element name='actor'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='jid' type='xs:string' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='reason' type='xs:string'/>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
    

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

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/muc#owner'
    xmlns='http://jabber.org/protocol/muc#owner'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0045: http://www.xmpp.org/extensions/xep-0045.html
    </xs:documentation>
  </xs:annotation>

  <xs:import 
      namespace='jabber:x:data'
      schemaLocation='http://www.xmpp.org/schemas/x-data.xsd'/>

  <xs:element name='query'>
    <xs:complexType>
      <xs:choice xmlns:xdata='jabber:x:data' minOccurs='0'>
        <xs:element ref='xdata:x'/>
        <xs:element ref='destroy'/>
      </xs:choice>
    </xs:complexType>
  </xs:element>

  <xs:element name='destroy'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='password' type='xs:string' minOccurs='0'/>
        <xs:element name='reason' type='xs:string' minOccurs='0'/>
      </xs:sequence>
      <xs:attribute name='jid' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
    

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

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/muc#unique'
    xmlns='http://jabber.org/protocol/muc#unique'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0045: http://www.xmpp.org/extensions/xep-0045.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='unique' type='xs:string'/>

</xs:schema>
    

Added more examples of the reason element; removed mention of nick inclusion with regard to ban lists; added denial of service considerations.

• Defined getmemberlist room configuration option
• Added direct invitation protocol
• Corrected logic regarding admission of room owner/admin when room is full
• Defined service discovery extension field for associated LDAP group
• Specified that room config fields can be listed in extended room information
• Specified message format for affiliation change notifications if user is not in the room
• Added example showing use of Result Set Management
• Recommended inclusion of MUC child element in presence errors
• 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.

Updated delayed delivery reference to reflect advancement of XEP-0203 to Draft and deprecation of XEP-0091.

• 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.
• Specified use of <not-acceptable/> error on nickname change if nicks are locked down.
• 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.
• Specified use of <not-acceptable/> error if room configuration options cannot be processed or violate service policies.
• Made explicit that roomnicks must not consist only of spaces.
• Moved all service discovery use cases into dedicated section.
• Changed urn:xmpp:delay support from SHOULD to MUST.
• Clarified that _whois room configuration option specifies room type.
• Defined XEP-0128 room information fields for discussion logs, associated pubsub node, and contact JID.
• Specified that changing role to moderator upon affiliation change to admin or owner is recommended, not required.
• Added internationalization consideration about localization of field labels for various data forms.
• Specified that implementations may persist roles across visits and should do so for moderated rooms.
• Added protocol and service discovery feature for requesting a unique room name prior to room creation.
• Further clarified nature of reserved room nicknames and nickname lockdown.
• Defined data forms for requesting voice and approving voice requests.
• Added multiple invitee example for XMPP URI.
• Clarified order of presence, discussion history, etc.
• Added status codes for occupant's own roomnick, service-modified roomnick, and warning that room discussion is publicly logged.
• Clarified privacy and anonymity considerations regarding room logging and non-anonymous rooms.

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.

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 <not-allowed/> to <service-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.

Corrected several errors in the affiliation state chart and in the examples (wrong FORM_TYPE values); mentioned /me command.

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.

Added example and registry submission for service discovery extension.

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.

Corrected discovery of registered roomnicks; added note about error to return if nicks are locked down.

Fixed an error in the muc#user schema.

Corrected a few errors in the examples; added IQ results in order to clarify workflows.

Clarified JID matching rules (same as for privacy lists in XMPP IM).

Added XMPP error handling; fully specified all conformance terms.

Removed protocol for requesting voice in a moderated room (should be performed using Ad-Hoc Commands).

Added protocol for requesting voice in a moderated room; added (informational) mapping of IRC commands to MUC protocols.

Added room configuration option for restricting presence broadcast to certain roles.

Added history management protocol on entering a room.

Specified that ban occurs by JID, not roomnick; allowed privileged users to send messages to the room even if not present in the room; added note that service should remove occupant if a delivery-related stanza error occurs; enabled user to disco the room in order to discover registered roomnick; specified that "banning" by domain or regex is a service-level configuration matter and therefore out of scope for MUC; specified that role should be decremented as appropriate if affiliation is lowered; added some clarifying text to room creation workflow; added implementation note about sending an out-of-band message if a user's affiliation changes while the user is not in the room; fixed stringprep references (room nicks use Resourceprep); clarified relationship between Room ID (i.e., node identifier of Room JID, which may be opaque) and natural-language Room Name; specified Field Standardization profile per XEP-0068; defined XMPP Registrar submissions; added schema locations.

Added XML schemas.

Added reference to nodeprep Internet-Draft.

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.

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.

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

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.

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.

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.

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.

Added ability to create an instant room within MUC (not by using gc-1.0 protocol); cleaned up disco examples.

Added experimental support for disco; added sections for security, IANA, and JANA considerations; corrected typographical errors; cleaned up some DocBook formatting.

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.

Added the <item/> element to presence stanzas of type "unavailable" in order to improve the tracking of user states in the room; consolidated <invitee/> and <invitor/> elements into an <invite/> element with 'from' and 'to' attributes; made <reason/> element always a child of <item/> or <invite/> in the muc#user namespace; moved the alternate room location in room destruction to a 'jid' attribute of the <alt/> element; further specified several error messages; disallowed simultaneous modifications of both affiliations and roles by a moderator or admin; added several more rules regarding handling of XML stanzas; added use cases for granting and revoking administrative privileges; adjusted DTD to track all changes.

Fully incorporated the change to affiliations + roles; moved a number of admin use cases to a new section for moderator use cases; added participant use case for requesting membership; added admin use cases for adding members, removing members, granting and revoking moderator privileges, and modifying the moderator list; organized the sections in a more logical manner.

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

Corrected the change nickname examples (newnick sent on unavailable, no nick sent on available).

Removed SHA1 passwords; specified that room shall add passwords on invitations to password-protected rooms (not supplied by invitor).

Changed 'participant' to 'room user' and 'discussant' to 'participant'; clarified presence rule about client generation of extended presence information; added role of 'none'.

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.

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.

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.

Fixed the room creation workflow; changed some terminology ("join" to "enter" and "leave" to "exit").

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.

Changed namespaces from http://jabber.org/protocol/muc/owner etc. to http://jabber.org/protocol/muc#owner etc. per Jabber Council discussion.

Changed namespaces to HTTP URIs; left role handling up to the implementation; further clarified presence rules.

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.

Removed <whois/> command (unnecessary since participants with appropriate privileges receive the full JID of all participants in presence stanzas); completed many small fixes throughout.

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.

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.

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.

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.

Changed all non-GC-1.0 use cases to jabber:gc:* namespaces or jabber:x:data; added use cases for ban list management and room moderation; added protocol for sending notice of admin and voice privileges in presence; cleaned up text and many examples.

Changed admin use cases; cleaned up participant and owner use cases.

Broke content out into three actors (participant, owner, and admin) and added more detail to owner and admin use cases.

Initial version.