moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-08-13 16:53:48 -04:00
Code Issues Releases Wiki Activity

XSF/SIG cleanup

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@320 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-01-15 03:38:19 +00:00
parent 8fc5fedf05
commit 29bee13867
205 changed files with 451 additions and 436 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
xep-0001.xml
View File

@ -7,12 +7,12 @@
<xep>
<header>
<title>XMPP Extension Protocols</title>
<abstract>This document defines the standards process followed by the Jabber Software Foundation.</abstract>
<abstract>This document defines the standards process followed by the XMPP Standards Foundation.</abstract>
&LEGALNOTICE;
<number>0001</number>
<status>Active</status>
<type>Procedural</type>
<jig>None</jig>
<sig>None</sig>
<approver>Board</approver>
<dependencies/>
<supersedes/>
@ -29,7 +29,7 @@
<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>
<remark><p>As approved by the members of the XMPP Standards Foundation, changed Jabber Enhancement Proposal to XMPP Extension Protocol.</p></remark>
</revision>
<revision>
<version>1.16</version>
@ -47,7 +47,7 @@
<version>1.14</version>
<date>2004-09-28</date>
<initials>psa</initials>
<remark><p>Defined Procedural type as the union of JIG Formation type and certain Informational specifications in order to clarify the categories; added Modifications to Approved Specifications section in order to make explicit existing Council practices regarding Active and Final specifications; specified that documents on which voting was not complete at the end of a Council term shall undergo a second Last Call and subsequent vote by the new Council; modified Proposal Process to specify that the Jabber Council shall issue Last Calls on documents for which it is the approving body, with all discussion to occur on the Standards-JIG list; updated the schema.</p></remark>
<remark><p>Defined Procedural type as the union of SIG Formation type and certain Informational specifications in order to clarify the categories; added Modifications to Approved Specifications section in order to make explicit existing Council practices regarding Active and Final specifications; specified that documents on which voting was not complete at the end of a Council term shall undergo a second Last Call and subsequent vote by the new Council; modified Proposal Process to specify that the Jabber Council shall issue Last Calls on documents for which it is the approving body, with all discussion to occur on the Standards list; updated the schema.</p></remark>
</revision>
<revision>
<version>1.13</version>
@ -89,13 +89,13 @@
<version>1.6</version>
<date>2003-01-08</date>
<initials>psa</initials>
<remark><p>Further clarified the proposal process per discussion on the JSF members list.</p></remark>
<remark><p>Further clarified the proposal process per discussion on the members list.</p></remark>
</revision>
<revision>
<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 specification (e.g., version 1.3 when proceeding from Draft to Final); (4) added information about the "Call for Experience" phase before proceeding from Draft to Final; (5) added reference to RFC 2119; (6) added sections for security considerations, IANA considerations, and XMPP Registrar considerations. Approved by the JSF Board and Jabber Council on 2002-11-20.</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 XSF members before being proposed for a Council vote; (3) clarification that the Council votes only on a particular revision of a specification (e.g., version 1.3 when proceeding from Draft to Final); (4) added information about the "Call for Experience" phase before proceeding from Draft to Final; (5) added reference to RFC 2119; (6) added sections for security considerations, IANA considerations, and XMPP Registrar considerations. Approved by the XSF Board and Jabber Council on 2002-11-20.</p></remark>
</revision>
<revision>
<version>1.4</version>
@ -125,7 +125,7 @@
<version>1.1</version>
<date>2001-09-09</date>
<initials>psa</initials>
<remark><p>(1) Changed "Jabber Foundation" to "Jabber Software Foundation"; (2) Changed "JIG Proposal" to "JIG Formation"; (3) Removed reference to the Secretary of the Jabber Software Foundation in connection with the role of Editor; (4) Clarified the possible states of acceptance of each kind of specification and described in greater detail the criteria for advancement from one state to another.</p></remark>
<remark><p>(1) Changed "Jabber Foundation" to "XMPP Standards Foundation"; (2) Changed "SIG Proposal" to "SIG Formation"; (3) Removed reference to the Secretary of the XMPP Standards Foundation in connection with the role of Editor; (4) Clarified the possible states of acceptance of each kind of specification and described in greater detail the criteria for advancement from one state to another.</p></remark>
</revision>
<revision>
<version>1.0</version>
@ -141,10 +141,10 @@
</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 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>
<p>The &XSF; adheres to an open standards process that enables interested parties to document existing protocols used within the Jabber/XMPP developer community and to submit proposals that define new protocols; with a few exceptions, <note>Effectively the only such exceptions are protocols that were superseded by <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</note> such protocols can be considered extensions to the Extensible Messaging and Presence Protocol (XMPP) approved by the &IETF; in &xmppcore; and &xmppim;. Advancement through the XSF's standards process is subject to open discussion on public discussion lists and approval by a technical steering committee elected by the members of the XSF. The focal point of the process is a series of protocol specifications called XMPP Extension Protocols or XEPs. <note>The JEP (now XEP) concept as exemplified in version 1.0 of this document (approved in July of 2001) was borrowed from the Python community (see <link url="http://python.sourceforge.net/peps/pep-0001.html">PEP-1</link>). Subsequent revisions have been based on the Jabber/XMPP developer community's experience with this standards process, as well as insights gleaned from the standards processes followed by the IETF (&rfc2026;), the &W3C; (&w3process;), and other standards development organizations.</note> The nature of XMPP Extension Protocols and the mechanisms for managing and advancing them within the XMPP Standards Foundation's standards process are canonically described in the current document, which represents the first document in the XEP series. <note>The term "XEP" is normally pronounced "zepp".</note></p>
</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>
<p>The XMPP Standards Foundation was founded in the year 2001 to openly document, safeguard, manage, and extend the wire protocols used within the Jabber/XMPP developer community. The work of the XMPP Standards Foundation has several objectives:</p>
<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 XMPP extensions in a clear, concise manner so that the task of implementing the protocols is straightforward.</li>
@ -162,7 +162,7 @@
<p>A <span class='ref'>Standards Track XEP</span> defines one of the following:</p>
<ol>
<li>A wire protocol intended to be used as a standard part of Jabber/XMPP technologies.
<note>Note well that a protocol defined in a Standards Track XEP is not considered a full standard of the 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>
<note>Note well that a protocol defined in a Standards Track XEP is not considered a full standard of the XMPP Standards Foundation until it achieves a status of Final within the standards process defined herein (a Standards Track XEP that has achieved a status of Draft may be referred to as a Draft Standard; a Standards Track XEP that has a status of Experimental must not be referred to as a standard, but instead should be referred to as a work in progress).</note>
</li>
<li>A protocol suite that determines conformance requirements (e.g., &xep0073;).</li>
</ol>
@ -175,34 +175,34 @@
</ol>
</section2>
<section2 topic='Historical' anchor='types-Historical'>
<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>
<p>An <span class='ref'>Historical XEP</span> documents a protocol that was developed before the XSF's standards process was instituted, but that is still in use within the Jabber/XMPP developer community; such a XEP may or may not be obsoleted by a Standards Track XEP, or upgraded to Standards Track.</p>
</section2>
<section2 topic='Humorous' anchor='types-Humorous'>
<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 XEP</span> defines a process or activity to be followed by the JSF, including JIG charters as specified by &xep0002;.</p>
<p>A <span class='ref'>Procedural XEP</span> defines a process or activity to be followed by the XSF, including SIG 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 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>
<p>The XSF welcomes and encourages the submission of protocols to the XSF's standards process. <note>It is important to understand that private extensions to XMPP are also allowed. The XSF does not, and cannot, require such private extensions to be added to the public, official set of protocols recognized by the XSF. The processes and procedures in this document apply only to protocols that are submitted to the XSF, not to private protocol extensions used for custom functionality in particular applications. However, such private extensions must not be considered part of the protocols recognized by the XSF.</note> Any individual or group of individuals may author a proposal and submit it to the XSF for consideration as a XEP, and there is no requirement that a XEP author shall be an elected member of the XSF. However, proposals to define official XSF protocols must be presented in the XEP format and must follow the rules defined herein. The authoring and submission process is defined in &xep0143; (see also &lt;<link url="http://www.xmpp.org/extensions/submit.shtml">http://www.xmpp.org/extensions/submit.shtml</link>&gt;). All inquiries related to the XSF's standards process, and all submissions, should be directed to the &EDITOR;.</p>
<p>Note well that XEP authors must transfer ownership of their protocols (but not implementations thereof) to the XSF. Refer to the &XSFIPR; for details. XEP authors must make sure that they have read, understood, and agreed to the XSF IPR Policy before submitting a proposal to the XMPP Extensions Editor!</p>
<p>All proposals submitted to the XSF for consideration as XEPs must contain the following information:</p>
<ol start='1'>
<li><p>Legal Notice -- the legal notice must be exactly that which is specified in the JSF IPR Policy</p></li>
<li><p>Legal Notice -- the legal notice must be exactly that which is specified in the XSF 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 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 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>
<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 XSF Board of Directors and which may be accepted for publication by the XMPP Extensions Editor in consultation with the Board). Upon receiving a proposal, the XMPP Extensions Editor shall do the following:</p>
<ul>
<li>ensure that its format is correct</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>publicly announce its existence by sending a message to the discussion list of the &SSIG;</li>
<li>request acceptance of the proposal as a XEP by the XMPP Council</li>
</ul>
<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 no member of the XMPP Council objects to publication of the proposal within seven (7) days or at the next meeting of the Council, the XMPP Extensions Editor shall accept it as a XEP. If objections are raised by the Council on the Standards list or in its meeting, the XEP author is encouraged to address the feedback of the Council and to submit a revised version of the proposal and/or confer with the XMPP Extensions Editor or objecting Council member(s) regarding how to proceed.</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>
@ -211,25 +211,25 @@
<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>
<li>publicly announce the existence of the XEP by sending a message to the Standards list</li>
</ul>
<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>
<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 XSF, the XMPP Council, or the Jabber/XMPP developer community. Implementation of Experimental XEPs is encouraged in an exploratory fashion (e.g., in a proof of concept) in order to gain experience with and iteratively improve the protocol defined therein, but such implementations may not be appropriate for deployment in production systems.</p>
</section1>
<section1 topic='Discussion Process' anchor='discussion'>
<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>Once a XEP is published, it becomes available for public discussion within the Standards SIG and the broader Jabber/XMPP developer community. The XEP author is responsible for collecting feedback from the Jabber/XMPP developer community during the life of the XEP and for incorporating such feedback into the proposal. In order to fully participate in discussion of the proposal, the XEP author should be subscribed to the Standards list, which is the primary venue for discussion of XMPP Extension Protocols. Changes made based on feedback received by the XEP author must be captured in updated versions of the XEP (e.g., 0.2 after 0.1), each of which must be put under source control and subsequently published and announced by the XMPP Extensions Editor.</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 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>
<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 list. The Last Call shall expire not less than 10 days after the date of issue.</p>
<p>Once the consensus of the Standards SIG has been incorporated into the XEP and all issues of substance raised during the Last Call have been addressed by the XEP author, the XMPP Extensions Editor shall formally propose a specific revision of the XEP to the XMPP Council for its vote. If necessary, the XMPP Extensions Editor may, at his discretion and in consultation with the XMPP Council, extend the Last Call or issue a new Last Call if the XEP requires further discussion.</p>
<p>Last Calls regarding Procedural XEPs for which the approving body is the XSF Board of Directors may be issued directly by the XMPP Extensions Editor once instructed by the Board.</p>
</section1>
<section1 topic='Approval Process' anchor='approval'>
<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>If the XMPP Council does not complete voting on a XEP before the end of its term, the XMPP Extensions Editor shall issue a new Last Call on the Standards list and the newly-elected Council shall vote anew on the XEP after completion of the Last Call. This provides an opportunity for any member of the previous Council who had voted -1 to voice his or her concerns in a public forum before the new Council votes on the XEP.</p>
<p>A vote of the XMPP Council applies only to the specific revision of the XEP that has been presented to it. Further revisions may need to be re-submitted for approval.</p>
<p>Any change in the status of a XEP must be announced on the Standards-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>Any change in the status of a XEP must be announced on the Standards list by the XMPP Extensions Editor. If a XEP advances to a status of Final, it shall be so announced and also published as one of the official XSF protocols <note>A list of official XSF protocols is maintained at &lt;<link url='http://www.xmpp.org/protocol/'>http://www.xmpp.org/protocol</link>&gt;.</note> on the website of the XMPP Standards Foundation.</p>
<p>Approval of Procedural XEPs for which the approving body is the XSF Board of Directors shall occur upon approval by the Board in accordance with the rules defined in the &BYLAWS;.</p>
<p>More detailed information about the approval process is provided below, including criteria for Standards Track XEPs and for Historical, Informational, and Procedural XEPs.</p>
<section2 topic='Standards Track XEPs' anchor='approval-std'>
<p>The possible states for a Standards Track XEP are as follows:</p>
@ -248,21 +248,21 @@ Experimental ----> Proposed ----> Draft ----> Final
</code>
<p>After an XMPP Extension Protocol has been accepted for publication by the XMPP Council and before it is proposed for advancement to a status of Draft (or retracted or deferred), it shall have a status of Experimental. Publication as an Experimental does not indicate approval of the protocol by the XMPP Council or the broader XMPP community.</p>
<p><em>Note: An Experimental specification is a work in progress and may undergo significant modification before advancing to a status of Draft. While implementation of an Experimental protocol is encouraged in order to determine the feasibility of the proposed solution, it is not recommended for such implementations to be included in the primary release for a software product (as opposed to an experimental branch).</em></p>
<p>The ideal path is for a Standards Track XEP is to be advanced by the XMPP Council from Proposed to Draft to Final (the criteria for this advancement are described in the following paragraphs). However, an Experimental XEP shall be assigned a status of Deferred if it has not been updated in six (6) months (e.g., because of a lack of interest or because it depends on other specifications that have yet to move forward). In addition, rather than being advanced from Proposed to Draft, a Standards Track XEP may be voted to a status of Rejected if the XMPP Council deems it unacceptable. (Note that if a XEP is Deferred, the XMPP Extensions Editor may at some point re-assign it to Experimental status, and that, even if a XEP is Rejected, it is retained in source control and on the 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>The ideal path is for a Standards Track XEP is to be advanced by the XMPP Council from Proposed to Draft to Final (the criteria for this advancement are described in the following paragraphs). However, an Experimental XEP shall be assigned a status of Deferred if it has not been updated in six (6) months (e.g., because of a lack of interest or because it depends on other specifications that have yet to move forward). In addition, rather than being advanced from Proposed to Draft, a Standards Track XEP may be voted to a status of Rejected if the XMPP Council deems it unacceptable. (Note that if a XEP is Deferred, the XMPP Extensions Editor may at some point re-assign it to Experimental status, and that, even if a XEP is Rejected, it is retained in source control and on the XMPP Standards Foundation website for future reference.) Finally, a XEP author may voluntarily remove an Experimental XEP from further consideration, resulting in a status of Retracted.</p>
<p>In order for a Standards Track XEP to advance from Proposed to Draft, it must:</p>
<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>
<li>document any known security considerations with the proposed technology</li>
<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>have achieved rough consensus (though not necessarily unanimity) within the Standards SIG</li>
<li>be formally defined by an XML schema</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 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.</p>
<p><em>Note: Once an XMPP Extension Protocol has been advanced to a status of Draft, it is expected that the specification will be basis for widespread implementation and for deployment in production environments. As a result of such implementation and deployment experience, the protocol may be subject to modification, including changes that are backwards-incompatible. Although such backwards-incompatible modifications shall be avoided if at all possible, deployment of a Draft protocol in mission-critical application may not be advisable.</em></p>
<p>Any proposed 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 and discussed on the Standards-JIG mailing list, and formally approved by the XMPP Council before being officially published at the canonical URL for the XEP.</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>Any proposed 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 and discussed on the Standards mailing list, and formally approved by the XMPP Council before being officially published at the canonical URL for the XEP.</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 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><em>Note: Once an XMPP Extension Protocol has been advanced to a status of Final, every effort shall be made to limit the scope of modifications; in particular, backwards-incompatible changes shall not be made. However, limited modifications may be made as long as they are optional, backwards-compatible extensions rather than modifications to the core protocol itself. Therefore, a Final protocol is safe for deployment in mission-critical applications.</em></p>
<p>A Standards Track XEP that has been advanced to a status of Final may be superseded by a future XEP approved by the XMPP Council. In such cases, the status of the earlier XEP shall be changed to Deprecated, possibly with an expiration date assigned by the XMPP Council (see the <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>
@ -289,14 +289,14 @@ Experimental ----> Proposed ----> Active
<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 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>
<p>A XEP of any type is in the Experimental state after it has been accepted by the XMPP Council and published by the XMPP Standards Foundation but before it has advanced within the standards process to a state of Active or Draft.</p>
<p><em>Note: An Experimental specification is a work in progress and may undergo significant modification before advancing to a status of Draft. While implementation of an Experimental protocol is encouraged in order to determine the feasibility of the proposed solution, it is not recommended for such implementations to be included in the primary release for a software product (as opposed to an experimental branch).</em></p>
</section2>
<section2 topic='Proposed' anchor='states-Proposed'>
<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 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>
<p>A Standards Track XEP is in the Draft state after it has undergone extensive discussion and technical review on the Standards list and has been voted forward on the standards track by the XMPP Council.</p>
<p><em>Note: Once an XMPP Extension Protocol has been advanced to a status of Draft, it is expected that the specification will be basis for widespread implementation and for deployment in production environments. As a result of such implementation and deployment experience, the protocol may be subject to modification, including changes that are backwards-incompatible. Although such backwards-incompatible modifications shall be avoided if at all possible, deployment of a Draft protocol in mission-critical application may not be advisable.</em></p>
</section2>
<section2 topic='Final' anchor='states-Final'>
@ -310,7 +310,7 @@ Experimental ----> Proposed ----> Active
<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 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>
<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 XSF's standards process.</p>
</section2>
<section2 topic='Rejected' anchor='states-Rejected'>
<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>
@ -323,10 +323,10 @@ Experimental ----> Proposed ----> Active
</section2>
</section1>
<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>Sometimes it is necessary to modify XEPs that have received final approval by the XMPP Council or XSF Board of Directors (e.g., to correct errors, incorporate the lessons of experience, or document new security concerns). This section describes the process for doing so with regard to Standards Track XEPs that have achieved a status of Final and Historical, Informational, and Procedural XEPs that have achieved a status of Active.</p>
<p>With regard to Standards Track XEPs, the XMPP Standards Foundation (in particular, the XMPP Council) strives to ensure that such XEPs are accurate, complete, and stable before advancing them to a status of Final (corresponding to document version 2.0 of the XEP). The Call for Experience and discussion within the Standards SIG help to ensure this result, but final responsibility rests with the XMPP Council. Despite the best efforts of all concerned, errors are sometimes discovered in Final XEPs (the individual who discovers such an error should inform the Council via the Standards mailing list or communicate directly with the XMPP Extensions Editor). Whereas other standards development organizations may issue errata while leaving the specification itself unchanged, the XSF makes changes to the Final XEP and publishes a revised document version (e.g., version 2.1). In general the changes are made by the XMPP Extensions Editor or XEP author in consultation with the XMPP Council, discussed within the Standards SIG if appropriate, and agreed upon by the full XMPP Council. Upon agreement regarding the exact changes, the XMPP Council shall instruct the XMPP Extensions Editor to publish a revised version of the XEP and announce the existence of the revised version through the normal channels (e.g., on the XSF website and to the Standards list). Naturally, if members of the Jabber/XMPP developer community have concerns regarding the changes made, they are free to discuss the matter in the relevant forum (usually the Standards list) before or after the revised version has been published.</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>
<p>Procedural XEPs may be modified more frequently as the XMPP Standards Foundation gains experience with the processes defined therein. For example, XEP-0001 is modified periodically in order to document processes previously not made explicit or to modify existing processes based on experience with the XSF's standards process; similar changes are sometimes made to the &xep0053; XEP and to various SIG-related XEPs. Changes to these XEPs are discussed by the XMPP Council, XSF Board of Directors, XSF membership, and Standards SIG as appropriate, and exact changes are agreed to by the relevant approving body (XMPP Council or XSF Board of Directors). The approving body then instructs the XMPP Extensions Editor to publish and announce the revised version as described above.</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 XEP may be approved provisionally and be assigned an expiration date.</p>
@ -345,7 +345,7 @@ Experimental ----> Proposed ----> Active
<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>XMPP Extension Protocol specifications that define official JSF protocols must include a schema that conforms to &w3xmlschema1; and &w3xmlschema2;.</p>
<p>XMPP Extension Protocol specifications that define official XSF 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'?>
@ -388,7 +388,7 @@ Experimental ----> Proposed ----> Active
<xs:element name='number' type='xs:byte'/>
<xs:element ref='status'/>
<xs:element ref='type'/>
<xs:element name='jig' type='xs:string'/>
<xs:element name='sig' type='xs:string'/>
<xs:element name='approver' type='xs:string'/>
<xs:element ref='dependencies'/>
<xs:element ref='supersedes'/>

14
xep-0002.xml
View File

@ -6,13 +6,13 @@
<?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>
<title>Special Interest Groups (SIGs)</title>
<abstract>A definition of Special Interest Groups within the XMPP Standards Foundation.</abstract>
&LEGALNOTICE;
<number>0002</number>
<status>Active</status>
<type>Procedural</type>
<jig>None</jig>
<sig>None</sig>
<approver>Board</approver>
<dependencies/>
<supersedes/>
@ -32,11 +32,11 @@
</revision>
</header>
<section1 topic='Short Definition'>
<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>
<p>A Special Interest Group (SIG) is a working group approved by the XMPP Council to address specific areas of growth or concern within the Jabber/XMPP developer community, usually by means of developing and publishing XMPP Extension Protocols (XEPs).</p>
</section1>
<section1 topic='Explanation'>
<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 specifications for review by the XMPP Council in the JIG's area of focus. However, if a JIG does not show signs of activity for an extended period of time (usually six months of inactivity on the JIG's mailing list), the JIG may be disbanded at the discretion of the XMPP Council with appropriate warning to the JIG members (usually in the form of an email sent to the JIG's mailing list).</p>
<p>The main function of most SIGs 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 SIGs may be approved (e.g., to address security or standards compliance).</p>
<p>Anyone (not limited to members of the XMPP Standards Foundation) may propose the formation of a SIG by completing a XMPP Extension Protocol outlining the need for the SIG and its proposed focus. However, SIG leaders must be members of the XMPP Standards Foundation. The number of leaders for a SIG is flexible, and shall be determined by each SIG, in consultation with the XMPP Council if necessary. The concept of "membership" with regard to SIGs is loose, and is essentially co-extensive with membership in the appropriate mailing list (each SIG has its own mailing list, which is archived for public review). SIG members do not need to be members of the XMPP Standards Foundation, and any member of the general public may subscribe to SIG mailing lists.</p>
<p>It is expected that all SIGs (other than certain standing SIGs) will remain active for as long as necessary in order to produce one or more standards-track specifications for review by the XMPP Council in the SIG's area of focus. However, if a SIG does not show signs of activity for an extended period of time (usually six months of inactivity on the SIG's mailing list), the SIG may be disbanded at the discretion of the XMPP Council with appropriate warning to the SIG members (usually in the form of an email sent to the SIG's mailing list).</p>
</section1>
</xep>

2
xep-0003.xml
View File

@ -12,7 +12,7 @@
<number>0003</number>
<status>Active</status>
<type>Historical</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>

6
xep-0004.xml
View File

@ -12,7 +12,7 @@
<number>0004</number>
<status>Final</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
@ -91,7 +91,7 @@
<version>0.6</version>
<date>2002-03-15</date>
<initials>rwe</initials>
<remark>Protocol tweaks based on standards-jig discussion.</remark>
<remark>Protocol tweaks based on Standards list discussion.</remark>
</revision>
<revision>
<version>0.5</version>
@ -577,7 +577,7 @@
<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 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>
<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 &FORMTYPES;.</p>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>

2
xep-0005.xml
View File

@ -12,7 +12,7 @@
<number>0005</number>
<status>Obsolete</status>
<type>Informational</type>
<jig>None</jig>
<sig>None</sig>
<author>
<firstname>Jeremie</firstname>
<surname>Miller</surname>

16
xep-0006.xml
View File

@ -11,8 +11,8 @@
&LEGALNOTICE;
<number>0006</number>
<status>Obsolete</status>
<type>JIG Formation</type>
<jig>Forms, Security</jig>
<type>SIG Formation</type>
<sig>Forms, Security</sig>
<author>
<firstname>Adam</firstname>
<surname>Theo</surname>
@ -66,7 +66,7 @@
</section2>
<section2 topic='Storage'>
<p>Storage is describing and accessing the physical location where the Profiles are kept. It will likely start off being only the Jabber Server, but will eventually allow for remote (specialized network hard drive services) and local (on the User's local machine or a portable floppy) storage. It also describes how this data will be transferred between computers and networks in an efficient and secure manner.</p>
<p>This will likely be the most other-JIG dependent part of the system, since we will have to make heavy use of encryption in Jabber, and likely file transfers. So we may want to help out those related JIGs when we get to this point to make sure their results can be used by this system.</p>
<p>This will likely be the most other-SIG dependent part of the system, since we will have to make heavy use of encryption in Jabber, and likely file transfers. So we may want to help out those related SIGs when we get to this point to make sure their results can be used by this system.</p>
</section2>
<section2 topic='Gate'>
<p>Gate gives the User complete control at all times of others' access to and power over their Profiles. Since this system is designed to hold the bulk, if not all, of a User's personal information, they *must* have a powerful way to prevent unwanted others to access their data. So there must exist a powerful access regulation framework to precisely control which, when, and how other parties can get this information.</p>
@ -75,22 +75,22 @@
</section1>
<section1 topic='Road-map'>
<p>To make sure this project progresses smoothly and orderly, it has been decided it will be split up into steps, or 'Phases'. Each of the above four aspects will be split into two to four Phases, and the Road-map for the entire project will follow along these Phases. Version 1.0 of the Profiles system will be little more than an expanded vCard schema with simple rules and permissions to regulate access to it. It will progress up to Version 4.0 or 5.0, adding in advanced verification to persuade Services to use a User's Jabber Profiles instead of forcing them to set up a local account, and also adding write permissions so Services can set receipts of purchases and similar information in a User's Account.</p>
<p>This Road-map will be produced soon after the JIG is set up, and will give a good feature list and time-line to follow.</p>
<p>This Road-map will be produced soon after the SIG is set up, and will give a good feature list and time-line to follow.</p>
</section1>
<section1 topic='Benefits'>
<p>Such an improved system would obviously provide for more types of information storage and management, but there are some other side-benefits that can be conceived of.</p>
<ul>
<li>Since the User will have all personal information in their one account, and Services can retrieve this information with permission, this could mean no more having to fill out forms, especially account sign-up forms with Services. The information can be automatically retrieved and filled in for you. This is similar to client-side form-filler applications, except it can be used from any computer, no matter what software it has installed on it.</li>
<li>With write permission allowed to Services by the User, the Service can store their own Profiles about you in your Jabber Account. Information such as your Amazon wish list, receipts of purchases, calendar events, etc. This is similar to what Services do now, except you have control over where and how this information is physically stored and accessed.</li>
<li>Also, with an advanced authentication system (which will be the focus of a future JIG), a Service could use your Jabber Account to verify you are who you say you are, instead of requiring you set up a new account just with them. This is often called 'Universal Accounts', and similar to Microsoft's Passport and AOL's new Magic Carpet services.</li>
<li>Also, with an advanced authentication system (which will be the focus of a future SIG), a Service could use your Jabber Account to verify you are who you say you are, instead of requiring you set up a new account just with them. This is often called 'Universal Accounts', and similar to Microsoft's Passport and AOL's new Magic Carpet services.</li>
<li>With cookies and other auto-detection methods allowed by the User, Services can automatically detect their JID from the web browser or other tool. This eliminates the step of the User having to type in their JID, and can make this system all the more seamless to them. Combined with the above universal account benefit, this is similar to single sign-on systems such as Microsoft's Passport or AOL's new Magic Carpet.</li>
</ul>
</section1>
<section1 topic='Conclusion'>
<p>Eventually we would like this Profiles specification to completely replace the strict vCard schema that is 'hard-coded' into the protocol. We do not expect vCard to disappear from Jabber at all, simply be one possible Profile among many in a User's Account. At the end of this JIGs existence, we would like to see it integrate the Profiles and special 'jabber:profiles' namespaces fully into the rest of the Jabber protocol, having it become the method by which all User information (such as Roster, client-side preferences, and filters) is stored and retrieved.</p>
<p>It is important to note that this JIG will not be a stand-alone JIG. It will draw upon many other JIGs (that currently exist and that have yet to be created). It will need encryption from the Security JIG for safe transfer of the information, a versatile forms format from the Forms JIG for Profiles administration, and advanced authentication from a future JIG for Services to authenticate the User against their Jabber account.</p>
<p>Eventually we would like this Profiles specification to completely replace the strict vCard schema that is 'hard-coded' into the protocol. We do not expect vCard to disappear from Jabber at all, simply be one possible Profile among many in a User's Account. At the end of this SIGs existence, we would like to see it integrate the Profiles and special 'jabber:profiles' namespaces fully into the rest of the Jabber protocol, having it become the method by which all User information (such as Roster, client-side preferences, and filters) is stored and retrieved.</p>
<p>It is important to note that this SIG will not be a stand-alone SIG. It will draw upon many other SIGs (that currently exist and that have yet to be created). It will need encryption from the Security SIG for safe transfer of the information, a versatile forms format from the Forms SIG for Profiles administration, and advanced authentication from a future SIG for Services to authenticate the User against their Jabber account.</p>
</section1>
<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 document 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>
<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 document 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 SIG that we have split the individual parts up, to make it easier to develop.</p>
</section1>
</xep>

10
xep-0007.xml
View File

@ -6,13 +6,13 @@
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Conferencing JIG</title>
<title>Conferencing SIG</title>
<abstract>A proposal for a Jabber Interest Group that will discuss the protocol for implementing many-to-many communications.</abstract>
&LEGALNOTICE;
<number>0007</number>
<status>Obsolete</status>
<type>JIG Proposal</type>
<jig>Conferencing</jig>
<type>SIG Proposal</type>
<sig>Conferencing</sig>
<author>
<firstname>David</firstname>
<surname>Waite</surname>
@ -36,7 +36,7 @@
<p>The following proposal is for the formation of a Jabber Interest Group that will create a new conferencing protocol, as well as create additional functionality and standardize communications on top of said conferencing protocol.</p>
</section1>
<section1 topic='Base conferencing protocol'>
<p>The initial task of the Conferencing JIG will be to propose a Jabber Conferencing specification that will solve various problems which exist in the current "groupchat" specification. This specification is meant to be a foundation for additional functionality; it defines the framework needed to provide additional features, without requiring changes to the framework specification itself. There is also to be a certain amount of feature-negotiation included; the conferencing service can define what features can be declared for a room, both as optional and required client features for room participation.</p>
<p>The initial task of the Conferencing SIG will be to propose a Jabber Conferencing specification that will solve various problems which exist in the current "groupchat" specification. This specification is meant to be a foundation for additional functionality; it defines the framework needed to provide additional features, without requiring changes to the framework specification itself. There is also to be a certain amount of feature-negotiation included; the conferencing service can define what features can be declared for a room, both as optional and required client features for room participation.</p>
<p>The framework's scope consists of the following minimum functionality:</p>
<ul>
<li>Browsing a list of public rooms</li>
@ -68,6 +68,6 @@
<p>Because of the prevalence of the existing "groupchat" specification for multi-user chats, a long conversion process is anticipated. A server implementation which supports both protocols will simply not allow "groupchat"-only clients to participate in rooms with required features.</p>
</section1>
<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>
<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 SIG will first be established to develop a framework, with features mainly being compared against the framework for feasibility of implementation. After a proposal has been formalized as a specification, the SIG will become a group for discussing and proposing new features, and for formally specifying those features.</p>
</section1>
</xep>

4
xep-0008.xml
View File

@ -12,7 +12,7 @@
<number>0008</number>
<status>Deferred</status>
<type>Historical</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
@ -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 document has been changed to Retracted, to be superseded by a forthcoming specification. This document 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.</remark>
</revision>
<revision>
<version>0.1</version>

2
xep-0009.xml
View File

@ -12,7 +12,7 @@
<number>0009</number>
<status>Final</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XML-RPC</spec>

14
xep-0010.xml
View File

@ -6,13 +6,13 @@
<?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>
<title>Whiteboarding SIG</title>
<abstract>A proposal to form a SIG to develop a protocol for whiteboarding over Jabber.</abstract>
&LEGALNOTICE;
<number>0010</number>
<status>Obsolete</status>
<type>JIG Formation</type>
<jig>None</jig>
<type>SIG Formation</type>
<sig>None</sig>
<author>
<firstname>Niklas</firstname>
<surname>Gustavsson</surname>
@ -35,15 +35,15 @@
<section1 topic='Introduction'>
<p>Jabber is often thought of simply as a system for instant messaging, albeit an open one. However, Jabber technology can be used, and is being used, in applications quite different from simple IM. One of these applications is whiteboarding. In collaborative work, the ability to draw (for example, to design sketches, UML schemas, house architectures, and organizational plans) is essential, as exemplified by the success of real-world whiteboarding applications such as Microsoft NetMeeting. Whiteboarding can also be used for entertainment purposes such as games and quizzes. Because of the value of whiteboarding as an important real-time collaboration tool, other IM services are beginning to offer these capabilities. For these and other reasons, I believe that a good protocol for whiteboarding in Jabber would be of great value.</p>
<p>There exists today a protocol draft for sending streaming XPM over Jabber <note>XPM over Jabber (<link url="http://docs.jabber.org/draft-proto/html/sxpm.html">http://docs.jabber.org/draft-proto/html/sxpm.html</link>)</note>. XPM is a bitmap format, which makes it well-suited for certain applications (e.g., smaller drawings and sketches). However, significant changes in an XPM image will require sending large amounts of XML data (even with the compression described in the protocol draft). Also, for example, XPM does not scale without loss of resolution, nor does it support metadata. In addition, the current draft specifies the data format only, not the way the data will be sent or handled by Jabber servers and clients.</p>
<p>Therefore, the Whiteboard JIG should develop a standard way of handling whiteboards in Jabber and a format for data transfer. This might be based on vector graphics, bitmap data, or a combination of these two. In addition, the protocol should work in the context of both regular messaging and conferencing. The protocol for whiteboarding during conferencing might depend on the new protocol proposal to come from the Conferencing JIG <note>Conferencing protocol draft (<link url="http://jabber.org/?oid=1538">http://jabber.org/?oid=1538</link>)</note>.</p>
<p>Therefore, the Whiteboard SIG should develop a standard way of handling whiteboards in Jabber and a format for data transfer. This might be based on vector graphics, bitmap data, or a combination of these two. In addition, the protocol should work in the context of both regular messaging and conferencing. The protocol for whiteboarding during conferencing might depend on the new protocol proposal to come from the Conferencing SIG <note>Conferencing protocol draft (<link url="http://jabber.org/?oid=1538">http://jabber.org/?oid=1538</link>)</note>.</p>
</section1>
<section1 topic='Deliverables'>
<p>The Whiteboarding JIG should produce the following deliverables (these deliverables will be presented to the Jabber Council):</p>
<p>The Whiteboarding SIG should produce the following deliverables (these deliverables will be presented to the Jabber Council):</p>
<section2 topic='Requirements'>
<p>A set of requirements that the proposed protocol should fulfill.</p>
</section2>
<section2 topic='Analysis of existing work'>
<p>There are today at least four different attempts <note>Distributed SVG documents (<link url="http://www.jabber.org/?oid=1025">http://www.jabber.org/?oid=1025</link>)</note> <note>SVG over Jabber (<link url="http://www.protocol7.com/jabber/whiteboard_proposal.txt">http://www.protocol7.com/jabber/whiteboard_proposal.txt</link>)</note> <note>Jabberzilla Whiteboard (<link url="http://jabberzilla.mozdev.org/">http://jabberzilla.mozdev.org/</link>)</note> to create a whiteboarding protocol in Jabber. The Whiteboarding JIG should evaluate them all and see which features of each are worth keeping.</p>
<p>There are today at least four different attempts <note>Distributed SVG documents (<link url="http://www.jabber.org/?oid=1025">http://www.jabber.org/?oid=1025</link>)</note> <note>SVG over Jabber (<link url="http://www.protocol7.com/jabber/whiteboard_proposal.txt">http://www.protocol7.com/jabber/whiteboard_proposal.txt</link>)</note> <note>Jabberzilla Whiteboard (<link url="http://jabberzilla.mozdev.org/">http://jabberzilla.mozdev.org/</link>)</note> to create a whiteboarding protocol in Jabber. The Whiteboarding SIG should evaluate them all and see which features of each are worth keeping.</p>
</section2>
<section2 topic='Graphics data format'>
<p>One or more data formats for the graphics data, presented both as a description and as a DTD or XML schema.</p>

2
xep-0011.xml
View File

@ -12,7 +12,7 @@
<number>0011</number>
<status>Deprecated</status>
<type>Historical</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>

2
xep-0012.xml
View File

@ -12,7 +12,7 @@
<number>0012</number>
<status>Active</status>
<type>Historical</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>

2
xep-0013.xml
View File

@ -12,7 +12,7 @@
<number>0013</number>
<status>Draft</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>

2
xep-0014.xml
View File

@ -12,7 +12,7 @@
<number>0014</number>
<status>Rejected</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<author>
<firstname>Mike</firstname>
<surname>Mintz</surname>

2
xep-0015.xml
View File

@ -12,7 +12,7 @@
<number>0015</number>
<status>Rejected</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<author>
<firstname>Casey</firstname>
<surname>Crabb</surname>

2
xep-0016.xml
View File

@ -12,7 +12,7 @@
<number>0016</number>
<status>Draft</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>

2
xep-0017.xml
View File

@ -12,7 +12,7 @@
<number>0017</number>
<status>Rejected</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<author>
<firstname>Mike</firstname>
<surname>Lin</surname>

2
xep-0018.xml
View File

@ -12,7 +12,7 @@
<number>0018</number>
<status>Rejected</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>XMPP Core, XMPP IM</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>

48
xep-0019.xml
View File

@ -6,13 +6,13 @@
<?xml-stylesheet type="text/xsl" href="xep.xsl"?>
<xep>
<header>
<title>Streamlining the JIGs</title>
<abstract>This document proposes to streamline the existing Jabber Interest Groups (JIGs).</abstract>
<title>Streamlining the SIGs</title>
<abstract>This document proposes to streamline the existing Special Interest Groups (SIGs).</abstract>
&LEGALNOTICE;
<number>0019</number>
<status>Active</status>
<type>Procedural</type>
<jig>None</jig>
<sig>None</sig>
<approver>Board</approver>
<dependencies/>
<supersedes/>
@ -38,39 +38,39 @@
</revision>
</header>
<section1 topic="Introduction">
<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 document, I argue that just such an adjustment is now necessary with regard to the Jabber Interest Groups (JIGs). <note>The proposal contained in this document 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>
<p>The XMPP Standards Foundation is a continuing experiment. When we initially set up our policies, processes, and structures, we knew that our initial thoughts might not be our final thoughts, and that we would need to make adjustments as experience dictated. In this document, I argue that just such an adjustment is now necessary with regard to the Special Interest Groups (SIGs). <note>The proposal contained in this document formalizes some conclusions reached during a weekly discussion forum held by the XMPP Standards 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 SIG has been helpful in clarifying the argument presented here.</note></p>
</section1>
<section1 topic="The Problem">
<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 within a reasonably limited period of time". In early January of 2002, XEP-0002 was modified to incorporate language about disbanding a JIG after a defined period of inactivity on the JIG's mailing list (normally six months).</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 XEP-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 specifications 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 specification for submission to the Jabber Council, and that specification (&xep0009;) was essentially created outside the JIG structure at JabberCon 2001. Perhaps most ominously, no other JIG has shown any signs of progress toward completing a specification, or even starting work on one. With the possible exception of XEP-0009, all of the specifications created so far have come from individuals or small, ad-hoc groups -- not through the efforts of the JIGs.</p>
<p>In other words, an honest assessment forces us to conclude that the JIGs are not working.</p>
<p>&xep0002; defined a SIG as "a working group approved by the XMPP Council to address specific areas of growth or concern within the Jabber community", and specified that the function of a SIG is to "produce acceptable enhancements to XMPP within a reasonably limited period of time". In early January of 2002, XEP-0002 was modified to incorporate language about disbanding a SIG after a defined period of inactivity on the SIG's mailing list (normally six months).</p>
<p>Unfortunately, it is widely recognized in our community that the SIGs are not working. Ten SIGs have been approved by the XMPP Council, eight of them over six months ago in July and August of 2001. Two of the special-purpose SIGs (OOB and Presence) have seen no activity whatsoever and thus are clearly eligible to be disbanded. The other special-purpose SIGs (Conference, Formatting, Forms, Profiles, RPC, and Whiteboard) have seen extremely limited activity and it is a judgment call whether some of them should be allowed to continue according to the current standards defined in XEP-0002. Only the two "standing" SIGs (Security and Standards) have experienced significant and continued mailing list activity, mainly because the Standards SIG has assumed the role of discussion forum for specifications before they are submitted to the XMPP Council.</p>
<p>In perhaps the best measure of success or failure, only one SIG has produced a specification for submission to the XMPP Council, and that specification (&xep0009;) was essentially created outside the SIG structure at JabberCon 2001. Perhaps most ominously, no other SIG has shown any signs of progress toward completing a specification, or even starting work on one. With the possible exception of XEP-0009, all of the specifications created so far have come from individuals or small, ad-hoc groups -- not through the efforts of the SIGs.</p>
<p>In other words, an honest assessment forces us to conclude that the SIGs are not working.</p>
</section1>
<section1 topic="Analysis and Possible Solutions">
<p>I see several possible solutions to the JIG problem:</p>
<p>I see several possible solutions to the SIG problem:</p>
<ol>
<li>"Crack the whip" -- encourage and cajole the existing JIGs into becoming more active, and energetically manage them so that they produce specifications.</li>
<li>"Wait and see" -- immediately disband the JIGs that are clearly inactive but keep the existing JIGs and hope that they will eventually produce something of value (over time disbanding any that are conspicuously inactive).</li>
<li>"Bite the bullet" -- recognize that, for whatever reason, the existing structure (many special-purpose interest groups) is not working and seek a better way to produce enhancements to the Jabber protocols.</li>
<li>"Crack the whip" -- encourage and cajole the existing SIGs into becoming more active, and energetically manage them so that they produce specifications.</li>
<li>"Wait and see" -- immediately disband the SIGs that are clearly inactive but keep the existing SIGs and hope that they will eventually produce something of value (over time disbanding any that are conspicuously inactive).</li>
<li>"Bite the bullet" -- recognize that, for whatever reason, the existing structure (many special-purpose interest groups) is not working and seek a better way to produce enhancements to XMPP.</li>
</ol>
<p>Given the lack of activity in the JIGs so far (and the lack of time available to those who would manage them), I am skeptical that "cracking the whip" will produce results, and I believe the onus of proof is on those who would argue that the existing JIGs can be successful. Similarly, taking a "wait and see" attitude will simply let a bad situation continue unchecked, and in my opinion will at some point require us to choose between option 1 and option 3. Rather than postpone the day of reckoning, I argue that we need to address the problem head-on and take action to streamline the JIGs and find a better way of working.</p>
<p>But what is that "better way"? In order to figure that out, we need to understand why things are not working now. I don't think it's that the current JIG members are lazy, stupid, or incompetent -- after all, these are the same people who have in many instances created good Jabber-based software. Nor do I think it's that members of the Jabber community are incapable of creating specifications, because individually and in small, ad-hoc groups they have created quite a few.</p>
<p>I see several reasons why the JIGs are not working:</p>
<p>Given the lack of activity in the SIGs so far (and the lack of time available to those who would manage them), I am skeptical that "cracking the whip" will produce results, and I believe the onus of proof is on those who would argue that the existing SIGs can be successful. Similarly, taking a "wait and see" attitude will simply let a bad situation continue unchecked, and in my opinion will at some point require us to choose between option 1 and option 3. Rather than postpone the day of reckoning, I argue that we need to address the problem head-on and take action to streamline the SIGs and find a better way of working.</p>
<p>But what is that "better way"? In order to figure that out, we need to understand why things are not working now. I don't think it's that the current SIG members are lazy, stupid, or incompetent -- after all, these are the same people who have in many instances created good XMPP-based software. Nor do I think it's that members of the XMPP community are incapable of creating specifications, because individually and in small, ad-hoc groups they have created quite a few.</p>
<p>I see several reasons why the SIGs are not working:</p>
<ol>
<li>The Jabber community right now is too small to be split up successfully into smaller interest groups.</li>
<li>We have tried to overlay too much structure too quickly. Jabber has traditionally been a fairly anarchic project (or set of projects), and creating ten JIGs right away was at odds with that successful lack of structure.</li>
<li>Good specifications, like good software programs, are usually created by at most a few interested people, not a formal group. Formal groups are not needed to move Jabber forward.</li>
<li>The XMPP community right now is too small to be split up successfully into smaller interest groups.</li>
<li>We have tried to overlay too much structure too quickly. The Jabber/XMPP community has traditionally been a fairly anarchic project (or set of projects), and creating ten SIGs right away was at odds with that successful lack of structure.</li>
<li>Good specifications, like good software programs, are usually created by at most a few interested people, not a formal group. Formal groups are not needed to move Jabber/XMPP technologies forward.</li>
</ol>
<p>If we reflect on what is working, we see that specifications are being produced by individuals and small, ad-hoc groups. We also see that active discussion of those proposals is taking place in the Standards JIG, which contains everyone who is strongly interested in the Jabber protocols. Finally, we notice that the special-purpose JIGs have not played any appreciable role in our success so far.</p>
<p>If we reflect on what is working, we see that specifications are being produced by individuals and small, ad-hoc groups. We also see that active discussion of those proposals is taking place in the Standards SIG, which contains everyone who is strongly interested in XMPP. Finally, we notice that the special-purpose SIGs have not played any appreciable role in our success so far.</p>
</section1>
<section1 topic="Proposed Solution">
<p>My proposed solution takes into account everything we have learned to date about producing specifications and advancing the state of the Jabber protocols. Specifically, I propose that we take the following steps:</p>
<p>My proposed solution takes into account everything we have learned to date about producing specifications and advancing the state of XMPP. Specifically, I propose that we take the following steps:</p>
<ol>
<li>Immediately disband all but the Standards JIG. <note>In an earlier version of this document, I proposed that we retain the Security JIG. However, since there is a security aspect to all protocols, I now think it is best if security-related topics are discussed within the Standards JIG, not in a separate Security JIG.</note></li>
<li>Immediately disband all but the Standards SIG. <note>In an earlier version of this document, I proposed that we retain the Security SIG. However, since there is a security aspect to all protocols, I now think it is best if security-related topics are discussed within the Standards SIG, not in a separate Security SIG.</note></li>
<li>Rely on individuals and small, ad-hoc groups to create specifications.</li>
<li>Continue to use the Standards JIG as the preferred forum for discussion of experimental specifications before they are submitted to the Jabber Council.</li>
<li>If the Standards JIG cannot reach a working consensus on a given topic, let the document author(s) continue to rework their proposal informally outside the context of the Standards JIG. <note>One option would be to send interested parties off to their own ad-hoc mailing list (e.g., on JabberStudio, <link url="http://www.jabberstudio.org/">http://www.jabberstudio.org/</link>). Unlike the current JIGs, such a list would be established on the initiative of the document author(s) and would not require any formal approval by the Jabber Council.</note></li>
<li>Continue to use the Standards SIG as the preferred forum for discussion of experimental specifications before they are submitted to the XMPP Council.</li>
<li>If the Standards SIG cannot reach a working consensus on a given topic, let the document author(s) continue to rework their proposal informally outside the context of the Standards SIG. <note>One option would be to send interested parties off to their own ad-hoc mailing list (e.g., on JabberStudio, <link url="http://www.jabberstudio.org/">http://www.jabberstudio.org/</link>). Unlike the current SIGs, such a list would be established on the initiative of the document author(s) and would not require any formal approval by the XMPP Council.</note></li>
</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 document. <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>
<p>There may be value in bringing back specialized SIGs in the future when the Jabber/XMPP community becomes larger. However, at this time I urge that we face the facts and proactively implement the solution I have outlined in this document. <note>Lest there be any concern that disbanding the SIGs is outside the power or purview of the XMPP Council, I note that Section 8.2 of the Bylaws of the XMPP Standards Foundation states in part that "The XMPP Council or the Members of the Corporation may, by resolution, ... terminate a Special 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>
</xep>

2
xep-0020.xml
View File

@ -12,7 +12,7 @@
<number>0020</number>
<status>Draft</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0004</spec>

4
xep-0021.xml
View File

@ -14,7 +14,7 @@
<number>0021</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards</jig>
<sig>Standards</sig>
<supersedes>None</supersedes>
<supersededby>XEP-0060</supersededby>
<shortname>None</shortname>
@ -28,7 +28,7 @@
<version>0.2</version>
<date>2003-04-22</date>
<initials>psa</initials>
<remark>At the request of the author, the status of this document has been changed to Retracted since it has been superseded by XEP-0060. This document 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 author, the status of this document has been changed to Retracted since it has been superseded by XEP-0060.</remark>
</revision>
<revision>
<version>0.1</version>

2
xep-0022.xml
View File

@ -12,7 +12,7 @@
<number>0022</number>
<status>Active</status>
<type>Historical</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>

4
xep-0023.xml
View File

@ -12,7 +12,7 @@
<number>0023</number>
<status>Deprecated</status>
<type>Historical</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
@ -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 &xep0079;.</em></p>
<p><em>Note Well: The protocol described herein has been deprecated by the &XSF;. 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>

4
xep-0024.xml
View File

@ -12,7 +12,7 @@
<number>0024</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards</jig>
<sig>Standards</sig>
<supersedes>None</supersedes>
<supersededby>XEP-0060</supersededby>
<shortname>None</shortname>
@ -32,7 +32,7 @@
<version>0.2</version>
<date>2003-04-22</date>
<initials>psa</initials>
<remark>At the request of the authors, the status of this document has been changed to Retracted since it has been superseded by XEP-0060. This document 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 since it has been superseded by XEP-0060.</remark>
</revision>
<revision>
<version>0.1</version>

2
xep-0025.xml
View File

@ -12,7 +12,7 @@
<number>0025</number>
<status>Deprecated</status>
<type>Historical</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>

4
xep-0026.xml
View File

@ -12,7 +12,7 @@
<number>0026</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards</jig>
<sig>Standards</sig>
<dependencies>None</dependencies>
<supersedes>None</supersedes>
<supersededby>XMPP Core</supersededby>
@ -27,7 +27,7 @@
<version>0.2</version>
<date>2003-11-05</date>
<initials>psa</initials>
<remark>The status of this document has been changed to Retracted since it has been superseded by &xmppcore;. This document will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
<remark>The status of this document has been changed to Retracted since it has been superseded by &xmppcore;.</remark>
</revision>
<revision>
<version>0.1</version>

2
xep-0027.xml
View File

@ -12,7 +12,7 @@
<number>0027</number>
<status>Active</status>
<type>Historical</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>

2
xep-0028.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>No Such XEP</title>
<abstract>This XEP was removed from the JSF website and source control at the request of the author.</abstract>
<abstract>This XEP was removed from the XSF website and source control at the request of the author.</abstract>
<number>0028</number>
</header>
</xep>

2
xep-0029.xml
View File

@ -12,7 +12,7 @@
<number>0029</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>None</dependencies>
<supersedes>None</supersedes>
<supersededby>XMPP Core</supersededby>

10
xep-0030.xml
View File

@ -12,7 +12,7 @@
<number>0030</number>
<status>Final</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
@ -135,7 +135,7 @@
<version>0.11</version>
<date>2002-12-17</date>
<initials>psa</initials>
<remark>Added support for the 'node' attribute per discussion on the Standards-JIG list in order to support items that are not JID-addressable.</remark>
<remark>Added support for the 'node' attribute per discussion on the Standards list in order to support items that are not JID-addressable.</remark>
</revision>
<revision>
<version>0.10</version>
@ -765,7 +765,7 @@
</section2>
<section2 topic='Registries' anchor='registrar-reg'>
<section3 topic='Identity Categories and Types Registry' anchor='registrar-reg-identity'>
<p>The XMPP Registrar shall maintain a registry of values for the 'category' and 'type' attributes of the &lt;identity/&gt; element in the 'http://jabber.org/protocol/disco#info' namespace; see &lt;<link url="http://www.jabber.org/registrar/disco-categories.html">http://www.jabber.org/registrar/disco-categories.html</link>&gt;.</p>
<p>The XMPP Registrar maintains a registry of values for the 'category' and 'type' attributes of the &lt;identity/&gt; element in the 'http://jabber.org/protocol/disco#info' namespace; see &DISCOCATEGORIES;.</p>
<section4 topic='Process' anchor='registrar-identity'>
&REGPROCESS;
<code><![CDATA[
@ -811,7 +811,7 @@
</section4>
</section3>
<section3 topic='Features Registry' anchor='registrar-reg-features'>
<p>The XMPP Registrar shall maintain a registry of features for use as values of the 'var' attribute of the &lt;feature/&gt; element in the 'http://jabber.org/protocol/disco#info' namespace; see &lt;<link url="http://www.jabber.org/registrar/disco-vars.html">http://www.jabber.org/registrar/disco-vars.html</link>&gt;.</p>
<p>The XMPP Registrar maintains a registry of features for use as values of the 'var' attribute of the &lt;feature/&gt; element in the 'http://jabber.org/protocol/disco#info' namespace; see &DISCOFEATURES;.</p>
<section4 topic='Process' anchor='registrar-reg-features-process'>
&REGPROCESS;
<code><![CDATA[
@ -832,7 +832,7 @@
</section4>
</section3>
<section3 topic='Well-Known Nodes' anchor='registrar-reg-nodes'>
<p>A using protocol may specify one or more service discovery nodes that have a special and well-defined meaning in the context of that protocol. For the purpose of reserving these node names globally across all Jabber protocols, the XMPP Registrar shall maintain a registry of well-known service discovery nodes; see &lt;<link url="http://www.jabber.org/registrar/disco-nodes.html">http://www.jabber.org/registrar/disco-nodes.html</link>&gt;.</p>
<p>A using protocol may specify one or more service discovery nodes that have a special and well-defined meaning in the context of that protocol. For the purpose of reserving these node names globally across all Jabber protocols, the XMPP Registrar maintains a registry of well-known service discovery nodes at &DISCONODES;.</p>
<section4 topic='Process' anchor='registrar-reg-nodes-process'>
&REGPROCESS;
<code><![CDATA[

4
xep-0031.xml
View File

@ -39,9 +39,9 @@ Deferred
Standards Track
</type>
<jig>
<sig>
Standards
</jig>
</sig>
<author>
<firstname>

2
xep-0032.xml
View File

@ -12,7 +12,7 @@
<number>0032</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>None</dependencies>
<supersedes>None</supersedes>
<supersededby><spec>RFC 4622</spec></supersededby>

2
xep-0033.xml
View File

@ -12,7 +12,7 @@
<number>0033</number>
<status>Draft</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0030</spec>

4
xep-0034.xml
View File

@ -14,7 +14,7 @@
<number>0034</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards</jig>
<sig>Standards</sig>
<dependencies>None</dependencies>
<supersedes>None</supersedes>
<supersededby>XMPP Core</supersededby>
@ -41,7 +41,7 @@
<version>1.1</version>
<date>2003-11-05</date>
<initials>psa</initials>
<remark>The status of this specification has been changed to Retracted since it has been superseded by &xmppcore;. This specification will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
<remark>The status of this specification has been changed to Retracted since it has been superseded by &xmppcore;.</remark>
</revision>
<revision>
<version>1.0</version>

4
xep-0035.xml
View File

@ -14,7 +14,7 @@
<number>0035</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards</jig>
<sig>Standards</sig>
<dependencies>None</dependencies>
<supersedes>None</supersedes>
<supersededby>XMPP Core</supersededby>
@ -29,7 +29,7 @@
<version>0.2</version>
<date>2003-11-05</date>
<initials>psa</initials>
<remark>The status of this specification has been changed to Retracted since it has been superseded by &xmppcore;. This document will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
<remark>The status of this specification has been changed to Retracted since it has been superseded by &xmppcore;.</remark>
</revision>
<revision>
<version>0.1</version>

4
xep-0036.xml
View File

@ -12,7 +12,7 @@
<number>0036</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards</jig>
<sig>Standards</sig>
<supersedes>None</supersedes>
<supersededby>XEP-0060</supersededby>
<shortname>None</shortname>
@ -22,7 +22,7 @@
<version>0.2</version>
<date>2003-04-22</date>
<initials>psa</initials>
<remark>At the request of the authors, the status of this specification has been changed to Retracted since it has been superseded by XEP-0060. This specification 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 specification has been changed to Retracted since it has been superseded by XEP-0060.</remark>
</revision>
<revision>
<version>0.1</version>

2
xep-0037.xml
View File

@ -11,7 +11,7 @@
<number>0037</number>
<status>Rejected</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<author>
<firstname>David</firstname>
<surname>Sutton</surname>

4
xep-0038.xml
View File

@ -12,7 +12,7 @@
<number>0038</number>
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>None</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
@ -228,7 +228,7 @@
</section1>
<section1 topic='IANA Considerations'>
<p>The JSF shall register and maintain a MIME type and file extension for icon style packages with the IANA. Ones have already been registered by Sebastiaan Deckers (aka 'CBAS') as <tt>application/vnd.jisp</tt> and <tt>.jisp</tt>, respectively. The registration can be found at <link url="http://www.iana.org/assignments/media-types/application/vnd.jisp">http://www.iana.org/assignments/media-types/application/vnd.jisp</link>. Sebastiaan's registration shall be considered the official MIME type and file extension of this specification.</p>
<p>The &XSF; shall register and maintain a MIME type and file extension for icon style packages with the IANA. Ones have already been registered by Sebastiaan Deckers (aka 'CBAS') as <tt>application/vnd.jisp</tt> and <tt>.jisp</tt>, respectively. The registration can be found at <link url="http://www.iana.org/assignments/media-types/application/vnd.jisp">http://www.iana.org/assignments/media-types/application/vnd.jisp</link>. Sebastiaan's registration shall be considered the official MIME type and file extension of this specification.</p>
<p>Also, this specification uses other MIME types that are maintained by IANA for the object and xml files that are included in the icon style packages.</p>
</section1>

2
xep-0039.xml
View File

@ -12,7 +12,7 @@
<number>0039</number>
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards</jig>
<sig>Standards</sig>
<author>
<firstname>Paul</firstname>
<surname>Curtis</surname>

2
xep-0040.xml
View File

@ -12,7 +12,7 @@
<number>0040</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards</jig>
<sig>Standards</sig>
<dependencies>None</dependencies>
<supersedes>None</supersedes>
<supersededby>XEP-0060</supersededby>

4
xep-0041.xml
View File

@ -12,7 +12,7 @@
<number>0041</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>XMPP Core, XEP-0020, XEP-0030</dependencies>
<supersedes>None</supersedes>
<supersededby>XEP-0065</supersededby>
@ -27,7 +27,7 @@
<version>0.2</version>
<date>2003-09-30</date>
<initials>psa</initials>
<remark>At the request of the author, the status of this specification has been changed to Retracted since it has been superseded by &xep0065;. This specification 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 author, the status of this specification has been changed to Retracted since it has been superseded by &xep0065;.</remark>
</revision>
<revision>
<version>0.8</version>

4
xep-0042.xml
View File

@ -12,7 +12,7 @@
<number>0042</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards</jig>
<sig>Standards</sig>
<dependencies>XEP-0004 (OPTIONAL), XEP-0011 (RECOMMENDED) XEP-0029 (REQUIRED)</dependencies>
<supersedes>None</supersedes>
<supersededby>XEP-0065</supersededby>
@ -27,7 +27,7 @@
<version>0.5</version>
<date>2003-04-11</date>
<initials>psa</initials>
<remark>At the request of the author, changed status to Retracted. This document 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 author, changed status to Retracted.</remark>
</revision>
<revision>
<version>0.4</version>

2
xep-0043.xml
View File

@ -12,7 +12,7 @@
<number>0043</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards</jig>
<sig>Standards</sig>
<author>
<firstname>Justin</firstname>
<surname>Kirby</surname>

2
xep-0044.xml
View File

@ -14,7 +14,7 @@
<number>0044</number>
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards</jig>
<sig>Standards</sig>
<author>
<firstname>Robert</firstna