XEP-0053: XMPP Registrar Function

Abstract:This document defines the roles and processes of the XMPP Registrar function within the XMPP Standards Foundation.
Author:Peter Saint-Andre
Copyright:© 1999 - 2016 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:Active
Type:Procedural
Version:1.5
Last Updated:2016-05-31

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 and Purpose
2. Composition
3. Registry Creation and Maintenance
4. Namespace Issuance
5. Security Considerations
6. IANA Considerations
7. XMPP Registrar Considerations

Appendices
    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 and Purpose

Because the XMPP Standards Foundation (XSF) [1] publishes a relatively large number of protocol specifications (see XMPP Extension Protocols (XEP-0001) [2]), it is important to keep track of the namespaces defined by those specifications as well as the parameters used in the context of the relevant protocols. (Examples of such parameters include the features and options used in Feature Negotiation (XEP-0020) [3] and the identities and features used in Service Discovery (XEP-0030) [4].) In particular, the common use of protocols published by the XSF requires that namespaces and particular parameter values be assigned uniquely. It is the role of the XMPP Registrar to make those unique assignments and to maintain registries of the currently assigned values. The XMPP Registrar shall also function as a single point of contact between the XMPP Standards Foundation and the Internet Assigned Numbers Authority (IANA) [5].

2. Composition

Until there is a perceived need for a more formal governing body, the functions of the XMPP Registrar shall be managed by the XMPP Extensions Editor [6]. In the future, the XMPP Council [7] and/or the XSF Board of Directors [8] may decide to create a more formal panel to oversee the functions of the XMPP Registrar; if they do, this document shall be updated to reflect the change.

3. Registry Creation and Maintenance

Every XMPP Extension Protocol specification (XEP) must contain a section devoted to "XMPP Registrar Considerations", detailing the namespaces and parameters to be registered with the XMPP Registrar, as well as any new registries to be created as a result of the XEP.

Registry entries have either a status of 'Proposed' or 'Standard'. Entries of an experimental XEP are added by the XMPP Registar to the registry in the 'Proposed' Status. The registry additions or creations specified in a XEP shall not transition to 'Standard' status until the document advances to a status of Draft (Standards-Track XEPs) or Active (Informational and Historical XEPs). Registration of namespaces shall be handled as described in the Namespace Issuance section of this document. Registration of particular parameters used within a specification shall be initiated by the XMPP Extensions Editor if specified in the XEP, and may also be initiated by implementors of the XEP after it has advanced to Active, Draft, or Final. Creation of new registries shall be initiated by the XMPP Registrar; if a document specifies the creation of a new registry, the author is strongly encouraged to consult with the XMPP Registrar before seeking a Last Call on the XEP.

Requests for parameter assignments must be sent to the XMPP Registrar in accordance with the process specified in the document (usually a XEP) that defines the relevant registry, normally by sending an appropriately formatted email message to the URI <mailto:registrar@xmpp.org>. If, in the Registrar's judgment, discussion of a request is required, the Registrar shall initiate such discussion within the Standards SIG [9]. The Registrar shall add registry items at its discretion based on discussion within the Standards SIG if necessary, but shall not unduly restrict registration of parameter values. If a document author or implementor thinks that a request was unfairly denied by the Registrar, an appeal of the decision may be directed to the XMPP Council.

The XMPP Registrar shall maintain registries of assigned namespaces and parameters at <http://www.xmpp.org/registrar/> and shall update those registries in a timely fashion. Changes to the registries shall be announced on the <standards@xmpp.org> mailing list.

4. Namespace Issuance

The XMPP Registrar shall be responsible for issuing namespaces to be used in XMPP Extension Protocols (XEPs) developed through the XMPP Standards Foundation's standards process as specified in XEP-0001. The policies and procedures for namespace issuance shall be as follows:

  1. When a XEP is first published in the Experimental state, the XMPP Registrar shall work with the author(s) to mint an appropriate namespace name, which shall be of the form "urn:xmpp:ShortName:0" or, where appropriate, "urn:xmpp:ShortName:SubName:0". The newly minted name shall be added by the XMPP Registrar as 'Proposed' to the registry. The following considerations apply:

    1. Each name shall adhere to the format defined in RFC 4854 [10].
    2. Each name shall be of the form "urn:xmpp:ShortName[:SubName]".
    3. The "ShortName" string shall be unique within the XMPP URN tree and any "SubName" strings shall be unique within the scope of the ShortName.
    4. Each name should be relevant and memorable. Names may be determined in consultation with the author(s) of the XEP and may be requested by the author(s) in the XMPP Registrar Considerations section of the XEP; however, the issuance of namespace names is the sole responsibility of the XMPP Registrar, which may modify or ignore any names requested.
    5. To ensure that no duplicate names are issued, each name to be minted shall be checked against the registry of registered names issued in both states: 'Proposed' and 'Standard'.
    6. The XMPP Registrar shall issue all XMPP URNs directly and shall not assign secondary responsibility for management of any sub-trees.

  2. While the XEP is in the Experimental state, if appropriate and in consultation with the author(s), the XMPP Registrar shall update the namespace version number at the end of namespace (e.g., from "0" to "1"); the XMPP Registrar shall do so only if the protocol defined in the XEP has been modified in a way that is not backwards-compatible with an earlier version of the protocol.

  3. When the XMPP Council votes to advance the XEP to a status of Draft, the XMPP Registrar shall update the namespace registry in accordance with the procedures specified in the Registry Creation and Maintenance section of this document.

  4. Any namespaces defined after advancement of the relevant XEP to a status of Draft shall be handled in the same manner.

  5. While the XEP is in the Draft or Final state, if appropriate and in consultation with the author(s) and the XMPP Council, the XMPP Registrar shall update the namespace version number at the end of namespace (e.g., from "1" to "2"); the XMPP Registrar shall do so only if the protocol defined in the XEP has been modified in a way that is not backwards-compatible with an earlier version of the protocol, or if significant new features have been added to the protocol. The XMPP Council must approve any change to the namespace version while the XEP is in the Draft or Final state.

The XMPP Registrar shall not issue XMPP URNs except as specified above (e.g., it shall not issue XMPP URNs to private parties or in relation to specifications that are not published in the XEP series). However, the XMPP Registrar may at its discretion add namespace names other than XMPP URNs to its namespace registry, e.g. to register "legacy" namespace names (of the form "jabber:iq:ShortName", "jabber:x:ShortName", and "http://jabber.org/protocol/ShortName" as well as namespace names produced by recognized standards development organizations (such as names issued in the IETF URN tree).

5. Security Considerations

Security considerations are primarily the responsibility of the protocols in which specific parameters are used. The XMPP Registrar shall respect the security considerations defined in XMPP Extension Protocol specifications, and shall endeavor to ensure that registered parameter values do not compromise privacy or security in any way.

6. IANA Considerations

The XMPP Registrar shall be responsible for interacting with the IANA on behalf of the XMPP Standards Foundation. If an XMPP Extension Protocol specification requires interaction with the IANA, that fact shall be noted by the document author(s) and discussed on the Standards mailing list along with normal discussion of the XEP. The XMPP Registrar shall collaborate with the author(s) to submit an appropriate request to the IANA.

7. XMPP Registrar Considerations

This entire document defines the processes and procedures of the XMPP Registrar.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0053
Publisher: XMPP Standards Foundation
Status: Active
Type: Procedural
Version: 1.5
Last Updated: 2016-05-31
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: peter@andyet.net
JabberID: stpeter@stpeter.im
URI: https://stpeter.im/

Appendix C: Legal Notices

Copyright

This XMPP Extension Protocol is copyright © 1999 - 2016 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 <http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/> 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 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 <http://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

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. XEP-0001: XMPP Extension Protocols <http://xmpp.org/extensions/xep-0001.html>.

3. XEP-0020: Feature Negotiation <http://xmpp.org/extensions/xep-0020.html>.

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

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

6. 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/about-xmpp/xsf/xsf-people/#editor>.

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

8. The XSF Board of Directors is an elected body that possesses overall responsibility for the affairs of the XMPP Standards Foundation. For further information, see <http://xmpp.org/xsf/board/>.

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

10. RFC 4854: A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP) <http://tools.ietf.org/html/rfc4854>.

Appendix H: Revision History

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

Version 1.5 (2016-05-31)

Introduce 'Proposed' registration status.

(fs)

Version 1.4 (2008-10-29)

Adjusted namespace issuance process to employ namespace versioning.

(psa)

Version 1.3 (2006-12-07)

Specified process for namespace issuance (i.e., XMPP URNs).

(psa)

Version 1.2 (2006-10-04)

As approved by the members of the XMPP Standards Foundation, changed Jabber Registrar to XMPP Registrar.

(psa)

Version 1.1 (2004-05-20)

Updated to reflect experience. (psa)

Version 1.0 (2003-03-20)

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

Version 0.5 (2003-01-21)

Changed name to XMPP Registrar in response to feedback from the XSF Board of Directors. (psa)

Version 0.4 (2003-01-20)

Added reference to jana@jabber.org mailing list. (psa)

Version 0.3 (2002-11-22)

Simplified to reflect discussion in the XMPP Council; in particular, reserved JANA functions to the XMPP Extensions Editor until there is a perceived need for a more formal governing body. (psa)

Version 0.2 (2002-10-27)

Clarified JANA composition, panel member requirements, and JANA process. (psa)

Version 0.1 (2002-10-24)

Initial version. (psa)

END