From 8590e2c4be1363ade9ccc8b9fac9b6ce5b6e46dc Mon Sep 17 00:00:00 2001
From: Peter Saint-Andre The XMPP Standards Foundation (XSF) develops extensions to XMPP through a standards process centered around XMPP Extension Protocols (XEPs). The process is managed by the XMPP Extensions Editor and involves intensive discussion on the Standards mailing list, formal review and voting by the XMPP Council, and modification based on implementation experience and interoperability testing. All documents in the XEP series are available under a liberal IPR Policy for wide implementation. Submissions are welcome (see also the "inbox"). Changes are tracked via a CVS repository (see instructions), old versions are available, and IETF-style XML reference files are provided. The XMPP Standards Foundation (XSF) develops extensions to XMPP through a standards process centered around XMPP Extension Protocols (XEPs). The process is managed by the XMPP Extensions Editor and involves intensive discussion on the Standards mailing list, formal review and voting by the XMPP Council, and modification based on implementation experience and interoperability testing. All documents in the XEP series are available under a liberal IPR Policy for wide implementation. Submissions are welcome (see also the "inbox"). Changes are tracked via a CVS repository (see instructions), old versions are available, and IETF-style XML reference files are provided. This page lists approved XMPP extensions as well as proposals that are under active consideration. A list of all XEPs (including retracted, rejected, deprecated, and obsolete XEPs) is also available. Good places for developers to start are the basic and intermediate protocol suites. 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. The registry additions or creations specified in an XMPP Extension Protocol specification shall not take effect 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 XMPP Extension Protocol document 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 <mailto:registrar@jabber.org>. If, in the Registrar's judgment, discussion of a request is required, the Registrar shall initiate such discussion within the &SSIG;. 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. 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 <mailto:registrar@xmpp.org>. If, in the Registrar's judgment, discussion of a request is required, the Registrar shall initiate such discussion within the &SSIG;. 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 mailing list. These functions are specified below. Periodically, people send mail to editor@jabber.org with new proposals. Here is how to process such submissions. Periodically, people send email to editor@xmpp.org with new proposals. Here is how to process such submissions. announce.py This script announces a new version of a XEP by updating the database and sending a message to standards-jig@jabber.org. This script announces a new version of a XEP by updating the database and sending a message to standards@xmpp.org. deferrred.py This script updates the database and sends a message to standards-jig@jabber.org when the status of a XEP is changed to Deferred. Before running this script, make sure that you modify the <status/> element in the XEP itself and run the gen.sh shell script. This script updates the database and sends a message to standards@xmpp.org when the status of a XEP is changed to Deferred. Before running this script, make sure that you modify the <status/> element in the XEP itself and run the gen.sh shell script. lastcall.py This script announces a Last Call for a XEP by updating the database and sending a message to standards-jig@jabber.org. This script announces a Last Call for a XEP by updating the database and sending a message to standards@xmpp.org. protoxep.py This script announces availability of a new "proto-XEP" (i.e., a document not yet accepted as a XEP by the XMPP Council) by sending a message to standards-jig@jabber.org. Before running this script, place the new proto-XEP so that it is available at http://www.xmpp.org/extensions/inbox/ (normally this is done by running 'xsltproc inbox/docname.xml > /var/www/xmpp.org/extensions/inbox/docname.html' from the editor's working CVS directory on the web server). This script announces availability of a new "proto-XEP" (i.e., a document not yet accepted as a XEP by the XMPP Council) by sending a message to standards@xmpp.org. Before running this script, place the new proto-XEP so that it is available at http://www.xmpp.org/extensions/inbox/ (normally this is done by running 'xsltproc inbox/docname.xml > /var/www/xmpp.org/extensions/inbox/docname.html' from the editor's working CVS directory on the web server).
diff --git a/xep.ent b/xep.ent
index de1e0411..8fe4b411 100644
--- a/xep.ent
+++ b/xep.ent
@@ -131,7 +131,7 @@
In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes, the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept 'false' and the strings "1" and "true" for the concept 'true'; implementations MUST support both styles of lexical representation." >
-In order to submit new values to this registry, the registrant must define an XML fragment of the following form and either include it in the relevant XMPP Extension Protocol or send it to the email address <registrar@jabber.org>:
NOTICE: This document is currently within Last Call or under consideration by the XMPP Council for advancement to the next stage in the XSF standards process.
WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document must not be referred to as an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://www.xmpp.org/extensions/> and announced on the <standards-jig@jabber.org> mailing list.
+WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document must not be referred to as an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://www.xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.
WARNING: This document has been Rejected by the XMPP Council. Implementation of the protocol described herein is not recommended under any circumstances.
@@ -227,11 +227,11 @@The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
+The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.
Discussion by the membership of the XSF may also be appropriate (see <http://mail.jabber.org/mailman/listinfo/members> for details).
The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
+The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.
Given that this XMPP Extension Protocol normatively references IETF technologies, discussion on the XSF-IETF list may also be appropriate (see <http://mail.jabber.org/mailman/listinfo/jsf-ietf> for details).