XEP-0143: Guidelines for Authors of XMPP Extension Protocols

Abstract:This document provides information intended to assist authors of XMPP Extension Protocols.
Author:Peter Saint-Andre
Copyright:© 1999 - 2011 XMPP Standards Foundation. SEE LEGAL NOTICES.
Last Updated:2010-02-12

NOTICE: This Procedural document defines a process or activity of the XMPP Standards Foundation (XSF) that has been approved by the XMPP Council and/or the XSF Board of Directors. The XSF is currently following the process or activity defined herein and will do so until this document is deprecated or obsoleted.

Table of Contents

1. Introduction
2. Preparation
3. Submission Process
4. XEP XML Format
    4.1. Working With XEP Files
    4.2. File Metadata
    4.3. File Contents
5. The Sections of a XEP Document
    5.1. Introduction
    5.2. Requirements
    5.3. Glossary
    5.4. Use Cases
    5.5. Error Codes
    5.6. Business Rules
    5.7. Implementation Notes
    5.8. Internationalization Considerations
    5.9. Security Considerations
    5.10. IANA Considerations
    5.11. XMPP Registrar Considerations
    5.12. XML Schema
    5.13. Acknowledgements
6. XEP Styleguide
    6.1. Attributes
    6.2. Code Examples
    6.3. Conformance Terms
    6.4. Elements
    6.5. Errors
    6.6. Namespaces

    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

1. Introduction

The XMPP Standards Foundation (XSF) [1] receives a significant number of proposals for defining extensions to the core XMPP protocols specified in XMPP Core [2]. However, it is not always clear to authors how to best structure a proposal in order for it to be accepted as an XMPP Extension Protocol (XEP) and then advance through the XSF's standards process. Therefore, this document provides guidelines that are intended to help authors write better XMPP Extension Protocol specifications.

These guidelines assume that the reader is familiar with the XEP series of documents and the processes for handling them within the XSF, as defined in XMPP Extension Protocols [3].

2. Preparation

The prospective author is strongly encouraged to complete some research before submitting a proposal for consideration as an XMPP Extension Protocol. In particular, the author should do the following:

After completing this research, the prospective author may conclude that a new protocol extension is needed. If so, the author is strongly advised to do the following:

  1. Review XEP-0001 and the XMPP Design Guidelines [8].
  2. Understand the Submission Process.
  3. Become familiar with the XEP XML Format.
  4. Then and only then write a proposal that includes all of the appropriate Sections of a XEP.
  5. Review the content to ensure that it conforms to the XEP Styleguide.

3. Submission Process

The process for submitting a proposal for consideration as an XMPP Extension Protocol is straightforward:

  1. Contact the XMPP Extensions Editor [9] so that he knows to expect your submission.
  2. Write your proposal following the guidelines described herein.
  3. Make sure that you read, understand, and agree to the XSF IPR Policy [10] before you submit your proposal.
  4. Send your XML file (or a URL for the file) to the XMPP Extensions Editor.

4. XEP XML Format

The XEP XML format is substantially similar to a reduced set of XHTML. This is intentional: it makes authoring XMPP Extension Protocol specifications easier. In fact, if you use the template file with its associated XSLT stylesheet, you should be able to view your proposal in most modern web browsers (see below). The following subsections explain how to get started with XEP authoring and describe the XML format used for XMPP Extension Protocols (see the xep.xsd or xep.dtd file for a formal description).

4.1 Working With XEP Files

The best way to start working on your proposal is to retrieve all of the existing XMPP Extension Protocol specifications and associated stylesheets from source control. These files are stored using Subsversion (SVN), in a module labelled 'xmpp' and subdirectory labelled 'extensions' at xmpp.org. Instructions for accessing these files are provided at <http://www.xmpp.org/xsf/sourcecontrol.shtml>. The document structure is formally defined by both a DTD and an XML schema, but you do not need to understand the formal descriptions in order to author an XMPP Extension Protocol. In addition, a handy template file is included as the 'xep-template.xml' file in the 'extensions' directory, providing a quick starting point for XEP authoring.

To create your proposal, do an SVN checkout of the 'xmpp' module, change directories to the 'trunk/extensions/' directory, copy the template file (e.g., 'cp xep-template.xml xep-foo.xml'), and start editing the file using either a basic text editor or a specialized XML editing application such as XML Spy or XMLmind.

Even if you use a basic text editor, you should be able to view your document in most modern web browsers as an XML file as long as you have xep.xsl and xep.dtd in the 'extensions/' directory. Because of inconsistencies in browser XSLT implementations, certain formatting (e.g., table layouts and the numbering of tables, examples, and footnotes) may not be perfect. Don't panic; it will look fine in the HTML output produced by the XMPP Extensions Editor. If your XML file doesn't render at all (i.e., it's just one big text blob), you are using a bad browser. If you see only the bare outline generated by xep.xsl but none of your text, you have an error in your XML. You can check your XML syntax at xml.com [11].

To programatically convert your XML file into HTML, we recommend using Daniel Veillard's xsltproc program, which will give you helpful error messages regarding XML syntax problems. However, the XMPP Extensions Editor will do the final rendering of XML into HTML as well as posting of your HTML file to www.xmpp.org, so you do not need to generate HTML files for submission to the XMPP Extensions Editor (in fact, the XMPP Extensions Editor requires that you submit your proposal in the XEP XML format, not HTML).

Finally, the xep.ent file contains convenient "external entities" that provide shortcuts for including references to XMPP Extension Protocols, RFCs, and other common strings. Unfortunately, most browsers do not correctly process external entities, so you cannot include entities from xep.ent if you need to view your XML source file in a browser. However, the XMPP Extensions Editor reserves the right to convert your markup to external entities, since it makes his life easier. Also, please do not add items to the xep.ent file; instead, ask the XMPP Extensions Editor to add them for you.

4.2 File Metadata

This section describes the metadata elements contained in the <header/> element of a XEP file (see below for the file contents).

The XML character data of the <title/> element is the title of your XEP. Choose a descriptive title that is less than five words long. The XMPP Extensions Editor may change this in consultation with the author.

The XML character data of the <abstract/> element SHOULD be one sentence that captures the essence of your proposal (usually beginning "This specification defines an XMPP protocol extension that..."). The XMPP Extensions Editor has been known to modify the abstract so that it accurately describes the proposal.

The XML character data of the <legal/> element MUST be as defined in the XSF IPR Policy and reflected in both the xep.ent file and the XEP template.

The XML character data of the <number/> element SHOULD be "xxxx"; this will be changed to the next sequential XEP number by the XMPP Extensions Editor if the XMPP Council accepts the proposal as an XMPP Extension Protocol.

The XML character data of the <status/> element SHOULD be "ProtoXEP" since all proposals start out as "proto-XEPs"; this will be changed to "Experimental" if the XMPP Council accepts the proposal as an XMPP Extension Protocol.

The XML character data of the <type/> element SHOULD be either "Standards Track" or "Informational" (there are also Historical, Humorous, and Procedural XEPs, but these are uncommon and usually written by the XMPP Extensions Editor). A Standards Track XEP defines an XMPP extension intended to be used as a common part of Jabber/XMPP technologies. An Informational XEP defines best practices or a usage profile related to XMPP or an XMPP Extension Protocol (e.g., Best Practices for Use of SASL ANONYMOUS [12]).

The XML character data of the <approver/> element SHOULD be "Council".

The <dependencies/> element is used to specify RFCs, XMPP Extension Protocols, and other specifications on which your proposal depends in a normative fashion (i.e., specifications that MUST or SHOULD be understood in order to implement your proposed protocol). Each specification MUST be identified by a distinct <spec/> child element (see existing XEP specifications for clues regarding document identifiers, or consult with the XMPP Extensions Editor).

The <supersedes/>, <supersededby/>, <shortname/>, and <schemaloc/> elements are for use by the XMPP Extensions Editor; however, if your document supersedes an existing XMPP Extension Protocol, feel free to include a <spec/> child element specifying the document identifier (e.g., XEP-0093) for the protocol that is being superseded.

Include one <author/> element for each co-author. Note well that the <firstname/> and <surname/> elements are REQUIRED per XEP-0001, as is some combination of the <email/>, <jid/>, and <uri/> elements so that appropriate contact information is available.

Include one <revision/> element for each revision of your document. The XML character data of the <version/> element SHOULD be "0.0.1" for your initial submission to the XMPP Extensions Editor, and the <remark/> SHOULD be "First draft."; for each revision, you will include another <revision/> element (place it before the existing <revision/> elements) and iterate the <version/> element (e.g., "0.0.2" after "0.0.1" or "0.7" after "0.6"). The format for the <date/> element is yyyy-mm-dd. Please do not include the characters ' or " in your revision remarks.

4.3 File Contents

Aside from the metadata in the <header/> element (see above), a XEP file is a series of sections, arranged in a hierarchy (<section1/> is a top-level section, within which you can nest <section2/> sections, and so on down to <section4/>). The title of a section is captured in the 'topic' attribute. You should also include an 'anchor' attribute so that you can link to page fragments from within your document. The allowable elements within a section element probably look familiar from XHTML: <p/> for paragraphs, <ol/> and <ul/> for ordered and unordered lists, and so on.

The <example/> and <code/> elements are used to show protocol snippets; the <example/> element SHOULD possess a 'caption' attribute that describes the example, whereas the <code/> element does not. Define an XML CDATA section within both of these elements so that you do not need to escape the '<' and '>' characters in your sample XML stanzas, since this makes life much easier for author and editor alike (see the markup in existing XEP specifications).

The <p/> and <li/> elements can also contain more markup that is familiar from XHTML, such as the <img/> element. Note that hyperlinks are of the form <link url='foo'>bar</link> rather than <a href='foo'>bar</a>; the reasons for this are lost in the mists of time and it is too late to change it now, so you'll just have to adjust. If needed, you can also use inline structural and presentational markup such as <em/>, <strong/>, <tt/>, <cite/>, and <span/> within the <p/> and <li/> elements.

You may also include tables (these are helpful for listing error codes and such). The <table/> element SHOULD possess a 'caption' attribute that describes the table's contents. Standard XHTML table structure applies (<tr/> defines a row, which contains <th/> elements for header rows and <td/> elements for data rows), and the 'colspan' and 'rowspan' attributes are also available if you need them. Table presentation (such as cellpadding and cellspacing) is handled by the XSLT and CSS stylesheets. However keep in mind that tables weren't mend to display huge amount of text.

In fact, the xep.xsl file performs all sorts of magic in converting your XML file into HTML, including creation of the front matter, table of contents, section numbering, notes, and revision history. Feel free to submit patches for this file, but do not commit your modified version to source control.

While HTML being the primary publishing format for XEPs, the XSF Editor also publishes XEPs in form of PDF since 2009. Keeping that in mind you should try to avoid tables with too much columns which require more width available on paper.

5. The Sections of a XEP Document

Most XEP specifications will have most of the following sections, usually in something like the order shown. Other sections may be appropriate (e.g., XHTML-IM [13] has a section for W3C Considerations). Use your best judgment regarding the sections you need in order to make your argument, or consult with the XMPP Extensions Editor regarding your needs.

5.1 Introduction

The introduction to a XEP document is quite important since it provides the rationale for considering the proposal. In particular, the introduction SHOULD include information such as the following:

  1. Tasks that users currently cannot complete because we are lacking the protocol you propose. (Note: Users are not just IM users, but any person, system, or application that could gain value from interacting with other entities over Jabber/XMPP networks.)
  2. Other projects or protocols and how Jabber/XMPP technologies could interface with them because of your proposed protocol (e.g., XML-RPC, SOAP).
  3. A comparison between Jabber/XMPP technologies and "the competition" (e.g., other IM systems or messaging protocols) that describes holes in the Jabber/XMPP protocols that need to be filled in order to offer similar functionality.
  4. The relevant history of thinking within the Jabber/XMPP community.
  5. Real-world examples of problems the protocol can solve.

5.2 Requirements

Every XEP document SHOULD include a section describing the requirements being addressed by the document. This information is critically important, because it clearly defines the scope of the proposal as well as any relevant constraints on the protocol design.

5.3 Glossary

If your XEP document uses terms that may not be familiar to the reader, please define them in a glossary.

The preferred layout for a glossary is a definition list using the HTML <dl>-tag.

5.4 Use Cases

It is recommended that document authors structure their proposals according to the use cases that the proposal will address. [14] We have found that use cases force authors to focus on functionality rather than "protocol for the sake of protocol". It is also helpful to sort use cases by actor, as is done in Multi-User Chat [15], for example. Include one subsection for each use case.

When writing use cases and the associated protocols, make sure to:

We just said so, but we will repeat ourselves: include lots of protocol examples. Examples help not only implementors but also those who will review your proposal in the Standards SIG and XMPP Council. You get extra credit with the XMPP Extensions Editor if you follow Jabber tradition by using characters and situations from the plays of Shakespeare:

Example 1. An Example from Shakespeare

  <body>Wherefore art thou, Romeo?</body>

5.5 Error Codes

If your proposal defines a number of error and status codes (as is done in XEP-0045), it is a good idea to include a table of all the codes defined in your document.

5.6 Business Rules

You may want to include a section describing various business rules (essentially, a variety of MUSTs, SHOULDs, and MAYs regarding application behavior). This is not required but can be helpful to implementors.

5.7 Implementation Notes

You may want to include a section devoted to implementation notes. Again, this is not required but can be helpful to implementors.

5.8 Internationalization Considerations

If there are any internationalization or localization issues related to your proposal (e.g., whether to include the 'xml:lang' attribute), define them in this optional section.

5.9 Security Considerations

Your proposal MUST include a section entitled "Security Considerations". Even if there are no security features or concerns related to your proposal, you MUST note that fact. For helpful guidelines, refer to RFC 3552 [17].

5.10 IANA Considerations

This section is REQUIRED. The IANA is the Internet Assigned Numbers Authority, the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. Most proposals do not require interaction with the IANA, in which case the text of this section SHOULD read "This document requires no interaction with the Internet Assigned Numbers Authority (IANA)." If your proposal requires interaction with the IANA, discuss the matter with the XMPP Extensions Editor. Do not contact the IANA on your own!

5.11 XMPP Registrar Considerations

This section is REQUIRED. The XMPP Registrar maintains a list of reserved Jabber/XMPP protocol namespaces as well as registries of parameters used in the context of protocols approved by the XMPP Standards Foundation. If your proposal does not require interaction with the XMPP Registrar, the text of this section SHOULD read "No namespaces or parameters need to be registered with the XMPP Registrar as a result of this document." Refer to Draft or Final XEPs for appropriate text in other cases, or consult with the XMPP Extensions Editor.

5.12 XML Schema

An XML Schema is required in order for protocols to be approved by the XMPP Council. The XMPP Extensions Editor can assist you in defining an XML Schema for the protocol you are proposing.

5.13 Acknowledgements

Some XEP documents end with a section thanking non-authors who have made significant contributions to the specification; if that is true of your document, feel free to include this section.

6. XEP Styleguide

Note: Authors of XMPP Extension Protocol specifications can consider this section as a kind of "Implementation Notes". :-)

XMPP Extension Protocols are written in English. It is not expected that you will be a fine prose writer, but try to write in a clear, easily-understood fashion. The XMPP Extensions Editor will correct any errors of grammar, spelling [18], punctuation, and usage he may find in your proposal, but may not do so until your proposal is in the XMPP Council's queue for advancement to Draft or Active. In addition, the XMPP Extensions Editor reserves the right to improve phrases that are unclear or infelicitous, move sections around, modify examples to use Shakespearean characters, and otherwise improve the argument and logical flow of your proposal (naturally, without changing the meaning).

The following styleguide is provided to supplement the standard English styleguides, such as The Elements of Style [19] and The Chicago Manual of Style [20]; please refer to those resources for information about common English (especially American English) usage and to this styleguide for XEP-specific guidelines.

6.1 Attributes

When talking about an attribute by name, refer to it in single quotes. Example: the 'to' attribute.

When talking about the value of an attribute, refer to it in double quotes. Example: the value of the 'subscription' attribute is "both".

Elements possess attributes and contain character data and/or child elements; do not confuse these terms.

6.2 Code Examples

In examples, use single quotes rather than double quotes; they are more readable.

To show the hierarchy of XML elements, indent two spaces for every level.

If an element possesses multiple attributes, please show them in the order dictated by Canonical XML [21].

If an element possesses a large number of attributes, include a line break before each attribute and indent them so that they are vertically aligned for readability.

If the XML character data of an element is long, include line breaks and indent by two spaces.

Examples are the major source of right-scrolling in our HTML output files. Right-scrolling is evil. Therefore, adjust your example layouts accordingly (line widths should be no more than 110 characters or so).


<iq from='darkcave@macbeth.shakespeare.lit' 
  <query xmlns='http://jabber.org/protocol/muc#roomconfig'>
    <x xmlns='jabber:x:data' type='form'>
      <title>Configuration for "darkcave" Room</title>
        Please complete this form to make changes to the configuration 
        of your room; to add room owners and administrators, use the 
        appropriate room commands rather than this form.
      <field type='hidden' var='FORM_TYPE'>

Some examples (e.g., avatar examples) include strings that are SHA-1 hashes (see RFC 3174 [22]). An easy way to generate these is to use the OpenSSL "dgst" command to generate the SHA-1 hash. For example, the following command will generate the SHA-1 hash "9f5f9fdab9da7fc12e3c52b258acbcb4bb8e66ac":

echo -n 'bard@shakespeare.lit' | openssl dgst -hex -sha1

Some examples (e.g., SASL examples) include strings that are encoded using Base64 (see RFC 3548 [23]). An easy way to generate these is to use the OpenSSL "enc" command to generate the base64-encoded equivalent. For example, the following command will generate the base64-encoded string "YmFyZEBzaGFrZXNwZWFyZS5saXQ=":

echo -n 'bard@shakespeare.lit' | openssl enc -nopad -base64

6.3 Conformance Terms

Conformance terms (e.g,, "MUST" and "SHOULD") are specified in RFC 2119. Use them. When such terms are not in ALL CAPS, the special conformance sense does not apply. [24]

6.4 Elements

When talking about an element by name, refer to it as an empty XML element. Example: the <query/> element.

The top-level <message/>, <presence/>, and <iq/> elements are actually XML stanzas (see RFC 3920); please refer to them as stanzas, not elements.

Elements possess attributes and contain character data and/or child elements; do not confuse these terms.

Do not use the term "tag" when you mean "element".

Do not add a possessive to the element itself. Negative example: the <body/>'s character data. Positive example: the <body/> element's character data.

Note: There are shortcuts for stanza names and some common element names in the xep.ent file.

6.5 Errors

When talking about an error condition, use the XML element names defined in RFC 3920 rather than the old HTTP-style code numbers. Example: the <feature-not-implemented/> error.

Note: There are shortcuts for the stanza errors in the xep.ent file.

6.6 Namespaces

When talking about a namespace by name, refer to it in single quotes. Example: the 'jabber:iq:roster' namespace.

An element or attribute is qualified by (rather than "scoped by" or "in") a particular namespace.


For precision, the XSF follows IETF usage by placing all punctuation outside the quotation marks unless one is quoting text that includes the punctuation. Example: the port used for client communications is "5222".


Appendix A: Document Information

Series: XEP
Number: 0143
Publisher: XMPP Standards Foundation
Status: Active
Type: Procedural
Version: 1.1rc1
Last Updated: 2010-02-12
Approving Body: XMPP Council
Dependencies: XEP-0001
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@jabber.org
JabberID: stpeter@jabber.org
URI: https://stpeter.im/

Appendix C: Legal Notices


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


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 <http://xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the 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 <http://xmpp.org/about/discuss.shtml> 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. The XMPP Standards Foundation (XSF) is an independent, non-profit membership organization that develops open extensions to the IETF's Extensible Messaging and Presence Protocol (XMPP). For further information, see <http://xmpp.org/xsf/>.

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

3. XEP-0001: XMPP Extension Protocols <http://xmpp.org/extensions/xep-0001.html>.

4. The XMPP Council is a technical steering committee, authorized by the XSF Board of Directors and elected by XSF members, that approves of new XMPP Extensions Protocols and oversees the XSF's standards process. For further information, see <http://xmpp.org/council/>.

5. The Internet Engineering Task Force is the principal body engaged in the development of new Internet standard specifications, best known for its work on standards such as HTTP and SMTP. For further information, see <http://www.ietf.org/>.

6. The World Wide Web Consortium defines data formats and markup languages (such as HTML and XML) for use over the Internet. For further information, see <http://www.w3.org/>.

7. The Standards SIG is a standing Special Interest Group devoted to development of XMPP Extension Protocols. The discussion list of the Standards SIG is the primary venue for discussion of XMPP protocol extensions, as well as for announcements by the XMPP Extensions Editor and XMPP Registrar. To subscribe to the list or view the list archives, visit <http://mail.jabber.org/mailman/listinfo/standards/>.

8. XEP-0134: XMPP Design Guidelines <http://xmpp.org/extensions/xep-0134.html>.

9. The XMPP Extensions Editor is the individual appointed by the XSF Board of Directors to handle protocol submissions and provide day-to-day management of the XSF's standards process. For further information, see <http://xmpp.org/extensions/editor.shtml>.

10. The XSF IPR Policy defines the XMPP Standards Foundation's official policy regarding intellectual property rights (IPR) as they pertain to XMPP Extension Protocols (XEPs). For further information, see <http://xmpp.org/extensions/ipr-policy.shtml>.

11. <http://www.xml.com/pub/a/tools/ruwf/check.html>

12. XEP-0175: Best Practices for Use of SASL ANONYMOUS <http://xmpp.org/extensions/xep-0175.html>.

13. XEP-0071: XHTML-IM <http://xmpp.org/extensions/xep-0071.html>.

14. A good introduction to use cases may be found at <http://www.pols.co.uk/usecasezone/>.

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

16. Our mantra is: "We put the example in example.com!"

17. RFC 3552: Guidelines for Writing RFC Text on Security Considerations <http://tools.ietf.org/html/rfc3552>.

18. With all due respect to authors in other parts of the world, XMPP Extension Protocols follow American spelling conventions; thus "authorisation" will be changed to "authorization" and such.

19. See <http://en.wikipedia.org/wiki/The_Elements_of_Style>.

20. See <http://en.wikipedia.org/wiki/The_Chicago_Manual_of_Style>.

21. Canonical XML 1.0 <http://www.w3.org/TR/xml-c14n>.

22. RFC 3174: US Secure Hash Algorithm 1 (SHA1) <http://tools.ietf.org/html/rfc3174>.

23. RFC 3548: The Base16, Base32, and Base64 Data Encodings <http://tools.ietf.org/html/rfc3548>.

24. This point should be obvious but may be confusing to some XEP authors, so we must mention it explicitly. ;-)

Appendix H: Revision History

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

Version 1.1rc1 (2010-02-12)

Use of definition list for glossary, best practice on table usage and reminder on PDF publications.


Version 1.0 (2004-12-09)

Per a vote of the XMPP Council, advanced status to Active.


Version 0.4 (2004-10-22)

Further clarifications.


Version 0.3 (2004-10-12)

Minor clarifications throughout.


Version 0.2 (2004-09-16)

Described document metadata elements.


Version 0.1 (2004-09-15)

Initial version.