This JEP defines the standards process followed by the Jabber Software Foundation.
NOTICE: This Procedural JEP defines a process or activity of the Jabber Software Foundation (JSF) that has been approved by the Jabber Council and/or the JSF Board of Directors. The JSF is currently following the process or activity defined herein and will do so until this JEP is deprecated or obsoleted.
Status: Active
Type: Procedural
Number: 0001
Version: 1.14
Last Updated: 2004-09-28
JIG: None
Approving Body: JSF Board of Directors
Dependencies: None
Supersedes: None
Superseded By: None
Short Name: N/A
Email: stpeter@jabber.org
JID: stpeter@jabber.org
This Jabber Enhancement Proposal is copyright 1999 - 2004 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.php>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
Discussion by the membership of the JSF may also be appropriate (see <http://mail.jabber.org/mailman/listinfo/members> for details).
The Jabber Software Foundation (JSF) [1] adheres to an open standards process that enables interested parties to document existing protocols used within the Jabber community and to submit proposals that define new protocols; all such protocols may be considered extensions to the Extensible Messaging and Presence Protocol (XMPP) approved by the Internet Engineering Task Force (IETF) [2]. Advancement through the JSF'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 JSF. The focal point of the process is a series of protocol specifications called Jabber Enhancement Proposals or JEPs. [3] The nature of JEPs and the mechanisms for managing and advancing them within the Jabber Software Foundation are canonically described in the current document, which represents the first document in the JEP series.
The Jabber Software Foundation was founded in the year 2001 to openly document, safeguard, manage, and extend the wire protocols used within the Jabber community. The work of the Jabber Software Foundation has several objectives:
The standards process specified herein has been developed and refined in order to meet these objectives.
There are four types of JEP:
A Standards Track JEP defines a wire protocol intended to be used as a standard part of Jabber technologies; this is the main JEP type of interest to the JSF, and most JEPs are Standards Track. [7]
An Informational JEP defines one of the following:
An Historical JEP documents a protocol that was developed before the JEP process was instituted, but that is still in use within the Jabber community; such a JEP may or may not be obsoleted by a Standards Track JEP, or upgraded to Standards Track.
A Humorous JEP attempts to be funny by defining a protocol that would never be used in the real world; such JEPs are usually published on April 1 and automatically have a status of Active.
An Procedural JEP defines a process or activity to be followed by the JSF, including JIG charters as specified by Jabber Interest Groups [10].
The approving body for all Standards Track, Informational, Historical, and Humorous JEPs is the Jabber Council [11]; the approving body for Procedural JEPs is usually the JSF Board of Directors [12] but may be the Jabber Council.
This document focuses primarily on Standards Track JEPs, since they are the vehicle for defining new protocols, but also discusses Historical, Informational, and Procedural JEPs.
The JSF welcomes and encourages the submission of protocols to the JSF's standards process. [13] Any individual or group of individuals may author a proposal and submit it to the JSF for consideration as a JEP, and there is no requirement that a JEP author shall be an elected member of the JSF. However, proposals to define official JSF protocols must be presented in the JEP format and must follow the rules defined herein.
The submission process is defined on the JSF website. Specifically, instructions for submission, a template for creating JEPs, and a link to the JEP DTD and schema may be found at <http://www.jabber.org/jeps/submit.php>. All inquiries related to the JEP process, and all submissions, should be directed to the JEP Editor [14].
Note well that JEP authors must transfer ownership of their protocols (but not implementations thereof) to the JSF. Refer to the JSF IPR Policy [15] for details. JEP authors must make sure that they have read, understood, and agreed to the JSF IPR Policy before submitting a proposal to the JEP Editor!
All proposals submitted to the JSF for consideration as a JEPs must contain the following information:
Legal Notice -- the legal notice must be exactly that which is specified in the JSF IPR Policy
Author Information -- first name, last name, email address, and Jabber ID are all required and must be provided for all authors
Finally, Standards Track, Informational, and Historical JEPs must conform to RFC 2119 in the use of terminology regarding requirements levels.
The approving body for almost all JEPs is the Jabber Council; therefore, in order to be published as a JEP, a proposal must first be accepted by the Jabber Council (the only exceptions are certain kinds of Procedural JEPs, for which the approving body may be the JSF Board of Directors and which may be accepted for publication by the JEP Editor in consultation with the Board). Upon receiving a proposal, the JEP Editor shall do the following:
If no member of the Jabber Council objects to publication of the proposal within seven (7) days, the JEP Editor shall accept it as a JEP. If objections are raised by the Council on the Standards-JIG list, the JEP author(s) is encouraged to address the feedback of the Council and to submit a revised version of the proposal and/or confer with the JEP Editor or objecting Council member(s) regarding how to proceed.
If the proposal is accepted as a JEP, the JEP Editor shall do the following:
Note well that no special criteria (other than acceptance by the Jabber Council and minimal formatting compliance) need to be met in order for a JEP to be granted a status of Experimental. The granting of Experimental status must not be construed as indicating any level of approval by the JSF, the Jabber Council, or the Jabber community. Implementation of Experimental JEPs is encouraged in an exploratory fashion (e.g., in a proof of concept), but such implementations may not be appropriate for deployment in production systems.
Once a JEP is published, it becomes available for public discussion within the Standards JIG and the broader Jabber community. The JEP author(s) is responsible for collecting feedback from the Jabber community during the life of the JEP and for incorporating such feedback into the proposal. In order to fully participate in discussion of the proposal, the JEP author(s) should be subscribed to the Standards-JIG list, which is the primary venue for discussion of JEPs. Changes made based on feedback received by the JEP author(s) must be captured in updated versions of the JEP (e.g., 0.2 after 0.1), each of which must be put under source control and subsequently tracked and announced by the JEP Editor.
If an Experimental JEP is inactive (i.e., no updated versions are published) for a period of six months, the JEP Editor shall automatically change the status of the JEP to Deferred unless it is in the queue of JEPs under active consideration for advancement by the Jabber Council; upon submission of an updated version, the JEP Editor shall change the status back to Experimental.
Before an experimental JEP may be proposed to the Jabber Council for advancement to Draft (Standards Track JEPs) or Active (Historical, Informational, and Procedural JEPs), the Jabber Council must agree that the JEP is ready to be considered for advancement. Once the Council so agrees, it shall instruct the JEP Editor to (1) change the status of the JEP from Experimental to Proposed and (2) issue a Last Call for open discussion on the Standards JIG list. The Last Call shall expire not less than 10 days after the date of issue.
Once the consensus of the Standards JIG has been incorporated into the JEP and all issues of substance raised during the Last Call have been addressed by the JEP author(s), the JEP Editor shall formally propose a specific revision of the JEP to the Jabber Council for its vote. If necessary, the JEP Editor may, at his discretion and in consultation with the Jabber Council, extend the Last Call or issue a new Last Call if the JEP requires further discussion.
Last Calls regarding Procedural JEPs for which the approving body is the JSF Board of Directors may be issued directly by the JEP Editor once instructed by the Board.
After a JEP has been proposed to the Jabber Council, any change in its status shall be determined by a vote of the Jabber Council. All members of the Council must vote, with the possible values being +1 (approve), 0 (neutral), or -1 (disapprove, with reasons). A JEP 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 JEP to advance. A majority of Council members must vote +1 in order for a JEP to advance. (Additional voting policies, such as voting periods and defaults if a member does not vote, may be set by the Jabber Council.) A vote of the Jabber Council is final and binding, although an JEP author(s) is free to address the concerns of the Council and to resubmit the JEP for future consideration.
If the Jabber Council does not complete voting on a JEP before the end of its term, the JEP Editor shall issue a new Last Call on the Standards JIG list and the newly-elected Council shall vote anew on the JEP 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 JEP.
A vote of the Jabber Council applies only to the specific revision of the JEP that has been presented to it. Further revisions may need to be re-submitted for approval.
Any change in the status of a JEP must be announced on the Standards-JIG list by the JEP Editor. If a JEP advances to a status of Final, it shall be so announced and also published as one of the official JSF protocols [19] on the website of the Jabber Software Foundation.
Approval of Procedural JEPs for which the approving body is the JSF Board of Directors shall occur upon approval by the Board in accordance with the rules defined in the JSF Bylaws [20].
More detailed information about the approval process is provided below, including criteria for Standards Track JEPs and for Historical, Informational, and Procedural JEPs.
The possible states for a Standards Track JEP are as follows:
+------> Rejected
| +
| |
Experimental ---> Proposed ---> Draft ----> Final
| | | |
| | + +
Retracted +------> Deferred Deprecated ---> Obsolete
The ideal path is for a Standards Track JEP to be advanced by the Jabber Council from Proposed to Draft to Final (the criteria for this approval are described in the following paragraphs). However, rather than being advanced from Proposed to Draft or from Draft to Final, a Standards Track JEP may, at the discretion of the Jabber Council, be either Deferred or Rejected, and thus not be advanced along the ideal path. Specifically, a JEP may be assigned a status of Deferred if no progress is being made on the JEP or if it is dependent on other protocol enhancements that are yet to be completed. Similarly, a JEP may be assigned a status of Rejected if it is deemed unacceptable by the Jabber Council. (Note that if a JEP is Deferred, the JEP Editor may at some point re-assign it to Experimental status, and that, even if a JEP is Rejected, it is retained in source control and on the Jabber Software Foundation website for future reference.) Finally, a JEP author(s) may retract an Experimental JEP from further consideration, resulting in a status of Retracted.
In order for a JEP to advance from Proposed to Draft, it must:
Elevation to Draft status is a major advancement for the JEP, indicating a strong belief on the part of the Jabber Council and Jabber 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.
In order for a JEP to advance from Draft to Final, it must be shown to be stable and well-received by the Jabber community. Before presenting a Draft standard to the Jabber Council for consideration as a Final standard, the JEP 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 JEP must exist, at least one of which must be free software (in accordance with the The General Public License [21] or The Lesser General Public License [22]) or open-source software (in accordance with the definition provided by The Open Source Initiative [23]). Until two implementations are produced, a Standards Track JEP shall retain a status of Draft. Once (1) two implementations have been presented to the Jabber Council, (2) feedback provided during the Call for Experience has been incorporated into the JEP, and (3) the JEP has been fully checked for accuracy, the status of the JEP may be changed to Final upon a vote of the Council.
Finally, a Standards Track JEP that has been granted a status of Final may be superseded by a future JEP approved by the Jabber Council. In such cases, the status of the earlier JEP shall be changed to Deprecated, possibly with an expiration date assigned by the Jabber Council (see the Expiration Dates section below). After a reasonable period of time or upon the passing of the expiration date, the status of the JEP shall be changed to Obsolete.
The possible states for a Historical, Informational, or Procedural JEP are as follows:
+-------> Rejected
|
|
Experimental ---> Proposed ---> Active ---------> Obsolete
| | |
| | |
Retracted +-------> Deprecated --+
Because such JEPs do not seek to define standard protocols, in general they are less controversial and tend to proceed from Proposed to Active without controversy on a vote of the Jabber Council. However, some of these JEPs may be remanded from the Council to the JEP author(s) and/or JEP Editor for revision in order to be suitable for advancement from Proposed to Active (e.g., documentation of protocols in use must be accurate and describe any existing security concerns). As with Standards Track JEPs, the JEP author(s) may retract such a JEP when it is Experimental, and the Council may reject such a JEP when it is Proposed.
Once approved, most Historical, Informational, and Procedural JEPs will have a status of Active. Naturally, such a JEP may also be assigned a status of Rejected or Deprecated (instead of Active) by the Jabber Council. Furthermore, such a JEP may be replaced by a new JEP on the same or a similar topic, thus rendering the earlier JEP obsolete; in such cases, the earlier JEP shall be assigned a status of Obsolete with a note specifying the superseding JEP.
The Jabber Council may, at its discretion, decide to convert an Historical JEP into a Standards Track JEP if the protocol defined in the JEP has been in long use, is deemed stable and uncontroversial, and is unlikely to be superseded by a newer protocol. The Historical JEP shall be treated in the same way as a Standards Track JEP that has a status of Experimental, beginning with the Proposal Process. If after the Last Call and voting by the Jabber Council the JEP is approved for advancement on the standards track, its type shall be changed to Standards Track and its status shall be changed to Draft.
Sometimes it is necessary to modify JEPs that have received final approval by the Jabber Council or JSF 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 JEPs that have achieved a status of Final and Historical, Informational, and Procedural JEPs that have achieved a status of Active.
With regard to Standards Track JEPs, the Jabber Software Foundation (in particular, the Jabber Council) strives to ensure that such JEPs are accurate, complete, and stable before advancing them to a status of Final (corresponding to document version 2.0 of the JEP). The Call for Experience and discussion within the Standards JIG help to ensure this result, but final responsibility rests with the Jabber Council. Despite the best efforts of all concerned, errors are sometimes discovered in Final JEPs (the individual who discovers such an error should inform the Council via the Standards-JIG mailing list or communicate directly with the JEP Editor). Whereas other standards development organizations may issue errata while leaving the specification itself unchanged, the JSF makes changes to the Final JEP and publishes a revised document version (e.g., version 2.1). In general the changes are made by the JEP Editor or JEP author(s) in consultation with the Jabber Council, discussed within the Standards JIG if appropriate, and agreed upon by the full Jabber Council. Upon agreement regarding the exact changes, the Jabber Council instructs the JEP Editor to publish a revised version of the JEP and announce the existence of the revised version through the normal channels (e.g., on the JSF website and to the Standards-JIG list). Naturally, if members of the Jabber community have concerns regarding the changes made, they are free to discuss the matter in the relevant forum (usually the Standards-JIG list) before or after the revised version has been published.
The process is similar with regard to Historical and Informational JEPs that have achieved a status of Active (corresponding to document version 1.0 of the JEP): the Jabber Council agrees on the exact changes to be made and instructs the JEP Editor to publish and announce a revised version (e.g., version 1.1). Here again the Jabber Council bears responsibility for any changes and public discussion is welcome.
Procedural JEPs may be modified more frequently as the Jabber Software Foundation gains experience with the processes defined therein. For example, JEP-0001 is modified periodically in order to document processes previously not made explicit or to modify existing processes based on experience with the JEP process; similar changes are sometimes made to the Jabber Registrar [24] JEP and to various JIG-related JEPs. Changes to these JEPs are discussed by the Jabber Council, JSF Board of Directors, JSF membership, and Standards JIG as appropriate, and exact changes are agreed to by the relevant approving body (Jabber Council or JSF Board of Directors). The approving body then instructs the JEP Editor to publish and announce the revised version as described above.
In rare cases, a protocol enhancement may be accepted as an interim solution, especially when it is recognized that expected future improvements in technology or the underlying Jabber/XMPP protocols will make possible a much better solution to the problem at hand (e.g., a better protocol for user avatars may be contingent upon the development of a robust protocol for publish/subscribe functionality). In such cases, a JEP may be approved provisionally and be assigned an expiration date.
The exact form of such an expiration date shall be left up to the discretion of the Jabber Council. However, the preferred form is to assign an expiration date of six months in the future, at which time the Jabber Council must re-affirm the status of the JEP and, if desired, extend the expiration date for another six months. While this process may continue indefinitely (although that is unlikely), it has the virtue of forcing the Jabber Council and Jabber community to re-examine the provisional protocol on a fairly regular basis in the light of technological changes. Alternatively, a JEP may be assigned a "soft" expiration date: that is, the JEP will expire when an expected future protocol comes into existence, whenever that may be. In either case, the status of the JEP shall be changed to Deprecated when it expires.
In addition, an expiration date may be assigned when the status of a JEP is changed from Final (or, potentially, Draft) to Deprecated. In this case, the expiration date applies to the date when the JEP is expected to change from Deprecated to Obsolete. These dates may be flexible; however it is expected that they will follow the same six-month rule as provisional protocol enhancements.
Every JEP must contain a section entitled "Security Considerations", detailing security concerns or features related to the proposal; in particular, a Standards Track JEP should list the security threats that the protocol addresses and does not address, as well as security issues related to implementation of the protocol. JEP authors should refer to RFC 3552 [25] for helpful information about documenting security considerations and should also confer with the JEP Editor and/or Jabber Council regarding this important task.
Some JEPs may require interaction with the Internet Assigned Numbers Authority (IANA) [26]. The IANA acts as a clearinghouse to assign and coordinate the use of numerous Internet protocol parameters, such as MIME types and port numbers (e.g., the TCP ports 5222 and 5269 used by the Jabber community are registered with the IANA). Whether or not a JEP requires registration of parameters with the IANA, that fact must be noted and explained in a distinct section of the JEP entitled "IANA Considerations". Registration with the IANA should not occur until a JEP advances to a status of Draft (Standards Track JEPs) or Active (Informational and Historical JEPs), and should be initiated by the Jabber Registrar in consultation with the JEP author, not by the JEP author(s) directly with the IANA.
The Jabber Registrar [27] performs a function similar to the IANA, although limited to the Jabber 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 Service Discovery [28]).
Whether or not a JEP requires registration of protocol namespaces or parameters with the Jabber Registrar, that fact must be noted and explained in a distinct section of the JEP entitled "Jabber Registrar Considerations". Such registration should not occur until a JEP advances to a status of Draft (Standards Track JEPs) or Active (Informational and Historical JEPs). Registration of protocol namespaces is initiated by the JEP Editor when a JEP advances to Draft or Active. Registration of particular parameters used within a specification may be initiated by a JEP author(s) within the text of the JEP, or by an implementor of the JEP after it has advanced to Draft or Active. For details regarding the Jabber Registrar and its processes, refer to JEP-0053.
A JEP may also request that a new registry is to be created by the Jabber Registrar. The JEP author(s) 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.
JEPs that define official JSF protocols must include a schema that conforms to XML Schema Part 1 [29] and XML Schema Part 2 [30].
The schema for the JEP format itself is as follows:
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://www.jabber.org/jeps'
xmlns='http://www.jabber.org/jeps'
elementFormDefault='qualified'>
<xs:element name='jep'>
<xs:annotation>
<xs:documentation>
This schema defines the document format for Jabber Enhancement
Proposals (JEPs). For further information about JEPs, visit:
http://www.jabber.org/jeps/
The canonical URL for this schema is:
http://www.jabber.org/jeps/jep.xsd
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element ref='header'/>
<xs:element ref='section1' maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='header'>
<xs:complexType>
<xs:sequence>
<xs:element name='title' type='xs:string'/>
<xs:element name='abstract' type='xs:string'/>
<xs:element name='legal' type='xs:string'/>
<xs:element name='number' type='xs:byte'/>
<xs:element ref='status'/>
<xs:element ref='type'/>
<xs:element name='jig' type='xs:string'/>
<xs:element name='approver' type='xs:string'/>
<xs:element name='dependencies' type='xs:string'/>
<xs:element name='supersedes' type='xs:string'/>
<xs:element name='supersededby' type='xs:string'/>
<xs:element name='shortname' type='xs:NCNAME'/>
<xs:element ref='schemaloc' minOccurs='0' maxOccurs='unbounded'/>
<xs:element name='registry' type='empty' minOccurs='0'/>
<xs:element name='expires' type='xs:string' minOccurs='0'/>
<xs:element ref='author' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='revision' minOccurs='0' maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='status'>
<xs:simpleType>
<xs:restriction base='xs:NCNAME'>
<xs:enumeration value='Active'/>
<xs:enumeration value='Deferred'/>
<xs:enumeration value='Deprecated'/>
<xs:enumeration value='Draft'/>
<xs:enumeration value='Experimental'/>
<xs:enumeration value='Final'/>
<xs:enumeration value='Obsolete'/>
<xs:enumeration value='Proposed'/>
<xs:enumeration value='Rejected'/>
<xs:enumeration value='Retracted'/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name='type'>
<xs:simpleType>
<xs:restriction base='xs:string'>
<xs:enumeration value='Historical'/>
<xs:enumeration value='Humorous'/>
<xs:enumeration value='Informational'/>
<xs:enumeration value='Procedural'/>
<xs:enumeration value='Standards Track'/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name='schemaloc'>
<xs:complexType>
<xs:sequence>
<xs:element name='ns' type='xs:string' minOccurs='0'/>
<xs:element name='url' type='xs:string'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='author'>
<xs:complexType>
<xs:sequence>
<xs:element name='firstname' type='xs:string'/>
<xs:element name='surname' type='xs:string'/>
<xs:element name='org' type='xs:string' minOccurs='0'/>
<xs:element name='email' type='xs:string'/>
<xs:element name='jid' type='xs:string'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='revision'>
<xs:complexType>
<xs:sequence>
<xs:element name='version' type='xs:string'/>
<xs:element name='date' type='xs:dateTime'/>
<xs:element name='initials' type='xs:NCName'/>
<xs:element name='remark' type='xs:string'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='section1'>
<xs:complexType>
<xs:choice maxOccurs='unbounded'>
<xs:element ref='div' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='p' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='section2' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='example' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='code' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='ul' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='ol' minOccurs='0' maxOccurs='unbounded'/>
</xs:choice>
<xs:attribute name='topic' type='xs:string' use='required'/>
<xs:attribute name='anchor' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='section2'>
<xs:complexType>
<xs:choice maxOccurs='unbounded'>
<xs:element ref='div' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='p' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='section3' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='example' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='code' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='ul' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='ol' minOccurs='0' maxOccurs='unbounded'/>
</xs:choice>
<xs:attribute name='topic' type='xs:string' use='required'/>
<xs:attribute name='anchor' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='section3'>
<xs:complexType>
<xs:choice maxOccurs='unbounded'>
<xs:element ref='div' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='p' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='section4' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='example' minOccurs='0' maxOccurs='unbounded'/>
<xs:element name='code' type='xs:string' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='ul' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='ol' minOccurs='0' maxOccurs='unbounded'/>
</xs:choice>
<xs:attribute name='topic' type='xs:string' use='required'/>
<xs:attribute name='anchor' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='section4'>
<xs:complexType>
<xs:choice maxOccurs='unbounded'>
<xs:element ref='div' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='p' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='example' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='code' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='ul' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='ol' minOccurs='0' maxOccurs='unbounded'/>
</xs:choice>
<xs:attribute name='topic' type='xs:string' use='required'/>
<xs:attribute name='anchor' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='div'>
<xs:complexType>
<xs:choice maxOccurs='unbounded'>
<xs:element ref='div' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='p' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='example' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='code' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='ul' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='ol' minOccurs='0' maxOccurs='unbounded'/>
</xs:choice>
<xs:attribute name='class' type='xs:string' use='optional'/>
<xs:attribute name='style' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='p' type='markup'/>
<xs:element name='ul'>
<xs:complexType>
<xs:sequence>
<xs:element ref='li' minOccurs='1' maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='ol'>
<xs:complexType>
<xs:sequence>
<xs:element ref='li' minOccurs='1' maxOccurs='unbounded'/>
</xs:sequence>
<xs:attribute name='start' type='xs:byte' use='optional'/>
<xs:attribute name='type' type='xs:NCName' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='li' type='markup'/>
<xs:element name='img'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='source' use='required'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='link'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='url' use='required'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='note' type='markup'/>
<xs:element name='example'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='caption' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='code'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='caption' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='table'>
<xs:complexType>
<xs:sequence>
<xs:element ref='tr' minOccurs='1' maxOccurs='unbounded'/>
</xs:sequence>
<xs:attribute name='caption' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='tr'>
<xs:complexType>
<xs:choice>
<xs:element ref='th' minOccurs='0' maxOccurs='unbounded'/>
<xs:element ref='td' minOccurs='0' maxOccurs='unbounded'/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name='th'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='colspan' use='optional'/>
<xs:attribute name='rowspan' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='td'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='colspan' use='optional'/>
<xs:attribute name='rowspan' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:complexType name='markup' type='mixed'>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
<xs:element name='cite' type='xs:token'/>
<xs:element name='em' type='xs:token'/>
<xs:element ref='img'/>
<xs:element ref='link'/>
<xs:element ref='note'/>
<xs:element name='span' type='xs:token'/>
<xs:element name='strong' type='xs:token'/>
<xs:element name='tt' type='xs:token'/>
</xs:choice>
<xs:attribute name='class' type='xs:string' use='optional'/>
<xs:attribute name='style' type='xs:string' use='optional'/>
</xs:complexType>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
1. The Jabber Software Foundation (JSF) is an independent, non-profit organization that develops open application protocols on top of the IETF's Extensible Messaging and Presence Protocol (XMPP). For further information, see <http://www.jabber.org/jsf/>.
2. The Internet Engineering Task Force is the principal body engaged in the development of new Internet standard specifications, best known for its work on standards such as HTTP and SMTP. For further information, see <http://www.ietf.org/>.
3. The JEP concept as exemplified in version 1.0 of this document (approved in July of 2001) was borrowed from the Python community (see PEP-1). Subsequent revisions have been based on the Jabber community's experience with the JEP process, as well as insights gleaned from the standards processes followed by the IETF (RFC 2026 [4]), the World Wide Web Consortium (W3C) [5] (W3C Process Document [6]), and other standards development organizations.
4. RFC 2026: The Internet Standards Process <http://www.ietf.org/rfc/rfc2026.txt>.
5. The World Wide Web Consortium defines data formats and markup languages (such as HTML and XML) for use over the Internet. For further information, see <http://www.w3.org/>.
6. W3C Process Document <http://www.w3.org/Consortium/Process-20010719/process.html>.
7. Note well that a Standards Track JEP is not considered a full standard of the Jabber Software Foundation until it achieves a status of Final within the standards process defined herein (a Standards Track JEP that has achieved a status of Draft may be referred to as a Draft Standard; a Standards Track JEP 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).
8. JEP-0128: Service Discovery Extensions <http://www.jabber.org/jeps/jep-0128.html>.
9. JEP-0126: Invisibility <http://www.jabber.org/jeps/jep-0126.html>.
10. JEP-0002: Jabber Interest Groups <http://www.jabber.org/jeps/jep-0002.html>.
11. The Jabber Council is a technical steering committee, authorized by the JSF Board of Directors and elected by JSF members, that approves of new Jabber protocols and oversees the JSF's standards process. For further information, see <http://www.jabber.org/council/>.
12. The JSF Board of Directors is an elected body that possesses overall responsibility for the affairs of the Jabber Software Foundation. For further information, see <http://www.jabber.org/board/>.
13. It is important to understand that private extensions to XMPP are also allowed. The JSF does not, and cannot, require such private extensions to be added to the public, official set of protocols recognized by the JSF. The processes and procedures in this document apply only to protocols that are submitted to the JSF, 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 JSF.
14. The JEP Editor is the individual appointed by the JSF Board of Directors to handle protocol submissions and provide day-to-day management of the JSF's standards process. For further information, see <http://www.jabber.org/jeps/editor.php>.
15. The JSF IPR Policy defines the Jabber Software Foundation's official policy regarding intellectual property rights (IPR) as they pertain to Jabber Enhancement Proposals (JEPs). For further information, see <http://www.jabber.org/jsf/ipr-policy.php>.
16. The Standards JIG is a standing Jabber Interest Group devoted to discussion of Jabber Enhancement Proposals. The discussion list of the Standards JIG is the primary venue for discussion of Jabber protocol development, as well as for announcements by the JEP Editor and Jabber Registrar. To subscribe to the list or view the list archives, visit <http://mail.jabber.org/mailman/listinfo/standards-jig/>.
17. JEPs are kept under source control in the 'jeps' module of the CVS repository maintained at the jabberstudio.org service. Instructions for accessing these files can be found at <http://www.jabberstudio.org/cvs.php>, and a web interface to these files is available at <http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/jeps/>.
18. The canonical URL for accessing JEPs is <http://www.jabber.org/jeps/jeplist.php>.
19. A list of official JSF protocols is maintained at <http://www.jabber.org/protocol>.
20. The Bylaws of the Jabber Software Foundation (JSF) define the legal basis and operating procedures of the JSF. For further information, see <http://www.jabber.org/jsf/bylaws.php>.
21. The General Public License is the primary code license for free software as defined by the Free Software Foundation. For further information, see <http://www.gnu.org/licenses/gpl.txt>.
22. The Lesser General Public License is a secondary code license for free software as defined by the Free Software Foundation. For further information, see <http://www.gnu.org/licenses/lgpl.txt>.
23. The Open Source Initiative defines the term 'open source' and maintains a list of a open-source code licenses. For further information, see <http://www.opensource.org/>.
24. JEP-0053: Jabber Registrar <http://www.jabber.org/jeps/jep-0053.html>.
25. RFC 3552: Guidelines for Writing RFC Text on Security Considerations <http://www.ietf.org/rfc/rfc3552.txt>.
26. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
27. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
28. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.
29. XML Schema Part 1: Structures <http://www.w3.org/TR/xmlschema-1/>.
30. XML Schema Part 2: Datatypes <http://www.w3.org/TR/xmlschema-2/>.
END