moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

XSF/SIG cleanup 

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</firstname>
<surname>Norris</surname>

6
xep-0045.xml
View File

@ -14,7 +14,7 @@
<number>0045</number>
<status>Draft</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
@ -225,7 +225,7 @@
<version>0.20</version>
<date>2002-10-29</date>
<initials>psa</initials>
<remark><p>Specified that messages sent to change the room subject must be of type "groupchat"; updated the legal notice to conform to the JSF IPR policy.</p></remark>
<remark><p>Specified that messages sent to change the room subject must be of type "groupchat"; updated the legal notice to conform to the XSF IPR policy.</p></remark>
</revision>
<revision>
<version>0.19</version>
@ -5250,6 +5250,6 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password
</section2>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>The author would like to thank the following individuals for their many helpful comments on various drafts of this proposal: David Sutton, Peter Millard, Joe Hildebrand, Craig Kaes, Alexey Shchepin, David Waite, Jean-Louis Seguineau, Jacek Konieczny, Gaston Dombiak, and many others in the jdev@conference.jabber.org conference room and on the Standards-JIG mailing list.</p>
<p>The author would like to thank the following individuals for their many helpful comments on various drafts of this proposal: David Sutton, Peter Millard, Joe Hildebrand, Craig Kaes, Alexey Shchepin, David Waite, Jean-Louis Seguineau, Jacek Konieczny, Gaston Dombiak, and many others in the jdev@conference.jabber.org conference room and on the Standards mailing list.</p>
</section1>
</xep>

4
xep-0046.xml
View File

@ -12,7 +12,7 @@
<number>0046</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards</jig>
<sig>Standards</sig>
<dependencies>None</dependencies>
<supersedes>None</supersedes>
<supersededby>XEP-0065</supersededby>
@ -27,7 +27,7 @@
<version>0.8</version>
<date>2003-04-11</date>
<initials>psa</initials>
<remark>At the request of the author, changed status to Retracted. 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, changed status to Retracted.</remark>
</revision>
<revision>
<version>0.7</version>

2
xep-0047.xml
View File

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

2
xep-0048.xml
View File

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

2
xep-0049.xml
View File

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

2
xep-0050.xml
View File

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

2
xep-0051.xml
View File

@ -14,7 +14,7 @@
<number>0051</number>
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<author>
<firstname>Klaus</firstname>
<surname>Wolf</surname>

4
xep-0052.xml
View File

@ -12,7 +12,7 @@
<number>0052</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>XMPP Core, XMPP IM, XEP-0004, XEP-0020, XEP-0030</dependencies>
<supersedes>None</supersedes>
<supersededby>XEP-0095, XEP-0096</supersededby>
@ -39,7 +39,7 @@
<version>0.2</version>
<date>2003-09-30</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-0095 and XEP-0096. 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-0095 and XEP-0096.</remark>
</revision>
<revision>
<version>0.1</version>

18
xep-0053.xml
View File

@ -7,12 +7,12 @@
<xep>
<header>
<title>XMPP Registrar Function</title>
<abstract>This document defines the roles and processes of the XMPP Registrar function within the Jabber Software Foundation.</abstract>
<abstract>This document defines the roles and processes of the XMPP Registrar function within the XMPP Standards Foundation.</abstract>
&LEGALNOTICE;
<number>0053</number>
<status>Active</status>
<type>Procedural</type>
<jig>None</jig>
<sig>None</sig>
<approver>Board</approver>
<dependencies/>
<supersedes/>
@ -29,7 +29,7 @@
<version>1.2</version>
<date>2006-10-04</date>
<initials>psa</initials>
<remark><p>As approved by the members of the Jabber Software Foundation, changed Jabber Registrar to XMPP Registrar.</p></remark>
<remark><p>As approved by the members of the XMPP Standards Foundation, changed Jabber Registrar to XMPP Registrar.</p></remark>
</revision>
<revision>
<version>1.1</version>
@ -47,7 +47,7 @@
<version>0.5</version>
<date>2003-01-21</date>
<initials>psa</initials>
<remark>Changed name to XMPP Registrar in response to feedback from the JSF Board of Directors.</remark>
<remark>Changed name to XMPP Registrar in response to feedback from the XSF Board of Directors.</remark>
</revision>
<revision>
<version>0.4</version>
@ -75,7 +75,7 @@
</revision>
</header>
<section1 topic='Introduction and Purpose' anchor='intro'>
<p>Because the &JSF; publishes a relatively large number of protocol specifications (see &xep0001;), it is important to keep track of the namespaces defined by those specifications as well as the parameters used in the context of the relevant protocols. (Examples of such parameters include the features and options used in &xep0020; and the identities and features used in &xep0030;.) In particular, the common use of protocols published by the JSF requires that namespaces and particular parameter values be assigned uniquely. It is the role of the XMPP Registrar to make those unique assignments and to maintain registries of the currently assigned values. The XMPP Registrar shall also function as a single point of contact between the Jabber/XMPP developer community and &IANA;.</p>
<p>Because the &XSF; publishes a relatively large number of protocol specifications (see &xep0001;), it is important to keep track of the namespaces defined by those specifications as well as the parameters used in the context of the relevant protocols. (Examples of such parameters include the features and options used in &xep0020; and the identities and features used in &xep0030;.) In particular, the common use of protocols published by the XSF requires that namespaces and particular parameter values be assigned uniquely. It is the role of the XMPP Registrar to make those unique assignments and to maintain registries of the currently assigned values. The XMPP Registrar shall also function as a single point of contact between the Jabber/XMPP developer community and &IANA;.</p>
</section1>
<section1 topic='Composition' anchor='composition'>
<p>Until there is a perceived need for a more formal governing body, the functions of the XMPP Registrar shall be managed by the &EDITOR;. In the future, the &COUNCIL; and/or the &BOARD; may decide to create a more formal panel to oversee the functions of the XMPP Registrar; if they do, this document shall be updated to reflect the change.</p>
@ -83,11 +83,11 @@
<section1 topic='Registry Creation and Maintenance' anchor='registries'>
<p>Every XMPP Extension Protocol specification (XEP) must contain a section devoted to "XMPP Registrar Considerations", detailing the namespaces and parameters to be registered with the XMPP Registrar, as well as any new registries to be created as a result of the XEP.</p>
<p>The registry additions or creations specified in an XMPP Extension Protocol specification shall not take effect until the document advances to a status of Draft (Standards-Track XEPs) or Active (Informational and Historical XEPs). Registration of namespaces shall be handled as described in the <link url='#namespaces'>Namespace Issuance</link> section of this document. Registration of particular parameters used within a specification shall be initiated by the XMPP Extensions Editor if specified in the XEP, and may also be initiated by implementors of the XMPP Extension Protocol document after it has advanced to Active, Draft, or Final. Creation of new registries shall be initiated by the XMPP Registrar; if a document specifies the creation of a new registry, the author is strongly encouraged to consult with the XMPP Registrar before seeking a Last Call on the XEP.</p>
<p>Requests for parameter assignments must be sent to the XMPP Registrar in accordance with the process specified in the document (usually a XEP) that defines the relevant registry, normally by sending an appropriately formatted email message to &lt;<link url='mailto:registrar@jabber.org'>mailto:registrar@jabber.org</link>&gt;. If, in the Registrar's judgment, discussion of a request is required, the Registrar shall initiate such discussion within the &SJIG;. The Registrar shall add registry items at its discretion based on discussion within the Standards JIG if necessary, but shall not unduly restrict registration of parameter values. If a document author or implementor thinks that a request was unfairly denied by the Registrar, an appeal of the decision may be directed to the XMPP Council.</p>
<p>The XMPP Registrar shall maintain registries of assigned namespaces and parameters at &lt;<link url="http://www.xmpp.org/registrar/">http://www.xmpp.org/registrar/</link>&gt; and shall update those registries in a timely fashion. Changes to the registries shall be announced on the Standards-JIG mailing list.</p>
<p>Requests for parameter assignments must be sent to the XMPP Registrar in accordance with the process specified in the document (usually a XEP) that defines the relevant registry, normally by sending an appropriately formatted email message to &lt;<link url='mailto:registrar@jabber.org'>mailto:registrar@jabber.org</link>&gt;. If, in the Registrar's judgment, discussion of a request is required, the Registrar shall initiate such discussion within the &SSIG;. The Registrar shall add registry items at its discretion based on discussion within the Standards SIG if necessary, but shall not unduly restrict registration of parameter values. If a document author or implementor thinks that a request was unfairly denied by the Registrar, an appeal of the decision may be directed to the XMPP Council.</p>
<p>The XMPP Registrar shall maintain registries of assigned namespaces and parameters at &lt;<link url="http://www.xmpp.org/registrar/">http://www.xmpp.org/registrar/</link>&gt; and shall update those registries in a timely fashion. Changes to the registries shall be announced on the Standards mailing list.</p>
</section1>
<section1 topic='Namespace Issuance' anchor='namespaces'>
<p>The XMPP Registrar shall be responsible for issuing namespaces to be used in XMPP protocol extensions developed through the Jabber Software Foundation's standards process as specified in <cite>XEP-0001</cite>. The policies and procedures for namespace issuance shall be as follows:</p>
<p>The XMPP Registrar shall be responsible for issuing namespaces to be used in XMPP protocol extensions developed through the XMPP Standards Foundation's standards process as specified in <cite>XEP-0001</cite>. The policies and procedures for namespace issuance shall be as follows:</p>
<ol start='1'>
<li><p>While a XEP is in the Experimental state, the namespaces specified therein shall be of the form "http://www.xmpp.org/extensions/xep-XXXX.html#ns" and "http://www.xmpp.org/extensions/xep-XXXX.html#ns-SubName", where "XXXX" is the XEP number and "SubName" is a sub-namespace (as is familiar from specifications such as &xep0045;).</p></li>
<li>
@ -107,7 +107,7 @@
<p>Security considerations are primarily the responsibility of the protocols in which specific parameters are used. The XMPP Registrar shall respect the security considerations defined in XMPP Extension Protocol specifications, and shall endeavor to ensure that registered parameter values do not compromise privacy or security in any way.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>The XMPP Registrar shall be responsible for interacting with the IANA on behalf of the Jabber Software Foundation and Jabber/XMPP developer community. If an XMPP Extension Protocol specification requires interaction with the IANA, that fact shall be noted by the document author and discussed on the Standards-JIG mailing list along with normal discussion of the XEP. The XMPP Registrar shall collaborate with the author to present an appropriate request to the IANA.</p>
<p>The XMPP Registrar shall be responsible for interacting with the IANA on behalf of the XMPP Standards Foundation and Jabber/XMPP developer community. If an XMPP Extension Protocol specification requires interaction with the IANA, that fact shall be noted by the document author and discussed on the Standards mailing list along with normal discussion of the XEP. The XMPP Registrar shall collaborate with the author to present an appropriate request to the IANA.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This entire document defines the processes and procedures of the XMPP Registrar.</p>

12
xep-0054.xml
View File

@ -12,7 +12,7 @@
<number>0054</number>
<status>Active</status>
<type>Historical</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
@ -79,10 +79,10 @@
<MIDDLE/>
</N>
<NICKNAME>stpeter</NICKNAME>
<URL>http://www.jabber.org/people/stpeter.php</URL>
<URL>http://www.xmpp.org/xsf/people/stpeter.shtml</URL>
<BDAY>1966-08-06</BDAY>
<ORG>
<ORGNAME>Jabber Software Foundation</ORGNAME>
<ORGNAME>XMPP Standards Foundation</ORGNAME>
<ORGUNIT/>
</ORG>
<TITLE>Executive Director</TITLE>
@ -242,7 +242,7 @@ PARTICULAR PURPOSE.
<!-- NOTE: the following root element is not used in the
modified vcard-temp DTD published by the Jabber
project (now Jabber Software Foundation) and is
project (now XMPP Standards Foundation) and is
included here only for historical purposes;
implementations that comply with vcard-temp must
specify the root element as vCard, not xCard. -->
@ -388,7 +388,7 @@ PARTICULAR PURPOSE.
<!ELEMENT USERID (#PCDATA)>
<!-- NOTE: the following element was added by the Jabber
project (now Jabber Software Foundation) to
project (now XMPP Standards Foundation) to
handle Jabber IDs; the value must be in the
form of user@host -->
@ -465,7 +465,7 @@ PARTICULAR PURPOSE.
<!ELEMENT URL (#PCDATA)>
<!-- NOTE: the following element was added by the Jabber
project (now Jabber Software Foundation) to
project (now XMPP Standards Foundation) to
handle free-form descriptive text. -->
<!ELEMENT DESC (#PCDATA)>

2
xep-0055.xml
View File

@ -12,7 +12,7 @@
<number>0055</number>
<status>Active</status>
<type>Historical</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec dep="SHOULD">XEP-0004</spec>

2
xep-0056.xml
View File

@ -12,7 +12,7 @@
<number>0056</number>
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>None</dependencies>
<author>
<firstname>Ulrich</firstname>

4
xep-0057.xml
View File

@ -12,7 +12,7 @@
<number>0057</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>None</shortname>
@ -26,7 +26,7 @@
<version>0.2</version>
<date>2003-04-28</date>
<initials>psa</initials>
<remark>Changed the status to Retracted at the request of the author, since the proposed protocol was incompatible with XMPP and clients have begun using jabber:iq:private for this kind of functionality. This document will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
<remark>Changed the status to Retracted at the request of the author, since the proposed protocol was incompatible with XMPP and clients have begun using jabber:iq:private for this kind of functionality.</remark>
</revision>
<revision>
<version>0.1</version>

2
xep-0058.xml
View File

@ -12,7 +12,7 @@
<number>0058</number>
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards</jig>
<sig>Standards</sig>
<author>
<firstname>Alexey</firstname>
<surname>Shchepin</surname>

2
xep-0059.xml
View File

@ -12,7 +12,7 @@
<number>0059</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-0060.xml
View File

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

2
xep-0061.xml
View File

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

2
xep-0062.xml
View File

@ -15,7 +15,7 @@
<number>0062</number>
<status>Deferred</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>XMPP Core, XEP-0030</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>

2
xep-0063.xml
View File

@ -15,7 +15,7 @@
<number>0063</number>
<status>Deferred</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>XEP-0062</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>

2
xep-0064.xml
View File

@ -15,7 +15,7 @@
<number>0064</number>
<status>Deferred</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>XEP-0062</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>

2
xep-0065.xml
View File

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

2
xep-0066.xml
View File

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

2
xep-0067.xml
View File

@ -12,7 +12,7 @@
<number>0067</number>
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>XEP-0060</dependencies>
<author>
<firstname>Ulrich</firstname>

10
xep-0068.xml
View File

@ -12,7 +12,7 @@
<number>0068</number>
<status>Active</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0004</spec>
@ -78,8 +78,8 @@
<section2 topic='Whether to Register' anchor='approach-register'>
<p>The first decision-point is whether a FORM_TYPE needs to be registered with the XMPP Registrar. The following rules apply:</p>
<ol>
<li>If the FORM_TYPE is used in the context of a form defined in a XEP, it MUST be registered.</li>
<li>If the FORM_TYPE is used in the context of a JSF-managed protocol but the form is not defined in a XEP, it MAY be registered.</li>
<li>If the FORM_TYPE is used in the context of a form defined in a XEP published by the &XSF;, it MUST be registered.</li>
<li>If the FORM_TYPE is used in the context of some other XMPP protocol but the form is not defined in a XEP, it MAY be registered.</li>
<li>If the FORM_TYPE is used in the context of a custom protocol, it MAY be registered.</li>
</ol>
</section2>
@ -87,8 +87,8 @@
<p>While the value of the FORM_TYPE attribute SHOULD be considered an opaque string from the application perspective, the following rules apply:</p>
<ol>
<li>For custom protocols, the name SHOULD be an HTTP URI that is managed by the namespace "owner".</li>
<li>For all new protocols approved by the JSF, the name MUST be an HTTP URI or IETF-style URN.</li>
<li>For "legacy" protocols managed by the JSF, the name SHOULD use the old-style "jabber:*:*" format.</li>
<li>For all new protocols approved by the XSF, the name MUST be an HTTP URI or IETF-style URN.</li>
<li>For "legacy" protocols managed by the XSF, the name SHOULD use the old-style "jabber:*:*" format.</li>
</ol>
</section2>
<section2 topic='Field Names' anchor='approach-fieldnames'>

27
xep-0069.xml
View File

@ -6,19 +6,14 @@
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Compliance JIG</title>
<abstract>A proposal to form a JIG devoted to issues related to protocol compliance.</abstract>
<title>Compliance SIG</title>
<abstract>A proposal to form a SIG devoted to issues related to protocol compliance.</abstract>
&LEGALNOTICE;
<number>0069</number>
<status>Deferred</status>
<type>JIG Formation</type>
<jig>None</jig>
<author>
<firstname>Peter</firstname>
<surname>Saint-Andre</surname>
<email>stpeter@jabber.org</email>
<jid>stpeter@jabber.org</jid>
</author>
<type>SIG Formation</type>
<sig>None</sig>
&stpeter;
<revision>
<version>0.1</version>
<date>2003-01-29</date>
@ -27,20 +22,20 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>The Jabber Software Foundation has an initiative underway to define and implement compliance testing of software that is based on XMPP and JSF-approved protocols. To date, participation in this compliance program has been limited to elected members of the JSF. However, not all matters related to the compliance program need to be limited to JSF members. In particular, it would be valuable to receive community feedback and input regarding test plans, testing software, and the like. In order to broaden participation, we propose that the JSF form a standing Jabber Interest Group devoted to compliance.</p>
<p>The XMPP Standards Foundation has an initiative underway to define and implement compliance testing of software that is based on XMPP and XSF-approved protocols. To date, participation in this compliance program has been limited to elected members of the XSF. However, not all matters related to the compliance program need to be limited to XSF members. In particular, it would be valuable to receive community feedback and input regarding test plans, testing software, and the like. In order to broaden participation, we propose that the XSF form a standing Jabber Interest Group devoted to compliance.</p>
</section1>
<section1 topic='Scope and Role'>
<p>The Compliance JIG shall provide a public forum for discussion and development of systems for testing compliance with the protocols defined and accepted by the JSF. It shall not have ultimate accountability for the JSF compliance program; rather, that accountability shall rest with the members-only Compliance Team. The Compliance JIG shall act in an advisory capacity in relation to the Compliance Team. In essence, the relationship between the Compliance JIG and the Compliance Team is analagous to the relationship between the Standards JIG and the Jabber Council.</p>
<p>In particular, the Compliance JIG shall work with the Compliance Team to define the processes, standards, test cases, and testing software required by the compliance program. However, the Compliance JIG shall not be privy to actual testing results, which shall be available only to the Compliance Team.</p>
<p>The Compliance SIG shall provide a public forum for discussion and development of systems for testing compliance with the protocols defined and accepted by the XSF. It shall not have ultimate accountability for the XSF compliance program; rather, that accountability shall rest with the members-only Compliance Team. The Compliance SIG shall act in an advisory capacity in relation to the Compliance Team. In essence, the relationship between the Compliance SIG and the Compliance Team is analagous to the relationship between the Standards SIG and the Jabber Council.</p>
<p>In particular, the Compliance SIG shall work with the Compliance Team to define the processes, standards, test cases, and testing software required by the compliance program. However, the Compliance SIG shall not be privy to actual testing results, which shall be available only to the Compliance Team.</p>
</section1>
<section1 topic='Membership'>
<p>The Compliance JIG shall be open to the public and shall not be limited to elected members of the Jabber Software Foundation. Compliance JIG discussions shall be conducted on a dedicated mailing list &lt;compliance-jig@jabber.org&gt; as well as in the &lt;foundation@conference.jabber.org&gt; chatroom.</p>
<p>The Compliance SIG shall be open to the public and shall not be limited to elected members of the XMPP Standards Foundation. Compliance SIG discussions shall be conducted on a dedicated mailing list &lt;compliance-jig@jabber.org&gt; as well as in the &lt;foundation@conference.jabber.org&gt; chatroom.</p>
</section1>
<section1 topic='Lifetime'>
<p>The Compliance JIG shall be a standing JIG, and shall exist as long as the JSF compliance program is in operation.</p>
<p>The Compliance SIG shall be a standing SIG, and shall exist as long as the XSF compliance program is in operation.</p>
</section1>
<section1 topic='Deliverables'>
<p>The Compliance JIG shall produce at least the following deliverables:</p>
<p>The Compliance SIG shall produce at least the following deliverables:</p>
<ul>
<li>Documentation of the testing process</li>
<li>Compliance test plans</li>

2
xep-0070.xml
View File

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

26
xep-0071.xml
View File

@ -12,7 +12,7 @@
<number>0071</number>
<status>Draft</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
@ -76,7 +76,7 @@
<version>0.15</version>
<date>2004-07-29</date>
<initials>psa</initials>
<remark>Based on W3C feedback, added content model and refactored the text to ensure separation between the XHTML 1.0 Integration Set itself and the JSF's recommended profile of the Integration Set; also split the requirements out from the Concepts and Approach section, added several more examples, and showed renderings of the examples.</remark>
<remark>Based on W3C feedback, added content model and refactored the text to ensure separation between the XHTML 1.0 Integration Set itself and the XSF's recommended profile of the Integration Set; also split the requirements out from the Concepts and Approach section, added several more examples, and showed renderings of the examples.</remark>
</revision>
<revision>
<version>0.14</version>
@ -168,10 +168,10 @@
</section1>
<section1 topic='Choice of Technology' anchor='tech'>
<p>In the past, there have existed several incompatible methods within the Jabber community for exchanging instant messages that contain lightweight text markup. The most notable such methods have included derivatives of &w3xhtml; as well as of &rtf;.</p>
<p>Although it is sometimes easier for client developers to implement RTF support (this is especially true on certain Microsoft Windows operating systems), there are several reasons (consistent with the &xep0134;) for the &JSF; to avoid the use of RTF in developing a protocol for lightweight text markup. Specifically:</p>
<p>Although it is sometimes easier for client developers to implement RTF support (this is especially true on certain Microsoft Windows operating systems), there are several reasons (consistent with the &xep0134;) for the &XSF; to avoid the use of RTF in developing a protocol for lightweight text markup. Specifically:</p>
<ol type='1' start='1'>
<li>RTF is not a structured vocabulary derived from SGML (as is &w3html;) or, more relevantly, from XML (as is XHTML 1.0).</li>
<li>RTF is under the control of the Microsoft Corporation and thus is not an open standard maintained by a recognized standards development organization; therefore the JSF is unable to contribute to or influence its development if necessary, and any protocol the JSF developed using RTF would introduce unwanted dependencies.</li>
<li>RTF is under the control of the Microsoft Corporation and thus is not an open standard maintained by a recognized standards development organization; therefore the XSF is unable to contribute to or influence its development if necessary, and any protocol the XSF developed using RTF would introduce unwanted dependencies.</li>
</ol>
<p>Conversely, there are several reasons to prefer XHTML for lightweight text markup:</p>
<ol type='1' start='1'>
@ -785,7 +785,7 @@ That seems fine to me.
<p>The fields of this FPI are as follows:</p>
<ol type='1' start='1'>
<li>The leading field is "-", which indicates that this is a privately-defined resource.</li>
<li>The second field is "JSF" (an abbreviation for Jabber Software Foundation), which identifies the organization that maintains the named item.</li>
<li>The second field is "JSF" (an abbreviation for Jabber Software Foundation, the former name for the XMPP Standards Foundation), which identifies the organization that maintains the named item.</li>
<li>The third field contains two constructs:
<ol type='1' start='1'>
<li>The public text class is "DTD", which adheres to ISO 8879 Clause 10.2.2.1.</li>
@ -801,15 +801,15 @@ That seems fine to me.
<ol type='1' start='4'>
<li>
<p><em>W3C TEXT:</em> If a user agent encounters an element it does not recognize, it must continue to process the children of that element. If the content is text, the text must be presented to the user.</p>
<p><em>JSF COMMENT:</em> This behavior is different from that defined by <cite>XMPP Core</cite>, and in the context of XHTML-IM implementations applies only to XML elements qualified by the 'http://www.w3.org/1999/xhtml' namespace as defined herein. This criterion MUST be applied to all XHTML 1.0 elements except those explicitly included in XHTML-IM as described in the <link url="#def">XHTML-IM Integration Set</link> and <link url='#profile'>Recommended Profile</link> sections of this document. Therefore, an XHTML-IM implementation MUST process all XHTML 1.0 child elements of the XHTML-IM &lt;html/&gt; element even if such child elements are not included in the XHTML 1.0 Integration Set defined herein, and MUST present to the recipient the XML character data contained in such child elements.</p>
<p><em>XSF COMMENT:</em> This behavior is different from that defined by <cite>XMPP Core</cite>, and in the context of XHTML-IM implementations applies only to XML elements qualified by the 'http://www.w3.org/1999/xhtml' namespace as defined herein. This criterion MUST be applied to all XHTML 1.0 elements except those explicitly included in XHTML-IM as described in the <link url="#def">XHTML-IM Integration Set</link> and <link url='#profile'>Recommended Profile</link> sections of this document. Therefore, an XHTML-IM implementation MUST process all XHTML 1.0 child elements of the XHTML-IM &lt;html/&gt; element even if such child elements are not included in the XHTML 1.0 Integration Set defined herein, and MUST present to the recipient the XML character data contained in such child elements.</p>
</li>
<li>
<p><em>W3C TEXT:</em> If a user agent encounters an attribute it does not recognize, it must ignore the entire attribute specification (i.e., the attribute and its value).</p>
<p><em>JSF COMMENT:</em> This criterion MUST be applied to all XHTML 1.0 attributes except those explicitly included in XHTML-IM as described in the <link url="#def">XHTML-IM Integration Set</link> and <link url='#profile'>Recommended Profile</link> sections of this document. Therefore, an XHTML-IM implementation MUST ignore all attributes of elements qualified by the 'http://www.w3.org/1999/xhtml' namespace if such attributes are not explicitly included in the XHTML 1.0 Integration Set defined herein.</p>
<p><em>XSF COMMENT:</em> This criterion MUST be applied to all XHTML 1.0 attributes except those explicitly included in XHTML-IM as described in the <link url="#def">XHTML-IM Integration Set</link> and <link url='#profile'>Recommended Profile</link> sections of this document. Therefore, an XHTML-IM implementation MUST ignore all attributes of elements qualified by the 'http://www.w3.org/1999/xhtml' namespace if such attributes are not explicitly included in the XHTML 1.0 Integration Set defined herein.</p>
</li>
<li>
<p><em>W3C TEXT:</em> If a user agent encounters an attribute value it doesn't recognize, it must use the default attribute value.</p>
<p><em>JSF COMMENT:</em> Since not one of the attributes included in XHTML-IM has a default value defined for it in <cite>XHTML 1.0</cite>, in practice this criterion does not apply to XHTML-IM implementations.</p>
<p><em>XSF COMMENT:</em> Since not one of the attributes included in XHTML-IM has a default value defined for it in <cite>XHTML 1.0</cite>, in practice this criterion does not apply to XHTML-IM implementations.</p>
</li>
</ol>
</section2>
@ -817,7 +817,7 @@ That seems fine to me.
<p>For information regarding XHTML modularization in XML schema for the XHTML 1.0 Integration Set defined in this specification, refer to the <link url="#schemas-driver">Schema Driver</link> section of this document.</p>
</section2>
<section2 topic='W3C Review' anchor='w3c-review'>
<p>The XHTML 1.0 Integration Set defined herein has been reviewed informally by an editor of the XHTML Modularization in XML Schema specification but has not undergone formal review by the W3C; before this specification proceeds to a status of Final within the Jabber Software Foundation's standards process, it should undergo a formal review through communication with the Hypertext Coordination Group within the W3C.</p>
<p>The XHTML 1.0 Integration Set defined herein has been reviewed informally by an editor of the XHTML Modularization in XML Schema specification but has not undergone formal review by the W3C; before this specification proceeds to a status of Final within the XMPP Standards Foundation's standards process, it should undergo a formal review through communication with the Hypertext Coordination Group within the W3C.</p>
</section2>
<section2 topic='XHTML Versioning' anchor='w3c-versions'>
<p>The W3C is actively working on &w3xhtml2; and may produce additional versions of XHTML in the future. This specification addresses XHTML 1.0 only, but it may be superseded or supplemented in the future by a XMPP Extension Protocol specification that defines methods for encapsulating XHTML 2.0 content in XMPP.</p>
@ -858,7 +858,7 @@ That seems fine to me.
Full documentation of this Integration Set is contained in
"XEP-0071: XHTML-IM", a specification published by the
Jabber Software Foundation.
XMPP Standards Foundation.
http://www.xmpp.org/extensions/xep-0071.html
@ -916,7 +916,7 @@ That seems fine to me.
Full documentation of this Integration Set is contained in
"XEP-0071: XHTML-IM", a specification published by the
Jabber Software Foundation, which is available at the
XMPP Standards Foundation, which is available at the
following URL:
http://www.xmpp.org/extensions/xep-0071.html
@ -990,7 +990,7 @@ That seems fine to me.
Full documentation of this Integration Set is contained in
"XEP-0071: XHTML-IM", a specification published by the
Jabber Software Foundation.
XMPP Standards Foundation.
http://www.xmpp.org/extensions/xep-0071.html
@ -1173,6 +1173,6 @@ That seems fine to me.
</section2>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>This specification formalizes and extends earlier work by Jeremie Miller and Julian Missig on XHTML formatting of Jabber messages. Many thanks to Shane McCarron for his assistance regarding XHTML modularization and conformance issues. Thanks also to contributors on the Standards-JIG list for their feedback and suggestions.</p>
<p>This specification formalizes and extends earlier work by Jeremie Miller and Julian Missig on XHTML formatting of Jabber messages. Many thanks to Shane McCarron for his assistance regarding XHTML modularization and conformance issues. Thanks also to contributors on the Standards list for their feedback and suggestions.</p>
</section1>
</xep>

6
xep-0072.xml
View File

@ -12,7 +12,7 @@
<number>0072</number>
<status>Draft</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>SOAP 1.2</spec>
@ -1034,9 +1034,9 @@
</section1>
<section1 topic="W3C Considerations" anchor='w3c'>
<p>The main body of text that addresses the requirements of the W3C with regard to SOAP bindings is provided in the <link url='#binding'>SOAP XMPP Binding</link> section of this document. The current section addresses only the topic of organizational interaction between the W3C and the &JSF; regarding the SOAP XMPP Binding.</p>
<p>The main body of text that addresses the requirements of the W3C with regard to SOAP bindings is provided in the <link url='#binding'>SOAP XMPP Binding</link> section of this document. The current section addresses only the topic of organizational interaction between the W3C and the &XSF; regarding the SOAP XMPP Binding.</p>
<section2 topic='W3C Review' anchor='w3c-review'>
<p>As was done with &xep0071;, the SOAP XMPP Binding defined herein has been reviewed informally by one or more appropriate experts from the W3C before the &COUNCIL; advanced it to a status of Draft within the JSF's standards process. Before this specification proceeds to a status of Final within the JSF's standards process, it should undergo a formal review through communication with the W3C's <link url='http://www.w3.org/2000/xp/Group/'>XML Protocol Working Group</link>. To that end, revised versions of this specification will be announced on the W3C's public xml-dist-app@w3.org mailing list.</p>
<p>As was done with &xep0071;, the SOAP XMPP Binding defined herein has been reviewed informally by one or more appropriate experts from the W3C before the &COUNCIL; advanced it to a status of Draft within the XSF's standards process. Before this specification proceeds to a status of Final within the XSF's standards process, it should undergo a formal review through communication with the W3C's <link url='http://www.w3.org/2000/xp/Group/'>XML Protocol Working Group</link>. To that end, revised versions of this specification will be announced on the W3C's public xml-dist-app@w3.org mailing list.</p>
</section2>
<section2 topic='SOAP Versioning' anchor='w3c-soapversions'>
<p>This specification addresses SOAP 1.2 only. This specification may be superseded or supplemented in the future by a XMPP Extension Protocol specification that defines methods for encapsulating content defined by future versions of SOAP as published by the W3C.</p>

4
xep-0073.xml
View File

@ -12,7 +12,7 @@
<number>0073</number>
<status>Draft</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
@ -94,7 +94,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Given the large number of Jabber/XMPP protocols,
<note>The protocols developed by the Jabber community have matured considerably since 1999. The core protocols were originally created by a small group of developers who worked on early Jabber-related open-source software projects such as the &jabberd; server, the Winjab, Gabber, and Jarl clients, the Net::Jabber and Jabberbeans libraries, and gateways to consumer IM services. In the summer of 2001, the &JSF; was founded to institute a formal standards process within the growing Jabber community (codified in &xep0001;). In late 2002, the &IETF; formed the &XMPPWG;, which formalized the core Jabber protocols under the name Extensible Messaging and Presence Protocol (XMPP). In early 2004, the IETF approved the main XMPP specifications as Proposed Standards within the Internet Standards Process defined by &rfc2026;, resulting in publication of <cite>RFC 3920</cite> (&xmppcore;) and <cite>RFC 3921</cite> (&xmppim;). In the meantime, the JSF has continued to develop additional protocols on top of XMPP in order to address functionality areas (such as file transfer) that were too application-specific for consideration within the IETF.</note>
<note>The protocols developed by the Jabber community have matured considerably since 1999. The core protocols were originally created by a small group of developers who worked on early Jabber-related open-source software projects such as the &jabberd; server, the Winjab, Gabber, and Jarl clients, the Net::Jabber and Jabberbeans libraries, and gateways to consumer IM services. In the summer of 2001, the &XSF; was founded to institute a formal standards process within the growing Jabber community (codified in &xep0001;). In late 2002, the &IETF; formed the &XMPPWG;, which formalized the core Jabber protocols under the name Extensible Messaging and Presence Protocol (XMPP). In early 2004, the IETF approved the main XMPP specifications as Proposed Standards within the Internet Standards Process defined by &rfc2026;, resulting in publication of <cite>RFC 3920</cite> (&xmppcore;) and <cite>RFC 3921</cite> (&xmppim;). In the meantime, the XSF has continued to develop additional protocols on top of XMPP in order to address functionality areas (such as file transfer) that were too application-specific for consideration within the IETF.</note>
it is not always clear to developers exactly which protocols they need to implement in order to interoperate over Jabber/XMPP networks. This document attempts to assist developers by defining a protocol suite for basic instant messaging and presence.</p>
</section1>
<section1 topic='Requirements and Approach' anchor='reqs'>

2
xep-0074.xml
View File

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

2
xep-0075.xml
View File

@ -16,7 +16,7 @@
<number>0075</number>
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>None</dependencies>
<supersededby>None</supersededby>
<supersedes>None</supersedes>

4
xep-0076.xml
View File

@ -12,7 +12,7 @@
<number>0076</number>
<status>Active</status>
<type>Humorous</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>RFC 3514</spec>
@ -30,7 +30,7 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>&rfc3514;, published just today (2003-04-01), defines a mechanism for specifying the "evil bit" in IPv4 in order to determine if a packet was sent with malicious intent. In Section 5 ("Related Work") of that RFC, reference is made to complementary mechanisms for other forms of evil such as IPv6 support and the application/evil MIME type. Because the &JSF; desires to maintain compliance with protocols developed by core Internet standards bodies, the current document defines a complementary mechanism for Jabber support of evil.</p>
<p>&rfc3514;, published just today (2003-04-01), defines a mechanism for specifying the "evil bit" in IPv4 in order to determine if a packet was sent with malicious intent. In Section 5 ("Related Work") of that RFC, reference is made to complementary mechanisms for other forms of evil such as IPv6 support and the application/evil MIME type. Because the &XSF; desires to maintain compliance with protocols developed by core Internet standards bodies, the current document defines a complementary mechanism for Jabber support of evil.</p>
</section1>
<section1 topic='Requirements and Approach'>
<p>There are three basic Jabber stanza types that may be sent within XML streams:</p>

2
xep-0077.xml
View File

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

2
xep-0078.xml
View File

@ -12,7 +12,7 @@
<number>0078</number>
<status>Deprecated</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>RFC 3174</spec>

8
xep-0079.xml
View File

@ -12,7 +12,7 @@
<number>0079</number>
<status>Draft</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0030</spec>
@ -90,7 +90,7 @@
<version>0.7</version>
<date>2003-12-10</date>
<initials>lw</initials>
<remark>Incorported changes requested from Standards-JIG discussions: Changed entity-to-server discovery behavior; s2s discovery behavior; Expanded application-specific error conditions; Reorganized for better presentation; Changed "per-hop" to apply to the entire ruleset; Fixed minor typos and missteps</remark>
<remark>Incorported changes requested from Standards list discussions: Changed entity-to-server discovery behavior; s2s discovery behavior; Expanded application-specific error conditions; Reorganized for better presentation; Changed "per-hop" to apply to the entire ruleset; Fixed minor typos and missteps</remark>
</revision>
<revision>
<version>0.6</version>
@ -1045,7 +1045,7 @@
</section2>
<section2 topic='Registries' anchor='registrar-reg'>
<section3 topic='Rule Conditions Registry' anchor='registrar-reg-conditions'>
<p>The XMPP Registrar maintains a registry of AMP &lt;rule/&gt; conditions (see &lt;<link url='http://www.jabber.org/registrar/amp-conditions.html'>http://www.jabber.org/registrar/amp-conditions.html</link>&gt;).</p>
<p>The XMPP Registrar maintains a registry of AMP &lt;rule/&gt; conditions at &AMPCONDITIONS;.</p>
<section4 topic='Process' anchor='registrar-reg-conditions-process'>
&REGPROCESS;
<code><![CDATA[
@ -1115,7 +1115,7 @@
</section4>
</section3>
<section3 topic='Rule Actions Registry' anchor='registrar-reg-actions'>
<p>The XMPP Registrar maintains a registry of AMP &lt;rule/&gt; actions (see &lt;<link url='http://www.jabber.org/registrar/amp-actions.html'>http://www.jabber.org/registrar/amp-actions.html</link>&gt;).</p>
<p>The XMPP Registrar maintains a registry of AMP &lt;rule/&gt; actions at &AMPACTIONS;.</p>
<section4 topic='Process' anchor='registrar-reg-actions-process'>
&REGPROCESS;
<code><![CDATA[

4
xep-0080.xml
View File

@ -12,7 +12,7 @@
<number>0080</number>
<status>Draft</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0060</spec>
@ -95,7 +95,7 @@
<version>0.2</version>
<date>2003-07-29</date>
<initials>psa</initials>
<remark><p>Incorporated Standards JIG feedback; changed document type to Informational.</p></remark>
<remark><p>Incorporated Standards list feedback; changed document type to Informational.</p></remark>
</revision>
<revision>
<version>0.1</version>

8
xep-0081.xml
View File

@ -12,7 +12,7 @@
<number>0081</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
@ -205,9 +205,9 @@ Encoding considerations: Same as encoding considerations of
of RFC 3920, the encoding must be UTF-8.
Security considerations: All of the security considerations
specified in RFC 3023 and RFC 3920 apply to this XML media
type. Refer to Section 11 of JSF XEP-0081.
type. Refer to Section 11 of XSF XEP-0081.
Interoperability considerations: (none)
Specification: JSF XEP-0081
Specification: XSF XEP-0081
Applications which use this media type: non-XMPP applications
(e.g., web browsers or email clients) that wish to invoke
XMPP-compliant applications for instant messaging and
@ -218,7 +218,7 @@ Additional information: This media type is not to be confused
Person and email address to contact for further information:
XMPP Registrar, <registrar@jabber.org>
Intended usage: COMMON
Author/Change controller: JSF, XMPP Registrar
Author/Change controller: XSF, XMPP Registrar
]]></code>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>

4
xep-0082.xml
View File

@ -12,7 +12,7 @@
<number>0082</number>
<status>Active</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>ISO 8601</spec>
@ -133,7 +133,7 @@
</code>
<p>The primary standard notation recommended by ISO 8601 includes the separators ("-" for dates and ":" for times), although ISO 8601 allows omission of the separators for applications in which compactness is more important than human readability. It is arguable whether Jabber applications using 'jabber:iq:time' and 'jabber:x:delay' require such compactness, but these protocols are in wide use today and have been implemented using the format shown above. Therefore, applications receiving data in those namespaces SHOULD be liberal in what they accept by handling datetimes either in the "CCYYMMDDThh:mm:ss" format or in the lexical representation defined in XML Schema and specified by this document. Applications generating data in those namespaces SHOULD use the existing format ("CCYYMMDDThh:mm:ss"), and are effectively "grandfathered" with respect to the date and time formats defined herein. While eventually it would be good to deprecate the older datetime representation for these protocols, the schedule for such deprecation (if any) shall be specified in official XEPs for these older protocols.</p>
<p>Jabber-RPC is a special case, since the specification for &xmlrpc; includes only one example for datetimes, which is of the format "CCYYMMDDThh:mm:ss". Apparently many implementations of XML-RPC have taken this lexical representation as canonical, and do not support any other representation; because Jabber-RPC normally provides an interface to software that is outside the Jabber network, it is prudent for Jabber-RPC implementations to generate dates in the format shown in the XML-RPC specification, not that defined in this document.</p>
<p>New protocols approved by the Jabber Software Foundation MUST use the lexical representations defined in this document.</p>
<p>New protocols approved by the XMPP Standards Foundation MUST use the lexical representations defined in this document.</p>
</section1>
<section1 topic='Implementation Notes'>
<p>The 'date', 'dateTime', and 'time' datatypes defined in XML Schema address several "edge cases" such as dates before the year 0000 and after the year 9999, as well as odd timezones no longer in use; most Jabber applications can safely ignore these edge cases, since it is highly unlikely that a Jabber entity will generate such representations.</p>

2
xep-0083.xml
View File

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

12
xep-0084.xml
View File

@ -10,9 +10,9 @@
<abstract>This document defines an XMPP protocol extension for exchanging user avatars.</abstract>
&LEGALNOTICE;
<number>0084</number>
<status>Experimental</status>
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0030</spec>
@ -28,6 +28,12 @@
&pgmillard;
&temas;
&xvirge;
<revision>
<version>0.9</version>
<date>2007-01-04</date>
<initials>psa</initials>
<remark><p>Updated to reflect pubsub and PEP changes; added implementation notes about multiple resources and avatar synchronization.</p></remark>
</revision>
<revision>
<version>0.8</version>
<date>2006-06-19</date>
@ -555,6 +561,6 @@
</section2>
</section1>
<section1 topic='Author Note' anchor='authornote'>
<p>Peter Millard, a co-author of this specification from version 0.1 through version 0.7, died on April 26, 2006. The remaining authors are thankful for his work on this specification.</p>
<p>Peter Millard, a co-author of this specification from version 0.1 through version 0.7, died on April 26, 2006. The remaining authors are thankful for his work on user avatars.</p>
</section1>
</xep>

2
xep-0085.xml
View File

@ -12,7 +12,7 @@
<number>0085</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-0086.xml
View File

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

2
xep-0087.xml
View File

@ -12,7 +12,7 @@
<number>0087</number>
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>XEP-0030</dependencies>
<supersedes>None</supersedes>
<supersededby>XEP-0095</supersededby>

2
xep-0088.xml
View File

@ -12,7 +12,7 @@
<number>0088</number>
<status>Deferred</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0030</spec>

2
xep-0089.xml
View File

@ -12,7 +12,7 @@
<number>0089</number>
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>None</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>

2
xep-0090.xml
View File

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

2
xep-0091.xml
View File

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

2
xep-0092.xml
View File

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

2
xep-0093.xml
View File

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

2
xep-0094.xml
View File

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

4
xep-0095.xml
View File

@ -12,7 +12,7 @@
<number>0095</number>
<status>Draft</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0030</spec>
@ -308,7 +308,7 @@
</section2>
<section2 topic='Registries' anchor='registrar-reg'>
<section3 topic='Profiles Registry' anchor='registrar-reg-profiles'>
<p>The XMPP Registrar shall maintain a registry of stream initiation profiles, located at &lt;<link url='http://www.jabber.org/registrar/si-profiles.html'>http://www.jabber.org/registrar/si-profiles.html</link>&gt;. Any such profile defined in a XMPP Extension Protocol specification MUST be submitted to the XMPP Registrar; profiles defined in non-standard protocol extensions SHOULD be submitted to the XMPP Registrar.</p>
<p>The XMPP Registrar shall maintain a registry of stream initiation profiles, located at &SIPROFILES;. Any such profile defined in a XMPP Extension Protocol specification MUST be submitted to the XMPP Registrar; profiles defined in non-standard protocol extensions SHOULD be submitted to the XMPP Registrar.</p>
<section4 topic='Process' anchor='registrar-reg-profiles-process'>
&REGPROCESS;
<code><![CDATA[

2
xep-0096.xml
View File

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

4
xep-0097.xml
View File

@ -12,7 +12,7 @@
<number>0097</number>
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards</jig>
<sig>Standards</sig>
<dependencies>XEP-0030</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
@ -89,7 +89,7 @@
SEQUENCE:3
SUMMARY:XEPs
LOCATION:foundation@conference.jabber.org
CATEGORIES:JSF
CATEGORIES:XSF
CLASS:PUBLIC
TRANSP:OPAQUE
LAST-MODIFIED:20030418T014527Z

2
xep-0098.xml
View File

@ -12,7 +12,7 @@
<number>0098</number>
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>None</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>

2
xep-0099.xml
View File

@ -12,7 +12,7 @@
<number>0099</number>
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<dependencies>None</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>

2
xep-0100.xml
View File

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

Some files were not shown because too many files have changed in this diff Show More