As approved by the members of the Jabber Software Foundation, changed Jabber Enhancement Proposal to XMPP Extension Protocol.
Added status of Retracted; corrected several errors related to the Jabber Registrar.
Added status of Retracted; corrected several errors related to the XMPP Registrar.
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 JEP (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 Jabber 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 JSF members before being proposed for a Council vote; (3) clarification that the Council votes only on a particular revision of a JEP (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.
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 &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 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 standards process specified herein has been developed and refined in order to meet these objectives.
The five JEP types are described in the following sections.
-The approving body for all Standards Track, Informational, Historical, and Humorous JEPs is the &COUNCIL;; the approving body for Procedural JEPs may be either the &BOARD; or the Jabber Council.
-This document focuses primarily on Standards Track JEPs since they are the vehicle for defining new protocols, but also discusses the other JEP types.
+The five XEP types are described in the following sections.
+The approving body for all Standards Track, Informational, Historical, and Humorous XEPs is the &COUNCIL;; the approving body for Procedural XEPs may be either the &BOARD; or the XMPP Council.
+This document focuses primarily on Standards Track XEPs since they are the vehicle for defining new protocols, but also discusses the other XEP types.
A Standards Track JEP defines one of the following:
+A Standards Track XEP defines one of the following:
An Informational JEP defines one of the following:
+An Informational XEP defines one of the following:
An Historical JEP documents a protocol that was developed before the JEP process was instituted, but that is still in use within the Jabber/XMPP developer community; such a JEP may or may not be obsoleted by a Standards Track JEP, or upgraded to Standards Track.
+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.
A Humorous JEP attempts to be funny by defining a protocol that would never be used in the real world; such JEPs are usually published on April 1 and automatically have a status of Active.
+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 JEP defines a process or activity to be followed by the JSF, including JIG charters as specified by &jep0002;.
+A Procedural XEP defines a process or activity to be followed by the JSF, including JIG charters as specified by &xep0002;.
The JSF welcomes and encourages the submission of protocols to the JSF's standards process.
Note well that JEP authors must transfer ownership of their protocols (but not implementations thereof) to the JSF. Refer to the &JSFIPR; for details. JEP authors must make sure that they have read, understood, and agreed to the JSF IPR Policy before submitting a proposal to the JEP Editor!
-All proposals submitted to the JSF for consideration as JEPs must contain the following information:
+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:
Legal Notice -- the legal notice must be exactly that which is specified in the JSF IPR Policy
Author Information -- first name, last name, email address, and Jabber ID are all required and must be provided for all authors
Finally, Standards Track, Informational, and Historical JEPs must conform to &rfc2119; in the use of terminology regarding requirements levels.
+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 JEPs is the Jabber Council; therefore, in order to be published as a JEP, a proposal must first be accepted by the Jabber Council (the only exceptions are certain kinds of Procedural JEPs, for which the approving body may be the JSF Board of Directors and which may be accepted for publication by the JEP Editor in consultation with the Board). Upon receiving a proposal, the JEP Editor shall do the following:
+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:
If no member of the Jabber Council objects to publication of the proposal within seven (7) days or at the next meeting of the Council, the JEP Editor shall accept it as a JEP. If objections are raised by the Council on the Standards-JIG list or in its meeting, the JEP author is encouraged to address the feedback of the Council and to submit a revised version of the proposal and/or confer with the JEP Editor or objecting Council member(s) regarding how to proceed.
-If the proposal is accepted as a JEP, the JEP Editor shall do the following:
+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 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 Jabber Council and minimal formatting compliance) need to be met in order for a JEP to be granted a status of Experimental. The granting of Experimental status must not be construed as indicating any level of approval by the JSF, the Jabber Council, or the Jabber/XMPP developer community. Implementation of Experimental JEPs 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 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.
Once a JEP is published, it becomes available for public discussion within the Standards JIG and the broader Jabber/XMPP developer community. The JEP author is responsible for collecting feedback from the Jabber/XMPP developer community during the life of the JEP and for incorporating such feedback into the proposal. In order to fully participate in discussion of the proposal, the JEP author should be subscribed to the Standards-JIG list, which is the primary venue for discussion of JEPs. Changes made based on feedback received by the JEP author must be captured in updated versions of the JEP (e.g., 0.2 after 0.1), each of which must be put under source control and subsequently published and announced by the JEP Editor.
-If an Experimental JEP is inactive (i.e., no updated versions are published) for a period of six (6) months, the JEP Editor shall automatically change the status of the JEP to Deferred unless it is in the queue of JEPs under active consideration for advancement by the Jabber Council; upon submission of an updated version, the JEP Editor shall change the status back to Experimental.
+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.
+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 JEP may be proposed to the Jabber Council for advancement to Draft (Standards Track JEPs) or Active (Historical, Informational, and Procedural JEPs), the Jabber Council must agree that the JEP is ready to be considered for advancement. Once the Council so agrees, it shall instruct the JEP Editor to (1) change the status of the JEP from Experimental to Proposed and (2) issue a Last Call for open discussion on the Standards JIG list. The Last Call shall expire not less than 10 days after the date of issue.
-Once the consensus of the Standards JIG has been incorporated into the JEP and all issues of substance raised during the Last Call have been addressed by the JEP author, the JEP Editor shall formally propose a specific revision of the JEP to the Jabber Council for its vote. If necessary, the JEP Editor may, at his discretion and in consultation with the Jabber Council, extend the Last Call or issue a new Last Call if the JEP requires further discussion.
-Last Calls regarding Procedural JEPs for which the approving body is the JSF Board of Directors may be issued directly by the JEP Editor once instructed by the Board.
+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.
After a JEP has been proposed to the Jabber Council, any change in its status shall be determined by a vote of the Jabber Council. All members of the Council must vote, with the possible values being +1 (approve), 0 (neutral), or -1 (disapprove, with reasons). A JEP shall not be advanced to the next stage in the approval process so long as any Council Member continues to vote -1; that Council Member's written concerns must be addressed in order for the JEP to advance. A majority of Council members must vote +1 in order for a JEP to advance. (Additional voting policies, such as voting periods and defaults if a member does not vote, may be set by the Jabber Council.) A vote of the Jabber Council is final and binding, although a JEP author is free to address the concerns of the Council and to resubmit the JEP for future consideration.
-If the Jabber Council does not complete voting on a JEP before the end of its term, the JEP Editor shall issue a new Last Call on the Standards JIG list and the newly-elected Council shall vote anew on the JEP after completion of the Last Call. This provides an opportunity for any member of the previous Council who had voted -1 to voice his or her concerns in a public forum before the new Council votes on the JEP.
-A vote of the Jabber Council applies only to the specific revision of the JEP that has been presented to it. Further revisions may need to be re-submitted for approval.
-Any change in the status of a JEP must be announced on the Standards-JIG list by the JEP Editor. If a JEP advances to a status of Final, it shall be so announced and also published as one of the official JSF protocols
Approval of Procedural JEPs for which the approving body is the JSF Board of Directors shall occur upon approval by the Board in accordance with the rules defined in the &BYLAWS;.
-More detailed information about the approval process is provided below, including criteria for Standards Track JEPs and for Historical, Informational, and Procedural JEPs.
-The possible states for a Standards Track JEP are as follows:
+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.
+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;.
+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:
+--> Retracted
@@ -234,8 +240,8 @@ Experimental ----> Proposed ----> Draft ----> Final
| |
+-----------+---> Deprecated ---> Obsolete
- The ideal path is for a Standards Track JEP is to be advanced by the Jabber Council from Proposed to Draft to Final (the criteria for this advancement are described in the following paragraphs). However, an Experimental JEP 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 JEP may be voted to a status of Rejected if the Jabber Council deems it unacceptable. (Note that if a JEP is Deferred, the JEP Editor may at some point re-assign it to Experimental status, and that, even if a JEP is Rejected, it is retained in source control and on the Jabber Software Foundation website for future reference.) Finally, a JEP author may voluntarily remove an Experimental JEP from further consideration, resulting in a status of Retracted.
-In order for a Standards Track JEP to advance from Proposed to Draft, it must:
+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.
+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 JEP, indicating a strong sense on the part of the Jabber Council and Jabber/XMPP developer community that the specification will be of lasting value. Since a Draft standard must be well-understood and must be known to be reasonably stable, it is relatively safe to use it as the basis for implementations and production deployments. However, note that because a Draft standard may still require additional field experience and may be subject to change based on such experience, mission-critical or large-scale implementations of the Draft standard may not be advisable (although every effort shall be made to ensure that any changes to a Draft JEP will be backwards-compatible with the 1.0 version). Note also that any changes to a Draft JEP must be provisionally published at <http://www.jabber.org/jeps/tmp/>, announced on the Standards-JIG mailing list, and formally approved by the Jabber Council before being officially published at the canonical URL for the JEP.
-In order for a JEP 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 Jabber Council for consideration as a Final standard, the JEP Editor shall issue a Call for Experience on the Standards-JIG list so that feedback can be gathered from those who have implemented the Draft standard (the Call for Experience shall expire not less than 14 days after the date of issue, and shall not be issued until at least 60 days have passed since advancement to Draft). In addition, at least two implementations of the JEP must exist, at least one of which must be free software (in accordance with the &GPL; or &LGPL;) or open-source software (in accordance with the definition provided by &OSI;). Until two implementations are produced, a Standards Track JEP shall retain a status of Draft. Once (1) two implementations have been presented to the Jabber Council, (2) feedback provided during the Call for Experience has been incorporated into the JEP, and (3) the JEP has been fully checked for accuracy, the status of the JEP may be changed to Final upon a vote of the Council.
-Finally, a Standards Track JEP that has been granted a status of Final may be superseded by a future JEP approved by the Jabber Council. In such cases, the status of the earlier JEP shall be changed to Deprecated, possibly with an expiration date assigned by the Jabber Council (see the Expiration Dates section below). After a reasonable period of time or upon the passing of the expiration date, the status of the JEP shall be changed to Obsolete.
+Elevation to Draft status (version 1.0) is a major advancement for the XEP, indicating a strong sense on the part of the XMPP Council and Jabber/XMPP developer community that the specification will be of lasting value. Since a Draft standard must be well-understood and must be known to be reasonably stable, it is relatively safe to use it as the basis for implementations and production deployments. However, note that because a Draft standard may still require additional field experience and may be subject to change based on such experience, mission-critical or large-scale implementations of the Draft standard may not be advisable (although every effort shall be made to ensure that any changes to a Draft XEP will be backwards-compatible with the 1.0 version). Note also that any changes to a Draft XEP must be provisionally published at <http://www.xmpp.org/extensions/tmp/>, announced on the Standards-JIG mailing list, and formally approved by the XMPP Council before being officially published at the canonical URL for the XEP.
+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.
+Finally, a Standards Track XEP that has been granted a status of Final may be superseded by a future XEP approved by the XMPP Council. In such cases, the status of the earlier XEP shall be changed to Deprecated, possibly with an expiration date assigned by the XMPP Council (see the 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 Historical, Informational, or Procedural JEP are as follows:
+The possible states for a Historical, Informational, or Procedural XEP are as follows:
+--> Retracted
@@ -264,90 +270,90 @@ Experimental ----> Proposed ----> Active
|
+--> Deprecated --> Obsolete
- Because such JEPs do not seek to define standard protocols, in general they are less controversial and tend to proceed from Proposed to Active without controversy on a vote of the Jabber Council. However, some of these JEPs may be remanded from the Council to the JEP author and/or JEP Editor for revision in order to be suitable for advancement from Proposed to Active (e.g., documentation of protocols in use must be accurate and describe any existing security concerns). As with Standards Track JEPs, the JEP author may retract such a JEP when it is Experimental, and the Council may reject such a JEP when it is Proposed.
-Once approved, Historical, Informational, and Procedural JEPs will have a status of Active. Such a JEP may be replaced by a new JEP on the same or a similar topic, thus rendering the earlier JEP out of date; in such cases, the earlier JEP shall be assigned a status of Deprecated (and eventually Obsolete) with a note specifying the superseding JEP.
-The Jabber Council may, at its discretion, decide to convert an Historical JEP into a Standards Track JEP if the protocol defined in the JEP has been in long use, is deemed stable and uncontroversial, and is unlikely to be superseded by a newer protocol. The Historical JEP shall be treated in the same way as a Standards Track JEP that has a status of Experimental, beginning with the Proposal Process. If after the Last Call and voting by the Jabber Council the JEP is approved for advancement on the standards track, its type shall be changed to Standards Track and its status shall be changed to Draft.
+Because such XEPs do not seek to define standard protocols, in general they are less controversial and tend to proceed from Proposed to Active without controversy on a vote of the XMPP Council. However, some of these XEPs may be remanded from the Council to the XEP author and/or XMPP Extensions Editor for revision in order to be suitable for advancement from Proposed to Active (e.g., documentation of protocols in use must be accurate and describe any existing security concerns). As with Standards Track XEPs, the XEP author may retract such a XEP when it is Experimental, and the Council may reject such a XEP when it is Proposed.
+Once approved, Historical, Informational, and Procedural XEPs will have a status of Active. Such a XEP may be replaced by a new XEP on the same or a similar topic, thus rendering the earlier XEP out of date; in such cases, the earlier XEP shall be assigned a status of Deprecated (and eventually Obsolete) with a note specifying the superseding XEP.
+The XMPP Council may, at its discretion, decide to convert an Historical XEP into a Standards Track XEP if the protocol defined in the XEP has been in long use, is deemed stable and uncontroversial, and is unlikely to be superseded by a newer protocol. The Historical XEP shall be treated in the same way as a Standards Track XEP that has a status of Experimental, beginning with the Proposal Process. If after the Last Call and voting by the XMPP Council the XEP is approved for advancement on the standards track, its type shall be changed to Standards Track and its status shall be changed to Draft.
The possible states for a JEP are summarized in the following sections.
+The possible states for a XEP are summarized in the following sections.
A JEP of any type is in the Experimental state after it has been accepted by the Jabber 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 Jabber Software Foundation but before it has advanced within the standards process to a state of Active or Draft.
A JEP of any type is in the Proposed state while it is in Last Call or under consideration by the Jabber Council for advancement from Experimental to Draft or Active.
+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 JEP 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 Jabber Council.
+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 JEP is in the Final state after it has been in the Draft state for at least 60 days, has been implemented in at least two separate codebases, and has been voted forward on the standards track by the Jabber Council.
+A Standards Track XEP is in the Final state after it has been in the Draft state for at least 60 days, has been implemented in at least two separate codebases, and has been voted forward on the standards track by the XMPP Council.
A JEP of any type other than Standards Track is advanced to a status of Active after it has been voted forward from Experimental by the Jabber Council.
+A XEP of any type other than Standards Track is advanced to a status of Active after it has been voted forward from Experimental by the XMPP Council.
An Experimental JEP of any type is changed to the Deferred state if it has not been updated in six (6) months.
+An Experimental XEP of any type is changed to the Deferred state if it has not been updated in six (6) months.
A JEP of any type is in the Retracted state if the authors have asked the JEP Editor to remove the JEP 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 JSF's standards process.
A JEP of any type is in the Rejected state if the Jabber Council has deemed it unacceptable and has voted to not move it forward within the 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.
A JEP of any type is in the Deprecated state if the Jabber Council has determined that the protocol defined therein is out of date and that new implementations are no longer encouraged (e.g., because it has been superseded by a more modern protocol).
+A XEP of any type is in the Deprecated state if the XMPP Council has determined that the protocol defined therein is out of date and that new implementations are no longer encouraged (e.g., because it has been superseded by a more modern protocol).
A JEP of any type is changed from Deprecated to Obsolete if the Jabber Council has determined that the protocol defined therein should no longer be implemented or deployed.
+A XEP of any type is changed from Deprecated to Obsolete if the XMPP Council has determined that the protocol defined therein should no longer be implemented or deployed.
Sometimes it is necessary to modify JEPs that have received final approval by the Jabber Council or JSF Board of Directors (e.g., to correct errors, incorporate the lessons of experience, or document new security concerns). This section describes the process for doing so with regard to Standards Track JEPs that have achieved a status of Final and Historical, Informational, and Procedural JEPs that have achieved a status of Active.
-With regard to Standards Track JEPs, the Jabber Software Foundation (in particular, the Jabber Council) strives to ensure that such JEPs are accurate, complete, and stable before advancing them to a status of Final (corresponding to document version 2.0 of the JEP). The Call for Experience and discussion within the Standards JIG help to ensure this result, but final responsibility rests with the Jabber Council. Despite the best efforts of all concerned, errors are sometimes discovered in Final JEPs (the individual who discovers such an error should inform the Council via the Standards-JIG mailing list or communicate directly with the JEP Editor). Whereas other standards development organizations may issue errata while leaving the specification itself unchanged, the JSF makes changes to the Final JEP and publishes a revised document version (e.g., version 2.1). In general the changes are made by the JEP Editor or JEP author in consultation with the Jabber Council, discussed within the Standards JIG if appropriate, and agreed upon by the full Jabber Council. Upon agreement regarding the exact changes, the Jabber Council shall instruct the JEP Editor to publish a revised version of the JEP and announce the existence of the revised version through the normal channels (e.g., on the JSF website and to the Standards-JIG list). Naturally, if members of the Jabber/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.
-The process is similar with regard to Historical and Informational JEPs that have achieved a status of Active (corresponding to document version 1.0 of the JEP): the Jabber Council agrees on the exact changes to be made and instructs the JEP Editor to publish and announce a revised version (e.g., version 1.1). Here again the Jabber Council bears responsibility for any changes and public discussion is welcome.
-Procedural JEPs may be modified more frequently as the Jabber Software Foundation gains experience with the processes defined therein. For example, JEP-0001 is modified periodically in order to document processes previously not made explicit or to modify existing processes based on experience with the JEP process; similar changes are sometimes made to the &jep0053; JEP and to various JIG-related JEPs. Changes to these JEPs are discussed by the Jabber Council, JSF Board of Directors, JSF membership, and Standards JIG as appropriate, and exact changes are agreed to by the relevant approving body (Jabber Council or JSF Board of Directors). The approving body then instructs the JEP Editor to publish and announce the revised version as described above.
+Sometimes 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.
+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.
In rare cases, a protocol enhancement may be accepted as an interim solution, especially when it is recognized that expected future improvements in technology or the underlying Jabber/XMPP protocols will make possible a much better solution to the problem at hand (e.g., a better protocol for user avatars may be contingent upon the development of a robust protocol for publish/subscribe functionality). In such cases, a JEP may be approved provisionally and be assigned an expiration date.
-The exact form of such an expiration date shall be left up to the discretion of the Jabber Council. However, the preferred form is to assign an expiration date of six (6) months in the future, at which time the Jabber Council must re-affirm the status of the JEP and, if desired, extend the expiration date for another six (6) months. While this process may continue indefinitely (although that is unlikely), it has the virtue of forcing the Jabber Council and Jabber/XMPP developer community to re-examine the provisional protocol on a fairly regular basis in the light of technological changes. Alternatively, a JEP may be assigned a "soft" expiration date: that is, the JEP will expire when an expected future protocol comes into existence, whenever that may be. In either case, the status of the JEP shall be changed to Deprecated when it expires.
-In addition, an expiration date may be assigned when the status of a JEP is changed from Final (or, potentially, Draft) to Deprecated. In this case, the expiration date applies to the date when the JEP is expected to change from Deprecated to Obsolete. These dates may be flexible; however it is expected that they will follow the same six-month rule as provisional protocol enhancements.
+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.
+The exact form of such an expiration date shall be left up to the discretion of the XMPP Council. However, the preferred form is to assign an expiration date of six (6) months in the future, at which time the XMPP Council must re-affirm the status of the XEP and, if desired, extend the expiration date for another six (6) months. While this process may continue indefinitely (although that is unlikely), it has the virtue of forcing the XMPP Council and Jabber/XMPP developer community to re-examine the provisional protocol on a fairly regular basis in the light of technological changes. Alternatively, a XEP may be assigned a "soft" expiration date: that is, the XEP will expire when an expected future protocol comes into existence, whenever that may be. In either case, the status of the XEP shall be changed to Deprecated when it expires.
+In addition, an expiration date may be assigned when the status of a XEP is changed from Final (or, potentially, Draft) to Deprecated. In this case, the expiration date applies to the date when the XEP is expected to change from Deprecated to Obsolete. These dates may be flexible; however it is expected that they will follow the same six-month rule as provisional protocol enhancements.
Every JEP must contain a section entitled "Security Considerations", detailing security concerns or features related to the proposal; in particular, a Standards Track JEP should list the security threats that the protocol addresses and does not address, as well as security issues related to implementation of the protocol. JEP authors should refer to &rfc3552; for helpful information about documenting security considerations and should also confer with the JEP Editor and/or Jabber Council regarding this important task.
+Every XMPP Extension Protocol specification must contain a section entitled "Security Considerations", detailing security concerns or features related to the proposal; in particular, a Standards Track XEP should list the security threats that the protocol addresses and does not address, as well as security issues related to implementation of the protocol. XEP authors should refer to &rfc3552; for helpful information about documenting security considerations and should also confer with the XMPP Extensions Editor and/or XMPP Council regarding this important task.
Some JEPs may require interaction with &IANA;. The IANA acts as a clearinghouse to assign and coordinate the use of numerous Internet protocol parameters, such as MIME types and port numbers (e.g., the TCP ports 5222 and 5269 used by the Jabber/XMPP developer community are registered with the IANA). Whether or not a JEP requires registration of parameters with the IANA, that fact must be noted and explained in a distinct section of the JEP entitled "IANA Considerations". Registration with the IANA should not occur until a JEP advances to a status of Draft (Standards Track JEPs) or Active (Informational and Historical JEPs), and should be initiated by the Jabber Registrar in consultation with the JEP author, not by the JEP author directly with the IANA.
+Some XMPP Extension Protocols may require interaction with &IANA;. The IANA acts as a clearinghouse to assign and coordinate the use of numerous Internet protocol parameters, such as MIME types and port numbers (e.g., the TCP ports 5222 and 5269 used by the Jabber/XMPP developer community are registered with the IANA). Whether or not a XEP requires registration of parameters with the IANA, that fact must be noted and explained in a distinct section of the XEP entitled "IANA Considerations". Registration with the IANA should not occur until a XEP advances to a status of Draft (Standards Track XEPs) or Active (Informational and Historical XEPs), and should be initiated by the XMPP Registrar in consultation with the XEP author, not by the XEP author directly with the IANA.
The ®ISTRAR; performs a function similar to the IANA, although limited to the Jabber/XMPP developer community. It does so by reserving protocol namespaces and by uniquely assigning parameters for use in the context of Jabber/XMPP protocols (for example, the categories and types used in &jep0030;).
-Whether or not a JEP requires registration of protocol namespaces or parameters with the Jabber Registrar, that fact must be noted and explained in a distinct section of the JEP entitled "Jabber Registrar Considerations". Such registration should not occur until a JEP advances to a status of Draft (Standards Track JEPs) or Active (Informational and Historical JEPs). Registration of protocol namespaces is initiated by the JEP Editor when a JEP advances to Draft or Active. Registration of particular parameters used within a specification may be initiated by a JEP author within the text of the JEP, or by an implementor of the JEP after it has advanced to Draft or Active. For details regarding the Jabber Registrar and its processes, refer to &jep0053;.
-A JEP may also request that a new registry is to be created by the Jabber Registrar. The JEP 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.
+The ®ISTRAR; performs a function similar to the IANA, although limited to the Jabber/XMPP developer community. It does so by reserving protocol namespaces and by uniquely assigning parameters for use in the context of Jabber/XMPP protocols (for example, the categories and types used in &xep0030;).
+Whether or not a XEP requires registration of protocol namespaces or parameters with the XMPP Registrar, that fact must be noted and explained in a distinct section of the XEP entitled "XMPP Registrar Considerations". Such registration should not occur until a XEP advances to a status of Draft (Standards Track XEPs) or Active (Informational and Historical XEPs). Registration of protocol namespaces is initiated by the XMPP Extensions Editor when a XEP advances to Draft or Active. Registration of particular parameters used within a specification may be initiated by a XEP author within the text of the XEP, or by an implementor of the XEP after it has advanced to Draft or Active. For details regarding the XMPP Registrar and its processes, refer to &xep0053;.
+A XEP may also request that a new registry is to be created by the XMPP Registrar. The XEP author must clearly define the nature of the new registry as well as the process for submitting data to the registry, and must do so in collaboration with the Registrar.
JEPs that define official JSF protocols must include a schema that conforms to &w3xmlschema1; and &w3xmlschema2;.
-The schema for the JEP format itself is as follows:
+XMPP Extension Protocol specifications that define official JSF protocols must include a schema that conforms to &w3xmlschema1; and &w3xmlschema2;.
+The schema for the XEP format itself is as follows:
- This schema defines the document format for Jabber Enhancement
- Proposals (JEPs). For further information about JEPs, visit:
+ This schema defines the document format for XMPP Extension
+ Protocols (XEPs). For further information about XEPs, visit:
- http://www.jabber.org/jeps/
+ http://www.xmpp.org/extensions/
The canonical URL for this schema is:
- http://www.jabber.org/jeps/jep.xsd
+ http://www.xmpp.org/extensions/xep.xsd
@@ -394,7 +400,7 @@ Experimental ----> Proposed ----> Active
]]>
A Jabber Interest Group (JIG) is a working group approved by the Jabber Council to address specific areas of growth or concern within the Jabber community, usually by means of developing and publishing Jabber Enhancements Proposals (JEPs).
+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).
The main function of most JIGs is to produce acceptable enhancements to the Jabber protocol (delivered in the form of Jabber Enhancement Proposals or JEPs
Anyone (not limited to members of the Jabber Software Foundation) may propose the formation of a JIG by completing a Jabber Enhancement Proposal 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 Jabber 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 JEPs for review by the Jabber 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 Jabber 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 JIGs is to produce acceptable XMPP extensions (delivered in the form of XMPP Extension Protocols or XEPs
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 JEPs 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).
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
No action on the part of the ®ISTRAR; is necessary as a result of this JEP, since 'jabber:iq:pass' is already a registered protocol namespace.
+No action on the part of the ®ISTRAR; is necessary as a result of this document, since 'jabber:iq:pass' is already a registered protocol namespace.
The protocol documented by this schema is defined in
- JEP-0003: http://www.jabber.org/jeps/jep-0003.html
+ XEP-0003: http://www.xmpp.org/extensions/xep-0003.html
@@ -344,4 +344,4 @@
]]>
Several existing Jabber/XMPP protocols involve the exchange of structured data between users and applications for common tasks such as registration (&jep0077;) and searching (&jep0055;). Unfortunately, these early protocols were "hard coded" and thus place significant restrictions on the range of information that can be exchanged. Furthermore, other protocols (e.g., &jep0045;) may need to exchange data for purposes such as configuration, but the configuration options may differ depending on the specific implementation or deployment. Finally, developers may want to extend other protocols (e.g., &jep0030;) in a flexible manner in order to provide information that is not defined in the base protocol. In all of these cases, it would be helpful to use a generic data description format that can be used for dynamic forms generation and data "modelling" in a variety of circumstances.
+Several existing Jabber/XMPP protocols involve the exchange of structured data between users and applications for common tasks such as registration (&xep0077;) and searching (&xep0055;). Unfortunately, these early protocols were "hard coded" and thus place significant restrictions on the range of information that can be exchanged. Furthermore, other protocols (e.g., &xep0045;) may need to exchange data for purposes such as configuration, but the configuration options may differ depending on the specific implementation or deployment. Finally, developers may want to extend other protocols (e.g., &xep0030;) in a flexible manner in order to provide information that is not defined in the base protocol. In all of these cases, it would be helpful to use a generic data description format that can be used for dynamic forms generation and data "modelling" in a variety of circumstances.
An example may be helpful. Let us imagine that when a user creates a multi-user chatroom on a text conferencing service, the service allows the user to configure the room in various ways. While most implementations will probably provide a somewhat common set of configurable features (discussion logging, maximum number of room occupants, etc.), there will be some divergence: perhaps one implementation will enable archiving of the room log in a variety of file types (XML, HTML, PDF, etc.) and for a variety of time periods (hourly, daily, weekly, etc.), whereas another implementation may present a boolean on/off choice of logging in only one format (e.g., daily logs saved in HTML). Obviously, the first implementation will have more configuration options than the second implementation. Rather than "hard-coding" every option via distinct XML elements (e.g., <room_logging_period/>), a better design would involve a more flexible format.
The 'jabber:x:data' protocol described herein defines such a flexible format for use by Jabber/XMPP entities, steering a middle course between the simplicity of "name-value" pairs and the complexity of &w3xforms; (on which development had just begun when this protocol was designed). In many ways, 'jabber:x:data' is similar to the Forms Module of &w3xhtml;; however, it provides several Jabber-specific data types, enables applications to require data fields, integrates more naturally into the "workflow" semantics of IQ stanzas, and can be included as an extension of existing Jabber/XMPP protocols in ways that the XHTML Forms Module could not when this protocol was developed (especially because &w3xhtmlmod; did not exist at that time).
This JEP addresses the following requirements:
+This document addresses the following requirements:
For &IQ; stanzas, the root element qualified by the "wrapper" namespace in a form of type "form" or "submit" MUST be returned in a form of type "result". The &X; element qualified by the 'jabber:x:data' namespace MUST be a child of the "wrapper" namespace's root element. As defined in &xmppcore;, the 'id' attribute MUST be copied in the IQ result. For data forms of type "form" or "result", the &IQ; stanza SHOULD be of type "result". For data forms of type "submit" or "cancel", the &IQ; stanza SHOULD be of type "set".
For &MESSAGE; stanzas, the <thread/> SHOULD be copied in the reply if provided. The &X; element qualified by the 'jabber:x:data' namespace MUST be a child of the &MESSAGE; stanza.
The only data form type allowed for <presence/> stanzas is "result". The &X; element qualified by the 'jabber:x:data' namespace MUST be a child of the &PRESENCE; stanza. In accordance with XMPP Core, use of data forms is not recommended unless necessary to provide information that is directly related to an entity's network availability.
The only data form type allowed for <presence/> stanzas is "result". The &X; element qualified by the 'jabber:x:data' namespace MUST be a child of the &PRESENCE; stanza. In accordance with XMPP Core, use of data forms is not recommended unless necessary to provide information that is directly related to an entity's network availability.
* Note: Data provided for fields of type "jid-single" or "jid-multi" MUST contain one or more valid Jabber IDs, where validity is determined by the addressing rules defined in XMPP Core (see the Data Validation section below).
+* Note: Data provided for fields of type "jid-single" or "jid-multi" MUST contain one or more valid Jabber IDs, where validity is determined by the addressing rules defined in XMPP Core (see the Data Validation section below).
** Note: Data provided for fields of type "text-multi" SHOULD NOT contain any newlines (the \n and \r characters). Instead, the application SHOULD split the data into multiple strings (based on the newlines inserted by the platform), then specify each string as the XML character data of a distinct <value/> element. Similarly, an application that receives multiple <value/> elements for a field of type "text-multi" SHOULD merge the XML character data of the value elements into one text block for presentation to a user, with each string separated by a newline character as appropriate for that platform.
Data validation is the responsibility of the form-processing entity (commonly a server, service, or bot) rather than the form-submitting entity (commonly a client controlled by a human user). This helps to meet the requirement for keeping client implementations simple. If the form-processing entity determines that the data provided is not valid, it SHOULD return a "Not Acceptable" error, optionally providing a textual explanation in the XMPP <text/> element or an application-specific child element that identifies the problem (see &jep0086; for information about mappings and formats).
+Data validation is the responsibility of the form-processing entity (commonly a server, service, or bot) rather than the form-submitting entity (commonly a client controlled by a human user). This helps to meet the requirement for keeping client implementations simple. If the form-processing entity determines that the data provided is not valid, it SHOULD return a "Not Acceptable" error, optionally providing a textual explanation in the XMPP <text/> element or an application-specific child element that identifies the problem (see &xep0086; for information about mappings and formats).
For the sake of the following examples, let us suppose that there exists a bot hosting service on the Jabber network, located at <botster.shakespeare.lit>. This service enables registered users to create and configure new bots, find and interact with existing bots, and so on. We will assume that these interactions occur using the &jep0050; protocol, which is used as a "wrapper" protocol for data forms qualified by the 'jabber:x:data' namespace. The examples in the sections that follow show most of the features of the data forms protocol described above.
-Note: Additional examples can be found in the specifications for various using protocols, such as JEP-0045: Multi-User Chat and JEP-0055: Jabber Search.
+For the sake of the following examples, let us suppose that there exists a bot hosting service on the Jabber network, located at <botster.shakespeare.lit>. This service enables registered users to create and configure new bots, find and interact with existing bots, and so on. We will assume that these interactions occur using the &xep0050; protocol, which is used as a "wrapper" protocol for data forms qualified by the 'jabber:x:data' namespace. The examples in the sections that follow show most of the features of the data forms protocol described above.
+Note: Additional examples can be found in the specifications for various using protocols, such as XEP-0045: Multi-User Chat and XEP-0055: Jabber Search.
The first step is for a user to create a new bot on the hosting service. We will assume that this is done by sending a "create" command to the desired bot:
There are no security concerns related to this specification above and beyond those described in the relevant section of XMPP Core.
+There are no security concerns related to this specification above and beyond those described in the relevant section of XMPP Core.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; includes the 'jabber:x:data' namespace in its registry of protocol namespaces.
The Jabber Registrar maintains a registry of parameter values related to the 'jabber:x:data' namespace, specifically as defined in &jep0068;; 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 <http://www.jabber.org/registrar/formtypes.html>.
Describe in detail how presence management currently works, and work on proposals for things like invisibility.
-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 JEP 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.
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.
Peter Millard, a co-author of this specification from version 0.1 through version 0.3, died on April 26, 2006.
-&xmlrpc; is a method of encoding RPC requests and responses in XML. The original specification defines HTTP (see &rfc2068;) as the only valid transport for XML-RPC payloads.
Various initiatives exist already to transport XML-RPC payloads over Jabber. These initiatives were independent of each other and used slightly differing methods (e.g. carrying the payload in a
A working session during JabberCon 2001 resulted in a formalisation of a single method. This JEP describes that method, which is labelled as Jabber-RPC to differentiate it from XML-RPC itself.
+A working session during JabberCon 2001 resulted in a formalisation of a single method. This document describes that method, which is labelled as Jabber-RPC to differentiate it from XML-RPC itself.
The &IQ; stanza is used to transport XML-RPC payloads. XML-RPC requests are transported using an &IQ; stanza of type "set", and XML-RPC responses are transported using an &IQ; stanza of type "result". An &IQ; stanza MUST NOT contain more than one request or response.
@@ -122,7 +122,7 @@ ]]>If an entity supports the Jabber-RPC protocol, it SHOULD advertise that fact in response to &jep0030; information ("diso#info") requests by returning an identity of "automation/rpc" and a feature of "jabber:iq:rpc":
+If an entity supports the Jabber-RPC protocol, it SHOULD advertise that fact in response to &xep0030; information ("diso#info") requests by returning an identity of "automation/rpc" and a feature of "jabber:iq:rpc":
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; includes 'jabber:iq:rpc' in its registry of protocol namespaces.
The Jabber Registrar includes a Service Discovery type of "rpc" within the "automation" category in its registry of service discovery identities.
+The XMPP Registrar includes a Service Discovery type of "rpc" within the "automation" category in its registry of service discovery identities.
The actual protocol for how the graphics data is sent over Jabber. This will also include an analysis of any associated functionality that must be performed by Jabber servers and clients.
-The Jabber world is a diverse place, with lots of services, transports, software agents, users, groupchat rooms, translators, headline tickers, and just about anything that might interact on a real-time basis using conversational messages or presence. Every JabberID (JID) is a node that can be interacted with via messages, presence, and special purpose IQ namespaces. Some JIDs are parents (such as transports), and often many JIDs have relationships with other JIDs (such as a user to their resources, a server to its services, etc.). We need a better way to structure and manage this culture of multi-namespace JID stew. The answer: Jabber Browsing.
-Note well that implementors are encouraged to implement &jep0030; instead of Jabber Browsing.
+Note well that implementors are encouraged to implement &xep0030; instead of Jabber Browsing.
One of the concepts in browsing which helps to extend the interaction between JIDs is a "JID-Type", a simple heirarchy for identifying the role of any JabberID that is similar to the mime-type format. Many programmers are comfortable with the concept of identifying file types by mime-types, which use the format "category/type". A JID-Type, once discovered, is to be used in the same way that a mime-type would be for a file, to alter the user interface representing that JID or provide alternative functionality for interacting with it (either automatically or driven by user interaction). The following categories and types are proposed as the canonical list for the purpose of JID-Types:
@@ -427,7 +424,7 @@This JEP requires no interaction with &IANA;.
No action on the part of the ®ISTRAR; is necessary as a result of this JEP, since 'jabber:iq:browse' is already a registered protocol namespace.
The 'jabber:iq:browse' namespace has been in use for quite some time. However, live browsing still needs to be better defined by a generic publication/subscription system. It is assumed that when such a system is defined, updates to this JEP will be made. It is, however, possible that no futher changes to jabber:iq:browse itself may be needed.
It is often helpful to know the time of the last activity associated with a Jabber Entity. The canonical usage is to discover when a disconnected user last accessed the server (a closely related usage is to discover when a connected user was last active on the server, i.e., the user's idle time). The 'jabber:iq:last' namespace provides a method for retrieving this kind of information. In historical usage, the 'jabber:iq:last' namespace has also been used to query Jabber servers and components about their current uptime; however, this is an extension to the core usage of the 'jabber:iq:last' namespace and may require the addition of a separate namespace in the future.
-Although the 'jabber:iq:last' namespace has been in use since January 2001, it is still not considered one of the standard Jabber protocols. While the &jabberd; server, many components, and some clients already implement this namespace, it is often overlooked by new developers because of the lack of standardization. This informational JEP defines the protocol as it is used today in order to more fully document it for historical purposes.
+Although the 'jabber:iq:last' namespace has been in use since January 2001, it is still not considered one of the standard Jabber protocols. While the &jabberd; server, many components, and some clients already implement this namespace, it is often overlooked by new developers because of the lack of standardization. This informational document defines the protocol as it is used today in order to more fully document it for historical purposes.
The 'jabber:iq:last' namespace is used as the value of the 'xmlns' attribute of a <query> element contained within an <iq/> element. When requesting last activity information, a Jabber Entity sends an <iq> element of type='get' to another Jabber Entity (i.e., a JID). When responding to such a request, a Jabber Entity sends an <iq> element of type='result'. The <query> element never has any children and contains only one attribute and CDATA, depending on the scenario in which it is used.
@@ -80,7 +80,7 @@ ]]>In this example, the user logged out fifteen minutes and three seconds ago, and when they logged out they sent a presence packet of type='unavailable' whose <status/> element contained the text "Heading home".
If the user has at least one available resource when the server receives the request, the response SHOULD contain an empty <query/> element whose 'seconds' attribute is set to a value of '0'.
-Note well that, as specified in &xmppcore; and &xmppim;, an IQ query sent to a JID of the form user@host is handled by a server on the user's behalf, not forwarded to one or more active resources. In addition, a server MUST NOT return last activity information to an entity that is not authorized to view the user's presence information (normally via presence subscription), and MUST return a "Forbidden" error in response to such a request (for information about error conditions, refer to &jep0086;).
+Note well that, as specified in &xmppcore; and &xmppim;, an IQ query sent to a JID of the form user@host is handled by a server on the user's behalf, not forwarded to one or more active resources. In addition, a server MUST NOT return last activity information to an entity that is not authorized to view the user's presence information (normally via presence subscription), and MUST return a "Forbidden" error in response to such a request (for information about error conditions, refer to &xep0086;).
When the IQ get in the 'jabber:iq:last' namespace is sent to a specific resource of an online user (i.e., a JID of the form of 'user@host/resource'), the JID sending the reply MAY respond with the idle time of the user. This is not a required protocol for clients to support, so clients sending such requests MUST NOT depend on receiving a meaningful result from the target user (although a client that does not support the protocol, or that does not wish to divulge this information, SHOULD return a "Service Unavailable" error). The standard does not specify what resolution the clients must use for the idle times, so the result SHOULD NOT be used as a precise measurement. Here is an example:
@@ -110,13 +110,13 @@In this example, the server has been up for a little more than 34 hours.
A server MUST NOT allow an unauthorized entity to learn a user's network availability by sending a Last Activity request to a JID of the form user@host or user@host/resource; Last Activity information MAY be divulged only to those entities that have permission to view the user's presence (normally via presence subscription), potentially as restricted by privacy rules (as defined in XMPP IM and further profiled in &jep0126;).
+A server MUST NOT allow an unauthorized entity to learn a user's network availability by sending a Last Activity request to a JID of the form user@host or user@host/resource; Last Activity information MAY be divulged only to those entities that have permission to view the user's presence (normally via presence subscription), potentially as restricted by privacy rules (as defined in XMPP IM and further profiled in &xep0126;).
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
No action on the part of the ®ISTRAR; is necessary as a result of this JEP, since 'jabber:iq:last' is already a registered protocol namespace.
+No action on the part of the ®ISTRAR; is necessary as a result of this document, since 'jabber:iq:last' is already a registered protocol namespace.
The protocol documented by this schema is defined in
- JEP-0012: http://www.jabber.org/jeps/jep-0012.html
+ XEP-0012: http://www.xmpp.org/extensions/xep-0012.html
@@ -154,6 +154,6 @@
The 'jabber:iq:last' namespace has been used intensively (in the jabberd server, components such as most transports, and some Jabber clients), and no major faults have been found in the current implementations. However, as noted, it has not necessarily been used widely, and many Jabber clients lack support for this namespace. For this reason it is probably best to consider it a non-core namespace.
The current specification assumes that the 'resource' portion of a JID is equivalent to a device or connection (laptop, PDA, etc.). While in that context it makes sense to interpret the information returned by an IQ reply in the 'jabber:iq:last' namespace as client idle time, such an assumption will make less sense in a future world where a resource may be not a device or connection but truly a more generic resource such as a calendar or weblog. The current interpretation of 'jabber:iq:last' for 'user@host/resource' as idle time may not be appropriate for the more diverse Jabber resources of the future.
- The most significant point of contention regarding the 'jabber:iq:last' namespace is the perceived ambiguity of the information contained in an IQ reply for this namespace. Specifically, for a 'user@host' the information is the time since the JID was last connected to the host, for a 'user@host/resource' the information is the time since the resource was last active (i.e., in most circumstances the client idle time), and for a 'host' the information is the uptime for the server or component. Because of this ambiguity (real or perceived), there is some sentiment in the Jabber community that it would be better to create a separate 'jabber:iq:uptime' namespace (and perhaps even a 'jabber:iq:idletime' namespace), leaving the 'jabber:iq:last' namespace for last disconnection time only. These potential namespaces may be proposed in one or more future JEPs if needed.
+ The most significant point of contention regarding the 'jabber:iq:last' namespace is the perceived ambiguity of the information contained in an IQ reply for this namespace. Specifically, for a 'user@host' the information is the time since the JID was last connected to the host, for a 'user@host/resource' the information is the time since the resource was last active (i.e., in most circumstances the client idle time), and for a 'host' the information is the uptime for the server or component. Because of this ambiguity (real or perceived), there is some sentiment in the Jabber community that it would be better to create a separate 'jabber:iq:uptime' namespace (and perhaps even a 'jabber:iq:idletime' namespace), leaving the 'jabber:iq:last' namespace for last disconnection time only. These potential namespaces may be proposed in one or more future specifications if needed.
-In order to discover whether one's server supports this protocol, one uses &jep0030;.
+In order to discover whether one's server supports this protocol, one uses &xep0030;.
If the server supports retrieval of the number of messages, it MUST include &jep0128; data specifying the number of messages:
+If the server supports retrieval of the number of messages, it MUST include &xep0128; data specifying the number of messages:
Upon receiving a service discovery request addressed to a node of "http://jabber.org/protocol/offline" (either a disco#info request as in this use case or a disco#items request as in the next use case), the server MUST NOT send a flood of offline messages if the user subsequently sends initial presence to the server during this session. Thus the user is now free to send initial presence (if desired) and to engage in normal IM activities while continuing to read through offline messages. However, once the user sends presence, the user's server MUST deliver in-session messages as usual; this JEP applies to offline messages only. In addition, if the user authenticates and provides presence for another resource while the first (non-flood) resource still has an active session, the server MUST NOT flood the second resource with the offline message queue.
+Upon receiving a service discovery request addressed to a node of "http://jabber.org/protocol/offline" (either a disco#info request as in this use case or a disco#items request as in the next use case), the server MUST NOT send a flood of offline messages if the user subsequently sends initial presence to the server during this session. Thus the user is now free to send initial presence (if desired) and to engage in normal IM activities while continuing to read through offline messages. However, once the user sends presence, the user's server MUST deliver in-session messages as usual; this document applies to offline messages only. In addition, if the user authenticates and provides presence for another resource while the first (non-flood) resource still has an active session, the server MUST NOT flood the second resource with the offline message queue.
In order to retrieve headers for all of the messages in the queue, the user sends a disco#items request without a 'to' address (i.e., implicitly to the user himself) and with the disco node specified as 'http://jabber.org/protocol/offline'.
@@ -205,12 +205,12 @@ ]]> -If the requester is a JID other than an authorized resource of the user (i.e., the user@host of the requester does not match the user@host of the user), the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return an ¬found; error. If there are no offline messages for this user, the server MUST return an empty query as defined in JEP-0030. (For information about the syntax of error conditions, refer to &jep0086;.)
+If the requester is a JID other than an authorized resource of the user (i.e., the user@host of the requester does not match the user@host of the user), the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return an ¬found; error. If there are no offline messages for this user, the server MUST return an empty query as defined in XEP-0030. (For information about the syntax of error conditions, refer to &xep0086;.)
The syntax and semantics of the attributes are as follows:
In order to distinguish incoming messages, each message MUST contain the node value. It is RECOMMENDED for the server to include &jep0091; information in the message.
+In order to distinguish incoming messages, each message MUST contain the node value. It is RECOMMENDED for the server to include &xep0091; information in the message.
A server MUST NOT remove a message simply because it has been requested by and delivered to the user; instead, the user must specifically request to remove a message. This further implies that the user's offline message queue SHOULD NOT be automatically cleared out by the server if there are offline messages remaining when the user's session ends. However, an implementation or deployment MAY remove messages according to its own algorithms (e.g., storage timeouts based on a "first in first out" rule) or policies (e.g., message queue size limits) if desired.
@@ -340,14 +340,14 @@ C: request and remove offline messages, send and receive messages, etc.A server MUST NOT deliver a user's offline messages to any JID except one of the user's authorized resources.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; includes 'http://jabber.org/protocol/offline' in its registry of protocol namespaces.
The Jabber Registrar includes "automation" in its registry of Service Discovery categories for use for any entities and nodes that provide automated or programmed interaction. This JEP specifies the following new types for the "automation" category:
+The XMPP Registrar includes "automation" in its registry of Service Discovery categories for use for any entities and nodes that provide automated or programmed interaction. This document specifies the following new types for the "automation" category:
| Type | @@ -370,25 +370,25 @@ C: request and remove offline messages, send and receive messages, etc. The node for the offline message queue; valid only for the node "http://jabber.org/protocol/offline" -
|---|