added informal process outline to introduction

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@898 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0001.xml

@@ -141,7 +141,24 @@
   </revision>
 </header>
 <section1 topic='Introduction' anchor='intro'>
-  <p>The &XSF; adheres to an open standards process that enables interested parties to document existing protocols used within the Jabber/XMPP developer community and to submit proposals that define new protocols; with a few exceptions, <note>Effectively the only such exceptions are protocols that were superseded by <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</note> such protocols can be considered extensions to the Extensible Messaging and Presence Protocol (XMPP) approved by the &IETF; in &xmppcore; and &xmppim;. Advancement through the XSF's standards process is subject to open discussion on public discussion lists and approval by a technical steering committee elected by the members of the XSF. The focal point of the process is a series of protocol specifications called XMPP Extension Protocols or XEPs. <note>The JEP (now XEP) concept as exemplified in version 1.0 of this document (approved in July of 2001) was borrowed from the Python community (see <link url="http://python.sourceforge.net/peps/pep-0001.html">PEP-1</link>). Subsequent revisions have been based on the Jabber/XMPP developer community's experience with this standards process, as well as insights gleaned from the standards processes followed by the IETF (&rfc2026;), the &W3C; (&w3process;), and other standards development organizations.</note> The nature of XMPP Extension Protocols and the mechanisms for managing and advancing them within the XMPP Standards Foundation's standards process are canonically described in the current document, which represents the first document in the XEP series. <note>The term "XEP" is normally pronounced "zepp".</note></p>
+  <p>The &XSF; adheres to an open standards process that enables interested parties to document existing protocols used within the Jabber/XMPP developer community and to submit proposals that define new protocols; with a few exceptions, <note>Effectively the only such exceptions are protocols that were superseded by <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</note> such protocols can be considered extensions to the Extensible Messaging and Presence Protocol (XMPP) approved by the &IETF; in &xmppcore; and &xmppim;. The focal point of the process is a series of protocol specifications called XMPP Extension Protocols or XEPs. <note>The JEP (now XEP) concept as exemplified in version 1.0 of this document (approved in July of 2001) was borrowed from the Python community (see <link url="http://python.sourceforge.net/peps/pep-0001.html">PEP-1</link>). Subsequent revisions have been based on the Jabber/XMPP developer community's experience with this standards process, as well as insights gleaned from the standards processes followed by the IETF (&rfc2026;), the &W3C; (&w3process;), and other standards development organizations. (Note: The term "XEP" is normally pronounced "zepp".)</note></p>
+  <p>Advancement of a XEP through the XSF's standards process is contingent on three factors:</p>
+  <ul>
+    <li>Rough consensus on the XSF's public discussion lists.</li>
+    <li>Running code in XMPP clients, servers, and libraries.</li>
+    <li>Formal approval by the &COUNCIL;.</li>
+  </ul>
+  <p>The XSF's standards process can be outlined informally as follows:</p>
+  <ol start='1'>
+    <li>A developer in the XMPP community defines a new XMPP extension that solves an existing problem or enables an innovative feature that is not addressed in the current XMPP protocol stack.</li>
+    <li>The developer submits a specification to the &EDITOR; and agrees to transfer ownership over the protocol (but not implementations thereof) to the XSF.</li>
+    <li>If the specification is accepted by the XMPP Council, it is published as an Experimental XEP.</li>
+    <li>The XEP undergoes extensive community review on the XSF's open discussion lists and is implemented experimentally in XMPP clients, servers, and libraries.</li>
+    <li>If the protocol fills an important need, meets with rough consensus, and is implemented in running code, the XMPP Council will formally review it and vote on advancing it to a status of Draft.</li>
+    <li>While the XEP is in the Draft state, the protocol may be refined based on further discussion and implementation experience.</li>
+    <li>If the protocol is deemed stable after at least six months (and normally more) of further implementation and deployment experience, the XSF will lead interoperability testing and then consider advancement of the XEP to a status of Final.</li>
+  </ol>
+  <p>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.</p>
 </section1>
 <section1 topic='Objectives' anchor='objectives'>
   <p>The XMPP Standards Foundation was founded in the year 2001 to openly document, safeguard, manage, and extend the wire protocols used within the Jabber/XMPP developer community. The work of the XMPP Standards Foundation has several objectives:</p>
@@ -156,13 +173,13 @@
 </section1>
 <section1 topic='XEP Types' anchor='types'>
   <p>The five XEP types are described in the following sections.</p>
-  <p>The approving body for all Standards Track, Informational, Historical, and Humorous XEPs is the &COUNCIL;; the approving body for Procedural XEPs may be either the &BOARD; or the XMPP Council.</p>
+  <p>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.</p>
   <p>This document focuses primarily on Standards Track XEPs since they are the vehicle for defining new protocols, but also discusses the other XEP types.</p>
   <section2 topic='Standards Track' anchor='types-Standards-Track'>
     <p>A <span class='ref'>Standards Track XEP</span> defines one of the following:</p>
     <ol>
       <li>A wire protocol intended to be used as a standard part of Jabber/XMPP technologies.
-        <note>Note well that a protocol defined in a Standards Track XEP is not considered a full standard of the XMPP Standards Foundation until it achieves a status of Final within the standards process defined herein (a Standards Track XEP that has achieved a status of Draft may be referred to as a Draft Standard; a Standards Track XEP that has a status of Experimental must not be referred to as a standard, but instead should be referred to as a work in progress).</note>
+        <note>A protocol defined in a Standards Track XEP is not considered a full standard of the XMPP Standards Foundation until it achieves a status of Final within the standards process defined herein (a Standards Track XEP that has achieved a status of Draft may be referred to as a Draft Standard; a Standards Track XEP that has a status of Experimental must not be referred to as a standard, but instead should be referred to as a work in progress).</note>
       </li>
       <li>A protocol suite that determines conformance requirements (e.g., &xep0073;).</li>
     </ol>
@@ -185,7 +202,7 @@
   </section2>
 </section1>
 <section1 topic='Submission Process' anchor='submission'>
-  <p>The XSF welcomes and encourages the submission of protocols to the XSF's standards process. <note>It is important to understand that private extensions to XMPP are also allowed. The XSF does not, and cannot, require such private extensions to be added to the public, official set of protocols recognized by the XSF. The processes and procedures in this document apply only to protocols that are submitted to the XSF, not to private protocol extensions used for custom functionality in particular applications. However, such private extensions must not be considered part of the protocols recognized by the XSF.</note> Any individual or group of individuals may author a proposal and submit it to the XSF for consideration as a XEP, and there is no requirement that a XEP author shall be an elected member of the XSF. However, proposals to define official XSF protocols must be presented in the XEP format and must follow the rules defined herein. The authoring and submission process is defined in &xep0143; (see also &lt;<link url="http://www.xmpp.org/extensions/submit.shtml">http://www.xmpp.org/extensions/submit.shtml</link>&gt;). All inquiries related to the XSF's standards process, and all submissions, should be directed to the &EDITOR;.</p> 
+  <p>The XSF welcomes and encourages the submission of protocols to the XSF's standards process. <note>It is important to understand that private extensions to XMPP are also allowed. The XSF does not, and cannot, require such private extensions to be added to the public, official set of protocols recognized by the XSF. The processes and procedures in this document apply only to protocols that are submitted to the XSF, not to private protocol extensions used for custom functionality in particular applications. However, such private extensions must not be considered part of the protocols recognized by the XSF.</note> Any individual or group of individuals may author a proposal and submit it to the XSF for consideration as a XEP, and there is no requirement that a XEP author shall be an elected member of the XSF. However, proposals to define official XSF protocols must be presented in the XEP format and must follow the rules defined herein. The authoring and submission process is defined in &xep0143; (see also &lt;<link url="http://www.xmpp.org/extensions/submit.shtml">http://www.xmpp.org/extensions/submit.shtml</link>&gt;). All inquiries related to the XSF's standards process, and all submissions, should be directed to the XMPP Extensions Editor.</p> 
   <p>Note well that XEP authors must transfer ownership of their protocols (but not implementations thereof) to the XSF. Refer to the &XSFIPR; for details. XEP authors must make sure that they have read, understood, and agreed to the XSF IPR Policy before submitting a proposal to the XMPP Extensions Editor!</p>
   <p>All proposals submitted to the XSF for consideration as XEPs must contain the following information:</p>
   <ol start='1'>
@@ -228,7 +245,7 @@
   <p>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.</p>
   <p>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.</p>
   <p>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.</p>
-  <p>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 <note>A list of official XSF protocols is maintained at &lt;<link url='http://www.xmpp.org/protocol/'>http://www.xmpp.org/protocol</link>&gt;.</note> on the website of the XMPP Standards Foundation.</p>
+  <p>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 on the website of the XMPP Standards Foundation.</p>
   <p>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;.</p>
   <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'>
@@ -246,7 +263,7 @@ Experimental ----> Proposed ----> Draft ----> Final
                                     |           |
                                     +-----------+---> Deprecated ---> Obsolete
     </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>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 XEP 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 XMPP Standards 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>
@@ -341,7 +358,7 @@ Experimental ----> Proposed ----> Active
 </section1>
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
   <p>The &REGISTRAR; performs a function similar to the IANA, although limited to the Jabber/XMPP developer community. It does so by reserving protocol namespaces and by uniquely assigning parameters for use in the context of Jabber/XMPP protocols (for example, the categories and types used in &xep0030;).</p>
-  <p>Whether or not a XEP requires registration of protocol namespaces or parameters with the XMPP Registrar, that fact must be noted and explained in a distinct section of the XEP entitled "XMPP Registrar Considerations". Such registration should not occur until a XEP advances to a status of Draft (Standards Track XEPs) or Active (Informational and Historical XEPs). Registration of protocol namespaces is initiated by the XMPP Extensions Editor when a XEP advances to Draft or Active. Registration of particular parameters used within a specification may be initiated by a XEP author within the text of the XEP, or by an implementor of the XEP after it has advanced to Draft or Active. For details regarding the XMPP Registrar and its processes, refer to &xep0053;.</p>
+  <p>Whether or not a XEP requires registration of protocol namespaces or parameters with the XMPP Registrar, that fact must be noted and explained in a distinct section of the XEP entitled "XMPP Registrar Considerations". Such registration should not occur until a XEP advances to a status of Draft (Standards Track XEPs) or Active (Informational and Historical XEPs). Registration of protocol namespaces is initiated by the XMPP Extensions Editor when a XEP advances to Draft or Active. Registration of particular parameters used within a specification may be initiated by a XEP author within the text of the XEP, or by an implementor of the XEP after it has advanced to Draft or Active. For details regarding the XMPP Registrar and its processes, refer to <cite>XEP-0053</cite>.</p>
   <p>A XEP may also request that a new registry is to be created by the XMPP Registrar. The XEP author must clearly define the nature of the new registry as well as the process for submitting data to the registry, and must do so in collaboration with the Registrar.</p>
 </section1>
 <section1 topic='XML Schema' anchor='schema'>