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.
The five XEP types are described in the following sections.
-The approving body for all Standards Track, Informational, Historical, and Humorous XEPs is the XMPP Council; the approving body for Procedural XEPs may be either the &BOARD; or the XMPP Council.
+The approving body for all Standards Track, Informational, and Historical XEPs is the XMPP Council; the approving body for Humorous XEPs in the XMPP Extensions Editor; and the approving body for Procedural XEPs may be either the &BOARD; 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.
A Standards Track XEP defines one of the following:
@@ -207,6 +223,7 @@This document concentrates on this type of XEP; variances from the procedures for Standards Track XEPs are noted where appropriate.
An Informational XEP typically defines best practices for implementation or deployment of an existing protocol (e.g., &xep0128; and &xep0175;).
@@ -216,9 +233,11 @@A Humorous XEP attempts to be funny by defining a protocol that would never be used in the real world; such XEPs are usually published on April 1 and automatically have a status of Active.
+Note that the Approving Body for Humorous XEPs is the XMPP Extensions Editor itself.
A Procedural XEP defines a process or activity to be followed by the XSF (e.g., &xep0053;), including SIG charters as specified by &xep0002;.
+For some Procedural XEPs, the Approving Body is the XSF Board instead of the XMPP Council.
Finally, Standards Track, Informational, and Historical XEPs must conform to &rfc2119; in the use of terminology regarding requirements levels.
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:
+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:
If no member of the XMPP Council objects to publication of the proposal within fourteen (14) days or at the next meeting of the Council, the XMPP Extensions Editor shall accept it as a XEP. If objections are raised by the Council on the Standards list or in its meeting, the XEP author is encouraged to address the feedback of the Council and to submit a revised version of the proposal and/or confer with the XMPP Extensions Editor or objecting Council member(s) regarding how to proceed.
+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 Standards list or in its meeting, the XEP author is encouraged to address the feedback of the Council 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:
Note well that no special criteria (other than acceptance by the XMPP Council 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.
+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.
Once a XEP is published, it becomes available for public discussion within the Standards SIG and the broader XMPP developer community. The XEP author 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, the XEP author 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 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 XMPP Council; upon submission of an updated version, the XMPP Extensions Editor shall change the status back to Experimental.
+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.
Before an Experimental XEP may be proposed to the XMPP Council for advancement to Draft (Standards Track XEPs) or Active (Historical, Informational, and Procedural XEPs), the XMPP Council must agree that the XEP is ready to be considered for advancement. Once the Council so agrees, it shall instruct the XMPP Extensions Editor to (1) change the status of the XEP from Experimental 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, the XMPP Extensions Editor shall formally propose a specific revision of the XEP to the XMPP Council for its vote. If necessary, the XMPP Extensions Editor may, at his discretion and in consultation with the XMPP Council, extend the Last Call or issue a new Last Call if the XEP requires further discussion.
-Last Calls regarding Procedural XEPs for which the approving body is the XSF Board of Directors may be issued directly by the XMPP Extensions Editor once instructed by the Board.
+Before an Experimental XEP may be proposed to the Approving Body for advancement to Draft (Standards Track XEPs) or Active (Historical, Informational, and Procedural XEPs), 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 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, 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.
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 is free to address the concerns of the Council and to resubmit the XEP for future consideration.
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 at <http://xmpp.org/protocols/>.
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 &BYLAWS;.
+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.
The possible states for a Standards Track XEP are as follows: