As approved by the members of the Jabber Software Foundation, changed Jabber Enhancement Proposal to XMPP Extension Protocol.
As approved by the members of the XMPP Standards Foundation, changed Jabber Enhancement Proposal to XMPP Extension Protocol.
Defined Procedural type as the union of JIG Formation type and certain Informational specifications in order to clarify the categories; added Modifications to Approved Specifications section in order to make explicit existing Council practices regarding Active and Final specifications; specified that documents on which voting was not complete at the end of a Council term shall undergo a second Last Call and subsequent vote by the new Council; modified Proposal Process to specify that the Jabber Council shall issue Last Calls on documents for which it is the approving body, with all discussion to occur on the Standards-JIG list; updated the schema.
Defined Procedural type as the union of SIG Formation type and certain Informational specifications in order to clarify the categories; added Modifications to Approved Specifications section in order to make explicit existing Council practices regarding Active and Final specifications; specified that documents on which voting was not complete at the end of a Council term shall undergo a second Last Call and subsequent vote by the new Council; modified Proposal Process to specify that the Jabber Council shall issue Last Calls on documents for which it is the approving body, with all discussion to occur on the Standards list; updated the schema.
Further clarified the proposal process per discussion on the JSF members list.
Further clarified the proposal process per discussion on the members list.
Major revision based on experience. In addition to a reorganization of the content to improve the clarity of the presentation, changes include: (1) no anonymous authors; (2) proposal must be seconded by at least 5% of JSF members before being proposed for a Council vote; (3) clarification that the Council votes only on a particular revision of a specification (e.g., version 1.3 when proceeding from Draft to Final); (4) added information about the "Call for Experience" phase before proceeding from Draft to Final; (5) added reference to RFC 2119; (6) added sections for security considerations, IANA considerations, and XMPP Registrar considerations. Approved by the JSF Board and Jabber Council on 2002-11-20.
Major revision based on experience. In addition to a reorganization of the content to improve the clarity of the presentation, changes include: (1) no anonymous authors; (2) proposal must be seconded by at least 5% of XSF members before being proposed for a Council vote; (3) clarification that the Council votes only on a particular revision of a specification (e.g., version 1.3 when proceeding from Draft to Final); (4) added information about the "Call for Experience" phase before proceeding from Draft to Final; (5) added reference to RFC 2119; (6) added sections for security considerations, IANA considerations, and XMPP Registrar considerations. Approved by the XSF Board and Jabber Council on 2002-11-20.
(1) Changed "Jabber Foundation" to "Jabber Software Foundation"; (2) Changed "JIG Proposal" to "JIG Formation"; (3) Removed reference to the Secretary of the Jabber Software Foundation in connection with the role of Editor; (4) Clarified the possible states of acceptance of each kind of specification and described in greater detail the criteria for advancement from one state to another.
(1) Changed "Jabber Foundation" to "XMPP Standards Foundation"; (2) Changed "SIG Proposal" to "SIG Formation"; (3) Removed reference to the Secretary of the XMPP Standards Foundation in connection with the role of Editor; (4) Clarified the possible states of acceptance of each kind of specification and described in greater detail the criteria for advancement from one state to another.
The &JSF; 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,
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,
The Jabber Software 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 Jabber Software Foundation has several objectives:
+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:
A Standards Track XEP defines one of the following:
An Historical XEP documents a protocol that was developed before the JSF's standards process was instituted, but that is still in use within the Jabber/XMPP developer community; such a XEP may or may not be obsoleted by a Standards Track XEP, or upgraded to Standards Track.
+An Historical XEP documents a protocol that was developed before the XSF's standards process was instituted, but that is still in use within the Jabber/XMPP developer community; such a XEP may or may not be obsoleted by a Standards Track XEP, or upgraded to Standards Track.
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.
A Procedural XEP defines a process or activity to be followed by the JSF, including JIG charters as specified by &xep0002;.
+A Procedural XEP defines a process or activity to be followed by the XSF, including SIG charters as specified by &xep0002;.
The JSF welcomes and encourages the submission of protocols to the JSF's standards process.
Note well that XEP authors must transfer ownership of their protocols (but not implementations thereof) to the JSF. Refer to the &JSFIPR; for details. XEP authors must make sure that they have read, understood, and agreed to the JSF IPR Policy before submitting a proposal to the XMPP Extensions Editor!
-All proposals submitted to the JSF for consideration as XEPs must contain the following information:
+The XSF welcomes and encourages the submission of protocols to the XSF's standards process.
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!
+All proposals submitted to the XSF for consideration as XEPs must contain the following information:
Legal Notice -- the legal notice must be exactly that which is specified in the JSF IPR Policy
Legal Notice -- the legal notice must be exactly that which is specified in the XSF 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 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 JSF 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 seven (7) 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-JIG 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.
+If no member of the XMPP Council objects to publication of the proposal within seven (7) 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.
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 JSF, the XMPP Council, or the Jabber/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 may not be appropriate for deployment in production systems.
+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 Jabber/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 may not be appropriate for deployment in production systems.
Once a XEP is published, it becomes available for public discussion within the Standards JIG and the broader Jabber/XMPP developer community. The XEP author is responsible for collecting feedback from the Jabber/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-JIG list, which is the primary venue for discussion of XMPP Extension Protocols. Changes made based on feedback received by the XEP author must 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.
+Once a XEP is published, it becomes available for public discussion within the Standards SIG and the broader Jabber/XMPP developer community. The XEP author is responsible for collecting feedback from the Jabber/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 must 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 six (6) 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.
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 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 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 JSF 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 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 10 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.
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 JIG 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.
+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-JIG 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 JSF protocols
Approval of Procedural XEPs 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 &BYLAWS;.
+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
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;.
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:
@@ -248,21 +248,21 @@ Experimental ----> Proposed ----> Draft ----> FinalAfter 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.
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).
-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.
+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.
In order for a Standards Track XEP to advance from Proposed to Draft, it must:
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.
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.
-Any proposed changes to a Draft XEP must be provisionally published at <http://www.xmpp.org/extensions/tmp/>, 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.
-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.
+Any proposed changes to a Draft XEP must be provisionally published at <http://www.xmpp.org/extensions/tmp/>, 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.
+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 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.
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.
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 Expiration Dates 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.
The possible states for a XEP are summarized in the following sections.
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.
+A XEP of any type is in the Experimental state after it has been accepted by the XMPP Council and published by the XMPP Standards Foundation but before it has advanced within the standards process to a state of Active or Draft.
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).
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.
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.
+A Standards Track XEP is in the Draft state after it has undergone extensive discussion and technical review on the Standards list and has been voted forward on the standards track by the XMPP Council.
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.
An Experimental XEP of any type is changed to the Deferred state if it has not been updated in six (6) months.
A XEP of any type is in the Retracted state if the authors have asked the XMPP Extensions Editor to remove the XEP from further consideration in the JSF's standards process.
+A XEP of any type is in the Retracted state if the authors have asked the XMPP Extensions Editor to remove the XEP from further consideration in the XSF's standards process.
A XEP of any type is in the Rejected state if the XMPP Council has deemed it unacceptable and has voted to not move it forward within the standards process.
@@ -323,10 +323,10 @@ Experimental ----> Proposed ----> ActiveSometimes it is necessary to modify XEPs that have received final approval by the XMPP 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 XEPs that have achieved a status of Final and Historical, Informational, and Procedural XEPs that have achieved a status of Active.
-With regard to Standards Track XEPs, the Jabber Software 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 JIG 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-JIG 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 JSF makes changes to the Final XEP and publishes a revised document version (e.g., version 2.1). In general the changes are made by the XMPP Extensions Editor or XEP author in consultation with the XMPP Council, discussed within the Standards JIG 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 JSF website and to the Standards-JIG list). Naturally, if members of the Jabber/XMPP developer 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.
+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.
+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 and publishes a revised document version (e.g., version 2.1). In general the 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 Jabber/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.
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.
-Procedural XEPs may be modified more frequently as the Jabber Software 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 JSF's standards process; similar changes are sometimes made to the &xep0053; XEP and to various JIG-related XEPs. Changes to these XEPs are discussed by the XMPP Council, JSF Board of Directors, JSF membership, and Standards JIG as appropriate, and exact changes are agreed to by the relevant approving body (XMPP Council or JSF Board of Directors). The approving body then instructs the XMPP Extensions Editor to publish and announce the revised version as described above.
+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.
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 XEP may be approved provisionally and be assigned an expiration date.
@@ -345,7 +345,7 @@ Experimental ----> Proposed ----> ActiveA 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.
XMPP Extension Protocol specifications that define official JSF protocols must include a schema that conforms to &w3xmlschema1; and &w3xmlschema2;.
+XMPP Extension Protocol specifications that define official XSF protocols must include a schema that conforms to &w3xmlschema1; and &w3xmlschema2;.
The schema for the XEP format itself is as follows:
@@ -388,7 +388,7 @@ Experimental ----> Proposed ----> Active
- Jabber Interest Groups (JIGs)
- A definition of Jabber Interest Groups, including their structure and role within the Jabber Software Foundation.
+ Special Interest Groups (SIGs)
+ A definition of Special Interest Groups within the XMPP Standards Foundation.
&LEGALNOTICE;
0002
Active
Procedural
- None
+ None
Board
- A Jabber Interest Group (JIG) is a working group approved by the XMPP Council to address specific areas of growth or concern within the Jabber/XMPP developer community, usually by means of developing and publishing XMPP Extension Protocols (XEPs).
+ A Special Interest Group (SIG) is a working group approved by the XMPP Council to address specific areas of growth or concern within the Jabber/XMPP developer community, usually by means of developing and publishing XMPP Extension Protocols (XEPs).
- The main function of most JIGs is to produce acceptable XMPP extensions (delivered in the form of XMPP Extension Protocols or XEPs For information about XMPP Extension Protocols, see http://www.xmpp.org/extensions/xep-0001.html. ) within a reasonably limited period of time. However, at the discretion of the XMPP Council, a handful of standing JIGs may be approved (e.g., to address security or standards compliance).
- Anyone (not limited to members of the Jabber Software Foundation) may propose the formation of a JIG by completing a XMPP Extension Protocol outlining the need for the JIG and its proposed focus. However, JIG leaders must be members of the Jabber Software Foundation. The number of leaders for a JIG is flexible, and shall be determined by each JIG, in consultation with the XMPP Council if necessary. The concept of "membership" with regard to JIGs is loose, and is essentially co-extensive with membership in the appropriate mailing list (each JIG has its own mailing list, which is archived for public review). JIG members do not need to be members of the Jabber Software Foundation, and any member of the general public may subscribe to JIG mailing lists.
- It is expected that all JIGs (other than certain standing JIGs) will remain active for as long as necessary in order to produce one or more standards-track specifications for review by the XMPP Council in the JIG's area of focus. However, if a JIG does not show signs of activity for an extended period of time (usually six months of inactivity on the JIG's mailing list), the JIG may be disbanded at the discretion of the XMPP Council with appropriate warning to the JIG members (usually in the form of an email sent to the JIG's mailing list).
+ The main function of most SIGs is to produce acceptable XMPP extensions (delivered in the form of XMPP Extension Protocols or XEPs For information about XMPP Extension Protocols, see http://www.xmpp.org/extensions/xep-0001.html. ) within a reasonably limited period of time. However, at the discretion of the XMPP Council, a handful of standing SIGs may be approved (e.g., to address security or standards compliance).
+ Anyone (not limited to members of the XMPP Standards Foundation) may propose the formation of a SIG by completing a XMPP Extension Protocol outlining the need for the SIG and its proposed focus. However, SIG leaders must be members of the XMPP Standards Foundation. The number of leaders for a SIG is flexible, and shall be determined by each SIG, in consultation with the XMPP Council if necessary. The concept of "membership" with regard to SIGs is loose, and is essentially co-extensive with membership in the appropriate mailing list (each SIG has its own mailing list, which is archived for public review). SIG members do not need to be members of the XMPP Standards Foundation, and any member of the general public may subscribe to SIG mailing lists.
+ It is expected that all SIGs (other than certain standing SIGs) will remain active for as long as necessary in order to produce one or more standards-track specifications for review by the XMPP Council in the SIG's area of focus. However, if a SIG does not show signs of activity for an extended period of time (usually six months of inactivity on the SIG's mailing list), the SIG may be disbanded at the discretion of the XMPP Council with appropriate warning to the SIG members (usually in the form of an email sent to the SIG's mailing list).
diff --git a/xep-0003.xml b/xep-0003.xml
index 1bc15f22..6de597fd 100644
--- a/xep-0003.xml
+++ b/xep-0003.xml
@@ -12,7 +12,7 @@
0003
Active
Historical
- Standards JIG
+ Standards
XMPP Core
diff --git a/xep-0004.xml b/xep-0004.xml
index 59624483..9abd889d 100644
--- a/xep-0004.xml
+++ b/xep-0004.xml
@@ -12,7 +12,7 @@
0004
Final
Standards Track
- Standards JIG
+ Standards
XMPP Core
@@ -91,7 +91,7 @@
0.6
2002-03-15
rwe
- Protocol tweaks based on standards-jig discussion.
+ Protocol tweaks based on Standards list discussion.
0.5
@@ -577,7 +577,7 @@
The ®ISTRAR; includes the 'jabber:x:data' namespace in its registry of protocol namespaces.
- The XMPP Registrar maintains a registry of parameter values related to the 'jabber:x:data' namespace, specifically as defined in &xep0068;; the registry is located at <http://www.jabber.org/registrar/formtypes.html>.
+ The XMPP Registrar maintains a registry of parameter values related to the 'jabber:x:data' namespace, specifically as defined in &xep0068;; the registry is located at &FORMTYPES;.
Storage is describing and accessing the physical location where the Profiles are kept. It will likely start off being only the Jabber Server, but will eventually allow for remote (specialized network hard drive services) and local (on the User's local machine or a portable floppy) storage. It also describes how this data will be transferred between computers and networks in an efficient and secure manner.
-This will likely be the most other-JIG dependent part of the system, since we will have to make heavy use of encryption in Jabber, and likely file transfers. So we may want to help out those related JIGs when we get to this point to make sure their results can be used by this system.
+This will likely be the most other-SIG dependent part of the system, since we will have to make heavy use of encryption in Jabber, and likely file transfers. So we may want to help out those related SIGs when we get to this point to make sure their results can be used by this system.
Gate gives the User complete control at all times of others' access to and power over their Profiles. Since this system is designed to hold the bulk, if not all, of a User's personal information, they *must* have a powerful way to prevent unwanted others to access their data. So there must exist a powerful access regulation framework to precisely control which, when, and how other parties can get this information.
@@ -75,22 +75,22 @@To make sure this project progresses smoothly and orderly, it has been decided it will be split up into steps, or 'Phases'. Each of the above four aspects will be split into two to four Phases, and the Road-map for the entire project will follow along these Phases. Version 1.0 of the Profiles system will be little more than an expanded vCard schema with simple rules and permissions to regulate access to it. It will progress up to Version 4.0 or 5.0, adding in advanced verification to persuade Services to use a User's Jabber Profiles instead of forcing them to set up a local account, and also adding write permissions so Services can set receipts of purchases and similar information in a User's Account.
-This Road-map will be produced soon after the JIG is set up, and will give a good feature list and time-line to follow.
+This Road-map will be produced soon after the SIG is set up, and will give a good feature list and time-line to follow.
Such an improved system would obviously provide for more types of information storage and management, but there are some other side-benefits that can be conceived of.
Eventually we would like this Profiles specification to completely replace the strict vCard schema that is 'hard-coded' into the protocol. We do not expect vCard to disappear from Jabber at all, simply be one possible Profile among many in a User's Account. At the end of this JIGs existence, we would like to see it integrate the Profiles and special 'jabber:profiles' namespaces fully into the rest of the Jabber protocol, having it become the method by which all User information (such as Roster, client-side preferences, and filters) is stored and retrieved.
-It is important to note that this JIG will not be a stand-alone JIG. It will draw upon many other JIGs (that currently exist and that have yet to be created). It will need encryption from the Security JIG for safe transfer of the information, a versatile forms format from the Forms JIG for Profiles administration, and advanced authentication from a future JIG for Services to authenticate the User against their Jabber account.
+Eventually we would like this Profiles specification to completely replace the strict vCard schema that is 'hard-coded' into the protocol. We do not expect vCard to disappear from Jabber at all, simply be one possible Profile among many in a User's Account. At the end of this SIGs existence, we would like to see it integrate the Profiles and special 'jabber:profiles' namespaces fully into the rest of the Jabber protocol, having it become the method by which all User information (such as Roster, client-side preferences, and filters) is stored and retrieved.
+It is important to note that this SIG will not be a stand-alone SIG. It will draw upon many other SIGs (that currently exist and that have yet to be created). It will need encryption from the Security SIG for safe transfer of the information, a versatile forms format from the Forms SIG for Profiles administration, and advanced authentication from a future SIG for Services to authenticate the User against their Jabber account.
The concept of Jabber Profiles was started by Eric Murphy and Mike Hearn. They both had begun to come up with similar ideas, but did not meet and exchange ideas until around early 2001. Adam Theo also came across them soon after that, and after some discussion, the three authors of this document agreed to start a serious effort on developing it. We started it as a project at Theoretic Solutions (http://www.theoretic.com/identity/), although at that time it was as a full-fledged identity specification, complete with Profiles, Authentication, and Trust. It was not until we have now moved to set it up as an official JIG that we have split the individual parts up, to make it easier to develop.
+The concept of Jabber Profiles was started by Eric Murphy and Mike Hearn. They both had begun to come up with similar ideas, but did not meet and exchange ideas until around early 2001. Adam Theo also came across them soon after that, and after some discussion, the three authors of this document agreed to start a serious effort on developing it. We started it as a project at Theoretic Solutions (http://www.theoretic.com/identity/), although at that time it was as a full-fledged identity specification, complete with Profiles, Authentication, and Trust. It was not until we have now moved to set it up as an official SIG that we have split the individual parts up, to make it easier to develop.
The following proposal is for the formation of a Jabber Interest Group that will create a new conferencing protocol, as well as create additional functionality and standardize communications on top of said conferencing protocol.
The initial task of the Conferencing JIG will be to propose a Jabber Conferencing specification that will solve various problems which exist in the current "groupchat" specification. This specification is meant to be a foundation for additional functionality; it defines the framework needed to provide additional features, without requiring changes to the framework specification itself. There is also to be a certain amount of feature-negotiation included; the conferencing service can define what features can be declared for a room, both as optional and required client features for room participation.
+The initial task of the Conferencing SIG will be to propose a Jabber Conferencing specification that will solve various problems which exist in the current "groupchat" specification. This specification is meant to be a foundation for additional functionality; it defines the framework needed to provide additional features, without requiring changes to the framework specification itself. There is also to be a certain amount of feature-negotiation included; the conferencing service can define what features can be declared for a room, both as optional and required client features for room participation.
The framework's scope consists of the following minimum functionality:
Because of the prevalence of the existing "groupchat" specification for multi-user chats, a long conversion process is anticipated. A server implementation which supports both protocols will simply not allow "groupchat"-only clients to participate in rooms with required features.
As listed above, there is a fairly large number of features that could be developed on top of a well-designed framework. The Conferencing JIG will first be established to develop a framework, with features mainly being compared against the framework for feasibility of implementation. After a proposal has been formalized as a specification, the JIG will become a group for discussing and proposing new features, and for formally specifying those features.
+As listed above, there is a fairly large number of features that could be developed on top of a well-designed framework. The Conferencing SIG will first be established to develop a framework, with features mainly being compared against the framework for feasibility of implementation. After a proposal has been formalized as a specification, the SIG will become a group for discussing and proposing new features, and for formally specifying those features.
Jabber is often thought of simply as a system for instant messaging, albeit an open one. However, Jabber technology can be used, and is being used, in applications quite different from simple IM. One of these applications is whiteboarding. In collaborative work, the ability to draw (for example, to design sketches, UML schemas, house architectures, and organizational plans) is essential, as exemplified by the success of real-world whiteboarding applications such as Microsoft NetMeeting. Whiteboarding can also be used for entertainment purposes such as games and quizzes. Because of the value of whiteboarding as an important real-time collaboration tool, other IM services are beginning to offer these capabilities. For these and other reasons, I believe that a good protocol for whiteboarding in Jabber would be of great value.
There exists today a protocol draft for sending streaming XPM over Jabber
Therefore, the Whiteboard JIG should develop a standard way of handling whiteboards in Jabber and a format for data transfer. This might be based on vector graphics, bitmap data, or a combination of these two. In addition, the protocol should work in the context of both regular messaging and conferencing. The protocol for whiteboarding during conferencing might depend on the new protocol proposal to come from the Conferencing JIG
Therefore, the Whiteboard SIG should develop a standard way of handling whiteboards in Jabber and a format for data transfer. This might be based on vector graphics, bitmap data, or a combination of these two. In addition, the protocol should work in the context of both regular messaging and conferencing. The protocol for whiteboarding during conferencing might depend on the new protocol proposal to come from the Conferencing SIG
The Whiteboarding JIG should produce the following deliverables (these deliverables will be presented to the Jabber Council):
+The Whiteboarding SIG should produce the following deliverables (these deliverables will be presented to the Jabber Council):
A set of requirements that the proposed protocol should fulfill.
There are today at least four different attempts
There are today at least four different attempts
One or more data formats for the graphics data, presented both as a description and as a DTD or XML schema.
diff --git a/xep-0011.xml b/xep-0011.xml index 1f7d1ae0..0a4fabba 100644 --- a/xep-0011.xml +++ b/xep-0011.xml @@ -12,7 +12,7 @@The Jabber Software Foundation is an experiment. When we initially set up our policies, processes, and structures, we knew that our initial thoughts might not be our final thoughts, and that we would need to make adjustments as experience dictated. In this document, I argue that just such an adjustment is now necessary with regard to the Jabber Interest Groups (JIGs).
The XMPP Standards Foundation is a continuing experiment. When we initially set up our policies, processes, and structures, we knew that our initial thoughts might not be our final thoughts, and that we would need to make adjustments as experience dictated. In this document, I argue that just such an adjustment is now necessary with regard to the Special Interest Groups (SIGs).
&xep0002; defined a JIG as "a working group approved by the Jabber Council to address specific areas of growth or concern within the Jabber community", and specified that the function of a JIG is to "produce acceptable enhancements to the Jabber protocol within a reasonably limited period of time". In early January of 2002, XEP-0002 was modified to incorporate language about disbanding a JIG after a defined period of inactivity on the JIG's mailing list (normally six months).
-Unfortunately, it is widely recognized in the Jabber community that the JIGs are not working. Ten JIGs have been approved by the Jabber Council,
In perhaps the best measure of success or failure, only one JIG has produced a specification for submission to the Jabber Council, and that specification (&xep0009;) was essentially created outside the JIG structure at JabberCon 2001. Perhaps most ominously, no other JIG has shown any signs of progress toward completing a specification, or even starting work on one. With the possible exception of XEP-0009, all of the specifications created so far have come from individuals or small, ad-hoc groups -- not through the efforts of the JIGs.
-In other words, an honest assessment forces us to conclude that the JIGs are not working.
+&xep0002; defined a SIG as "a working group approved by the XMPP Council to address specific areas of growth or concern within the Jabber community", and specified that the function of a SIG is to "produce acceptable enhancements to XMPP within a reasonably limited period of time". In early January of 2002, XEP-0002 was modified to incorporate language about disbanding a SIG after a defined period of inactivity on the SIG's mailing list (normally six months).
+Unfortunately, it is widely recognized in our community that the SIGs are not working. Ten SIGs have been approved by the XMPP Council, eight of them over six months ago in July and August of 2001. Two of the special-purpose SIGs (OOB and Presence) have seen no activity whatsoever and thus are clearly eligible to be disbanded. The other special-purpose SIGs (Conference, Formatting, Forms, Profiles, RPC, and Whiteboard) have seen extremely limited activity and it is a judgment call whether some of them should be allowed to continue according to the current standards defined in XEP-0002. Only the two "standing" SIGs (Security and Standards) have experienced significant and continued mailing list activity, mainly because the Standards SIG has assumed the role of discussion forum for specifications before they are submitted to the XMPP Council.
+In perhaps the best measure of success or failure, only one SIG has produced a specification for submission to the XMPP Council, and that specification (&xep0009;) was essentially created outside the SIG structure at JabberCon 2001. Perhaps most ominously, no other SIG has shown any signs of progress toward completing a specification, or even starting work on one. With the possible exception of XEP-0009, all of the specifications created so far have come from individuals or small, ad-hoc groups -- not through the efforts of the SIGs.
+In other words, an honest assessment forces us to conclude that the SIGs are not working.
I see several possible solutions to the JIG problem:
+I see several possible solutions to the SIG problem:
Given the lack of activity in the JIGs so far (and the lack of time available to those who would manage them), I am skeptical that "cracking the whip" will produce results, and I believe the onus of proof is on those who would argue that the existing JIGs can be successful. Similarly, taking a "wait and see" attitude will simply let a bad situation continue unchecked, and in my opinion will at some point require us to choose between option 1 and option 3. Rather than postpone the day of reckoning, I argue that we need to address the problem head-on and take action to streamline the JIGs and find a better way of working.
-But what is that "better way"? In order to figure that out, we need to understand why things are not working now. I don't think it's that the current JIG members are lazy, stupid, or incompetent -- after all, these are the same people who have in many instances created good Jabber-based software. Nor do I think it's that members of the Jabber community are incapable of creating specifications, because individually and in small, ad-hoc groups they have created quite a few.
-I see several reasons why the JIGs are not working:
+Given the lack of activity in the SIGs so far (and the lack of time available to those who would manage them), I am skeptical that "cracking the whip" will produce results, and I believe the onus of proof is on those who would argue that the existing SIGs can be successful. Similarly, taking a "wait and see" attitude will simply let a bad situation continue unchecked, and in my opinion will at some point require us to choose between option 1 and option 3. Rather than postpone the day of reckoning, I argue that we need to address the problem head-on and take action to streamline the SIGs and find a better way of working.
+But what is that "better way"? In order to figure that out, we need to understand why things are not working now. I don't think it's that the current SIG members are lazy, stupid, or incompetent -- after all, these are the same people who have in many instances created good XMPP-based software. Nor do I think it's that members of the XMPP community are incapable of creating specifications, because individually and in small, ad-hoc groups they have created quite a few.
+I see several reasons why the SIGs are not working:
If we reflect on what is working, we see that specifications are being produced by individuals and small, ad-hoc groups. We also see that active discussion of those proposals is taking place in the Standards JIG, which contains everyone who is strongly interested in the Jabber protocols. Finally, we notice that the special-purpose JIGs have not played any appreciable role in our success so far.
+If we reflect on what is working, we see that specifications are being produced by individuals and small, ad-hoc groups. We also see that active discussion of those proposals is taking place in the Standards SIG, which contains everyone who is strongly interested in XMPP. Finally, we notice that the special-purpose SIGs have not played any appreciable role in our success so far.
My proposed solution takes into account everything we have learned to date about producing specifications and advancing the state of the Jabber protocols. Specifically, I propose that we take the following steps:
+My proposed solution takes into account everything we have learned to date about producing specifications and advancing the state of XMPP. Specifically, I propose that we take the following steps:
There may be value in bringing back specialized JIGs in the future when the Jabber community becomes larger. However, at this time I urge that we face the facts and proactively implement the solution I have outlined in this document.
There may be value in bringing back specialized SIGs in the future when the Jabber/XMPP community becomes larger. However, at this time I urge that we face the facts and proactively implement the solution I have outlined in this document.
Note Well: The protocol described herein has been deprecated by the &JSF;. The recommended protocol for implementing message expiration functionality is now &xep0079;.
+Note Well: The protocol described herein has been deprecated by the &XSF;. The recommended protocol for implementing message expiration functionality is now &xep0079;.
It is sometimes helpful to indicate that a piece of information has a finite useful life or time-to-live (TTL). In the context of instant messaging, the main use of a TTL is to indicate that a message must or should be used by or read by a certain time, usually because the message has meaning or purpose only within a finite amount of time. In normal usage, such a message should be discarded after the specified time has passed if it has not been used or read by that time.
In Jabber, TTL functionality has been implemented informally using the jabber:x:expire namespace. Support for this namespace was added to the &jabberd; server as well as some clients and components in early 2001. Specifically, that support has involved the following two areas of responsibility:
The XMPP Registrar shall maintain a registry of values for the 'category' and 'type' attributes of the <identity/> element in the 'http://jabber.org/protocol/disco#info' namespace; see <http://www.jabber.org/registrar/disco-categories.html>.
+The XMPP Registrar maintains a registry of values for the 'category' and 'type' attributes of the <identity/> element in the 'http://jabber.org/protocol/disco#info' namespace; see &DISCOCATEGORIES;.
The XMPP Registrar shall maintain a registry of features for use as values of the 'var' attribute of the <feature/> element in the 'http://jabber.org/protocol/disco#info' namespace; see <http://www.jabber.org/registrar/disco-vars.html>.
+The XMPP Registrar maintains a registry of features for use as values of the 'var' attribute of the <feature/> element in the 'http://jabber.org/protocol/disco#info' namespace; see &DISCOFEATURES;.
A using protocol may specify one or more service discovery nodes that have a special and well-defined meaning in the context of that protocol. For the purpose of reserving these node names globally across all Jabber protocols, the XMPP Registrar shall maintain a registry of well-known service discovery nodes; see <http://www.jabber.org/registrar/disco-nodes.html>.
+A using protocol may specify one or more service discovery nodes that have a special and well-defined meaning in the context of that protocol. For the purpose of reserving these node names globally across all Jabber protocols, the XMPP Registrar maintains a registry of well-known service discovery nodes at &DISCONODES;.
-
+
Standards
-
+
diff --git a/xep-0032.xml b/xep-0032.xml
index 571e5c98..692bb896 100644
--- a/xep-0032.xml
+++ b/xep-0032.xml
@@ -12,7 +12,7 @@
0032
Retracted
Standards Track
- Standards JIG
+ Standards
None
None
RFC 4622 0033
Draft
Standards Track
- Standards JIG
+ Standards
XMPP Core
XEP-0030
diff --git a/xep-0034.xml b/xep-0034.xml
index bc842c93..5ba9e1b5 100644
--- a/xep-0034.xml
+++ b/xep-0034.xml
@@ -14,7 +14,7 @@
0034
Retracted
Standards Track
- Standards
+ Standards
None
None
XMPP Core
@@ -41,7 +41,7 @@
1.1
2003-11-05
psa
- The status of this specification has been changed to Retracted since it has been superseded by &xmppcore;. This specification will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.
+ The status of this specification has been changed to Retracted since it has been superseded by &xmppcore;.
The JSF shall register and maintain a MIME type and file extension for icon style packages with the IANA. Ones have already been registered by Sebastiaan Deckers (aka 'CBAS') as application/vnd.jisp and .jisp, respectively. The registration can be found at http://www.iana.org/assignments/media-types/application/vnd.jisp. Sebastiaan's registration shall be considered the official MIME type and file extension of this specification.
+The &XSF; shall register and maintain a MIME type and file extension for icon style packages with the IANA. Ones have already been registered by Sebastiaan Deckers (aka 'CBAS') as application/vnd.jisp and .jisp, respectively. The registration can be found at http://www.iana.org/assignments/media-types/application/vnd.jisp. Sebastiaan's registration shall be considered the official MIME type and file extension of this specification.
Also, this specification uses other MIME types that are maintained by IANA for the object and xml files that are included in the icon style packages.
Specified that messages sent to change the room subject must be of type "groupchat"; updated the legal notice to conform to the JSF IPR policy.
Specified that messages sent to change the room subject must be of type "groupchat"; updated the legal notice to conform to the XSF IPR policy.
The author would like to thank the following individuals for their many helpful comments on various drafts of this proposal: David Sutton, Peter Millard, Joe Hildebrand, Craig Kaes, Alexey Shchepin, David Waite, Jean-Louis Seguineau, Jacek Konieczny, Gaston Dombiak, and many others in the jdev@conference.jabber.org conference room and on the Standards-JIG mailing list.
+The author would like to thank the following individuals for their many helpful comments on various drafts of this proposal: David Sutton, Peter Millard, Joe Hildebrand, Craig Kaes, Alexey Shchepin, David Waite, Jean-Louis Seguineau, Jacek Konieczny, Gaston Dombiak, and many others in the jdev@conference.jabber.org conference room and on the Standards mailing list.
As approved by the members of the Jabber Software Foundation, changed Jabber Registrar to XMPP Registrar.
As approved by the members of the XMPP Standards Foundation, changed Jabber Registrar to XMPP Registrar.
Because the &JSF; publishes a relatively large number of protocol specifications (see &xep0001;), it is important to keep track of the namespaces defined by those specifications as well as the parameters used in the context of the relevant protocols. (Examples of such parameters include the features and options used in &xep0020; and the identities and features used in &xep0030;.) In particular, the common use of protocols published by the JSF requires that namespaces and particular parameter values be assigned uniquely. It is the role of the XMPP Registrar to make those unique assignments and to maintain registries of the currently assigned values. The XMPP Registrar shall also function as a single point of contact between the Jabber/XMPP developer community and &IANA;.
+Because the &XSF; publishes a relatively large number of protocol specifications (see &xep0001;), it is important to keep track of the namespaces defined by those specifications as well as the parameters used in the context of the relevant protocols. (Examples of such parameters include the features and options used in &xep0020; and the identities and features used in &xep0030;.) In particular, the common use of protocols published by the XSF requires that namespaces and particular parameter values be assigned uniquely. It is the role of the XMPP Registrar to make those unique assignments and to maintain registries of the currently assigned values. The XMPP Registrar shall also function as a single point of contact between the Jabber/XMPP developer community and &IANA;.
Until there is a perceived need for a more formal governing body, the functions of the XMPP Registrar shall be managed by the &EDITOR;. In the future, the &COUNCIL; and/or the &BOARD; may decide to create a more formal panel to oversee the functions of the XMPP Registrar; if they do, this document shall be updated to reflect the change.
@@ -83,11 +83,11 @@Every XMPP Extension Protocol specification (XEP) must contain a section devoted to "XMPP Registrar Considerations", detailing the namespaces and parameters to be registered with the XMPP Registrar, as well as any new registries to be created as a result of the XEP.
The registry additions or creations specified in an XMPP Extension Protocol specification shall not take effect until the document advances to a status of Draft (Standards-Track XEPs) or Active (Informational and Historical XEPs). Registration of namespaces shall be handled as described in the Namespace Issuance section of this document. Registration of particular parameters used within a specification shall be initiated by the XMPP Extensions Editor if specified in the XEP, and may also be initiated by implementors of the XMPP Extension Protocol document after it has advanced to Active, Draft, or Final. Creation of new registries shall be initiated by the XMPP Registrar; if a document specifies the creation of a new registry, the author is strongly encouraged to consult with the XMPP Registrar before seeking a Last Call on the XEP.
-Requests for parameter assignments must be sent to the XMPP Registrar in accordance with the process specified in the document (usually a XEP) that defines the relevant registry, normally by sending an appropriately formatted email message to <mailto:registrar@jabber.org>. If, in the Registrar's judgment, discussion of a request is required, the Registrar shall initiate such discussion within the &SJIG;. The Registrar shall add registry items at its discretion based on discussion within the Standards JIG if necessary, but shall not unduly restrict registration of parameter values. If a document author or implementor thinks that a request was unfairly denied by the Registrar, an appeal of the decision may be directed to the XMPP Council.
-The XMPP Registrar shall maintain registries of assigned namespaces and parameters at <http://www.xmpp.org/registrar/> and shall update those registries in a timely fashion. Changes to the registries shall be announced on the Standards-JIG mailing list.
+Requests for parameter assignments must be sent to the XMPP Registrar in accordance with the process specified in the document (usually a XEP) that defines the relevant registry, normally by sending an appropriately formatted email message to <mailto:registrar@jabber.org>. If, in the Registrar's judgment, discussion of a request is required, the Registrar shall initiate such discussion within the &SSIG;. The Registrar shall add registry items at its discretion based on discussion within the Standards SIG if necessary, but shall not unduly restrict registration of parameter values. If a document author or implementor thinks that a request was unfairly denied by the Registrar, an appeal of the decision may be directed to the XMPP Council.
+The XMPP Registrar shall maintain registries of assigned namespaces and parameters at <http://www.xmpp.org/registrar/> and shall update those registries in a timely fashion. Changes to the registries shall be announced on the Standards mailing list.
The XMPP Registrar shall be responsible for issuing namespaces to be used in XMPP protocol extensions developed through the Jabber Software Foundation's standards process as specified in XEP-0001. The policies and procedures for namespace issuance shall be as follows:
+The XMPP Registrar shall be responsible for issuing namespaces to be used in XMPP protocol extensions developed through the XMPP Standards Foundation's standards process as specified in XEP-0001. The policies and procedures for namespace issuance shall be as follows:
While a XEP is in the Experimental state, the namespaces specified therein shall be of the form "http://www.xmpp.org/extensions/xep-XXXX.html#ns" and "http://www.xmpp.org/extensions/xep-XXXX.html#ns-SubName", where "XXXX" is the XEP number and "SubName" is a sub-namespace (as is familiar from specifications such as &xep0045;).
Security considerations are primarily the responsibility of the protocols in which specific parameters are used. The XMPP Registrar shall respect the security considerations defined in XMPP Extension Protocol specifications, and shall endeavor to ensure that registered parameter values do not compromise privacy or security in any way.
The XMPP Registrar shall be responsible for interacting with the IANA on behalf of the Jabber Software Foundation and Jabber/XMPP developer community. If an XMPP Extension Protocol specification requires interaction with the IANA, that fact shall be noted by the document author and discussed on the Standards-JIG mailing list along with normal discussion of the XEP. The XMPP Registrar shall collaborate with the author to present an appropriate request to the IANA.
+The XMPP Registrar shall be responsible for interacting with the IANA on behalf of the XMPP Standards Foundation and Jabber/XMPP developer community. If an XMPP Extension Protocol specification requires interaction with the IANA, that fact shall be noted by the document author and discussed on the Standards mailing list along with normal discussion of the XEP. The XMPP Registrar shall collaborate with the author to present an appropriate request to the IANA.
This entire document defines the processes and procedures of the XMPP Registrar.
diff --git a/xep-0054.xml b/xep-0054.xml index 38550ac0..39ba928e 100644 --- a/xep-0054.xml +++ b/xep-0054.xml @@ -12,7 +12,7 @@The first decision-point is whether a FORM_TYPE needs to be registered with the XMPP Registrar. The following rules apply:
While the value of the FORM_TYPE attribute SHOULD be considered an opaque string from the application perspective, the following rules apply:
The Jabber Software Foundation has an initiative underway to define and implement compliance testing of software that is based on XMPP and JSF-approved protocols. To date, participation in this compliance program has been limited to elected members of the JSF. However, not all matters related to the compliance program need to be limited to JSF members. In particular, it would be valuable to receive community feedback and input regarding test plans, testing software, and the like. In order to broaden participation, we propose that the JSF form a standing Jabber Interest Group devoted to compliance.
+The XMPP Standards Foundation has an initiative underway to define and implement compliance testing of software that is based on XMPP and XSF-approved protocols. To date, participation in this compliance program has been limited to elected members of the XSF. However, not all matters related to the compliance program need to be limited to XSF members. In particular, it would be valuable to receive community feedback and input regarding test plans, testing software, and the like. In order to broaden participation, we propose that the XSF form a standing Jabber Interest Group devoted to compliance.
The Compliance JIG shall provide a public forum for discussion and development of systems for testing compliance with the protocols defined and accepted by the JSF. It shall not have ultimate accountability for the JSF compliance program; rather, that accountability shall rest with the members-only Compliance Team. The Compliance JIG shall act in an advisory capacity in relation to the Compliance Team. In essence, the relationship between the Compliance JIG and the Compliance Team is analagous to the relationship between the Standards JIG and the Jabber Council.
-In particular, the Compliance JIG shall work with the Compliance Team to define the processes, standards, test cases, and testing software required by the compliance program. However, the Compliance JIG shall not be privy to actual testing results, which shall be available only to the Compliance Team.
+The Compliance SIG shall provide a public forum for discussion and development of systems for testing compliance with the protocols defined and accepted by the XSF. It shall not have ultimate accountability for the XSF compliance program; rather, that accountability shall rest with the members-only Compliance Team. The Compliance SIG shall act in an advisory capacity in relation to the Compliance Team. In essence, the relationship between the Compliance SIG and the Compliance Team is analagous to the relationship between the Standards SIG and the Jabber Council.
+In particular, the Compliance SIG shall work with the Compliance Team to define the processes, standards, test cases, and testing software required by the compliance program. However, the Compliance SIG shall not be privy to actual testing results, which shall be available only to the Compliance Team.
The Compliance JIG shall be open to the public and shall not be limited to elected members of the Jabber Software Foundation. Compliance JIG discussions shall be conducted on a dedicated mailing list <compliance-jig@jabber.org> as well as in the <foundation@conference.jabber.org> chatroom.
+The Compliance SIG shall be open to the public and shall not be limited to elected members of the XMPP Standards Foundation. Compliance SIG discussions shall be conducted on a dedicated mailing list <compliance-jig@jabber.org> as well as in the <foundation@conference.jabber.org> chatroom.
The Compliance JIG shall be a standing JIG, and shall exist as long as the JSF compliance program is in operation.
+The Compliance SIG shall be a standing SIG, and shall exist as long as the XSF compliance program is in operation.
The Compliance JIG shall produce at least the following deliverables:
+The Compliance SIG shall produce at least the following deliverables:
In the past, there have existed several incompatible methods within the Jabber community for exchanging instant messages that contain lightweight text markup. The most notable such methods have included derivatives of &w3xhtml; as well as of &rtf;.
-Although it is sometimes easier for client developers to implement RTF support (this is especially true on certain Microsoft Windows operating systems), there are several reasons (consistent with the &xep0134;) for the &JSF; to avoid the use of RTF in developing a protocol for lightweight text markup. Specifically:
+Although it is sometimes easier for client developers to implement RTF support (this is especially true on certain Microsoft Windows operating systems), there are several reasons (consistent with the &xep0134;) for the &XSF; to avoid the use of RTF in developing a protocol for lightweight text markup. Specifically:
Conversely, there are several reasons to prefer XHTML for lightweight text markup:
The fields of this FPI are as follows:
W3C TEXT: If a user agent encounters an element it does not recognize, it must continue to process the children of that element. If the content is text, the text must be presented to the user.
-JSF COMMENT: This behavior is different from that defined by XMPP Core, and in the context of XHTML-IM implementations applies only to XML elements qualified by the 'http://www.w3.org/1999/xhtml' namespace as defined herein. This criterion MUST be applied to all XHTML 1.0 elements except those explicitly included in XHTML-IM as described in the XHTML-IM Integration Set and Recommended Profile sections of this document. Therefore, an XHTML-IM implementation MUST process all XHTML 1.0 child elements of the XHTML-IM <html/> element even if such child elements are not included in the XHTML 1.0 Integration Set defined herein, and MUST present to the recipient the XML character data contained in such child elements.
+XSF COMMENT: This behavior is different from that defined by XMPP Core, and in the context of XHTML-IM implementations applies only to XML elements qualified by the 'http://www.w3.org/1999/xhtml' namespace as defined herein. This criterion MUST be applied to all XHTML 1.0 elements except those explicitly included in XHTML-IM as described in the XHTML-IM Integration Set and Recommended Profile sections of this document. Therefore, an XHTML-IM implementation MUST process all XHTML 1.0 child elements of the XHTML-IM <html/> element even if such child elements are not included in the XHTML 1.0 Integration Set defined herein, and MUST present to the recipient the XML character data contained in such child elements.
W3C TEXT: If a user agent encounters an attribute it does not recognize, it must ignore the entire attribute specification (i.e., the attribute and its value).
-JSF COMMENT: This criterion MUST be applied to all XHTML 1.0 attributes except those explicitly included in XHTML-IM as described in the XHTML-IM Integration Set and Recommended Profile sections of this document. Therefore, an XHTML-IM implementation MUST ignore all attributes of elements qualified by the 'http://www.w3.org/1999/xhtml' namespace if such attributes are not explicitly included in the XHTML 1.0 Integration Set defined herein.
+XSF COMMENT: This criterion MUST be applied to all XHTML 1.0 attributes except those explicitly included in XHTML-IM as described in the XHTML-IM Integration Set and Recommended Profile sections of this document. Therefore, an XHTML-IM implementation MUST ignore all attributes of elements qualified by the 'http://www.w3.org/1999/xhtml' namespace if such attributes are not explicitly included in the XHTML 1.0 Integration Set defined herein.
W3C TEXT: If a user agent encounters an attribute value it doesn't recognize, it must use the default attribute value.
-JSF COMMENT: Since not one of the attributes included in XHTML-IM has a default value defined for it in XHTML 1.0, in practice this criterion does not apply to XHTML-IM implementations.
+XSF COMMENT: Since not one of the attributes included in XHTML-IM has a default value defined for it in XHTML 1.0, in practice this criterion does not apply to XHTML-IM implementations.
For information regarding XHTML modularization in XML schema for the XHTML 1.0 Integration Set defined in this specification, refer to the Schema Driver section of this document.
The XHTML 1.0 Integration Set defined herein has been reviewed informally by an editor of the XHTML Modularization in XML Schema specification but has not undergone formal review by the W3C; before this specification proceeds to a status of Final within the Jabber Software Foundation's standards process, it should undergo a formal review through communication with the Hypertext Coordination Group within the W3C.
+The XHTML 1.0 Integration Set defined herein has been reviewed informally by an editor of the XHTML Modularization in XML Schema specification but has not undergone formal review by the W3C; before this specification proceeds to a status of Final within the XMPP Standards Foundation's standards process, it should undergo a formal review through communication with the Hypertext Coordination Group within the W3C.
The W3C is actively working on &w3xhtml2; and may produce additional versions of XHTML in the future. This specification addresses XHTML 1.0 only, but it may be superseded or supplemented in the future by a XMPP Extension Protocol specification that defines methods for encapsulating XHTML 2.0 content in XMPP.
@@ -858,7 +858,7 @@ That seems fine to me. Full documentation of this Integration Set is contained in "XEP-0071: XHTML-IM", a specification published by the - Jabber Software Foundation. + XMPP Standards Foundation. http://www.xmpp.org/extensions/xep-0071.html @@ -916,7 +916,7 @@ That seems fine to me. Full documentation of this Integration Set is contained in "XEP-0071: XHTML-IM", a specification published by the - Jabber Software Foundation, which is available at the + XMPP Standards Foundation, which is available at the following URL: http://www.xmpp.org/extensions/xep-0071.html @@ -990,7 +990,7 @@ That seems fine to me. Full documentation of this Integration Set is contained in "XEP-0071: XHTML-IM", a specification published by the - Jabber Software Foundation. + XMPP Standards Foundation. http://www.xmpp.org/extensions/xep-0071.html @@ -1173,6 +1173,6 @@ That seems fine to me.This specification formalizes and extends earlier work by Jeremie Miller and Julian Missig on XHTML formatting of Jabber messages. Many thanks to Shane McCarron for his assistance regarding XHTML modularization and conformance issues. Thanks also to contributors on the Standards-JIG list for their feedback and suggestions.
+This specification formalizes and extends earlier work by Jeremie Miller and Julian Missig on XHTML formatting of Jabber messages. Many thanks to Shane McCarron for his assistance regarding XHTML modularization and conformance issues. Thanks also to contributors on the Standards list for their feedback and suggestions.
The main body of text that addresses the requirements of the W3C with regard to SOAP bindings is provided in the SOAP XMPP Binding section of this document. The current section addresses only the topic of organizational interaction between the W3C and the &JSF; regarding the SOAP XMPP Binding.
+The main body of text that addresses the requirements of the W3C with regard to SOAP bindings is provided in the SOAP XMPP Binding section of this document. The current section addresses only the topic of organizational interaction between the W3C and the &XSF; regarding the SOAP XMPP Binding.
As was done with &xep0071;, the SOAP XMPP Binding defined herein has been reviewed informally by one or more appropriate experts from the W3C before the &COUNCIL; advanced it to a status of Draft within the JSF's standards process. Before this specification proceeds to a status of Final within the JSF's standards process, it should undergo a formal review through communication with the W3C's XML Protocol Working Group. To that end, revised versions of this specification will be announced on the W3C's public xml-dist-app@w3.org mailing list.
+As was done with &xep0071;, the SOAP XMPP Binding defined herein has been reviewed informally by one or more appropriate experts from the W3C before the &COUNCIL; advanced it to a status of Draft within the XSF's standards process. Before this specification proceeds to a status of Final within the XSF's standards process, it should undergo a formal review through communication with the W3C's XML Protocol Working Group. To that end, revised versions of this specification will be announced on the W3C's public xml-dist-app@w3.org mailing list.
This specification addresses SOAP 1.2 only. This specification may be superseded or supplemented in the future by a XMPP Extension Protocol specification that defines methods for encapsulating content defined by future versions of SOAP as published by the W3C.
diff --git a/xep-0073.xml b/xep-0073.xml index ddf1c2fe..9dc11f3f 100644 --- a/xep-0073.xml +++ b/xep-0073.xml @@ -12,7 +12,7 @@Given the large number of Jabber/XMPP protocols,
-
&rfc3514;, published just today (2003-04-01), defines a mechanism for specifying the "evil bit" in IPv4 in order to determine if a packet was sent with malicious intent. In Section 5 ("Related Work") of that RFC, reference is made to complementary mechanisms for other forms of evil such as IPv6 support and the application/evil MIME type. Because the &JSF; desires to maintain compliance with protocols developed by core Internet standards bodies, the current document defines a complementary mechanism for Jabber support of evil.
+&rfc3514;, published just today (2003-04-01), defines a mechanism for specifying the "evil bit" in IPv4 in order to determine if a packet was sent with malicious intent. In Section 5 ("Related Work") of that RFC, reference is made to complementary mechanisms for other forms of evil such as IPv6 support and the application/evil MIME type. Because the &XSF; desires to maintain compliance with protocols developed by core Internet standards bodies, the current document defines a complementary mechanism for Jabber support of evil.
There are three basic Jabber stanza types that may be sent within XML streams:
diff --git a/xep-0077.xml b/xep-0077.xml index 74a15227..e45224ad 100644 --- a/xep-0077.xml +++ b/xep-0077.xml @@ -12,7 +12,7 @@The XMPP Registrar maintains a registry of AMP <rule/> conditions (see <http://www.jabber.org/registrar/amp-conditions.html>).
+The XMPP Registrar maintains a registry of AMP <rule/> conditions at &CONDITIONS;.
The XMPP Registrar maintains a registry of AMP <rule/> actions (see <http://www.jabber.org/registrar/amp-actions.html>).
+The XMPP Registrar maintains a registry of AMP <rule/> actions at &ACTIONS;.
0080
Draft
Standards Track
- Standards JIG
+ Standards
XMPP Core
XEP-0060
@@ -95,7 +95,7 @@
0.2
2003-07-29
psa
- Incorporated Standards JIG feedback; changed document type to Informational.
Incorporated Standards list feedback; changed document type to Informational.
0.1
diff --git a/xep-0081.xml b/xep-0081.xml
index 738390b8..6578b03f 100644
--- a/xep-0081.xml
+++ b/xep-0081.xml
@@ -12,7 +12,7 @@
0081
Retracted
Standards Track
- Standards JIG
+ Standards
XMPP Core
XMPP IM
@@ -205,9 +205,9 @@ Encoding considerations: Same as encoding considerations of
of RFC 3920, the encoding must be UTF-8.
Security considerations: All of the security considerations
specified in RFC 3023 and RFC 3920 apply to this XML media
- type. Refer to Section 11 of JSF XEP-0081.
+ type. Refer to Section 11 of XSF XEP-0081.
Interoperability considerations: (none)
-Specification: JSF XEP-0081
+Specification: XSF XEP-0081
Applications which use this media type: non-XMPP applications
(e.g., web browsers or email clients) that wish to invoke
XMPP-compliant applications for instant messaging and
@@ -218,7 +218,7 @@ Additional information: This media type is not to be confused
Person and email address to contact for further information:
XMPP Registrar,
Intended usage: COMMON
-Author/Change controller: JSF, XMPP Registrar
+Author/Change controller: XSF, XMPP Registrar
]]>
The primary standard notation recommended by ISO 8601 includes the separators ("-" for dates and ":" for times), although ISO 8601 allows omission of the separators for applications in which compactness is more important than human readability. It is arguable whether Jabber applications using 'jabber:iq:time' and 'jabber:x:delay' require such compactness, but these protocols are in wide use today and have been implemented using the format shown above. Therefore, applications receiving data in those namespaces SHOULD be liberal in what they accept by handling datetimes either in the "CCYYMMDDThh:mm:ss" format or in the lexical representation defined in XML Schema and specified by this document. Applications generating data in those namespaces SHOULD use the existing format ("CCYYMMDDThh:mm:ss"), and are effectively "grandfathered" with respect to the date and time formats defined herein. While eventually it would be good to deprecate the older datetime representation for these protocols, the schedule for such deprecation (if any) shall be specified in official XEPs for these older protocols.
Jabber-RPC is a special case, since the specification for &xmlrpc; includes only one example for datetimes, which is of the format "CCYYMMDDThh:mm:ss". Apparently many implementations of XML-RPC have taken this lexical representation as canonical, and do not support any other representation; because Jabber-RPC normally provides an interface to software that is outside the Jabber network, it is prudent for Jabber-RPC implementations to generate dates in the format shown in the XML-RPC specification, not that defined in this document.
-New protocols approved by the Jabber Software Foundation MUST use the lexical representations defined in this document.
+New protocols approved by the XMPP Standards Foundation MUST use the lexical representations defined in this document.
The 'date', 'dateTime', and 'time' datatypes defined in XML Schema address several "edge cases" such as dates before the year 0000 and after the year 9999, as well as odd timezones no longer in use; most Jabber applications can safely ignore these edge cases, since it is highly unlikely that a Jabber entity will generate such representations.
diff --git a/xep-0083.xml b/xep-0083.xml index 8f06379b..1ad373c8 100644 --- a/xep-0083.xml +++ b/xep-0083.xml @@ -12,7 +12,7 @@Updated to reflect pubsub and PEP changes; added implementation notes about multiple resources and avatar synchronization.
Peter Millard, a co-author of this specification from version 0.1 through version 0.7, died on April 26, 2006. The remaining authors are thankful for his work on this specification.
+Peter Millard, a co-author of this specification from version 0.1 through version 0.7, died on April 26, 2006. The remaining authors are thankful for his work on user avatars.
The XMPP Registrar shall maintain a registry of stream initiation profiles, located at <http://www.jabber.org/registrar/si-profiles.html>. Any such profile defined in a XMPP Extension Protocol specification MUST be submitted to the XMPP Registrar; profiles defined in non-standard protocol extensions SHOULD be submitted to the XMPP Registrar.
+The XMPP Registrar shall maintain a registry of stream initiation profiles, located at &SIPROFILES;. Any such profile defined in a XMPP Extension Protocol specification MUST be submitted to the XMPP Registrar; profiles defined in non-standard protocol extensions SHOULD be submitted to the XMPP Registrar.
0096
Draft
Standards Track
- Standards JIG
+ Standards
XMPP Core
XEP-0095
diff --git a/xep-0097.xml b/xep-0097.xml
index 5cf01ce8..3fc3640f 100644
--- a/xep-0097.xml
+++ b/xep-0097.xml
@@ -12,7 +12,7 @@
0097
Deferred
Standards Track
- Standards
+ Standards
XEP-0030
None
None
@@ -89,7 +89,7 @@
SEQUENCE:3
SUMMARY:XEPs
LOCATION:foundation@conference.jabber.org
- CATEGORIES:JSF
+ CATEGORIES:XSF
CLASS:PUBLIC
TRANSP:OPAQUE
LAST-MODIFIED:20030418T014527Z
diff --git a/xep-0098.xml b/xep-0098.xml
index a6e6161f..0f5114f7 100644
--- a/xep-0098.xml
+++ b/xep-0098.xml
@@ -12,7 +12,7 @@
0098
Deferred
Standards Track
- Standards JIG
+ Standards
None
None
None
diff --git a/xep-0099.xml b/xep-0099.xml
index bda34b4d..feb4dab6 100644
--- a/xep-0099.xml
+++ b/xep-0099.xml
@@ -12,7 +12,7 @@
0099
Deferred
Standards Track
- Standards JIG
+ Standards
None
None
None
diff --git a/xep-0100.xml b/xep-0100.xml
index d55273f5..f4179f0e 100644
--- a/xep-0100.xml
+++ b/xep-0100.xml
@@ -12,7 +12,7 @@
0100
Active
Informational
- Standards JIG
+ Standards
XMPP Core
XMPP IM
diff --git a/xep-0101.xml b/xep-0101.xml
index 5efa2a7f..0e934832 100644
--- a/xep-0101.xml
+++ b/xep-0101.xml
@@ -12,7 +12,7 @@
0101
Deferred
Standards Track
- Standards JIG
+ Standards
RFC 2616, RFC 2617, XEP-0030
XMPP Core
diff --git a/xep-0102.xml b/xep-0102.xml
index 398b246b..77300951 100644
--- a/xep-0102.xml
+++ b/xep-0102.xml
@@ -12,7 +12,7 @@
0102
Deferred
Standards Track
- Standards JIG
+ Standards
None
None
None
diff --git a/xep-0103.xml b/xep-0103.xml
index d1913a79..6db98a09 100644
--- a/xep-0103.xml
+++ b/xep-0103.xml
@@ -12,7 +12,7 @@
0103
Deferred
Standards Track
- Standards JIG
+ Standards
XMPP Core
XEP-0095
diff --git a/xep-0104.xml b/xep-0104.xml
index e8c1c567..ae0960ef 100644
--- a/xep-0104.xml
+++ b/xep-0104.xml
@@ -12,7 +12,7 @@
0104
Deferred
Standards Track
- Standards JIG
+ Standards
XMPP Core
RFC 3986
diff --git a/xep-0105.xml b/xep-0105.xml
index c39d2615..1805b0a8 100644
--- a/xep-0105.xml
+++ b/xep-0105.xml
@@ -12,7 +12,7 @@
0105
Deferred
Standards Track
- Standards JIG
+ Standards
XEP-0095, XEP-0096
None
None
diff --git a/xep-0106.xml b/xep-0106.xml
index 9a0dc1e2..0033d906 100644
--- a/xep-0106.xml
+++ b/xep-0106.xml
@@ -12,7 +12,7 @@
0106
Draft
Standards Track
- Standards JIG
+ Standards
XMPP Core
XEP-0030
diff --git a/xep-0107.xml b/xep-0107.xml
index dd55baee..51c1afad 100644
--- a/xep-0107.xml
+++ b/xep-0107.xml
@@ -12,7 +12,7 @@
0107
Draft
Standards Track
- Standards JIG
+ Standards
XMPP Core
XEP-0060
diff --git a/xep-0108.xml b/xep-0108.xml
index 800096b7..b4695a14 100644
--- a/xep-0108.xml
+++ b/xep-0108.xml
@@ -12,7 +12,7 @@
0108
Draft
Standards Track
- Standards JIG
+ Standards
XMPP Core
XEP-0060
diff --git a/xep-0109.xml b/xep-0109.xml
index 4dde2081..d935a657 100644
--- a/xep-0109.xml
+++ b/xep-0109.xml
@@ -12,7 +12,7 @@
0109
Deferred
Informational
- Standards JIG
+ Standards
XEP-0030, XEP-0082
None
None
diff --git a/xep-0110.xml b/xep-0110.xml
index 7a37bb30..c8c88b4f 100644
--- a/xep-0110.xml
+++ b/xep-0110.xml
@@ -12,7 +12,7 @@
0110
Deferred
Standards Track
- Standards JIG
+ Standards
None
None
None
diff --git a/xep-0111.xml b/xep-0111.xml
index 155ba401..c4db77d4 100644
--- a/xep-0111.xml
+++ b/xep-0111.xml
@@ -12,7 +12,7 @@
0111
Retracted
Standards Track
- Standards JIG
+ Standards
XMPP Core
RFC 2327
diff --git a/xep-0112.xml b/xep-0112.xml
index 2aa8c0e5..99705536 100644
--- a/xep-0112.xml
+++ b/xep-0112.xml
@@ -12,7 +12,7 @@
0112
Obsolete
Standards Track
- Standards JIG
+ Standards
XMPP Core
XEP-0060
diff --git a/xep-0113.xml b/xep-0113.xml
index f5852364..e71bc6c7 100644
--- a/xep-0113.xml
+++ b/xep-0113.xml
@@ -12,7 +12,7 @@
0113
Deferred
Informational
- Standards JIG
+ Standards
None
None
None
@@ -37,7 +37,7 @@
- As explained in the now obsolete XEP-0010: Whiteboarding JIG XEP-0010: Whiteboarding JIG http://www.xmpp.org/extensions/xep-0010.html : "Jabber is often thought of simply as a system for instant messaging, albeit an open one. However, Jabber technology can be used, and is being used, in applications quite different from simple IM. One of these applications is whiteboarding. In collaborative work, the ability to draw (for example, to design sketches, UML schemas, house architectures, and organizational plans) is essential, as exemplified by the success of real-world whiteboarding applications such as Microsoft NetMeeting. Whiteboarding can also be used for entertainment purposes such as games and quizzes. Because of the value of whiteboarding as an important real-time collaboration tool, other IM services are beginning to offer these capabilities. For these and other reasons, I believe that a good protocol for whiteboarding in Jabber would be of great value".
+ As explained in the now obsolete XEP-0010: Whiteboarding XEP-0010: Whiteboarding SIG http://www.xmpp.org/extensions/xep-0010.html : "Jabber is often thought of simply as a system for instant messaging, albeit an open one. However, Jabber technology can be used, and is being used, in applications quite different from simple IM. One of these applications is whiteboarding. In collaborative work, the ability to draw (for example, to design sketches, UML schemas, house architectures, and organizational plans) is essential, as exemplified by the success of real-world whiteboarding applications such as Microsoft NetMeeting. Whiteboarding can also be used for entertainment purposes such as games and quizzes. Because of the value of whiteboarding as an important real-time collaboration tool, other IM services are beginning to offer these capabilities. For these and other reasons, I believe that a good protocol for whiteboarding in Jabber would be of great value".
The increasing penetration of pen-based devices, such as PDAs and tablet PCs, makes the need for a protocol that allows for sending freehand drawing information more urgent.
Several attempts have been made to create a whiteboarding protocol for Jabber:
diff --git a/xep-0114.xml b/xep-0114.xml
index 57764d9c..884adc02 100644
--- a/xep-0114.xml
+++ b/xep-0114.xml
@@ -12,7 +12,7 @@
0114
Active
Historical
- Standards JIG
+ Standards
XMPP Core
diff --git a/xep-0115.xml b/xep-0115.xml
index c6815d33..8e06a449 100644
--- a/xep-0115.xml
+++ b/xep-0115.xml
@@ -12,7 +12,7 @@
0115
Draft
Standards Track
- Standards JIG
+ Standards
XMPP Core
XMPP IM
diff --git a/xep-0116.xml b/xep-0116.xml
index 9559ee23..3c7287e5 100644
--- a/xep-0116.xml
+++ b/xep-0116.xml
@@ -51,7 +51,7 @@
0116
Experimental
Standards Track
- Standards JIG
+ Standards
XMPP Core
XMPP IM
diff --git a/xep-0117.xml b/xep-0117.xml
index f3238a64..36aaf0f0 100644
--- a/xep-0117.xml
+++ b/xep-0117.xml
@@ -12,7 +12,7 @@
0117
Draft
Standards Track
- Standards JIG
+ Standards
XMPP Core
XMPP IM
@@ -84,7 +84,7 @@
- It addresses common needs of instant messaging users that are addressed by virtually all other popular IM services or systems.
- It is more advanced than basic IM and presence.
- - It has achieved a status of at least Draft within the Jabber Software Foundation's standards process (as defined in &xep0001;).
+ - It has achieved a status of at least Draft within the XMPP Standards Foundation's standards process (as defined in &xep0001;).
diff --git a/xep-0118.xml b/xep-0118.xml
index 3cde4f3d..545dfed8 100644
--- a/xep-0118.xml
+++ b/xep-0118.xml
@@ -12,7 +12,7 @@
0118
Draft
Standards Track
- Standards JIG
+ Standards
XMPP Core
XMPP IM
diff --git a/xep-0119.xml b/xep-0119.xml
index b84ce120..c4bd729d 100644
--- a/xep-0119.xml
+++ b/xep-0119.xml
@@ -12,7 +12,7 @@
0119
Retracted
Standards Track
- Standards JIG
+ Standards
XMPP Core
XMPP IM
@@ -117,7 +117,7 @@ Service | Manager
A protocol is deemed worthy of inclusion in this protocol suite if:
- It addresses "extended presence" data that is defined in other presence services or protocols (e.g., Wireless Village or SIMPLE), or that is felt to be needed within the Jabber/XMPP community.
- - It has achieved a status of at least Draft within the Jabber Software Foundation's standards process (as defined in &xep0001;).
+ - It has achieved a status of at least Draft within the XMPP Standards Foundation's standards process (as defined in &xep0001;).
@@ -156,7 +156,7 @@ Service | Manager
REQUIRED *
- * Note: The User Avatar specification (XEP-0084) has not yet advanced to a status of Draft within the JSF's standards process, and the Extended Presence Protocol Suite will not be submitted for approval until it does so.
+ * Note: The User Avatar specification (XEP-0084) has not yet advanced to a status of Draft within the XSF's standards process, and the Extended Presence Protocol Suite will not be submitted for approval until it does so.
Discovery of extended presence pubsub nodes is expedited through the use of Personal Eventing via Pubsub (PEP), since in PEP services there is a one-to-one relationship between payload types and NodeIDs. The NodeIDs MUST be as follows:
diff --git a/xep-0120.xml b/xep-0120.xml
index de4a74d0..5fdb9abc 100644
--- a/xep-0120.xml
+++ b/xep-0120.xml
@@ -15,7 +15,7 @@
0120
Retracted
Standards Track
- Standards JIG
+ Standards
XMPP Core
None
None
diff --git a/xep-0121.xml b/xep-0121.xml
index b3628b1d..5c9b4062 100644
--- a/xep-0121.xml
+++ b/xep-0121.xml
@@ -15,7 +15,7 @@
0121
Retracted
Informational
- Standards JIG
+ Standards
XEP-0120
None
None
diff --git a/xep-0122.xml b/xep-0122.xml
index 890992bf..bedf5622 100644
--- a/xep-0122.xml
+++ b/xep-0122.xml
@@ -12,7 +12,7 @@
0122
Draft
Standards Track
- Standards JIG
+ Standards
XMPP Core
XEP-0004
@@ -339,7 +339,7 @@
The XMPP Registrar maintains a registry of datatype prefixes used in the context of Data Forms Validation (see http://www.jabber.org/registrar/xdv-prefixes.html), where each prefix denotes a group of related datatypes.
+The XMPP Registrar maintains a registry of datatype prefixes used in the context of Data Forms Validation (see &XDVPREFIXES;), where each prefix denotes a group of related datatypes.
The XMPP Registrar maintains a registry of datatypes used in the context of Data Forms Validation (see http://www.jabber.org/registrar/xdv-datatypes.html), where each datatype name includes the relevant prefix (e.g., "xs:anyURI").
+The XMPP Registrar maintains a registry of datatypes used in the context of Data Forms Validation (see &XDVTYPES;), where each datatype name includes the relevant prefix (e.g., "xs:anyURI").
0123
Retracted
Standards Track
- Standards JIG
+ Standards
XMPP Core, XMPP IM, XEP-0030, XEP-0120
None
None
@@ -53,7 +53,7 @@
- Applicable not just to people but to any entity on the network, including but not limited to servers, components, bots, &xep0045; rooms, &xep0060; nodes, and in general anything that can be addressed as a Jabber ID (as defined in &xmppcore;).
- Usable in encapsulating any information about the entity itself (name, address, description, title, etc.).
- - Extensible enough to handle any metadata that may be needed for current and future applications (including, at a minimum, everything that can be defined in vCard); it must be possible to use it for public protocols defined by the IETF or Jabber Software Foundation as well as for custom or private protocols.
+ - Extensible enough to handle any metadata that may be needed for current and future applications (including, at a minimum, everything that can be defined in vCard); it must be possible to use it for public protocols defined by the IETF or XMPP Standards Foundation as well as for custom or private protocols.
- Well-defined enough, through datatyping and public registries where applicable, to enable robust searching and filtering based on defined data fields and their values.
diff --git a/xep-0124.xml b/xep-0124.xml
index c249d127..9ea792db 100644
--- a/xep-0124.xml
+++ b/xep-0124.xml
@@ -12,7 +12,7 @@
0124
Draft
Standards Track
- Standards JIG
+ Standards
XMPP Core
RFC 1945
diff --git a/xep-0125.xml b/xep-0125.xml
index 77333671..258b556a 100644
--- a/xep-0125.xml
+++ b/xep-0125.xml
@@ -15,7 +15,7 @@
0125
Retracted
Informational
- Standards JIG
+ Standards
XEP-0120
None
None
diff --git a/xep-0126.xml b/xep-0126.xml
index cdf04ec0..9195770b 100644
--- a/xep-0126.xml
+++ b/xep-0126.xml
@@ -12,7 +12,7 @@
0126
Active
Informational
- Standards JIG
+ Standards
XMPP Core
XMPP IM
diff --git a/xep-0127.xml b/xep-0127.xml
index 6a6b5ed1..fd55bae9 100644
--- a/xep-0127.xml
+++ b/xep-0127.xml
@@ -12,7 +12,7 @@
0127
Active
Informational
- Standards JIG
+ Standards
XMPP Core
Common Alerting Protocol
diff --git a/xep-0128.xml b/xep-0128.xml
index 92aa6377..6ef50fe6 100644
--- a/xep-0128.xml
+++ b/xep-0128.xml
@@ -12,7 +12,7 @@
0128
Active
Informational
- Standards JIG
+ Standards
XMPP Core
XEP-0004
@@ -63,7 +63,7 @@
]]>
Note: A <field/> element MAY contain more than one <value/> child if appropriate.
-If the data fields are to be used in the context of a protocol approved by the Jabber Software Foundation, they SHOULD be described in the relevant XMPP Extension Protocol specification and registered in accordance with the rules defined in XEP-0068, resulting in the inclusion of a <field/> element whose 'var' attribute has a value of "FORM_TYPE" and whose 'type' attribute has a value of "hidden".
+If the data fields are to be used in the context of a protocol approved by the XMPP Standards Foundation, they SHOULD be described in the relevant XMPP Extension Protocol specification and registered in accordance with the rules defined in XEP-0068, resulting in the inclusion of a <field/> element whose 'var' attribute has a value of "FORM_TYPE" and whose 'type' attribute has a value of "hidden".
An entity MUST NOT supply extended information about associated children communicated via the 'http://jabber.org/protocol/disco#items' namespace, since a core principle of Service Discovery is that an entity must define its own identity only and must not define the identity of any children associated with the entity.
In general, the Jabber Software Foundation may choose to define at most one FORM_TYPE for each service discovery identity (category+type) registered with the XMPP Registrar. In addition, particular applications may define application-specific FORM_TYPEs as well, and one entity may have multiple service discovery identities (e.g., an XMPP server might also function as a publish-subscribe service). Therefore, it is possible (and allowed) for a single service discovery result to contain multiple service discovery extension elements (potentially up to two elements for each identity). However, in practice it is unlikely that any given service discovery result will contain more than one service discovery extension element.
+In general, the XMPP Standards Foundation may choose to define at most one FORM_TYPE for each service discovery identity (category+type) registered with the XMPP Registrar. In addition, particular applications may define application-specific FORM_TYPEs as well, and one entity may have multiple service discovery identities (e.g., an XMPP server might also function as a publish-subscribe service). Therefore, it is possible (and allowed) for a single service discovery result to contain multiple service discovery extension elements (potentially up to two elements for each identity). However, in practice it is unlikely that any given service discovery result will contain more than one service discovery extension element.
Applications SHOULD ensure that information disclosed in a disco extension is appropriate for discovery by any entity on the network.
diff --git a/xep-0129.xml b/xep-0129.xml index 49090726..f6efcf3e 100644 --- a/xep-0129.xml +++ b/xep-0129.xml @@ -12,7 +12,7 @@Determination of physical presence necessarily involves an invasion of the target entity's "personal space". The &JSF; shall not be held liable for any use of this protocol. Client implementations MUST enable the user to disable support for this protocol via configuration options.
+Determination of physical presence necessarily involves an invasion of the target entity's "personal space". The &XSF; shall not be held liable for any use of this protocol. Client implementations MUST enable the user to disable support for this protocol via configuration options.
Responding entities (whether server or client) MUST NOT return physical presence information to requesting entities that are not entitled to discover such information.
diff --git a/xep-0133.xml b/xep-0133.xml index 05ec5646..ac242ebb 100644 --- a/xep-0133.xml +++ b/xep-0133.xml @@ -12,7 +12,7 @@Background
-When the &JSF; submitted the XMPP Core and XMPP IM specifications to the &IETF;, it ceded change control over the core XML streaming technology developed by the Jabber community. However, the JSF has reserved the right to define extensions to XMPP; furthermore, that right is not exclusive to the JSF, since anyone can define their own public or private extensions to XMPP. These extensions are usually in the form of structured XML data that is qualified by a unique namespace other than those currently reserved by the IETF or the JSF.
+When the &XSF; submitted the XMPP Core and XMPP IM specifications to the &IETF;, it ceded change control over the core XML streaming technology developed by the Jabber community. However, the XSF has reserved the right to define extensions to XMPP; furthermore, that right is not exclusive to the XSF, since anyone can define their own public or private extensions to XMPP. These extensions are usually in the form of structured XML data that is qualified by a unique namespace other than those currently reserved by the IETF or the XSF.
Meaning
When we say that "XMPP is Sacred", we mean that good protocol design must work within the context of XMPP and not require changes to the core protocols. For one thing, any such changes would need to be pursued within the IETF. Further, the core semantics most likely provide everything that a protocol designer needs. If you think that you need to define a new kind of top-level stanza (other than &MESSAGE;, &PRESENCE;, and &IQ;) or a new value of the 'type' attribute for any stanza kind, then you need to think again. Treat XMPP as a transport layer and build extensions on top of that layer (among other things, this implies that you must not modify the foundation when you are working on higher-level structures, for example by adding adding elements and attributes to the XMPP schemas on the theory that if applications will ignore them; define your own extensions in a separate namespace). A further implication of respecting XMPP is using structured data formats (e.g., applications of &w3xml; rather than binary or plaintext formats) whenever possible. Finally, as explained in XMPP Core, the &PRESENCE; stanza exists to broadcast network and communications availability only; for more advanced information publishing, use &xep0060;.
Examples
@@ -80,7 +80,7 @@Background
The Jabber community has been developing wire protocols for XML streaming, presence, and instant messaging since 1999. In that time, members of the community have defined a number of building blocks that can be used as the basis for further development. Furthermore, many smart people have created open protocols within other standards development organizations, including the IETF, the &W3C;, &OASIS;, the &ITU;, and the &DUBLINCORE;.
Meaning
-Good protocol designers "stand on the shoulders of giants" by re-using protocols that have been defined within the JSF and within other standards development organizations. That does not mean we don't define new protocols, because sometimes that is necessary. However, we are aware of work completed by others and we make use of it, especially when that work is outside the Jabber community's core competence areas (e.g., security or multimedia data formats rather than XML streaming, presence, and real-time messaging). Furthermore, the JSF prefers to re-use open protocols wherever possible. Finally, just as with XMPP, so also with XMPP extensions defined through the JSF: do not modify existing schemas (e.g., adding new elements and attributes) except through the XMPP extension process; instead, define extensions in a separate namespace).
+Good protocol designers "stand on the shoulders of giants" by re-using protocols that have been defined within the XSF and within other standards development organizations. That does not mean we don't define new protocols, because sometimes that is necessary. However, we are aware of work completed by others and we make use of it, especially when that work is outside the Jabber community's core competence areas (e.g., security or multimedia data formats rather than XML streaming, presence, and real-time messaging). Furthermore, the XSF prefers to re-use open protocols wherever possible. Finally, just as with XMPP, so also with XMPP extensions defined through the XSF: do not modify existing schemas (e.g., adding new elements and attributes) except through the XMPP extension process; instead, define extensions in a separate namespace).
Examples
Examples of re-using existing Jabber protocols include &xep0095; (which re-uses &xep0020;) and XEP-0126: Invisibility (which re-uses the privacy lists protocol defined in XMPP IM). Examples of re-using non-Jabber protocols include &xep0065; (which makes use of &rfc1928;) and &xep0127; (which defines a way to send &oasiscap; data via Jabber). Here again XEP-0071 provides an example: it re-uses XHTML 1.0 (an open protocol developed by a recognized standards development organization) rather than RTF (a closed protocol under the control of the Microsoft Corporation).
Background
Since the beginning, privacy and security have been important priorities within the Jabber community. That must not change.
Meaning
-Good protocols respect the confidentiality of data generated or communicated by users and applications as well as the security of the system or network as a whole. Although privacy and security considerations have been dealt with at the core XMPP layer, application-level protocols must not compromise privacy and security. Attention to these matters, along with rigorous cross-area review and close scrutiny by protocol designers (in the form of the &COUNCIL; and &SJIG;), will help ensure that the protocols we develop will provide a strong foundation for communication over the Internet.
+Good protocols respect the confidentiality of data generated or communicated by users and applications as well as the security of the system or network as a whole. Although privacy and security considerations have been dealt with at the core XMPP layer, application-level protocols must not compromise privacy and security. Attention to these matters, along with rigorous cross-area review and close scrutiny by protocol designers (in the form of the &COUNCIL; and &SSIG;), will help ensure that the protocols we develop will provide a strong foundation for communication over the Internet.
Examples
As is well-known, the presence subscription model developed by the Jabber community and specified in XMPP IM requires approval before a contact can view a user's presence. Similarly, Jabber has always included strong authentication methods, which have been further improved through the use of SASL (&rfc4422;).
diff --git a/xep-0135.xml b/xep-0135.xml index 2a17f726..e5bb6797 100644 --- a/xep-0135.xml +++ b/xep-0135.xml @@ -12,7 +12,7 @@The XMPP Registrar includes 'http://jabber.org/protocol/compress' in its registry of protocol namespaces.
The XMPP Registrar maintains a registry of compression methods at <http://www.jabber.org/registrar/compress.html>.
+The XMPP Registrar maintains a registry of compression methods at &COMPRESSMETHODS;.
- Security JIG
- This document proposes the formation of a Jabber Interest Group devoted to the analysis of security threats related to Jabber technologies.
+ Security SIG
+ This document proposes the formation of a Special Interest Group devoted to the analysis of security threats related to Jabber technologies.
&LEGALNOTICE;
0139
Retracted
- JIG Formation
- None
+ SIG Formation
+ None
0.2
2004-09-15
psa
- Changed status to Retracted since it now appears unnecessary to form a JIG in order to complete this work; rather, it should be sufficient to write a XEP and solicit feedback from appropriate security experts before the Last Call. However, such a XEP should use the process described herein.
+ Changed status to Retracted since it now appears unnecessary to form a SIG in order to complete this work; rather, it should be sufficient to write a XEP and solicit feedback from appropriate security experts before the Last Call. However, such a XEP should use the process described herein.
0.1
@@ -44,22 +44,22 @@
- Because security is a core value within the Jabber community, it is appropriate for the Jabber Software Foundation to assess potential security threats related to technologies that implement the Jabber protocols (including XMPP and defined XMPP extensions), as well as ways to address the threats (for general information about the Internet threat model, see &rfc3552;). Furthermore, since security threats are wide-ranging and of broad concern, it would be valuable for interested members of the entire Jabber community to discuss these matters. Unfortunately, security discussions can often be theoretical, contentious, and inconclusive. Thus it is imperative that discussion proceed based on a methodical process of threat identification, risk analysis, and prioritization before moving on to documentation of threat responses (preferably in protocol specifications such as &xep0001;). This document proposes a forum and process for such security discussions in the form of a Jabber Interest Group (see &xep0002;) that shall report to the &COUNCIL; in accordance with Article VIII of the &BYLAWS;.
+ Because security is a core value within the Jabber community, it is appropriate for the XMPP Standards Foundation to assess potential security threats related to technologies that implement the Jabber protocols (including XMPP and defined XMPP extensions), as well as ways to address the threats (for general information about the Internet threat model, see &rfc3552;). Furthermore, since security threats are wide-ranging and of broad concern, it would be valuable for interested members of the entire Jabber community to discuss these matters. Unfortunately, security discussions can often be theoretical, contentious, and inconclusive. Thus it is imperative that discussion proceed based on a methodical process of threat identification, risk analysis, and prioritization before moving on to documentation of threat responses (preferably in protocol specifications such as &xep0001;). This document proposes a forum and process for such security discussions in the form of a Special Interest Group (see &xep0002;) that shall report to the &COUNCIL; in accordance with Article VIII of the &BYLAWS;.
- The role of the Security JIG shall be to identify and describe security threats related to Jabber technologies, analyze their potential risk, assign priorities to each threat, provide references to existing responses, and (where appropriate) provisionally recommend improvements in Jabber protocols and technologies in order to address the identified threats. The Security JIG shall not itself develop or approve protocols, which tasks shall remain under the purview of the &SJIG; and the Jabber Council respectively.
+ The role of the Security SIG shall be to identify and describe security threats related to Jabber technologies, analyze their potential risk, assign priorities to each threat, provide references to existing responses, and (where appropriate) provisionally recommend improvements in Jabber protocols and technologies in order to address the identified threats. The Security SIG shall not itself develop or approve protocols, which tasks shall remain under the purview of the &SSIG; and the Jabber Council respectively.
- The Security JIG shall be open to the public and shall not be limited to elected members of the Jabber Software Foundation. Security JIG discussions shall be conducted in open forums, including a dedicated mailing list at <security-jig@jabber.org>. The process for moderating such discussions shall be decided by the members of the Security JIG, but such moderation is strongly encouraged in order to follow the orderly process of threat identification and risk analysis outlined below.
+ The Security SIG shall be open to the public and shall not be limited to elected members of the XMPP Standards Foundation. Security SIG discussions shall be conducted in open forums, including a dedicated mailing list at <security-jig@jabber.org>. The process for moderating such discussions shall be decided by the members of the Security SIG, but such moderation is strongly encouraged in order to follow the orderly process of threat identification and risk analysis outlined below.
- The Security JIG shall be a standing JIG, and shall exist as long as the Jabber Council deems it useful.
+ The Security SIG shall be a standing SIG, and shall exist as long as the Jabber Council deems it useful.
- The Security JIG shall produce at least the following deliverables:
+ The Security SIG shall produce at least the following deliverables:
-
-
A brief document specifying the process by which the JIG shall identify, define, analyze, and prioritize a collection of documented security-related threats. This process document will not identify threats or define ways to address them, but instead specify the process to be followed in Steps 2 and 3 below. In defining the process, the JIG should also describe some of its guiding principles, such as:
+ A brief document specifying the process by which the SIG shall identify, define, analyze, and prioritize a collection of documented security-related threats. This process document will not identify threats or define ways to address them, but instead specify the process to be followed in Steps 2 and 3 below. In defining the process, the SIG should also describe some of its guiding principles, such as:
- Rough consensus and running code are superior to "perfect" solutions
- Security measures that cannot or will not be implemented are useless
diff --git a/xep-0140.xml b/xep-0140.xml
index 206d2b82..50e092bb 100644
--- a/xep-0140.xml
+++ b/xep-0140.xml
@@ -12,7 +12,7 @@
0140
Retracted
Informational
- Standards JIG
+ Standards
XMPP Core
XMPP IM
diff --git a/xep-0141.xml b/xep-0141.xml
index 089c2d0d..ff40ef1e 100644
--- a/xep-0141.xml
+++ b/xep-0141.xml
@@ -12,7 +12,7 @@
0141
Draft
Standards Track
- Standards JIG
+ Standards
XMPP Core
XEP-0004
@@ -66,7 +66,7 @@
All of the use cases refer to the following form:
- JSF Application
+ XSF Application
Please fill out this form
@@ -100,14 +100,14 @@
One of the simplest layout usages is to partition fields into pages. This is done by including one or more <page/> elements within the x:data form. Each <page/> element SHOULD possess a "label" attribute to label the page, MAY contain a <text/> child element for additional information, and SHOULD contain a <fieldref/> element for each field to be included in the page. To reference an x:data field, the <fieldref/> element's "var" attribute MUST be the same as the intended <field/> element's "var" attribute.
- JSF Application
+ XSF Application
Please fill out this form
This is page one of three.
- Note: In accordance with the JSF privacy policy, your personal information will
+ Note: In accordance with the XSF privacy policy, your personal information will
never be shared outside the organization in any way for any purpose; however,
- your name and JID may be published in the JSF membership directory.
+ your name and JID may be published in the XSF membership directory.
You're almost done!
This is where you describe your future plans and why you think you
- deserve to be a member of the Jabber Software Foundation.
+ deserve to be a member of the XMPP Standards Foundation.
The next usage of layout is to partition pages into sections. This is done by including one or more <section/> elements within each <page/> element. Each <section/> element SHOULD possess a "label" attribute to identify the section, MAY contain a <text/> child element for additional information, and SHOULD contain a <fieldref/> element for each field to be included in the section. A <section/> element MUST contain at least one <fieldref/> element or <reportedref/> element. To reference an x:data field, the <fieldref/> element's "var" attribute MUST be the same as the intended <field/> element's "var" attribute.
- JSF Application
+ XSF Application
Please fill out this form
- Note: In accordance with the JSF privacy policy, your personal information will
+ Note: In accordance with the XSF privacy policy, your personal information will
never be shared outside the organization in any way for any purpose; however,
- your name and JID may be published in the JSF membership directory.
+ your name and JID may be published in the XSF membership directory.
You're almost done!
This is where you describe your future plans and why you think you
- deserve to be a member of the Jabber Software Foundation.
+ deserve to be a member of the XMPP Standards Foundation.
- Note: In accordance with the JSF privacy policy, your personal information will
+ Note: In accordance with the XSF privacy policy, your personal information will
never be shared outside the organization in any way for any purpose; however,
- your name and JID may be published in the JSF membership directory.
+ your name and JID may be published in the XSF membership directory.
Who are you?
@@ -260,7 +260,7 @@
This is where you describe your future plans and why you think you
- deserve to be a member of the Jabber Software Foundation.
+ deserve to be a member of the XMPP Standards Foundation.
0142
Deferred
Standards Track
- Standards JIG
+ Standards
XMPP Core
XEP-0030
diff --git a/xep-0143.xml b/xep-0143.xml
index 102d0c17..a2e786fa 100644
--- a/xep-0143.xml
+++ b/xep-0143.xml
@@ -12,7 +12,7 @@
0143
Active
Procedural
- Standards JIG
+ Standards
Council
XEP-0001
@@ -53,8 +53,8 @@
- The &JSF; receives a significant number of proposals for defining extensions to the core XMPP protocols specified in &xmppcore;. However, it is not always clear to authors how to best structure a proposal in order for it to be accepted as an XMPP Extension Protocol (XEP) and then advance through the JSF's standards process. Therefore, this document provides guidelines that are intended to help authors write better XMPP Extension Protocol specifications.
- These guidelines assume that the reader is familiar with the XEP series of documents and the processes for handling them within the JSF, as defined in &xep0001;.
+ The &XSF; receives a significant number of proposals for defining extensions to the core XMPP protocols specified in &xmppcore;. However, it is not always clear to authors how to best structure a proposal in order for it to be accepted as an XMPP Extension Protocol (XEP) and then advance through the XSF's standards process. Therefore, this document provides guidelines that are intended to help authors write better XMPP Extension Protocol specifications.
+ These guidelines assume that the reader is familiar with the XEP series of documents and the processes for handling them within the XSF, as defined in &xep0001;.
The prospective author is strongly encouraged to complete some research before submitting a proposal for consideration as an XMPP Extension Protocol. In particular, the author should do the following:
@@ -62,7 +62,7 @@
- Review the XMPP RFCs and experimental or approved XMPP Extension Protocols to determine if the proposed protocol extension is truly needed in order to fill a gap in existing Jabber/XMPP technologies and protocols.
- Review rejected and deferred XMPP Extension Protocol specifications to determine if similar extensions have been proposed in the past but not approved by the &COUNCIL;.
- Review protocols developed within other standards development organizations, such as the &IETF; and &W3C;, to determine if they might be more appropriate than a new XMPP extension.
- - Review discussions within the &SJIG; to determine if similar functionality has been discussed in the past or is currently under discussion.
+ - Review discussions within the &SSIG; to determine if similar functionality has been discussed in the past or is currently under discussion.
After completing this research, the prospective author may conclude that a new protocol extension is needed. If so, the author is strongly advised to do the following:
@@ -78,7 +78,7 @@
- Contact the &EDITOR; so that he knows to expect your submission.
- Write your proposal following the guidelines described herein.
- - Make sure you read, understand, and agree to the &JSFIPR; before you submit your proposal.
+ - Make sure you read, understand, and agree to the &XSFIPR; before you submit your proposal.
- Send your XML file (or a URL for the file) to the XMPP Extensions Editor.
@@ -96,7 +96,7 @@
The XML character data of the <title/> element is the title of your XEP. Choose a descriptive title that is less than five words long. The XMPP Extensions Editor may change this in consultation with the author.
The XML character data of the <abstract/> element SHOULD be one sentence that captures the essence of your proposal (usually beginning "This document defines a protocol that..."). The XMPP Extensions Editor has been known to modify the abstract so that it accurately describes the proposal.
The XML character data of the <legal/> element MUST be as follows:
- This XMPP Extension Protocol is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy (<http://www.xmpp.org/extensions/ipr-policy.shtml>). This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
+ This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy (<http://www.xmpp.org/extensions/ipr-policy.shtml>). This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
The XML character data of the <number/> element SHOULD be "xxxx"; this will be changed to the next sequential XEP number by the XMPP Extensions Editor if the XMPP Council accepts the proposal as an XMPP Extensions Protocol.
The XML character data of the <status/> element SHOULD be "ProtoXEP" since all proposals start out as "proto-XEPs"; this will be changed to "Experimental" if the XMPP Council accepts the proposal as an XMPP Extensions Protocol.
The XML character data of the <type/> element SHOULD be either "Standards Track" or "Informational" (there are also Historical, Humorous, and Procedural XEPs, but these are uncommon and usually written by the XMPP Extensions Editor). A Standards Track XEP defines a XMPP extension intended to be used as a common part of Jabber/XMPP technologies. An Informational XEP defines best practices or a usage profile related to XMPP or an XMPP Extension Protocol (e.g., &xep0175;).
@@ -140,7 +140,7 @@
- Describe the expected behavior of Jabber/XMPP clients, servers, and components when using this protocol.
- Include lots of protocol examples.
- We just said so, but we will repeat ourselves: include lots of protocol examples. Examples help not only implementors but also those who will review your proposal in the Standards JIG and XMPP Council. You get extra credit with the XMPP Extensions Editor if you follow Jabber tradition by using characters and situations from the plays of Shakespeare:
+ We just said so, but we will repeat ourselves: include lots of protocol examples. Examples help not only implementors but also those who will review your proposal in the Standards SIG and XMPP Council. You get extra credit with the XMPP Extensions Editor if you follow Jabber tradition by using characters and situations from the plays of Shakespeare:
This section is REQUIRED. The IANA is the Internet Assigned Numbers Authority, the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. Most proposals do not require interaction with the IANA, in which case the text of this section SHOULD read "This document requires no interaction with the Internet Assigned Numbers Authority (IANA)." If your proposal requires interaction with the IANA, discuss the matter with the XMPP Extensions Editor. Do not contact the IANA on your own!
This section is REQUIRED. The XMPP 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. If your proposal does not require interaction with the XMPP Registrar, the text of this section SHOULD read "No namespaces or parameters need to be registered with the XMPP Registrar as a result of this document." Refer to Draft or Final XEPs for appropriate text in other cases, or consult with the XMPP Extensions Editor.
+This section is REQUIRED. The XMPP Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the XMPP Standards Foundation. If your proposal does not require interaction with the XMPP Registrar, the text of this section SHOULD read "No namespaces or parameters need to be registered with the XMPP Registrar as a result of this document." Refer to Draft or Final XEPs for appropriate text in other cases, or consult with the XMPP Extensions Editor.
An XML Schema is required in order for protocols to be approved by the XMPP Council. The XMPP Extensions Editor can assist you in defining an XML Schema for the protocol you are proposing.
@@ -244,7 +244,7 @@ echo -n 'bard@shakespeare.lit' | openssl dgst -sha1An element or attribute is qualified by (rather than "scoped by" or "in") a particular namespace.
For precision, the JSF follows IETF usage by placing all punctuation outside the quotation marks unless one is quoting text that includes the punctuation. Example: the port used for client communications is "5222".
+For precision, the XSF follows IETF usage by placing all punctuation outside the quotation marks unless one is quoting text that includes the punctuation. Example: the port used for client communications is "5222".
The Jabber protocols have long included a method for sending roster items from one entity to another, making use of the 'jabber:x:roster' namespace. Because this protocol extension was not required by &rfc2779;, it was removed from &xmppim; and documented for historical purposes in &xep0093;. However, since that time discussions in the &SJIG; have revealed that it would be helpful to use roster item exchange in the problem spaces of "shared groups" (e.g., predefined roster groups used within an organization) and roster synchronization (e.g., keeping a Jabber roster in sync with a contact list on a legacy IM service). These problem spaces require a slightly more sophisticated kind of roster item exchange than was documented in XEP-0093, specifically the ability to indicate whether a roster item is to be added, deleted, or modified. Therefore this document redefines roster item exchange to provide this functionality in a way that is backwards-compatible with existing implementations, albeit using a modern namespace URI of 'http://jabber.org/protocol/rosterx' rather than the old 'jabber:x:roster' namespace name. Further specifications will define how to solve the problems of shared groups and roster synchronization using the protocol defined herein.
+The Jabber protocols have long included a method for sending roster items from one entity to another, making use of the 'jabber:x:roster' namespace. Because this protocol extension was not required by &rfc2779;, it was removed from &xmppim; and documented for historical purposes in &xep0093;. However, since that time discussions in the &SSIG; have revealed that it would be helpful to use roster item exchange in the problem spaces of "shared groups" (e.g., predefined roster groups used within an organization) and roster synchronization (e.g., keeping a Jabber roster in sync with a contact list on a legacy IM service). These problem spaces require a slightly more sophisticated kind of roster item exchange than was documented in XEP-0093, specifically the ability to indicate whether a roster item is to be added, deleted, or modified. Therefore this document redefines roster item exchange to provide this functionality in a way that is backwards-compatible with existing implementations, albeit using a modern namespace URI of 'http://jabber.org/protocol/rosterx' rather than the old 'jabber:x:roster' namespace name. Further specifications will define how to solve the problems of shared groups and roster synchronization using the protocol defined herein.
XEP-0093 did not define the requirements for roster item exchange. This section remedies that oversight.
@@ -237,7 +237,7 @@These are described more completely below.
Roster item exchange as developed within the early Jabber community and documented in XEP-0093 was used to send a roster item from one user to another in a manner more structured than simply typing a third party's JID in a chat window. This usage is still encouraged. However, if the sender is a human user and/or the sending application has a primary Service Discovery category of "client" (e.g., a bot)
Roster item exchange as developed within the early Jabber community and documented in XEP-0093 was used to send a roster item from one user to another in a manner more structured than simply typing a third party's JID in a chat window. This usage is still encouraged. However, if the sender is a human user and/or the sending application has a primary Service Discovery category of "client" (e.g., a bot)
The nature of client proxy gateways (i.e., entities with a service discovery category of "gateway") is specified more fully in &xep0100;. Herein we describe how such gateways should use roster item exchange, and how receiving applications should treat roster items received from such gateways.
diff --git a/xep-0145.xml b/xep-0145.xml index f79be12d..cb00076d 100644 --- a/xep-0145.xml +++ b/xep-0145.xml @@ -12,7 +12,7 @@For each such action, the XMPP Registrar maintains a RECOMMENDED "querytype" (this can be thought of as an action name or "verb"; see RFC 4622 for syntax and semantics) as well as an OPTIONAL list of keys to be used in key-value pairs if appropriate.
-The querytypes and key-value pairs related to RFC 3920 and RFC 3921 are defined herein; the querytypes and key-value pairs related to protocols defined in the JSF's XEP series are defined in the relevant XMPP Extension Protocol specifications.
+The querytypes and key-value pairs related to RFC 3920 and RFC 3921 are defined herein; the querytypes and key-value pairs related to protocols defined in the XMPP Standards Foundation's XEP series are defined in the relevant XMPP Extension Protocol specifications.
It may desirable for an XMPP IRI/URI to trigger a specialized interface for sending an XMPP message stanza. The RECOMMENDED querytype for this action is "message". If no key-value pair is provided, interacting with an XMPP IRI/URI that contains a querytype of "message" SHOULD trigger an interface that enables the user to input the text of an XMPP message and other relevant parameters (e.g., a message subject or &xep0071; markup).
The Data Forms field that represents a biographical URL is "bio".
Implementation experience indicates that a dual-stack approach may not be feasible on all the computing platforms for which Jabber clients have been written, or even desirable on platforms where it is feasible. Therefore, it seems reasonable to define an XMPP signalling protocol that can provide the necessary signalling semantics while also making it relatively straightforward to interoperate with existing Internet standards.
-As a result of feedback received on XEP-0111, the original authors of this document (Joe Hildebrand and Peter Saint-Andre) began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team,
As a result of feedback received on XEP-0111, the original authors of this document (Joe Hildebrand and Peter Saint-Andre) began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team,
The purpose of Jingle is not to supplant or replace SIP. Because dual-stack XMPP+SIP clients are difficult to build, given that they essentially have two centers of program control,
The authors would like to thank Rohan Mahy for his valuable input on early versions of this document. Rob Taylor, Dafydd Harries, Jussi Laako, Saku Vainio, Antti Ijäs, Brian West, Anthony Minessale, Matt O'Gorman, and others have also provided helpful input. Thanks also to those who have commented on the &SJIG; and (earlier) Jingle
The authors would like to thank Rohan Mahy for his valuable input on early versions of this document. Rob Taylor, Dafydd Harries, Jussi Laako, Saku Vainio, Antti Ijäs, Brian West, Anthony Minessale, Matt O'Gorman, and others have also provided helpful input. Thanks also to those who have commented on the &SSIG; and (earlier) Jingle
The XMPP Registrar maintains a registry of application-specific error conditions (see &APPERRORS;).
-All application-specific error conditions that are defined in XMPP Extension Protocol specifications MUST be included in this registry. Application-specific error conditions that are defined outside of the Jabber Software Foundation's standards process (see &xep0001;) MAY be included in this registry, but it is not required for them to be so registered.
+All application-specific error conditions that are defined in XMPP Extension Protocol specifications MUST be included in this registry. Application-specific error conditions that are defined outside of the XMPP Standards Foundation's standards process (see &xep0001;) MAY be included in this registry, but it is not required for them to be so registered.
0183
Active
Humorous
- Standards JIG
+ Standards
Council
XMPP Core
diff --git a/xep-0184.xml b/xep-0184.xml
index 991712f8..87ac0a81 100644
--- a/xep-0184.xml
+++ b/xep-0184.xml
@@ -10,9 +10,9 @@
This document specifies an XMPP protocol extension for message receipts.
&LEGALNOTICE;
0184
- Proposed
+ Experimenal
Standards Track
- Standards JIG
+ Standards
Council
XMPP Core
@@ -230,7 +230,7 @@
controlled by the intended recipient has received and processed
the message, including presentation to a human user if appropriate.
- XEP-xxxx
+ XEP-0184
]]>
Further clarified relationship to privacy lists.
The simple communications blocking protocol specified herein is intended to be a user-friendly "front end" to a subset of the functionality defined by the privacy lists protocol (XEP-0016). If a service deploys both privacy lists and simple communications blocking, both protocols MUST use the same back-end data store.
-Wherever possible, this document attempts to define a protocol that is fully consistent with XEP-0016. If a particular aspect of functionality is not specified herein, the relevant text in XEP-0016 shall be taken to apply.
+The simple communications blocking protocol specified herein is intended to be a user-friendly "front end" to a subset of the functionality defined by the privacy lists protocol (XEP-0016). If a service deploys both privacy lists and simple communications blocking, the service MUST use the same back-end data store for both protocols. (Note: Wherever possible, this document attempts to define a protocol that is fully consistent with XEP-0016; if a particular aspect of functionality is not specified herein, the relevant text in XEP-0016 shall be taken to apply.)
+A service SHOULD map the blocklist to the default privacy list, where each blocked JID is represented as a privacy list item of type "jid" and action "deny". If this is done and none of the user's clients ever use the privacy lists protocol, then the blocklist will always apply. This mapping has the following implications:
+If all of a user's clients always use simple communications blocking, then the default privacy list will be equivalent to the blocklist and the default privacy list will be a kind of "virtual list" (in the sense that it is never modified directly by any of the clients).
If one of a user's clients uses privacy lists instead of blocklists and modifies the default privacy list by removing a blocked JID or blocking a new JID, then that change will be reflected in the blocklist.
If one of a user's clients uses privacy lists and does anything but block or unblock a JID, then that change will not be reflected in the blocklist (since blocklists cannot represent anything except blocked JIDs).
If one of a user's clients removes the default privacy list and substitutes a new list for the old list, the blocked JIDs in the new default privacy list (if any) will become the new blocklist.
If one of a user's clients makes active something other than the default privacy list, the user may receive communications from contacts who are blocked in the default list.
Because of the potential for confusion between block lists and privacy lists, it is NOT RECOMMENDED for a client to request both the block list and privacy lists in the same session.
Matching of JIDs as specified in the 'jid' attribute of the <item/> element SHOULD proceed in the following order (this is consistent with XEP-0016):
diff --git a/xep-0192.xml b/xep-0192.xml index 1e6e697d..2923d861 100644 --- a/xep-0192.xml +++ b/xep-0192.xml @@ -12,7 +12,7 @@Those shortcomings are addressed in this document, and the recommendations described herein have been incorporated into rfc3920bis.
The XMPP stream feature for Transport Layer Security (TLS) includes a <required/> child element that can be used to indicate that negotiation of TLS must be completed before proceeding with the rest of the stream negotiation. However, as defined in RFC 3920 the remaining stream features do not include the ability to flag that negotiation of the feature is required in order to (1) proceed with the negotiation or (2) begin sending XML stanzas. Because the non-TLS features lack a required flag, it is not possible for the initiating entity to know definitively how to proceed at any given stage in the stream negotiation, and the only way for the initiating entity to know whether it may begin sending XML stanzas is to attempt to send them (the receiving entity will return a ¬authorized; stream error if not all required features have been negotiated). This state of affairs is suboptimal. Therefore, we recommend that every stream feature must include the ability to flag the feature as required or not required.
+The XMPP stream feature for Transport Layer Security (TLS) includes a <required/> child element that can be used to indicate that negotiation of TLS must be completed before proceeding with the rest of the stream negotiation. However, as defined in RFC 3920 the remaining stream features do not include the ability to flag that negotiation of the feature is required in order to (1) proceed with the negotiation or (2) begin sending XML stanzas. Because the non-TLS features lack a required flag, it is not possible for the initiating entity to know definitively how to proceed at any given stage in the stream negotiation, and the only way for the initiating entity to know whether it may begin sending XML stanzas is to attempt to send them (the receiving entity will return a ¬authorized; stream error if not all required features have been negotiated). This state of affairs is suboptimal. Therefore, every stream feature must include the ability to flag the feature as required or not required. When the initiating entity receives a stream features element with no features containing a <required/> element, it knows thatt the receiving party will accept XML stanzas over the stream.
The following examples show a possible flow of stream negotiation between a client and a server, using the required flag for all but one of the features and following the order specified in &xep0170;. (This example is more verbose than a typical stream negotiation flow, but is provided here for the sake of completeness.)
Since the inception of the &JSF;, the &EDITOR; has been Peter Saint-Andre. However, if he gets hit by a bus or is replaced by someone else, this document may prove useful.
+Since the inception of the &XSF;, the &EDITOR; has been Peter Saint-Andre. However, if he gets hit by a bus or is replaced by someone else, this document may prove useful.
The XMPP Extensions Editor manages the XMPP extensions process as defined in &xep0001;. In addition, the XMPP Extensions Editor functions as the XMPP Registrar as defined in &xep0053;. Read those documents first, since this README focuses on mechanics rather than philosophy.