moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-23 08:08:53 -05:00
Code Issues Releases Wiki Activity

JEP to XEP

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@27 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-10-03 22:26:53 +00:00
parent ba3ae901fb
commit 86f6eb0758
29 changed files with 1238 additions and 589 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

198
xep-0001.xml
View File

@ -1,12 +1,12 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jabber Enhancement Proposals (JEPs)</title>
<title>XMPP Extension Protocols</title>
<abstract>This document defines the standards process followed by the Jabber Software Foundation.</abstract>
&LEGALNOTICE;
<number>0001</number>
@ -19,6 +19,12 @@
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.17</version>
<date>2006-10-04</date>
<initials>psa</initials>
<remark><p>As approved by the members of the Jabber Software Foundation, changed Jabber Enhancement Proposal to XMPP Extension Protocol.</p></remark>
</revision>
<revision>
<version>1.16</version>
<date>2006-06-23</date>
@ -71,7 +77,7 @@
<version>1.7</version>
<date>2003-04-11</date>
<initials>psa</initials>
<remark><p>Added status of Retracted; corrected several errors related to the Jabber Registrar.</p></remark>
<remark><p>Added status of Retracted; corrected several errors related to the XMPP Registrar.</p></remark>
</revision>
<revision>
<version>1.6</version>
@ -83,7 +89,7 @@
<version>1.5</version>
<date>2002-10-29</date>
<initials>psa</initials>
<remark><p>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.</p></remark>
<remark><p>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.</p></remark>
</revision>
<revision>
<version>1.4</version>
@ -129,98 +135,98 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>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, <note>Effectively the only such exceptions are protocols that were superseded by <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</note> such protocols can be considered extensions to the Extensible Messaging and Presence Protocol (XMPP) approved by the &IETF; in &xmppcore; and &xmppim;. Advancement through the JSF's standards process is subject to open discussion on public discussion lists and approval by a technical steering committee elected by the members of the JSF. The focal point of the process is a series of protocol specifications called Jabber Enhancement Proposals or JEPs. <note>The JEP concept as exemplified in version 1.0 of this document (approved in July of 2001) was borrowed from the Python community (see <link url="http://python.sourceforge.net/peps/pep-0001.html">PEP-1</link>). Subsequent revisions have been based on the Jabber/XMPP developer community's experience with the JEP process, as well as insights gleaned from the standards processes followed by the IETF (&rfc2026;), the &W3C; (&w3process;), and other standards development organizations.</note> The nature of JEPs and the mechanisms for managing and advancing them within the Jabber Software Foundation's standards process are canonically described in the current document, which represents the first document in the JEP series.</p>
<p>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, <note>Effectively the only such exceptions are protocols that were superseded by <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</note> such protocols can be considered extensions to the Extensible Messaging and Presence Protocol (XMPP) approved by the &IETF; in &xmppcore; and &xmppim;. Advancement through the JSF's standards process is subject to open discussion on public discussion lists and approval by a technical steering committee elected by the members of the JSF. The focal point of the process is a series of protocol specifications called XMPP Extension Protocols or XEPs. <note>The JEP (now XEP) concept as exemplified in version 1.0 of this document (approved in July of 2001) was borrowed from the Python community (see <link url="http://python.sourceforge.net/peps/pep-0001.html">PEP-1</link>). Subsequent revisions have been based on the Jabber/XMPP developer community's experience with this standards process, as well as insights gleaned from the standards processes followed by the IETF (&rfc2026;), the &W3C; (&w3process;), and other standards development organizations.</note> The nature of XMPP Extension Protocols and the mechanisms for managing and advancing them within the Jabber Software Foundation's standards process are canonically described in the current document, which represents the first document in the XEP series. <note>The term "XEP" is normally pronounced "zepp".</note></p>
</section1>
<section1 topic='Objectives' anchor='objectives'>
<p>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:</p>
<ol start='1'>
<li>To produce practical, technically excellent solutions to important problems of real-time communication based on the set of streaming XML technologies known as Jabber/XMPP.</li>
<li>To document Jabber protocols and XMPP extensions in a clear, concise manner so that the task of implementing the protocols is straightforward.</li>
<li>To document XMPP extensions in a clear, concise manner so that the task of implementing the protocols is straightforward.</li>
<li>To ensure interoperability among the disparate technologies used on Jabber/XMPP networks.</li>
<li>To guarantee that any person or entity may implement the protocols without encumbrance.</li>
<li>To work in an fair, open, objective manner.</li>
</ol>
<p>The standards process specified herein has been developed and refined in order to meet these objectives.</p>
</section1>
<section1 topic='JEP Types' anchor='types'>
<p>The five JEP types are described in the following sections.</p>
<p>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.</p>
<p>This document focuses primarily on Standards Track JEPs since they are the vehicle for defining new protocols, but also discusses the other JEP types.</p>
<section1 topic='XEP Types' anchor='types'>
<p>The five XEP types are described in the following sections.</p>
<p>The approving body for all Standards Track, Informational, Historical, and Humorous XEPs is the &COUNCIL;; the approving body for Procedural XEPs may be either the &BOARD; or the XMPP Council.</p>
<p>This document focuses primarily on Standards Track XEPs since they are the vehicle for defining new protocols, but also discusses the other XEP types.</p>
<section2 topic='Standards Track' anchor='types-Standards-Track'>
<p>A <span class='ref'>Standards Track JEP</span> defines one of the following:</p>
<p>A <span class='ref'>Standards Track XEP</span> defines one of the following:</p>
<ol>
<li>A wire protocol intended to be used as a standard part of Jabber/XMPP technologies.
<note>Note well that a protocol defined in a Standards Track JEP is not considered a full standard of the Jabber Software Foundation until it achieves a status of Final within the standards process defined herein (a Standards Track JEP that has achieved a status of Draft may be referred to as a Draft Standard; a Standards Track JEP that has a status of Experimental must not be referred to as a standard, but instead should be referred to as a work in progress).</note>
<note>Note well that a protocol defined in a Standards Track XEP is not considered a full standard of the Jabber Software Foundation until it achieves a status of Final within the standards process defined herein (a Standards Track XEP that has achieved a status of Draft may be referred to as a Draft Standard; a Standards Track XEP that has a status of Experimental must not be referred to as a standard, but instead should be referred to as a work in progress).</note>
</li>
<li>A protocol suite that determines conformance requirements (e.g., &jep0073;).</li>
<li>A protocol suite that determines conformance requirements (e.g., &xep0073;).</li>
</ol>
</section2>
<section2 topic='Informational' anchor='types-Informational'>
<p>An <span class='ref'>Informational JEP</span> defines one of the following:</p>
<p>An <span class='ref'>Informational XEP</span> defines one of the following:</p>
<ol start='1'>
<li>Best practices for protocol development (e.g., &jep0128;).</li>
<li>A usage profile for an existing protocol (e.g., &jep0126;).</li>
<li>Best practices for protocol development (e.g., &xep0128;).</li>
<li>A usage profile for an existing protocol (e.g., &xep0126;).</li>
</ol>
</section2>
<section2 topic='Historical' anchor='types-Historical'>
<p>An <span class='ref'>Historical JEP</span> 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.</p>
<p>An <span class='ref'>Historical XEP</span> 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.</p>
</section2>
<section2 topic='Humorous' anchor='types-Humorous'>
<p>A <span class='ref'>Humorous JEP</span> 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.</p>
<p>A <span class='ref'>Humorous XEP</span> 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.</p>
</section2>
<section2 topic='Procedural' anchor='types-Procedural'>
<p>A <span class='ref'>Procedural JEP</span> defines a process or activity to be followed by the JSF, including JIG charters as specified by &jep0002;.</p>
<p>A <span class='ref'>Procedural XEP</span> defines a process or activity to be followed by the JSF, including JIG charters as specified by &xep0002;.</p>
</section2>
</section1>
<section1 topic='Submission Process' anchor='submission'>
<p>The JSF welcomes and encourages the submission of protocols to the JSF's standards process. <note>It is important to understand that private extensions to XMPP are also allowed. The JSF does not, and cannot, require such private extensions to be added to the public, official set of protocols recognized by the JSF. The processes and procedures in this document apply only to protocols that are submitted to the JSF, not to private protocol extensions used for custom functionality in particular applications. However, such private extensions must not be considered part of the protocols recognized by the JSF.</note> Any individual or group of individuals may author a proposal and submit it to the JSF for consideration as a JEP, and there is no requirement that a JEP author shall be an elected member of the JSF. However, proposals to define official JSF protocols must be presented in the JEP format and must follow the rules defined herein. The JEP authoring and submission process is defined in &jep0143; (see also &lt;<link url="http://www.jabber.org/jeps/submit.shtml">http://www.jabber.org/jeps/submit.shtml</link>&gt;). All inquiries related to the JEP process, and all submissions, should be directed to the &EDITOR;.</p>
<p>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!</p>
<p>All proposals submitted to the JSF for consideration as JEPs must contain the following information:</p>
<p>The JSF welcomes and encourages the submission of protocols to the JSF's standards process. <note>It is important to understand that private extensions to XMPP are also allowed. The JSF does not, and cannot, require such private extensions to be added to the public, official set of protocols recognized by the JSF. The processes and procedures in this document apply only to protocols that are submitted to the JSF, not to private protocol extensions used for custom functionality in particular applications. However, such private extensions must not be considered part of the protocols recognized by the JSF.</note> Any individual or group of individuals may author a proposal and submit it to the JSF for consideration as a XEP, and there is no requirement that a XEP author shall be an elected member of the JSF. However, proposals to define official JSF protocols must be presented in the XEP format and must follow the rules defined herein. The authoring and submission process is defined in &xep0143; (see also &lt;<link url="http://www.xmpp.org/extensions/submit.shtml">http://www.xmpp.org/extensions/submit.shtml</link>&gt;). All inquiries related to the JSF's standards process, and all submissions, should be directed to the &EDITOR;.</p>
<p>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!</p>
<p>All proposals submitted to the JSF for consideration as XEPs must contain the following information:</p>
<ol start='1'>
<li><p>Legal Notice -- the legal notice must be exactly that which is specified in the JSF IPR Policy</p></li>
<li><p>Author Information -- first name, last name, email address, and Jabber ID are all required and must be provided for all authors</p></li>
</ol>
<p>Finally, Standards Track, Informational, and Historical JEPs must conform to &rfc2119; in the use of terminology regarding requirements levels.</p>
<p>Finally, Standards Track, Informational, and Historical XEPs must conform to &rfc2119; in the use of terminology regarding requirements levels.</p>
</section1>
<section1 topic='Publication Process' anchor='publication'>
<p>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:</p>
<p>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:</p>
<ul>
<li>ensure that its format is correct</li>
<li>publish it to &lt;<link url='http://www.jabber.org/jeps/inbox/'>http://www.jabber.org/jeps/inbox/</link>&gt;</li>
<li>publish it to &lt;<link url='http://www.xmpp.org/extensions/inbox/'>http://www.xmpp.org/extensions/inbox/</link>&gt;</li>
<li>publicly announce its existence by sending a message to the discussion list of the &SJIG;</li>
<li>request acceptance of the proposal as a JEP by the Jabber Council</li>
<li>request acceptance of the proposal as a XEP by the XMPP Council</li>
</ul>
<p>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.</p>
<p>If the proposal is accepted as a JEP, the JEP Editor shall do the following:</p>
<p>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.</p>
<p>If the proposal is accepted as a XEP, the XMPP Extensions Editor shall do the following:</p>
<ul>
<li>assign it a number</li>
<li>specify an appropriate type</li>
<li>specify a status of Experimental</li>
<li>add it to source control <note>JEPs are kept under source control in the 'jeps' module of the CVS repository maintained at the jabberstudio.org service. Instructions for accessing these files can be found at &lt;<link url='http://www.jabberstudio.org/cvs.php'>http://www.jabberstudio.org/cvs.php</link>&gt;, and a web interface to these files is available at &lt;<link url='http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/jeps/'>http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/jeps/</link>&gt;.</note></li>
<li>add tracking information to the JEPs database</li>
<li>publish version 0.1 of the JEP to the JSF website <note>The canonical URL for accessing JEPs is &lt;<link url='http://www.jabber.org/jeps/'>http://www.jabber.org/jeps/</link>&gt;.</note></li>
<li>publicly announce the existence of the JEP by sending a message to the Standards-JIG list</li>
<li>add it to source control <note>XEPs are kept under source control in the 'xmpp' module and 'extensions' directory of the CVS repository maintained at the jabberstudio.org service. Instructions for accessing these files can be found at &lt;<link url='http://www.jabberstudio.org/cvs.php'>http://www.jabberstudio.org/cvs.php</link>&gt;, and a web interface to these files is available at &lt;<link url='http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/xmpp/extensions/'>http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/xmpp/extensions/</link>&gt;.</note></li>
<li>add tracking information to the XEPs database</li>
<li>publish version 0.1 of the XEP to the xmpp.org website <note>The canonical URL for accessing XMPP Extensions is &lt;<link url='http://www.xmpp.org/extensions/'>http://www.xmpp.org/extensions/</link>&gt;.</note></li>
<li>publicly announce the existence of the XEP by sending a message to the Standards-JIG list</li>
</ul>
<p>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.</p>
<p>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.</p>
</section1>
<section1 topic='Discussion Process' anchor='discussion'>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
</section1>
<section1 topic='Proposal Process' anchor='proposal'>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
</section1>
<section1 topic='Approval Process' anchor='approval'>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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 <note>A list of official JSF protocols is maintained at &lt;<link url='http://www.jabber.org/protocol/'>http://www.jabber.org/protocol</link>&gt;.</note> on the website of the Jabber Software Foundation.</p>
<p>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;.</p>
<p>More detailed information about the approval process is provided below, including criteria for Standards Track JEPs and for Historical, Informational, and Procedural JEPs.</p>
<section2 topic='Standards Track JEPs' anchor='approval-std'>
<p>The possible states for a Standards Track JEP are as follows:</p>
<p>After a XEP has been proposed to the XMPP Council, any change in its status shall be determined by a vote of the XMPP Council. All members of the Council must vote, with the possible values being +1 (approve), 0 (neutral), or -1 (disapprove, with reasons). A XEP shall not be advanced to the next stage in the approval process so long as any Council Member continues to vote -1; that Council Member's written concerns must be addressed in order for the XEP to advance. A majority of Council members must vote +1 in order for a XEP to advance. (Additional voting policies, such as voting periods and defaults if a member does not vote, may be set by the XMPP Council.) A vote of the XMPP Council is final and binding, although a XEP author is free to address the concerns of the Council and to resubmit the XEP for future consideration.</p>
<p>If the XMPP Council does not complete voting on a XEP before the end of its term, the XMPP Extensions Editor shall issue a new Last Call on the Standards 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.</p>
<p>A vote of the XMPP Council applies only to the specific revision of the XEP that has been presented to it. Further revisions may need to be re-submitted for approval.</p>
<p>Any change in the status of a XEP must be announced on the Standards-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 <note>A list of official JSF protocols is maintained at &lt;<link url='http://www.xmpp.org/protocol/'>http://www.xmpp.org/protocol</link>&gt;.</note> on the website of the Jabber Software Foundation.</p>
<p>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;.</p>
<p>More detailed information about the approval process is provided below, including criteria for Standards Track XEPs and for Historical, Informational, and Procedural XEPs.</p>
<section2 topic='Standards Track XEPs' anchor='approval-std'>
<p>The possible states for a Standards Track XEP are as follows:</p>
<code>
+--> Retracted
@ -234,8 +240,8 @@ Experimental ----> Proposed ----> Draft ----> Final
| |
+-----------+---> Deprecated ---> Obsolete
</code>
<p>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.</p>
<p>In order for a Standards Track JEP to advance from Proposed to Draft, it must:</p>
<p>The ideal path is for a Standards Track XEP is to be advanced by the XMPP Council from Proposed to Draft to Final (the criteria for this advancement are described in the following paragraphs). However, an Experimental XEP shall be assigned a status of Deferred if it has not been updated in six (6) months (e.g., because of a lack of interest or because it depends on other specifications that have yet to move forward). In addition, rather than being advanced from Proposed to Draft, a Standards Track XEP may be voted to a status of Rejected if the XMPP Council deems it unacceptable. (Note that if a XEP is Deferred, the XMPP Extensions Editor may at some point re-assign it to Experimental status, and that, even if a XEP is Rejected, it is retained in source control and on the 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.</p>
<p>In order for a Standards Track XEP to advance from Proposed to Draft, it must:</p>
<ol>
<li>fill known gaps in Jabber/XMPP technologies or deficiencies with existing protocols</li>
<li>be clearly described and accurately documented so that it can be understood and implemented by interested and knowledgeable members of the Jabber/XMPP developer community</li>
@ -243,14 +249,14 @@ Experimental ----> Proposed ----> Draft ----> Final
<li>be generally stable and appropriate for further field experience</li>
<li>have achieved rough consensus (though not necessarily unanimity) within the Standards JIG</li>
<li>be formally defined by an XML schema</li>
<li>receive the requisite votes from the Jabber Council</li>
<li>receive the requisite votes from the XMPP Council</li>
</ol>
<p>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 &lt;<link url='http://www.jabber.org/jeps/tmp/'>http://www.jabber.org/jeps/tmp/</link>&gt;, 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.</p>
<p>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.</p>
<p>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 <link url='#expiration'>Expiration Dates</link> section below). After a reasonable period of time or upon the passing of the expiration date, the status of the JEP shall be changed to Obsolete.</p>
<p>Elevation to Draft status (version 1.0) is a major advancement for the XEP, indicating a strong sense on the part of the XMPP Council and 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 &lt;<link url='http://www.xmpp.org/extensions/tmp/'>http://www.xmpp.org/extensions/tmp/</link>&gt;, 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.</p>
<p>In order for a XEP to advance from Draft status to Final status (version 2.0), it must be shown to be stable and well-received by the 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.</p>
<p>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 <link url='#expiration'>Expiration Dates</link> section below). After a reasonable period of time or upon the passing of the expiration date, the status of the XEP shall be changed to Obsolete.</p>
</section2>
<section2 topic='Historical, Informational, and Procedural JEPs' anchor='approval-info'>
<p>The possible states for a Historical, Informational, or Procedural JEP are as follows:</p>
<section2 topic='Historical, Informational, and Procedural XEPs' anchor='approval-info'>
<p>The possible states for a Historical, Informational, or Procedural XEP are as follows:</p>
<code>
+--> Retracted
@ -264,90 +270,90 @@ Experimental ----> Proposed ----> Active
|
+--> Deprecated --> Obsolete
</code>
<p>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.</p>
<p>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.</p>
<p>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 <link url="#proposal">Proposal Process</link>. 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.</p>
<p>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.</p>
<p>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.</p>
<p>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 <link url="#proposal">Proposal Process</link>. 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.</p>
</section2>
</section1>
<section1 topic='Summary of JEP States' anchor='states'>
<p>The possible states for a JEP are summarized in the following sections.</p>
<section1 topic='Summary of XEP States' anchor='states'>
<p>The possible states for a XEP are summarized in the following sections.</p>
<section2 topic='Experimental' anchor='states-Experimental'>
<p>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.</p>
<p>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.</p>
</section2>
<section2 topic='Proposed' anchor='states-Proposed'>
<p>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.</p>
<p>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.</p>
</section2>
<section2 topic='Draft' anchor='states-Draft'>
<p>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.</p>
<p>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.</p>
</section2>
<section2 topic='Final' anchor='states-Final'>
<p>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.</p>
<p>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.</p>
</section2>
<section2 topic='Active' anchor='states-Active'>
<p>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.</p>
<p>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.</p>
</section2>
<section2 topic='Deferred' anchor='states-Deferred'>
<p>An Experimental JEP of any type is changed to the Deferred state if it has not been updated in six (6) months.</p>
<p>An Experimental XEP of any type is changed to the Deferred state if it has not been updated in six (6) months.</p>
</section2>
<section2 topic='Retracted' anchor='states-Retracted'>
<p>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.</p>
<p>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.</p>
</section2>
<section2 topic='Rejected' anchor='states-Rejected'>
<p>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.</p>
<p>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.</p>
</section2>
<section2 topic='Deprecated' anchor='states-Deprecated'>
<p>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).</p>
<p>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).</p>
</section2>
<section2 topic='Obsolete' anchor='states-Obsolete'>
<p>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.</p>
<p>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.</p>
</section2>
</section1>
<section1 topic='Modification of Final and Active JEPs' anchor='mods'>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<section1 topic='Modification of Final and Active XEPs' anchor='mods'>
<p>Sometimes it is necessary to modify XEPs that have received final approval by the XMPP Council or 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.</p>
<p>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.</p>
<p>The process is similar with regard to Historical and Informational XEPs that have achieved a status of Active (corresponding to document version 1.0 of the XEP): the XMPP Council agrees on the exact changes to be made and instructs the XMPP Extensions Editor to publish and announce a revised version (e.g., version 1.1). Here again the XMPP Council bears responsibility for any changes and public discussion is welcome.</p>
<p>Procedural XEPs may be modified more frequently as the 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.</p>
</section1>
<section1 topic='Expiration Dates' anchor='expiration'>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>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.</p>
<p>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.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>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.</p>
<p>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.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<p>The &REGISTRAR; performs a function similar to the IANA, although limited to the Jabber/XMPP developer community. It does so by reserving protocol namespaces and by uniquely assigning parameters for use in the context of Jabber/XMPP protocols (for example, the categories and types used in &jep0030;).</p>
<p>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;.</p>
<p>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.</p>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The &REGISTRAR; performs a function similar to the IANA, although limited to the Jabber/XMPP developer community. It does so by reserving protocol namespaces and by uniquely assigning parameters for use in the context of Jabber/XMPP protocols (for example, the categories and types used in &xep0030;).</p>
<p>Whether or not a XEP requires registration of protocol namespaces or parameters with the XMPP Registrar, that fact must be noted and explained in a distinct section of the XEP entitled "XMPP Registrar Considerations". Such registration should not occur until a XEP advances to a status of Draft (Standards Track XEPs) or Active (Informational and Historical XEPs). Registration of protocol namespaces is initiated by the XMPP Extensions Editor when a XEP advances to Draft or Active. Registration of particular parameters used within a specification may be initiated by a XEP author within the text of the XEP, or by an implementor of the XEP after it has advanced to Draft or Active. For details regarding the XMPP Registrar and its processes, refer to &xep0053;.</p>
<p>A XEP may also request that a new registry is to be created by the XMPP Registrar. The XEP author must clearly define the nature of the new registry as well as the process for submitting data to the registry, and must do so in collaboration with the Registrar.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>JEPs that define official JSF protocols must include a schema that conforms to &w3xmlschema1; and &w3xmlschema2;.</p>
<p>The schema for the JEP format itself is as follows:</p>
<p>XMPP Extension Protocol specifications that define official JSF protocols must include a schema that conforms to &w3xmlschema1; and &w3xmlschema2;.</p>
<p>The schema for the XEP format itself is as follows:</p>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://www.jabber.org/jeps'
xmlns='http://www.jabber.org/jeps'
targetNamespace='http://www.xmpp.org/extensions'
xmlns='http://www.xmpp.org/extensions'
elementFormDefault='qualified'>
<xs:element name='jep'>
<xs:annotation>
<xs:documentation>
This schema defines the document format for Jabber Enhancement
Proposals (JEPs). For further information about JEPs, visit:
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
</xs:documentation>
</xs:annotation>
@ -394,7 +400,7 @@ Experimental ----> Proposed ----> Active
<xs:enumeration value='Final'/>
<xs:enumeration value='Obsolete'/>
<xs:enumeration value='Proposed'/>
<xs:enumeration value='ProtoJEP'/>
<xs:enumeration value='ProtoXEP'/>
<xs:enumeration value='Rejected'/>
<xs:enumeration value='Retracted'/>
</xs:restriction>
@ -685,4 +691,4 @@ Experimental ----> Proposed ----> Active
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

18
xep-0002.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jabber Interest Groups (JIGs)</title>
<abstract>A definition of Jabber Interest Groups, including their structure and role within the Jabber Software Foundation.</abstract>
@ -32,11 +32,11 @@
</revision>
</header>
<section1 topic='Short Definition'>
<p>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).</p>
<p>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).</p>
</section1>
<section1 topic='Explanation'>
<p>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 <note>For information about Jabber Enhancement Proposals, see <link url="http://foundation.jabber.org/jeps/jep-0001.html">http://foundation.jabber.org/jeps/jep-0001.html</link>.</note>) within a reasonably limited period of time. However, at the discretion of the Jabber Council, a handful of standing JIGs may be approved (e.g., to address security or standards compliance).</p>
<p>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.</p>
<p>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).</p>
<p>The main function of most JIGs is to produce acceptable XMPP extensions (delivered in the form of XMPP Extension Protocols or XEPs <note>For information about XMPP Extension Protocols, see <link url="http://www.xmpp.org/extensions/xep-0001.html">http://www.xmpp.org/extensions/xep-0001.html</link>.</note>) 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).</p>
<p>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.</p>
<p>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).</p>
</section1>
</jep>
</xep>

22
xep-0003.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Proxy Accept Socket Service (PASS)</title>
<abstract>A proposal for proxy support in Jabber.</abstract>
<abstract>This document defines a method for relaying media via proxies on the Jabber/XMPP network.</abstract>
&LEGALNOTICE;
<number>0003</number>
<status>Active</status>
@ -20,7 +20,7 @@
<supersededby/>
<shortname>pass</shortname>
<schemaloc>
<url>http://jabber.org/protocol/pass/pass.xsd</url>
<url>http://www.xmpp.org/schemas/pass.xsd</url>
</schemaloc>
&jer;
&reatmon;
@ -292,10 +292,10 @@
</section2>
</section1>
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<p>No action on the part of the &REGISTRAR; is necessary as a result of this JEP, since 'jabber:iq:pass' is already a registered protocol namespace.</p>
<section1 topic='XMPP Registrar Considerations'>
<p>No action on the part of the &REGISTRAR; is necessary as a result of this document, since 'jabber:iq:pass' is already a registered protocol namespace.</p>
</section1>
<section1 topic='XML Schema'>
<code><![CDATA[
@ -310,7 +310,7 @@
<xs:annotation>
<xs:documentation>
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
</xs:documentation>
</xs:annotation>
@ -344,4 +344,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

42
xep-0004.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Data Forms</title>
<abstract>This JEP defines a protocol for data forms and generic data description in Jabber/XMPP.</abstract>
<abstract>This document defines an XMPP protocol extension for data forms and generic data description.</abstract>
&LEGALNOTICE;
<number>0004</number>
<status>Final</status>
@ -20,7 +20,7 @@
<supersededby/>
<shortname>x-data</shortname>
<schemaloc>
<url>http://jabber.org/protocol/x-data/x-data.xsd</url>
<url>http://www.xmpp.org/schemas/x-data.xsd</url>
</schemaloc>
&reatmon;
&hildjj;
@ -49,7 +49,7 @@
<version>2.4</version>
<date>2004-05-04</date>
<initials>psa</initials>
<remark>Per discussion by the JEP authors and Jabber Council, specified that the 'var' attribute is required for all field types except "fixed", for which the 'var' attribute is optional.</remark>
<remark>Per discussion by the authors and Jabber Council, specified that the 'var' attribute is required for all field types except "fixed", for which the 'var' attribute is optional.</remark>
</revision>
<revision>
<version>2.3</version>
@ -103,7 +103,7 @@
<version>0.4</version>
<date>2001-11-16</date>
<initials>rwe</initials>
<remark>Major redesign to attempt to clarify the scope of this JEP and limit what it is trying to solve.</remark>
<remark>Major redesign to attempt to clarify the scope of this document and limit what it is trying to solve.</remark>
</revision>
<revision>
<version>0.3</version>
@ -125,12 +125,12 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>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.</p>
<p>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.</p>
<p>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., &lt;room_logging_period/&gt;), a better design would involve a more flexible format.</p>
<p>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).</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This JEP addresses the following requirements:</p>
<p>This document addresses the following requirements:</p>
<ol>
<li><strong>Data Gathering</strong> -- the protocol should enable a form-processing entity (commonly a server, service, or bot) to gather data from a form-submitting entity (commonly a client controlled by a human user); this should be done via distinct data fields (e.g., items in a questionnaire or configuration form), each of which can be a different data "type" and enable free-form input or a choice between multiple options (as is familiar from HTML forms).</li>
<li><strong>Data Reporting</strong> -- the protocol should enable a form-processing entity to report data (e.g., search results) to a form-submitting entity, again via distinct data fields.</li>
@ -194,7 +194,7 @@
<ul>
<li><p>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".</p></li>
<li><p>For &MESSAGE; stanzas, the &lt;thread/&gt; 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.</p></li>
<li><p>The only data form type allowed for &lt;presence/&gt; stanzas is "result". The &X; element qualified by the 'jabber:x:data' namespace MUST be a child of the &PRESENCE; stanza. In accordance with <strong>XMPP Core</strong>, use of data forms is not recommended unless necessary to provide information that is directly related to an entity's network availability.</p></li>
<li><p>The only data form type allowed for &lt;presence/&gt; stanzas is "result". The &X; element qualified by the 'jabber:x:data' namespace MUST be a child of the &PRESENCE; stanza. In accordance with <cite>XMPP Core</cite>, use of data forms is not recommended unless necessary to provide information that is directly related to an entity's network availability.</p></li>
</ul>
</section2>
<section2 topic='The Field Element' anchor='protocol-field'>
@ -257,7 +257,7 @@
<td>The field enables an entity to gather or provide a single line or word of text, which may be shown in an interface. This field type is the default and MUST be assumed if a form-submitting entity receives a field type it does not understand.</td>
</tr>
</table>
<p>* 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 <strong>XMPP Core</strong> (see the <link url='#validation'>Data Validation</link> section below).</p>
<p>* 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 <cite>XMPP Core</cite> (see the <link url='#validation'>Data Validation</link> section below).</p>
<p>** 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 &lt;value/&gt; element. Similarly, an application that receives multiple &lt;value/&gt; 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.</p>
</section2>
<section2 topic='Multiple Items in Form Results' anchor='protocol-results'>
@ -287,11 +287,11 @@
</section2>
</section1>
<section1 topic='Data Validation' anchor='validation'>
<p>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 &lt;text/&gt; element or an application-specific child element that identifies the problem (see &jep0086; for information about mappings and formats).</p>
<p>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 &lt;text/&gt; element or an application-specific child element that identifies the problem (see &xep0086; for information about mappings and formats).</p>
</section1>
<section1 topic='Examples' anchor='examples'>
<p>For the sake of the following examples, let us suppose that there exists a bot hosting service on the Jabber network, located at &lt;botster.shakespeare.lit&gt;. 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.</p>
<p>Note: Additional examples can be found in the specifications for various using protocols, such as <strong>JEP-0045: Multi-User Chat</strong> and <strong>JEP-0055: Jabber Search</strong>.</p>
<p>For the sake of the following examples, let us suppose that there exists a bot hosting service on the Jabber network, located at &lt;botster.shakespeare.lit&gt;. 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.</p>
<p>Note: Additional examples can be found in the specifications for various using protocols, such as <cite>XEP-0045: Multi-User Chat</cite> and <cite>XEP-0055: Jabber Search</cite>.</p>
<section2 topic='Configuration' anchor='examples-config'>
<p>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:</p>
<example caption="User Requests Bot Creation"><![CDATA[
@ -567,17 +567,17 @@
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>There are no security concerns related to this specification above and beyond those described in the relevant section of <strong>XMPP Core</strong>.</p>
<p>There are no security concerns related to this specification above and beyond those described in the relevant section of <cite>XMPP Core</cite>.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-namespaces'>
<p>The &REGISTRAR; includes the 'jabber:x:data' namespace in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Parameter Values' anchor='registrar-parameters'>
<p>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 &lt;<link url="http://www.jabber.org/registrar/formtypes.html">http://www.jabber.org/registrar/formtypes.html</link>&gt;.</p>
<p>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 &lt;<link url="http://www.jabber.org/registrar/formtypes.html">http://www.jabber.org/registrar/formtypes.html</link>&gt;.</p>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
@ -594,7 +594,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0004: http://www.jabber.org/jeps/jep-0004.html
XEP-0004: http://www.xmpp.org/extensions/xep-0004.html
</xs:documentation>
</xs:annotation>
@ -706,4 +706,4 @@
<li>The &lt;reported/&gt; fields MAY possess a 'type' attribute to provide hints about how to interact with the data (type='jid-single' being the most useful).</li>
</ul>
</section1>
</jep>
</xep>

10
xep-0005.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jabber Interest Groups</title>
<abstract>This is the official list and summary information of the Jabber Interest Groups.</abstract>
@ -104,5 +104,5 @@ Create additional protocols and methods to assist exchanging OOB data in heterog
<p>Describe in detail how presence management currently works, and work on proposals for things like invisibility.</p>
</section1>
</jep>
</xep>

10
xep-0006.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Profiles</title>
<abstract>A proposal for a more powerful and extensible protocol for the management of personal information within Jabber.</abstract>
@ -93,4 +93,4 @@
<section1 topic='History'>
<p>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 (<link url="http://www.theoretic.com/identity/">http://www.theoretic.com/identity/</link>), 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.</p>
</section1>
</jep>
</xep>

10
xep-0007.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Conferencing JIG</title>
<abstract>A proposal for a Jabber Interest Group that will discuss the protocol for implementing many-to-many communications.</abstract>
@ -70,4 +70,4 @@
<section1 topic='Continuing Development'>
<p>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.</p>
</section1>
</jep>
</xep>

14
xep-0008.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>IQ-Based Avatars</title>
<abstract>This JEP provides historical documentation of an IQ-based protocol for exchanging user avatars.</abstract>
<abstract>This specification provides historical documentation of an IQ-based protocol for exchanging user avatars.</abstract>
&LEGALNOTICE;
<number>0008</number>
<status>Deferred</status>
@ -39,7 +39,7 @@
<version>0.2</version>
<date>2003-05-06</date>
<initials>psa</initials>
<remark>At the request of the authors, the status of this JEP has been changed to Retracted, to be superseded by a forthcoming JEP. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
<remark>At the request of the authors, the status of this document has been changed to Retracted, to be superseded by a forthcoming JEP. This document will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
</revision>
<revision>
<version>0.1</version>
@ -135,4 +135,4 @@
<p>Peter Millard, a co-author of this specification from version 0.1 through version 0.3, died on April 26, 2006.</p>
</section1>
</jep>
</xep>

28
xep-0009.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jabber-RPC</title>
<abstract>This JEP defines a method for transporting XML-RPC encoded requests and responses over Jabber/XMPP.</abstract>
<abstract>This specification defines a method for transporting XML-RPC encoded requests and responses over Jabber/XMPP.</abstract>
&LEGALNOTICE;
<number>0009</number>
<status>Final</status>
@ -21,7 +21,7 @@
<supersededby/>
<shortname>jabber-rpc</shortname>
<schemaloc>
<url>http://jabber.org/protocol/jabber-rpc/jabber-rpc.xsd</url>
<url>http://www.xmpp.org/schemas/jabber-rpc.xsd</url>
</schemaloc>
<author>
<firstname>DJ</firstname>
@ -33,7 +33,7 @@
<version>2.1</version>
<date>2006-02-09</date>
<initials>psa</initials>
<remark>Defined error handling, service discovery, security considerations, and Jabber Registrar considerations.</remark>
<remark>Defined error handling, service discovery, security considerations, and XMPP Registrar considerations.</remark>
</revision>
<revision>
<version>2.0</version>
@ -57,7 +57,7 @@
<section1 topic='Introduction'>
<p>&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.</p>
<p>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 <message/> element as opposed to an &IQ; stanza), resulting in potential interoperability problems.</p>
<p>A working session during JabberCon 2001 resulted in a <link url="http://www.pipetree.com/jabber/jrpc.html">formalisation</link> of a single method. This JEP describes that method, which is labelled as Jabber-RPC to differentiate it from XML-RPC itself.</p>
<p>A working session during JabberCon 2001 resulted in a <link url="http://www.pipetree.com/jabber/jrpc.html">formalisation</link> of a single method. This document describes that method, which is labelled as Jabber-RPC to differentiate it from XML-RPC itself.</p>
</section1>
<section1 topic='Jabber-RPC'>
<p>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.</p>
@ -122,7 +122,7 @@
]]></example>
</section1>
<section1 topic='Service Discovery' anchor='disco'>
<p>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":</p>
<p>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":</p>
<example caption='A disco#info query'><![CDATA[
<iq type='get'
from='requester@company-b.com/jrpc-client'
@ -147,14 +147,14 @@
<p>An entity that supports Jabber-RPC SHOULD establish a "whitelist" of entities that are allowed to perform remote procedure calls and MUST return a &forbidden; error if entities with insufficient permissions attempt such calls.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic="Jabber Registrar Considerations" anchor='registrar'>
<section1 topic="XMPP Registrar Considerations" anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes 'jabber:iq:rpc' in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Service Discovery Identity' anchor='registrar-disco'>
<p>The Jabber Registrar includes a Service Discovery type of "rpc" within the "automation" category in its registry of service discovery identities.</p>
<p>The XMPP Registrar includes a Service Discovery type of "rpc" within the "automation" category in its registry of service discovery identities.</p>
</section2>
</section1>
<section1 topic='XML Schema'>
@ -170,7 +170,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0009: http://www.jabber.org/jeps/jep-0009.html
XEP-0009: http://www.xmpp.org/extensions/xep-0009.html
There is no official XML schema for XML-RPC. The main body
of this schema has been borrowed from an unofficial schema
@ -313,4 +313,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

10
xep-0010.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Whiteboarding JIG</title>
<abstract>A proposal to form a JIG to develop a protocol for whiteboarding over Jabber.</abstract>
@ -52,4 +52,4 @@
<p>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.</p>
</section2>
</section1>
</jep>
</xep>

24
xep-0011.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jabber Browsing</title>
<abstract>This JEP defines a way to describe information about Jabber entities and the relationships between entities. Note: This JEP is superseded by JEP-0030: Service Discovery.</abstract>
@ -21,9 +21,6 @@
<spec>JEP-0030</spec>
</supersededby>
<shortname>iq-browse</shortname>
<schemaloc>
<url>http://jabber.org/protocol/iq-browse/iq-browse.xsd</url>
</schemaloc>
&jer;
&xvirge;
&temas;
@ -72,7 +69,7 @@
</header>
<section1 topic='Introduction'>
<p>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.</p>
<p><em>Note well that implementors are encouraged to implement &jep0030; instead of Jabber Browsing.</em></p>
<p><em>Note well that implementors are encouraged to implement &xep0030; instead of Jabber Browsing.</em></p>
</section1>
<section1 topic='JID-Types'>
<p>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:</p>
@ -427,7 +424,7 @@
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<section1 topic='XMPP Registrar Considerations'>
<p>No action on the part of the &REGISTRAR; is necessary as a result of this JEP, since 'jabber:iq:browse' is already a registered protocol namespace.</p>
</section1>
<section1 topic='XML Schema'>
@ -440,13 +437,6 @@
xmlns='jabber:iq:browse'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0011: http://www.jabber.org/jeps/jep-0011.html
</xs:documentation>
</xs:annotation>
<xs:element name='query'>
<xs:complexType>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
@ -480,4 +470,4 @@
<section1 topic='Future Considerations'>
<p>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.</p>
</section1>
</jep>
</xep>

32
xep-0012.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Last Activity</title>
<abstract>This JEP defines a protocol for retrieving information about the last activity associated with a Jabber entity.</abstract>
<abstract>This document defines an XMPP protocol extension for retrieving information about the last activity associated with a Jabber entity.</abstract>
&LEGALNOTICE;
<number>0012</number>
<status>Active</status>
@ -21,7 +21,7 @@
<supersededby/>
<shortname>iq-last</shortname>
<schemaloc>
<url>http://jabber.org/protocol/iq-last/iq-last.xsd</url>
<url>http://www.xmpp.org/schemas/iq-last.xsd</url>
</schemaloc>
&jer;
&temas;
@ -42,7 +42,7 @@
<version>0.3</version>
<date>2002-01-14</date>
<initials>psa</initials>
<remark>Made appropriate changes to reflect this JEP's status as informational.</remark>
<remark>Made appropriate changes to reflect status as informational.</remark>
</revision>
<revision>
<version>0.2</version>
@ -59,7 +59,7 @@
</header>
<section1 topic='Introduction'>
<p>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.</p>
<p>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.</p>
<p>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.</p>
</section1>
<section1 topic='Basic Protocol'>
<p>The 'jabber:iq:last' namespace is used as the value of the 'xmlns' attribute of a &#60;query&#62; element contained within an &#60;iq/&#62; element. When requesting last activity information, a Jabber Entity sends an &#60;iq&#62; element of type='get' to another Jabber Entity (i.e., a JID). When responding to such a request, a Jabber Entity sends an &#60;iq&#62; element of type='result'. The &#60;query&#62; element never has any children and contains only one attribute and CDATA, depending on the scenario in which it is used.</p>
@ -80,7 +80,7 @@
]]></example>
<p>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 &lt;status/&gt; element contained the text "Heading home".</p>
<p>If the user has at least one available resource when the server receives the request, the response SHOULD contain an empty &lt;query/&gt; element whose 'seconds' attribute is set to a value of '0'.</p>
<p>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;).</p>
<p>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;).</p>
</section1>
<section1 topic='Online User Query'>
<p>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:</p>
@ -110,13 +110,13 @@
<p>In this example, the server has been up for a little more than 34 hours.</p>
</section1>
<section1 topic='Security Considerations'>
<p>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 <strong>XMPP IM</strong> and further profiled in &jep0126;).</p>
<p>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 <strong>XMPP IM</strong> and further profiled in &xep0126;).</p>
</section1>
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<p>No action on the part of the &REGISTRAR; is necessary as a result of this JEP, since 'jabber:iq:last' is already a registered protocol namespace.</p>
<section1 topic='XMPP Registrar Considerations'>
<p>No action on the part of the &REGISTRAR; is necessary as a result of this document, since 'jabber:iq:last' is already a registered protocol namespace.</p>
</section1>
<section1 topic='XML Schema'>
<code><![CDATA[
@ -131,7 +131,7 @@
<xs:annotation>
<xs:documentation>
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
</xs:documentation>
</xs:annotation>
@ -154,6 +154,6 @@
<section1 topic='Future Considerations'>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
</section1>
</jep>
</xep>

50
xep-0013.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Flexible Offline Message Retrieval</title>
<abstract>This JEP defines a protocol for flexible, POP3-like handling of offline messages in Jabber/XMPP.</abstract>
<abstract>This document defines an XMPP protocol extension for flexible, POP3-like handling of offline messages.</abstract>
&LEGALNOTICE;
<number>0013</number>
<status>Draft</status>
@ -16,8 +16,8 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0030</spec>
<spec>JEP-0082</spec>
<spec>XEP-0030</spec>
<spec>XEP-0082</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -66,13 +66,13 @@
<version>0.6</version>
<date>2003-06-10</date>
<initials>psa</initials>
<remark>Slight fixes to JEP-0082 reference and XML schema.</remark>
<remark>Slight fixes to XEP-0082 reference and XML schema.</remark>
</revision>
<revision>
<version>0.5</version>
<date>2003-04-28</date>
<initials>psa</initials>
<remark>Added reference to JEP-0082; changed timestamp format to use milliseconds rather than ten-thousandths of a second; made several small editorial changes throughout.</remark>
<remark>Added reference to XEP-0082; changed timestamp format to use milliseconds rather than ten-thousandths of a second; made several small editorial changes throughout.</remark>
</revision>
<revision>
<version>0.4</version>
@ -119,7 +119,7 @@
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Discovering Server Support' anchor='discover'>
<p>In order to discover whether one's server supports this protocol, one uses &jep0030;.</p>
<p>In order to discover whether one's server supports this protocol, one uses &xep0030;.</p>
<example caption='User Requests Service Discovery Information'><![CDATA[
<iq type='get' to='montague.net'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
@ -147,7 +147,7 @@
node='http://jabber.org/protocol/offline'/>
</iq>
]]></example>
<p>If the server supports retrieval of the number of messages, it MUST include &jep0128; data specifying the number of messages:</p>
<p>If the server supports retrieval of the number of messages, it MUST include &xep0128; data specifying the number of messages:</p>
<example caption='Server Returns Information About Offline Message Node, Including Number of Messages'><![CDATA[
<iq type='result' to='romeo@montague.net/orchard'>
<query xmlns='http://jabber.org/protocol/disco#info'
@ -167,7 +167,7 @@
</query>
</iq>
]]></example>
<p>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.</p>
<p>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.</p>
</section2>
<section2 topic='Requesting Message Headers' anchor='request-headers'>
<p>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'.</p>
@ -205,12 +205,12 @@
</query>
</iq>
]]></example>
<p>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 &notfound; 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;.)</p>
<p>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 &notfound; 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;.)</p>
<p>The syntax and semantics of the attributes are as follows:</p>
<ul>
<li>The 'jid' attribute is the Jabber ID with which the item nodes are associated, i.e., the user himself.</li>
<li>The 'name' attribute is the full JID of the sender as received in the 'from' address of the message itself.</li>
<li>The 'node' attribute is a unique identifier for the message. The value SHOULD be considered opaque, but applications MAY perform character-by-character dictionary ordering on the values. This enables applications to implement ordering on messages, such as that shown above, wherein the node values are UTC timestamps (if timestamps are used, they MUST conform to the 'Datetime' profile defined in &jep0082;).</li>
<li>The 'node' attribute is a unique identifier for the message. The value SHOULD be considered opaque, but applications MAY perform character-by-character dictionary ordering on the values. This enables applications to implement ordering on messages, such as that shown above, wherein the node values are UTC timestamps (if timestamps are used, they MUST conform to the 'Datetime' profile defined in &xep0082;).</li>
</ul>
</section2>
<section2 topic='Retrieving Specific Messages' anchor='retrieve-specific'>
@ -234,7 +234,7 @@
<iq type='result' to='user@domain/resource' id='view1'/>
]]></example>
<p>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.</p>
<p>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.</p>
</section2>
<section2 topic='Removing Specific Messages' anchor='remove-specific'>
<p>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.</p>
@ -340,14 +340,14 @@ C: request and remove offline messages, send and receive messages, etc.
<p>A server MUST NOT deliver a user's offline messages to any JID except one of the user's authorized resources.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes 'http://jabber.org/protocol/offline' in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Service Discovery Identities' anchor='registrar-disco-identity'>
<p>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:</p>
<p>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:</p>
<table caption='Types for Category "automation"'>
<tr>
<th>Type</th>
@ -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"
</desc>
<doc>JEP-0013</doc>
<doc>XEP-0013</doc>
</type>
<type>
<name>message-node</name>
<desc>A node for a specific offline message if service discovery is provided for messages</desc>
<doc>JEP-0013</doc>
<doc>XEP-0013</doc>
</type>
</category>
]]></code>
</section2>
<section2 topic='Well-Known Service Discovery Nodes' anchor='registrar-disco-nodes'>
<p>The Jabber Registrar includes "http://jabber.org/protocol/offline" in its registry of well-known Service Discovery nodes.</p>
<p>The XMPP Registrar includes "http://jabber.org/protocol/offline" in its registry of well-known Service Discovery nodes.</p>
</section2>
<section2 topic='Field Standardization' anchor='registrar-formtype'>
<p>&jep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. There is one uses of such forms in offline message retrieval as described in the <link url='#request-number'>Requesting Number of Messages</link> section of this JEP. The registry submission is as follows:</p>
<p>&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. There is one uses of such forms in offline message retrieval as described in the <link url='#request-number'>Requesting Number of Messages</link> section of this XEP. The registry submission is as follows:</p>
<code caption='Registry Submission'><![CDATA[
<form_type>
<name>http://jabber.org/protocol/offline</name>
<doc>JEP-0013</doc>
<doc>XEP-0013</doc>
<desc>
Service Discovery extension for number of messages
in an offline message queue.
@ -414,7 +414,7 @@ C: request and remove offline messages, send and receive messages, etc.
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0013: http://www.jabber.org/jeps/jep-0013.html
XEP-0013: http://www.xmpp.org/extensions/xep-0013.html
</xs:documentation>
</xs:annotation>
@ -444,4 +444,4 @@ C: request and remove offline messages, send and receive messages, etc.
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

10
xep-0014.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Message Tone</title>
<abstract>A proposal for including the sender's tone in messages.</abstract>
@ -67,4 +67,4 @@
<li>serious</li>
</ul>
</section1>
</jep>
</xep>

10
xep-0015.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Account Transfer</title>
<abstract>A proposal for enabling the ability to transfer an account from one Jabber server to another.</abstract>
@ -255,4 +255,4 @@
server.</p>
</section2>
</section1>
</jep>
</xep>

1119
xep-0016.xml
View File

File diff suppressed because it is too large Load Diff

16
xep-0017.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Naive Packet Framing Protocol</title>
<abstract>An intermediate method for more efficient framing of the Jabber XML Stream.</abstract>
@ -46,7 +46,7 @@
</header>
<section1 topic='Introduction'>
<p>Framing is the mechanism by which a listener is able to separate a stream of information into discrete semantic units. In Jabber, each of these semantic units is a fragment of a &lt;stream:stream&gt; document consisting of a direct (depth=1) child element of the &lt;stream:stream&gt; document element, and all its attributes and child nodes. These semantic units are hereafter called packets. A Jabber session document, excluding the document element start tag and end tag which are handled as special cases, is implicitly encoded into these packets and transmitted across the network.</p>
<p>This JEP describes a framing method that may provide performance and code simplicity advantages over the framing method currently used.</p>
<p>This document describes a framing method that may provide performance and code simplicity advantages over the framing method currently used.</p>
</section1>
<section1 topic='Framing in Jabber'> <p>The current scheme for framing in Jabber relies on the inherent structure of XML to determine packet boundaries. Since each packet is a well-formed XML fragment, the start of the packet is unambiguously denoted by the element start tag at depth=1, and the end of the packet is unambiguously denoted by the corresponding close tag at depth=1.</p>
<p>This method of framing is elegant because all the necessary framing information is inherent in the XML; it makes framing independent of the underlying transport layer so long as that transport layer guarantees per-session FIFO delivery. However, it has significant performance and implementation disadvantages, as it requires any Jabber node (endpoint or router) to XML-parse the packet as it is still being received in order to determine the packet boundary. Many XML parsing suites are not designed to be used in this manner, and various hacks and workarounds have emerged in current Jabber software in order to adapt them for this purpose.</p>
@ -68,7 +68,7 @@
</section1>
<section1 topic='Implementation Notes'>
<p>Framing data is included for the &lt;stream:stream&gt; and &lt;/stream:stream&gt; tags as if they were their own packets, although they are not independently well-formed XML. These should be handled as special cases in a Jabber XML streams implementation.</p>
<p>The connecting agent (client) implicitly requests that the receiving agent (server) use JEP-0017 framing by transmitting JEP-0017 framing data in its own outgoing stream (the connecting agent always "goes first"). Servers should detect the presence of framing data in the client's stream (by testing whether the first character received is a digit or a &lt;) and, if it is detected, activate outgoing framing for that session.</p>
<p>The connecting agent (client) implicitly requests that the receiving agent (server) use XEP-0017 framing by transmitting XEP-0017 framing data in its own outgoing stream (the connecting agent always "goes first"). Servers should detect the presence of framing data in the client's stream (by testing whether the first character received is a digit or a &lt;) and, if it is detected, activate outgoing framing for that session.</p>
<p>Regardless of the use of framing data, all nodes must verify the well-formedness of XML payloads in order to avoid propagating misframes.</p>
</section1>
<section1 topic='Example'>
@ -77,7 +77,7 @@
</example>
</section1>
<section1 topic='Philosophical Notes and Conclusion'>
<p>This framing method is not intended as a fully satisfactory or permanent solution to XML stream framing. In the "distant" (longer than one year) time span, it may be desirable to consider more thorough systems such as BEEP. The intent of this JEP is to establish an intermediate solution that will provide code simplicity advantages to new implementations in the near term without requiring fundamental changes to the Jabber transport or protocol (as adopting BEEP would almost certainly require).</p>
<p>This framing method is not intended as a fully satisfactory or permanent solution to XML stream framing. In the "distant" (longer than one year) time span, it may be desirable to consider more thorough systems such as BEEP. The intent of this document is to establish an intermediate solution that will provide code simplicity advantages to new implementations in the near term without requiring fundamental changes to the Jabber transport or protocol (as adopting BEEP would almost certainly require).</p>
</section1>
</jep>
</xep>

10
xep-0018.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Invisible Presence</title>
<abstract>Documentation of invisible presence.</abstract>
@ -132,4 +132,4 @@
<section1 topic="Jabber Registrar Considerations">
<p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this JEP.</p>
</section1>
</jep>
</xep>

21
xep-0019.xml
View File

@ -1,10 +1,10 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type="text/xsl" href="../jep.xsl"?>
<jep>
<?xml-stylesheet type="text/xsl" href="xep.xsl"?>
<xep>
<header>
<title>Streamlining the JIGs</title>
<abstract>This JEP proposes to streamline the existing Jabber Interest Groups (JIGs).</abstract>
@ -17,12 +17,7 @@
<dependencies/>
<supersedes/>
<supersededby/>
<author>
<firstname>Peter</firstname>
<surname>Saint-Andre</surname>
<email>stpeter@jabber.org</email>
<jid>stpeter@jabber.org</jid>
</author>
&stpeter;
<revision>
<version>1.0</version>
<date>2002-03-20</date>
@ -46,9 +41,9 @@
<p>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 JEP, I argue that just such an adjustment is now necessary with regard to the Jabber Interest Groups (JIGs). <note>The proposal contained in this JEP formalizes some conclusions reached during a weekly discussion forum held by the Jabber Software Foundation on 2002-01-23. A log of that discussion is available at <link url="http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-01-23.html">http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-01-23.html</link>. Further discussion within the Standards JIG has been helpful in clarifying the argument presented here.</note></p>
</section1>
<section1 topic="The Problem">
<p>JEP-0002 <note>URL: <link url='http://www.jabber.org/jeps/jep-0002.html'>http://www.jabber.org/jeps/jep-0002.html</link></note> 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 (delivered in the form of Jabber Enhancement Proposals or JEPs) within a reasonably limited period of time". In early January of 2002, JEP-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).</p>
<p>&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 (delivered in the form of Jabber Enhancement Proposals or JEPs) within a reasonably limited period of time". In early January of 2002, JEP-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).</p>
<p>Unfortunately, it is widely recognized in the Jabber community that the JIGs are not working. Ten JIGs have been approved by the Jabber Council,<note>See <link url='http://www.jabber.org/jigs.html'>http://www.jabber.org/jigs.html</link> for the official list.</note> eight of them over six months ago in July and August of 2001. Two of the special-purpose JIGs (OOB and Presence) have seen no activity whatsoever and thus are clearly eligible to be disbanded. The other special-purpose JIGs (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 JEP-0002. Only the two "standing" JIGs (Security and Standards) have experienced significant and continued mailing list activity, mainly because the Standards JIG has assumed the role of discussion forum for JEPs before they are submitted to the Jabber Council.</p>
<p>In perhaps the best measure of success or failure, only one JIG has produced a JEP for submission to the Jabber Council, and that JEP (JEP-0009 <note>URL: <link url='http://www.jabber.org/jeps/jep-0009.html'>http://www.jabber.org/jeps/jep-0009.html</link></note> for transporting XML-RPC over Jabber) 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 JEP, or even starting work on one. With the possible exception of JEP-0009, all of the JEPs created so far have come from individuals or small, ad-hoc groups -- not through the efforts of the JIGs.</p>
<p>In perhaps the best measure of success or failure, only one JIG has produced a JEP for submission to the Jabber Council, and that JEP (&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 JEP, or even starting work on one. With the possible exception of JEP-0009, all of the JEPs created so far have come from individuals or small, ad-hoc groups -- not through the efforts of the JIGs.</p>
<p>In other words, an honest assessment forces us to conclude that the JIGs are not working.</p>
</section1>
<section1 topic="Analysis and Possible Solutions">
@ -78,4 +73,4 @@
</ol>
<p>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 JEP. <note>Lest there be any concern that disbanding the JIGs is outside the power or purview of the Jabber Council, I note that Section 8.2 of the Bylaws of the Jabber Software Foundation states in part that "The Jabber Council or the Members of the Corporation may, by resolution, ... terminate a Jabber Interest Group at any time for any reason." (An electronic copy of the Bylaws may be found at <link url="http://www.jabber.org/bylaws.html">http://www.jabber.org/bylaws.html</link>.)</note></p>
</section1>
</jep>
</xep>

40
xep-0020.xml
View File

@ -1,13 +1,13 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Feature Negotiation</title>
<abstract>This JEP defines a A protocol that enables two Jabber entities to mutually negotiate feature options.</abstract>
<abstract>This document defines an XMPP protocol extension that enables two entities to mutually negotiate feature options.</abstract>
&LEGALNOTICE;
<number>0020</number>
<status>Draft</status>
@ -15,7 +15,7 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0004</spec>
<spec>XEP-0004</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -29,13 +29,13 @@
<version>1.4</version>
<date>2004-05-21</date>
<initials>psa</initials>
<remark>Moved remaining feature negotiation text from JEP-0030 to this document.</remark>
<remark>Moved remaining feature negotiation text from XEP-0030 to this document.</remark>
</revision>
<revision>
<version>1.3</version>
<date>2004-04-23</date>
<initials>psa</initials>
<remark>Per Council discussion, changed root element from &lt;query/&gt; to &lt;feature/&gt; for the sake of consistency with using protocols; moved some text from JEP-0030 to this document.</remark>
<remark>Per Council discussion, changed root element from &lt;query/&gt; to &lt;feature/&gt; for the sake of consistency with using protocols; moved some text from XEP-0030 to this document.</remark>
</revision>
<revision>
<version>1.2</version>
@ -81,14 +81,14 @@
</revision>
</header>
<section1 topic="Introduction" anchor='intro'>
<p>A discovery protocol such as &jep0030; enables Jabber entities to query other entities regarding the features they support, but does not provide a means for the two entities to negotiate specific options related to the advertised features (e.g., specific methods of file transfer such as &jep0047; or &jep0065;).</p>
<p>A discovery protocol such as &xep0030; enables Jabber entities to query other entities regarding the features they support, but does not provide a means for the two entities to negotiate specific options related to the advertised features (e.g., specific methods of file transfer such as &xep0047; or &xep0065;).</p>
<p>The protocol defined herein enables Jabber entities to negotiate options for specific features. These features could be negotiated between any two endpoints on the Jabber network, such as two clients, a client and a component, two components, a client and a server, or two servers. The protocol is generic enough that it can be used whenever options need to be negotiated between two Jabber entities.</p>
</section1>
<section1 topic="Protocol Details" anchor='protocol'>
<p>Features are negotiated though the exchange of &IQ; stanzas containing &QUERY; child elements qualified by the 'http://jabber.org/protocol/feature-neg' namespace. However, this &QUERY; element is simply a wrapper for structured data encapsulated in the &jep0004; protocol. <note>Earlier versions of this JEP defined an structured data format to handle the feature negotiation workflow; versions later than 0.4 use <strong>Data Forms</strong>, i.e., the 'jabber:x:data' namespace.</note></p>
<p>In order to begin a negotation, the initiator sends an &IQ; stanza of type "get" to the recipient with a single &lt;feature/&gt; element containing a data form of type "form" which defines the available options for one or more features. Each feature is represented as an x-data "field", which MUST be of type "list-single" as specified in JEP-0004.</p>
<p>Features are negotiated though the exchange of &IQ; stanzas containing &QUERY; child elements qualified by the 'http://jabber.org/protocol/feature-neg' namespace. However, this &QUERY; element is simply a wrapper for structured data encapsulated in the &xep0004; protocol. <note>Earlier versions of this document defined an structured data format to handle the feature negotiation workflow; versions later than 0.4 use <strong>Data Forms</strong>, i.e., the 'jabber:x:data' namespace.</note></p>
<p>In order to begin a negotation, the initiator sends an &IQ; stanza of type "get" to the recipient with a single &lt;feature/&gt; element containing a data form of type "form" which defines the available options for one or more features. Each feature is represented as an x-data "field", which MUST be of type "list-single" as specified in XEP-0004.</p>
<p>The recipient SHOULD examine each feature and the options provided. In order to indicate preferred options, the recipient then SHOULD specify one option for each feature and return a data form of type "submit" to the initiator in an &IQ; stanza of type "result".</p>
<p>The following examples show some likely scenarios for feature negotiation between entities. Further examples can be found in using protocols, such as &jep0096;.</p>
<p>The following examples show some likely scenarios for feature negotiation between entities. Further examples can be found in using protocols, such as &xep0096;.</p>
<section2 topic="Basic Flow" anchor='protocol-basic'>
<p>A typical negotiation flow is shown in the following example of two entities negotiating the time and place for a meeting.</p>
<example caption="Initiating entity sends offer"><![CDATA[
@ -156,7 +156,7 @@
]]></example>
</section2>
<section2 topic="Querying for Negotiable Features" anchor='protocol-query'>
<p>If at least one feature offered by an entity is subject to &jep0020;, the entity's response to a service discovery information request MUST include &lt;feature var='http://jabber.org/protocol/feature-neg'/&gt; as one of the features.</p>
<p>If at least one feature offered by an entity is subject to &xep0020;, the entity's response to a service discovery information request MUST include &lt;feature var='http://jabber.org/protocol/feature-neg'/&gt; as one of the features.</p>
<example caption='Client queries a chatroom for supported features'><![CDATA[
<iq type='get'
from='juliet@capulet.com/balcony'
@ -176,7 +176,7 @@
...
</query>
</iq>]]></example>
<p>The using protocol (in these examples, &jep0045;) SHOULD specify which features might be negotiable, either in the relevant documentation or in the entry for that feature in the service discovery features registry maintained by the Jabber Registrar. However, the requesting entity MAY also query the responding entity in order to determine which features are negotiable, as shown below.</p>
<p>The using protocol (in these examples, &xep0045;) SHOULD specify which features might be negotiable, either in the relevant documentation or in the entry for that feature in the service discovery features registry maintained by the XMPP Registrar. However, the requesting entity MAY also query the responding entity in order to determine which features are negotiable, as shown below.</p>
<example caption='Client queries a chatroom for supported features'><![CDATA[
<iq type='get'
from='juliet@capulet.com/balcony'
@ -196,7 +196,7 @@
...
</query>
</iq>]]></example>
<p>The using protocol (in these examples, <cite>JEP-0045</cite>) SHOULD specify which features might be negotiable, either in the relevant documentation or in the entry for that feature in the service discovery features registry maintained by the Jabber Registrar (see &lt;<link url='http://www.jabber.org/registrar/disco-vars.html'>http://www.jabber.org/registrar/disco-vars.html</link>&gt;). However, the requesting entity MAY also query the responding entity in order to determine which features are negotiable, as shown below.</p>
<p>The using protocol (in these examples, <cite>XEP-0045</cite>) SHOULD specify which features might be negotiable, either in the relevant documentation or in the entry for that feature in the service discovery features registry maintained by the XMPP Registrar (see &lt;<link url='http://www.jabber.org/registrar/disco-vars.html'>http://www.jabber.org/registrar/disco-vars.html</link>&gt;). However, the requesting entity MAY also query the responding entity in order to determine which features are negotiable, as shown below.</p>
<example caption='Client queries chatroom regarding options for a negotiable feature'><![CDATA[
<iq type='get'
from='juliet@capulet.com/balcony'
@ -252,11 +252,11 @@
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic="Jabber Registrar Considerations" anchor='registrar'>
<p>In order for Jabber entities to adequately leverage <strong>Data Forms</strong> (e.g., by using machine-readable fields), it is RECOMMENDED to register standard x-data fields with the &REGISTRAR; via the mechanisms defined in &jep0068;. Whether to do so for any given features and options shall be determined by the using protocol.</p>
<section1 topic="XMPP Registrar Considerations" anchor='registrar'>
<p>In order for Jabber entities to adequately leverage <strong>Data Forms</strong> (e.g., by using machine-readable fields), it is RECOMMENDED to register standard x-data fields with the &REGISTRAR; via the mechanisms defined in &xep0068;. Whether to do so for any given features and options shall be determined by the using protocol.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
@ -276,7 +276,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0020: http://www.jabber.org/jeps/jep-0020.html
XEP-0020: http://www.xmpp.org/extensions/xep-0020.html
</xs:documentation>
</xs:annotation>
@ -293,4 +293,4 @@
<section1 topic='Author Note' anchor='authornote'>
<p>Peter Millard, the primary author of this specification from version 0.1 through version 1.4, died on April 26, 2006. The remaining author is thankful for Peter's work on this specification.</p>
</section1>
</jep>
</xep>

10
xep-0021.xml
View File

@ -1,11 +1,11 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<jep>
<xep>
<header>
<title>Jabber Event Notification Service (ENS)</title>
@ -340,4 +340,4 @@
</section2>
</section1>
</jep>
</xep>

19
xep-0022.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Message Events</title>
<abstract>This JEP defines protocol extensions used to request and respond to events relating to the delivery, display, and composition of messages.</abstract>
<abstract>This document defines an XMPP protocol extension used to request and respond to events relating to the delivery, display, and composition of messages.</abstract>
&LEGALNOTICE;
<number>0022</number>
<status>Active</status>
@ -71,6 +71,7 @@
<section1 topic='Introduction'>
<p>The 'jabber:x:event' namespace defines extensions used to request and respond to events relating to the delivery, display, and composition of messages.</p>
<p>By attaching a jabber:x:event extension to a &MESSAGE; element, the sender can track stages in the delivery of that message to its recipient.</p>
<p><em>Note: A more modern protocol extension for this functionality has been been defined in &xep0085;.</em></p>
</section1>
<section1 topic='The Events'>
@ -267,10 +268,10 @@ SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
<p>There are no security features or concerns related to this proposal.</p>
</section1>
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<p>No action on the part of the &REGISTRAR; is necessary as a result of this JEP, since 'jabber:x:event' is already a registered protocol namespace.</p>
<p>No action on the part of the &REGISTRAR; is necessary as a result of this document, since 'jabber:x:event' is already a registered protocol namespace.</p>
</section1>
<section1 topic='XML Schema'>
@ -286,7 +287,7 @@ SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0022: http://www.jabber.org/jeps/jep-0022.html
XEP-0022: http://www.xmpp.org/extensions/xep-0022.html
</xs:documentation>
</xs:annotation>
@ -318,4 +319,4 @@ SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
</ol>
</section1>
</jep>
</xep>

18
xep-0023.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Message Expiration</title>
<abstract>This specification documents an historical protocol that was used to specify expiration dates for messages; this protocol has been deprecated in favor of JEP-0079: Advanced Message Processing.</abstract>
@ -47,7 +47,7 @@
<version>1.1</version>
<date>2004-01-06</date>
<initials>psa</initials>
<remark>Added XML schema; added security, IANA, and Jabber Registrar considerations.</remark>
<remark>Added XML schema; added security, IANA, and XMPP Registrar considerations.</remark>
</revision>
<revision>
<version>1.0</version>
@ -70,7 +70,7 @@
</header>
<section1 topic='Introduction'>
<p><em>Note Well: The protocol described herein has been deprecated by the &JSF;. The recommended protocol for implementing message expiration functionality is now &jep0079;.</em></p>
<p><em>Note Well: The protocol described herein has been deprecated by the &JSF;. The recommended protocol for implementing message expiration functionality is now &xep0079;.</em></p>
<p>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.</p>
<p>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:</p>
<ul>
@ -123,7 +123,7 @@ SEND: &lt;message to='sabine@gnu.mine.nu' id='msg811'&gt;
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<section1 topic='XMPP Registrar Considerations'>
<p>No action on the part of the &REGISTRAR; is necessary as a result of this JEP, since 'jabber:x:expire' is already a registered protocol namespace.</p>
</section1>
@ -140,7 +140,7 @@ SEND: &lt;message to='sabine@gnu.mine.nu' id='msg811'&gt;
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0023: http://www.jabber.org/jeps/jep-0023.html
XEP-0023: http://www.xmpp.org/extensions/xep-0023.html
</xs:documentation>
</xs:annotation>
@ -172,4 +172,4 @@ SEND: &lt;message to='sabine@gnu.mine.nu' id='msg811'&gt;
</ol>
</section1>
</jep>
</xep>

12
xep-0024.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Publish/Subscribe</title>
<abstract>A publish--subscribe protocol for Jabber.</abstract>
<abstract>A publish-subscribe protocol for Jabber.</abstract>
<legal>This document has been placed in the public domain.</legal>
<number>0024</number>
<status>Retracted</status>
@ -1129,4 +1129,4 @@ connect to the real component.
</section1>
</jep>
</xep>

12
xep-0025.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jabber HTTP Polling</title>
<abstract>This document defines a protocol that enables access to a Jabber server from behind firewalls which do not allow outgoing sockets on port 5222, via HTTP requests.</abstract>
@ -60,7 +60,7 @@
</revision>
</header>
<section1 topic="Introduction">
<p><em>Note Well: This protocol specified in this document has been superseded by the protocol specified in &jep0124;.</em></p>
<p><em>Note Well: This protocol specified in this document has been superseded by the protocol specified in &xep0124;.</em></p>
<p>
This specification documents a method to allow Jabber clients to access Jabber
servers from behind existing firewalls. Although several similar methods
@ -383,4 +383,4 @@ Host: webim.jabber.com
<li>This method works over HTTPS, which is good from the standpoint of functionality, but bad in the sense that a massive amount of hardware would be needed to support reasonable polling intervals for non-trivial numbers of clients.</li>
</ul>
</section1>
</jep>
</xep>

14
xep-0026.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Internationalization (I18N)</title>
<abstract>NOTE WELL: this JEP was retracted on 2003-11-05 since the topic is addressed definitively in XMPP Core. Please refer to XMPP Core for further information.</abstract>
@ -65,7 +65,7 @@
Some examples on how this information could and should be used, include
</p>
<ul>
<li>Forms (e.g. for registration or searching, refer also to <link url="http://foundation.jabber.org/jeps/jep-0004.html">JEP-0004</link>) can be localized, so that instructions and field labels are in the native language of the person who has to fill them out</li>
<li>Forms (e.g. for registration or searching, refer also to &xep0004;) can be localized, so that instructions and field labels are in the native language of the person who has to fill them out</li>
<li>Even if the form can't be sent in the proper language (e.g. simply because it hasn't yet been translated), the component still should tag its reply with the language being used</li>
<li>Incoming messages in a different language could be automatically translated (server-side or client-side)</li>
<li>Redirection of messages based on their language (think of a help desk which services world wide requests)</li>
@ -137,7 +137,7 @@
<section2 topic='Service support'>
<p>
Jabber based services that wish to comply to this JEP have to make sure that all information they send to clients is tagged with an xml:lang attribute corresponding to the language used in the outgoing data, if appropriate, even if the component supports no other localizations. An example for this is a search form based on <link url="http://foundation.jabber.org/jeps/jep-0004.html">JEP-0004</link>.
Jabber based services that wish to comply to this JEP have to make sure that all information they send to clients is tagged with an xml:lang attribute corresponding to the language used in the outgoing data, if appropriate, even if the component supports no other localizations. An example for this is a search form based on <cite>JEP-0004</cite>.
</p>
<example caption='Search form in English'>
&lt;iq from='users.jabber.org' type='result' id='4' xml:lang='en'&gt;
@ -206,4 +206,4 @@
</section2>
</section1>
</jep>
</xep>

24
xep-0027.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Current Jabber OpenPGP Usage</title>
<abstract>This document outlines the current usage of OpenPGP for messaging and presence.</abstract>
@ -38,7 +38,7 @@
<version>1.1</version>
<date>2004-01-06</date>
<initials>psa</initials>
<remark>Added XML schemas; added security, IANA, and Jabber Registrar considerations.</remark>
<remark>Added XML schemas; added security, IANA, and XMPP Registrar considerations.</remark>
</revision>
<revision>
<version>1.0</version>
@ -60,7 +60,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The Jabber community has long acknowledged the need for privacy and security features in a well-rounded instant messaging system. Unfortunately, finding a consensus solution to the problem of end-to-end encryption during the community's younger days was not easy. Eventually, early contributors created a quick solution using OpenPGP. This specification documents the OpenPGP solution as it is used today, so that others may interoperate with clients that support it. This JEP is not intended to present a standard, because more complete solutions are being investigated.</p>
<p>The Jabber community has long acknowledged the need for privacy and security features in a well-rounded instant messaging system. Unfortunately, finding a consensus solution to the problem of end-to-end encryption during the community's younger days was not easy. Eventually, early contributors created a quick solution using OpenPGP. This specification documents the OpenPGP solution as it is used today, so that others may interoperate with clients that support it. This document is not intended to present a standard, because more complete solutions are being investigated.</p>
<p>All operations described here are done with standard OpenPGP software such as <link url='http://www.gnupg.org/'>GnuPG</link>. All program output is US-ASCII armored output with the headers removed. This allows for easy transportation of the program output directly in the XML. All keys are exchanged using OpenPGP key servers, and usually are retrieved when a signed &PRESENCE; stanza is received (key retrieval does not happen in-band).</p>
</section1>
<section1 topic='Signing' anchor='signing'>
@ -129,10 +129,10 @@
</ul>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<p>The &REGISTRAR; shall register the 'jabber:x:encrypted' and 'jabber:x:signed' namespaces as a result of this JEP.</p>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The &REGISTRAR; shall register the 'jabber:x:encrypted' and 'jabber:x:signed' namespaces as a result of this document.</p>
</section1>
<section1 topic='XML Schemas' anchor='schemas'>
<section2 topic='jabber:x:encrypted' anchor='schemas-encrypted'>
@ -148,7 +148,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0027: http://www.jabber.org/jeps/jep-0027.html
XEP-0027: http://www.xmpp.org/extenions/xep-0027.html
</xs:documentation>
</xs:annotation>
@ -170,7 +170,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0027: http://www.jabber.org/jeps/jep-0027.html
XEP-0027: http://www.xmpp.org/extenions/xep-0027.html
</xs:documentation>
</xs:annotation>
@ -180,4 +180,4 @@
]]></code>
</section2>
</section1>
</jep>
</xep>

14
xep-0028.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>No Such JEP</title>
<abstract>This JEP was removed from the JSF website and source control at the request of the author.</abstract>
<title>No Such XEP</title>
<abstract>This XEP was removed from the JSF website and source control at the request of the author.</abstract>
<number>0028</number>
</header>
</jep>
</xep>

10
xep-0029.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Definition of Jabber Identifiers (JIDs)</title>
<abstract>This document defines the exact nature of a Jabber Identifier (JID). <em>Note well: this document is superseded by the XMPP Core memo defined by the IETF's XMPP Working Group.</em></abstract>
@ -114,4 +114,4 @@
<p>Specifying limits in terms of bytes instead of characters is somewhat arbitrary once a lower bound for characters is established. This JEP proposes limits in terms of bytes mainly because doing so results in parsing efficiency; specifically, an implementation does not have to un-encode the UTF-8 string for the sole purpose of further restricting character sets that require fewer than four bytes per character point. It is sufficient to have a lower bound on characters and an upper bound on bytes.</p>
</section2>
</section1>
</jep>
</xep>