JEP-0XXX: Simplified Multi-User Chat

This JEP defines a robust protocol for XMPP-based text conferencing that is a superset of JEP-0045.


WARNING: This document has not yet been accepted for consideration or approved in any official manner by the Jabber Software Foundation, and this document must not be referred to as a Jabber Enhancement Proposal (JEP). If this document is accepted as a JEP by the Jabber Council, it will be published at <http://www.jabber.org/jeps/> and announced on the <standards-jig@jabber.org> mailing list.


JEP Information

Status: Experimental
Type: Standards Track
Number: 0XXX
Version: 0.0.1
Last Updated: 2005-01-10
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, XMPP IM, JEP-0004, JEP-0030, JEP-0068, JEP-0045, JEP-0082
Supersedes: JEP-0045
Superseded By: None
Short Name: muc+

Author Information

Nolan Eakins

Email: sneakin@semanticgap.com
JID: sneakin@semanticgap.com

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2005 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.php>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocols defined in this JEP have been developed outside the Internet Standards Process and are to be understood as extensions to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.


Table of Contents

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. Room Creation
6.4. Exiting a Room
6.5. Changing Nickname
6.6. Changing Availability Status
6.7. Inviting Another User to a Room
6.8. Requesting and Reserving an Unique Room Name
6.9. Converting a One-to-One Chat Into a Conference
6.10. Modifying the Room Subject
6.11. Sending a Private Message
6.12. Sending a Message to All Occupants
6.13. Registering with a Room
6.14. Discovering Reserved Room Nickname
7. Changing Roles
7.1. Basic Role Change
7.1.1. Changing an Occupant's Role to 'none'
7.2. Requesting a Role List
7.3. Changing Multiple Roles
8. Changing Affiliations
8.1. Basic Affiliation Change
8.1.1. Changing an Occupant's Affiliation to 'outcast'
8.1.2. Changing an Occupant's Affiliation to 'member'
8.2. Requesting an Affiliation List
8.3. Changing Multiple Affiliations
9. Moderator Use Cases
10. Admin Use Cases
10.1. Approving Registration Requests
11. Owner Use Cases
11.1. Creating a Room
11.2. Subsequent Room Configuration
11.3. Destroying a Room
12. Error and Status Codes
13. Security Considerations
14. IANA Considerations
15. Jabber Registrar Considerations
15.1. Protocol Namespaces
15.2. Service Discovery Category/Type
15.3. Service Discovery Features
15.4. Well-Known Service Discovery Nodes
15.5. Field Standardization
15.5.1. muc#register FORM_TYPE
15.5.2. muc#roomconfig FORM_TYPE
15.5.3. muc#roominfo FORM_TYPE
16. Business Rules
16.1. Room JIDs
16.2. Message
16.3. Presence
16.4. IQ
17. Implementation Notes
17.1. Services
17.1.1. Allowable Traffic
17.2. Clients
17.2.1. IRC Command Mapping
18. XML Schemas
18.1. http://jabber.org/protocol/muc
18.2. http://jabber.org/protocol/muc#user
18.3. http://jabber.org/protocol/muc#admin
18.4. http://jabber.org/protocol/muc#owner
19. Acknowledgements
Notes
Revision History


1. Introduction

Multi-User Chat [1] defines a usable protocol for text conferencing. While good it creates more complexity than is necessary, and it stepped too far into the details of implementation from the terminology used and use cases it described. This JEP is practically the same as Multi-User Chat [2], except that it simplifies the presentation of Multi-User Chat [3] by giving it a refactoring making it more powerful as a protocol. Some use cases have been condensed making it easier for implementors to implement, while also allowing greater versatility through some simple changes and additions.

This JEP aims to allow a client that implements Multi-User Chat [4] to work with a MUC+ service without any changes. The defined protocol is basically a superset of what JEP-0045 defined. Thus the same schemas and namespaces that JEP-0045 defined are used with some minor changes and additions.

This JEP has condensed, changed, or added to JEP-0045 in the following ways:

2. Scope

This JEP addresses common requirements related to configuration of, participation in, and administration of individual text-based conference rooms. All of the requirements addressed herein apply at the level of the individual room and are "common" in the sense that they have been widely discussed within the Jabber community or are familiar from existing text-based conference environments outside of Jabber (e.g., Internet Relay Chat as defined in RFC 1459 [5]).

This JEP explicitly does not address the following:

This limited scope is not meant to disparage such topics, which are of inherent interest; however, it is meant to focus the discussion in this JEP and to present a comprehensible proposal that can be implemented by Jabber client and component developers alike. Future JEPs may of course address the topics mentioned above.

3. Requirements

This JEP must address the minimal functionality provided by existing multi-user chat services in Jabber. For the sake of backward-compatibility, this JEP uses the original "groupchat 1.0" protocol for this baseline functionality, with the result that:

The additional features and functionality addressed in this JEP include the following:

  1. "native" conversation logging (no bot required)
  2. enabling users to request membership in a room
  3. enabling occupants to view an occupant's full JID in a non-anonymous room
  4. enabling moderators to view an occupant's full JID in a semi-anonymous room
  5. allowing only moderators to change the room subject
  6. enabling moderators to kick participants and visitors from the room
  7. enabling moderators to grant and revoke voice (i.e., the privilege to speak) in a moderated room
  8. enabling admins to grant and revoke moderator privileges
  9. enabling admins to ban users from the room
  10. enabling admins to grant and revoke membership privileges
  11. enabling owners to limit the number of occupants
  12. enabling owners to specify other owners
  13. enabling owners to grant and revoke administrative privileges
  14. enabling owners to destroy the room

In addition, this JEP provides protocol elements for supporting the following room types:

  1. public or hidden
  2. persistent or temporary
  3. password-protected or unsecured
  4. members-only or open
  5. moderated or unmoderated
  6. non-anonymous or semi-anonymous

4. Terminology

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 orthogonal to 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 [6] currently in use for text-based conferencing in Jabber.

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 documented in Multi-User Chat [7]; occasionally refered to as "the original MUC".

MUC+ — the multi-user chat protocol for text-based conferencing documented in this JEP that is a superset of MUC.

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, orthogonal to 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 more than one other user.

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

Room Owner — the Jabber user who created the room, or a Jabber user who has been designated by the room creator 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; 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 affiliated with room as a 'member'; 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 occupants' full JIDs are exposed to all occupants, although they may choose any desired room nickname; contrast with Semi-Anonymous Room and Fully-Anonymous Room.

Open Room — a room that anyone may enter unless their affiliation is 'outcast'; 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 occupants' full JIDs 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. Roles and Affiliations

There are two dimensions along which we can measure a user's connection with or position in a room. One is the user's long-lived affiliation with a room — e.g., a user's status as an owner or an outcast. The other is a user's role while an occupant of a room — e.g., an occupant's position as a moderator with the ability to kick visitors and participants. These two dimensions are orthogonal to each other, since an affiliation lasts across visits, while a role lasts only for the duration of a visit. In addition, there is no one-to-one correspondence between roles and affiliations; for example, someone who is not affiliated with a room may be a (temporary) moderator, and a member may be a participant or a visitor in a moderated room. These concepts are explained more fully below.

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

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

Table 1: Privileges Associated With Roles

Privilege None Visitor Participant Moderator
Present in Room No Yes Yes Yes
Receive Messages No Yes Yes Yes
Change Availability Status No Yes Yes Yes
Change Room Nickname No Yes* Yes Yes
Send Private Messages No Yes* Yes Yes
Invite Other Users No Yes* Yes* Yes
Send Messages to All No No** Yes Yes
Modify Subject No No Yes* Yes
Kick Participants and Visitors No No No Yes
Change a role to 'participant' No No No Yes
Change a role to 'visitor' No No No Yes***

* Default; configuration settings MAY further restrict this privilege.

** An implementation MAY use 'participant' as the default for occupants in unmoderated rooms.

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

5.1.2 Changing Roles

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

Table 2: Role State Chart

> None Visitor Participant Moderator
None Enter moderated room Enter unmoderated room Admin grants moderator privileges
Visitor Exit room or be kicked by a moderator Moderator grants voice Admin grants moderator privileges
Participant Exit room or be kicked by a moderator Moderator revokes voice Admin grants moderator privileges
Moderator Exit room Admin changes role to visitor Admin changes role to participant or revokes moderator privileges **

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

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.

Owners and admins are by definition immune from certain actions. Specifically, an owner or admin cannot be kicked from a room and cannot be banned from a room. An admin MUST first lose his or her affiliation (i.e., have an affiliation of "none" or "member") before such actions could be performed on them.

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.

5.2.1 Privileges

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

Table 3: Privileges Associated With Affiliations

Privilege Outcast None Member Admin Owner
Enter Open Room No Yes** Yes Yes Yes
Register with an Open Room No Yes n/a n/a n/a
Enter Members-Only Room No No Yes* Yes Yes
Ban Members and Unaffiliated Users No No No Yes Yes
Change an affiliation to/from 'member' No No No Yes Yes
Change a role to/from 'moderator' No No No Yes** Yes**
Change an affiliation to/from 'admin' No No No No Yes
Change an affiliation to/from 'owner' No No No No Yes
Change Room Definition No No No No Yes
Destroy Room No No No No Yes

* As a default, an unaffiliated user enters a moderated room as a visitor, and enters an open room as a participant. A member enters a room as a participant. An admin or owner enters a room as a moderator.

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

5.2.2 Changing Affiliations

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

Table 4: Affiliation State Chart

-> Outcast None Member Admin Owner
Outcast Admin or owner removes ban Admin or owner changes affiliation to "member" Owner changes affiliation to "admin" Owner changes affiliation to "owner"
None Admin or owner applies ban Admin or owner changes affiliation to "member", or user registers as member (if allowed) Owner changes affiliation to "admin" Owner changes affiliation to "owner"
Member Admin or owner applies ban Admin or owner changes affiliation to "none" Owner changes affiliation to "admin" Owner changes affiliation to "owner"
Admin Owner applies ban Owner changes affiliation to "none" Owner changes affiliation to "member" Owner changes affiliation to "owner"
Owner Owner applies ban Owner changes affiliation to "none" Owner changes affiliation to "member" Owner changes affiliation to "admin"

6. Occupant Use Cases

The main actor in a multi-user chat environment is the occupant, who can be said to be located "in" a multi-user chat room and to participate in the discussions held in that room (for the purposes of this JEP, participants and visitors are considered to be "mere" occupants, since they possess no administrative privileges). As will become clear, the protocol elements proposed in this JEP to fulfill the occupant use cases fall into three categories:

  1. existing "groupchat 1.0" protocol for minimal functionality

  2. straightforward applications of the "groupchat 1.0" protocol, for example to handle some of the errors related to new room types

  3. new protocol elements to handle functionality not covered by "groupchat 1.0" (room invites, room passwords, extended presence related to room roles and affiliations); these are contained in the new 'http://jabber.org/protocol/muc#user' namespace

Note: All client-generated examples herein are presented from the perspective of the service, with the result that all stanzas received by a service contain a 'from' attribute corresponding to the sender's full JID as added by a normal Jabber router or session manager. In addition, normal IQ result stanzas sent upon successful completion of a request are not shown. Most of the examples in this document use the scenario of the witches' meeting held in a dark cave at the beginning of Act IV, Scene I of Shakespeare's Macbeth. The characters are as follows:

Table 5: Dramatis Personae

Room Nickname Full JID Affiliation
firstwitch crone1@shakespeare.lit/desktop Owner
secondwitch wiccarocks@shakespeare.lit/laptop Admin
thirdwitch hag66@shakespeare.lit/pda None

6.1 Discovering Component Support for MUC

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

A compliant implementation MUST support Service Discovery [8].

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'/>
    <feature var='http://jabber.org/protocol/muc#plus'/>
  </query>
</iq>
    

Notes: because MUC+ is a superset of MUC and aims to allow older clients to work with a MUC+ service, both features MUST be returned. Whereas 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:

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='http://jabber.org/protocol/muc#plus'/>
    <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>
    

Notes: Because MUC+ is a superset of MUC and aims to allow older clients to work with a MUC+ service both 'http://jabber.org/protocol/muc' and 'http://jabber.org/protocol/muc#plus' MUST be returned. Since 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 var registry maintained by the Jabber Registrar; see also the registry submission in this document).

A chatroom MAY return more detailed information in its disco#info response using Service Discovery Extensions [9]. 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='http://jabber.org/protocol/muc#plus'/>
    <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 that these <item/> elements are in 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 an entity attempts to send a disco request to an address of the form <room@service/nick>, a compliant component SHOULD return the request to the entity and specify a <bad-request/> error condition.

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 room nick as the value of the 'name' attribute:

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

6.3 Entering a Room

6.3.1 Groupchat 1.0 Protocol

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

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

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

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

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

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

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

6.3.2 Basic MUC Protocol

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

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

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

6.3.3 Presence Broadcast

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

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

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

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

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

Example 19. Service Sends New Occupant's Presence 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' 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>
      

In this example, initial room presence is being sent from the new occupant (thirdwitch) to all occupants, including the new occupant.

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

6.3.4 Default Roles

The following table summarizes the initial default roles that a service should set based on the user's affiliation (there is no role associated with the "outcast" affiliation, since such users are never allowed to enter the room).

Table 6: Initial Role Based on Affiliation

Room Type None Member Admin Owner
Moderated Visitor Participant Moderator Moderator
Unmoderated Participant Participant Moderator Moderator
Members-Only n/a Participant Moderator Moderator
Open Participant Participant Moderator Moderator

6.3.5 Non-Anonymous Rooms

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

Example 20. Service Sends Full JID 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>
.
.
.
      

If the user is entering a room that is non-anonymous (i.e., which informs all occupants of each occupant's full JID as shown above), the service SHOULD allow the user to enter the room but MAY warn the user that the room is not anonymous; this is done by sending a message of type "groupchat" to the new occupant containing an <x/> child with a <status/> element that has the 'code' attribute set to a value of "100":

Example 21. Service Warns New Occupant of Lack of Anonymity

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

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

6.3.6 Semi-Anonymous Rooms

If the room is semi-anonymous, the service MUST send the new occupant's full JID in the format shown above only to those occupants with a role of "moderator".

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

6.3.7 Password-Protected Rooms

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

Example 22. Service Denies Access Because No Password Provided

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

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

Example 23. User Provides Password On Entering a Room

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

6.3.8 Members-Only Rooms

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

Example 24. Service Denies Access Because User Is Not a Member

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

6.3.9 Banned Users

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

Example 25. Service Denies Access Because User is Banned

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

6.3.10 Nickname Conflict

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

Example 26. Service Denies Access 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.3.11 Max Users

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

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

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

Once the number of occupants goes below the maximum number, the service SHOULD go ahead and add the user to the room.

6.3.12 Discussion History

After sending initial presence as shown above, a room MAY send discussion history to the new occupant. Whether such history is sent, and how many messages comprise the history, shall be determined by the chat service implementation or specific deployment.

Example 28. Delivery of Discussion History

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

Discussion history messages SHOULD be stamped with extended information in the 'jabber:x:delay' namespace (see Delayed Delivery [10]) to indicate that they are sent with delayed delivery. The 'from' attribute SHOULD be the JID of the original sender in non-anonymous rooms, but MUST NOT be in semi-anonymous rooms (the 'from' attribute SHOULD be set to the room JID in semi-anonymous rooms).

6.3.13 Managing Discussion History

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

Table 7: History Management Attributes

Attribute Datatype Meaning
maxchars int Limit the total number of characters in the history to "X".
maxstanzas int Limit the total number of messages in the history to "X".
seconds int Send only the messages received in the last "X" seconds.
since dateTime Send only the messages received since the dateTime specified (which MUST conform to Jabber Date and Time Profiles [11]).

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

The following examples illustrate the use of this protocol.

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

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

Example 30. User Requests History in Last 3 Minutes

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

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

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

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

Example 32. User Requests No History

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

6.3.14 Room Creation

If the room does not already exist when the user seeks to enter it, the service MAY be responsible for creating it; however, this is OPTIONAL, since an implementation or deployment MAY choose to restrict the privilege of creating rooms. See "Owner Use Cases" for details.

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

Example 33. Service Denies Access Because Room Does Not Exist

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

Normal presence stanza generation rules apply as defined in XMPP IM, 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 Jabber 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 36. Occupant Changes Nickname

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

The service then sends two presence packets 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 scoped 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 37. 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 38. 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 room@service/nick.

Example 39. 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 packet 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 40. 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. The protocol most commonly used is for the inviting occupant to send a message directly to the invitee, containing extended content in 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 41. Occupant Sends an Invitation (Existing Protocol)

<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 existing 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 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 be officially discouraged (it cannot be deprecated since it was never approved) and a MUC-compliant client MUST instead send XML of the following form to the room 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 42. 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 occupant may also invite more than one person at a time:

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>
    <invite to='hag66@shakespeare.lit'>
      <reason>
        Hey Hag66, this is the place for all good witches!
      </reason>
    </invite>
  </x>
</message>
    

The room itself MUST then add a 'from' address to the <invite/> element equal to the bare JID (or, optionally, the room JID) of the inviter and send the invitation to the invitee captured in the 'to' address (the service SHOULD include the jabber:x:conference information for backward compatibility and MAY if desired include a message body explaining the invitation or containing the reason; in addition, the room SHOULD add the password if the room is password-protected). If the invitee included multiple invites, the room MUST send an invitation to each one seperately:

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

<message
    from='darkcave@macbeth.shakespeare.lit'
    to='hecate@shakespeare.lit'>
  <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='room@service' xmlns='jabber:x:conference'>
    Hey Hecate, this is the place for all good witches!
  </x>
</message>
    

If the room is members-only, the service SHOULD also set the invitee's affiliation to 'member'. (Note that invitation privileges in members-only rooms SHOULD be restricted to room admins; if a member without privileges to change an affiliation to 'member' attempts to invite another user, the service SHOULD return a <forbidden/> error to the occupant; for details, see the Changing Affiliations section.

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

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

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 Inviter 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 inviter. 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), in which case the service MUST handle both the invites and declines.

6.8 Requesting and Reserving an Unique Room Name

A MUC+ service MUST allow entities to request and reserve unique rooms. This facilitates converting a one-to-one chat into a multi-user chat. It may also be handy for other things as well.

To request an unique room, a client sends an <iq/> with its <query/> scoped by the 'http://jabber.org/protocol/muc' namespace that includes an <unique-room/> element. The returned <iq/> is practically the same except that the <unique-room/> element includes the room's name and has an 'expires' attribute set to the time that the reservation expires which MUST follow Jabber Date and Time Profiles [12]:

Example 47. Requests an Unique Room

<iq to="macbeth.shakespeare.lit"
    from="crone1@shakespeare.lit/desktop"
    type="get"
    id="unique">
  <query xmlns="http://jabber.org/protocol/muc">
    <unique-room/>
  </query>
</iq>

<iq to="crone1@shakespeare.lit/desktop"
    from="crone1@shakespeare.lit/desktop"
    type="result"
    id="unique">
  <query xmlns="http://jabber.org/protocol/muc">
    <unique-room expires="2005-01-01T12:00Z">unique_1</unique-room>
  </query>
</iq>
    

It is not specified in this JEP the form of the room name, except that it MUST NOT be an existing room. It could be a UUID, hash of the requestor's JID, or something else. The expiration time is RECOMMENDED to be no more than five minutes, but this SHOULD be configurable.

The service MAY also limit the number of unique rooms a single entity can reserve at any one time. In such a case the service MUST return a <resource-constraint/> error:

Example 48. Error on Reserving to Many Unique Rooms

<iq to="crone1@shakespeare.lit/desktop"
    from="crone1@shakespeare.lit/desktop"
    type="error"
    id="unique">
  <error code='500' type='cancel'>
    <resource-constraint xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

If someone other than the requestor tries to create the reserved room, the service MUST deny the request with a <not-allowed/> error:

Example 49. Entity Attempts To Create a Room That's Reserved

<presence to="unique_1@macbeth.shakespeare.lit/hag66"
          from="hag66@shakespeare.lit">
  <x xmlns="http://jabber.org/protocol/muc"/>
</presence>

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

6.9 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. This can be done by using the <continue/> child element. The process flow is shown in the following examples.

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

Example 50. 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. Requests an unique room that will be reserved (the previous use case)
  2. Creates the new room by including the <continue/> child element in the presence
  3. Optionally sends history of the one-to-one chat to the room
  4. Sends an invitation to the second person, third person, and whoever else including a <continue/> flag.

Example 51. Continuing the Discussion I: User Creates Room

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

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

The continue element signals to the service that the owner wishes to continue an existing one-to-one chat.  This allows the service to provision the room accordingly.  The service MAY have a different default configuration for continued conversations than other newly created rooms.  The service SHOULD immediately unlock the room, apply the instant room defaults, and not require any configuration.  It is RECOMMENDED that the service configure the room as non-persistent, non-anonymous, private, and members only.

Once the room is created, the first person MAY send the one-to-one chat to the room:

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

<message
    from='crone1@shakespeare.lit/desktop'
    to='unique_1@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='unique_1@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 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 under Discussion History) to prior chat history messages received from the room owner.

The service MUST NOT accept messages of type groupchat containing delayed delivery elements from any occupant other than the room owner, or in any rooms which were not created with the <continue/> element, or after any users other than the initial owner have joined the room. The service MUST respond with a <bad-request/> stanza error to such messages and MUST NOT broadcast the message to room occupants.

Once the discussion history has been set, the first occupant can then invite others:

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

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

The invitations are delivered to the invitees:

Example 54. Invitations Delivered

<message
    from='unique_1@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='unique_1@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>
    

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

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

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

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

<presence
    from='unique_1@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='unique_1@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='unique_1@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='unique_1@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 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.10 Modifying the Room Subject

A common feature of multi-user chat rooms is the ability to change the subject within the room. As a 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 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 56. 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 compliant 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 57. 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 compliant 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:

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

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

6.11 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 59. 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 60. 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 and return a <bad-request/> error to the sender:

Example 61. 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 a <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.12 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 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. In an unmoderated room, any occupant sends a message to all other occupants by directing the message to the room itself and setting the 'type' attribute to a value of "groupchat".

Example 62. 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 63. 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; however, 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 that user is not an occupant.

6.13 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 in the 'jabber:iq:register' namespace as described in In-Band Registration [13]:

Example 64. 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 a <item-not-found/> error.

Otherwise, the room MUST then return a form to the user in the 'jabber:x:data' namespace. The specific information required to register is not specified in this JEP and MAY vary by implementation or deployment. The following can be taken as a fairly typical example:

Example 65. 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 66. 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 67. 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 68. 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 does, the room MUST return a <bad-request/> error to the user:

Example 69. 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 70. 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 Approving Registration Requests) or MAY immediately change 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 scoped 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 71. 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" (406) error to the user if the user attempts to join the room with a room nick other than the user's registered room nick.

6.14 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 the 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 Service Discovery node of "x-roomuser-item".

Example 72. 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 it does and the user has a registered nickname, it MUST return the nickname to the user as value of the 'name' attribute of a Service Discovery <identity/> element (for which the category/type SHOULD be "conference/member"):

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

If the room or service does not support the foregoing service discovery node, it MUST return a "Feature Not Implemented" (502) error to the user.

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" (406) error. The service MUST NOT return an error to the user if his or her client performs the foregoing request after having already joined the room.

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.

7. Changing Roles

Only occupants whose role is "moderator" can change another occupants role. Even then strict rules apply depending on the second occupant's affiliation. These rules are given in the section Changing Roles.

7.1 Basic Role Change

A basic role change is when a single occupant has their role changed. This is typically done to grant/revoke voice or kick the occupant out of the room. The protocol is a simple <iq/> with its 'type' attribute set to 'set'. Role changes are sent to the room and have the <query/> scoped by the 'http://jabber.org/protocol/muc#admin' namespace. That namespace also specifies 'affiliation' and 'jid' attributes. These MUST NOT be used in changing roles since they are used to change affiliations. Since roles are temporary, changing them is based on the occupant's nickname. The following example changes thirdwitch's role to 'participant' giving her voice. (The '<reason/>' is OPTIONAL).

Example 74. Basic Role Change

<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 send updated presence from this individual to all occupants, indicating the change in role by including an <x/> element scoped by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to the corresponding role. If a <reason/> was given, this MUST be sent too:

Example 75. Service Sends Notice 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>
.
.
.
    

The service MUST then inform the moderator of success:

Example 76. Service Informs Moderator of Success

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

Depending on the occupant's affiliation a moderator may not be able to change their role. A moderator MUST NOT be able to change an occupant's role if the occupant's affiliation is equal to or above the moderator's in the hierarchy of affiliations. In addition, admins and owners can not have their roles changed. They are always moderators. If a moderator tries to change such an occupant's role, the service MUST deny the request and return a <not-allowed/> error to the sender:

Example 77. Service Returns Error on Attempt to Change Role

<iq from="darkcave@macbeth.shakespeare.lit"
    id="voice1"
    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>
    

If an occupant whose role is not moderator tries to change another occupant's role, the service MUST return a <forbidden/> error:

Example 78. Service Denies Request to Change Role

<iq from="darkcave@macbeth.shakespeare.lit"
    id="voice1"
    to="wiccarocks@shakespeare.lit/desktop"
    type="error">
  <query xmlns="http://jabber.org/protocol/muc#admin">
    <item nick="firstwitch" role="visitor"/>
  </query>
  <error code="403" type="cancel">
    <forbidden xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
  </error>
</iq>
    

7.1.1 Changing an Occupant's Role to 'none'

Changing an occupant's role to 'none' kicks them out of the room. This affects the <presence/> that is sent to the occupants. The <presence/> MUST have its 'type' attribute set to 'unavailable' and include a status code of 307. If the stanza is sent to the kicked occupant, the service SHOULD include the moderator's bare JID as follows:

Example 79. Notice Sent to 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 service MAY include the <actor/> in the <presence/> stanzas sent to the other occupants, but if the room is semi-anonymous a 'nick' attribute giving the moderator's nickname MUST be used instead of a 'jid' attribute. The remaining occupants receive the following:

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

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.

7.2 Requesting a Role List

A role list is a list of occupants that have a specified role. Requesting a role list may not be extremely useful since roles only apply to occupants in a room, it is however required to maintain compatibility with the original MUC that had use cases for modifying voice and moderator lists. To request a role list the following is sent to the room:

Example 81. Requesting a Role List

<iq from="author@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 role list to the moderator; each item MUST include the 'nick' and 'role' attributes and SHOULD include the 'affiliation' and 'jid' attributes, but it MUST NOT include the 'jid' if the requestor's role is not 'moderator' and the room is semi-anonymous:

Example 82. Service Sends Role List to Moderator

<iq from='goodfolk@chat.shakespeare.lit'
    id='voice3'
    to='author@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 service MUST also allow multiple roles to specified. This allows a list of all the roles to be retrieved in one swoop. To do so, multiple <item/> elements are included in the <query/>:

Example 83. Requesting a Mixed Role List

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

The service MUST then return a resulting <iq/>. The returned <iq/> has the same semantics as the result for the list for a single role, except that the 'role' attributes can be any of the requested roles:

Example 84. Service Sends Mixed Role List to Moderator

<iq from='goodfolk@chat.shakespeare.lit'
    id='voice3'
    to='author@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'/>
    <item affiliation='none'
          jid='juliet@shakespeare.lit/balcony'
          nick='Juliet'
          role='visitor'/>
    <item affiliation='owner'
          jid='author@shakespeare.lit/globe'
          nick='Bill'
          role='moderator'/>
  </query>
</iq>
    

7.3 Changing Multiple Roles

A moderator may want to modify the roles of more than one occupant at a time. This also encapsulates the voice and moderator list use cases that the original MUC defined. Changing the roles of multiple occupants is not much different from the basic role change. The difference is that multiple <item/> elements are used. The same rules apply, such as changing an occupant's role to 'none'. Also the 'jid' and 'affiliation' attributes MUST NOT be sent:

Example 85. Changing Multiple Roles

<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="secondwitch"
           role="moderator">
        <reason>A worthy witch indeed!</reason>
     </item>
     <item nick="thirdwitch"
           role="visitor"/>
  </query>
</iq>
    

The service MUST then send notice to all the occupants of the role change:

Example 86. Service Sends Notice 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="secondwitch"
          role="moderator">
      <reason>A worthy witch indeed!</reason>
    </item>
  </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"
          nick="thirdwitch"
          role="visitor"/>
  </x>
</presence>
.
.
.
    

The service MUST then inform the moderator of success:

Example 87. Service Informs Moderator of Success

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

If a moderator attempts to change an occupant whose affiliation is at or greater than their own, the service MUST return a <not-allowed/> error. This same error MUST be returned if one of the listed occupants is no longer in the room. The returned error <iq/> MUST only include the <item/> elements that caused the error as they appeared in the request:

Example 88. Error Changing Multiple Roles

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

As in the basic role change if an occupant whose role is not 'moderator' tries to change another occupant's role, a <forbidden/> error MUST be returned by the service. Since this is a non-moderator making the request, all of the <item/> elements MUST be returned because none of them will have taken affect.

8. Changing Affiliations

Typically only an occupant's whose affiliation is 'admin' or greater can change another occupant's affiliation. This is usually the case and is for the following use cases, though it may be possible for a user to change their own or another's affiliation through other means such as registration. Those exceptions are not covered in this section.

Affiliation changes are done through <iq/> request/response pairs. The <query/> element is scoped by one of two namespaces: 'http://jabber.org/protocol/muc#admin' or 'http://jabber.org/protocol/muc#owner'. Using the 'http://jabber.org/protocol/muc#owner' namespace is depreciated when changing affiliations, but is maintained only for compatibility with the original MUC (which used both namespaces depending on the affiliation change). Both MUST be supported by a component when changing affiliations.

Affiliations are associated with JIDs. Typically an entity's bare JID is used, but other JIDs are allowable. JIDs are matched according the following rules:

  1. <user@domain/resource> (only that resource matches)
  2. <user@domain> (any resource matches, the RECOMMENDED JID to be used)
  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)

Affiliation changes also follow certain rules that are defined in Affiliation Changes.

8.1 Basic Affiliation Change

A basic affiliation change is when a single entity's affiliation is changed, which may also affect the entity's role too. Affiliation changes can only be done by an admin or owner. An affiliation change is based on the entity's nick or a JID. JIDs are allowed because affiliations are long-lived and can be changed when the entity is not in the room, but could be less convenient to use than the entity's nick if the entity is in the room, so both are allowed.

An entity's affiliation is changed in a similar fashion as a role change except that an 'affiliation' attribute is used instead of a 'role' attribute. The 'role' attribute SHOULD NOT be sent, but if it is it MUST be ignored:

Example 89. Basic Affiliation Change

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

If it was an actual occupant's affiliation that was changed, the service MUST then send updated presence from this individual to all occupants, indicating the change in affiliation by including an <x/> element scoped by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to the corresponding affiliation. If a <reason/> was given, this MUST be sent too:

Example 90. Service Sends Notice 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="admin"
          nick="thirdwitch"
          role="moderator">
      <reason>A worthy witch indeed!</reason>
    </item>
  </x>
</presence>
.
.
.
    

The service MUST then inform the moderator of success:

Example 91. Service Informs Moderator of Success

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

An entity's affiliation can only be changed by an admin or owner whose affiliation is greater than their own. The exception is for owners, whose affiliation can be changed by another owner. If an owner tries to change their own affiliation and the room has no other owners, or if an occupant is not allowed to change an entity's affiliation, the service MUST deny the request and return a <not-allowed/> error to the sender:

Example 92. Service Returns Error on Attempt to Change Affiliation

<iq from="darkcave@macbeth.shakespeare.lit"
    id="affil2"
    to="hag66@shakespeare.lit/pda"
    type="error">
  <query xmlns="http://jabber.org/protocol/muc#admin">
    <item jid="crone1@shakespeare.lit" affiliation="member"/>
  </query>
  <error code="405" type="cancel">
    <not-allowed xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
  </error>
</iq>
    

If an occupant whose affiliation is not 'admin' or 'owner' tries to change another entity's affiliation, the service MUST return a <forbidden/> error:

Example 93. Service Denies Request to Change Affiliation

<iq from="darkcave@macbeth.shakespeare.lit"
    id="affil2"
    to="wiccarocks@shakespeare.lit/desktop"
    type="error">
  <query xmlns="http://jabber.org/protocol/muc#admin">
    <item jid="crone1@shakespeare.lit" affiliation="outcast"/>
  </query>
  <error code="403" type="cancel">
    <forbidden xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
  </error>
</iq>
    

8.1.1 Changing an Occupant's Affiliation to 'outcast'

Changing an occupant's affiliation to 'outcast' bans them from the room. This affects the <presence/> that is sent to the occupants. The <presence/> MUST have its 'type' attribute set to 'unavailable' and include a status code of 301. If the stanza is sent to the banned occupant, the service SHOULD include the admin or owner's bare JID as follows:

Example 94. Notice Sent to 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='outcast' role='none'>
      <actor jid='fluellen@shakespeare.lit'/>
      <reason>Avaunt, you cullion!</reason>
    </item>
    <status code='301'/>
  </x>
</presence>
      

The service MAY include the <actor/> in the <presence/> stanzas sent to the other occupants, but if the room is semi-anonymous a 'nick' attribute giving the admin or owner's nickname MUST be used instead of a 'jid' attribute. The remaining occupants receive the following:

Example 95. 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='outcast' role='none'/>
    <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 occupant would like to discuss the matter.

8.1.2 Changing an Occupant's Affiliation to 'member'

Besides the exception above when changing an entities affiliation to 'outcast', one exists when changing an entity's affiliation to 'member'. The service SHOULD send an invitation to an unaffiliated entity who has had their affiliation changed to 'member' in a members-only room and are not currently in the room. The following example includes both <reason/> and <password/> elements. These are OPTIONAL:

Example 96. 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='author@shakespeare.lit'/>
    <password>cauldron</password>
    <reason>Time to set the stage!</reason>
  </x>
  <x jid='darkcave@macbeth.shakespeare.lit'
     xmlns='jabber:x:conference'/>
</message>
      

8.2 Requesting an Affiliation List

An affiliation list is a list of JIDs that have a specified affiliation. To request an affiliation list the following is sent to the room:

Example 97. Requesting an Affiliation List

<iq from="author@shakespeare.lit/globe"
    id="affil5"
    to="goodfolk@chat.shakespeare.lit"
    type="get"
  <query xmlns="http://jabber.org/protocol/muc#admin">
     <item affiliation="outcast"/>
  </query>
</iq>
    

The service MUST then return the affiliation list to the requestor; each item MUST include the 'jid' and 'affiliation' attributes and MAY include the 'nick' and 'role' attributes if the entity is an occupant in the room. If the occupant is not in the room, the last known or registered nick MAY be sent with their role set to 'none':

Example 98. Service Sends Affiliation List

<iq from='goodfolk@chat.shakespeare.lit'
    id='affil5'
    to='author@shakespeare.lit/globe'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='outcast'
          jid='julius@rome/pda'
          nick='Ceasar'
          role='none'/>
    <item affiliation='outcast'
          jid='brutus@rome/senate'
          nick='brutus'
          role='none'/>
  </query>
</iq>
    

The service MUST also allow multiple affiliations to be specified. This allows the possibility of getting a list of all the affiliations in one swoop. This request could possibly be combined with a role list request. The service MAY support such a mixed request, but none of the examples demonstrate it and could make setting the roles and affiliations for multiple occupants more difficult. To do so, multiple <item/> elements are included in the <query/>:

Example 99. Requesting a Mixed Affiliation List

<iq from="author@shakespeare.lit/globe"
    id="affil6"
    to="goodfolk@chat.shakespeare.lit"
    type="get"
  <query xmlns="http://jabber.org/protocol/muc#admin">
     <item affiliation="owner"/>
     <item affiliation="admin"/>
  </query>
</iq>
    

The service MUST then return a resulting <iq/>. The returned <iq/> has the same semantics as the result for the list for a single affiliation list, except that the 'affiliation' attributes can be any of the requested affiliations:

Example 100. Service Sends Mixed Affiliation List

<iq from='goodfolk@chat.shakespeare.lit'
    id='affil6'
    to='author@shakespeare.lit/globe'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='owner'
          jid='author@shakespeare.lit'
          nick='Bill'
          role='moderator'/>
    <item affiliation='admin'
          jid='elizabeth@royalty.uk/castle'
          nick='TheQueen'
          role='moderator'/>
  </query>
</iq>
    

An implementation MAY allow occupants whose affiliation is not 'admin' or 'owner' to retrieve an affiliation list. The original MUC allowed other members to retrieve the list of members. Due to privacy concerns this may not be desirable since a list of JIDs may be obtained. Because of that, compatibility with the original MUC will not be observed, and implementations SHOULD only allow moderators, admins, and owners to retrieve affiliation lists in semi-anonymous rooms. If an occupant who is not a moderator, admin, or owner tries to retrieve an affiliation list, the service MUST return a <not-allowed/> error:

Example 101. Service Returns Error on Attempt to Retrieve an Affiliation List

<iq from="darkcave@macbeth.shakespeare.lit"
    id="affil2"
    to="hag66@shakespeare.lit/pda"
    type="error">
  <query xmlns="http://jabber.org/protocol/muc#admin">
    <item affiliation="owner"/>
  </query>
  <error code="405" type="cancel">
    <not-allowed xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
  </error>
</iq>
    

8.3 Changing Multiple Affiliations

An admin or owner may want to modify the affiliations of more than one user at a time. This also encapsulates the ban, admin, and owner list use cases that the original MUC defined. The difference is that multiple <item/> elements are used. Changing the affiliations of multiple occupants is not much different from the basic affiliation change. The same rules apply, as in changing an occupant's affiliation to 'outcast'. Also the 'role' attribute SHOULD NOT be sent, but if it is it MUST be ignored:

Example 102. Changing Multiple Affiliations

<iq from="crone1@shakespeare.lit/desktop"
    id="affil7"
    to="darkcave@macbeth.shakespeare.lit"
    type="set">
  <query xmlns="http://jabber.org/protocol/muc#admin">
     <item nick="secondwitch"
           affiliation="owner">
        <reason>A worthy witch indeed!</reason>
     </item>
     <item jid="hag66@shakespeare.lit"
           affiliation="outcast"/>
  </query>
</iq>
    

The service MUST then send notice to all the occupants of the affiliation change:

Example 103. Service Sends Notice 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="owner"
          nick="secondwitch"
          role="moderator">
      <reason>A worthy witch indeed!</reason>
    </item>
  </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="outcast"
          nick="thirdwitch"
          role="none"/>
    <status code='301'/>
  </x>
</presence>
.
.
.
    

The service MUST then inform the admin or owner of success:

Example 104. Service Informs Admin/Owner of Success

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

An entity's affiliation can only be changed by an admin or owner whose affiliation is greater than their own. The exception is for owners, whose affiliation can be changed by another owner. If an owner tries to change their own affiliation and the room has no other owners, or if an occupant is not allowed to change an occupant's affiliation, the service MUST deny the request and return a <not-allowed/> error to the sender. The returned error <iq/> MUST only include the <item/> elements that caused the error as they appeared in the request:

Example 105. Error Changing Multiple Affiliations

<iq from="darkcave@macbeth.shakespeare.lit"
    id="affil7"
    to="crone1@shakespeare.lit/desktop"
    type="error">
  <query xmlns="http://jabber.org/protocol/muc#admin">
     <item jid="hag66@shakespeare.lit"
           affiliation="outcast"/>
  </query>
  <error code="405" type="cancel">
    <not-allowed xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
  </error>
</iq>
    

As in the basic affiliation change, if an occupant whose affiliation is not 'admin' or 'owner' tries to change another occupant's affiliation, a <forbidden/> error MUST be returned by the service. Since this is a not an admin or owner making the request, all of the <item/> elements MUST be returned because none of them will have taken affect.

9. Moderator Use Cases

A moderator has privileges to perform certain actions within the room (e.g., to change the roles of some occupants) but does not have rights to change persistent information about affiliations, which MAY be changed only by an admin (or owner). Exactly which actions may be performed by a moderator is subject to configuration. However, for the purposes of the MUC framework, moderators are stipulated to have privileges to perform the following actions:

  1. discover an occupant's full JID in a semi-anonymous room (occurs by default as shown above)
  2. modify the subject (defined above)
  3. kick a participant or visitor from the room (change an occupant's role to 'none')
  4. grant or revoke voice in a moderated room (change an occupant's role to 'participant' or 'visitor' respectively)

These features are covered in the use cases above. The specific use case is noted in parenthesis.

10. Admin Use Cases

A room administrator has privileges to modify persistent information about user affiliations (e.g., by banning users) and to grant and revoke moderator privileges, but does not have rights to change the defining features of the room, which are the sole province of the room owner. Exactly which actions MAY be performed by a room admin will be subject to configuration. However, for the purposes of the MUC framework, room admins are stipulated to have privileges to perform the following actions:

  1. ban a user from the room (change affiliation to 'outcast')
  2. modify the list of users who are banned from the room (affiliation list followed by setting multiple affiliations)
  3. grant or revoke membership (change affiliation to 'member' or 'none' respectively)
  4. modify the member list (affiliation list followed by setting multiple affiliations)
  5. grant or revoke moderator privileges (change role to 'moderator' or 'participant' respectively
  6. modify the list of moderators (role list followed by setting multiple roles)

The above actions are detailed in use cases that have already been described. Only use cases that have not been mentioned will follow.

10.1 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 106. 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>
</iq>
    

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 [14] as is done in Publish-Subscribe [15]) are out of scope for this JEP.

11. Owner Use Cases

Every room MUST have at least one owner, and that owner (or a successor) is a long-lived attribute of the room for as long as the room exists (e.g., the owner does not lose ownership on exiting a persistent room). This JEP assumes that the (initial) room owner is the individual who creates the room and that only a room owner has the right to change defining room configuration settings such as the room type. Ideally, room owners will be able to specify not only the room types (password-protected, members-only, etc.) but also certain attributes of the room as listed under the requirements section of this JEP. In addition, it would be good if an owner were able to specify the JIDs of other owners, but that shall be determined by the implementation.

In order to provide the necessary flexibility for a wide range of configuration options, Data Forms [16] shall be used for room configuration, triggered by use of the 'http://jabber.org/protocol/muc' namespace.

Note that the configuration options shown below address all of the features and room types listed in the requirements section of this JEP, but that the exact configuration options and form layout shall be determined by the implementation or specific deployment. Also, these are examples only and are not intended to define the only allowed or required configuration options for rooms. A given implementation or deployment MAY choose to provide many additional configuration options (profanity filters, setting the default language for a room, message logging, etc., which MAY include items defined in other FORM_TYPEs), which is why the use of the jabber:x:data protocol is valuable here.

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

Example 107. Service Informs User of Inability to Create 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>
  

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

11.1 Creating a Room

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

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

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

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

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

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

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

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

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

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

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

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

If the room does not yet exist, the service SHOULD create the room (subject to local policies regarding room creation), assign the bare JID of the requesting user as the owner, add the owner to the room, and acknowledge successful creation of the room.

Example 109. Service Creates Room

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

The initial room owner can request an instant room by sending the following XML:

Example 110. Owner Requests Instant Room

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

If the initial room owner wants to create and configure a reserved room, the room owner MUST request an initial configuration form for the room by not including empty data form in the creation request:

Example 111. Owner Requests Configuration Form

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

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

Example 112. Service Sends Configuration Form

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

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

Example 113. Service Informs Owner that No Configuration is Possible

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

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

Example 114. Owner Submits Configuration Form

<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
          hecate@shakespeare.lit
        </value>
      </field>
    </x>
  </query>
</iq>
    

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

Example 115. Service Informs New Room Owner of Success

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

Alternatively, the room owner can cancel the configuration process:

Example 116. Owner Cancels Initial Configuration

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

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

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

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

Example 117. Service Denies Access Because Room Does Not Yet Exist

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

11.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 "conversation", a room owner MUST request a new configuration form from the room by sending an IQ to room@service containing an empty <query/> element scoped by the 'http://jabber.org/protocol/muc#owner' namespace.

Example 118. 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 119. 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 120. 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 above.

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

Alternatively, the room owner MAY cancel the configuration process:

Example 121. 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 scoped 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 122. 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 scoped 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 123. 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 scoped 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 124. 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>
.
.
.
    

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

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

11.3 Destroying a Room

A room owner MUST be able to destroy a room that he or she has created, 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.

This JEP does not specify what if anything a compliant component implementation must do as a result of a room destruction request other than the foregoing. For example, if the room was defined as persistent, an implementation MAY choose to reserve the room ID or redirect enter requests to the alternate venue; 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 shall be provided in the <destroy/> element's 'jid' attribute (this is OPTIONAL). The reason for the room destruction shall be provided as the XML character data of a <reason/> child element of the <destroy/> element (this, too, is OPTIONAL). An OPTIONAL <password/> element can also be sent to tell the room's occupants the alternate venue's password.

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

Example 126. 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>
      <password>sofullofjest</password>
    </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. Also if a <password/> element was used to destroy the room, the service SHOULD also send the password for the alternate venue using a <password/> element outside of the <destroy/> element as shown:

Example 127. 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>
    <password>sofullofjest</password>
  </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>
    <password>sofullofjest</password>
  </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>
    <password>sofullofjest</password>
  </x>
</presence>
    

Example 128. 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 129. 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>
    

12. Error and Status Codes

The error codes associated with the 'http://jabber.org/protocol/muc#admin' namespace are fairly straightforward. However, in order to make it easier for client and component developers to understand the codes they need to send and receive, the table below provides a summary of all the error and status codes associated with the 'http://jabber.org/protocol/muc#user' namespace. For detailed information about mapping legacy error codes to XMPP-style error types and conditions, refer to Error Condition Mappings [17]; compliant implementations SHOULD support both legacy and XMPP error handling (no such requirement applies to MUC status codes).

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

Code Type Element Context Purpose
100 Status Message Entering a room Inform user that any occupant is allowed to see the user's full JID
101 Status Message (out of band) Affiliation change Inform user that his or her affiliation changed while not in the room
102 Status In-room message Configuration change Inform occupants that room now shows unavailable members
103 Status Message Configuration change Inform occupants that room now does not show unavailable members
104 Status Message Configuration change Inform occupants that some room configuration has changed
201 Status Presence Entering a room Inform user that a new room has been created
301 Status Presence Removal from room Inform user that he or she has been banned from the room
303 Status Presence Exiting a room Inform all occupants of new room nickname
307 Status Presence Removal from room Inform user that he or she has been kicked from the room
321 Status Presence Removal from room Inform user that he or she is being removed from the room because of an affiliation change
322 Status Presence Removal from room 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
332 Status Presence Removal from room Inform user that he or she is being removed from the room because of a system shutdown
401 Error Presence Entering a room Inform user that a password is required
403 Error Presence Entering a room Inform user that he or she is banned from the room
404 Error Presence Entering a room Inform user that the room does not exist
405 Error Presence Entering a room Inform user that room creation is restricted
407 Error Presence Entering a room Inform user that their affiliation is not 'member'
409 Error Presence Entering a room Inform user that his or her desired room nickname is taken
500 Error Presence Entering a room Inform user that the room is full

This JEP does not stipulate text messages associated with each error condition.

13. Security Considerations

No room entrance authentication method more secure than cleartext passwords is defined or required by this JEP. This is recognized to be sub-optimal; a future proposal will need to address this shortcoming.

14. IANA Considerations

This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [18].

15. Jabber Registrar Considerations

The Jabber Registrar [19] shall include the following information in its registries.

15.1 Protocol Namespaces

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

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

15.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, and the 'http://jabber.org/protocol/muc#plus' namespace used to differentiate from the original MUC. In addition, a MUC room SHOULD provide information when queried about the specific room features it implements, such as password protection and room moderation.

Registry Submission

<var>
  <name>http://jabber.org/protocol/muc</name>
  <desc>Multi-User Chat (MUC) namespace</desc>
  <doc>JEP-0045</doc>
</var>
<var>
  <name>http://jabber.org/protocol/muc#plus</name>
  <desc>Multi-User Chat+ (MUC) feature notification</desc>
  <doc>MUC+</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_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>
<var>
  <name>muc_rooms</name>
  <desc>List of MUC rooms (each as a separate item)</desc>
  <doc>JEP-0045</doc>
</var>
    

15.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 'http://jabber.org/protocol/muc#traffic' enables discovery of the namespaces that are allowed in traffic sent through a room.

15.5 Field Standardization

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

15.5.1 muc#register FORM_TYPE

Registry Submission

<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_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'/>
  <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_allow'
       type='boolean'
       label='Allow this person to register with the room?'>
</form_type>
      

15.5.2 muc#roomconfig FORM_TYPE

Registry Submission

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

15.5.3 muc#roominfo FORM_TYPE

Registry Submission

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

16. Business Rules

16.1 Room JIDs

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 XMPP Core [21]).

16.2 Message

  1. If an occupant wants to send a message to all other occupants, a compliant 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 compliant 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 compliant service receives a message directed to a room that does not exist or is locked, the service SHOULD return the message to the sender with a <item-not-found/> error.

  4. A compliant service SHOULD pass extended information (e.g., an XHTML version of the message body) through to occupants unchanged.

  5. A compliant client MUST NOT generate message events as specified in Message Events [22]; such message events are not intended for use in the context of groupchat.

16.3 Presence

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

  2. Only a component SHOULD generate extended presence information about roles, affiliations, full JIDs, or status codes scoped by the 'http://jabber.org/protocol/muc#user' namespace (based on information the component 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 compliant component receives such extended presence information from an occupant, it MUST NOT reflect it to other occupants. A client can generate extended presence information in 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 component SHOULD allow all other presence information to pass through, although it MAY choose to block extended presence information. Thus effectively clients can 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.

  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, compliant component 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 scoped 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 compliant service MUST send extended presence to a client even if the client did not send an empty <x/> element scoped by the 'http://jabber.org/protocol/muc' namespace on entering the room; naturally, a Jabber-compliant client MUST ignore such information if it does not understand it.

  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.

16.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 compliant 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 compliant client MUST send only the 'affiliation' attribute or the 'role' attribute in the <item/> element contained within an IQ set scoped 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 compliant 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 compliant client MUST include the 'nick' and 'role' attributes only; in IQ results regarding roles, a compliant 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 compliant client MUST include the 'jid' and 'affiliation' attributes only (with the value typically set to the bare JID); in IQ results regarding affiliations, a compliant service SHOULD NOT include the 'role' attribute, MUST include the 'affiliation' attribute and the 'jid' attribute (with the value typically set to the bare JID), and SHOULD include the 'nick' attribute (except if the affiliation is "outcast", since outcasts SHOULD NOT have reserved nicknames).

17. Implementation Notes

The following guidelines may assist client and component developers in creating compliant implementations.

17.1 Services

  1. In handling messages sent by visitors in a moderated room, a chatroom 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 chatroom 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 chatroom service MAY send a <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-compliant service.

  4. Out of courtesy, a chatroom service MAY send a <message/> outside the context of the room 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 chatroom 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 sent in the 'http://jabber.org/protocol/muc#user' namespace.

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

  7. A chatroom 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 chatroom 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 as opposed to a human user.

  9. A chatroom 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 chatroom service MAY choose to send a message outside the context of the room to any user who is affected by a change in affiliation (e.g., if a user becomes an admin or owner). Such a message could include an appropriate status code in an extended child element scoped by the muc#user namespace.

  11. A chatroom 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.).

  12. A chatroom service MAY choose to discard extended presence information that is attached to <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 below.

  13. A chatroom 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 [23]. 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 below.

17.1.1 Allowable Traffic

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

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

Example 130. User Queries Service Regarding Allowable Namespaces

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

Example 131. Service Returns Allowable Namespaces

<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'>
    <feature var='http://jabber.org/protocol/xhtml-im'/>
    <feature var='jabber:x:roster/'/>
  </query>
</iq>
      

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

17.2.1 IRC Command Mapping

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

Table 9: IRC Command Mapping

Command Function MUC protocol
/ban <roomnick> [comment] bans user with that roomnick from this room (client translates roomnick to jid)

<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>
          
/invite <jid> [comment] invites jid to this room

<message to='room@service'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite to='jid'>
      <reason>comment</reason>
    </invite>
  </x>
</message>
          
/join <roomname> [pass] joins room on this service (roomnick is same as nick in this room)

<presence to='room@service/nick'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <password>pass</password>
  </x>
</presence>
          
/kick <roomnick> [comment] kicks user with that roomnick from this room

<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>
          
/msg <roomnick> <foo> sends private message "foo" to roomnick

<message to='room@service/nick'>
  <body>foo</body>
</message>
          
/nick <newnick> changes nick in this room to "newnick"

<presence to='room@service/newnick'/>
          
/part [comment] exits this room (some IRC clients also support /leave)

<presence to='room@service/nick'
          type='unavailable'>
  <status>comment</status>
</presence>
          
/topic <foo> changes subject of this room to "foo"

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

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

Note: Many Jabber clients also implement a '/me ' command, where the command is followed by a verb or verb phrase (e.g., '/me laughs'). This command does not result in any MUC or IRC protocol action and is therefore not shown in the table. Instead, the message is sent as-is (e.g., <message><body>/me laughs</body></message>) and the receiving client performs string-matching on the character data of the <message/>'s <body/> element to determine if the message begins with the string '/me '; if it does the receiving client will show the message in a special format, usually italicized text sometimes prepended by the "*" character:

* stpeter laughs

18. XML Schemas

18.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-0xxx: http://www.jabber.org/jeps/jep-0xxx.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:element ref='unique-room' minOccurs='0' maxOccurs='1'/>
      </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:element name='unique-room'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='xs:string'>
	  <xs:attribute name='expires' type='xs:dateTime' use='optional'/>
	</xs:extension>
    </xs:complexType>
  </xs:element>

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

</xs:schema>
    

18.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-0xxx: http://www.jabber.org/jeps/jep-0xxx.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'/>
        <xs:element ref='item' minOccurs='0'/>
	<xs:element ref='continue' minOccurs='0' maxOccurs='1'/>
        <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:element ref='continue' 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:sequence>
      <xs:attribute name='affiliation' use='required'>
        <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:enumeration value='100'/>
            <xs:enumeration value='201'/>
            <xs:enumeration value='301'/>
            <xs:enumeration value='303'/>
            <xs:enumeration value='307'/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
    </xs:complexType>
  </xs:element>

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

  <xs:element name='continue' type='empty'/>

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

</xs:schema>
    

18.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-0xxx: http://www.jabber.org/jeps/jep-0xxx.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='query'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='item' minOccurs='0' 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>
    

18.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:element name='query'>
    <xs:complexType>
      <xs:choice>
        <xs:element ref='item' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='destroy' minOccurs='0'/>
      </xs:choice>
    </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='required'>
        <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: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='destroy'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='reason' minOccurs='0'/>
        <xs:element ref='password' minOccurs='0'/>
      </xs:sequence>
      <xs:attribute name='jid' type='xs:string' use='optional'/>
    </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>
    

19. Acknowledgements

Nolan Eakins would like to thank Peter Saint-André for being to busy and for writing a JEP that needed to be reworked. He would also like to thank JD Conley for suggesting the protocol for retrieving mixed role/affiliation lists, the unique room reservation use case, multiple invites, and a better name.

Original MUC Acks: Peter Saint-André would like to thank the following individuals for their many helpful comments on various drafts of JEP-0045: David Sutton, Peter Millard, Joe Hildebrand, Craig Kaes, Alexey Shchepin, David Waite, Jean-Louis Seguineau, Jacek Konieczny, Gaston Dombiak, and many others in the jdev@conference.jabber.org conference room and on the Standards-JIG mailing list.


Notes

1. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.

2. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.

3. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.

4. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.

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

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

7. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Revision History

Version 0.0.1 (2005-01-10)

Initial version. (nde)


END