git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@254 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-12-05 22:18:37 +00:00
parent e9ab4b230b
commit 47bba0345d
1 changed files with 19 additions and 5 deletions

View File

@ -19,6 +19,12 @@
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.18pre1</version>
<date>in progress, last updated 2006-12-05</date>
<initials>psa</initials>
<remark><p>Clarified meaning of Experimental, Draft, and Final states.</p></remark>
</revision>
<revision>
<version>1.17</version>
<date>2006-10-04</date>
@ -227,7 +233,7 @@
<p>More detailed information about the approval process is provided below, including criteria for Standards Track XEPs and for Historical, Informational, and Procedural XEPs.</p>
<section2 topic='Standards Track XEPs' anchor='approval-std'>
<p>The possible states for a Standards Track XEP are as follows:</p>
<code>
<code>
+--> Retracted
|
@ -239,7 +245,9 @@ Experimental ----> Proposed ----> Draft ----> Final
| |
| |
+-----------+---> Deprecated ---> Obsolete
</code>
</code>
<p>After an XMPP Extension Protocol has been accepted for publication by the XMPP Council and before it is proposed for advancement to a status of Draft (or retracted or deferred), it shall have a status of Experimental. Publication as an Experimental does not indicate approval of the protocol by the XMPP Council or the broader XMPP community.</p>
<p><em>Note: An Experimental specification is a work in progress and may undergo significant modification before advancing to a status of Draft. While implementation of an Experimental protocol is encouraged in order to determine the feasibility of the proposed solution, it is not recommended for such implementations to be included in the primary release for a software product (as opposed to an experimental branch).</em></p>
<p>The ideal path is for a Standards Track XEP is to be advanced by the XMPP Council from Proposed to Draft to Final (the criteria for this advancement are described in the following paragraphs). However, an Experimental XEP shall be assigned a status of Deferred if it has not been updated in six (6) months (e.g., because of a lack of interest or because it depends on other specifications that have yet to move forward). In addition, rather than being advanced from Proposed to Draft, a Standards Track XEP may be voted to a status of Rejected if the XMPP Council deems it unacceptable. (Note that if a XEP is Deferred, the XMPP Extensions Editor may at some point re-assign it to Experimental status, and that, even if a XEP is Rejected, it is retained in source control and on the Jabber Software Foundation website for future reference.) Finally, a XEP author may voluntarily remove an Experimental XEP from further consideration, resulting in a status of Retracted.</p>
<p>In order for a Standards Track XEP to advance from Proposed to Draft, it must:</p>
<ol>
@ -251,9 +259,12 @@ Experimental ----> Proposed ----> Draft ----> Final
<li>be formally defined by an XML schema</li>
<li>receive the requisite votes from the XMPP Council</li>
</ol>
<p>Elevation to Draft status (version 1.0) is a major advancement for the XEP, indicating a strong sense on the part of the XMPP Council and Jabber/XMPP developer community that the specification will be of lasting value. Since a Draft standard must be well-understood and must be known to be reasonably stable, it is relatively safe to use it as the basis for implementations and production deployments. However, note that because a Draft standard may still require additional field experience and may be subject to change based on such experience, mission-critical or large-scale implementations of the Draft standard may not be advisable (although every effort shall be made to ensure that any changes to a Draft XEP will be backwards-compatible with the 1.0 version). Note also that any changes to a Draft XEP must be provisionally published at &lt;<link url='http://www.xmpp.org/extensions/tmp/'>http://www.xmpp.org/extensions/tmp/</link>&gt;, announced on the Standards-JIG mailing list, and formally approved by the XMPP Council before being officially published at the canonical URL for the XEP.</p>
<p>In order for a XEP to advance from Draft status to Final status (version 2.0), it must be shown to be stable and well-received by the Jabber/XMPP developer community. Before presenting a Draft standard to the XMPP Council for consideration as a Final standard, the XMPP Extensions Editor shall issue a Call for Experience on the Standards-JIG list so that feedback can be gathered from those who have implemented the Draft standard (the Call for Experience shall expire not less than 14 days after the date of issue, and shall not be issued until at least 60 days have passed since advancement to Draft). In addition, at least two implementations of the XEP must exist, at least one of which must be free software (in accordance with the &GPL; or &LGPL;) or open-source software (in accordance with the definition provided by &OSI;). Until two implementations are produced, a Standards Track XEP shall retain a status of Draft. Once (1) two implementations have been presented to the XMPP Council, (2) feedback provided during the Call for Experience has been incorporated into the XEP, and (3) the XEP has been fully checked for accuracy, the status of the XEP may be changed to Final upon a vote of the Council.</p>
<p>Finally, a Standards Track XEP that has been granted a status of Final may be superseded by a future XEP approved by the XMPP Council. In such cases, the status of the earlier XEP shall be changed to Deprecated, possibly with an expiration date assigned by the XMPP Council (see the <link url='#expiration'>Expiration Dates</link> section below). After a reasonable period of time or upon the passing of the expiration date, the status of the XEP shall be changed to Obsolete.</p>
<p>Elevation to Draft status (version 1.0) is a major advancement for the XEP, indicating a strong sense on the part of the XMPP Council and Jabber/XMPP developer community that the specification will be of lasting value.</p>
<p><em>Note: Once an XMPP Extension Protocol has been advanced to a status of Draft, it is expected that the specification will be basis for widespread implementation and for deployment in production environments. As a result of such implementation and deployment experience, the protocol may be subject to modification, including changes that are backwards-incompatible. Although such backwards-incompatible modifications shall be avoided if at all possible, deployment of a Draft protocol in mission-critical application may not be advisable.</em></p>
<p>Any proposed changes to a Draft XEP must be provisionally published at &lt;<link url='http://www.xmpp.org/extensions/tmp/'>http://www.xmpp.org/extensions/tmp/</link>&gt;, announced and discussed on the Standards-JIG mailing list, and formally approved by the XMPP Council before being officially published at the canonical URL for the XEP.</p>
<p>In order for a XEP to advance from Draft status to Final status (version 2.0), it must be shown to be stable and well-received by the Jabber/XMPP developer community. Before presenting a Draft standard to the XMPP Council for consideration as a Final standard, the XMPP Extensions Editor shall issue a Call for Experience on the Standards-JIG list so that feedback can be gathered from those who have implemented the Draft standard (the Call for Experience shall expire not less than 14 days after the date of issue, and shall not be issued until at least 60 days have passed since advancement to Draft). In addition, at least two implementations of the XEP must exist, at least one of which must be free software (in accordance with the &GPL; or &LGPL;) or open-source software (in accordance with the definition provided by &OSI;). Until two implementations are produced, a Standards Track XEP shall retain a status of Draft. Once (1) two implementations have been presented to the XMPP Council, (2) feedback provided during the Call for Experience has been incorporated into the XEP, and (3) the XEP has been fully checked for accuracy, the status of the XEP may be changed to Final upon a vote of the Council.</p>
<p><em>Note: Once an XMPP Extension Protocol has been advanced to a status of Final, every effort shall be made to limit the scope of modifications; in particular, backwards-incompatible changes shall not be made. However, limited modifications may be made as long as they are optional, backwards-compatible extensions rather than modifications to the core protocol itself. Therefore, a Final protocol is safe for deployment in mission-critical applications.</em></p>
<p>A Standards Track XEP that has been advanced to a status of Final may be superseded by a future XEP approved by the XMPP Council. In such cases, the status of the earlier XEP shall be changed to Deprecated, possibly with an expiration date assigned by the XMPP Council (see the <link url='#expiration'>Expiration Dates</link> section below). After a reasonable period of time or upon the passing of the expiration date, the status of the XEP shall be changed to Obsolete.</p>
</section2>
<section2 topic='Historical, Informational, and Procedural XEPs' anchor='approval-info'>
<p>The possible states for a Historical, Informational, or Procedural XEP are as follows:</p>
@ -279,15 +290,18 @@ Experimental ----> Proposed ----> Active
<p>The possible states for a XEP are summarized in the following sections.</p>
<section2 topic='Experimental' anchor='states-Experimental'>
<p>A XEP of any type is in the Experimental state after it has been accepted by the XMPP Council and published by the Jabber Software Foundation but before it has advanced within the standards process to a state of Active or Draft.</p>
<p><em>Note: An Experimental specification is a work in progress and may undergo significant modification before advancing to a status of Draft. While implementation of an Experimental protocol is encouraged in order to determine the feasibility of the proposed solution, it is not recommended for such implementations to be included in the primary release for a software product (as opposed to an experimental branch).</em></p>
</section2>
<section2 topic='Proposed' anchor='states-Proposed'>
<p>A XEP of any type is in the Proposed state while it is in Last Call or under consideration by the XMPP Council for advancement from Experimental to Draft or Active.</p>
</section2>
<section2 topic='Draft' anchor='states-Draft'>
<p>A Standards Track XEP is in the Draft state after it has undergone extensive discussion and technical review on the Standards-JIG list and has been voted forward on the standards track by the XMPP Council.</p>
<p><em>Note: Once an XMPP Extension Protocol has been advanced to a status of Draft, it is expected that the specification will be basis for widespread implementation and for deployment in production environments. As a result of such implementation and deployment experience, the protocol may be subject to modification, including changes that are backwards-incompatible. Although such backwards-incompatible modifications shall be avoided if at all possible, deployment of a Draft protocol in mission-critical application may not be advisable.</em></p>
</section2>
<section2 topic='Final' anchor='states-Final'>
<p>A Standards Track XEP is in the Final state after it has been in the Draft state for at least 60 days, has been implemented in at least two separate codebases, and has been voted forward on the standards track by the XMPP Council.</p>
<p><em>Note: Once an XMPP Extension Protocol has been advanced to a status of Final, every effort shall be made to limit the scope of modifications; in particular, backwards-incompatible changes shall not be made. However, limited modifications may be made as long as they are optional, backwards-compatible extensions rather than modifications to the core protocol itself. Therefore, a Final protocol is safe for deployment in mission-critical applications.</em></p>
</section2>
<section2 topic='Active' anchor='states-Active'>
<p>A XEP of any type other than Standards Track is advanced to a status of Active after it has been voted forward from Experimental by the XMPP Council.</p>