JEP-0XXX: Multi-User Chat+

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

There are four defined roles that an occupant MAY have:

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

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

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

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

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

5.2 Affiliations

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

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

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

If a user without a defined affiliation enters a room, the user's affiliation is defined as "none"; however, this affiliation does not persist across visits.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.4 Exiting a Room

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

Example 34. Occupant Exits a Room

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

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

Example 35. Service Sends Presence Related to Departure of Occupant

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

Presence stanzas of type "unavailable" reflected by the room MUST contain extended presence information about roles and affiliations, and MAY also contain normal <show/> and <status/> information (this last enables occupants to provide custom exit messages if desired).

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.