JEP-0045: Multi-User Chat

Peter Saint-Andre

Email: stpeter@jabber.org
JID: stpeter@jabber.org

1. Introduction

2. Scope

3. Requirements

4. Terminology

4.1. General Terms

4.2. Room Types

5. Roles and Affiliations

5.1. Roles

5.1.1. Privileges

5.1.2. Changing Roles

5.2. Affiliations

5.2.1. Privileges

5.2.2. Changing Affiliations

6. Occupant Use Cases

6.1. Discovering Component Support for MUC

6.2. Discovering Client Support for MUC

6.3. Entering a Room

6.3.1. Groupchat 1.0 Protocol

6.3.2. Basic MUC Protocol

6.3.3. Presence Broadcast

6.3.4. Default Roles

6.3.5. Non-Anonymous Rooms

6.3.6. Semi-Anonymous Rooms

6.3.7. Password-Protected Rooms

6.3.8. Members-Only Rooms

6.3.9. Banned Users

6.3.10. Nickname Conflict

6.3.11. Max Users

6.3.12. Discussion History

6.3.13. Managing Discussion History

6.3.14. Locked Room

6.3.15. Nonexistent Room

6.4. Exiting a Room

6.5. Changing Nickname

6.6. Changing Availability Status

6.7. Inviting Another User to a Room

6.8. Converting a One-to-One Chat Into a Conference

6.9. Occupant Modification of the Room Subject

6.10. Sending a Private Message

6.11. Sending a Message to All Occupants

6.12. Registering with a Room

6.13. Discovering Reserved Room Nickname

7. Moderator Use Cases

7.1. Modifying the Room Subject

7.2. Kicking a Visitor or Participant from a Room

7.3. Granting Voice to a Visitor

7.4. Revoking Voice from a Participant

7.5. Modifying the Voice List

8. Admin Use Cases

8.1. Banning a User

8.2. Modifying the Ban List

8.3. Granting Membership

8.4. Revoking Membership

8.5. Modifying the Member List

8.6. Granting Moderator Privileges

8.7. Revoking Moderator Privileges

8.8. Modifying the Moderator List

8.9. Approving Registration Requests

9. Owner Use Cases

9.1. Creating a Room

9.1.1. General Considerations

9.1.2. Creating an Instant Room

9.1.3. Creating a Reserved Room

9.2. Subsequent Room Configuration

9.3. Granting Ownership Privileges

9.4. Revoking Ownership Privileges

9.5. Modifying the Owner List

9.6. Granting Administrative Privileges

9.7. Revoking Administrative Privileges

9.8. Modifying the Admin List

9.9. Destroying a Room

10. Error and Status Codes

10.1. Error Codes

10.2. Status Codes

11. Internationalization Considerations

12. Security Considerations

13. IANA Considerations

14. Jabber Registrar Considerations

14.1. Protocol Namespaces

14.2. Service Discovery Category/Type

14.3. Service Discovery Features

14.4. Well-Known Service Discovery Nodes

14.5. Field Standardization

14.5.1. muc#register FORM_TYPE

14.5.2. muc#roomconfig FORM_TYPE

14.5.3. muc#roominfo FORM_TYPE

14.6. Status Codes Registry

14.6.1. Process

14.6.2. Initial Submission

15. Business Rules

15.1. Addresses

15.2. Message

15.3. Presence

15.4. IQ

16. Implementation Notes

16.1. Services

16.1.1. Allowable Traffic

16.2. Clients

16.2.1. IRC Command Mapping

17. XML Schemas

17.1. http://jabber.org/protocol/muc

17.2. http://jabber.org/protocol/muc#user

17.3. http://jabber.org/protocol/muc#admin

17.4. http://jabber.org/protocol/muc#owner

18. Acknowledgements

Notes

Revision History

4.1 General Terms

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 [2] 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 future retrieval inside or 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 an affiliation of "moderator".

MUC -- the multi-user chat protocol for text-based conferencing specified in this JEP.

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.

4.2 Room Types

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.

5.1 Roles

There are four defined roles that an occupant may have:

1. Moderator
2. Participant
3. Visitor
4. None (the absence of a role)

These roles are temporary in that they do not persist across a user's visits to the room and MAY change during the course of an occupant's visit to the room. In addition, there is no one-to-one mapping between these roles and a user's affiliation with the room (e.g., a member could be a participant or a visitor).

A moderator is the most powerful occupant within the context of the room, and can to some extent manage other occupants' roles in the room. A participant has fewer privileges than a moderator, although he or she always has the right to speak. A visitor is a more restricted role within the context of a moderated room, since visitors are not allowed to send messages to all occupants.

Roles are granted, revoked, and maintained based on the occupant's room nickname or full JID rather than bare JID. The privileges associated with these roles, as well as the actions that trigger changes in roles, are defined below.

Information about roles MUST be sent in all presence stanzas generated or reflected by the room and thus sent to occupants.

5.2 Affiliations

There are five defined affiliations that a user may have in relation to a room:

1. Owner
2. Admin
3. Member
4. Outcast
5. None (the absence of an affiliation)

These affiliations are long-lived in that they persist across a user's visits to the room and are not affected by happenings in the room. In addition, there is no one-to-one mapping between these affiliations and an occupant's role within the room. Affiliations are granted, revoked, and maintained based on the user's bare JID.

If a user without a defined affiliation enters a room, the user's affiliation is defined as "none"; however, this affiliation does not persist across visits (i.e., a service does not maintain a "none list" across visits).

The member affiliation provides a way for a room owner or admin to specify a "whitelist" of users who are allowed to enter a members-only room. When a member enters a members-only room, his or her affiliation does not change, no matter what his or her role is. The member affiliation also provides a way for users to effectively register with an open room and thus be lastingly associated with that room in some way (one result may be that the user's nickname is reserved in the room).

An outcast is a user who has been banned from a room and who is not allowed to enter the room.

Information about affiliations MUST be sent in all presence stanzas generated or reflected by the room and sent to occupants.

6.1 Discovering Component Support for MUC

Before entering a room, a Jabber user may want to discover if the room implements the Multi-User Chat protocol.

A MUC implementation MUST support Service Discovery [4].

Example 1. User Queries Chat Service for MUC Support via Disco

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

The service MUST return its identity and the features it supports:

Example 2. Service Returns Disco Info Results

<iq from='macbeth.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>
    

Note: Because MUC is a superset of the old "groupchat 1.0" protocol, a MUC service SHOULD NOT return a <feature var='gc-1.0'/> entry in a disco#info result.

The disco protocol also enables a user to query a service for a list of associated items, which in the case of a chat service would mainly consist of the specific chat rooms hosted by the service.

Example 3. User Queries Chat Service for Associated Items

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

Example 4. Service Returns Disco Item Results

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

Using disco, a user may also query a specific chat room for more detailed information about the room:

Example 5. User Queries for Information about a Specific Chat Room

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

The room MUST return its identity and SHOULD return the features it supports:

Example 6. Room Returns Disco Info Results

<iq from='darkcave@macbeth.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>
    

Note: Because MUC is a superset of the old "groupchat 1.0" protocol, a MUC room SHOULD NOT return a <feature var='gc-1.0'/> entry in a disco#info result. The room SHOULD return the materially-relevant features it supports, such as password protection and room moderation (these are listed fully in the feature registry maintained by the Jabber Registrar; see also the Jabber Registrar section of this document).

A chatroom MAY return more detailed information in its disco#info response using Service Discovery Extensions [5], identified by inclusion of a hidden FORM_TYPE field whose value is "http://jabber.org/protocol/muc#roominfo". Such information might include a more verbose description of the room, the current room subject, and the current number of occupants in the room:

Example 7. Room Returns Extended Disco Info Results

<iq from='darkcave@macbeth.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_subject' label='Subject'>
        <value>Spells</value>
      </field>
      <field var='muc#roominfo_occupants' label='Number of occupants'>
        <value>3</value>
      </field>
      <field var='muc#roominfo_lang' label='Language of discussion'>
        <value>en</value>
      </field>
    </x>
  </query>
</iq>
    

Note: The foregoing extended service discovery fields for the 'http://jabber.org/protocol/muc#roominfo' FORM_TYPE may be supplemented in the future via the mechanisms described in the Field Standardization section of this document.

Finally, a user MAY also query a specific chat room for its associated items:

Example 8. User Queries for Items Associated with a Specific Chat Room

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

An implementation MAY return a list of existing occupants if that information is publicly available, or return no list at all if this information is kept private.

Example 9. Room Returns Disco Item Results (Items are Public)

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

Note: These <item/> elements are qualified by the disco#items namespace, not the muc namespace; this means that they cannot possess 'affiliation' or 'role' attributes, for example.

Example 10. Room Returns Empty Disco Item Results (Items are Private)

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

If a non-occupant attempts to send a disco request to an address of the form <<room@service/nick>>, a MUC service SHOULD return the request to the entity and specify a <bad-request/> error condition. If an occupant sends such a request, the service MAY pass it through the intended recipient; see the Implementation Guidelines section of this document for details.

6.2 Discovering Client Support for MUC

A Jabber user may want to discover if one of the user's contacts supports the Multi-User Chat protocol. This is done using Service Discovery.

Example 11. User Queries Contact Regarding MUC Support

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

The client SHOULD return its identity and the features it supports:

Example 12. Contact Returns Disco Info Results

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

A user may also query a contact regarding which rooms the contact is in. This is done by querying the contact's full JID (<user@host/resource>) while specifying the well-known Service Discovery node 'http://jabber.org/protocol/muc#rooms':

Example 13. User Queries Contact for Current Rooms

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

Example 14. Contact Returns Room Query Results

<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@macbeth.shakespeare.lit'/>
    <item jid='characters@conference.shakespeare.lit'/>
  </query>
</iq>
    

Optionally, the contact MAY include its roomnick as the value of the 'name' attribute:

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

6.3 Entering a Room

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

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

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

<presence
    from='darkcave@macbeth.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@macbeth.shakespeare.lit/secondwitch'
    to='hag66@shakespeare.lit/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin' role='moderator'/>
  </x>
</presence>
      

<presence
    from='darkcave@macbeth.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@macbeth.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@macbeth.shakespeare.lit/thirdwitch'
    to='hag66@shakespeare.lit/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
  </x>
</presence>
      

<presence
    from='darkcave@macbeth.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@macbeth.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>
      

<presence
    from='darkcave@macbeth.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <error code='401' type='auth'>
    <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
      

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

<presence
    from='darkcave@macbeth.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <error code='407' type='auth'>
    <registration-required xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
      

<presence
    from='darkcave@macbeth.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <error code='403' type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
      

<presence
    from='darkcave@macbeth.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <error code='409' type='cancel'>
    <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
      

<presence
    from='darkcave@macbeth.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <error code='503' type='wait'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
      

<message
    from='darkcave@macbeth.shakespeare.lit/firstwitch'
    to='hecate@shakespeare.lit/broom'
    type='groupchat'>
  <body>Thrice the brinded cat hath mew'd.</body>
  <x xmlns='jabber:x:delay'
     from='crone1@shakespeare.lit/desktop'
     stamp='20021013T23:58:37'/>
</message>

<message
    from='darkcave@macbeth.shakespeare.lit/secondwitch'
    to='hecate@shakespeare.lit/broom'
    type='groupchat'>
  <body>Thrice and once the hedge-pig whined.</body>
  <x xmlns='jabber:x:delay'
     from='wiccarocks@shakespeare.lit/laptop'
     stamp='20021013T23:58:43'/>
</message>

<message
    from='darkcave@macbeth.shakespeare.lit/thirdwitch'
    to='hecate@shakespeare.lit/broom'
    type='groupchat'>
  <body>Harpier cries 'Tis time, 'tis time.</body>
  <x xmlns='jabber:x:delay'
     from='hag66@shakespeare.lit/pda'
     stamp='20021013T23:58:49'/>
</message>
      

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

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

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

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

<presence
    from='darkcave@macbeth.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <error code='404' type='cancel'>
    <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
      

6.4 Exiting a Room

In order to exit a multi-user chat room, an occupant sends a presence stanza of type "unavailable" to the <room@service/nick> it is currently using in the room.

Example 34. Occupant Exits a Room

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

The service MUST then send presence stanzas of type "unavailable" from the departing occupant's room JID to the full JIDs of the departing occupant and of the remaining occupants:

Example 35. Service Sends Presence Related to Departure of Occupant

<presence
    from='darkcave@macbeth.shakespeare.lit/thirdwitch'
    to='hag66@shakespeare.lit/pda'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='none'/>
  </x>
</presence>
<presence
    from='darkcave@macbeth.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@macbeth.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 stanzas of type "unavailable" reflected by the room MUST contain extended presence information about roles and affiliations, and MAY also contain normal <show/> and <status/> information (this last enables occupants to provide custom exit messages if desired).

Example 36. Custom Exit Message

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

Normal presence stanza generation rules apply as defined in XMPP IM [8], so that if the user sends a general unavailable presence stanza, the user's server will broadcast that stanza to the <room@service/nick> to which the user's client has sent directed presence.

If the room is not persistent and this occupant is the last to exit, the service is responsible for destroying the room.

6.5 Changing Nickname

A common feature of multi-user chat rooms is the ability for an occupant to change his or her nickname within the room. In MUC this is done by sending updated presence information to the room, specifically by sending presence to a new room JID in the same room (changing only the resource identifier in the room JID).

Example 37. Occupant Changes Nickname

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

The service then sends two presence stanzas to the full JID of each occupant (including the occupant who is changing his or her room nickname), one of type "unavailable" for the old nickname and one indicating availability for the new nickname. The unavailable presence MUST contain the new nickname and an appropriate status code (namely 303) as extended presence information in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace so that Jabber clients are able to provide relevant hints to occupants regarding the nickname change if desired.

Example 38. Service Updates Nick

<presence
    from='darkcave@macbeth.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@macbeth.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@macbeth.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'/>
  </x>
</presence>

<presence
    from='darkcave@macbeth.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@macbeth.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@macbeth.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'/>
  </x>
</presence>
    

If the user attempts to change his or her room nickname to a room nickname that is already in use by another occupant (or that is reserved by someone affiliated with the room, e.g., a member or owner), the service MUST deny the nickname change request and inform the user of the conflict; this is done by returning a presence stanza of type "error" specifying a <conflict/> error condition:

Example 39. Service Denies Nickname Change Because of Nick Conflict

<presence
    from='darkcave@macbeth.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <error code='409' type='cancel'>
    <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
    

6.6 Changing Availability Status

In multi-user chat systems such as IRC, one common use for changing one's room nickname is to indicate a change in one's availability (e.g., changing one's room nickname to "thirdwitch|away"). In Jabber, availability is of course noted by a change in presence (specifically the <show/> and <status/> elements), which can provide important context within a chatroom. An occupant changes availability status within the room by sending the updated presence to its <room@service/nick>.

Example 40. Occupant Changes Availability Status

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

The service then sends a presence stanza from the occupant changing his or her presence to the full JID of each occupant, including extended presence information about the occupant's role and full JID to those with privileges to view such information:

Example 41. Service Passes Along Changed Presence to All Occupants

<presence
    from='darkcave@macbeth.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>
.
.
.
    

6.7 Inviting Another User to a Room

It can be useful to invite another user to a room in which one is an occupant. Several different mechanisms have been suggested in the past to do this. One existing protocol is for the inviting occupant to send a message directly to the invitee, containing extended content qualified by the 'jabber:x:conference' namespace. The server (not the chat service) adds a 'from' address to the invite message, which is delivered like any other message. This undocumented protocol, which is not part of "groupchat 1.0", is as follows:

Example 42. Occupant Sends an Invitation (Not Recommended)

<message
    from='crone1@shakespeare.lit/desktop'
    to='hecate@shakespeare.lit'>
  <body>You have been invited to darkcave@macbeth.</body>
    <x jid='room@service' xmlns='jabber:x:conference'/>
</message>
    

While the current protocol meets the needs of "groupchat 1.0" implementations, it could not work within the context of a members-only room, since the service needs to keep track of who is registered as a member. Because we would like to support members-only rooms, it seems desirable for an occupant to send the invitation to the <room@service> itself and have the room keep track of the invitations (if the room is members-only) or simply forward the invitation to the invitee.

Therefore the old undocumented protocol SHOULD NOT be used (it cannot be deprecated since it was never approved) and a MUC client MUST send XML of the following form to the <room@service> itself (the reason is OPTIONAL and the message MUST NOT possess a 'type' attribute; the service MAY ignore or reject invites that possess a 'type' attribute):

Example 43. Occupant Sends an Invitation by Way of Room (Multi-User Chat)

<message
    from='crone1@shakespeare.lit/desktop'
    to='darkcave@macbeth.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 (or, optionally, the room JID) of the invitor and send the invitation to the invitee captured in the 'to' address (the service SHOULD 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) and MAY include the old jabber:x:conference extension as well for backwards-compatibility:

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

<message
    from='darkcave@macbeth.shakespeare.lit'
    to='hecate@shakespeare.lit'>
  <body>You have been invited to darkcave@macbeth by crone1@shakespeare.lit.</body>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite from='crone1@shakespeare.lit'>
      <reason>
        Hey Hecate, this is the place for all good witches!
      </reason>
    </invite>
    <password>cauldron</password>
  </x>
  <x jid='darkcave@macbeth.shakespeare.lit' xmlns='jabber:x:conference'>
    Hey Hecate, this is the place for all good witches!
  </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 45. Invitee Declines Invitation

<message
    from='hecate@shakespeare.lit/broom'
    to='darkcave@macbeth.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 46. Room Informs Invitor that Invitation Was Declined

<message
    from='darkcave@macbeth.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.

6.8 Converting a One-to-One Chat Into a Conference

Sometimes it is desirable to convert a one-to-one chat into a multi-user conference. The process flow is shown in the following examples.

First, two users begin a one-to-one chat.

Example 47. A One-to-One Chat

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

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

Now the first person decides to include a third person in the discussion, so she (or, more precisely, her client) does the following:

1. Creates a new room (which SHOULD be non-anonymous and MAY be an instant room as specified below)
2. Optionally sends history of the one-to-one chat to the room
3. Sends an invitation to the second person and the third person, including a <continue/> flag.

Example 48. Continuing the Discussion I: User Creates Room

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

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

Example 49. Continuing the Discussion II: Owner Sends History to Room

<message
    from='crone1@shakespeare.lit/desktop'
    to='darkcave@macbeth.shakespeare.lit'
    type='groupchat'>
  <body>Thrice the brinded cat hath mew'd.</body>
  <x xmlns='jabber:x:delay'
     from='crone1@shakespeare.lit/desktop'
     stamp='20040929T01:54:37'/>
</message>

<message
    from='crone1@shakespeare.lit/desktop'
    to='darkcave@macbeth.shakespeare.lit'
    type='groupchat'>
  <body>Thrice and once the hedge-pig whined.</body>
  <x xmlns='jabber:x:delay'
     from='wiccarocks@shakespeare.lit/laptop'
     stamp='20040929T01:55:21'/>
</message>
    

Note: Use of the Delayed Delivery protocol enables the room creator to specify the datetime of each message from the one-to-one chat history (via the 'stamp' attribute), as well as the JID of the original sender of each message (via the 'from' attribute). The room creator SHOULD send the complete one-to-one chat history before inviting additional users to the room, and SHOULD also send as history any messages appearing in the one-to-one chat interface after joining the room and before the second person joins the room; if the one-to-one history is especially large, the sending client may want to send the history over a few seconds rather than all at once (to avoid triggering rate limits). The service SHOULD NOT add its own delay elements (as described in the Discussion History section of this document) to prior chat history messages received from the room owner.

Example 50. Continuing the Discussion III: Owner Sends Invitations, Including Continue Flag

<message
    from='crone1@shakespeare.lit/desktop'
    to='darkcave@macbeth.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/>
    </invite>
    <invite to='hag66@shakespeare.lit'>
      <reason>This coven needs both wiccarocks and hag66.</reason>
      <continue/>
    </invite>
  </x>
</message>
    

Note: Since the invitor's client knows the full JID of the person with whom the invitor was having a one-to-one chat, it SHOULD include the full JID (rather than the bare JID) in the invitation.

The invitations are delivered to the invitees:

Example 51. Invitations Delivered

<message
    from='darkcave@macbeth.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/>
    </invite>
  </x>
</message>

<message
    from='darkcave@macbeth.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/>
    </invite>
  </x>
</message>
    

When the client being used by <wiccarocks@shakespeare.lit/laptop> receives the invitation, it SHOULD auto-join the room or prompt the user whether to join (subject to user preferences) and then seamlessly convert the existing one-to-one chat window into a multi-user conferencing window:

Example 52. Invitee Accepts Invitation, Joins Room, and Receives Presence and History

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

<presence
    from='darkcave@macbeth.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@macbeth.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@macbeth.shakespeare.lit'
    to='wiccarocks@shakespeare.lit/laptop'
    type='groupchat'>
  <body>Thrice the brinded cat hath mew'd.</body>
  <x xmlns='jabber:x:delay'
     from='crone1@shakespeare.lit/desktop'
     stamp='20040929T01:54:37'/>
</message>

<message
    from='darkcave@macbeth.shakespeare.lit'
    to='wiccarocks@shakespeare.lit/laptop'
    type='groupchat'>
  <body>Thrice and once the hedge-pig whined.</body>
  <x xmlns='jabber:x:delay'
     from='wiccarocks@shakespeare.lit/laptop'
     stamp='20040929T01:55:21'/>
</message>
    

Note: The fact that the messages come from the <room@service> itself rather than <room@service/nick> is a clue to the receiving client that these messages are prior chat history, since any message from a room occupant will have a 'from' address equal to the sender's room JID.

6.9 Occupant Modification of the Room Subject

If allowed in accordance with room configuration, a mere occupant MAY be allowed to change the subject in a room. For details, see the Modifying the Room Subject section of this document.

6.10 Sending a Private Message

Since each occupant has a unique room JID, an occupant MAY send a "private message" to a selected occupant via the service by sending a message to the occupant's room JID. The message type SHOULD be "chat" and MUST NOT be "groupchat", but MAY be left unspecified (i.e., a normal message). This privilege SHOULD be allowed to any occupant (even a visitor in a moderated room).

Example 53. Occupant Sends Private Message

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

The service is responsible for changing the 'from' address to the sender's room JID and delivering the message to the intended recipient's full JID.

Example 54. Recipient Receives the Private Message

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

If the sender attempts to send a private message of type "groupchat" to a particular occupant, the service MUST refuse to deliver the message (since the recipient's client would expect in-room messages to be of type "groupchat") and return a <bad-request/> error to the sender:

Example 55. Occupant Attempts to Send a Message of Type "Groupchat" to a Particular Occupant

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

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

If the sender attempts to send a private message to a room JID that does not exist, the service MUST return an <item-not-found/> error to the sender.

If the sender is not an occupant of the room in which the intended recipient is visiting, the service MUST return a <not-acceptable/> error to the sender.

6.11 Sending a Message to All Occupants

An occupant sends a message to all other occupants in the room by sending a message of type "groupchat" to the <room@service> itself (a service MAY ignore or reject messages that do not have a type of "groupchat"). In a moderated room, this privilege is restricted to occupants with a role of participant or higher.

Example 56. Occupant Sends a Message to All Occupants

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

If the sender has voice in the room (this is the default except in moderated rooms), the service MUST change the 'from' attribute to the sender's room JID and reflect the message out to the full JID of each occupant.

Example 57. Service Reflects Message to All Occupants

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

If the sender is a visitor (i.e., does not have voice in a moderated room), the service MAY return a <forbidden/> error to the sender and MUST NOT reflect the message to all occupants. If the sender is not an occupant of the room, the service SHOULD return a <not-acceptable/> error to the sender and SHOULD NOT reflect the message to all occupants; the only exception to this rule is that an implementation MAY allow users with certain privileges (e.g., a room owner, room admin, or service-level admin) to send messages to the room even if those users are not occupants.

6.12 Registering with a Room

An implementation MAY allow an unaffiliated user (in a moderated room, probably a participant) to register with a room and thus become a member of the room (conversely, an implementation MAY restrict this privilege and allow only room admins to add new members). If allowed, this functionality SHOULD be implemented by enabling a user to send a request for registration requirements to the room qualified by the 'jabber:iq:register' namespace as described in In-Band Registration [9]:

Example 58. User Requests Registration Requirements

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

If the user requesting registration requirements is not allowed to register with the room (e.g., because that privilege has been restricted), the room MUST return a <not-allowed/> error to the user. If the user is already registered, the room MUST reply with an IQ stanza of type "result" that contains an empty <register/> element as described in JEP-0077. If the room does not exist, the service MUST return an <item-not-found/> error.

Otherwise, the room MUST then return a Data Form to the user (as described in Data Forms [10]). The information required to register MAY vary by implementation or deployment and is not fully specified in this JEP (e.g., the fields registered by this JEP for the 'http://jabber.org/protocol/muc#register' FORM_TYPE may be supplemented in the future via the mechanisms described in the Field Standardization section of this document). The following can be taken as a fairly typical example:

Example 59. Service Returns Registration Form

<iq from='darkcave@macbeth.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='First Name'
          type='text-single'
          var='muc#register_first'>
        <required/>
      </field>
      <field
          label='Last 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>
    

The user SHOULD then submit the form:

Example 60. User Submits Registration Form

<iq from='hag66@shakespeare.lit/pda'
    id='reg2'
    to='darkcave@macbeth.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>
    

If the desired room nickname is already reserved for that room, the room MUST return a <conflict/> error to the user:

Example 61. Room Returns Conflict Error to User

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

If the room or service does not support registration, it MUST return a <service-unavailable/> error to the user:

Example 62. Room Returns Service Unavailable Error to User

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

If the user did not include a valid data form, the room MUST return a <bad-request/> error to the user:

Example 63. Room Returns Service Bad Request Error to User

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

Otherwise, the room MUST inform the user of successful registration:

Example 64. Room Informs User of Successful Registration

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

After the user successfully submits the form, the service MAY request that the submission be approved by a room admin/owner (see the Approving Registration Requests section of this document) or MAY immediately add the user to the member list by changing the user's affiliation from "none" to "member". If the service changes the user's affiliation and the user is in the room, it MUST send updated presence from this individual to all occupants, indicating the change in affiliation by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member".

Example 65. Service Sends Notice of Membership to All Occupants

<presence
    from='darkcave@macbeth.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>
.
.
.
    

If a user has registered with a room, the room MAY choose to restrict the user to use of the registered nickname only in that room. If it does so, it SHOULD return a <not-acceptable/> error to the user if the user attempts to join the room with a roomnick other than the user's registered roomnick (this enables a room to "lock down" roomnicks for consistent identification of occupants).

6.13 Discovering Reserved Room Nickname

A user MAY have a reserved room nickname, for example through explicit room registration or database integration. In such cases it may be desirable for the user to discover his or her reserved nickname before attempting to enter the room (e.g., because the user has forgotten his or her reserved nickname). This is done by sending a Service Discovery information request to the room JID while specifying a well-known Service Discovery node of "x-roomuser-item".

Example 66. User Requests Reserved Nickname

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

It is OPTIONAL for a multi-user chat service to support the foregoing service discovery node. If the room or service does not support the foregoing service discovery node, it MUST return a <feature-not-implemented/> error to the user. If it does and the user has a registered nickname, it MUST return the nickname to the user as the value of the 'name' attribute of a Service Discovery <identity/> element (for which the category/type SHOULD be "conference/text"):

Example 67. Room Returns Nickname

<iq from='darkcave@macbeth.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>
    

If the user does not have a registered nickname, the room MUST return a service discovery <query/> element that is empty (in accordance with JEP-0030).

Even if a user has registered one room nickname, the service SHOULD allow the user to specify a different nickname on entering the room (e.g., in order to join from different client resources), although the service MAY choose to "lock down" nicknames and therefore deny entry to the user, including a <not-acceptable/> error. The service MUST NOT return an error to the user if his or her client sends the foregoing request after having already joined the room, but instead SHOULD reply as described above.

If another user attempts to join the room with a nickname reserved by the first user, the service MUST deny entry to the second user and return a <conflict/> error as previously described.

7.1 Modifying the Room Subject

A common feature of multi-user chat rooms is the ability to change the subject within the room. By default, only users with a role of "moderator" SHOULD be allowed to change the subject in a room (although this SHOULD be configurable, with the result that a mere participant or even visitor may be allowed to change the subject if desired). The subject is changed by sending a message of type "groupchat" to the <room@service>, containing no body but a <subject/> that specifies the new subject:

Example 68. Moderator Changes Subject

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

If a MUC service receives such a message, it MUST reflect the message to all other occupants with a 'from' address equal to the room JID that corresponds to the sender of the subject change:

Example 69. Service Informs All Occupants of Subject Change

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

In addition, the room SHOULD include the last subject change in the discussion history sent when a new occupant joins the room.

A MUC client that receives such a message MAY choose to display an in-room message; the body of such in-room messages SHOULD NOT be generated by the sending client or the service, so as to ensure correct localization (however, the sending client or service MAY generate the body if desired). The in-room message could be something like the following:

Example 70. Service Sends In-Room Subject Change Message

<message
    from='darkcave@macbeth.shakespeare.lit'
    to='crone1@shakespeare.lit/desktop'
    type='groupchat'>
  <subject>Fire Burn and Cauldron Bubble!</subject>
  <body>* secondwitch has changed the subject to: Fire Burn and Cauldron Bubble!</body>
</message>
.
.
.
    

If someone without appropriate privileges attempts to change the room subject, the service MUST return a message of type "error" specifying a <forbidden/> error condition:

Example 71. Service Returns Error Related to Unauthorized Subject Change

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

7.2 Kicking a Visitor or Participant from a Room

A moderator has permissions kick a visitor or participant from a room. The kick is normally performed based on the occupant's room nickname (though it MAY be based on the full JID) and is completed by setting the role of a participant or visitor to a value of "none".

Example 72. Moderator Kicks Occupant

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

The service MUST remove the kicked occupant by sending a presence stanza of type "unavailable" to each kicked occupant, including status code 307 in the extended presence information, optionally along with the reason (if provided) and the bare JID of the user who initiated the kick.

Example 73. Service Removes Kicked Occupant

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

The inclusion of the status code assists clients in presenting their own notification messages (e.g., information appropriate to the user's locality). The optional inclusion of the reason and actor enable the kicked user to understand why he or she was kicked, and by whom if the kicked occupant would like to discuss the matter. [11]

After removing the kicked occupant(s), the service MUST then inform the moderator of success:

Example 74. Service Informs Moderator of Success

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

After informing the moderator, the service MUST then inform all of the remaining occupants that the kicked occupant is no longer in the room by sending presence stanzas of type "unavailable" from the individual's roomnick (<room@service/nick>) to all the remaining occupants (just as it does when occupants exit the room of their own volition), including the status code and optionally the reason and actor.

Example 75. Service Informs Remaining Occupants

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

A moderator cannot be kicked from a room, nor can any user with an affiliation of "owner" or "admin". If a moderator attempts to kick such a user, the service MUST deny the request and return a <not-allowed/> error to the sender:

Example 76. Service Returns Error on Attempt to Kick Moderator, Admin, or Owner

<iq from='darkcave@macbeth.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 code='405' type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

7.3 Granting Voice to a Visitor

In a moderated room, a moderator may want to manage who does and does not have "voice" in the room (i.e., the ability to send messages to all occupants). Voice is granted based on the visitor's room nickname, which the service will convert into the visitor's full JID internally. The moderator grants voice to a visitor by changing the visitor's role to "participant" (the <reason/> element is optional):

Example 77. Moderator Grants Voice to a Visitor

<iq from='crone1@shakespeare.lit/desktop'
    id='voice1'
    to='darkcave@macbeth.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>
    

The service MUST then inform the moderator of success:

Example 78. Service Informs Moderator of Success

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

The service MUST then send updated presence from this individual's <room@service/nick> to all occupants, indicating the addition of voice privileges by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "participant".

Example 79. Service Sends Notice of Voice to All Occupants

<presence
    from='darkcave@macbeth.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>
.
.
.
    

7.4 Revoking Voice from a Participant

In a moderated room, a moderator may want to revoke a participant's privileges to speak. The moderator can revoke voice from a participant by changing the participant's role to "visitor":

Example 80. Moderator Revokes Voice from a Participant

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

The service MUST then inform the moderator of success:

Example 81. Service Informs Moderator of Success

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

The service MUST then send updated presence from this individual to all occupants, indicating the removal of voice privileges by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "visitor".

Example 82. Service Notes Loss of Voice

<presence
    from='darkcave@macbeth.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>
.
.
.
    

A moderator MUST NOT be able to revoke voice from a user whose affiliation is at or above the moderator's level. In addition, a service MUST NOT allow the voice privileges of an admin or owner to be removed by anyone. If a moderator attempts to revoke voice privileges from such a user, the service MUST deny the request and return a <not-allowed/> error to the sender along with the offending item(s):

Example 83. Service Returns Error on Attempt to Revoke Voice from an Admin, Owner, or User with a Higher Affiliation

<iq from='darkcave@macbeth.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 code='405' type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

7.5 Modifying the Voice List

A moderator in a moderated room may want to modify the voice list. To do so, the moderator first requests the voice list by querying the room for all occupants with a role of 'participant'.

Example 84. Moderator Requests Voice List

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

The service MUST then return the voice list to the moderator; each item MUST include the 'nick' and 'role' attributes and SHOULD include the 'affiliation' and 'jid' attributes:

Example 85. Service Sends Voice List to Moderator

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

The moderator MAY then modify the voice list. In order to do so, the moderator MUST send the changed items (i.e., only the "delta") back to the service; each item MUST include the 'nick' attribute and 'role' attribute (normally set to a value of "participant" or "visitor") but SHOULD NOT include the 'jid' attribute and MUST NOT include the 'affiliation' attribute (which is used to manage affiliations such as owner rather than the participant role):

Example 86. Moderator Sends Modified Voice List to Service

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

The service MUST then inform the moderator of success:

Example 87. Service Informs Moderator of Success

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

The service MUST then send updated presence for any affected individuals to all occupants, indicating the change in voice privileges by sending the appropriate extended presence stanzas as described in the foregoing use cases.

As noted, voice privileges cannot be revoked from a room owner or room admin, nor from any user with a higher affiliation than the moderator making the request. If a room admin attempts to revoke voice privileges from such a user by modifying the voice list, the service MUST deny the request and return a <not-allowed/> error to the sender:

Example 88. Service Returns Error on Attempt to Revoke Voice from an Admin, Owner, or User with a Higher Affiliation

<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 code='405' type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

8.1 Banning a User

An admin or owner can ban one or more users from a room. The ban MUST be performed based on the occupant's bare JID. In order to ban a user, an admin MUST change the user's affiliation to "outcast".

Example 89. Admin Bans User

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

The service MUST add that bare JID to the ban list, SHOULD remove the outcast's nickname from the list of registered nicknames, and MUST inform the admin or owner of success:

Example 90. Service Informs Admin or Owner of Success

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

The service MUST also remove any banned users who are in the room by sending a presence stanza of type "unavailable" to each banned occupant, including status code 301 in the extended presence information, optionally along with the reason (if provided) and the bare JID of the user who initiated the ban.

Example 91. Service Removes Banned User

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

The inclusion of the status code assists clients in presenting their own notification messages (e.g., information appropriate to the user's locality). The optional inclusion of the reason and actor enable the banned user to understand why he or she was banned, and by whom if the banned user would like to discuss the matter.

The service MUST then inform all of the remaining occupants that the banned user is no longer in the room by sending presence stanzas of type "unavailable" from the banned user to all remaining occupants (just as it does when occupants exit the room of their own volition), including the status code and optionally the reason and actor:

Example 92. Service Informs Remaining Occupants

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

8.2 Modifying the Ban List

A room admin may want to modify the ban list. Note: The ban list is always based on a user's bare JID, although a nick (perhaps the last room nickname associated with that JID) MAY be included for convenience. To modify the list of banned JIDs, the admin first requests the ban list by querying the room for all users with an affiliation of 'outcast'.

Example 93. Admin Requests Ban List

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

The service MUST then return the list of banned users to the admin; each item MUST include the 'affiliation' and 'jid' attributes but SHOULD NOT include the 'nick' and 'role' attributes:

Example 94. Service Sends Ban List to Admin

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

The admin MAY then modify the ban list. In order to do so, the admin MUST send the changed items (i.e., only the "delta") back to the service; each item MUST include the 'affiliation' attribute (normally set to a value of "outcast" to ban or "none" to remove ban) and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than the outcast affiliation); in addition, the reason and actor elements are OPTIONAL:

Example 95. Admin Sends Modified Ban List to Service

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

After updating the ban list, the service MUST inform the admin of success:

Example 96. Service Informs Admin of Success

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

The service MUST then remove the affected occupants (if they are in the room) and send updated presence (including the appropriate status code) from them to all the remaining occupants as described in the "Banning a User" use case. (The service SHOULD also remove each banned user's reserved nickname from the list of reserved roomnicks, if appropriate.)

When an entity is banned from a room, an implementation SHOULD match JIDs in the following order (these matching rules are the same as those defined for privacy lists in RFC 3921):

1. <user@domain/resource> (only that resource matches)
2. <user@domain> (any resource matches)
3. <domain/resource> (only that resource matches)
4. <domain> (the domain itself matches, as does any user@domain, domain/resource, or address containing a subdomain)

Some administrators may wish to ban all users associated with a specific domain from all rooms hosted by a MUC service. Such functionality is a service-level feature and is therefore out of scope for this document (but see Service Administration [12]).

8.3 Granting Membership

An admin can grant membership to a user; this is done by changing the user's affiliation to "member" (normally based on nick if the user is in the room, or on bare JID if not; in either case, if the nick is provided, that nick becomes the user's default nick in the room if that functionality is supported by the implementation):

Example 97. Admin Grants Membership

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

The service MUST add the user to the member list and then inform the admin of success:

Example 98. Service Informs Admin of Success

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

If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the granting of membership by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member".

Example 99. Service Sends Notice of Membership to All Occupants

<presence
    from='darkcave@macbeth.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>
.
.
.
    

8.4 Revoking Membership

An admin may want to revoke a user's membership; this is done by changing the user's affiliation to "none":

Example 100. Admin Revokes Membership

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

The service MUST remove the user from the member list and then inform the moderator of success:

Example 101. Service Informs Moderator of Success

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

The service MUST then send updated presence from this individual to all occupants, indicating the loss of membership by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "none".

Example 102. Service Notes Loss of Membership

<presence
    from='darkcave@macbeth.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 room is members-only, the service MUST remove the user from the room, including a status code of 321 to indicate that the user was removed because of an affiliation change, and inform all remaining occupants:

Example 103. Service Removes Non-Member

<presence
    from='darkcave@macbeth.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@macbeth.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>
.
.
.
    

8.5 Modifying the Member List

In the context of a members-only room, the member list is essentially a "whitelist" of people who are allowed to enter the room. Anyone who is not a member is effectively banned from entering the room, even if their affiliation is not "outcast".

In the context of an open room, the member list is simply a list of users (bare JID and reserved nick) who are registered with the room. Such users may appear in a room roster, have their room nickname reserved, be returned in search results or FAQ queries, and the like.

It is RECOMMENDED that only room admins have the privilege to modify the member list in members-only rooms. To do so, the admin first requests the member list by querying the room for all users with an affiliation of "member":

Example 104. Admin Requests Member List

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

(A service SHOULD also return the member list to any occupant in a members-only room; i.e., it SHOULD NOT generate a <forbidden/> error when a member in the room requests the member list. This functionality may assist clients in showing all the existing members even if some of them are not in the room, e.g. to help a member determine if another user should be invited.)

The service MUST then return the full member list to the admin qualified by the 'http://jabber.org/protocol/muc#admin' namespace; each item MUST include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and 'role' attributes for each members that is currently an occupant.

Example 105. Service Sends Member List to Admin

<iq from='darkcave@macbeth.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>
    

The admin MAY then modify the member list. In order to do so, the admin MUST send the changed items (i.e., only the "delta") to the service; each item MUST include the 'affiliation' attribute (normally set to a value of "member" or "none") and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than the member affiliation):

Example 106. Admin Sends Modified Member List to Service

<iq from='crone1@shakespeare.lit/desktop'
    id='member4'
    to='darkcave@macbeth.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>
    

The service MUST modify the member list and then inform the moderator of success:

Example 107. Service Informs Moderator of Success

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

The service MUST change the affiliation of any affected user. If the user has been removed from the member list, the service MUST change the user's affiliation from "member" to "none". If the user has been added to the member list, the service MUST change the user's affiliation to "member".

If a removed member is currently in a members-only room, the service SHOULD kick the occupant by changing the removed member's role to "none" and send appropriate presence to the removed member as previously described. No matter whether the removed member was in or out of a members-only room, the service MUST subsequently refuse entry to the user.

For all room types, the service MUST send updated presence from this individual to all occupants, indicating the change in affiliation by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "none".

Example 108. Service Sends Notice of Loss of Membership to All Occupants

<presence
    from='darkcave@macbeth.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>
.
.
.
    

In addition, the service SHOULD send an invitation to any user who has been added to the member list of a members-only room if the user is not currently affiliated with the room, for example as an admin or owner (such a user would by definition not be in the room; note also that this example includes a password but not a reason -- both child elements are OPTIONAL):

Example 109. Room Sends Invitation to New Member

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

While only admins and owners SHOULD be allowed to modify the member list, an implementation MAY provide a configuration option that opens invitation privileges to any member of a members-only room. In such a situation, any invitation sent SHOULD automatically trigger the addition of the invitee to the member list. However, if invitation privileges are restricted to admins and a mere member attempts to a send an invitation, the service MUST deny the invitation request and return a <forbidden/> error to the sender:

Example 110. Service Returns Error on Attempt by Mere Member to Invite Others to a Members-Only Room

<message
    from='darkcave@macbeth.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 code='403' type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</message>
    

Invitations sent through an open room MUST NOT trigger the addition of the invitee to the member list.

If a user is added to the member list of an open room and the user is in the room, the service MUST send updated presence from this individual to all occupants, indicating the change in affiliation by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member".

Example 111. Service Sends Notice of Membership to All Occupants

<presence
    from='darkcave@macbeth.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>
.
.
.
    

8.6 Granting Moderator Privileges

An admin may want to grant moderator privileges to a participant or visitor; this is done by changing the user's role to "moderator":

Example 112. Admin Grants Moderator Privileges

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

The service MUST add the user to the moderator list and then inform the admin of success:

Example 113. Service Informs Admin of Success

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

The service MUST then send updated presence from this individual to all occupants, indicating the addition of moderator privileges by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "moderator".

Example 114. Service Sends Notice of Moderator Privileges to All Occupants

<presence
    from='darkcave@macbeth.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>
.
.
.
    

8.7 Revoking Moderator Privileges

An admin may want to revoke a user's moderator privileges. An admin MAY revoke moderator privileges only from a user whose affiliation is "member" or "none" (i.e., not from an owner or admin). The privilege is revoked by changing the user's role to "participant":

Example 115. Admin Revokes Moderator Privileges

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

The service MUST remove the user from the moderator list and then inform the admin of success:

Example 116. Service Informs Admin of Success

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

The service MUST then send updated presence from this individual to all occupants, indicating the removal of moderator privileges by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "participant".

Example 117. Service Notes Loss of Moderator Privileges

<presence
    from='darkcave@macbeth.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>
.
.
.
    

As noted, an admin MUST NOT be allowed to revoke moderator privileges from a user whose affiliation is "owner" or "admin". If an admin attempts to revoke moderator privileges from such a user, the service MUST deny the request and return a <not-allowed/> error to the sender:

Example 118. Service Returns Error on Attempt to Revoke Moderator Privileges from an Admin or Owner

<iq from='darkcave@macbeth.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 code='405' type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

8.8 Modifying the Moderator List

An admin may want to modify the moderator list. To do so, the admin first requests the moderator list by querying the room for all users with a role of 'moderator'.

Example 119. Admin Requests Moderator List

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

The service MUST then return the moderator list to the admin; each item MUST include the 'jid', 'nick', and 'role' attributes and SHOULD include the 'affiliation' attribute:

Example 120. Service Sends Moderator List to Admin

<iq from='darkcave@macbeth.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>
    

The admin MAY then modify the moderator list. In order to do so, the admin MUST send the changed items (i.e., only the "delta") back to the service; each item MUST include the 'jid' attribute and 'role' attribute (normally set to a value of "member" or "participant") but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'affiliation' attribute (which is used to manage affiliations such as admin rather than the moderator role):

Example 121. Admin Sends Modified Moderator List to Service

<iq from='crone1@shakespeare.lit/desktop'
    id='mod4'
    to='darkcave@macbeth.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>
    

The service MUST modify the moderator list and then inform the admin of success:

Example 122. Service Informs Admin of Success

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

The service MUST then send updated presence for any affected individuals to all occupants, indicating the change in moderator privileges by sending the appropriate extended presence stanzas as described in the foregoing use cases.

As noted, moderator privileges cannot be revoked from a room owner or room admin. If a room admin attempts to revoke moderator privileges from such a user by modifying the moderator list, the service MUST deny the request and return a <not-allowed/> error to the sender:

Example 123. Service Returns Error on Attempt to Revoke Moderator Privileges from an Admin or Owner

<iq from='darkcave@macbeth.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 code='405' type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

8.9 Approving Registration Requests

If a service does not automatically accept requests to register with a room, it MAY provide a way for room admins to approve or deny registration requests over Jabber (alternatively, it could provide a web interface or some other admin tool). The simplest way to do so is for the service to send a <message/> stanza to the room admin(s) when the registration request is received, where the <message/> stanza contains a Data Form asking for approval or denial of the request. The following Data Form is RECOMMENDED but implementations MAY use a different form entirely, or supplement the following form with additional fields.

Example 124. Registration Request Approval Form

<message from='darkcave@macbeth.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='First Name'>
      <value>Brunhilde</value>
    </field>
    <field var='muc#register_last'
           type="text-single"
           label="Last 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>
    

If the admin approves the registration request, the service shall register the user with the room.

More advanced registration approval mechanisms (e.g., retrieving a list of registration requests using Ad-Hoc Commands [13] as is done in Publish-Subscribe [14]) are out of scope for this JEP.

9.1 Creating a Room

<presence
    from='darkcave@macbeth.shakespeare.lit/thirdwitch'
    to='hag66@shakespeare.lit/pda'
    type='error'>
  <error code='405' type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>
      

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

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

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

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

<iq from='darkcave@macbeth.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 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='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>
      

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

<iq from='crone1@shakespeare.lit/desktop'
    id='create2'
    to='darkcave@macbeth.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>cauldron</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>
      

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

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

9.2 Subsequent Room Configuration

At any time after specifying the initial configuration of the room, a room owner may want to change the configuration. In order to initiate this process, a room owner MUST request a new configuration form from the room by sending an IQ to <room@service> containing an empty <query/> element qualified by the 'http://jabber.org/protocol/muc#owner' namespace.

Example 135. Owner Requests Configuration Form

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

If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a <forbidden/> error to the sender:

Example 136. Service Denies Configuration Access to Non-Owner

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

Otherwise, the service MUST send a configuration form to the room owner with the current options set as defaults:

Example 137. Service Sends Configuration Form to Owner

<iq from='darkcave@macbeth.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 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='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>cauldron</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>
    

If there are no configuration options available, the service MUST return an empty query element to the room owner as shown in the previous use case.

The room owner SHOULD then submit the form with updated configuration information.

Alternatively, the room owner MAY cancel the configuration process:

Example 138. Owner Cancels Subsequent Configuration

<iq from='crone1@shakespeare.lit/desktop'
    id='config2'
    to='darkcave@macbeth.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 subsequent configuration, the service MUST leave the configuration of the room as it was before the room owner initiated the subsequent configuration process.

If as a result of a change in the room configuration a room admin loses administrative privileges while the admin is in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member" and the 'role' attribute set to a value of "participant" or "visitor" as appropriate for the affiliation level and the room type:

Example 139. Service Notes Loss of Admin Affiliation

<presence
    from='darkcave@macbeth.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>
.
.
.
    

If as a result of a change in the room configuration a user gains administrative privileges while the user is in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to a value of "admin":

Example 140. Service Notes Gain of Admin Affiliation to All Users

<presence
    from='darkcave@macbeth.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>
.
.
.
    

If as a result of a change in the room configuration a room owner loses owner privileges while that owner is in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to a value of "moderator":

Example 141. Service Notes Loss of Owner Affiliation

<presence
    from='darkcave@macbeth.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>
.
.
.
    

A service MUST NOT allow an owner to revoke his or her own ownership privileges if there are no other owners; if an owner attempts to do this, the service MUST return a <conflict/> error to the owner. However, a service SHOULD allow an owner to revoke his or her own ownership privileges if there are other owners.

If as a result of a change in the room configuration a user gains ownership privileges while the user is in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "owner" and the 'role' attribute set to a value of 'moderator'.

Example 142. Service Notes Gain of Owner Affiliation to All Users

<presence
    from='darkcave@macbeth.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>
.
.
.
    

If as a result of a change in the room configuration the room type is changed to members-only but there are non-members in the room, the service MUST remove any non-members from the room and include a status code of 322 in the presence unavailable stanzas sent to those users as well as any remaining occupants.

9.3 Granting Ownership Privileges

If allowed by an implementation, an owner MAY grant ownership privileges to another user; this is done by changing the user's affiliation to "owner":

Example 143. Owner Grants Ownership Privileges

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

The service MUST add the user to the owner list and then inform the owner of success:

Example 144. Service Informs Owner of Success

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

If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the granting of ownership privileges by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "owner" and the 'role' attribute set to a value of "moderator".

Example 145. Service Sends Notice of Ownership Privileges to All Occupants

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

9.4 Revoking Ownership Privileges

An implementation MAY allow an owner to revoke another user's ownership privileges; this is done by changing the user's affiliation to something other than "owner":

Example 146. Owner Revokes Ownership Privileges

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

A service MUST NOT allow an owner to revoke his or her own ownership privileges if there are no other owners; if an owner attempts to do this, the service MUST return a <conflict/> error to the owner. However, a service SHOULD allow an owner to revoke his or her own ownership privileges if there are other owners.

If an implementation does not allow one owner to revoke another user's ownership privileges, the implementation MUST return a <not-authorized/> error to the owner who made the request.

In all other cases, the service MUST remove the user from the owner list and then inform the owner of success:

Example 147. Service Informs Owner of Success

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

If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the loss of ownership privileges by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value other than "owner" and the 'role' attribute set to an appropriate value:

Example 148. Service Notes Loss of Owner Affiliation

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

Note: Allowing an owner to remove another user's ownership privileges can compromise the control model for room management; therefore this feature is OPTIONAL, and implementations are encouraged to support owner removal through an interface that is open only to individuals with service-wide administrative privileges.

9.5 Modifying the Owner List

If allowed by an implementation, a room owner may want to modify the owner list. To do so, the owner first requests the owner list by querying the room for all users with an affiliation of 'owner'.

Example 149. Owner Requests Owner List

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

If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a <forbidden/> error to the sender.

Otherwise, the service MUST then return the owner list to the owner; each item MUST include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and 'role' attributes for any owner that is currently an occupant:

Example 150. Service Sends Owner List to Owner

<iq from='darkcave@macbeth.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>
    

The owner MAY then modify the owner list. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; [15] each item MUST include the 'affiliation' and 'jid' attributes but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than the owner affiliation):

Example 151. Owner Sends Modified Owner List to Service

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

Only owners shall be allowed to modify the owner list. If a non-owner attempts to view or modify the owner list, the service MUST deny the request and return a <forbidden/> error to the sender:

Example 152. Service Returns Error on Attempt by Non-Owner to Modify Owner List

<iq from='darkcave@macbeth.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 code='403' type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

A service MUST NOT allow an owner to revoke his or her own ownership privileges if there are no other owners; if an owner attempts to do this, the service MUST return a <conflict/> error to the owner. However, a service SHOULD allow an owner to revoke his or her own ownership privileges if there are other owners.

In all other cases, the service MUST modify owner list and then inform the owner of success:

Example 153. Service Informs Owner of Success

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

The service MUST also send presence notifications related to any affiliation changes that result from modifying the owner list as previously described.

9.6 Granting Administrative Privileges

An owner can grant administrative privileges to a member or unaffiliated user; this is done by changing the user's affiliation to "admin":

Example 154. Owner Grants Admin Privileges

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

The service MUST add the user to the admin list and then inform the owner of success:

Example 155. Service Informs Owner of Success

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

If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the granting of administrative privileges by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to a value of "moderator".

Example 156. Service Sends Notice of Administrative Privileges to All Occupants

<presence
    from='darkcave@macbeth.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>
.
.
.
    

9.7 Revoking Administrative Privileges

An owner may want to revoke a user's administrative privileges; this is done by changing the user's affiliation to something other than "admin" or "owner":

Example 157. Owner Revokes Administrative Privileges

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

The service MUST remove the user from the admin list and then inform the owner of success:

Example 158. Service Informs Owner of Success

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

The service MUST then send updated presence from this individual to all occupants, indicating the loss of administrative privileges by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value other than "admin" or "owner" and the 'role' attribute set to an appropriate value given the affiliation level and the room type:

Example 159. Service Notes Loss of Admin Affiliation

<presence
    from='darkcave@macbeth.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>
.
.
.
    

9.8 Modifying the Admin List

A room owner may want to modify the admin list. To do so, the owner first requests the admin list by querying the room for all users with an affiliation of 'admin'.

Example 160. Owner Requests Admin List

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

If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a <forbidden/> error to the sender.

Otherwise, the service MUST then return the admin list to the owner; each item MUST include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and 'role' attributes for any admin that is currently an occupant:

Example 161. Service Sends Admin List to Owner

<iq from='darkcave@macbeth.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>
    

The owner MAY then modify the admin list. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; [16] each item MUST include the 'affiliation' attribute (normally set to a value of "admin" or "none") and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than the admin affiliation):

Example 162. Owner Sends Modified Admin List to Service

<iq from='bard@shakespeare.lit/globe'
    id='admin4'
    to='darkcave@macbeth.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>
    

Only owners shall be allowed to modify the admin list. If a non-owner attempts to view or modify the admin list, the service MUST deny the request and return a <forbidden/> error to the sender:

Example 163. Service Returns Error on Attempt by Non-Owner to Modify Admin List

<iq from='darkcave@macbeth.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 code='403' type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

Otherwise, the service MUST modify the admin list and then inform the owner of success:

Example 164. Service Informs Owner of Success

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

The service MUST also send presence notifications related to any affiliation changes that result from modifying the admin list as previously described.

9.9 Destroying a Room

A room owner MUST be able to destroy a room, especially if the room is persistent. The workflow is as follows:

1. The room owner requests that the room be destroyed, specifying a reason and an alternate venue if desired.

2. The room removes all users from the room (including appropriate information about the alternate location and the reason for being removed) and destroys the room, even if it was defined as persistent.

Other than the foregoing, this JEP does not specify what (if anything) a MUC service implementation shall do as a result of a room destruction request. For example, if the room was defined as persistent, an implementation MAY choose to lock the room ID so that it cannot be re-used, redirect enter requests to the alternate venue, or invite the current participants to the new room; however, such behavior is OPTIONAL.

In order to destroy a room, the room owner MUST send an IQ set to the address of the room to be destroyed. The <iq/> stanza shall contain a <query/> element qualified by the 'http://jabber.org/protocol/muc#owner' namespace, which in turn shall contain a <destroy/> element. The address of the alternate venue MAY be provided as the value of the <destroy/> element's 'jid' attribute. A password for the alternate venue MAY be provided as the XML character data of a <password/> child element of the <destroy/> element. The reason for the room destruction MAY be provided as the XML character data of a <reason/> child element of the <destroy/> element.

The following examples illustrate the protocol elements to be sent and received:

Example 165. Owner Submits Room Destruction Request

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

The service is responsible for removing all the occupants. It SHOULD NOT broadcast presence stanzas of type "unavailable" from all occupants, instead sending only one presence stanza of type "unavailable" to each occupant so that the user knows he or she has been removed from the room. If extended presence information specifying the JID of an alternate location and the reason for the room destruction was provided by the room owner, the presence stanza MUST include that information.

Example 166. Service Removes Each Occupant

<presence
    from='heath@macbeth.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@macbeth.shakespeare.lit'>
      <reason>Macbeth doth come.</reason>
    </destroy>
  </x>
</presence>

<presence
    from='heath@macbeth.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@macbeth.shakespeare.lit'>
      <reason>Macbeth doth come.</reason>
    </destroy>
  </x>
</presence>

<presence
    from='heath@macbeth.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@macbeth.shakespeare.lit'>
      <reason>Macbeth doth come.</reason>
    </destroy>
  </x>
</presence>
    

Example 167. Service Informs Owner of Successful Destruction

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

If the <user@host> of the 'from' address received on a destroy request does not match the bare JID of a room owner, the service MUST return a <forbidden/> error to the sender:

Example 168. Service Denies Destroy Request Submitted by Non-Owner

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

10.1 Error Codes

The error codes associated with the 'http://jabber.org/protocol/muc#user' namespace are fairly straightforward, as summarized in the following table. For detailed information about mapping legacy error codes to XMPP-style error types and conditions, refer to Error Condition Mappings [17]; implementations SHOULD support both legacy and XMPP error handling.

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

This JEP does not stipulate text strings (i.e., values of the XMPP <text/> element) associated with the foregoing error conditions.

10.2 Status Codes

Multi-User Chat uses a <status/> element (specifically, the 'code' attribute of the <status/> element) to communicate information about a user's status in a room. Over time, the number of status codes has grown quite large, and new status codes continue to be requested of the JEP author. Therefore, these codes are now documented in a registry maintained by the Jabber Registrar. For details, refer to the Status Codes Registry section of this document.

Note: In general, MUC status codes tend to follow the "philosophy" of status codes that is implicit in RFC 2616 [18] and RFC 1893 [19] (1xx codes are informational, 2xx codes specify that it is fine to continue, 3xx codes specify redirects such as being kicked or banned, x3x codes refer to system status, x7x codes refer to security or policy matters, etc.).

Note: If the MUC protocol were being designed today, it would specify a more flexible, XML-friendly approach rather than hardcoded status numbers; however, at this point the pain of changing the status reporting system would be greater than the benefit of doing so, which is why the status code numbers remain in use. A future version of this JEP may define a more XMPP-like approach to status conditions, retaining the code numbers but supplementing them with more descriptive child elements as is done in RFC 3920.

14.1 Protocol Namespaces

The Jabber Registrar includes the following MUC-related namespaces in its registry of protocol namespaces:

• http://jabber.org/protocol/muc
• http://jabber.org/protocol/muc#admin
• http://jabber.org/protocol/muc#owner
• http://jabber.org/protocol/muc#user

14.2 Service Discovery Category/Type

A Multi-User Chat service or room is identified by the "conference" category and the "text" type within Service Discovery.

14.3 Service Discovery Features

There are many features related to a MUC service or room that can be discovered by means of Service Discovery. The most fundamental of these is the 'http://jabber.org/protocol/muc' namespace. In addition, a MUC room SHOULD provide information about the specific room features it implements, such as password protection and room moderation.

Registry Submission

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

14.4 Well-Known Service Discovery Nodes

The well-known Service Discovery node 'http://jabber.org/protocol/muc#rooms' enables discovery of the rooms in which a user is an occupant.

The well-known Service Discovery node 'x-roomuser-item' enables a user to discover his or registered roomnick from outside the room.

The well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' enables discovery of the namespaces that are allowed in traffic sent through a room (see the Allowable Traffic section of this document).

14.5 Field Standardization

Field Standardization for Data Forms [22] defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. Within MUC, there are three uses of such forms: room registration within muc#user, room configuration within muc#owner, and service discovery extensions for room information. The reserved fields are defined below.

<form_type>
  <name>http://jabber.org/protocol/muc#register</name>
  <doc>JEP-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='First Name'/>
  <field
      var='muc#register_last'
      type='text-single'
      label='Last 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>
      

<form_type>
  <name>http://jabber.org/protocol/muc#roomconfig</name>
  <doc>JEP-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 Logging of Room Conversations'/>
  <field
      var='muc#roomconfig_lang'
      type='text-single'
      label='Natural Language for Room Discussions'/>
  <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>
      

<form_type>
  <name>http://jabber.org/protocol/muc#roominfo</name>
  <doc>JEP-0045</doc>
  <desc>
    Forms enabling the communication of extended service discovery
    information about a Multi-User Chat (MUC) room.
  </desc>
  <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_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'/>
</form_type>
      

14.6 Status Codes Registry

<statuscode>
  <number>the three-digit code number</number>
  <stanza>the stanza type of which it is a child (message or presence)</desc>
  <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>
      

<statuscode>
  <number>100</number>
  <stanza>message</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 some room configuration has changed</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>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.1 Addresses

In order to provide consistency regarding the addresses captured in room JIDs, Room IDs MUST match the Nodeprep profile of Stringprep and Room Nicknames MUST match the Resourceprep profile of Stringprep (both of these are defined in RFC 3920)).

15.2 Message

1. If an occupant wants to send a message to all other occupants, a MUC client MUST set the 'type' attribute to a value of "groupchat". A service MAY ignore messages that are improperly typed, or reject them with a <bad-request/> error.

2. If a MUC service receives a message directed to the room or to a single occupant from a Jabber user who has a role of "none", the service MUST NOT deliver the message and SHOULD return the message to the sender with a <forbidden/> error.

3. If a MUC service receives a message directed to a room that does not exist or is not yet unlocked, the service SHOULD return the message to the sender with an <item-not-found/> error.

4. A MUC service SHOULD pass extended information (e.g., an XHTML version of the message body) through to occupants unchanged; however, a MUC service MAY disallow message specific extensions (see the Allowable Traffic section of this document).

5. A MUC client MAY generate extensions that conform to the Message Events [23] or Chat State Notifications [24] specification; however, a MUC service MAY disallow these extensions (see the Allowable Traffic section of this document).

15.3 Presence

1. A room MUST silently ignore unavailable presence received from a user who has a role of "none".

2. Only the MUC service itself SHOULD generate extended presence information about roles, affiliations, full JIDs, or status codes qualified by the 'http://jabber.org/protocol/muc#user' namespace (based on information the service knows about occupants, e.g., roles, or as a result of actions taken by a moderator or room administrator). A client SHOULD NOT presume to generate such information. If a MUC service receives such extended presence information from an occupant, it MUST NOT reflect it to other occupants. (A client MAY generate extended presence information qualified by the 'http://jabber.org/protocol/muc#user' namespace in order to supply a password, but naturally this is not reflected to other occupants.)

3. A MUC service SHOULD allow all other presence information to pass through, although it MAY choose to block extended presence information; see the Allowable Traffic section of this document.

4. In order to appropriately inform occupants of room roles and affiliations, and to make it easier for Jabber clients to track the current state of all users in the room, MUC service implementations MUST provide extended presence information about roles and affiliations in all presence stanzas, including presence stanzas of type "unavailable" sent when a user exits the room for any reason.

5. If a privilege is revoked, the service MUST note that by sending an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child element with the 'role' and/or 'affiliation' attributes set to a value that indicates the loss of the relevant privilege. All future presence stanzas for the occupant MUST include the updated role and affiliation, until and unless they change again.

6. A MUC service MUST send extended presence to a client even if the client did not send an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace on entering the room; naturally, a client MUST ignore such information if it does not understand it (in accordance with RFC 3920).

7. Extended presence about roles and affiliations sent in the muc#user namespace MUST include the full JID (not the bare JID) as the value of the 'jid' attribute.

8. A client MAY send a custom exit message if desired (as is often done in IRC channels) by including a <status/> element in the presence stanza of type "unavailable" sent when exiting a room.

15.4 IQ

1. If an occupant wants to send an IQ stanza to another user in a non-anonymous room, the sender SHOULD send the request directly to the recipient's bare JID or full JID, rather than attempting to send the request through the room (i.e., via the recipient's room JID).

2. If an occupant wants to send an IQ stanza to another user in a semi-anonymous room, the sender can direct the stanza to the recipient's room JID and the service MAY forward the stanza to the recipient's real JID. However, a MUC service MUST NOT reveal the sender's real JID to the recipient at any time, nor reveal the recipient's real JID to the sender.

3. A MUC client MUST send only the 'affiliation' attribute or the 'role' attribute in the <item/> element contained within an IQ set qualified by the 'http://jabber.org/protocol/muc#admin' namespace; if a moderator, admin, or owner attempts to modify both the affiliation and role of the same item in the same IQ set, the service MUST return a <bad-request/> error to the sender. However, a MUC service MAY modify a role based on a change to an affiliation and thus MAY send presence updates that include both a modified role and a modified affiliation.

4. In IQ sets regarding roles, a MUC client MUST include the 'nick' attribute only; in IQ results regarding roles, a MUC service MUST include the 'nick', 'role', 'affiliation', and 'jid' attributes (with the value of the latter set to the user's full JID).

5. In IQ sets regarding affiliations, a MUC client MUST include the 'jid' attribute only (with the value set to the bare JID); in IQ results regarding affiliations, a MUC service MUST NOT include the 'role' attribute, MUST include the 'affiliation' attribute and the 'jid' attribute (with the value set to the bare JID), and SHOULD include the 'nick' attribute (except if the affiliation is "outcast", since outcasts SHOULD NOT have reserved nicknames).

16.1 Services

1. In handling messages sent by visitors in a moderated room, a MUC service MAY queue each message for approval by a moderator and MAY inform the sender that the message is being held for approval; however, such behavior is OPTIONAL, and definition of a message approval protocol (e.g., using Data Forms as defined in JEP-0004) is out of scope for this JEP.

2. It is common for MUC services to provide in-room messages when certain events occur, such as when the subject changes, when an occupant enters or exits, or when a room is destroyed. Such messages are entirely OPTIONAL and are left up to the implementation or deployment, but if used MUST be messages of type "groupchat" sent from the room JID itself (room@service) rather than a specific occupant (<room@service/nick>). However, in general it is preferable for the receiving client to generate such messages based on events in the room (e.g., user entrances and exits) as well as specific status codes provided in MUC; this will help ensure correct localization of such messages.

3. Out of courtesy, a MUC service MAY send an out-of-room <message/> to an occupant who is kicked or banned, and MAY broadcast an in-room <message/> to all remaining occupants informing them that the occupant has been kicked or banned from the room. However, such messages are OPTIONAL, and indeed are unnecessary since the information required for a receiving client to generate such messages is communicated in the presence stanzas (specifically the status codes) sent by a MUC service.

4. Out of courtesy, a MUC service MAY send an out-of-room <message/> if a user's affiliation changes while the user is not in the room; the message SHOULD be sent from the room to the user's bare JID, MAY contain a <body/> element describing the affiliation change, and MUST contain a status code of 101.

5. There is no requirement that a MUC service shall provide special treatment for users of the older "groupchat 1.0" protocol, such as messages that contain equivalents to the extended presence information that is qualified by the 'http://jabber.org/protocol/muc#user' namespace.

6. Room types MAY be configured in any combination. A MUC service MAY support or allow any desired room types or combinations thereof.

7. A MUC service MAY limit the number of configuration options presented to an owner after initial configuration has been completed, e.g. because certain options cannot take effect without restarting the service.

8. A MUC service MAY provide an interface to room creation and configuration (e.g., in the form of a special Jabber user or a Web page), so that the ostensible room owner is actually the application instead of a human user.

9. A MUC service MAY choose to make available a special in-room resource that provides an interface to administrative functionality (e.g., a "user" named "ChatBot"), which occupants could interact with directly, thus enabling admins to type '/command parameter' in a private message to that "user". Obviously this kind of implementation would require the service to add a 'ChatBot' user to the room when it is created, and to prevent any occupant from having the nickname 'ChatBot' in the room. This might be difficult to ensure in some implementations or deployments. In any case, any such interface is OPTIONAL.

10. A MUC service SHOULD remove a user if the service receives a delivery-related error in relation to a stanza it has previously sent to the user (remote server unreachable, user not found, etc.).

11. A MUC service MAY choose to discard extended presence information that is attached to a <presence/> stanza before reflecting the presence change to the occupants of a room. That is, an implementation MAY choose to reflect only the <show/>, <status/>, and <priority/> child elements of the presence element as specified in the XML schema for the 'jabber:client' namespace, with the result that presence "changes" in extended namespaces (e.g., gabber:x:music:info) are not passed through to occupants. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the Allowable Traffic section of this document.

12. A MUC service MAY choose to discard extended information attached to <message/> stanzas before reflecting the message to the occupants of a room. An example of such extended information is the lightweight text markup specified by XHTML-IM [25]. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the Allowable Traffic section of this document..

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

<iq from='heath@macbeth.shakespeare.lit'
    to='wiccarocks@shakespeare.lit/laptop'
    id='allow1'
    type='get'>
  <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/protocolhttp://jabber.org/protocol//rosterx'/>
  </query>
</iq>
      

16.2 Clients

1. Jabber clients MAY present room roles by showing ad-hoc groups for each role within a room roster. This will enable occupants to clearly visualize which occupants are moderators, participants, and visitors. However, such a representation is OPTIONAL.

2. Jabber clients MAY implement a variety of interface styles that provide "shortcuts" to functionality such as changing one's nickname, kicking or banning users, discovering an occupant's full JID, or changing the subject. One option consists of IRC-style commands such as '/nick', '/kick', '/ban', and '/whois'; another is to enable a user to right-click items in a room roster. All such interface styles are OPTIONAL. However, for convenience, a mapping of IRC commands to MUC protocols is provided below.

<iq id='someid'
    to='room@service'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='outcast'
          jid='jid-of-roomnick'>
      <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>
          

17.1 http://jabber.org/protocol/muc

<?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
      JEP-0045: http://www.jabber.org/jeps/jep-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>
    

17.2 http://jabber.org/protocol/muc#user

<?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
      JEP-0045: http://www.jabber.org/jeps/jep-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'/>
      </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 name='continue' type='empty' 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='status'>
    <xs:complexType>
      <xs:attribute name='code' use='required'>
        <xs:simpleType>
          <xs:restriction base='xs:int'>
            <xs:length value='3'/>
          </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>
    

17.3 http://jabber.org/protocol/muc#admin

<?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
      JEP-0045: http://www.jabber.org/jeps/jep-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>
    

17.4 http://jabber.org/protocol/muc#owner

<?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
      JEP-0045: http://www.jabber.org/jeps/jep-0045.html
    </xs:documentation>
  </xs:annotation>

  <xs:import 
      namespace='jabber:x:data'
      schemaLocation='http://jabber.org/protocol/x-data/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>
    

1. RFC 1459: Internet Relay Chat <http://www.ietf.org/rfc/rfc1459.txt>.

2. http://www.jabber.org/protocol/groupchat.html

3. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.

4. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.

5. JEP-0128: Service Discovery Extensions <http://www.jabber.org/jeps/jep-0128.html>.

6. JEP-0091: Delayed Delivery <http://www.jabber.org/jeps/jep-0091.html>.

7. JEP-0082: Jabber Date and Time Profiles <http://www.jabber.org/jeps/jep-0082.html>.

8. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.

9. JEP-0077: In-Band Registration <http://www.jabber.org/jeps/jep-0077.html>.

10. JEP-0004: Data Forms <http://www.jabber.org/jeps/jep-0004.html>.

11. Some commentors have complained that this opens room owners and administrators up to potential abuse; however, with power comes responsibility.

12. JEP-0133: Service Administration <http://www.jabber.org/jeps/jep-0133.html>.

13. JEP-0050: Ad-Hoc Commands <http://www.jabber.org/jeps/jep-0050.html>.

14. JEP-0060: Publish-Subscribe <http://www.jabber.org/jeps/jep-0060.html>.

15. This is different from the behavior of room configuration, wherein the 'muc#roomconfig_roomowners' field specifies the full list of room owners, not the delta.

16. This is different from the behavior of room configuration, wherein the 'muc#roomconfig_roomadmins' field specifies the full list of room admins, not the delta.

17. JEP-0086: Error Condition Mappings <http://www.jabber.org/jeps/jep-0086.html>.

18. RFC 2616: Hypertext Transport Protocol -- HTTP/1.1 <http://www.ietf.org/rfc/rfc2616.txt>.

19. RFC 1893: Enhanced Mail System Status Codes <http://www.ietf.org/rfc/rfc1893.txt>.

20. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

21. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.

22. JEP-0068: Field Data Standardization for Data Forms <http://www.jabber.org/jeps/jep-0068.html>.

23. JEP-0022: Message Events <http://www.jabber.org/jeps/jep-0022.html>.

24. JEP-0085: Chat State Notifications <http://www.jabber.org/jeps/jep-0085.html>.

25. JEP-0071: XHTML-IM <http://www.jabber.org/jeps/jep-0071.html>.

Version 1.19 (2005-04-21)

Version 1.18 (2004-11-02)

Version 1.17 (2004-10-04)

Version 1.16 (2004-06-30)

Version 1.15 (2004-06-24)

Version 1.14 (2004-05-03)

Version 1.13 (2004-03-31)

Version 1.12 (2004-03-01)

Version 1.11 (2004-02-05)

Version 1.10 (2004-01-07)

Version 1.9 (2003-12-14)

Version 1.8 (2003-12-04)

Version 1.7 (2003-10-21)

Version 1.6 (2003-10-03)

Version 1.5 (2003-09-11)

Version 1.4 (2003-02-16)

Version 1.3 (2003-02-11)

Version 1.2 (2003-01-30)

Version 1.1 (2002-12-16)

Version 1.0 (2002-11-21)