XEP-0045: Multi-User Chat

4.1 General Terms¶

4.2 Room Types¶

4.3 Dramatis Personae¶

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, represented here as the "[email protected]" chatroom. The characters are as follows:

5.1 Roles¶

The following roles are defined:

Roles are temporary in that they do not necessarily persist across a user's visits to the room and MAY change during the course of an occupant's visit to the room. An implementation MAY persist roles across visits and SHOULD do so for moderated rooms (since the distinction between visitor and participant is critical to the functioning of a moderated room).

There is no one-to-one mapping between roles and affiliations (e.g., a member could be a participant or a visitor).

A moderator is the most powerful role within the context of the room, and can to some extent manage other occupants' roles in the room. A participant has fewer privileges than a moderator, although he or she always has the right to speak. A visitor is a more restricted role within the context of a moderated room, since visitors are not allowed to send messages to all occupants (depending on room configuration, it is even possible that visitors' presence will not be broadcasted to the room).

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 (if the room is configured to broadcast presence for a given role).

5.2 Affiliations¶

The following affiliations are defined:

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

Support for the owner affiliation is REQUIRED. Support for the admin, member, and outcast affiliations is RECOMMENDED. (The "None" affiliation is the absence of an affiliation.)

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

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

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

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

6.1 Discovering a MUC Service¶

An entity often discovers a MUC service by sending a Service Discovery items ("disco#items") request to its own server.

<iq from='[email protected]/pda'
    id='h7ns81g'
    to='shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>

The server then returns the services that are associated with it.

<iq from='shakespeare.lit'
    id='h7ns81g'
    to='[email protected]/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='chat.shakespeare.lit'
          name='Chatroom Service'/>
  </query>
</iq>

6.2 Discovering the Features Supported by a MUC Service¶

An entity may wish to discover if a service implements the Multi-User Chat protocol; in order to do so, it sends a service discovery information ("disco#info") query to the MUC service's JID.

<iq from='[email protected]/pda'
    id='lx09df27'
    to='chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

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

<iq from='chat.shakespeare.lit'
    id='lx09df27'
    to='[email protected]/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='conference'
        name='Shakespearean Chat Service'
        type='text'/>
    <feature var='http://jabber.org/protocol/muc'/>
  </query>
</iq>

6.3 Discovering Rooms¶

The service discovery items ("disco#items") protocol enables an entity to query a service for a list of associated items, which in the case of a chat service would consist of the specific chat rooms hosted by the service.

<iq from='[email protected]/pda'
    id='zb8q41f4'
    to='chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>

The service SHOULD return a full list of the public rooms it hosts (i.e., not return any rooms that are hidden).

<iq from='chat.shakespeare.lit'
    id='zb8q41f4'
    to='[email protected]/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='[email protected]'
          name='A Lonely Heath'/>
    <item jid='[email protected]'
          name='A Dark Cave'/>
    <item jid='[email protected]'
          name='The Palace'/>
    <item jid='[email protected]'
          name='Macbeth&apos;s Castle'/>
  </query>
</iq>

If the full list of rooms is large (see Service Discovery (XEP-0030) [9] for details), the service MAY return only a partial list of rooms. If it does so, it SHOULD include a <set/> element qualified by the 'http://jabber.org/protocol/rsm' namespace (as defined in Result Set Management (XEP-0059) [10]) to indicate that the list is not the full result set.

<iq from='chat.shakespeare.lit'
    id='hx51v49s'
    to='[email protected]/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='[email protected]'/>
    <item jid='[email protected]'/>
    <item jid='[email protected]'/>
    <item jid='[email protected]'/>
    <item jid='[email protected]'/>
    <item jid='[email protected]'/>
    <item jid='[email protected]'/>
    <item jid='[email protected]'/>
    <item jid='[email protected]'/>
    <item jid='[email protected]'/>
    <set xmlns='http://jabber.org/protocol/rsm'>
      <first index='0'>[email protected]</first>
      <last>[email protected]</last>
      <count>37</count>
    </set>
  </query>
</iq>

6.4 Querying for Room Information¶

Using the disco#info protocol, an entity may also query a specific chat room for more detailed information about the room. An entity SHOULD do so before entering a room in order to determine the privacy and security profile of the room configuration (see the Security Considerations for details).

<iq from='[email protected]/pda'
    id='ik3vs715'
    to='[email protected]'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

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

<iq from='[email protected]'
    id='ik3vs715'
    to='[email protected]/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#stable_id'/>
    <feature var='muc_passwordprotected'/>
    <feature var='muc_hidden'/>
    <feature var='muc_temporary'/>
    <feature var='muc_open'/>
    <feature var='muc_unmoderated'/>
    <feature var='muc_nonanonymous'/>
  </query>
</iq>

Note: The room SHOULD return the materially-relevant features it supports, such as password protection and room moderation (these are listed fully in the feature registry maintained by the XMPP Registrar; see also the XMPP Registrar section of this document).

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

<iq from='[email protected]'
    id='ik3vs715'
    to='[email protected]/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='conference'
        name='A Dark Cave'
        type='text'/>
    <feature var='http://jabber.org/protocol/muc'/>
    <feature var='muc_passwordprotected'/>
    <feature var='muc_hidden'/>
    <feature var='muc_temporary'/>
    <feature var='muc_open'/>
    <feature var='muc_unmoderated'/>
    <feature var='muc_nonanonymous'/>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>http://jabber.org/protocol/muc#roominfo</value>
      </field>
      <field var='muc#roominfo_description'
             label='Description'>
        <value>The place for all good witches!</value>
      </field>
      <field var='muc#roominfo_contactjid'
             label='Contact Addresses'>
        <value>[email protected]</value>
      </field>
      <field var='muc#roominfo_subject'
             label='Current Discussion Topic'>
        <value>Spells</value>
      </field>
      <field var='muc#roomconfig_changesubject'
             label='Subject can be modified'>
        <value>true</value>
      </field>
      <field var='muc#roominfo_occupants'
             label='Number of occupants'>
        <value>3</value>
      </field>
      <field var='muc#roominfo_ldapgroup'
             label='Associated LDAP Group'>
        <value>cn=witches,dc=shakespeare,dc=lit</value>
      </field>
      <field var='muc#roominfo_lang'
             label='Language of discussion'>
        <value>en</value>
      </field>
      <field var='muc#roominfo_logs'
             label='URL for discussion logs'>
        <value>http://www.shakespeare.lit/chatlogs/coven/</value>
      </field>
      <field var='muc#maxhistoryfetch'
             label='Maximum Number of History Messages Returned by Room'>
        <value>50</value>
      </field>
      <field var='muc#roominfo_pubsub'
             label='Associated pubsub node'>
        <value>xmpp:pubsub.shakespeare.lit?;node=the-coven-node</value>
      </field>
    </x>
  </query>
</iq>

Some extended room information is dynamically generated (e.g., the URL for discussion logs, which may be based on service-wide configuration), whereas other information is based on the more-stable room configuration, which is why any field defined for the muc#roomconfig FORM_TYPE can be included in the extended service discovery fields (as shown above for the "muc#roomconfig_changesubject" field).

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

6.5 Querying for Room Items¶

An entity MAY also query a specific chat room for its associated items:

<iq from='[email protected]/pda'
    id='kl2fax27'
    to='[email protected]'
    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. Implementations and deployments are advised to turn off such information sharing by default.

<iq from='[email protected]'
    id='kl2fax27'
    to='[email protected]/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='[email protected]/firstwitch'/>
    <item jid='[email protected]/secondwitch'/>
  </query>
</iq>

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

If the list of occupants is private, the room MUST return an empty <query/> element, in accordance with Service Discovery (XEP-0030) [9].

<iq from='[email protected]'
    id='kl2fax27'
    to='[email protected]/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>

6.6 Querying a Room Occupant¶

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

6.7 Discovering Client Support for MUC¶

An entity might want to discover if one of the entity's contacts supports the Multi-User Chat protocol (e.g., before attempting to invite the contact to a room). This can be done using Service Discovery.

<iq from='[email protected]/pda'
    id='yh2fs843'
    to='[email protected]/laptop'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

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

<iq from='[email protected]/laptop'
    id='yh2fs843'
    to='[email protected]/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>

An entity 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'.

<iq from='[email protected]/pda'
    id='gp7w61v3'
    to='[email protected]/laptop'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'
         node='http://jabber.org/protocol/muc#rooms'/>
</iq>

<iq from='[email protected]/laptop'
    id='gp7w61v3'
    to='[email protected]/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'
         node='http://jabber.org/protocol/muc#rooms'>
    <item jid='[email protected]'/>
    <item jid='[email protected]'/>
  </query>
</iq>

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

    ...
    <item jid='[email protected]'
          name='secondwitch'/>
    ...

If this information is private, the user MUST return an empty <query/> element, in accordance with Service Discovery (XEP-0030) [9].

7.1 Order of Events¶

The order of events involved in joining a room needs to be consistent so that clients can know which events to expect when. After a client sends presence to join a room, the MUC service MUST send it events in the following order:

1. In-room presence from other occupants
2. In-room presence from the joining entity itself (so-called "self-presence")
3. Room history (if any)
4. The room subject
5. Live messages, presence updates, new user joins, etc.

7.2 Entering a Room¶

<presence
    from='[email protected]/pda'
    id='n13mt3l'
    to='[email protected]/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

<presence
    from='[email protected]'
    id='273hs51g'
    to='[email protected]/pda'
    type='error'>
  <error by='[email protected]' type='modify'>
    <jid-malformed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>

<presence
    from='[email protected]/firstwitch'
    id='3DCB0401-D7CF-4E31-BE05-EDF8D057BFBD'
    to='[email protected]/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='owner' role='moderator'/>
  </x>
</presence>

<presence
    from='[email protected]/secondwitch'
    id='C2CD9EE3-8421-431E-854A-A2AD0CE2E23D'
    to='[email protected]/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin' role='moderator'/>
  </x>
</presence>

<presence
    from='[email protected]/thirdwitch'
    id='27C55F89-1C6A-459A-9EB5-77690145D624'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
  </x>
</presence>

<presence
    from='[email protected]/thirdwitch'
    id='9E757BAE-8AC8-4093-AA9C-407F6AEF15D6'
    to='[email protected]/laptop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
  </x>
</presence>

<presence
    from='[email protected]/thirdwitch'
    id='026B3509-2CCE-4D69-96D6-25F41FFDC408'
    to='[email protected]/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
    <status code='110'/>
  </x>
</presence>

<presence
    from='[email protected]/thirdwitch'
    id='n13mt3l'
    to='[email protected]/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
    <status code='110'/>
    <status code='210'/>
  </x>
</presence>

<presence
    from='[email protected]/thirdwitch'
    id='17232D15-134F-43C8-9A29-61C20A64B236'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none'
          jid='[email protected]/pda'
          role='participant'/>
  </x>
</presence>

[ ... ]

<presence
    from='[email protected]/thirdwitch'
    id='n13mt3l'
    to='[email protected]/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
    <status code='100'/>
    <status code='110'/>
    <status code='210'/>
  </x>
</presence>

<presence
    from='[email protected]/thirdwitch'
    id='n13mt3l'
    to='[email protected]/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error by='[email protected]' type='auth'>
    <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>

<presence
    from='[email protected]/pda'
    id='djn4714'
    to='[email protected]/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <password>cauldronburn</password>
  </x>
</presence>

<presence
    from='[email protected]/thirdwitch'
    id='n13mt3l'
    to='[email protected]/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error by='[email protected]' type='auth'>
    <registration-required xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>

<presence
    from='[email protected]/thirdwitch'
    id='n13mt3l'
    to='[email protected]/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error by='[email protected]' type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>

<presence
    from='[email protected]/thirdwitch'
    id='n13mt3l'
    to='[email protected]/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error by='[email protected]' type='cancel'>
    <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>

<presence
    from='[email protected]/thirdwitch'
    id='n13mt3l'
    to='[email protected]/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error by='[email protected]' type='wait'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>

<presence
    from='[email protected]/thirdwitch'
    id='n13mt3l'
    to='[email protected]/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error by='[email protected]' type='cancel'>
    <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>

<presence
    from='[email protected]/thirdwitch'
    id='n13mt3l'
    to='[email protected]/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
    <status code='100'/>
    <status code='110'/>
    <status code='170'/>
    <status code='210'/>
  </x>
</presence>

<message
    from='[email protected]/firstwitch'
    id='162BEBB1-F6DB-4D9A-9BD8-CFDCC801A0B2'
    to='[email protected]/broom'
    type='groupchat'>
  <body>Thrice the brinded cat hath mew'd.</body>
  <delay xmlns='urn:xmpp:delay'
     from='[email protected]'
     stamp='2002-10-13T23:58:37Z'/>
</message>

<message
    from='[email protected]/secondwitch'
    id='90057840-30FD-4141-AA44-103EEDF218FC'
    to='[email protected]/broom'
    type='groupchat'>
  <body>Thrice and once the hedge-pig whined.</body>
  <delay xmlns='urn:xmpp:delay'
     from='[email protected]'
     stamp='2002-10-13T23:58:43Z'/>
</message>

<message
    from='[email protected]/thirdwitch'
    id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
    to='[email protected]/broom'
    type='groupchat'>
  <body>Harpier cries 'Tis time, 'tis time.</body>
  <delay xmlns='urn:xmpp:delay'
     from='[email protected]'
     stamp='2002-10-13T23:58:49Z'/>
</message>

<message
    from='[email protected]/firstwitch'
    id='162BEBB1-F6DB-4D9A-9BD8-CFDCC801A0B2'
    to='[email protected]/broom'
    type='groupchat'>
  <body>Thrice the brinded cat hath mew'd.</body>
  <delay xmlns='urn:xmpp:delay'
     from='[email protected]'
     stamp='2002-10-13T23:58:37Z'/>
  <addresses xmlns='http://jabber.org/protocol/address'>
    <address type='ofrom' jid='[email protected]/desktop'/>
  </addresses>
</message>

<presence
    from='[email protected]/pda'
    id='n13mt3l'
    to='[email protected]/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <history maxchars='65000'/>
  </x>
</presence>

<presence
    from='[email protected]/pda'
    id='n13mt3l'
    to='[email protected]/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <history maxstanzas='20'/>
  </x>
</presence>

<presence
    from='[email protected]/pda'
    id='n13mt3l'
    to='[email protected]/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <history seconds='180'/>
  </x>
</presence>

<presence
    from='[email protected]/pda'
    id='n13mt3l'
    to='[email protected]/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <history since='1970-01-01T00:00:00Z'/>
  </x>
</presence>

<presence
    from='[email protected]/pda'
    id='n13mt3l'
    to='[email protected]/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <history maxchars='0'/>
  </x>
</presence>

<message
    from='[email protected]/secondwitch'
    id='F437C672-D438-4BD3-9BFF-091050D32EE2'
    to='[email protected]/desktop'
    type='groupchat'>
  <subject>Fire Burn and Cauldron Bubble!</subject>
  <delay xmlns='urn:xmpp:delay' from='[email protected]' stamp='1610-04-20T00:00:00Z'/>
</message>

<message
    from='[email protected]/secondwitch'
    id='F437C672-D438-4BD3-9BFF-091050D32EE2'
    to='[email protected]/desktop'
    type='groupchat'>
  <subject></subject>
</message>

<presence
    from='[email protected]/pda'
    id='ng91xs69'
    to='[email protected]/thirdwitch'/>

<presence
    from='[email protected]/thirdwitch'
    to='[email protected]/pda'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'>
      <reason>You are not in the room.</reason>
    </item>
    <status code='110'/>
    <status code='307'/>
    <status code='333'/>
  </x>
</presence>

7.3 Occupant Modification of the Room Subject¶

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

7.4 Sending a Message to All Occupants¶

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

<message
    from='[email protected]/pda'
    id='hysf1v37'
    to='[email protected]'
    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) and the message does not violate any service-level or room-level policies (e.g., policies regarding message content or size), the service MUST change the 'from' attribute to the sender's occupant JID and reflect the message out to the full JID of each occupant.

<message
    from='[email protected]/thirdwitch'
    id='hysf1v37'
    to='[email protected]/desktop'
    type='groupchat'>
  <body>Harpier cries: 'tis time, 'tis time.</body>
</message>
<message
    from='[email protected]/thirdwitch'
    id='hysf1v37'
    to='[email protected]/laptop'
    type='groupchat'>
  <body>Harpier cries: 'tis time, 'tis time.</body>
</message>
<message
    from='[email protected]/thirdwitch'
    id='hysf1v37'
    to='[email protected]/pda'
    type='groupchat'>
  <body>Harpier cries: 'tis time, 'tis time.</body>
</message>

The service SHOULD reflect the message with the same 'id' that was generated by the client, to allow clients to track their outbound messages. If the client did not provide an 'id', the server MAY generate an 'id' and use it for all reflections of the same message (e.g. using a UUID as defined in RFC 4122 [18]).

Note: the requirement to reflect the 'id' attribute was added in version 1.31 of this XEP. Servers following the new specification SHOULD advertise that with a disco info feature of 'http://jabber.org/protocol/muc#stable_id' on both the service domain and on individual MUCs, so that clients can check for support.

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

7.5 Sending a Private Message¶

Since each occupant has its own occupant JID, an occupant can send a "private message" to a selected occupant via the service by sending a message to the intended recipient's occupant JID. The message type SHOULD be "chat" and MUST NOT be "groupchat", but MAY be left unspecified (i.e., a normal message). This privilege is controlled by the "muc#roomconfig_allowpm" room configuration option.

To allow for proper synchronization of these messages to the user's other clients by Message Carbons (XEP-0280) [19], the sending client SHOULD add an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace to the message.

Note: because this requirement was only added in revision 1.28 of this XEP, receiving entities MUST NOT rely on the existence of the <x/> element on private messages for proper processing.

<message
    from='[email protected]/laptop'
    id='hgn27af1'
    to='[email protected]/firstwitch'
    type='chat'>
  <body>I'll give thee a wind.</body>
  <x xmlns='http://jabber.org/protocol/muc#user' />
</message>

The service is responsible for changing the 'from' address to the sender's occupant JID and delivering the message to the intended recipient's full JID. The service SHOULD add the <x/> element if the message does not contain it already.

<message
    from='[email protected]/secondwitch'
    id='hgn27af1'
    to='[email protected]/desktop'
    type='chat'>
  <body>I'll give thee a wind.</body>
  <x xmlns='http://jabber.org/protocol/muc#user' />
</message>

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

<message
    from='[email protected]/laptop'
    id='bx71f29k'
    to='[email protected]/firstwitch'
    type='groupchat'>
  <body>I'll give thee a wind.</body>
</message>

<message
    from='[email protected]/firstwitch'
    id='bx71f29k'
    to='[email protected]/laptop'
    type='error'>
  <body>I'll give thee a wind.</body>
  <error by='[email protected]' type='modify'>
    <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</message>

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

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

7.6 Changing Nickname¶

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

<presence
    from='[email protected]/pda'
    id='ifd1c35'
    to='[email protected]/oldhag'/>

The service then sends two presence stanzas to the full JID of each occupant (including the occupant who is changing his or her room nickname), one of type "unavailable" for the old nickname and one indicating availability for the new nickname.

The unavailable presence MUST contain the following as extended presence information in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace:

• The new nickname (in this case, nick='oldhag')
• A status code of 303

This enables the recipients to correlate the old roomnick with the new roomnick.

<presence
    from='[email protected]/thirdwitch'
    id='5C1B95B3-7CCC-4422-A952-8885A050BDE9'
    to='[email protected]/desktop'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/pda'
          nick='oldhag'
          role='participant'/>
    <status code='303'/>
  </x>
</presence>
<presence
    from='[email protected]/thirdwitch'
    id='B0E6ABD5-575D-42F0-8242-569004D88F73'
    to='[email protected]/laptop'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/pda'
          nick='oldhag'
          role='participant'/>
    <status code='303'/>
  </x>
</presence>
<presence
    from='[email protected]/thirdwitch'
    id='DC352437-C019-40EC-B590-AF29E879AF98'
    to='[email protected]/pda'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/pda'
          nick='oldhag'
          role='participant'/>
    <status code='303'/>
    <status code='110'/>
  </x>
</presence>

<presence
    from='[email protected]/oldhag'
    id='19E41EB3-3F4C-444F-8A1B-713A8860980C'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/pda'
          role='participant'/>
  </x>
</presence>
<presence
    from='[email protected]/oldhag'
    id='79225CEA-F610-49BE-9B97-FEFA8737185B'
    to='[email protected]/laptop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/pda'
          role='participant'/>
  </x>
</presence>
<presence
    from='[email protected]/oldhag'
    id='5B4F27A4-25ED-43F7-A699-382C6B4AFC67'
    to='[email protected]/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/pda'
          role='participant'/>
    <status code='110'/>
  </x>
</presence>

If the service modifies the user's nickname in accordance with local service policies, it MUST include a MUC status code of 210 in the presence stanza sent to the user. An example follows (here the service changes the nickname to all lowercase).

<presence
    from='[email protected]/pda'
    id='nx6z2v5'
    to='[email protected]/OldHag'/>

<presence
    from='[email protected]/oldhag'
    id='D0E2B666-3373-42C9-B726-D52C40A48383'
    to='[email protected]/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/pda'
          role='participant'/>
    <status code='110'/>
    <status code='210'/>
  </x>
</presence>

If the user attempts to change his or her room nickname to a room nickname that is already in use by another user (or that is reserved by another user 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:

<presence
    from='[email protected]/thirdwitch'
    id='ifd1c35'
    to='[email protected]/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error by='[email protected]' type='cancel'>
    <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>

However, if the bare JID <[email protected]> of the present occupant matches the bare JID of the user seeking to change his or her nickname, then the service MAY allow the nickname change. See the Nickname Conflict section of this document for details.

If the user attempts to change their room nickname but nicknames are "locked down", the service MUST either deny the nickname change request and return a presence stanza of type "error" with a <not-acceptable/> error condition:

<presence
    from='[email protected]/thirdwitch'
    id='ifd1c35'
    to='[email protected]/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error by='[email protected]' type='cancel'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>

The user SHOULD then discover its reserved nickname as specified in the Discovering Reserved Room Nickname section of this document.

7.7 Changing Availability Status¶

In text 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 XMPP, 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 updated presence to its <room@service/nick>.

<presence
    from='[email protected]/laptop'
    id='kr7v143h'
    to='[email protected]/oldhag'>
  <show>xa</show>
  <status>gone where the goblins go</status>
</presence>

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

<presence
    from='[email protected]/secondwitch'
    id='86E11ABF-26BC-46F1-AD3B-F5E54F3C1EE5'
    to='[email protected]/desktop'>
  <show>xa</show>
  <status>gone where the goblins go</status>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin'
          jid='[email protected]/laptop'
          role='moderator'/>
  </x>
</presence>

[ ... ]

7.8 Inviting Another User to a Room¶

There are two ways of inviting another user to a room: direct invitations and mediated invitations.

Direct invitations were the original method used in the early Jabber community's "groupchat 1.0" protocol. Mediated invitations were added in Multi-User Chat as a way to handle invitations in the context of members-only rooms (so that the room could exercise control over the issuance of invitations). The existence of two different invitation methods might cause confusion among client developers. Because the room needs to be involved in the invitation process only for members-only rooms, because members-only rooms are relatively rare, and because mediated invitations do not work when Privacy Lists (XEP-0016) [20] or similar technologies are used to block communication from entities not in a user's roster, client developers are encouraged to use direct invitations for all other room types.

<message
    from='[email protected]/desktop'
    id='nzd143v8'
    to='[email protected]'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite to='[email protected]'>
      <reason>
        Hey Hecate, this is the place for all good witches!
      </reason>
    </invite>
  </x>
</message>

<message
    from='[email protected]'
    id='nzd143v8'
    to='[email protected]'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite from='[email protected]/desktop'>
      <reason>
        Hey Hecate, this is the place for all good witches!
      </reason>
    </invite>
    <password>cauldronburn</password>
  </x>
</message>

<message
    from='[email protected]/broom'
    id='jk2vs61v'
    to='[email protected]'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <decline to='[email protected]'>
      <reason>
        Sorry, I'm too busy right now.
      </reason>
    </decline>
  </x>
</message>

<message
    from='[email protected]'
    id='jk2vs61v'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <decline from='[email protected]'>
      <reason>
        Sorry, I'm too busy right now.
      </reason>
    </decline>
  </x>
</message>

7.9 Converting a One-to-One Chat Into a Multi-User Conference¶

Sometimes it is desirable to convert a one-to-one chat into a multi-user conference. The process is as follows.

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

<message
    from='[email protected]/desktop'
    id='mjs51f36'
    to='[email protected]/laptop'
    type='chat'>
  <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
  <body>Thrice the brinded cat hath mew'd.</body>
</message>

<message
    from='[email protected]/laptop'
    id='l9ij1f3h'
    to='[email protected]/desktop'
    type='chat'>
  <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
  <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 does the following:

1. Creates a new multi-user chatroom
2. Sends history of the one-to-one chat to the room (this is purely discretionary; however, because it might cause information leakage, the client ought to warn the user before doing so)
3. Sends an invitation to the second person and the third person, including a <continue/> element (optionally including a 'thread' attribute).

Note: The new room SHOULD be non-anonymous and MAY be an instant room as specified in the Creating an Instant Room section of this document.

Note: If the one-to-one chat messages included a <thread/> element, the person who creates the room SHOULD include the ThreadID with the history messages, specify the ThreadID in the invitations as the value of the <continue/> element's 'thread' attribute, and include the ThreadID in any new messages sent to the room. Use of ThreadIDs is RECOMMENDED because it helps to provide continuity between the one-to-one chat and the multi-user chat.

<presence
    from='[email protected]/desktop'
    to='[email protected]/firstwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

<presence
    from='[email protected]/firstwitch'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='owner' role='moderator'/>
    <status code='110'/>
  </x>
</presence>

<message
    from='[email protected]/desktop'
    id='b4va73n0'
    to='[email protected]'
    type='groupchat'>
  <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
  <body>Thrice the brinded cat hath mew'd.</body>
  <delay xmlns='urn:xmpp:delay'
     from='[email protected]/desktop'
     stamp='2004-09-29T01:54:37Z'/>
</message>

<message
    from='[email protected]/desktop'
    id='i4hs759k'
    to='[email protected]'
    type='groupchat'>
  <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
  <body>Thrice and once the hedge-pig whined.</body>
  <delay xmlns='urn:xmpp:delay'
     from='[email protected]/desktop'
     stamp='2004-09-29T01:55:21Z'/>
</message>

Note: Use of the Delayed Delivery protocol enables the room creator to specify the datetime of each message from the one-to-one chat history (via the 'stamp' attribute), as well as the JID of the original sender of each message (via the 'from' attribute); note well that the 'from' here is not the room itself, since the originator of the message is the delaying party. The room creator might send the complete one-to-one chat history before inviting additional users to the room, and 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 might want to send the history over a few seconds rather than all at once (to avoid triggering rate limits). The service SHOULD NOT add its own delay elements (as described in the Discussion History section of this document) to prior chat history messages received from the room owner.

<message
    from='[email protected]/desktop'
    id='gl3s85n7'
    to='[email protected]'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite to='[email protected]/laptop'>
      <reason>This coven needs both wiccarocks and hag66.</reason>
      <continue thread='e0ffe42b28561960c6b12b944a092794b9683a38'/>
    </invite>
    <invite to='[email protected]'>
      <reason>This coven needs both wiccarocks and hag66.</reason>
      <continue thread='e0ffe42b28561960c6b12b944a092794b9683a38'/>
    </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 its invitation to that user.

The invitations are delivered to the invitees:

<message
    from='[email protected]/firstwitch'
    id='DB0414CB-AFBA-407E-9DE3-0E014E84860F'
    to='[email protected]/laptop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite from='[email protected]'>
      <reason>This coven needs both wiccarocks and hag66.</reason>
      <continue thread='e0ffe42b28561960c6b12b944a092794b9683a38'/>
    </invite>
  </x>
</message>

<message
    from='[email protected]/firstwitch'
    id='89028D79-AB4C-44C0-BE81-B07607C2F4C2'
    to='[email protected]'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite from='[email protected]'>
      <reason>This coven needs both wiccarocks and hag66.</reason>
      <continue thread='e0ffe42b28561960c6b12b944a092794b9683a38'/>
    </invite>
  </x>
</message>

When the client being used by <[email protected]/laptop> receives the invitation, it can either auto-join the room or prompt the user whether to join (subject to user preferences) and then seamlessly convert the existing one-to-one chat window into a multi-user conferencing window:

<presence
    from='[email protected]/laptop'
    to='[email protected]/secondwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

<presence
    from='[email protected]/firstwitch'
    to='[email protected]/laptop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='owner' role='moderator'/>
  </x>
</presence>

<presence
    from='[email protected]/secondwitch'
    to='[email protected]/laptop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
  </x>
</presence>

<message
    from='[email protected]'
    id='67268D36-100C-457D-A769-8A3663BD1949'
    to='[email protected]/laptop'
    type='groupchat'>
  <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
  <body>Thrice the brinded cat hath mew'd.</body>
  <delay xmlns='urn:xmpp:delay'
     from='[email protected]'
     stamp='2004-09-29T01:54:37Z'/>
</message>

<message
    from='[email protected]'
    id='367DCF6B-0CB4-482D-A142-C0B9E08016B5'
    to='[email protected]/laptop'
    type='groupchat'>
  <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
  <body>Thrice and once the hedge-pig whined.</body>
  <delay xmlns='urn:xmpp:delay'
     from='[email protected]'
     stamp='2004-09-29T01:55:21Z'/>
</message>

7.10 Registering with a Room¶

An implementation MAY allow an unaffiliated user (in a moderated room, normally a participant) to register with a room; as a result, the user will become a member of the room and will have their preferred nickname reserved in the room. (Conversely, an implementation MAY restrict this privilege and allow only room admins to add new members.) In particular, it is not possible to join a members-only room without being on the member list, so an entity might need to request membership in order to join such a room.

If allowed, this functionality SHOULD be implemented by enabling a user to send a request for registration requirements to the room qualified by the 'jabber:iq:register' namespace as described in In-Band Registration (XEP-0077) [21]:

<iq from='[email protected]/pda'
    id='jw81b36f'
    to='[email protected]'
    type='get'>
  <query xmlns='jabber:iq:register'/>
</iq>

If the room does not exist, the service MUST return an <item-not-found/> error.

<iq from='[email protected]'
    id='jw81b36f'
    to='[email protected]/pda'
    type='error'>
  <error type='cancel'>
    <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</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.

<iq from='[email protected]'
    id='jw81b36f'
    to='[email protected]/pda'
    type='error'>
  <error type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

If the user is already registered, as described in In-Band Registration (XEP-0077) [21] the room MUST reply with an IQ stanza of type "result", which MUST contain an empty <registered/> element and SHOULD contain at least a <username/> element that specifies the user's registered nickname in the room.

<iq from='[email protected]'
    id='jw81b36f'
    to='[email protected]/pda'
    type='result'>
  <query xmlns='jabber:iq:register'>
    <registered/>
    <username>thirdwitch</username>
  </query>
</iq>

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

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

The user SHOULD then submit the form:

<iq from='[email protected]/pda'
    id='nv71va54'
    to='[email protected]'
    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:

<iq from='[email protected]'
    id='nv71va54'
    to='[email protected]/pda'
    type='error'>
  <error 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:

<iq from='[email protected]'
    id='nv71va54'
    to='[email protected]/pda'
    type='error'>
  <error type='cancel'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

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

<iq from='[email protected]'
    id='nv71va54'
    to='[email protected]/pda'
    type='error'>
  <error type='modify'>
    <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

Otherwise, the room MUST inform the user that the registration request was successfully received:

<iq from='[email protected]'
    id='nv71va54'
    to='[email protected]/pda'
    type='result'/>

After the user submits the form, the service MAY request that the submission be approved by a room admin/owner (see the Approving Registration Requests section of this document), MAY immediately add the user to the member list by changing the user's affiliation from "none" to "member", or MAY perform some service-specific checking (e.g., email verification).

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

<presence
    from='[email protected]/thirdwitch'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/pda'
          role='participant'/>
  </x>
</presence>

[ ... ]

If the user's nickname is modified by the service as a result of registration and the user is in the room, the service SHOULD include status code "210" in the updated presence notification that it sends to all users.

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 modify the user's nickname to be the registered nickname (instead of returning a <not-acceptable/> error) if the user attempts to join the room with a roomnick other than the user's registered roomnick (this enables a room to "lock down" roomnicks for consistent identification of occupants).

7.11 Getting the Member List¶

If allowed in accordance with room configuration, an occupant MAY be allowed to retrieve the list of room members. For details, see the Modifying the Member List section of this document.

7.12 Discovering Reserved Room Nickname¶

A user MAY have a reserved room nickname, for example through explicit room registration, database integration, or nickname "lockdown". A user SHOULD discover his or her reserved nickname before attempting to enter the room. This is done by sending a Service Discovery information request to the room JID while specifying a well-known Service Discovery node of "x-roomuser-item".

<iq from='[email protected]/pda'
    id='getnick1'
    to='[email protected]'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='x-roomuser-item'/>
</iq>

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

<iq from='[email protected]'
    id='getnick1'
    to='[email protected]/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 Service Discovery (XEP-0030) [9]).

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

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

7.13 Requesting Voice¶

It is not possible for a visitor to speak (i.e., send a message to all occupants) in a moderated room. To request voice, a visitor SHOULD send a <message/> stanza containing a data form to the room itself, where the data form contains only a "muc#role" field with a value of "participant".

<message from='[email protected]/pda'
         id='yd53c486'
         to='[email protected]'>
  <x xmlns='jabber:x:data' type='submit'>
    <field var='FORM_TYPE'>
      <value>http://jabber.org/protocol/muc#request</value>
    </field>
    <field var='muc#role'
           type='list-single'
           label='Requested role'>
      <value>participant</value>
    </field>
  </x>
</message>

The service then proceeds as described in the Approving Voice Requests section of this document.

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

<presence
    from='[email protected]/pda'
    to='[email protected]/thirdwitch'
    type='unavailable'/>

The service MUST then send a presence stanzas of type "unavailable" from the departing user's occupant JID to the departing occupant's full JIDs, including a status code of "110" to indicate that this notification is "self-presence":

<presence
    from='[email protected]/thirdwitch'
    to='[email protected]/pda'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/pda'
          role='none'/>
    <status code='110'/>
  </x>
</presence>

Note: The presence stanza used to exit a room MUST possess a 'type' attribute whose value is "unavailable". For further discussion, see the Presence business rules.

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

<presence
    from='[email protected]/thirdwitch'
    to='[email protected]/pda'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/pda'
          role='none'/>
    <status code='110'/>
  </x>
</presence>
<presence
    from='[email protected]/thirdwitch'
    to='[email protected]/desktop'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/pda'
          role='none'/>
  </x>
</presence>
<presence
    from='[email protected]/thirdwitch'
    to='[email protected]/laptop'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/pda'
          role='none'/>
  </x>
</presence>

Presence stanzas of type "unavailable" reflected by the room MUST contain extended presence information about roles and affiliations; in particular, the 'role' attribute MUST be set to a value of "none" to denote that the individual is no longer an occupant.

The occupant MAY include normal <status/> information in the unavailable presence stanzas; this enables the occupant to provide a custom exit message if desired:

<presence
    from='[email protected]/laptop'
    to='[email protected]/oldhag'
    type='unavailable'>
  <status>gone where the goblins go</status>
</presence>

Normal presence stanza generation rules apply as defined in XMPP IM [23], so that if the user sends a general unavailable presence stanza, the user's server will broadcast that stanza to the client's <room@service/nick>; as a result, there is no need for the leaving client to send directed unavailable presence to its occupant JID. It is possible that a user might not be able to gracefully exit the room by sending unavailable presence. If the user goes offline without sending unavailable presence, the user's server is responsible for sending unavailable presence on behalf of the user (in accordance with RFC 6121 [23]).

Note: See Ghost Users for suggestions regarding room occupants that appear to be present in the room but that are actually offline.

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

8.1 Modifying the Room Subject¶

A common feature of multi-user chat rooms is the ability to change the subject within the room.

By default, only users with a role of "moderator" SHOULD be allowed to change the subject in a room (although this is configurable, with the result that a mere participant or even visitor might be allowed to change the subject, as controlled by the "muc#roomconfig_changesubject" option).

The subject is changed by sending a message of type "groupchat" to the <room@service>, where the <message/> MUST contain a <subject/> element that specifies the new subject but MUST NOT contain a <body/> element (or a <thread/> element). In accordance with the core definition of XMPP, other child elements are allowed (although the entity that receives them might ignore them).

Note: A message with a <subject/> and a <body/> or a <subject/> and a <thread/> is a legitimate message, but it SHALL NOT be interpreted as a subject change.

<message
    from='[email protected]/laptop'
    id='lh2bs617'
    to='[email protected]'
    type='groupchat'>
  <subject>Fire Burn and Cauldron Bubble!</subject>
</message>

The MUC service MUST reflect the message to all other occupants with a 'from' address equal to the room JID or to the occupant JID that corresponds to the sender of the subject change:

<message
    from='[email protected]/secondwitch'
    id='5BCE07C5-0729-4353-A6A3-ED9818C9B498'
    to='[email protected]/desktop'
    type='groupchat'>
  <subject>Fire Burn and Cauldron Bubble!</subject>
</message>

[ ... ]

As explained under , when a new occupant joins the room the room SHOULD include the last subject change after the discussion history.

A MUC client that receives such a message MAY choose to display an in-room message, such as 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:

<message
    from='[email protected]/thirdwitch'
    id='lh2bs617'
    to='[email protected]/pda'
    type='error'>
  <subject>Fire Burn and Cauldron Bubble!</subject>
  <error by='[email protected]' type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</message>

In order to remove the existing subject but not provide a new subject (i.e., set the subject to be empty), the client shall send an empty <subject/> element (i.e., either "<subject/>" or "<subject></subject>").

<message
    from='[email protected]/laptop'
    id='uj3bs61g'
    to='[email protected]'
    type='groupchat'>
  <subject></subject>
</message>

8.2 Kicking an Occupant¶

A moderator has permissions to kick certain kinds of occupants from a room (which occupants are "kickable" depends on service provisioning, room configuration, and the moderator's affiliation -- see below). The kick is performed based on the occupant's room nickname and is completed by setting the role of a participant or visitor to a value of "none".

<iq from='[email protected]/pda'
    id='kick1'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='pistol' role='none'>
      <reason>Avaunt, you cullion!</reason>
    </item>
  </query>
</iq>

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

<presence
    from='[email protected]/pistol'
    to='[email protected]/harfleur'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'>
      <actor nick='Fluellen'/>
      <reason>Avaunt, you cullion!</reason>
    </item>
    <status code='110'/>
    <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. [24]

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

<iq from='[email protected]'
    id='kick1'
    to='[email protected]/pda'
    type='result'/>

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

<presence
    from='[email protected]/pistol'
    to='[email protected]/cell'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'/>
    <status code='307'/>
  </x>
</presence>

[ ... ]

A user cannot be kicked by a moderator with a lower affiliation. Therefore, if a moderator who is a member attempts to kick an admin, or a moderator who is a member or admin attempts to kick an owner, the service MUST deny the request and return a <not-allowed/> error to the sender:

<iq from='[email protected]'
    id='kicktest'
    to='[email protected]/laptop'
    type='error'>
  <error type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

If a moderator attempts to kick himself, the service MAY deny the request and return a <conflict/> error to the sender. (Although the act of kicking oneself may seem odd, it is common in IRC as a way of apologizing for one's actions in the room.)

8.3 Granting Voice to a Visitor¶

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

<iq from='[email protected]/desktop'
    id='voice1'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='participant'/>
  </query>
</iq>

The <reason/> element is OPTIONAL:

<iq from='[email protected]/desktop'
    id='voice1'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='participant'>
      <reason>A worthy witch indeed!</reason>
    </item>
  </query>
</iq>

The service MUST then inform the moderator of success:

<iq from='[email protected]'
    id='voice1'
    to='[email protected]/desktop'
    type='result'/>

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

<presence
    from='[email protected]/thirdwitch'
    to='[email protected]/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>

[ ... ]

8.4 Revoking Voice from a Participant¶

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

<iq from='[email protected]/desktop'
    id='voice2'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='visitor'/>
  </query>
</iq>

The <reason/> element is OPTIONAL:

<iq from='[email protected]/desktop'
    id='voice2'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='visitor'>
      <reason>Not so worthy after all!</reason>
    </item>
  </query>
</iq>

The service MUST then inform the moderator of success:

<iq from='[email protected]'
    id='voice2'
    to='[email protected]/desktop'
    type='result'/>

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

<presence
    from='[email protected]/thirdwitch'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/pda'
          role='visitor'/>
  </x>
</presence>

[ ... ]

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

<iq from='[email protected]'
    id='voicetest'
    to='[email protected]/desktop'
    type='error'>
  <error type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

8.5 Modifying the Voice List¶

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

<iq from='[email protected]/globe'
    id='voice3'
    to='[email protected]'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item role='participant'/>
  </query>
</iq>

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

<iq from='[email protected]'
    id='voice3'
    to='[email protected]/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='[email protected]/broom'
          nick='Hecate'
          role='participant'/>
  </query>
</iq>

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

<iq from='[email protected]/globe'
    id='voice4'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='Hecate'
          role='visitor'/>
    <item nick='rosencrantz'
          role='participant'>
      <reason>A worthy fellow.</reason>
    </item>
    <item nick='guildenstern'
          role='participant'>
      <reason>A worthy fellow.</reason>
    </item>
  </query>
</iq>

The service MUST then inform the moderator of success:

<iq from='[email protected]'
    id='voice1'
    to='[email protected]/globe'
    type='result'/>

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

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

<iq from='[email protected]'
    id='voicetest'
    to='[email protected]/globe'
    type='error'>
  <error type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

8.6 Approving Voice Requests¶

As noted in the Requesting Voice section of this document, an occupant requests voice by sending a voice request data form to the service. The service then SHOULD use that voice request data form as the basis for a voice approval data form that it generates and sends to the room moderator(s). The voice approval data form is contained in a <message/> stanza, as shown below.

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

In order to approve the request, a moderator shall submit the form:

<message from='[email protected]/pda'
         id='approve'
         to='[email protected]'>
  <x xmlns='jabber:x:data' type='submit'>
    <field var='FORM_TYPE' type='hidden'>
        <value>http://jabber.org/protocol/muc#request</value>
    </field>
    <field var='muc#role'>
      <value>participant</value>
    </field>
    <field var='muc#jid'>
      <value>[email protected]/pda</value>
    </field>
    <field var='muc#roomnick'>
      <value>thirdwitch</value>
    </field>
    <field var='muc#request_allow'>
      <value>true</value>
    </field>
  </x>
</message>

If a moderator approves the voice request, the service shall grant voice to the occupant and send a presence update as described in the Granting Voice to a Visitor section of this document.

9.1 Banning a User¶

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

<iq from='[email protected]/throne'
    id='ban1'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='outcast'
          jid='[email protected]'/>
  </query>
</iq>

The <reason/> element is OPTIONAL.

<iq from='[email protected]/throne'
    id='ban1'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='outcast'
          jid='[email protected]'>
      <reason>Treason</reason>
    </item>
  </query>
</iq>

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

<iq from='[email protected]'
    id='ban1'
    to='[email protected]/throne'
    type='result'/>

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

<presence
    from='[email protected]/cambridge'
    to='[email protected]/stabber'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='outcast' role='none'>
      <actor nick='The ♚'/>
      <reason>Treason</reason>
    </item>
    <status code='301'/>
  </x>
</presence>

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

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

<presence
    type='unavailable'
    from='[email protected]/cambridge'
    to='[email protected]/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='outcast'
          jid='[email protected]/stabber'
          role='none'/>
    <status code='301'/>
  </x>
</presence>

[ ... ]

As with Kicking an Occupant, a user cannot be banned by an admin with a lower affiliation. Therefore, if an admin attempts to ban an owner, the service MUST deny the request and return a <not-allowed/> error to the sender:

<iq from='[email protected]/throne'
    id='ban1'
    to='[email protected]'
    type='set'>
  <error type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

If an admin or owner attempts to ban himself, the service MUST deny the request and return a <conflict/> error to the sender. (Note: This is different from the recommended service behavior on kicking oneself.)

9.2 Modifying the Ban List¶

A room admin might want to modify the ban list. (Note: The ban list is always based on a user's bare JID.) To modify the list of banned JIDs, the admin first requests the ban list by querying the room for all users with an affiliation of 'outcast'.

<iq from='[email protected]/throne'
    id='ban2'
    to='[email protected]'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='outcast'/>
  </query>
</iq>

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

<iq from='[email protected]'
    id='ban2'
    to='[email protected]/throne'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='outcast'
          jid='[email protected]'>
      <reason>Treason</reason>
    </item>
  </query>
</iq>

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

<iq from='[email protected]/throne'
    id='ban3'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='outcast'
          jid='[email protected]'>
      <reason>Treason</reason>
    </item>
    <item affiliation='outcast'
          jid='[email protected]'>
      <reason>Treason</reason>
    </item>
  </query>
</iq>

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

<iq from='[email protected]'
    id='ban3'
    to='[email protected]/throne'
    type='result'/>

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

When an entity is banned from a room, an implementation SHOULD match JIDs in the following order:

1. <user@domain>
2. <domain> (the domain itself matches, as does any user@domain)

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

As specified in Banning a User, users cannot be banned under certain conditions. For example: admins and owners cannot ban themselves, and a user cannot be banned by an admin with a lower affiliation. When a request to modify the ban list includes one or more modifications that is prohibited by the definitions in Banning a User, then the service SHOULD NOT apply any of the requested changes and MUST deny the request using an error which SHOULD be either <conflict/> or <not-allowed/>.

9.3 Granting Membership¶

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

<iq from='[email protected]/desktop'
    id='member1'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'
          jid='[email protected]'
          nick='thirdwitch'/>
  </query>
</iq>

The <reason/> element is OPTIONAL.

<iq from='[email protected]/desktop'
    id='member1'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'
          jid='[email protected]'
          nick='thirdwitch'>
      <reason>A worthy witch indeed!</reason>
    </item>
  </query>
</iq>

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

<iq from='[email protected]'
    id='member1'
    to='[email protected]/desktop'
    type='result'/>

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

<presence
    from='[email protected]/thirdwitch'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/pda'
          role='participant'
          nick='thirdwitch'/>
  </x>
</presence>

[ ... ]

9.4 Revoking Membership¶

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

<iq from='[email protected]/desktop'
    id='member2'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='none'
          jid='[email protected]'/>
  </query>
</iq>

The <reason/> element is OPTIONAL.

<iq from='[email protected]/desktop'
    id='member2'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='none'
          jid='[email protected]'>
      <reason>Not so worthy after all!</reason>
    </item>
  </query>
</iq>

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

<iq from='[email protected]'
    id='member2'
    to='[email protected]/desktop'
    type='result'/>

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

<presence
    from='[email protected]/thirdwitch'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none'
          jid='[email protected]/pda'
          role='participant'/>
  </x>
</presence>

[ ... ]

If the room is members-only, the service MUST remove the user from the room, including a status code of 321 to indicate that the user was removed because of an affiliation change, and inform all remaining occupants. The stanza MAY include an <actor/> element.

<presence
    from='[email protected]/thirdwitch'
    to='[email protected]/desktop'>
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'>
      <actor nick='TheBard'/>
    </item>
    <status code='321'/>
  </x>
</presence>

[ ... ]

As there is no point in time where a non-member user must be in a members-only room, the service SHOULD NOT send both a de-affiliation presence (without a 'type' attribute) followed by room-removal presence (of type 'unavailable'). Instead, it SHOULD only send the latter of the two.

9.5 Modifying the Member List¶

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

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

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

<iq from='[email protected]/desktop'
    id='member3'
    to='[email protected]'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'/>
  </query>
</iq>

Note: If the room is non-anonymous, a service SHOULD also return the member list to any occupant in a members-only room; i.e., it SHOULD NOT generate a <forbidden/> error when a member in such a room requests the member list. This functionality can assist clients in showing all the existing members even if some of them are not in the room, e.g. to help a member determine if another user should be invited. If the room is non-anonymous, a service SHOULD also allow any member to retrieve the member list even if not yet an occupant.

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

<iq from='[email protected]'
    id='member3'
    to='[email protected]/desktop'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'
          jid='[email protected]'
          nick='thirdwitch'
          role='participant'/>
  </query>
</iq>

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

<iq from='[email protected]/desktop'
    id='member4'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='none'
          jid='[email protected]'/>
    <item affiliation='member'
          jid='[email protected]'/>
  </query>
</iq>

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

<iq from='[email protected]'
    id='member4'
    to='[email protected]/desktop'
    type='result'/>

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

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

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

<presence
    from='[email protected]/thirdwitch'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none'
          jid='[email protected]/pda'
          role='participant'/>
  </x>
</presence>

[ ... ]

In addition, the service SHOULD send an invitation to any user who has been added to the member list of a members-only room if the user is not currently affiliated with the room (note that the following example includes a password but not a reason -- both child elements are OPTIONAL):

<message
    from='[email protected]'
    id='CA409450-5AAE-41C1-AAAD-5375CA738885'
    to='[email protected]'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite from='[email protected]'/>
    <password>cauldronburn</password>
  </x>
</message>

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

<message
    from='[email protected]'
    id='C6E14DF6-00B7-4729-BC1C-94E59C07548E'
    to='[email protected]/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite to='[email protected]'>
      <reason>
        Hey Hecate, this is the place for all good witches!
      </reason>
    </invite>
  </x>
  <error type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</message>

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

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

<presence
    from='[email protected]/hecate'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/broom'
          role='participant'/>
  </x>
</presence>

[ ... ]

9.6 Granting Moderator Status¶

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

<iq from='[email protected]/desktop'
    id='mod1'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='moderator'/>
  </query>
</iq>

The <reason/> element is OPTIONAL.

<iq from='[email protected]/desktop'
    id='mod1'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='moderator'>
      <reason>A worthy witch indeed!</reason>
    </item>
  </query>
</iq>

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

<iq from='[email protected]'
    id='mod1'
    to='[email protected]/desktop'
    type='result'/>

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

<presence
    from='[email protected]/thirdwitch'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/pda'
          role='moderator'/>
  </x>
</presence>

[ ... ]

9.7 Revoking Moderator Status¶

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

<iq from='[email protected]/desktop'
    id='mod2'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='participant'/>
  </query>
</iq>

The <reason/> element is OPTIONAL.

<iq from='[email protected]/desktop'
    id='mod2'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='participant'>
      <reason>Not so worthy after all!</reason>
    </item>
  </query>
</iq>

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

<iq from='[email protected]'
    id='mod2'
    to='[email protected]/desktop'
    type='result'/>

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

<presence
    from='[email protected]/thirdwitch'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/pda'
          role='participant'/>
  </x>
</presence>

[ ... ]

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

<iq from='[email protected]'
    id='modtest'
    to='[email protected]/desktop'
    type='error'>
  <error type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

9.8 Modifying the Moderator List¶

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

<iq from='[email protected]/desktop'
    id='mod3'
    to='[email protected]'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item role='moderator'/>
  </query>
</iq>

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

<iq from='[email protected]'
    id='mod3'
    to='[email protected]/desktop'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'
          jid='[email protected]/pda'
          nick='thirdwitch'
          role='moderator'/>
  </query>
</iq>

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

<iq from='[email protected]/desktop'
    id='mod4'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item nick='thirdwitch'
          role='participant'/>
    <item nick='Hecate'
          role='moderator'/>
  </query>
</iq>

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

<iq from='[email protected]'
    id='mod4'
    to='[email protected]/desktop'
    type='result'/>

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

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

<iq from='[email protected]'
    id='modtest'
    to='[email protected]/pda'
    type='error'>
  <error type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

9.9 Approving Registration Requests¶

If a service does not automatically accept requests to register with a room, it MAY provide a way for room admins to approve or deny registration requests over XMPP (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 might use a different form entirely, or supplement the following form with additional fields.

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

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

More advanced registration approval mechanisms (e.g., retrieving a list of registration requests using Ad-Hoc Commands (XEP-0050) [25] as is done in Publish-Subscribe (XEP-0060) [26]) are out of scope for this document.

10.1 Creating a Room¶

<presence
    from='[email protected]/thirdwitch'
    to='[email protected]/pda'
    type='error'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <error by='[email protected]' type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>

<presence
    from='[email protected]/desktop'
    to='[email protected]/firstwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

<presence
    from='[email protected]/firstwitch'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='owner'
          role='moderator'/>
    <status code='110'/>
    <status code='201'/>
  </x>
</presence>

<iq from='[email protected]/desktop'
    id='create1'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <x xmlns='jabber:x:data' type='submit'/>
  </query>
</iq>

<iq from='[email protected]/desktop'
    id='create1'
    to='[email protected]'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#owner'/>
</iq>

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

<iq from='[email protected]'
    id='create1'
    to='[email protected]/desktop'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#owner'/>
</iq>

<iq from='[email protected]/desktop'
    id='create2'
    to='[email protected]'
    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_allowpm'>
        <value>anyone</value>
      </field>
      <field var='muc#roomconfig_maxusers'>
        <value>10</value>
      </field>
      <field var='muc#roomconfig_publicroom'>
        <value>0</value>
      </field>
      <field var='muc#roomconfig_persistentroom'>
        <value>0</value>
      </field>
      <field var='muc#roomconfig_moderatedroom'>
        <value>0</value>
      </field>
      <field var='muc#roomconfig_membersonly'>
        <value>0</value>
      </field>
      <field var='muc#roomconfig_passwordprotectedroom'>
        <value>1</value>
      </field>
      <field var='muc#roomconfig_roomsecret'>
        <value>cauldronburn</value>
      </field>
      <field var='muc#roomconfig_whois'>
        <value>moderators</value>
      </field>
      <field var='muc#maxhistoryfetch'>
        <value>50</value>
      </field>
      <field var='muc#roomconfig_roomadmins'>
        <value>[email protected]</value>
        <value>[email protected]</value>
      </field>
    </x>
  </query>
</iq>

<iq from='[email protected]'
    id='create2'
    to='[email protected]/desktop'
    type='result'/>

<iq from='[email protected]'
    id='create2'
    to='[email protected]/desktop'
    type='error'>
  <error type='modify'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

<iq from='[email protected]/desktop'
    id='create2'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <x xmlns='jabber:x:data' type='cancel'/>
  </query>
</iq>

10.2 Subsequent Room Configuration¶

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

<iq from='[email protected]/desktop'
    id='config1'
    to='[email protected]'
    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:

<iq from='[email protected]'
    id='configures'
    to='[email protected]/laptop'
    type='error'>
  <query xmlns='http://jabber.org/protocol/muc#owner'/>
  <error type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

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

<iq from='[email protected]'
    id='config1'
    to='[email protected]/desktop'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <x xmlns='jabber:x:data' type='form'>
      <title>Configuration for "coven" Room</title>
      <instructions>
        Complete this form to modify the
        configuration of your room.
      </instructions>
      <field
          type='hidden'
          var='FORM_TYPE'>
        <value>http://jabber.org/protocol/muc#roomconfig</value>
      </field>
      <field
          label='Natural-Language Room Name'
          type='text-single'
          var='muc#roomconfig_roomname'>
        <value>A Dark Cave</value>
      </field>
      <field
          label='Short Description of Room'
          type='text-single'
          var='muc#roomconfig_roomdesc'>
        <value>The place for all good witches!</value>
      </field>
      <field
          label='Enable Public Logging?'
          type='boolean'
          var='muc#roomconfig_enablelogging'>
        <value>0</value>
      </field>
      <field
          label='Allow Occupants to Change Subject?'
          type='boolean'
          var='muc#roomconfig_changesubject'>
        <value>0</value>
      </field>
      <field
          label='Allow Occupants to Invite Others?'
          type='boolean'
          var='muc#roomconfig_allowinvites'>
        <value>0</value>
      </field>
      <field
          label='Who Can Send Private Messages?'
          type='list-single'
          var='muc#roomconfig_allowpm'>
        <value>anyone</value>
        <option label='Anyone'>
          <value>anyone</value>
        </option>
        <option label='Anyone with Voice'>
          <value>participants</value>
          </option>
        <option label='Moderators Only'>
          <value>moderators</value>
        </option>
        <option label='Nobody'>
          <value>none</value>
        </option>
      </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 Broadcasted'
          type='list-multi'
          var='muc#roomconfig_presencebroadcast'>
        <value>moderator</value>
        <value>participant</value>
        <value>visitor</value>
        <option label='Moderator'><value>moderator</value></option>
        <option label='Participant'><value>participant</value></option>
        <option label='Visitor'><value>visitor</value></option>
      </field>
      <field
          label='Roles and Affiliations that May Retrieve Member List'
          type='list-multi'
          var='muc#roomconfig_getmemberlist'>
        <value>moderator</value>
        <value>participant</value>
        <value>visitor</value>
        <option label='Moderator'><value>moderator</value></option>
        <option label='Participant'><value>participant</value></option>
        <option label='Visitor'><value>visitor</value></option>
      </field>
      <field
          label='Make Room Publicly Searchable?'
          type='boolean'
          var='muc#roomconfig_publicroom'>
        <value>0</value>
      </field>
      <field
          label='Make Room Persistent?'
          type='boolean'
          var='muc#roomconfig_persistentroom'>
        <value>0</value>
      </field>
      <field
          label='Make Room Moderated?'
          type='boolean'
          var='muc#roomconfig_moderatedroom'>
        <value>0</value>
      </field>
      <field
          label='Make Room Members Only?'
          type='boolean'
          var='muc#roomconfig_membersonly'>
        <value>0</value>
      </field>
      <field
          label='Password Required for Entry?'
          type='boolean'
          var='muc#roomconfig_passwordprotectedroom'>
        <value>1</value>
      </field>
      <field type='fixed'>
        <value>
          If a password is required to enter this room,
          you must specify the password below.
        </value>
      </field>
      <field
          label='Password'
          type='text-private'
          var='muc#roomconfig_roomsecret'>
        <value>cauldronburn</value>
      </field>
      <field
          label='Who May Discover Real JIDs?'
          type='list-single'
          var='muc#roomconfig_whois'>
        <value>moderators</value>
        <option label='Moderators Only'>
          <value>moderators</value>
        </option>
        <option label='Anyone'>
          <value>anyone</value>
        </option>
      </field>
      <field
          label='Maximum Number of History Messages Returned by Room'
          type='text-single'
          var='muc#maxhistoryfetch'>
        <value>50</value>
      </field>
      <field type='fixed'>
        <value>
          You may specify additional people who have
          admin status in the room. Please
          provide one Jabber ID per line.
        </value>
      </field>
      <field
          label='Room Admins'
          type='jid-multi'
          var='muc#roomconfig_roomadmins'>
        <value>[email protected]</value>
        <value>[email protected]</value>
      </field>
      <field type='fixed'>
        <value>
          You may specify additional owners for this
          room. Please provide one Jabber ID per line.
        </value>
      </field>
      <field
          label='Room Owners'
          type='jid-multi'
          var='muc#roomconfig_roomowners'/>
    </x>
  </query>
</iq>

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

The room owner then submits the form with updated configuration information. (Example not shown.)

Alternatively, the room owner MAY cancel the configuration process:

<iq from='[email protected]/desktop'
    id='config2'
    to='[email protected]'
    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 admin status while in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member" or "none" and the 'role' attribute set to a value of "participant" or "visitor" as appropriate for the affiliation level and the room type:

<presence
    from='[email protected]/secondwitch'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]/laptop'
          role='participant'/>
  </x>
</presence>

[ ... ]

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

<presence
    from='[email protected]/secondwitch'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin'
          jid='[email protected]/laptop'
          role='moderator'/>
  </x>
</presence>

[ ... ]

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

<presence
    from='[email protected]/secondwitch'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin'
          jid='[email protected]/laptop'
          role='moderator'/>
  </x>
</presence>

[ ... ]

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

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

<presence
    from='[email protected]/secondwitch'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='owner'
          jid='[email protected]/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.

<message from='[email protected]'
         id='80349046-F26A-44F3-A7A6-54825064DD9E'
         to='[email protected]/desktop'
         type='groupchat'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <status code='170'/>
  </x>
</message>

10.3 Granting Owner Status¶

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

<iq from='[email protected]/desktop'
    id='owner1'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='owner'
          jid='[email protected]'/>
  </query>
</iq>

The <reason/> element is OPTIONAL.

<iq from='[email protected]/desktop'
    id='owner1'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='owner'
          jid='[email protected]'>
      <reason>A worthy witch indeed!</reason>
    </item>
  </query>
</iq>

As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of the user in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

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

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

<iq from='[email protected]'
    id='owner1'
    to='[email protected]/desktop'
    type='result'/>

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

<presence
    from='[email protected]/hecate'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='owner'
          jid='[email protected]'
          role='moderator'/>
  </x>
</presence>

[ ... ]

If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the granting of owner status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "owner".

<message
    from='chat.shakespeare.lit'
    id='22B0F570-526A-4F22-BDE3-52EC3BB18371'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member'
          jid='[email protected]'
          role='none'/>
  </x>
</message>

[ ... ]

10.4 Revoking Owner Status¶

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

<iq from='[email protected]/desktop'
    id='owner2'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='admin'
          jid='[email protected]'/>
  </query>
</iq>

The <reason/> element is OPTIONAL.

<iq from='[email protected]/desktop'
    id='owner2'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='admin'
          jid='[email protected]'>
      <reason>Not so worthy after all!</reason>
    </item>
  </query>
</iq>

As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of the user in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

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.

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

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

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

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

<iq from='[email protected]'
    id='owner2'
    to='[email protected]/desktop'
    type='result'/>

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

<presence
    from='[email protected]/secondwitch'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin'
          jid='[email protected]'
          role='moderator'/>
  </x>
</presence>

[ ... ]

10.5 Modifying the Owner List¶

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

<iq from='[email protected]/globe'
    id='owner3'
    to='[email protected]'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='owner'/>
  </query>
</iq>

If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a <forbidden/> error to the sender in semi-anonymous rooms. In non-anonymous rooms, the service MAY process the request.

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

<iq from='[email protected]'
    id='owner3'
    to='[email protected]/globe'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='owner'
          jid='[email protected]'/>
  </query>
</iq>

The owner can then modify the owner list if desired. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; [27] each item MUST include the 'affiliation' and 'jid' attributes but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as owner). As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of users in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

<iq from='[email protected]/globe'
    id='owner4'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='owner'
          jid='[email protected]'/>
  </query>
</iq>

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

<iq from='[email protected]'
    id='ownertest'
    to='[email protected]/pda'
    type='error'>
  <error type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

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

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

<iq from='[email protected]'
    id='owner4'
    to='[email protected]/desktop'
    type='result'/>

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

10.6 Granting Admin Status¶

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

<iq from='[email protected]/desktop'
    id='admin1'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='admin'
          jid='[email protected]'/>
  </query>
</iq>

The <reason/> element is OPTIONAL.

<iq from='[email protected]/desktop'
    id='admin1'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='admin'
          jid='[email protected]'>
      <reason>A worthy witch indeed!</reason>
    </item>
  </query>
</iq>

As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of the user in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

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

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

<iq from='[email protected]'
    id='admin1'
    to='[email protected]/desktop'
    type='result'/>

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

<presence
    from='[email protected]/secondwitch'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin'
          jid='[email protected]'
          role='moderator'/>
  </x>
</presence>

[ ... ]

If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the granting of admin status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "admin".

<message
    from='chat.shakespeare.lit'
    id='C75B919A-30B3-4233-AE89-6E9834E26929'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin'
          jid='[email protected]'
          role='none'/>
  </x>
</message>

[ ... ]

10.7 Revoking Admin Status¶

An owner might want to revoke a user's admin status; this is done by changing the user's affiliation to something other than "admin" or "owner" (typically to "member" in a members-only room or to "none" in other types of room).

<iq from='[email protected]/desktop'
    id='admin2'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='none'
          jid='[email protected]'/>
  </query>
</iq>

The <reason/> element is OPTIONAL.

<iq from='[email protected]/desktop'
    id='admin2'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='none'
          jid='[email protected]'>
      <reason>Not so worthy after all!</reason>
    </item>
  </query>
</iq>

As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of the user in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

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

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

<iq from='[email protected]'
    id='admin2'
    to='[email protected]/desktop'
    type='result'/>

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

<presence
    from='[email protected]/secondwitch'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none'
          jid='[email protected]'
          role='participant'/>
  </x>
</presence>

[ ... ]

If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the loss of admin status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value other than "admin".

<message
    from='chat.shakespeare.lit'
    id='2CF9013B-E8A8-42A1-9633-85AD7CA12F40'
    to='[email protected]/desktop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none'
          jid='[email protected]'
          role='none'/>
  </x>
</message>

[ ... ]

10.8 Modifying the Admin List¶

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

<iq from='[email protected]/desktop'
    id='admin3'
    to='[email protected]'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='admin'/>
  </query>
</iq>

If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a <forbidden/> error to the sender in semi-anonymous rooms. In non-anonymous rooms, the service MAY process the request.

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

<iq from='[email protected]'
    id='admin3'
    to='[email protected]/globe'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='admin'
          jid='[email protected]'
          nick='secondwitch'/>
    <item affiliation='admin'
          jid='[email protected]'/>
  </query>
</iq>

The owner can then modify the admin list if desired. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; [28] each item MUST include the 'affiliation' attribute (normally set to a value of "admin" or "none") and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as owner). As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of users in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

<iq from='[email protected]/globe'
    id='admin4'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='none'
          jid='[email protected]'>
    </item>
    <item affiliation='admin'
          jid='[email protected]'>
    </item>
  </query>
</iq>

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

<iq from='[email protected]'
    id='admintest'
    to='[email protected]/pda'
    type='error'>
  <error type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

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

<iq from='[email protected]'
    id='admin4'
    to='[email protected]/desktop'
    type='result'/>

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

10.9 Destroying a Room¶

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

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

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

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

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

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

<iq from='[email protected]/desktop'
    id='begone'
    to='[email protected]'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <destroy jid='[email protected]'>
      <reason>Macbeth doth come.</reason>
    </destroy>
  </query>
</iq>

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

Note: in older versions of this standard, the inclusion of a <destroy/> element was not explicitly defined to be mandatory (when no alternate location or reason are provided by the room owner). Implementations therefore cannot reliably depend on the existence of this element to identify a room destruction event.

<presence
    from='[email protected]/firstwitch'
    to='[email protected]/desktop'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'/>
    <destroy jid='[email protected]'>
      <reason>Macbeth doth come.</reason>
    </destroy>
  </x>
</presence>

<presence
    from='[email protected]/secondwitch'
    to='[email protected]/laptop'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'/>
    <destroy jid='[email protected]'>
      <reason>Macbeth doth come.</reason>
    </destroy>
  </x>
</presence>

<presence
    from='[email protected]/thirdwitch'
    to='[email protected]/pda'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'/>
    <destroy jid='[email protected]'>
      <reason>Macbeth doth come.</reason>
    </destroy>
  </x>
</presence>

<iq from='[email protected]'
    id='begone'
    to='[email protected]/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:

<iq from='[email protected]'
    id='destroytest'
    to='[email protected]/laptop'
    type='error'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <destroy jid='[email protected]'>
      <reason>Macbeth doth come.</reason>
    </destroy>
  </query>
  <error type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

11.1 Service removes user because of error response¶

A MUC service MAY support adding the 333 status code to presences when a user gets removed by the service due to a technical problem (e.g. s2s link failure). This can, for example, be used as a hint for clients to distinguish between an occupant getting disconnected and them intentionally leaving the room.

If a MUC service supports this OPTIONAL feature, it MUST include the 333 status code in the resulting presence:

<presence
    from='[email protected]/pistol'
    to='[email protected]/harfleur'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none' />
    <status code='110'/>
    <status code='333'/>
  </x>
</presence>

The status code MUST also be included in presences sent to other occupants:

<presence
    from='[email protected]/pistol'
    to='[email protected]/cell'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'/>
    <status code='333'/>
  </x>
</presence>

Note: Some server implementations additionally include a 307 status code (signifying a 'kick', i.e. a forced ejection from the room). This is generally not advisable, as these types of disconnects may be frequent in the presence of poor network conditions and they are not linked to any user (e.g. moderator) action that the 307 code usually indicates. It is therefore recommended for the client to ignore the 307 code if a 333 status code is present.

11.2 Service removes user because of service shut down¶

When a MUC service shuts downs, it SHOULD inform its participant by sending presences containing the 332 status code

<presence
    from='[email protected]/pistol'
    to='[email protected]/client'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none' />
    <status code='110'/>
    <status code='332'/>
  </x>
</presence>
<presence
    from='[email protected]/othello'
    to='[email protected]/client'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none' />
    <status code='110'/>
    <status code='332'/>
  </x>
</presence>

14.1 User Authentication and Authorization¶

No room entrance authentication or authorization method more secure than cleartext passwords is defined or required by this document. Although the risks involved can mitigated somewhat by the use of channel encryption and strong authentication via TLS and SASL as described in RFC 6120 [12], an entity that joins a room has no way of knowing if its complete communication channel to the room is encrypted (thereby protecting the plaintext password). A future specification might define an XMPP profile of SASL for use with MUC, but currently there is no such specification.

14.2 End-to-End Encryption¶

No end-to-end message or session encryption method is specified herein. Users SHOULD NOT trust a service to keep secret any text sent through a room. A future specification might define a method for end-to-end encryption of MUC traffic, but currently there is no such specification.

14.3 Privacy¶

Depending on room configuration, a room might publicly log all discussions held in the room. A service MUST warn the user that the room is publicly logged by returning a status code of "170" with the user's initial presence, and the user's client MUST warn the user if the room discussion is logged (a user's client SHOULD also query the room for its configuration prior to allowing the user to enter in order to "pre-discover" whether the room is logged). A client MUST also warn the user if the room's configuration is subsequently modified to allow room logging (which the client will discover when the room sends status code 170).

Note: In-room history is different from public room logging, and naturally a room cannot effectively prevent occupants from separately maintaining their own room logs, which may become public; users SHOULD exercise due caution and consider any room discussions to be effectively public.

14.4 Information Leaks¶

The "roominfo" data form used in extended service discovery can result in information leaks, e.g., the current discussion topic (via the "roominfo_subject" field). The same is true of service discovery items (disco#items) requests from outside the room (which could be used to discover the list of room occupants).

Implementations and deployments are advised to carefully consider the possibility that this information might be leaked, and to turn off information sharing by default for sensitive data.

14.5 Anonymity¶

Depending on room configuration, a room might expose each occupant's real JID to other occupants (if the room is non-anonymous). If real JIDs are exposed to all occupants in the room, the service MUST warn the user by returning a status code of "100" with the user's initial presence, and the user's client MUST warn the user (a user's client SHOULD also query the room for its configuration prior to allowing the user to enter in order to "pre-discover" whether real JIDs are exposed in the room). A client MUST also warn the user if the room's configuration is modified from semi-anonymous to non-anonymous (which the client will discover when the room sends status code 172).

14.6 Denial of Service¶

Public MUC rooms can be subject to a number of attacks, most of which reduce to denial of service attacks. Such attacks include but are not limited to:

1. Stuffing the room with a large number of illegitimate occupants and therefore preventing legitimate users from joining the room.
2. Sending abusive messages and then leaving the room before a kick or ban can be applied; such abusive messages include but are not limited to large messages that prevent participants from following the conversation thread or room history, personal attacks on participants (especially room administrators and moderators), offensive text, and links to spam sites.
3. Making rapid and repeated presence changes.
4. Using long nicknames to route around lack of voice.
5. Abusing the room administrators or other room occupants.
6. Registering multiple nicknames across a service and therefore denying the use of those nicknames.
7. Mimicking another occupant's roomnick (e.g., by adding a space at the end or substituting visually similar characters), then sending messages from that roomnick in an effort to confuse the occupants.

These attacks can be mitigated but not completely prevented through the liberal use of administrative actions such as banning, the presence of automated room bots with admin status, implementation of intelligent content filtering, checking the IP addresses of connected users (not always possible in a distributed system), applying voice rules to presence as well as messaging, matching room nicks using more stringent rules than the Resourceprep profile of stringprep, etc. However, experience has shown that it is impossible to fully prevent attacks of this kind.

Public MUC services also can be subject to attacks, such as creating a large number of rooms on a service, leaving rooms in an unconfigured state, etc. Such service-level attacks can be mitigated by limiting the number of rooms that any given non-adminstrative user can own, deleting rooms if they remain in the unconfigured state for too long, etc.

14.7 Other Considerations¶

See Delayed Delivery (XEP-0203) [14] for security considerations regarding the inclusion and processing of delayed delivery notations.

16.1 Protocol Namespaces¶

The XMPP Registrar includes the following MUC-related namespaces in its registry of protocol namespaces at <https://xmpp.org/registrar/namespaces.html>:

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

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

16.3 Service Discovery Features¶

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

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

16.4 Well-Known Service Discovery Nodes¶

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

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

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

16.5 Field Standardization¶

Field Standardization for Data Forms (XEP-0068) [35] defines a process for standardizing the fields used within Data Forms qualified by a particular FORM_TYPE. Within MUC, there are four uses of such forms: room registration (the "muc#register" FORM_TYPE), requesting voice and approving voice requests ("muc#request"), room configuration ("muc#roomconfig"), and service discovery extensions for room information ("muc#roominfo"). The reserved fields are defined below.

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

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

<form_type>
  <name>http://jabber.org/protocol/muc#roomconfig</name>
  <doc>XEP-0045</doc>
  <desc>
    Forms enabling creation and configuration of
    a Multi-User Chat (MUC) room.
  </desc>
  <field
      var='muc#maxhistoryfetch'
      type='text-single'
      label='Maximum Number of History Messages Returned by Room'/>
  <field
      var='muc#roomconfig_allowpm'
      type='list-single'
      label='Roles that May Send Private Messages'/>
  <field
      var='muc#roomconfig_allowinvites'
      type='boolean'
      label='Whether to Allow Occupants to Invite Others'/>
  <field
      var='muc#roomconfig_changesubject'
      type='boolean'
      label='Whether to Allow Occupants to Change Subject'/>
  <field
      var='muc#roomconfig_enablelogging'
      type='boolean'
      label='Whether to Enable Public Logging of Room Conversations'/>
  <field
      var='muc#roomconfig_getmemberlist'
      type='list-multi'
      label='Roles and Affiliations that May Retrieve Member List'/>
  <field
      var='muc#roomconfig_lang'
      type='text-single'
      label='Natural Language for Room Discussions'/>
  <field
      var='muc#roomconfig_pubsub'
      type='text-single'
      label='XMPP URI of Associated Publish-Subscribe Node'/>
  <field
      var='muc#roomconfig_maxusers'
      type='list-single'
      label='Maximum Number of Room Occupants'/>
  <field
      var='muc#roomconfig_membersonly'
      type='boolean'
      label='Whether to 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 Broadcasted'/>
  <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-single'
      label='The Room Password'/>
  <field
      var='muc#roomconfig_whois'
      type='list-single'
      label='Affiliations that May Discover Real JIDs of Occupants'/>
</form_type>

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

16.6 Status Codes Registry¶

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

<statuscode>
  <number>100</number>
  <stanza>message or presence</stanza>
  <context>Entering a room</context>
  <purpose>
    Inform user that any occupant is allowed to see the user's full JID
  </purpose>
</statuscode>
<statuscode>
  <number>101</number>
  <stanza>message (out of band)</stanza>
  <context>Affiliation change</context>
  <purpose>
    Inform user that his or her affiliation changed while not in the room
  </purpose>
</statuscode>
<statuscode>
  <number>102</number>
  <stanza>message</stanza>
  <context>Configuration change</context>
  <purpose>
    Inform occupants that room now shows unavailable members
  </purpose>
</statuscode>
<statuscode>
  <number>103</number>
  <stanza>message</stanza>
  <context>Configuration change</context>
  <purpose>
    Inform occupants that room now does not show unavailable members
  </purpose>
</statuscode>
<statuscode>
  <number>104</number>
  <stanza>message</stanza>
  <context>Configuration change</context>
  <purpose>
    Inform occupants that a non-privacy-related room configuration change has occurred
  </purpose>
</statuscode>
<statuscode>
  <number>110</number>
  <stanza>presence</stanza>
  <context>Any room presence</context>
  <purpose>
    Inform user that presence refers to itself
  </purpose>
</statuscode>
<statuscode>
  <number>170</number>
  <stanza>message or initial presence</stanza>
  <context>Configuration change</context>
  <purpose>
    Inform occupants that room logging is now enabled
  </purpose>
</statuscode>
<statuscode>
  <number>171</number>
  <stanza>message</stanza>
  <context>Configuration change</context>
  <purpose>
    Inform occupants that room logging is now disabled
  </purpose>
</statuscode>
<statuscode>
  <number>172</number>
  <stanza>message</stanza>
  <context>Configuration change</context>
  <purpose>
    Inform occupants that the room is now non-anonymous
  </purpose>
</statuscode>
<statuscode>
  <number>173</number>
  <stanza>message</stanza>
  <context>Configuration change</context>
  <purpose>
    Inform occupants that the room is now semi-anonymous
  </purpose>
</statuscode>
<statuscode>
  <number>201</number>
  <stanza>presence</stanza>
  <context>Entering a room</context>
  <purpose>
    Inform user that a new room has been created
  </purpose>
</statuscode>
<statuscode>
  <number>210</number>
  <stanza>presence</stanza>
  <context>Entering a room, changing nickname, etc.</context>
  <purpose>
    Inform user that service has assigned or modified occupant's roomnick
  </purpose>
</statuscode>
<statuscode>
  <number>301</number>
  <stanza>presence</stanza>
  <context>Removal from room</context>
  <purpose>
    A user has been banned from the room
  </purpose>
</statuscode>
<statuscode>
  <number>303</number>
  <stanza>presence</stanza>
  <context>Exiting a room</context>
  <purpose>
    Inform all occupants of new room nickname
  </purpose>
</statuscode>
<statuscode>
  <number>307</number>
  <stanza>presence</stanza>
  <context>Removal from room</context>
  <purpose>
    A user has been kicked from the room
  </purpose>
</statuscode>
<statuscode>
  <number>321</number>
  <stanza>presence</stanza>
  <context>Removal from room</context>
  <purpose>
    A user is being removed from the room
    because of an affiliation change
  </purpose>
</statuscode>
<statuscode>
  <number>322</number>
  <stanza>presence</stanza>
  <context>Removal from room</context>
  <purpose>
    A user is being removed from the room
    because the room has been changed to members-only and the
    user is not a member
  </purpose>
</statuscode>
<statuscode>
  <number>332</number>
  <stanza>presence</stanza>
  <context>Removal from room</context>
  <purpose>
    A user is being removed from the room
    because the MUC service is being shut down
  </purpose>
</statuscode>
<statuscode>
  <number>333</number>
  <stanza>presence</stanza>
  <context>Removal from room</context>
  <purpose>
    A user was removed because of an error reply (for example
    when an s2s link fails between the MUC and the removed users server).
  </purpose>
</statuscode>

16.7 URI Query Types¶

As authorized by XMPP URI Query Components (XEP-0147) [36], the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see <https://xmpp.org/registrar/querytypes.html>).

xmpp:[email protected]?join

<presence to='[email protected]/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

xmpp:[email protected]?join;password=cauldronburn

<presence to='[email protected]/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <password>cauldronburn</password>
  </x>
</presence>

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

xmpp:[email protected]?invite;[email protected]

<presence to='[email protected]/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

<message to='[email protected]'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite to='[email protected]'/>
  </x>
</message>

xmpp:[email protected]?invite;[email protected];[email protected]

<message to='[email protected]'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite to='[email protected]'/>
    <invite to='[email protected]'/>
  </x>
</message>

xmpp:[email protected]?invite;[email protected];password=cauldronburn

<presence to='[email protected]/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

<message to='[email protected]'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite to='[email protected]'/>
    <password>cauldronburn</password>
  </x>
</message>

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

17.1 Addresses¶

In order to provide consistency regarding the addresses captured in room JIDs and occupant JIDs, Room IDs MUST match the Nodeprep profile of Stringprep and Room Nicknames MUST match the Resourceprep profile of Stringprep (both of these are defined in RFC 6122 [32]). As explicitly stated in RFC 6122, both the Room ID (node) and Room Nickname (resource) portions of an Occupant JID MUST be of non-zero length. In addition, a MUC service MUST NOT allow empty or invisible Room Nicknames (i.e., Room Nicknames that consist only of one or more space characters).

It is up to the service implementation whether it will further restrict roomnicks (e.g., by applying case folding routines, the Nodeprep profile of stringprep, or other restrictions).

17.2 Message¶

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

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

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

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

5. A MUC client MAY generate extensions that conform to Chat State Notifications (XEP-0085) [37] specification; however, a MUC service MAY disallow these extensions (see the Allowable Traffic section of this document).

17.3 Presence¶

1. The presence stanza used to join a room MUST NOT possess a 'type' attribute, i.e., it must be available presence. A MUC service MUST NOT treat a presence stanza with a 'type' attribute (e.g., a presence probe) as a request to join the room.

2. The presence stanza used to exit a room MUST possess a 'type' attribute whose value is "unavailable". A MUC service MUST NOT treat a presence stanza with a 'type' attribute whose value is other than "unavailable" (e.g., a presence probe) as a request to exit the room.

3. If a MUC service receives a Basic MUC Protocol join request from a client that is already joined, it MUST treat it as a full synchronization request, and send to the client everything that would be sent to it on a normal join. The MUC service SHOULD send a presence update to the other participants if the join presence is different from the client's previous presence.

4. A MUC service MAY handle presence probes sent to the room JID <room@service> or an occupant JID <room@service/nick> (e.g, these might be sent by an occupant's home server to determine if the room is still online or to synchronize presence information if the user or the user's server has gone offline temporarily or has started sharing presence again, as for instance when Stanza Interception and Filtering Technology (XEP-0273) [38] is used).

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

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

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

8. In order to inform occupants of room roles and affiliations, and to make it easier for clients to track the current state of all users in the room, MUC service implementations MUST provide role and affiliation data (and, if allowed by the room configuration, full JID) in all presence stanzas, including presence stanzas of type "unavailable" sent when a user exits the room for any reason.

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

10. If the service includes an occupant's JabberID in the MUC presence extension, the value of the 'jid' attribute MUST be the full JID (not the bare JID).

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

17.4 IQ¶

1. MUC is designed for sharing of messages and presence, not IQs. An IQ sent to the JID of the room itself is handled by the room and is not reflected to all of the room occupants.

2. 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 occupant JID).

3. 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 occupant JID and the service SHOULD forward the stanza to the recipient's real JID. However, the MUC service MUST NOT reveal the sender's real JID to the recipient at any time, nor reveal the recipient's real JID to the sender.

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

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

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

18.1 Services¶

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

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

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

4. Room types MAY be configured in any combination. A MUC service MAY support or allow any desired room types or combinations thereof. There is no guarantee that any such combination is sensible.

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

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

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

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

9. A MUC service MAY choose to discard extended information attached to a <message/> stanza 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 (XEP-0071) [39]. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the Allowable Traffic section of this document.

10. A MUC service MAY choose to "lock down" room nicknames (e.g., hardcoding the room nickname to the bare JID of the occupant). If so, the service MUST treat the locked nickname as a reserved room nickname and MUST support the protocol specified in the Discovering Reserved Room Nickname section of this document.

<iq from='[email protected]/laptop'
    to='[email protected]'
    id='allow1'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://jabber.org/protocol/muc#traffic'/>
</iq>

<iq from='[email protected]'
    to='[email protected]/laptop'
    id='allow1'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://jabber.org/protocol/muc#traffic'>
    <feature var='http://jabber.org/protocol/xhtml-im'/>
    <feature var='http://jabber.org/protocol/rosterx'/>
  </query>
</iq>

<iq from='[email protected]'
    to='[email protected]/laptop'
    id='allow1'
    type='error'>
  <error type='cancel'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

18.2 Clients¶

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

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

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

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

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

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

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

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

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

19.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
      XEP-0045: http://www.xmpp.org/extensions/xep-0045.html
    </xs:documentation>
  </xs:annotation>

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

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

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

</xs:schema>

19.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
      XEP-0045: http://www.xmpp.org/extensions/xep-0045.html
    </xs:documentation>
  </xs:annotation>

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

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

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

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

  <xs:element name='item'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='actor' minOccurs='0'/>
        <xs:element ref='continue' 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='optional'/>
          <xs:attribute name='nick' type='xs:string' use='optional'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

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

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

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

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

</xs:schema>

19.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
      XEP-0045: http://www.xmpp.org/extensions/xep-0045.html
    </xs:documentation>
  </xs:annotation>

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

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

  <xs:element name='actor'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='jid' type='xs:string' use='optional'/>
          <xs:attribute name='nick' type='xs:string' use='optional'/>
        </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>

19.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
      XEP-0045: http://www.xmpp.org/extensions/xep-0045.html
    </xs:documentation>
  </xs:annotation>

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

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

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

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

</xs:schema>

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2024 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

1. RFC 1459: Internet Relay Chat <http://tools.ietf.org/html/rfc1459>.

2. RFC 2810: Internet Relay Chat: Architecture <http://tools.ietf.org/html/rfc2810>.

3. RFC 2811: Internet Relay Chat: Channel Management <http://tools.ietf.org/html/rfc2811>.

4. RFC 2812: Internet Relay Chat: Client Protocol <http://tools.ietf.org/html/rfc2812>.

5. RFC 2813: Internet Relay Chat: Server Protocol <http://tools.ietf.org/html/rfc2813>.

6. XEP-0133: Service Administration <https://xmpp.org/extensions/xep-0133.html>.

7. XEP-0272: Multiparty Jingle <https://xmpp.org/extensions/xep-0272.html>.

8. XEP-0249: Direct MUC Invitations <https://xmpp.org/extensions/xep-0249.html>.

9. XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>.

10. XEP-0059: Result Set Management <https://xmpp.org/extensions/xep-0059.html>.

11. XEP-0128: Service Discovery Extensions <https://xmpp.org/extensions/xep-0128.html>.

12. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.

13. The <presence/> element MUST NOT include more than once instance of the <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace.

14. XEP-0203: Delayed Delivery <https://xmpp.org/extensions/xep-0203.html>.

15. XEP-0091: Legacy Delayed Delivery <https://xmpp.org/extensions/xep-0091.html>.

16. XEP-0033: Extended Stanza Addressing <https://xmpp.org/extensions/xep-0033.html>.

17. XEP-0082: XMPP Date and Time Profiles <https://xmpp.org/extensions/xep-0082.html>.

18. RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace <http://tools.ietf.org/html/rfc4122>.

19. XEP-0280: Message Carbons <https://xmpp.org/extensions/xep-0280.html>.

20. XEP-0016: Privacy Lists <https://xmpp.org/extensions/xep-0016.html>.

21. XEP-0077: In-Band Registration <https://xmpp.org/extensions/xep-0077.html>.

22. XEP-0004: Data Forms <https://xmpp.org/extensions/xep-0004.html>.

23. RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>.

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

25. XEP-0050: Ad-Hoc Commands <https://xmpp.org/extensions/xep-0050.html>.

26. XEP-0060: Publish-Subscribe <https://xmpp.org/extensions/xep-0060.html>.

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

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

29. RFC 2616: Hypertext Transport Protocol -- HTTP/1.1 <http://tools.ietf.org/html/rfc2616>.

30. RFC 1893: Enhanced Mail System Status Codes <http://tools.ietf.org/html/rfc1893>.

31. XEP-0171: Language Translation <https://xmpp.org/extensions/xep-0171.html>.

32. RFC 6122: Extensible Messaging and Presence Protocol (XMPP): Address Format <http://tools.ietf.org/html/rfc6122>.

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

34. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.

35. XEP-0068: Field Data Standardization for Data Forms <https://xmpp.org/extensions/xep-0068.html>.

36. XEP-0147: XMPP URI Query Components <https://xmpp.org/extensions/xep-0147.html>.

37. XEP-0085: Chat State Notifications <https://xmpp.org/extensions/xep-0085.html>.

38. XEP-0273: Stanza Interception and Filtering Technology <https://xmpp.org/extensions/xep-0273.html>.

39. XEP-0071: XHTML-IM <https://xmpp.org/extensions/xep-0071.html>.

40. XEP-0199: XMPP Ping <https://xmpp.org/extensions/xep-0199.html>.

41. XEP-0245: The /me Command <https://xmpp.org/extensions/xep-0245.html>.