XEP-xxxx: Multi-User Chat Administration

Abstract
This specification defines how to administer Multi-User Chat rooms and services using Ad-Hoc Commands.
Author
Peter Saint-Andre
Copyright
© 2012 – 2012 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status

ProtoXEP

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <https://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.
Type
Standards Track
Version
0.0.1 (2012-09-25)
Document Lifecycle
  1. Experimental
  2. Proposed
  3. Stable
  4. Final

1. Introduction

Multi-User Chat (XEP-0045) [1] defines a widely-implemented XMPP extension for chatrooms. The MUC specification covers a number of common administrative use cases, such as kicking and banning users, granting voice, and changing user affiliations (moderator, admin, etc.). However, the protocols for these use cases are "hardcoded" and not as flexible or extensible as we might like. A more flexible approach would be to use Ad-Hoc Commands (XEP-0050) [2] (which did not exist when MUC was originally being developed) so that any implementation or deployment of a MUC service could define its own commands, as was done for core XMPP servers in Service Administration (XEP-0133) [3]. This specification defines such a framework for MUC services, including in-room administration as well as administration of the MUC service as a whole (e.g., banning users across all rooms).

2. Requirements

This document addresses the following requirements:

3. Discovery

A MUC service MUST advertise any administrative commands it supports via Service Discovery (XEP-0030) [4] (as described in XEP-0050: Ad-Hoc Commands); such commands exist as well-defined discovery nodes associated with the service in question.

All supported Ad-Hoc Command nodes MUST be included in the Entity Capabilities (XEP-0115) [5] hash generated by a MUC service.

4. Extensibility

The Data Forms (XEP-0004) [6] FORM_TYPE for MUC administration is "urn:xmpp:muc-admin". Fields defined in this specification are of the form "urn:xmpp:muc-admin:*". Particular implementations and deployments MAY define their own commands as fields to be included in data forms scoped by the "urn:xmpp:muc-admin" FORM_TYPE; in accordance with Field Standardization for Data Forms (XEP-0068) [7], the names of such fields SHOULD use Clark Notation [8] (e.g., "{http://www.example.com/muc-admin}foo").

5. Use Cases

This document defines a profile of XEP-0050: Ad-Hoc Commands that enables a MUC administrator to complete the use cases listed below. (Any overlap with existing administrative use cases currently defined in XEP-0045 is noted below.)

  1. Modify Room Subject
  2. Set Occupant Role
  3. Set User Affiliation
  4. Assign Occupant Nickname
  5. Clear Room History
  6. Report a Spammer

Some of these scenarios can apply to a single room or to multiple rooms. If the request is sent to a room JID (e.g., coven@chat.shakespeare.lit), then the interaction applies to that room only and the data form generated by the service might include a hidden field specifying the room. If the request is sent to the service's JID (e.g., chat.shakespeare.lit), the data form generated by the service might include a boolean flag specifying whether the interaction applies to all rooms on the service. The examples below illustrate these settings.

5.1 Modify Room Subject

This use case provides the same functionality as the protocol described in Section 8.1 of XEP-0045. The following command sequence mirrors the examples in Section 8.1 of XEP-0045.

Example 1. Admin Requests to Modify a Room Subject
<iq from='wiccarocks@shakespeare.lit/laptop'
    id='ur72vx41'
    to='coven@chat.shakespeare.lit'
    type='set'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           action='execute'
           node='urn:xmpp:muc-admin:modify-room-subject'/>
</iq>

Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form. Notice that, since the request was sent to a particular room, the interaction applies to that room only (in this case, the data form includes an optional hidden field specifying the room).

Example 2. Service Returns Modify Room Subject Form to Admin
<iq from='coven@chat.shakespeare.lit'
    id='ur72vx41'
    to='wiccarocks@shakespeare.lit/laptop'
    type='result'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='urn:xmpp:muc-admin:modify-room-subject'/>
           sessionid='5981DC80-AF4E-445E-9FF6-0F4067FDCD05'
           status='executing'>
    <x xmlns='jabber:x:data' type='form'>
      <title>Modifying a Room Subject</title>
      <instructions>Fill out this form to modify the room subject.</instructions>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:muc-admin</value>
      </field>
      <field label='Room subject'
             type='text'
             var='room-subject'>
        <required/>
      </field>
      <field type='hidden' var='roomjid'>
        <value>coven</value>
      </field>
    </x>
  </command>
</iq>
Example 3. Admin Submits Modify Room Subject Form to Service
<iq from='wiccarocks@shakespeare.lit/laptop'
    id='9i2fsvc7'
    to='coven@chat.shakespeare.lit'
    type='set'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='urn:xmpp:muc-admin:modify-room-subject'
           sessionid='5981DC80-AF4E-445E-9FF6-0F4067FDCD05'>
    <x xmlns='jabber:x:data' type='submit'>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:muc-admin</value>
      </field>
      <field var='room-subject'>
        <value>Fire Burn and Cauldron Bubble!</value>
      </field>
      <field var='roomjid'>
        <value>coven@chat.shakespeare.lit</value>
      </field>
    </x>
  </command>
</iq>
Example 4. Service Informs Admin of Completion
<iq from='coven@chat.shakespeare.lit'
    id='9i2fsvc7'
    to='wiccarocks@shakespeare.lit/laptop'
    type='result'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='urn:xmpp:muc-admin:modify-room-subject'
           sessionid='5981DC80-AF4E-445E-9FF6-0F4067FDCD05'
           status='completed'/>
</iq>

Notification of completion MAY include the processed data in a data form of type "result", although strictly speaking this is unnecessary since the subject change will be sent in the room.

5.2 Modify Occupant Role

This use case provides the same functionality as the protocol described in Sections 8.2, 8.3, and 8.4 of XEP-0045. However, the 'role' field is more easily extensible so that implementations can include their own values (e.g., a new role of "scribe"). The following command sequence mirrors the examples in Section 8.2 of XEP-0045.

Example 5. Admin Requests to Modify an Occupant Role
<iq from='fluellen@shakespeare.lit/pda'
    id='so3g2bl5'
    to='harfleur@chat.shakespeare.lit'
    type='set'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           action='execute'
           node='urn:xmpp:muc-admin:modify-occupant-role'/>
</iq>

Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

Example 6. Service Returns Modify Occupant Role Form to Admin
<iq from='harfleur@chat.shakespeare.lit'
    id='so3g2bl5'
    to='fluellen@shakespeare.lit/pda'
    type='result'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='urn:xmpp:muc-admin:modify-occupant-role'/>
           sessionid='F4CC8121-DA42-4FDD-8668-17900310D8BE'
           status='executing'>
    <x xmlns='jabber:x:data' type='form'>
      <title>Modifying an Occupant Role</title>
      <instructions>Fill out this form to modify the role for a room occupant.</instructions>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:muc-admin</value>
      </field>
      <field label='Occupant Nickname'
             type='text-single'
             var='nick'>
        <required/>
      </field>
      <field label='Role'
             type='list-single'
             var='role'>
        <option label='None (note: user will be kicked)'><value>none</value></option>
        <option label='Visitor'><value>visitor</value></option>
        <option label='Participant'><value>participant</value></option>
        <option label='Moderator'><value>moderator</value></option>
        <required/>
      </field>
      <field label='Reason'
             type='text-single'
             var='reason'/>
    </x>
  </command>
</iq>
Example 7. Admin Submits Modify Occupant Role Form to Service
<iq from='fluellen@shakespeare.lit/pda'
    id='kes62fa3'
    to='harfleur@chat.shakespeare.lit'
    type='set'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='urn:xmpp:muc-admin:modify-occupant-role'
           sessionid='F4CC8121-DA42-4FDD-8668-17900310D8BE'>
    <x xmlns='jabber:x:data' type='submit'>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:muc-admin</value>
      </field>
      <field var='nick'>
        <value>pistol</value>
      </field>
      <field var='role'>
        <value>none</value>
      </field>
      <field var='reason'>
        <value>Avaunt, you cullion!</value>
      </field>
    </x>
  </command>
</iq>
Example 8. Service Informs Admin of Completion
<iq from='harfleur@chat.shakespeare.lit'
    id='kes62fa3'
    to='fluellen@shakespeare.lit/pda'
    type='result'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='urn:xmpp:muc-admin:modify-occupant-role'
           sessionid='F4CC8121-DA42-4FDD-8668-17900310D8BE'
           status='completed'/>
</iq>

5.3 Set User Affiliation

This use case provides the same functionality as the protocol described in Sections 9.1, 9.3, 9.4, 9.6, 9.7, 10.3, 10.4, 10.6, and 10.7 of XEP-0045. However, the 'affiliation' field is more easily extensible so that implementations can include their own values (e.g., a new affiliation of "creator"). The following command sequence mirrors the examples in Section 10.3 of XEP-0045.

Example 9. Admin Requests to Modify a User Affiliation
<iq from='crone1@shakespeare.lit/desktop'
    id='rk391bf6'
    to='coven@chat.shakespeare.lit'
    type='set'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           action='execute'
           node='urn:xmpp:muc-admin:modify-user-affiliation'/>
</iq>

Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

Example 10. Service Returns Modify Occupant Role Form to Admin
<iq from='coven@chat.shakespeare.lit'
    id='rk391bf6'
    to='crone1@shakespeare.lit/desktop'
    type='result'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='urn:xmpp:muc-admin:modify-user-affiliation'/>
           sessionid='3C5229C9-CD08-46F0-80BF-3BAB604363A2'
           status='executing'>
    <x xmlns='jabber:x:data' type='form'>
      <title>Modifying a User Affiliation</title>
      <instructions>Fill out this form to modify the affiliation for a user.</instructions>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:muc-admin</value>
      </field>
      <field label='User JID'
             type='jid-single'
             var='userjid'>
        <required/>
      </field>
      <field label='Affiliation'
             type='list-single'
             var='affiliation'>
        <option label='Outcast (note: user will be banned)'><value>outcast</value></option>
        <option label='None'><value>none</value></option>
        <option label='Member'><value>member</value></option>
        <option label='Administrator'><value>administrator</value></option>
        <option label='Owner'><value>owner</value></option>
        <required/>
      </field>
      <field label='Reason'
             type='text-single'
             var='reason'/>
    </x>
  </command>
</iq>
Example 11. Admin Submits Modify User Affiliation Form to Service
<iq from='crone1@shakespeare.lit/desktop'
    id='i72bs93v'
    to='coven@chat.shakespeare.lit'
    type='set'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='urn:xmpp:muc-admin:modify-user-affiliation'
           sessionid='3C5229C9-CD08-46F0-80BF-3BAB604363A2'>
    <x xmlns='jabber:x:data' type='submit'>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:muc-admin</value>
      </field>
      <field var='userjid'>
        <value>hecate@shakespeare.lit</value>
      </field>
      <field var='affiliation'>
        <value>owner</value>
      </field>
      <field var='reason'>
        <value>A worthy witch indeed!</value>
      </field>
    </x>
  </command>
</iq>
Example 12. Service Informs Admin of Completion
<iq from='coven@chat.shakespeare.lit'
    id='i72bs93v'
    to='crone1@shakespeare.lit/desktop'
    type='result'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='urn:xmpp:muc-admin:modify-user-affiliation'
           sessionid='3C5229C9-CD08-46F0-80BF-3BAB604363A2'
           status='completed'/>
</iq>

5.4 Assign Occupant Nickname

This use case enables a moderator or administrator to assign a new nickname to an occupant. This functionality can be helpful in situations where an occupant specifies or receives a temporary or inscrutable nickname on joining the room (e.g., "Call-In-User-7"), but the administrator wants to assign a more user-friendly nickname (e.g., "Peter Saint-Andre").

Example 13. Admin Requests to Assign an Occupant Nickname
<iq from='crone1@shakespeare.lit/desktop'
    id='9eb251ck'
    to='heath@chat.shakespeare.lit'
    type='set'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           action='execute'
           node='urn:xmpp:muc-admin:assign-occupant-nickname'/>
</iq>

Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

Example 14. Service Returns Assign Occupant Nickname Form to Admin
<iq from='heath@chat.shakespeare.lit'
    id='9eb251ck'
    to='crone1@shakespeare.lit/desktop'
    type='result'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='urn:xmpp:muc-admin:assign-occupant-nickname'/>
           sessionid='53E9C396-64DD-4652-97CF-42E21E857A2D'
           status='executing'>
    <x xmlns='jabber:x:data' type='form'>
      <title>Assigning an Occupant Nickname</title>
      <instructions>Fill out this form to assign a nickname to a participant.</instructions>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:muc-admin</value>
      </field>
      <field label='Current Nickname'
             type='text-single'
             var='current-nick'>
        <required/>
      </field>
      <field label='New Nickname'
             type='text-single'
             var='nick'>
        <required/>
      </field>
    </x>
  </command>
</iq>
Example 15. Admin Submits Assign Occupant Nickname Form to Service
<iq from='crone1@shakespeare.lit/desktop'
    id='h4bs91hy'
    to='coven@chat.shakespeare.lit'
    type='set'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='urn:xmpp:muc-admin:assign-occupant-nickname'
           sessionid='53E9C396-64DD-4652-97CF-42E21E857A2D'
    <x xmlns='jabber:x:data' type='submit'>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:muc-admin</value>
      </field>
      <field var='nick'>
        <value>thirdwitch</value>
      </field>
      <field var='newnick'>
        <value>hag66</value>
      </field>
    </x>
  </command>
</iq>
Example 16. Service Informs Admin of Completion
<iq from='heath@chat.shakespeare.lit'
    id='h4bs91hy'
    to='crone1@shakespeare.lit/desktop'
    type='result'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='urn:xmpp:muc-admin:assign-occupant-nickname'
           sessionid='53E9C396-64DD-4652-97CF-42E21E857A2D'
           status='completed'/>
</iq>

5.5 Clear Room History

This use case enables a moderator or administrator to clear the history that new occupants receive when they join the room.

Example 17. Admin Requests to Clear History
<iq from='bard@shakespeare.lit/globe'
    id='xn274h59'
    to='heath@chat.shakespeare.lit'
    type='set'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           action='execute'
           node='urn:xmpp:muc-admin:clear-room-history'/>
</iq>

Unless an error occurs (see the Error Handling section below), the service SHOULD simply clear the history.

Example 18. Service Informs Admin of Completion
<iq from='heath@chat.shakespeare.lit'
    id='xn274h59'
    to='bard@shakespeare.lit/globe'
    type='result'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='urn:xmpp:muc-admin:clear-room-history'
           status='completed'/>
</iq>

5.6 Report a Spammer

This use case enables a moderator or administrator to report a particular user as a spammer. Typically such a report will trigger further events such as those described in Incident Reporting (XEP-0268) [9].

Example 19. Admin Requests to Report a Spammer
<iq from='fluellen@shakespeare.lit/pda'
    id='lz62g4b8'
    to='harfleur@chat.shakespeare.lit'
    type='set'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           action='execute'
           node='urn:xmpp:muc-admin:spamreport'/>
</iq>

Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

Example 20. Service Returns Spam Report Form to Admin
<iq from='harfleur@chat.shakespeare.lit'
    id='lz62g4b8'
    to='fluellen@shakespeare.lit/pda'
    type='result'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='urn:xmpp:muc-admin:spamreport'/>
           sessionid='E244DA21-E081-430C-B030-6886FDBCF0CD'
           status='executing'>
    <x xmlns='jabber:x:data' type='form'>
      <title>Spam Report</title>
      <instructions>Fill out this form to report a room occupant as a spammer.</instructions>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:muc-admin</value>
      </field>
      <field label='Occupant Nickname'
             type='text-single'
             var='nick'>
        <required/>
      </field>
    </x>
  </command>
</iq>
Example 21. Admin Submits Spam Report Form to Service
<iq from='fluellen@shakespeare.lit/pda'
    id='gr92g1v5'
    to='harfleur@chat.shakespeare.lit'
    type='set'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='urn:xmpp:muc-admin:spamreport'
           sessionid='E244DA21-E081-430C-B030-6886FDBCF0CD'>
    <x xmlns='jabber:x:data' type='submit'>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:muc-admin</value>
      </field>
      <field var='nick'>
        <value>pistol</value>
      </field>
    </x>
  </command>
</iq>
Example 22. Service Informs Admin of Completion
<iq from='harfleur@chat.shakespeare.lit'
    id='gr92g1v5'
    to='fluellen@shakespeare.lit/pda'
    type='result'
    xml:lang='en'>
  <command xmlns='http://jabber.org/protocol/commands'
           node='urn:xmpp:muc-admin:modify-occupant-role'
           sessionid='E244DA21-E081-430C-B030-6886FDBCF0CD'
           status='completed'/>
</iq>

6. Error Handling

Several error conditions are possible when an entity sends a command request to the service, as defined in the following table. If one of these error conditions occurs, the service MUST return an error stanza to the requesting entity.

Table 1: Error Conditions
Condition Cause
<conflict/> The command cannot be completed because of a data or system conflict (e.g., a user already exists with that username).
<feature-not-implemented/> The specific command is not supported (even though the ad-hoc commands protocol is).
<forbidden/> The requesting entity does not have sufficient privileges to perform the command.
<not-allowed/> No entity is allowed to perform the command (e.g., retrieve the CEO's roster).
<service-unavailable/> The ad-hoc commands protocol is not supported.

For the syntax of these errors, see Error Condition Mappings (XEP-0086) [10]. Naturally, other errors may be returned as well (e.g., <internal-server-error/> if the service cannot be shut down).

7. Security Considerations

The ability to complete the administrative tasks specified herein MUST NOT be granted to users who lack service-level administrative privileges.

8. IANA Considerations

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

9. XMPP Registrar Considerations

9.1 Protocol Namespaces

The XMPP Registrar shall add "urn:xmpp:muc-admin" to its registry of protocol namespaces.

9.2 Field Standardization

XEP-0068 defines a process for standardizing the fields used within Data Forms scoped by a particular namespace. The reserved fields for the 'urn:xmpp:muc-admin' namespace are specified below.

Registry Submission
<form_type>
  <name>urn:xmpp:muc-admin</name>
  <doc>XEP-xxxx</doc>
  <desc>Forms used for administration of MUC rooms and services.</desc>
  <field var='newnick'
         type='text-single'
         label='The new nickname to be assigned to a room occupant'/>
  <field var='nick'
         type='text-single'
         label='The current nickname of a room occupant'/>
  <field var='roomjid'
         type='jid-single'
         label='The Jabber ID of MUC room'/>
  <field var='roomjids'
         type='jid-multi'
         label='The Jabber IDs of one or more rooms to which an operation applies'/>
  <field var='subject'
         type='text-single'
         label='The text of a room subject'/>
</form_type>

10. XML Schema

Because the protocol defined here is a profile of XEP-0050: Ad-Hoc Commands, no schema definition is needed.

Appendices

Appendix A: Document Information

Series
XEP
Number
xxxx
Publisher
XMPP Standards Foundation
Status
ProtoXEP
Type
Standards Track
Version
0.0.1
Last Updated
2012-09-25
Approving Body
XMPP Council
Dependencies
XMPP Core, XEP-0045, XEP-0050
Supersedes
None
Superseded By
None
Short Name
NOT_YET_ASSIGNED

This document in other formats: XML  PDF

Appendix B: Author Information

Peter Saint-Andre
Email
stpeter@stpeter.im
JabberID
stpeter@jabber.org
URI
https://stpeter.im/

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.

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

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

Appendix G: Notes

1. XEP-0045: Multi-User Chat <https://xmpp.org/extensions/xep-0045.html>.

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

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

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

5. XEP-0115: Entity Capabilities <https://xmpp.org/extensions/xep-0115.html>.

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

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

8. Clark Notation, a syntax to allow universal names written as a URI in curly brackets followed by the local name; developed by James Clark. <http://www.jclark.com/xml/xmlns.htm>.

9. XEP-0268: Incident Reporting <https://xmpp.org/extensions/xep-0268.html>.

10. XEP-0086: Error Condition Mappings <https://xmpp.org/extensions/xep-0086.html>.

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

Appendix H: Revision History

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

  1. Version 0.0.1 (2012-09-25)

    First draft.

    psa

Appendix I: Bib(La)TeX Entry

@report{saint-andre2012xepxxxx,
  title = {Multi-User Chat Administration},
  author = {Saint-Andre, Peter},
  type = {XEP},
  number = {xxxx},
  version = {0.0.1},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-xxxx.html},
  date = {2012-09-25/2012-09-25},
}

END