XEP-0001: XMPP Extension Protocols

1. Introduction¶

The XMPP Standards Foundation (XSF) [1] adheres to an open standards process that enables interested parties to document existing protocols used within the Jabber/XMPP developer community and to submit proposals that define new protocols; with a few exceptions, [2] such protocols can be considered extensions to the Extensible Messaging and Presence Protocol (XMPP) approved by the Internet Engineering Task Force (IETF) [4] in XMPP Core [5] and XMPP IM [6]. The focal point of the process is a series of protocol specifications called XMPP Extension Protocols or XEPs. [7]

Advancement of a XEP through the XSF's standards process is contingent on three factors:

• Rough consensus on the XSF's public discussion lists.
• Running code in XMPP clients, servers, and libraries.
• Formal approval by the XMPP Council [11].

The XSF's standards process can be outlined informally as follows:

1. A developer in the XMPP community defines a new XMPP extension that solves an existing problem or enables an innovative feature that is not addressed in the current XMPP protocol stack.
2. The developer submits a specification to the XMPP Extensions Editor [12] and agrees to transfer ownership over the protocol (but not implementations thereof) to the XSF.
3. If the specification is accepted by the XMPP Council, it is published as an Experimental XEP.
4. The XEP undergoes extensive community review on the XSF's open discussion lists and is implemented experimentally in XMPP clients, servers, and libraries.
5. If the protocol fills an important need, meets with rough consensus, and is (preferably) implemented in running code, the XMPP Council will formally review it and vote on advancing it to a status of Stable.
6. While the XEP is in the Stable state, the protocol may be refined based on further discussion and implementation experience.
7. If the protocol is deemed stable after at least six months (and normally more) of further implementation and deployment experience, the XSF then considers advancement of the XEP to a status of Final.

Other types of XEP follow modified variants through the same essential path.

The remainder of this document formally defines the nature of XMPP Extension Protocols and the mechanisms for managing and advancing them within the XSF's standards process.

2. Objectives¶

The XMPP Standards Foundation was founded in the year 2001 to openly document, safeguard, manage, and extend the wire protocols used within the XMPP developer community. The work of the XMPP Standards Foundation has several objectives:

1. To produce practical, technically excellent solutions to important problems of real-time communication based on the set of streaming XML technologies known as XMPP.
2. To document XMPP extensions in a clear, concise manner so that the task of implementing the protocols is straightforward.
3. To ensure interoperability among the disparate technologies used on XMPP networks.
4. To guarantee that any person or entity can implement the protocols without encumbrance.
5. To work in an fair, open, objective manner.

The standards process specified herein has been developed and refined in order to meet these objectives.

3. XEP Types¶

The five XEP types are described in the following sections.

The approving body for all Standards Track, Informational, and Historical XEPs is the XMPP Council; the approving body for Humorous XEPs is the XMPP Extensions Editor; and the approving body for Procedural XEPs may be either the XSF Board of Directors [13] or the XMPP Council.

This document focuses primarily on Standards Track XEPs since they are the vehicle for defining new protocols, but also discusses the other XEP types.

4. Submission Process¶

The XSF welcomes and encourages the submission of protocols to the XSF's standards process. [20] Any individual or group of individuals may author a proposal and submit it to the XSF for consideration as a XEP, and there is no requirement that a XEP author shall be an elected member of the XSF. Proposals to define official XSF protocols must be presented in the XEP format and must follow the rules defined herein (after a proposal has been submitted but before it has been accepted as a XEP, it is known informally as a "ProtoXEP"). The authoring and submission process is defined in Guidelines for Authors of XMPP Extension Protocols (XEP-0143) [21]. All submissions to the XSF's standards process should be directed to the XMPP Extensions Editor.

Note well that XEP authors must transfer ownership of their protocols (but not implementations thereof) to the XSF. Refer to the XSF IPR Policy [22] for details. XEP authors must make sure that they have read, understood, and agreed to the XSF IPR Policy before submitting a proposal to the XMPP Extensions Editor!

All proposals submitted to the XSF for consideration as XEPs must contain the following information:

1. Legal Notices -- the legal notices must be exactly those specified in the XSF IPR Policy

2. Author Information -- first name, last name, email address, and Jabber ID are all required and must be provided for all authors (to simplify the text we use singular "author" in the remainder of this document, with the understanding that there can be multiple authors)

Finally, Standards Track, Informational, and Historical XEPs must conform to RFC 2119 [23] in the use of terminology regarding requirements levels.

5. Publication Process¶

The Approving Body for almost all XEPs is the XMPP Council; therefore, in order to be published as a XEP, a proposal must first be accepted by the XMPP Council (the only exceptions are certain kinds of Procedural XEPs, for which the approving body may be the XSF Board of Directors and which may be accepted for publication by the XMPP Extensions Editor in consultation with the Board). Upon receiving a proposal, the XMPP Extensions Editor shall do the following:

• ensure that its format is correct
• publish it to <http://www.xmpp.org/extensions/inbox/>
• publicly announce its existence by sending a message to the discussion list of the Standards SIG [24]
• request acceptance of the proposal as a XEP by the Approving Body (normally the XMPP Council)

Within 14 days, the Chair of the Approving Body shall poll members of the Approving Body. In rare cases, the Approving Body may decide that the wrong Approving Body may have been chosen. If the Approving Body is in doubt, the XSF Board shall determine the correct Approving Body.

If no member of the Approving Body objects to publication of the proposal, the XMPP Extensions Editor shall accept it as a XEP. The precise rules for polls, including meetings and timeouts, are determined by the Chair of the Approving Body.

If objections are raised by the Approving Body on the discussion list of the Standards SIG [24] (the Standards list) or in its meeting, the XEP author is encouraged to address the feedback of the Approving Body and to submit a revised version of the proposal and/or confer with the XMPP Extensions Editor or objecting Approving Body member(s) regarding how to proceed.

If the proposal is accepted as a XEP, the XMPP Extensions Editor shall do the following:

• assign it a number
• specify an appropriate type
• specify a status of Experimental (or Active for Humorous XEPs)
• add it to source control [25]
• add tracking information to the XEPs database
• publish version 0.1 of the XEP to the xmpp.org website [26]
• publicly announce the existence of the XEP by sending a message to the Standards list

Note well that no special criteria (other than acceptance by the Approving Body and minimal formatting compliance) need to be met in order for a XEP to be granted a status of Experimental. The granting of Experimental status must not be construed as indicating any level of approval by the XSF, the XMPP Council, or the XMPP developer community. Implementation of Experimental XEPs is encouraged in an exploratory fashion (e.g., in a proof of concept) in order to gain experience with and iteratively improve the protocol defined therein, but such implementations might not be appropriate for deployment in production systems.

6. Discussion Process¶

Once a XEP is published, it becomes available for public discussion within the Standards SIG and the broader XMPP developer community. The XEP author (or Document Shepherd) is responsible for collecting feedback from the XMPP developer community during the life of the XEP and for incorporating such feedback into the proposal. In order to fully participate in discussion of the proposal, they should be subscribed to the Standards list, which is the primary venue for discussion of XMPP Extension Protocols. Changes made based on feedback received by the XEP author (or Document Shepherd) shall be captured in updated versions of the XEP (e.g., 0.2 after 0.1), each of which must be put under source control and subsequently published and announced by the XMPP Extensions Editor.

If an Experimental XEP is inactive (i.e., no updated versions are published) for a period of twelve (12) months, the XMPP Extensions Editor shall automatically change the status of the XEP to Deferred unless it is in the queue of XEPs under active consideration for advancement by the Approving Body; upon submission of an updated version, the XMPP Extensions Editor shall change the status back to Experimental.

Only substantial, non-editorial changes (e.g. those that would cause an updated version of 0.1 to 0.2, not editorial updates from 0.1.1 to 0.1.2) count as activity (or updates) for the purpose of considering moving a XEP from or to Deferred state.

7. Proposal Process¶

An Experimental (or Deferred) XEP may be proposed to the Approving Body for advancement to Stable (Standards Track XEPs) or Active (Historical, Informational, and Procedural XEPs). This can be requested from the Approving Body on the Standards list by, or in collaboration with, the XEP author. In case the XEP has been abandoned by its author(s), any other individual can propose advancement in their stead. The Approving Body will then require a Document Shepherd to take on responsibilities on behalf of the XEP author during the proposal and approval processes. The Approving Body must agree that the XEP is ready to be considered for advancement. Once the Approving Body so agrees, it shall instruct the XMPP Extensions Editor to (1) change the status of the XEP from Experimental (or Deferred) to Proposed and (2) issue a Last Call for open discussion on the Standards list. The Last Call shall expire not less than fourteen (14) days after the date of issue.

Once the consensus of the Standards SIG has been incorporated into the XEP and all issues of substance raised during the Last Call have been addressed by the XEP author or Document Shepherd, the XMPP Extensions Editor shall formally propose a specific revision of the XEP to the Approving Body for its vote. If necessary, the XMPP Extensions Editor may, at his discretion and in consultation with the Approving Body, extend the Last Call or issue a new Last Call if the XEP requires further discussion.

8. Approval Process¶

The precise mechanism for approval depends on the Approving Body.

After a XEP has been proposed to the XMPP Council, any change in its status shall be determined by a vote of the XMPP Council. All members of the Council must vote, with the possible values being +1 (approve), 0 (neutral), or -1 (disapprove, with reasons). A XEP shall not be advanced to the next stage in the approval process so long as any Council Member continues to vote -1; that Council Member's written concerns must be addressed in order for the XEP to advance. A majority of Council members must vote +1 in order for a XEP to advance. (Additional voting policies, such as voting periods and defaults if a member does not vote, may be set by the XMPP Council.) A vote of the XMPP Council is final and binding, although a XEP author or Document Shepherd is free to address the concerns of the Council and to resubmit the XEP for future consideration.

If the Approving Body decides after Last Call that the XEP is not ready for advancement yet, but nevertheless useful, it can vote to move it back to Experimental state.

If the XMPP Council does not complete voting on a XEP before the end of its term, the XMPP Extensions Editor shall issue a new Last Call on the Standards list and the newly-elected Council shall vote anew on the XEP after completion of the Last Call. This provides an opportunity for any member of the previous Council who had voted -1 to voice his or her concerns in a public forum before the new Council votes on the XEP.

A vote of the XMPP Council applies only to the specific revision of the XEP that has been presented to it. Further revisions may need to be re-submitted for approval.

Any change in the status of a XEP must be announced on the Standards list by the XMPP Extensions Editor. If a XEP advances to a status of Final, it shall be so announced and also published as one of the official XSF protocols of the XMPP Standards Foundation.

Approval of Procedural XEPs for which the approving body is the XSF Board of Directors shall occur upon approval by the Board in accordance with the rules defined in the XSF Bylaws [27].

Approval for Humorous XEPs (for which the Approving Body is the XMPP Extensions Editor) is automatic upon accepting the submission.

More detailed information about the approval process is provided below, including criteria for Standards Track XEPs and for Historical, Informational, and Procedural XEPs.

     +--> Retracted
     |
     |
     +--> Deferred    +--> Rejected
     |         |      |
     |         |      |
Experimental --+-> Proposed ----> Stable ---> Final
     ^                |             |           |
     +----------------+             |           |
                                    +-----------+---> Deprecated
                                                          |
                                                          +--> Obsolete
    

     +--> Retracted
     |
     |
     +--> Deferred    +--> Rejected
     |                |
     |                |
Experimental ----> Proposed ----> Active
                                    |
                                    |
                                    +--> Deprecated
                                             |
                                             +--> Obsolete
    

9. Summary of XEP States¶

The possible states for a XEP are summarized in the following sections.

10. Modification of Final and Active XEPs¶

Sometimes it is necessary to modify XEPs that have received final approval by the XMPP Council or XSF Board of Directors (e.g., to correct errors, incorporate the lessons of experience, or document new security concerns). This section describes the process for doing so with regard to Standards Track XEPs that have achieved a status of Final and Historical, Informational, and Procedural XEPs that have achieved a status of Active.

With regard to Standards Track XEPs, the XMPP Standards Foundation (in particular, the XMPP Council) strives to ensure that such XEPs are accurate, complete, and stable before advancing them to a status of Final (corresponding to document version 2.0 of the XEP). The Call for Experience and discussion within the Standards SIG help to ensure this result, but final responsibility rests with the XMPP Council. Despite the best efforts of all concerned, errors are sometimes discovered in Final XEPs (the individual who discovers such an error should inform the Council via the Standards mailing list or communicate directly with the XMPP Extensions Editor). Whereas other standards development organizations may issue errata while leaving the specification itself unchanged, the XSF makes changes to the Final XEP "in place", where any changes that could reasonably be construed as material are subject to review by the XMPP Council and result in publication of a revised document version (e.g., version 2.1). In general, any such changes are made by the XMPP Extensions Editor or XEP author in consultation with the XMPP Council, discussed within the Standards SIG if appropriate, and agreed upon by the full XMPP Council. Upon agreement regarding the exact changes, the XMPP Council shall instruct the XMPP Extensions Editor to publish a revised version of the XEP and announce the existence of the revised version through the normal channels (e.g., on the XSF website and to the Standards list). Naturally, if members of the XMPP developer community have concerns regarding the changes made, they are free to discuss the matter in the relevant forum (usually the Standards list) before or after the revised version has been published. Ultimate authority for Final and Active XEPs rests with the XMPP Council, which can at its discretion demand the reversal of any changes made by the XMPP Extensions Editor or the XEP author while the XEP is in the Final or Active state.

The process is similar with regard to Historical and Informational XEPs that have achieved a status of Active (corresponding to document version 1.0 of the XEP): the XMPP Council agrees on the exact changes to be made and instructs the XMPP Extensions Editor to publish and announce a revised version (e.g., version 1.1). Here again the XMPP Council bears responsibility for any changes and public discussion is welcome.

Procedural XEPs may be modified more frequently as the XMPP Standards Foundation gains experience with the processes defined therein. For example, XEP-0001 is modified periodically in order to document processes previously not made explicit or to modify existing processes based on experience with the XSF's standards process; similar changes are sometimes made to the XMPP Registrar Function (XEP-0053) [18] XEP and to various SIG-related XEPs. Changes to these XEPs are discussed by the XMPP Council, XSF Board of Directors, XSF membership, and Standards SIG as appropriate, and exact changes are agreed to by the relevant approving body (XMPP Council or XSF Board of Directors). The approving body then instructs the XMPP Extensions Editor to publish and announce the revised version as described above.

11. Expiration Dates¶

In rare cases, a protocol enhancement may be accepted as an interim solution, especially when it is recognized that expected future improvements in technology or the underlying XMPP protocols will make possible a much better solution to the problem at hand (e.g., a better protocol for user avatars may be contingent upon the development of a robust protocol for publish/subscribe functionality). In such cases, a XEP may be approved provisionally and be assigned an expiration date.

The exact form of such an expiration date shall be left up to the discretion of the XMPP Council. However, the preferred form is to assign an expiration date of six (6) months in the future, at which time the XMPP Council must re-affirm the status of the XEP and, if desired, extend the expiration date for another six (6) months. Although this process may continue indefinitely (although that is unlikely), it has the virtue of forcing the XMPP Council and XMPP developer community to re-examine the provisional protocol on a fairly regular basis in the light of technological changes. Alternatively, a XEP may be assigned a "soft" expiration date: that is, the XEP will expire when an expected future protocol comes into existence, whenever that may be. In either case, the status of the XEP shall be changed to Deprecated when it expires.

In addition, an expiration date may be assigned when the status of a XEP is changed from Final (or, potentially, Stable) to Deprecated. In this case, the expiration date applies to the date when the XEP is expected to change from Deprecated to Obsolete. These dates may be flexible; however it is expected that they will follow the same six-month rule as provisional protocol enhancements.

12. Security Considerations¶

Every XMPP Extension Protocol specification must contain a section entitled "Security Considerations", detailing security concerns or features related to the proposal; in particular, a Standards Track XEP should list the security threats that the protocol addresses and does not address, as well as security issues related to implementation of the protocol and deployment of such implementations. XEP authors should refer to RFC 3552 [31] for helpful information about documenting security considerations and should also confer with the XMPP Extensions Editor and/or XMPP Council regarding this important task.

13. IANA Considerations¶

Some XMPP Extension Protocols may require interaction with the Internet Assigned Numbers Authority (IANA) [32]. The IANA acts as a clearinghouse to assign and coordinate the use of numerous Internet protocol parameters, such as MIME types and port numbers (e.g., the TCP ports 5222, 5269, and 5280 used by the XMPP developer community are registered with the IANA). Whether or not a XEP requires registration of parameters with the IANA, that fact must be noted and explained in a distinct section of the XEP entitled "IANA Considerations". Registration with the IANA must not occur until the registration has been approved by the XMPP Council (e.g., by advancement of a XEP to a status of Stable or Active), and must be initiated by the XMPP Registrar in consultation with the XEP author, not by the XEP author directly with the IANA.

14. XMPP Registrar Considerations¶

The XMPP Registrar [33] performs a function similar to the IANA, although limited to the XMPP developer community. It does so by reserving protocol namespaces and by uniquely assigning parameters for use in the context of XMPP protocols (for example, the categories and types used in Service Discovery (XEP-0030) [34]).

Whether or not a XEP requires registration of protocol namespaces or parameters with the XMPP Registrar, that fact must be noted and explained in a distinct section of the XEP entitled "XMPP Registrar Considerations". Such registration should not occur until a XEP advances to a status of Stable (Standards Track XEPs) or Active (Informational and Historical XEPs). Registration of protocol namespaces is initiated by the XMPP Extensions Editor when a XEP advances to Stable or Active. Registration of particular parameters used within a specification may be initiated by a XEP author within the text of the XEP, or by an implementor of the XEP after it has advanced to Stable or Active. For details regarding the XMPP Registrar and its processes, refer to XMPP Registrar Function (XEP-0053) [18].

A XEP may also request that a new registry is to be created by the XMPP Registrar. The XEP author must clearly define the nature of the new registry as well as the process for submitting data to the registry, and should do so in collaboration with the Registrar.

15. XML Schema¶

XMPP Extension Protocol specifications that define official XSF protocols must include a schema that conforms to XML Schema Part 1 [35] and XML Schema Part 2 [36].

The schema for the XEP format itself is as follows:

<?xml version='1.0' encoding='UTF-8'?>

<!--

Copyright (c) 1999 - 2021 XMPP Standards Foundation

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

-->

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://www.xmpp.org/extensions'
    xmlns='http://www.xmpp.org/extensions'
    elementFormDefault='qualified'>

  <xs:element name='xep'>
    <xs:annotation>
      <xs:documentation>

        This schema defines the document format for XMPP Extension
        Protocols (XEPs). For further information about XEPs, visit:

           http://www.xmpp.org/extensions/

        The canonical URL for this schema is:

           http://www.xmpp.org/extensions/xep.xsd

      </xs:documentation>
    </xs:annotation>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='header'/>
        <xs:element ref='section1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='header'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='title' type='xs:string'/>
        <xs:element name='abstract' type='xs:string'/>
        <xs:element ref='legal'/>
        <xs:element name='number' type='xs:byte'/>
        <xs:element ref='status'/>
        <xs:element name='lastcall' minOccurs='0' type='xs:string'/>
        <xs:element name='interim' minOccurs='0' type='empty'/>
        <xs:element ref='type'/>
        <xs:element name='sig' type='xs:string'/>
        <xs:element name='approver' type='xs:string'/>
        <xs:element ref='dependencies'/>
        <xs:element ref='supersedes'/>
        <xs:element ref='supersededby'/>
        <xs:element name='shortname' type='xs:NCName'/>
        <xs:element ref='schemaloc' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element name='registry' minOccurs='0' type='empty'/>
        <xs:element name='discuss' minOccurs='0' type='xs:string'/>
        <xs:element name='expires' minOccurs='0' type='xs:string'/>
        <xs:element ref='author' minOccurs='1' maxOccurs='unbounded'/>
        <xs:element ref='revision' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='legal'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='copyright' type='markup'/>
        <xs:element name='permissions' type='markup'/>
        <xs:element name='warranty' type='markup'/>
        <xs:element name='liability' type='markup'/>
        <xs:element name='conformance' type='markup'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='status'>
    <xs:simpleType>
      <xs:restriction base='xs:NCName'>
        <xs:enumeration value='Active'/>
        <xs:enumeration value='Deferred'/>
        <xs:enumeration value='Deprecated'/>
        <xs:enumeration value='Draft'/>
        <xs:enumeration value='Experimental'/>
        <xs:enumeration value='Final'/>
        <xs:enumeration value='Obsolete'/>
        <xs:enumeration value='Proposed'/>
        <xs:enumeration value='ProtoXEP'/>
        <xs:enumeration value='Rejected'/>
        <xs:enumeration value='Retracted'/>
      </xs:restriction>
    </xs:simpleType>
  </xs:element>

  <xs:element name='type'>
    <xs:simpleType>
      <xs:restriction base='xs:string'>
        <xs:enumeration value='Historical'/>
        <xs:enumeration value='Humorous'/>
        <xs:enumeration value='Informational'/>
        <xs:enumeration value='Procedural'/>
        <xs:enumeration value='Standards Track'/>
      </xs:restriction>
    </xs:simpleType>
  </xs:element>

  <xs:element name='dependencies'>
    <xs:complexType>
      <xs:sequence minOccurs='0' maxOccurs='unbounded'>
        <xs:element name='spec' type='xs:string'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='supersedes'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='spec' type='xs:string'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='supersededby'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='spec' type='xs:string'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='schemaloc'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='ns' type='xs:string' minOccurs='0'/>
        <xs:element name='url' type='xs:string'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='author'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='firstname' type='xs:string'/>
        <xs:element name='surname' type='xs:string'/>
        <xs:element name='authornote' type='empty' minOccurs='0'/>
        <xs:element name='org' type='xs:string' minOccurs='0'/>
        <xs:element name='email' type='xs:string' minOccurs='0'/>
        <xs:element name='jid' type='xs:string' minOccurs='0'/>
        <xs:element name='uri' type='xs:string' minOccurs='0'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='revision'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='version' type='xs:string'/>
        <xs:element name='date' type='xs:dateTime'/>
        <xs:element name='initials' type='xs:NCName'/>
        <xs:element ref='remark'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='remark'>
    <xs:complexType>
      <xs:choice>
        <xs:element ref='p' minOccurs='0' maxOccurs='1'/>
        <xs:element ref='ul' minOccurs='0' maxOccurs='1'/>
      </xs:choice>
    </xs:complexType>
  </xs:element>

  <xs:element name='section1'>
    <xs:complexType>
      <xs:choice maxOccurs='unbounded'>
        <xs:element ref='code' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='div' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='dl' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='example' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='ol' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='p' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='section2' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='table' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='ul' minOccurs='0' maxOccurs='unbounded'/>
      </xs:choice>
      <xs:attribute name='topic' type='xs:string' use='required'/>
      <xs:attribute name='anchor' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='section2'>
    <xs:complexType>
      <xs:choice maxOccurs='unbounded'>
        <xs:element ref='code' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='div' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='dl' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='example' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='ol' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='p' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='section3' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='table' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='ul' minOccurs='0' maxOccurs='unbounded'/>
      </xs:choice>
      <xs:attribute name='topic' type='xs:string' use='required'/>
      <xs:attribute name='anchor' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='section3'>
    <xs:complexType>
      <xs:choice maxOccurs='unbounded'>
        <xs:element ref='code' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='div' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='dl' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='example' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='ol' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='p' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='section4' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='table' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='ul' minOccurs='0' maxOccurs='unbounded'/>
      </xs:choice>
      <xs:attribute name='topic' type='xs:string' use='required'/>
      <xs:attribute name='anchor' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='section4'>
    <xs:complexType>
      <xs:choice maxOccurs='unbounded'>
        <xs:element ref='code' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='div' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='dl' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='example' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='ol' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='p' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='table' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='ul' minOccurs='0' maxOccurs='unbounded'/>
      </xs:choice>
      <xs:attribute name='topic' type='xs:string' use='required'/>
      <xs:attribute name='anchor' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='div'>
    <xs:complexType>
      <xs:choice maxOccurs='unbounded'>
        <xs:element ref='div' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='p' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='example' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='code' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='ul' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='ol' minOccurs='0' maxOccurs='unbounded'/>
      </xs:choice>
      <xs:attribute name='class' type='xs:string' use='optional'/>
      <xs:attribute name='style' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='p' type='markup'/>

  <xs:element name='ul'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='li' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:attribute name='class' type='xs:string' use='optional'/>
      <xs:attribute name='style' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='ol'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='li' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:attribute name='class' type='xs:string' use='optional'/>
      <xs:attribute name='start' type='xs:byte' use='optional'/>
      <xs:attribute name='style' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='li' type='markup'/>

  <xs:element name='dl'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='di' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='di'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='dt' minOccurs='1' maxOccurs='1'/>
        <xs:element ref='dd' minOccurs='1' maxOccurs='1'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

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

  <xs:element name='dd' type='markup'/>

  <xs:element name='img'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='source' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='link'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='xs:string'>
          <xs:attribute name='url' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='note' type='markup'/>

  <xs:element name='example'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='xs:string'>
          <xs:attribute name='caption' use='optional'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='code'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='xs:string'>
          <xs:attribute name='caption' use='optional'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='table'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='tr' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:attribute name='caption' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='tr'>
    <xs:complexType>
      <xs:choice>
        <xs:element ref='th' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element ref='td' minOccurs='0' maxOccurs='unbounded'/>
      </xs:choice>
    </xs:complexType>
  </xs:element>

  <xs:element name='th'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='xs:string'>
          <xs:attribute name='colspan' use='optional'/>
          <xs:attribute name='rowspan' use='optional'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='td'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='xs:string'>
          <xs:attribute name='colspan' use='optional'/>
          <xs:attribute name='rowspan' use='optional'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:complexType name='markup' mixed='true'>
    <xs:choice minOccurs='0' maxOccurs='unbounded'>
      <xs:element name='br' type='empty'/>
      <xs:element name='cite' type='xs:token'/>
      <xs:element name='dfn' type='xs:token'/>
      <xs:element name='em' type='xs:token'/>
      <xs:element ref='img'/>
      <xs:element ref='link'/>
      <xs:element ref='note'/>
      <xs:element name='span' type='xs:token'/>
      <xs:element name='strong' type='xs:token'/>
      <xs:element name='tt' type='xs:token'/>
    </xs:choice>
    <xs:attribute name='class' type='xs:string' use='optional'/>
    <xs:attribute name='style' type='xs:string' use='optional'/>
  </xs:complexType>

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

</xs:schema>

Appendices

Appendix A: Document Information¶

Series

XEP

Number

0001

Publisher

XMPP Standards Foundation

Status

Active

Type

Procedural

Version

1.25.0

Last Updated

2024-03-11

Approving Body

XSF Board of Directors

Dependencies

None

Supersedes

None

Superseded By

None

Short Name

N/A

Source Control

HTML

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/

Dave Cridland

Email

dave@hellopando.com

JabberID

dwd@dave.cridland.net

Ralph Meijer

Email

ralphm@ik.nu

JabberID

ralphm@ik.nu

Appendix C: Legal Notices¶

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 by the membership of the XSF might also be appropriate (see <https://mail.jabber.org/mailman/listinfo/members> for details).

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¶

Appendix H: Revision History¶

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

1. Version 1.25.0 (2024-03-11)¶

   Add note that editorial changes do not affect Deferred state

   XEP Editor: dg
2. Version 1.24.0 (2021-08-24)¶

   Change "Draft" to "Stable".

   ssw
3. Version 1.23.1 (2019-10-19)¶

   Change Organizational type in schema for Procedural

   mb
4. Version 1.23.0 (2019-01-17)¶

   Clarify proposing Deferred XEPs for advancement to Draft and introduce the role of Document Shepherd.

   rm
5. Version 1.22.0 (2018-11-08)¶

   Officially allow moving XEPs back to Experimental after Last Call.

   jsc
6. Version 1.21.1 (2016-11-16)¶

   Remove dead links.

   ssw
7. Version 1.21rc1 (2014-02-25)¶
   • Made the Approving Body a generic term in the Publication Process.
   • Changed the period for objections such that it falls under the Approving Body's rules.
   • Added a requirement for the Approving Body to initiate a poll for objections within 14 days.
   • Changed the approving body for Humorous XEPs to the XMPP Extensions Editor.
   dwd
8. Version 1.20 (2010-03-10)¶
   • Changed the period for Council objections to submitted proposals (ProtoXEPs) from 7 days to 14 days.
   • Changed the period for Last Calls from 10 days to 14 days.
   • Changed the period for automatic deferral of an Experimental XEP from 6 months to 12 months.
   • Changed the holding period for advancement from Draft to Final from 60 days to 6 months.
   • Clarified that the Editor is the canonical target for all submissions, not necessarily all questions related to the XSF's standards process.
   • Clarified that only changes in Draft and Final XEPs that could reasonably be construed as material must be reviewed and voted on by the XMPP Council, thus exempting correction of typographical errors, minor clarifications, and other such errata.
   • Clarified that the Council has ultimate authority over Draft, Final, and Active XEPs, and can demand the reversal of any changes made to XEPs in those states by the XMPP Extensions Editor or the XEP author.
   • Clarified that Council review is mandatory (not just recommended) regarding IANA registrations initiated by the XMPP Registrar.
   • Updated some references and added some links.
   psa
9. Version 1.19 (2008-01-23)¶

   Updated to reflect version 1.4 of the XSF IPR Policy.

   psa
10. Version 1.18 (2006-12-07)¶

    Clarified meaning of Experimental, Draft, and Final states.

    psa
11. Version 1.17 (2006-10-04)¶

    As approved by the members of the XMPP Standards Foundation, changed Jabber Enhancement Proposal to XMPP Extension Protocol.

    psa
12. Version 1.16 (2006-06-23)¶

    Clarified and simplified the state charts based on implementation experience; summarized state definitions.

    psa
13. Version 1.15 (2004-11-02)¶

    Specified that a Standards Track specification defines either (1) a wire protocol or (2) a protocol suite.

    psa
14. Version 1.14 (2004-09-28)¶

    Defined Procedural type as the union of SIG Formation type and certain Informational specifications in order to clarify the categories; added Modifications to Approved Specifications section in order to make explicit existing Council practices regarding Active and Final specifications; specified that documents on which voting was not complete at the end of a Council term shall undergo a second Last Call and subsequent vote by the new Council; modified Proposal Process to specify that the Jabber Council shall issue Last Calls on documents for which it is the approving body, with all discussion to occur on the Standards list; updated the schema.

    psa
15. Version 1.13 (2004-08-24)¶

    Further specified the goals of the standards process; mentioned Board-approved specifications.

    psa
16. Version 1.11 (2004-07-14)¶

    Specified the procedure for changing a XEP from Historical to Standards Track.

    psa
17. Version 1.10 (2004-03-24)¶

    Specified the procedure for acceptance of a proposal as a XEP; clarified the XEP types; completed editorial review.

    psa
18. Version 1.9 (2003-12-22)¶

    Added rule about automatic deferral of inactive specifications.

    psa
19. Version 1.8 (2003-10-06)¶

    Clarified the definition of informational specification.

    psa
20. Version 1.7 (2003-04-11)¶

    Added status of Retracted; corrected several errors related to the XMPP Registrar.

    psa
21. Version 1.6 (2003-01-08)¶

    Further clarified the proposal process per discussion on the members list.

    psa
22. Version 1.5 (2002-10-29)¶

    Major revision based on experience. In addition to a reorganization of the content to improve the clarity of the presentation, changes include: (1) no anonymous authors; (2) proposal must be seconded by at least 5% of XSF members before being proposed for a Council vote; (3) clarification that the Council votes only on a particular revision of a specification (e.g., version 1.3 when proceeding from Draft to Final); (4) added information about the "Call for Experience" phase before proceeding from Draft to Final; (5) added reference to RFC 2119; (6) added sections for security considerations, IANA considerations, and XMPP Registrar considerations. Approved by the XSF Board and Jabber Council on 2002-11-20.

    psa
23. Version 1.4 (2002-01-16)¶

    Added information about the new "Experimental" state for Standards Track specifications and made appropriate changes to the standards process.

    psa
24. Version 1.3.1 (2002-01-11)¶

    Added link to DTD.

    psa
25. Version 1.3 (2001-10-23)¶

    (1) Added information about the "cooling off" period before a Standards Track specification may be advanced from Draft to Final; (2) Added a link to the template file; (3) Performed several minor fixes.

    psa
26. Version 1.2 (2001-09-27)¶

    (1) Added information about expiration dates; (2) Added a status of Deprecated to Standards Track specifications.

    psa
27. Version 1.1 (2001-09-09)¶

    (1) Changed "Jabber Foundation" to "XMPP Standards Foundation"; (2) Changed "SIG Proposal" to "SIG Formation"; (3) Removed reference to the Secretary of the XMPP Standards Foundation in connection with the role of Editor; (4) Clarified the possible states of acceptance of each kind of specification and described in greater detail the criteria for advancement from one state to another.

    psa
28. Version 1.0 (2001-07-09)¶

    Changed status to Active.

    psa
29. Version 0.1 (2001-06-28)¶

    Initial release -- a simplified and updated version of Rahul Dave's Jabberization of the process and format for Python Enhancement Proposals

    psa

Appendix I: Bib(La)TeX Entry

@report{saint-andre2001n/a,
  title = {XMPP Extension Protocols},
  author = {Saint-Andre, Peter and Cridland, Dave and Meijer, Ralph},
  type = {XEP},
  number = {0001},
  version = {1.25.0},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-0001.html},
  date = {2001-06-28/2024-03-11},
}

END