moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00
Code Issues Releases Wiki Activity

1.20rc2

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3915 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2010-02-04 01:39:57 +00:00
parent 1ab44e2f94
commit bd8c42d0dd
1 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
xep-0001.xml
View File

@ -20,8 +20,8 @@
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.20rc1</version>
<date>in progress, last updated 2010-01-13</date>
<version>1.20rc2</version>
<date>in progress, last updated 2010-02-03</date>
<initials>psa</initials>
<remark>
<ul>
@ -30,6 +30,7 @@
<li>Changed the holding period for advancement from Draft to Final from 60 days to 6 months.</li>
<li>Clarified that the Editor is the canonical target for all submissions, not necessarily all questions related to the XSF's standards process.</li>
<li>Clarified that only changes in Draft and Final XEPs that could reasonably be construed as material must be reviewed and voted on by the XMPP Council, thus exempting correction of typographical errors, minor clarifications, and other such errata.</li>
<li>Clarified that the Council has ultimate authority over Draft, Final, and Active XEPs, and can demand the reversal of any changes made to XEPs in those states by the XMPP Extensions Editor or the XEP author.</li>
<li>Clarified that Council review is mandatory (not just recommended) regarding IANA registrations initiated by the XMPP Registrar.</li>
<li>Updated some references and added some links.</li>
</ul>
@ -298,7 +299,7 @@ Experimental ----> Proposed ----> Draft ----> Final
</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 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 the 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 changes to a Draft XEP that could reasonably be construed as material 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 mailing list, and formally approved by the XMPP Council before being officially published at the canonical URL for the XEP.</p>
<p>Any changes to a Draft XEP that could reasonably be construed as material 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 mailing list, and formally approved by the XMPP Council before being officially published at the canonical URL for the XEP. Ultimate authority for Draft XEPs rests with the XMPP Council, which can at its discretion demand the reversal of any changes made by the XMPP Extensions Editor or the XEP author while the XEP is in the Draft state.</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 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 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 six (6) months 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>
@ -363,7 +364,7 @@ Experimental ----> Proposed ----> Active
</section1>
<section1 topic='Modification of Final and Active XEPs' anchor='mods'>
<p>Sometimes it is necessary to modify XEPs that have received final approval by the XMPP Council or XSF Board of Directors (e.g., to correct errors, incorporate the lessons of experience, or document new security concerns). This section describes the process for doing so with regard to Standards Track XEPs that have achieved a status of Final and Historical, Informational, and Procedural XEPs that have achieved a status of Active.</p>
<p>With regard to Standards Track XEPs, the XMPP Standards Foundation (in particular, the XMPP Council) strives to ensure that such XEPs are accurate, complete, and stable before advancing them to a status of Final (corresponding to document version 2.0 of the XEP). The Call for Experience and discussion within the Standards SIG help to ensure this result, but final responsibility rests with the XMPP Council. Despite the best efforts of all concerned, errors are sometimes discovered in Final XEPs (the individual who discovers such an error should inform the Council via the Standards mailing list or communicate directly with the XMPP Extensions Editor). Whereas other standards development organizations may issue errata while leaving the specification itself unchanged, the XSF makes changes to the Final XEP "in place", where any changes that could reasonably be construed as material are subject to review by the XMPP Council and result in publication of a revised document version (e.g., version 2.1). In general, any such changes are made by the XMPP Extensions Editor or XEP author in consultation with the XMPP Council, discussed within the Standards SIG if appropriate, and agreed upon by the full XMPP Council. Upon agreement regarding the exact changes, the XMPP Council shall instruct the XMPP Extensions Editor to publish a revised version of the XEP and announce the existence of the revised version through the normal channels (e.g., on the XSF website and to the Standards list). Naturally, if members of the XMPP developer community have concerns regarding the changes made, they are free to discuss the matter in the relevant forum (usually the Standards list) before or after the revised version has been published.</p>
<p>With regard to Standards Track XEPs, the XMPP Standards Foundation (in particular, the XMPP Council) strives to ensure that such XEPs are accurate, complete, and stable before advancing them to a status of Final (corresponding to document version 2.0 of the XEP). The Call for Experience and discussion within the Standards SIG help to ensure this result, but final responsibility rests with the XMPP Council. Despite the best efforts of all concerned, errors are sometimes discovered in Final XEPs (the individual who discovers such an error should inform the Council via the Standards mailing list or communicate directly with the XMPP Extensions Editor). Whereas other standards development organizations may issue errata while leaving the specification itself unchanged, the XSF makes changes to the Final XEP "in place", where any changes that could reasonably be construed as material are subject to review by the XMPP Council and result in publication of a revised document version (e.g., version 2.1). In general, any such changes are made by the XMPP Extensions Editor or XEP author in consultation with the XMPP Council, discussed within the Standards SIG if appropriate, and agreed upon by the full XMPP Council. Upon agreement regarding the exact changes, the XMPP Council shall instruct the XMPP Extensions Editor to publish a revised version of the XEP and announce the existence of the revised version through the normal channels (e.g., on the XSF website and to the Standards list). Naturally, if members of the XMPP developer community have concerns regarding the changes made, they are free to discuss the matter in the relevant forum (usually the Standards list) before or after the revised version has been published. Ultimate authority for Final and Active XEPs rests with the XMPP Council, which can at its discretion demand the reversal of any changes made by the XMPP Extensions Editor or the XEP author while the XEP is in the Final or Active state.</p>
<p>The process is similar with regard to Historical and Informational XEPs that have achieved a status of Active (corresponding to document version 1.0 of the XEP): the XMPP Council agrees on the exact changes to be made and instructs the XMPP Extensions Editor to publish and announce a revised version (e.g., version 1.1). Here again the XMPP Council bears responsibility for any changes and public discussion is welcome.</p>
<p>Procedural XEPs may be modified more frequently as the XMPP Standards Foundation gains experience with the processes defined therein. For example, XEP-0001 is modified periodically in order to document processes previously not made explicit or to modify existing processes based on experience with the XSF's standards process; similar changes are sometimes made to the &xep0053; XEP and to various SIG-related XEPs. Changes to these XEPs are discussed by the XMPP Council, XSF Board of Directors, XSF membership, and Standards SIG as appropriate, and exact changes are agreed to by the relevant approving body (XMPP Council or XSF Board of Directors). The approving body then instructs the XMPP Extensions Editor to publish and announce the revised version as described above.</p>
</section1>