From 29bee13867aa6dbd22d501dfaf34b1c7f49e959d Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Mon, 15 Jan 2007 03:38:19 +0000 Subject: [PATCH] XSF/SIG cleanup git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@320 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0001.xml | 80 ++++++++++++++++++++++++------------------------ xep-0002.xml | 14 ++++----- xep-0003.xml | 2 +- xep-0004.xml | 6 ++-- xep-0005.xml | 2 +- xep-0006.xml | 16 +++++----- xep-0007.xml | 10 +++--- xep-0008.xml | 4 +-- xep-0009.xml | 2 +- xep-0010.xml | 14 ++++----- xep-0011.xml | 2 +- xep-0012.xml | 2 +- xep-0013.xml | 2 +- xep-0014.xml | 2 +- xep-0015.xml | 2 +- xep-0016.xml | 2 +- xep-0017.xml | 2 +- xep-0018.xml | 2 +- xep-0019.xml | 48 ++++++++++++++--------------- xep-0020.xml | 2 +- xep-0021.xml | 4 +-- xep-0022.xml | 2 +- xep-0023.xml | 4 +-- xep-0024.xml | 4 +-- xep-0025.xml | 2 +- xep-0026.xml | 4 +-- xep-0027.xml | 2 +- xep-0028.xml | 2 +- xep-0029.xml | 2 +- xep-0030.xml | 10 +++--- xep-0031.xml | 4 +-- xep-0032.xml | 2 +- xep-0033.xml | 2 +- xep-0034.xml | 4 +-- xep-0035.xml | 4 +-- xep-0036.xml | 4 +-- xep-0037.xml | 2 +- xep-0038.xml | 4 +-- xep-0039.xml | 2 +- xep-0040.xml | 2 +- xep-0041.xml | 4 +-- xep-0042.xml | 4 +-- xep-0043.xml | 2 +- xep-0044.xml | 2 +- xep-0045.xml | 6 ++-- xep-0046.xml | 4 +-- xep-0047.xml | 2 +- xep-0048.xml | 2 +- xep-0049.xml | 2 +- xep-0050.xml | 2 +- xep-0051.xml | 2 +- xep-0052.xml | 4 +-- xep-0053.xml | 18 +++++------ xep-0054.xml | 12 ++++---- xep-0055.xml | 2 +- xep-0056.xml | 2 +- xep-0057.xml | 4 +-- xep-0058.xml | 2 +- xep-0059.xml | 2 +- xep-0060.xml | 2 +- xep-0061.xml | 2 +- xep-0062.xml | 2 +- xep-0063.xml | 2 +- xep-0064.xml | 2 +- xep-0065.xml | 2 +- xep-0066.xml | 2 +- xep-0067.xml | 2 +- xep-0068.xml | 10 +++--- xep-0069.xml | 27 +++++++--------- xep-0070.xml | 2 +- xep-0071.xml | 26 ++++++++-------- xep-0072.xml | 6 ++-- xep-0073.xml | 4 +-- xep-0074.xml | 2 +- xep-0075.xml | 2 +- xep-0076.xml | 4 +-- xep-0077.xml | 2 +- xep-0078.xml | 2 +- xep-0079.xml | 8 ++--- xep-0080.xml | 4 +-- xep-0081.xml | 8 ++--- xep-0082.xml | 4 +-- xep-0083.xml | 2 +- xep-0084.xml | 12 ++++++-- xep-0085.xml | 2 +- xep-0086.xml | 2 +- xep-0087.xml | 2 +- xep-0088.xml | 2 +- xep-0089.xml | 2 +- xep-0090.xml | 2 +- xep-0091.xml | 2 +- xep-0092.xml | 2 +- xep-0093.xml | 2 +- xep-0094.xml | 2 +- xep-0095.xml | 4 +-- xep-0096.xml | 2 +- xep-0097.xml | 4 +-- xep-0098.xml | 2 +- xep-0099.xml | 2 +- xep-0100.xml | 2 +- xep-0101.xml | 2 +- xep-0102.xml | 2 +- xep-0103.xml | 2 +- xep-0104.xml | 2 +- xep-0105.xml | 2 +- xep-0106.xml | 2 +- xep-0107.xml | 2 +- xep-0108.xml | 2 +- xep-0109.xml | 2 +- xep-0110.xml | 2 +- xep-0111.xml | 2 +- xep-0112.xml | 2 +- xep-0113.xml | 4 +-- xep-0114.xml | 2 +- xep-0115.xml | 2 +- xep-0116.xml | 2 +- xep-0117.xml | 4 +-- xep-0118.xml | 2 +- xep-0119.xml | 6 ++-- xep-0120.xml | 2 +- xep-0121.xml | 2 +- xep-0122.xml | 6 ++-- xep-0123.xml | 4 +-- xep-0124.xml | 2 +- xep-0125.xml | 2 +- xep-0126.xml | 2 +- xep-0127.xml | 2 +- xep-0128.xml | 6 ++-- xep-0129.xml | 2 +- xep-0130.xml | 2 +- xep-0131.xml | 2 +- xep-0132.xml | 4 +-- xep-0133.xml | 2 +- xep-0134.xml | 8 ++--- xep-0135.xml | 2 +- xep-0136.xml | 2 +- xep-0137.xml | 2 +- xep-0138.xml | 4 +-- xep-0139.xml | 22 ++++++------- xep-0140.xml | 2 +- xep-0141.xml | 26 ++++++++-------- xep-0142.xml | 2 +- xep-0143.xml | 18 +++++------ xep-0144.xml | 6 ++-- xep-0145.xml | 2 +- xep-0146.xml | 2 +- xep-0147.xml | 4 +-- xep-0148.xml | 2 +- xep-0149.xml | 2 +- xep-0150.xml | 2 +- xep-0151.xml | 2 +- xep-0152.xml | 2 +- xep-0153.xml | 2 +- xep-0154.xml | 6 ++-- xep-0155.xml | 2 +- xep-0156.xml | 2 +- xep-0157.xml | 2 +- xep-0158.xml | 2 +- xep-0159.xml | 2 +- xep-0160.xml | 2 +- xep-0161.xml | 2 +- xep-0162.xml | 4 +-- xep-0163.xml | 2 +- xep-0164.xml | 2 +- xep-0165.xml | 2 +- xep-0166.xml | 6 ++-- xep-0167.xml | 2 +- xep-0168.xml | 2 +- xep-0169.xml | 2 +- xep-0170.xml | 2 +- xep-0171.xml | 2 +- xep-0172.xml | 2 +- xep-0173.xml | 2 +- xep-0174.xml | 2 +- xep-0175.xml | 2 +- xep-0176.xml | 2 +- xep-0177.xml | 2 +- xep-0178.xml | 2 +- xep-0179.xml | 2 +- xep-0180.xml | 2 +- xep-0181.xml | 2 +- xep-0182.xml | 4 +-- xep-0183.xml | 2 +- xep-0184.xml | 6 ++-- xep-0185.xml | 2 +- xep-0186.xml | 2 +- xep-0187.xml | 2 +- xep-0188.xml | 2 +- xep-0189.xml | 2 +- xep-0190.xml | 2 +- xep-0191.xml | 20 ++++++++++-- xep-0192.xml | 4 +-- xep-0193.xml | 2 +- xep-0194.xml | 2 +- xep-0195.xml | 2 +- xep-0196.xml | 2 +- xep-0197.xml | 2 +- xep-0198.xml | 2 +- xep-0199.xml | 2 +- xep-0200.xml | 2 +- xep-0201.xml | 2 +- xep-0202.xml | 2 +- xep-0203.xml | 2 +- xep-README.xml | 10 +++--- xep-template.xml | 4 +-- 205 files changed, 451 insertions(+), 436 deletions(-) diff --git a/xep-0001.xml b/xep-0001.xml index 2e666640..a6e475d1 100644 --- a/xep-0001.xml +++ b/xep-0001.xml @@ -7,12 +7,12 @@
XMPP Extension Protocols - This document defines the standards process followed by the Jabber Software Foundation. + This document defines the standards process followed by the XMPP Standards Foundation. &LEGALNOTICE; 0001 Active Procedural - None + None Board @@ -29,7 +29,7 @@ 1.17 2006-10-04 psa -

As approved by the members of the Jabber Software Foundation, changed Jabber Enhancement Proposal to XMPP Extension Protocol.

 +

As approved by the members of the XMPP Standards Foundation, changed Jabber Enhancement Proposal to XMPP Extension Protocol.

 1.16 @@ -47,7 +47,7 @@ 1.14 2004-09-28 psa -

Defined Procedural type as the union of JIG Formation type and certain Informational specifications in order to clarify the categories; added Modifications to Approved Specifications section in order to make explicit existing Council practices regarding Active and Final specifications; specified that documents on which voting was not complete at the end of a Council term shall undergo a second Last Call and subsequent vote by the new Council; modified Proposal Process to specify that the Jabber Council shall issue Last Calls on documents for which it is the approving body, with all discussion to occur on the Standards-JIG list; updated the schema.

 +

Defined Procedural type as the union of SIG Formation type and certain Informational specifications in order to clarify the categories; added Modifications to Approved Specifications section in order to make explicit existing Council practices regarding Active and Final specifications; specified that documents on which voting was not complete at the end of a Council term shall undergo a second Last Call and subsequent vote by the new Council; modified Proposal Process to specify that the Jabber Council shall issue Last Calls on documents for which it is the approving body, with all discussion to occur on the Standards list; updated the schema.

 1.13 @@ -89,13 +89,13 @@ 1.6 2003-01-08 psa -

Further clarified the proposal process per discussion on the JSF members list.

 +

Further clarified the proposal process per discussion on the members list.

 1.5 2002-10-29 psa -

Major revision based on experience. In addition to a reorganization of the content to improve the clarity of the presentation, changes include: (1) no anonymous authors; (2) proposal must be seconded by at least 5% of JSF members before being proposed for a Council vote; (3) clarification that the Council votes only on a particular revision of a specification (e.g., version 1.3 when proceeding from Draft to Final); (4) added information about the "Call for Experience" phase before proceeding from Draft to Final; (5) added reference to RFC 2119; (6) added sections for security considerations, IANA considerations, and XMPP Registrar considerations. Approved by the JSF Board and Jabber Council on 2002-11-20.

 +

Major revision based on experience. In addition to a reorganization of the content to improve the clarity of the presentation, changes include: (1) no anonymous authors; (2) proposal must be seconded by at least 5% of XSF members before being proposed for a Council vote; (3) clarification that the Council votes only on a particular revision of a specification (e.g., version 1.3 when proceeding from Draft to Final); (4) added information about the "Call for Experience" phase before proceeding from Draft to Final; (5) added reference to RFC 2119; (6) added sections for security considerations, IANA considerations, and XMPP Registrar considerations. Approved by the XSF Board and Jabber Council on 2002-11-20.

 1.4 @@ -125,7 +125,7 @@ 1.1 2001-09-09 psa -

(1) Changed "Jabber Foundation" to "Jabber Software Foundation"; (2) Changed "JIG Proposal" to "JIG Formation"; (3) Removed reference to the Secretary of the Jabber Software Foundation in connection with the role of Editor; (4) Clarified the possible states of acceptance of each kind of specification and described in greater detail the criteria for advancement from one state to another.

 +

(1) Changed "Jabber Foundation" to "XMPP Standards Foundation"; (2) Changed "SIG Proposal" to "SIG Formation"; (3) Removed reference to the Secretary of the XMPP Standards Foundation in connection with the role of Editor; (4) Clarified the possible states of acceptance of each kind of specification and described in greater detail the criteria for advancement from one state to another.

 1.0 @@ -141,10 +141,10 @@
-

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, Effectively the only such exceptions are protocols that were superseded by RFC 3920 and RFC 3921. 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. 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 PEP-1). 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. 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. The term "XEP" is normally pronounced "zepp".

+

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, Effectively the only such exceptions are protocols that were superseded by RFC 3920 and RFC 3921. 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. 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 PEP-1). 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. 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. The term "XEP" is normally pronounced "zepp".

 -

The Jabber Software Foundation was founded in the year 2001 to openly document, safeguard, manage, and extend the wire protocols used within the Jabber/XMPP developer community. The work of the Jabber Software Foundation has several objectives:

+

The XMPP Standards Foundation was founded in the year 2001 to openly document, safeguard, manage, and extend the wire protocols used within the Jabber/XMPP developer community. The work of the XMPP Standards Foundation has several objectives:

  1. 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.
  2. To document XMPP extensions in a clear, concise manner so that the task of implementing the protocols is straightforward.
    3. @@ -162,7 +162,7 @@

    A Standards Track XEP defines one of the following:

    1. A wire protocol intended to be used as a standard part of Jabber/XMPP technologies. - 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 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).
    2. A protocol suite that determines conformance requirements (e.g., &xep0073;).
    @@ -175,34 +175,34 @@
-

An Historical XEP documents a protocol that was developed before the JSF's standards process was instituted, but that is still in use within the Jabber/XMPP developer community; such a XEP may or may not be obsoleted by a Standards Track XEP, or upgraded to Standards Track.

+

An Historical XEP documents a protocol that was developed before the XSF's standards process was instituted, but that is still in use within the Jabber/XMPP developer community; such a XEP may or may not be obsoleted by a Standards Track XEP, or upgraded to Standards Track.

A Humorous XEP attempts to be funny by defining a protocol that would never be used in the real world; such XEPs are usually published on April 1 and automatically have a status of Active.

 -

A Procedural XEP defines a process or activity to be followed by the JSF, including JIG charters as specified by &xep0002;.

+

A Procedural XEP defines a process or activity to be followed by the XSF, including SIG charters as specified by &xep0002;.

 -

The JSF welcomes and encourages the submission of protocols to the JSF's standards process. 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. 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 <http://www.xmpp.org/extensions/submit.shtml>). All inquiries related to the JSF's standards process, and all submissions, should be directed to the &EDITOR;.

-

Note well that XEP authors must transfer ownership of their protocols (but not implementations thereof) to the JSF. Refer to the &JSFIPR; for details. XEP authors must make sure that they have read, understood, and agreed to the JSF IPR Policy before submitting a proposal to the XMPP Extensions Editor!

-

All proposals submitted to the JSF for consideration as XEPs must contain the following information:

+

The XSF welcomes and encourages the submission of protocols to the XSF's standards process. 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. 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 <http://www.xmpp.org/extensions/submit.shtml>). All inquiries related to the XSF's standards process, and all submissions, should be directed to the &EDITOR;.

+

Note well that XEP authors must transfer ownership of their protocols (but not implementations thereof) to the XSF. Refer to the &XSFIPR; for details. XEP authors must make sure that they have read, understood, and agreed to the XSF IPR Policy before submitting a proposal to the XMPP Extensions Editor!

+

All proposals submitted to the XSF for consideration as XEPs must contain the following information:

    -

  1. Legal Notice -- the legal notice must be exactly that which is specified in the JSF IPR Policy

    2. +

  2. Legal Notice -- the legal notice must be exactly that which is specified in the XSF IPR Policy

  3. Author Information -- first name, last name, email address, and Jabber ID are all required and must be provided for all authors

Finally, Standards Track, Informational, and Historical XEPs must conform to &rfc2119; in the use of terminology regarding requirements levels.

 -

The approving body for almost all XEPs is the XMPP Council; therefore, in order to be published as a XEP, a proposal must first be accepted by the XMPP Council (the only exceptions are certain kinds of Procedural XEPs, for which the approving body may be the JSF Board of Directors and which may be accepted for publication by the XMPP Extensions Editor in consultation with the Board). Upon receiving a proposal, the XMPP Extensions Editor shall do the following:

+

The approving body for almost all XEPs is the XMPP Council; therefore, in order to be published as a XEP, a proposal must first be accepted by the XMPP Council (the only exceptions are certain kinds of Procedural XEPs, for which the approving body may be the XSF Board of Directors and which may be accepted for publication by the XMPP Extensions Editor in consultation with the Board). Upon receiving a proposal, the XMPP Extensions Editor shall do the following:

  • ensure that its format is correct
  • publish it to <http://www.xmpp.org/extensions/inbox/>
    • -
  • publicly announce its existence by sending a message to the discussion list of the &SJIG;
    • +
  • publicly announce its existence by sending a message to the discussion list of the &SSIG;
  • request acceptance of the proposal as a XEP by the XMPP Council
-

If no member of the XMPP Council objects to publication of the proposal within seven (7) days or at the next meeting of the Council, the XMPP Extensions Editor shall accept it as a XEP. If objections are raised by the Council on the Standards-JIG list or in its meeting, the XEP author is encouraged to address the feedback of the Council and to submit a revised version of the proposal and/or confer with the XMPP Extensions Editor or objecting Council member(s) regarding how to proceed.

+

If no member of the XMPP Council objects to publication of the proposal within seven (7) days or at the next meeting of the Council, the XMPP Extensions Editor shall accept it as a XEP. If objections are raised by the Council on the Standards list or in its meeting, the XEP author is encouraged to address the feedback of the Council and to submit a revised version of the proposal and/or confer with the XMPP Extensions Editor or objecting Council member(s) regarding how to proceed.

If the proposal is accepted as a XEP, the XMPP Extensions Editor shall do the following:

  • assign it a number
    • @@ -211,25 +211,25 @@
  • add it to source control 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 <http://www.jabberstudio.org/cvs.php>, and a web interface to these files is available at <http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/xmpp/extensions/>.
  • add tracking information to the XEPs database
  • publish version 0.1 of the XEP to the xmpp.org website The canonical URL for accessing XMPP Extensions is <http://www.xmpp.org/extensions/>.
    • -
  • publicly announce the existence of the XEP by sending a message to the Standards-JIG list
    • +
  • publicly announce the existence of the XEP by sending a message to the Standards list
-

Note well that no special criteria (other than acceptance by the XMPP Council and minimal formatting compliance) need to be met in order for a XEP to be granted a status of Experimental. The granting of Experimental status must not be construed as indicating any level of approval by the JSF, the XMPP Council, or the Jabber/XMPP developer community. Implementation of Experimental XEPs is encouraged in an exploratory fashion (e.g., in a proof of concept) in order to gain experience with and iteratively improve the protocol defined therein, but such implementations may not be appropriate for deployment in production systems.

+

Note well that no special criteria (other than acceptance by the XMPP Council and minimal formatting compliance) need to be met in order for a XEP to be granted a status of Experimental. The granting of Experimental status must not be construed as indicating any level of approval by the XSF, the XMPP Council, or the Jabber/XMPP developer community. Implementation of Experimental XEPs is encouraged in an exploratory fashion (e.g., in a proof of concept) in order to gain experience with and iteratively improve the protocol defined therein, but such implementations may not be appropriate for deployment in production systems.

 -

Once a XEP is published, it becomes available for public discussion within the Standards JIG and the broader Jabber/XMPP developer community. The XEP author is responsible for collecting feedback from the Jabber/XMPP developer community during the life of the XEP and for incorporating such feedback into the proposal. In order to fully participate in discussion of the proposal, the XEP author should be subscribed to the Standards-JIG list, which is the primary venue for discussion of XMPP Extension Protocols. Changes made based on feedback received by the XEP author must be captured in updated versions of the XEP (e.g., 0.2 after 0.1), each of which must be put under source control and subsequently published and announced by the XMPP Extensions Editor.

+

Once a XEP is published, it becomes available for public discussion within the Standards SIG and the broader Jabber/XMPP developer community. The XEP author is responsible for collecting feedback from the Jabber/XMPP developer community during the life of the XEP and for incorporating such feedback into the proposal. In order to fully participate in discussion of the proposal, the XEP author should be subscribed to the Standards list, which is the primary venue for discussion of XMPP Extension Protocols. Changes made based on feedback received by the XEP author must be captured in updated versions of the XEP (e.g., 0.2 after 0.1), each of which must be put under source control and subsequently published and announced by the XMPP Extensions Editor.

If an Experimental XEP is inactive (i.e., no updated versions are published) for a period of six (6) months, the XMPP Extensions Editor shall automatically change the status of the XEP to Deferred unless it is in the queue of XEPs under active consideration for advancement by the XMPP Council; upon submission of an updated version, the XMPP Extensions Editor shall change the status back to Experimental.

 -

Before an Experimental XEP may be proposed to the XMPP Council for advancement to Draft (Standards Track XEPs) or Active (Historical, Informational, and Procedural XEPs), the XMPP Council must agree that the XEP is ready to be considered for advancement. Once the Council so agrees, it shall instruct the XMPP Extensions Editor to (1) change the status of the XEP from Experimental to Proposed and (2) issue a Last Call for open discussion on the Standards JIG list. The Last Call shall expire not less than 10 days after the date of issue.

-

Once the consensus of the Standards JIG has been incorporated into the XEP and all issues of substance raised during the Last Call have been addressed by the XEP author, the XMPP Extensions Editor shall formally propose a specific revision of the XEP to the XMPP Council for its vote. If necessary, the XMPP Extensions Editor may, at his discretion and in consultation with the XMPP Council, extend the Last Call or issue a new Last Call if the XEP requires further discussion.

-

Last Calls regarding Procedural XEPs for which the approving body is the JSF Board of Directors may be issued directly by the XMPP Extensions Editor once instructed by the Board.

+

Before an Experimental XEP may be proposed to the XMPP Council for advancement to Draft (Standards Track XEPs) or Active (Historical, Informational, and Procedural XEPs), the XMPP Council must agree that the XEP is ready to be considered for advancement. Once the Council so agrees, it shall instruct the XMPP Extensions Editor to (1) change the status of the XEP from Experimental to Proposed and (2) issue a Last Call for open discussion on the Standards list. The Last Call shall expire not less than 10 days after the date of issue.

+

Once the consensus of the Standards SIG has been incorporated into the XEP and all issues of substance raised during the Last Call have been addressed by the XEP author, the XMPP Extensions Editor shall formally propose a specific revision of the XEP to the XMPP Council for its vote. If necessary, the XMPP Extensions Editor may, at his discretion and in consultation with the XMPP Council, extend the Last Call or issue a new Last Call if the XEP requires further discussion.

+

Last Calls regarding Procedural XEPs for which the approving body is the XSF Board of Directors may be issued directly by the XMPP Extensions Editor once instructed by the Board.

After a XEP has been proposed to the XMPP Council, any change in its status shall be determined by a vote of the XMPP Council. All members of the Council must vote, with the possible values being +1 (approve), 0 (neutral), or -1 (disapprove, with reasons). A XEP shall not be advanced to the next stage in the approval process so long as any Council Member continues to vote -1; that Council Member's written concerns must be addressed in order for the XEP to advance. A majority of Council members must vote +1 in order for a XEP to advance. (Additional voting policies, such as voting periods and defaults if a member does not vote, may be set by the XMPP Council.) A vote of the XMPP Council is final and binding, although a XEP author is free to address the concerns of the Council and to resubmit the XEP for future consideration.

-

If the XMPP Council does not complete voting on a XEP before the end of its term, the XMPP Extensions Editor shall issue a new Last Call on the Standards JIG list and the newly-elected Council shall vote anew on the XEP after completion of the Last Call. This provides an opportunity for any member of the previous Council who had voted -1 to voice his or her concerns in a public forum before the new Council votes on the XEP.

+

If the XMPP Council does not complete voting on a XEP before the end of its term, the XMPP Extensions Editor shall issue a new Last Call on the Standards list and the newly-elected Council shall vote anew on the XEP after completion of the Last Call. This provides an opportunity for any member of the previous Council who had voted -1 to voice his or her concerns in a public forum before the new Council votes on the XEP.

A vote of the XMPP Council applies only to the specific revision of the XEP that has been presented to it. Further revisions may need to be re-submitted for approval.

-

Any change in the status of a XEP must be announced on the Standards-JIG list by the XMPP Extensions Editor. If a XEP advances to a status of Final, it shall be so announced and also published as one of the official JSF protocols A list of official JSF protocols is maintained at <http://www.xmpp.org/protocol>. on the website of the Jabber Software Foundation.

-

Approval of Procedural XEPs for which the approving body is the JSF Board of Directors shall occur upon approval by the Board in accordance with the rules defined in the &BYLAWS;.

+

Any change in the status of a XEP must be announced on the Standards list by the XMPP Extensions Editor. If a XEP advances to a status of Final, it shall be so announced and also published as one of the official XSF protocols A list of official XSF protocols is maintained at <http://www.xmpp.org/protocol>. on the website of the XMPP Standards Foundation.

+

Approval of Procedural XEPs for which the approving body is the XSF Board of Directors shall occur upon approval by the Board in accordance with the rules defined in the &BYLAWS;.

More detailed information about the approval process is provided below, including criteria for Standards Track XEPs and for Historical, Informational, and Procedural XEPs.

The possible states for a Standards Track XEP are as follows:

@@ -248,21 +248,21 @@ Experimental ----> Proposed ----> Draft ----> Final

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.

Note: An Experimental specification is a work in progress and may undergo significant modification before advancing to a status of Draft. While implementation of an Experimental protocol is encouraged in order to determine the feasibility of the proposed solution, it is not recommended for such implementations to be included in the primary release for a software product (as opposed to an experimental branch).

-

The ideal path is for a Standards Track XEP is to be advanced by the XMPP Council from Proposed to Draft to Final (the criteria for this advancement are described in the following paragraphs). However, an Experimental XEP shall be assigned a status of Deferred if it has not been updated in six (6) months (e.g., because of a lack of interest or because it depends on other specifications that have yet to move forward). In addition, rather than being advanced from Proposed to Draft, a Standards Track XEP may be voted to a status of Rejected if the XMPP Council deems it unacceptable. (Note that if a XEP is Deferred, the XMPP Extensions Editor may at some point re-assign it to Experimental status, and that, even if a XEP is Rejected, it is retained in source control and on the Jabber Software Foundation website for future reference.) Finally, a XEP author may voluntarily remove an Experimental XEP from further consideration, resulting in a status of Retracted.

+

The ideal path is for a Standards Track XEP is to be advanced by the XMPP Council from Proposed to Draft to Final (the criteria for this advancement are described in the following paragraphs). However, an Experimental XEP shall be assigned a status of Deferred if it has not been updated in six (6) months (e.g., because of a lack of interest or because it depends on other specifications that have yet to move forward). In addition, rather than being advanced from Proposed to Draft, a Standards Track XEP may be voted to a status of Rejected if the XMPP Council deems it unacceptable. (Note that if a XEP is Deferred, the XMPP Extensions Editor may at some point re-assign it to Experimental status, and that, even if a XEP is Rejected, it is retained in source control and on the XMPP Standards Foundation website for future reference.) Finally, a XEP author may voluntarily remove an Experimental XEP from further consideration, resulting in a status of Retracted.

In order for a Standards Track XEP to advance from Proposed to Draft, it must:

  1. fill known gaps in Jabber/XMPP technologies or deficiencies with existing protocols
  2. 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
  3. document any known security considerations with the proposed technology
  4. be generally stable and appropriate for further field experience
    5. -
  5. have achieved rough consensus (though not necessarily unanimity) within the Standards JIG
    6. +
  6. have achieved rough consensus (though not necessarily unanimity) within the Standards SIG
  7. be formally defined by an XML schema
  8. receive the requisite votes from the XMPP Council

Elevation to Draft status (version 1.0) is a major advancement for the XEP, indicating a strong sense on the part of the XMPP Council and Jabber/XMPP developer community that the specification will be of lasting value.

Note: Once an XMPP Extension Protocol has been advanced to a status of Draft, it is expected that the specification will be basis for widespread implementation and for deployment in production environments. As a result of such implementation and deployment experience, the protocol may be subject to modification, including changes that are backwards-incompatible. Although such backwards-incompatible modifications shall be avoided if at all possible, deployment of a Draft protocol in mission-critical application may not be advisable.

-

Any proposed changes to a Draft XEP must be provisionally published at <http://www.xmpp.org/extensions/tmp/>, announced and discussed on the Standards-JIG mailing list, and formally approved by the XMPP Council before being officially published at the canonical URL for the XEP.

-

In order for a XEP to advance from Draft status to Final status (version 2.0), it must be shown to be stable and well-received by the Jabber/XMPP developer community. Before presenting a Draft standard to the XMPP Council for consideration as a Final standard, the XMPP Extensions Editor shall issue a Call for Experience on the Standards-JIG list so that feedback can be gathered from those who have implemented the Draft standard (the Call for Experience shall expire not less than 14 days after the date of issue, and shall not be issued until at least 60 days have passed since advancement to Draft). In addition, at least two implementations of the XEP must exist, at least one of which must be free software (in accordance with the &GPL; or &LGPL;) or open-source software (in accordance with the definition provided by &OSI;). Until two implementations are produced, a Standards Track XEP shall retain a status of Draft. Once (1) two implementations have been presented to the XMPP Council, (2) feedback provided during the Call for Experience has been incorporated into the XEP, and (3) the XEP has been fully checked for accuracy, the status of the XEP may be changed to Final upon a vote of the Council.

+

Any proposed changes to a Draft XEP must be provisionally published at <http://www.xmpp.org/extensions/tmp/>, announced and discussed on the Standards mailing list, and formally approved by the XMPP Council before being officially published at the canonical URL for the XEP.

+

In order for a XEP to advance from Draft status to Final status (version 2.0), it must be shown to be stable and well-received by the Jabber/XMPP developer community. Before presenting a Draft standard to the XMPP Council for consideration as a Final standard, the XMPP Extensions Editor shall issue a Call for Experience on the Standards list so that feedback can be gathered from those who have implemented the Draft standard (the Call for Experience shall expire not less than 14 days after the date of issue, and shall not be issued until at least 60 days have passed since advancement to Draft). In addition, at least two implementations of the XEP must exist, at least one of which must be free software (in accordance with the &GPL; or &LGPL;) or open-source software (in accordance with the definition provided by &OSI;). Until two implementations are produced, a Standards Track XEP shall retain a status of Draft. Once (1) two implementations have been presented to the XMPP Council, (2) feedback provided during the Call for Experience has been incorporated into the XEP, and (3) the XEP has been fully checked for accuracy, the status of the XEP may be changed to Final upon a vote of the Council.

Note: Once an XMPP Extension Protocol has been advanced to a status of Final, every effort shall be made to limit the scope of modifications; in particular, backwards-incompatible changes shall not be made. However, limited modifications may be made as long as they are optional, backwards-compatible extensions rather than modifications to the core protocol itself. Therefore, a Final protocol is safe for deployment in mission-critical applications.

A Standards Track XEP that has been advanced to a status of Final may be superseded by a future XEP approved by the XMPP Council. In such cases, the status of the earlier XEP shall be changed to Deprecated, possibly with an expiration date assigned by the XMPP Council (see the Expiration Dates section below). After a reasonable period of time or upon the passing of the expiration date, the status of the XEP shall be changed to Obsolete.

 @@ -289,14 +289,14 @@ Experimental ----> Proposed ----> Active

The possible states for a XEP are summarized in the following sections.

-

A XEP of any type is in the Experimental state after it has been accepted by the XMPP Council and published by the Jabber Software Foundation but before it has advanced within the standards process to a state of Active or Draft.

+

A XEP of any type is in the Experimental state after it has been accepted by the XMPP Council and published by the XMPP Standards Foundation but before it has advanced within the standards process to a state of Active or Draft.

Note: An Experimental specification is a work in progress and may undergo significant modification before advancing to a status of Draft. While implementation of an Experimental protocol is encouraged in order to determine the feasibility of the proposed solution, it is not recommended for such implementations to be included in the primary release for a software product (as opposed to an experimental branch).

A XEP of any type is in the Proposed state while it is in Last Call or under consideration by the XMPP Council for advancement from Experimental to Draft or Active.

 -

A Standards Track XEP is in the Draft state after it has undergone extensive discussion and technical review on the Standards-JIG list and has been voted forward on the standards track by the XMPP Council.

+

A Standards Track XEP is in the Draft state after it has undergone extensive discussion and technical review on the Standards list and has been voted forward on the standards track by the XMPP Council.

Note: Once an XMPP Extension Protocol has been advanced to a status of Draft, it is expected that the specification will be basis for widespread implementation and for deployment in production environments. As a result of such implementation and deployment experience, the protocol may be subject to modification, including changes that are backwards-incompatible. Although such backwards-incompatible modifications shall be avoided if at all possible, deployment of a Draft protocol in mission-critical application may not be advisable.

 @@ -310,7 +310,7 @@ Experimental ----> Proposed ----> Active

An Experimental XEP of any type is changed to the Deferred state if it has not been updated in six (6) months.

 -

A XEP of any type is in the Retracted state if the authors have asked the XMPP Extensions Editor to remove the XEP from further consideration in the JSF's standards process.

+

A XEP of any type is in the Retracted state if the authors have asked the XMPP Extensions Editor to remove the XEP from further consideration in the XSF's standards process.

A XEP of any type is in the Rejected state if the XMPP Council has deemed it unacceptable and has voted to not move it forward within the standards process.

@@ -323,10 +323,10 @@ Experimental ----> Proposed ----> Active -

Sometimes it is necessary to modify XEPs that have received final approval by the XMPP Council or JSF Board of Directors (e.g., to correct errors, incorporate the lessons of experience, or document new security concerns). This section describes the process for doing so with regard to Standards Track XEPs that have achieved a status of Final and Historical, Informational, and Procedural XEPs that have achieved a status of Active.

-

With regard to Standards Track XEPs, the Jabber Software Foundation (in particular, the XMPP Council) strives to ensure that such XEPs are accurate, complete, and stable before advancing them to a status of Final (corresponding to document version 2.0 of the XEP). The Call for Experience and discussion within the Standards JIG help to ensure this result, but final responsibility rests with the XMPP Council. Despite the best efforts of all concerned, errors are sometimes discovered in Final XEPs (the individual who discovers such an error should inform the Council via the Standards-JIG mailing list or communicate directly with the XMPP Extensions Editor). Whereas other standards development organizations may issue errata while leaving the specification itself unchanged, the JSF makes changes to the Final XEP and publishes a revised document version (e.g., version 2.1). In general the changes are made by the XMPP Extensions Editor or XEP author in consultation with the XMPP Council, discussed within the Standards JIG if appropriate, and agreed upon by the full XMPP Council. Upon agreement regarding the exact changes, the XMPP Council shall instruct the XMPP Extensions Editor to publish a revised version of the XEP and announce the existence of the revised version through the normal channels (e.g., on the JSF website and to the Standards-JIG list). Naturally, if members of the Jabber/XMPP developer community have concerns regarding the changes made, they are free to discuss the matter in the relevant forum (usually the Standards-JIG list) before or after the revised version has been published.

+

Sometimes it is necessary to modify XEPs that have received final approval by the XMPP Council or XSF Board of Directors (e.g., to correct errors, incorporate the lessons of experience, or document new security concerns). This section describes the process for doing so with regard to Standards Track XEPs that have achieved a status of Final and Historical, Informational, and Procedural XEPs that have achieved a status of Active.

+

With regard to Standards Track XEPs, the XMPP Standards Foundation (in particular, the XMPP Council) strives to ensure that such XEPs are accurate, complete, and stable before advancing them to a status of Final (corresponding to document version 2.0 of the XEP). The Call for Experience and discussion within the Standards SIG help to ensure this result, but final responsibility rests with the XMPP Council. Despite the best efforts of all concerned, errors are sometimes discovered in Final XEPs (the individual who discovers such an error should inform the Council via the Standards mailing list or communicate directly with the XMPP Extensions Editor). Whereas other standards development organizations may issue errata while leaving the specification itself unchanged, the XSF makes changes to the Final XEP and publishes a revised document version (e.g., version 2.1). In general the changes are made by the XMPP Extensions Editor or XEP author in consultation with the XMPP Council, discussed within the Standards SIG if appropriate, and agreed upon by the full XMPP Council. Upon agreement regarding the exact changes, the XMPP Council shall instruct the XMPP Extensions Editor to publish a revised version of the XEP and announce the existence of the revised version through the normal channels (e.g., on the XSF website and to the Standards list). Naturally, if members of the Jabber/XMPP developer community have concerns regarding the changes made, they are free to discuss the matter in the relevant forum (usually the Standards list) before or after the revised version has been published.

The process is similar with regard to Historical and Informational XEPs that have achieved a status of Active (corresponding to document version 1.0 of the XEP): the XMPP Council agrees on the exact changes to be made and instructs the XMPP Extensions Editor to publish and announce a revised version (e.g., version 1.1). Here again the XMPP Council bears responsibility for any changes and public discussion is welcome.

-

Procedural XEPs may be modified more frequently as the Jabber Software Foundation gains experience with the processes defined therein. For example, XEP-0001 is modified periodically in order to document processes previously not made explicit or to modify existing processes based on experience with the JSF's standards process; similar changes are sometimes made to the &xep0053; XEP and to various JIG-related XEPs. Changes to these XEPs are discussed by the XMPP Council, JSF Board of Directors, JSF membership, and Standards JIG as appropriate, and exact changes are agreed to by the relevant approving body (XMPP Council or JSF Board of Directors). The approving body then instructs the XMPP Extensions Editor to publish and announce the revised version as described above.

+

Procedural XEPs may be modified more frequently as the XMPP Standards Foundation gains experience with the processes defined therein. For example, XEP-0001 is modified periodically in order to document processes previously not made explicit or to modify existing processes based on experience with the XSF's standards process; similar changes are sometimes made to the &xep0053; XEP and to various SIG-related XEPs. Changes to these XEPs are discussed by the XMPP Council, XSF Board of Directors, XSF membership, and Standards SIG as appropriate, and exact changes are agreed to by the relevant approving body (XMPP Council or XSF Board of Directors). The approving body then instructs the XMPP Extensions Editor to publish and announce the revised version as described above.

In rare cases, a protocol enhancement may be accepted as an interim solution, especially when it is recognized that expected future improvements in technology or the underlying Jabber/XMPP protocols will make possible a much better solution to the problem at hand (e.g., a better protocol for user avatars may be contingent upon the development of a robust protocol for publish/subscribe functionality). In such cases, a XEP may be approved provisionally and be assigned an expiration date.

@@ -345,7 +345,7 @@ Experimental ----> Proposed ----> Active

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.

 -

XMPP Extension Protocol specifications that define official JSF protocols must include a schema that conforms to &w3xmlschema1; and &w3xmlschema2;.

+

XMPP Extension Protocol specifications that define official XSF protocols must include a schema that conforms to &w3xmlschema1; and &w3xmlschema2;.

The schema for the XEP format itself is as follows:

@@ -388,7 +388,7 @@ Experimental ----> Proposed ----> Active - + diff --git a/xep-0002.xml b/xep-0002.xml index 8f65b6d8..58edecf3 100644 --- a/xep-0002.xml +++ b/xep-0002.xml @@ -6,13 +6,13 @@
- Jabber Interest Groups (JIGs) - A definition of Jabber Interest Groups, including their structure and role within the Jabber Software Foundation. + Special Interest Groups (SIGs) + A definition of Special Interest Groups within the XMPP Standards Foundation. &LEGALNOTICE; 0002 Active Procedural - None + None Board @@ -32,11 +32,11 @@
-

A Jabber Interest Group (JIG) is a working group approved by the XMPP Council to address specific areas of growth or concern within the Jabber/XMPP developer community, usually by means of developing and publishing XMPP Extension Protocols (XEPs).

+

A Special Interest Group (SIG) is a working group approved by the XMPP Council to address specific areas of growth or concern within the Jabber/XMPP developer community, usually by means of developing and publishing XMPP Extension Protocols (XEPs).

 -

The main function of most JIGs is to produce acceptable XMPP extensions (delivered in the form of XMPP Extension Protocols or XEPs For information about XMPP Extension Protocols, see http://www.xmpp.org/extensions/xep-0001.html.) within a reasonably limited period of time. However, at the discretion of the XMPP Council, a handful of standing JIGs may be approved (e.g., to address security or standards compliance).

-

Anyone (not limited to members of the Jabber Software Foundation) may propose the formation of a JIG by completing a XMPP Extension Protocol outlining the need for the JIG and its proposed focus. However, JIG leaders must be members of the Jabber Software Foundation. The number of leaders for a JIG is flexible, and shall be determined by each JIG, in consultation with the XMPP Council if necessary. The concept of "membership" with regard to JIGs is loose, and is essentially co-extensive with membership in the appropriate mailing list (each JIG has its own mailing list, which is archived for public review). JIG members do not need to be members of the Jabber Software Foundation, and any member of the general public may subscribe to JIG mailing lists.

-

It is expected that all JIGs (other than certain standing JIGs) will remain active for as long as necessary in order to produce one or more standards-track specifications for review by the XMPP Council in the JIG's area of focus. However, if a JIG does not show signs of activity for an extended period of time (usually six months of inactivity on the JIG's mailing list), the JIG may be disbanded at the discretion of the XMPP Council with appropriate warning to the JIG members (usually in the form of an email sent to the JIG's mailing list).

+

The main function of most SIGs is to produce acceptable XMPP extensions (delivered in the form of XMPP Extension Protocols or XEPs For information about XMPP Extension Protocols, see http://www.xmpp.org/extensions/xep-0001.html.) within a reasonably limited period of time. However, at the discretion of the XMPP Council, a handful of standing SIGs may be approved (e.g., to address security or standards compliance).

+

Anyone (not limited to members of the XMPP Standards Foundation) may propose the formation of a SIG by completing a XMPP Extension Protocol outlining the need for the SIG and its proposed focus. However, SIG leaders must be members of the XMPP Standards Foundation. The number of leaders for a SIG is flexible, and shall be determined by each SIG, in consultation with the XMPP Council if necessary. The concept of "membership" with regard to SIGs is loose, and is essentially co-extensive with membership in the appropriate mailing list (each SIG has its own mailing list, which is archived for public review). SIG members do not need to be members of the XMPP Standards Foundation, and any member of the general public may subscribe to SIG mailing lists.

+

It is expected that all SIGs (other than certain standing SIGs) will remain active for as long as necessary in order to produce one or more standards-track specifications for review by the XMPP Council in the SIG's area of focus. However, if a SIG does not show signs of activity for an extended period of time (usually six months of inactivity on the SIG's mailing list), the SIG may be disbanded at the discretion of the XMPP Council with appropriate warning to the SIG members (usually in the form of an email sent to the SIG's mailing list).

 diff --git a/xep-0003.xml b/xep-0003.xml index 1bc15f22..6de597fd 100644 --- a/xep-0003.xml +++ b/xep-0003.xml @@ -12,7 +12,7 @@ 0003 Active Historical - Standards JIG + Standards XMPP Core diff --git a/xep-0004.xml b/xep-0004.xml index 59624483..9abd889d 100644 --- a/xep-0004.xml +++ b/xep-0004.xml @@ -12,7 +12,7 @@ 0004 Final Standards Track - Standards JIG + Standards XMPP Core @@ -91,7 +91,7 @@ 0.6 2002-03-15 rwe - Protocol tweaks based on standards-jig discussion. + Protocol tweaks based on Standards list discussion. 0.5 @@ -577,7 +577,7 @@

The ®ISTRAR; includes the 'jabber:x:data' namespace in its registry of protocol namespaces.

-

The XMPP Registrar maintains a registry of parameter values related to the 'jabber:x:data' namespace, specifically as defined in &xep0068;; the registry is located at <http://www.jabber.org/registrar/formtypes.html>.

+

The XMPP Registrar maintains a registry of parameter values related to the 'jabber:x:data' namespace, specifically as defined in &xep0068;; the registry is located at &FORMTYPES;.

 diff --git a/xep-0005.xml b/xep-0005.xml index 0d89c0a8..dacf003a 100644 --- a/xep-0005.xml +++ b/xep-0005.xml @@ -12,7 +12,7 @@ 0005 Obsolete Informational - None + None Jeremie Miller diff --git a/xep-0006.xml b/xep-0006.xml index 60669aa3..1e7bc201 100644 --- a/xep-0006.xml +++ b/xep-0006.xml @@ -11,8 +11,8 @@ &LEGALNOTICE; 0006 Obsolete - JIG Formation - Forms, Security + SIG Formation + Forms, Security Adam Theo @@ -66,7 +66,7 @@

Storage is describing and accessing the physical location where the Profiles are kept. It will likely start off being only the Jabber Server, but will eventually allow for remote (specialized network hard drive services) and local (on the User's local machine or a portable floppy) storage. It also describes how this data will be transferred between computers and networks in an efficient and secure manner.

-

This will likely be the most other-JIG dependent part of the system, since we will have to make heavy use of encryption in Jabber, and likely file transfers. So we may want to help out those related JIGs when we get to this point to make sure their results can be used by this system.

+

This will likely be the most other-SIG dependent part of the system, since we will have to make heavy use of encryption in Jabber, and likely file transfers. So we may want to help out those related SIGs when we get to this point to make sure their results can be used by this system.

Gate gives the User complete control at all times of others' access to and power over their Profiles. Since this system is designed to hold the bulk, if not all, of a User's personal information, they *must* have a powerful way to prevent unwanted others to access their data. So there must exist a powerful access regulation framework to precisely control which, when, and how other parties can get this information.

@@ -75,22 +75,22 @@

To make sure this project progresses smoothly and orderly, it has been decided it will be split up into steps, or 'Phases'. Each of the above four aspects will be split into two to four Phases, and the Road-map for the entire project will follow along these Phases. Version 1.0 of the Profiles system will be little more than an expanded vCard schema with simple rules and permissions to regulate access to it. It will progress up to Version 4.0 or 5.0, adding in advanced verification to persuade Services to use a User's Jabber Profiles instead of forcing them to set up a local account, and also adding write permissions so Services can set receipts of purchases and similar information in a User's Account.

-

This Road-map will be produced soon after the JIG is set up, and will give a good feature list and time-line to follow.

+

This Road-map will be produced soon after the SIG is set up, and will give a good feature list and time-line to follow.

Such an improved system would obviously provide for more types of information storage and management, but there are some other side-benefits that can be conceived of.

  • 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.
  • 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.
    • -
  • 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.
    • +
  • 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.
  • 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.
 -

Eventually we would like this Profiles specification to completely replace the strict vCard schema that is 'hard-coded' into the protocol. We do not expect vCard to disappear from Jabber at all, simply be one possible Profile among many in a User's Account. At the end of this JIGs existence, we would like to see it integrate the Profiles and special 'jabber:profiles' namespaces fully into the rest of the Jabber protocol, having it become the method by which all User information (such as Roster, client-side preferences, and filters) is stored and retrieved.

-

It is important to note that this JIG will not be a stand-alone JIG. It will draw upon many other JIGs (that currently exist and that have yet to be created). It will need encryption from the Security JIG for safe transfer of the information, a versatile forms format from the Forms JIG for Profiles administration, and advanced authentication from a future JIG for Services to authenticate the User against their Jabber account.

+

Eventually we would like this Profiles specification to completely replace the strict vCard schema that is 'hard-coded' into the protocol. We do not expect vCard to disappear from Jabber at all, simply be one possible Profile among many in a User's Account. At the end of this SIGs existence, we would like to see it integrate the Profiles and special 'jabber:profiles' namespaces fully into the rest of the Jabber protocol, having it become the method by which all User information (such as Roster, client-side preferences, and filters) is stored and retrieved.

+

It is important to note that this SIG will not be a stand-alone SIG. It will draw upon many other SIGs (that currently exist and that have yet to be created). It will need encryption from the Security SIG for safe transfer of the information, a versatile forms format from the Forms SIG for Profiles administration, and advanced authentication from a future SIG for Services to authenticate the User against their Jabber account.

 -

The concept of Jabber Profiles was started by Eric Murphy and Mike Hearn. They both had begun to come up with similar ideas, but did not meet and exchange ideas until around early 2001. Adam Theo also came across them soon after that, and after some discussion, the three authors of this document agreed to start a serious effort on developing it. We started it as a project at Theoretic Solutions (http://www.theoretic.com/identity/), although at that time it was as a full-fledged identity specification, complete with Profiles, Authentication, and Trust. It was not until we have now moved to set it up as an official JIG that we have split the individual parts up, to make it easier to develop.

+

The concept of Jabber Profiles was started by Eric Murphy and Mike Hearn. They both had begun to come up with similar ideas, but did not meet and exchange ideas until around early 2001. Adam Theo also came across them soon after that, and after some discussion, the three authors of this document agreed to start a serious effort on developing it. We started it as a project at Theoretic Solutions (http://www.theoretic.com/identity/), although at that time it was as a full-fledged identity specification, complete with Profiles, Authentication, and Trust. It was not until we have now moved to set it up as an official SIG that we have split the individual parts up, to make it easier to develop.

 diff --git a/xep-0007.xml b/xep-0007.xml index 617f7ef8..01713b9f 100644 --- a/xep-0007.xml +++ b/xep-0007.xml @@ -6,13 +6,13 @@
- Conferencing JIG + Conferencing SIG A proposal for a Jabber Interest Group that will discuss the protocol for implementing many-to-many communications. &LEGALNOTICE; 0007 Obsolete - JIG Proposal - Conferencing + SIG Proposal + Conferencing David Waite @@ -36,7 +36,7 @@

The following proposal is for the formation of a Jabber Interest Group that will create a new conferencing protocol, as well as create additional functionality and standardize communications on top of said conferencing protocol.

-

The initial task of the Conferencing JIG will be to propose a Jabber Conferencing specification that will solve various problems which exist in the current "groupchat" specification. This specification is meant to be a foundation for additional functionality; it defines the framework needed to provide additional features, without requiring changes to the framework specification itself. There is also to be a certain amount of feature-negotiation included; the conferencing service can define what features can be declared for a room, both as optional and required client features for room participation.

+

The initial task of the Conferencing SIG will be to propose a Jabber Conferencing specification that will solve various problems which exist in the current "groupchat" specification. This specification is meant to be a foundation for additional functionality; it defines the framework needed to provide additional features, without requiring changes to the framework specification itself. There is also to be a certain amount of feature-negotiation included; the conferencing service can define what features can be declared for a room, both as optional and required client features for room participation.

The framework's scope consists of the following minimum functionality:

  • Browsing a list of public rooms
    • @@ -68,6 +68,6 @@

    Because of the prevalence of the existing "groupchat" specification for multi-user chats, a long conversion process is anticipated. A server implementation which supports both protocols will simply not allow "groupchat"-only clients to participate in rooms with required features.

    -

    As listed above, there is a fairly large number of features that could be developed on top of a well-designed framework. The Conferencing JIG will first be established to develop a framework, with features mainly being compared against the framework for feasibility of implementation. After a proposal has been formalized as a specification, the JIG will become a group for discussing and proposing new features, and for formally specifying those features.

    +

    As listed above, there is a fairly large number of features that could be developed on top of a well-designed framework. The Conferencing SIG will first be established to develop a framework, with features mainly being compared against the framework for feasibility of implementation. After a proposal has been formalized as a specification, the SIG will become a group for discussing and proposing new features, and for formally specifying those features.

     diff --git a/xep-0008.xml b/xep-0008.xml index f50b4823..27a21593 100644 --- a/xep-0008.xml +++ b/xep-0008.xml @@ -12,7 +12,7 @@ 0008 Deferred Historical - Standards JIG + Standards Council XMPP Core @@ -39,7 +39,7 @@ 0.2 2003-05-06 psa - 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. + At the request of the authors, the status of this document has been changed to Retracted. 0.1 diff --git a/xep-0009.xml b/xep-0009.xml index 1cc085a6..a6da662f 100644 --- a/xep-0009.xml +++ b/xep-0009.xml @@ -12,7 +12,7 @@ 0009 Final Standards Track - Standards JIG + Standards XMPP Core XML-RPC diff --git a/xep-0010.xml b/xep-0010.xml index d4640cf7..1af90ab5 100644 --- a/xep-0010.xml +++ b/xep-0010.xml @@ -6,13 +6,13 @@
    - Whiteboarding JIG - A proposal to form a JIG to develop a protocol for whiteboarding over Jabber. + Whiteboarding SIG + A proposal to form a SIG to develop a protocol for whiteboarding over Jabber. &LEGALNOTICE; 0010 Obsolete - JIG Formation - None + SIG Formation + None Niklas Gustavsson @@ -35,15 +35,15 @@

    Jabber is often thought of simply as a system for instant messaging, albeit an open one. However, Jabber technology can be used, and is being used, in applications quite different from simple IM. One of these applications is whiteboarding. In collaborative work, the ability to draw (for example, to design sketches, UML schemas, house architectures, and organizational plans) is essential, as exemplified by the success of real-world whiteboarding applications such as Microsoft NetMeeting. Whiteboarding can also be used for entertainment purposes such as games and quizzes. Because of the value of whiteboarding as an important real-time collaboration tool, other IM services are beginning to offer these capabilities. For these and other reasons, I believe that a good protocol for whiteboarding in Jabber would be of great value.

    There exists today a protocol draft for sending streaming XPM over Jabber XPM over Jabber (http://docs.jabber.org/draft-proto/html/sxpm.html). 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.

    -

    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 Conferencing protocol draft (http://jabber.org/?oid=1538).

    +

    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 Conferencing protocol draft (http://jabber.org/?oid=1538).

     -

    The Whiteboarding JIG should produce the following deliverables (these deliverables will be presented to the Jabber Council):

    +

    The Whiteboarding SIG should produce the following deliverables (these deliverables will be presented to the Jabber Council):

    A set of requirements that the proposed protocol should fulfill.

     -

    There are today at least four different attempts Distributed SVG documents (http://www.jabber.org/?oid=1025) SVG over Jabber (http://www.protocol7.com/jabber/whiteboard_proposal.txt) Jabberzilla Whiteboard (http://jabberzilla.mozdev.org/) to create a whiteboarding protocol in Jabber. The Whiteboarding JIG should evaluate them all and see which features of each are worth keeping.

    +

    There are today at least four different attempts Distributed SVG documents (http://www.jabber.org/?oid=1025) SVG over Jabber (http://www.protocol7.com/jabber/whiteboard_proposal.txt) Jabberzilla Whiteboard (http://jabberzilla.mozdev.org/) to create a whiteboarding protocol in Jabber. The Whiteboarding SIG should evaluate them all and see which features of each are worth keeping.

    One or more data formats for the graphics data, presented both as a description and as a DTD or XML schema.

    diff --git a/xep-0011.xml b/xep-0011.xml index 1f7d1ae0..0a4fabba 100644 --- a/xep-0011.xml +++ b/xep-0011.xml @@ -12,7 +12,7 @@ 0011 Deprecated Historical - Standards JIG + Standards XMPP Core diff --git a/xep-0012.xml b/xep-0012.xml index 77baf5e6..22993cc8 100644 --- a/xep-0012.xml +++ b/xep-0012.xml @@ -12,7 +12,7 @@ 0012 Active Historical - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0013.xml b/xep-0013.xml index cfbc10bd..2ba7f234 100644 --- a/xep-0013.xml +++ b/xep-0013.xml @@ -12,7 +12,7 @@ 0013 Draft Standards Track - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0014.xml b/xep-0014.xml index c7f716bc..e1f61a5e 100644 --- a/xep-0014.xml +++ b/xep-0014.xml @@ -12,7 +12,7 @@ 0014 Rejected Standards Track - Standards JIG + Standards Mike Mintz diff --git a/xep-0015.xml b/xep-0015.xml index 898775dd..e325e107 100644 --- a/xep-0015.xml +++ b/xep-0015.xml @@ -12,7 +12,7 @@ 0015 Rejected Standards Track - Standards JIG + Standards Casey Crabb diff --git a/xep-0016.xml b/xep-0016.xml index 2d8e3f6f..6ae4b9dd 100644 --- a/xep-0016.xml +++ b/xep-0016.xml @@ -12,7 +12,7 @@ 0016 Draft Standards Track - Standards JIG + Standards XMPP Core diff --git a/xep-0017.xml b/xep-0017.xml index 8dd5a9e8..b89b800d 100644 --- a/xep-0017.xml +++ b/xep-0017.xml @@ -12,7 +12,7 @@ 0017 Rejected Informational -Standards JIG +Standards Mike Lin diff --git a/xep-0018.xml b/xep-0018.xml index 867a85d6..01441aea 100644 --- a/xep-0018.xml +++ b/xep-0018.xml @@ -12,7 +12,7 @@ 0018 Rejected Informational - Standards JIG + Standards XMPP Core, XMPP IM None None diff --git a/xep-0019.xml b/xep-0019.xml index 53bdc51e..4be1b13c 100644 --- a/xep-0019.xml +++ b/xep-0019.xml @@ -6,13 +6,13 @@
    - Streamlining the JIGs - This document proposes to streamline the existing Jabber Interest Groups (JIGs). + Streamlining the SIGs + This document proposes to streamline the existing Special Interest Groups (SIGs). &LEGALNOTICE; 0019 Active Procedural - None + None Board @@ -38,39 +38,39 @@
    -

    The Jabber Software Foundation is an experiment. When we initially set up our policies, processes, and structures, we knew that our initial thoughts might not be our final thoughts, and that we would need to make adjustments as experience dictated. In this document, I argue that just such an adjustment is now necessary with regard to the Jabber Interest Groups (JIGs). The 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 http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-01-23.html. Further discussion within the Standards JIG has been helpful in clarifying the argument presented here.

    +

    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). 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 http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-01-23.html. Further discussion within the Standards SIG has been helpful in clarifying the argument presented here.

     -

    &xep0002; defined a JIG as "a working group approved by the Jabber Council to address specific areas of growth or concern within the Jabber community", and specified that the function of a JIG is to "produce acceptable enhancements to the Jabber protocol within a reasonably limited period of time". In early January of 2002, XEP-0002 was modified to incorporate language about disbanding a JIG after a defined period of inactivity on the JIG's mailing list (normally six months).

    -

    Unfortunately, it is widely recognized in the Jabber community that the JIGs are not working. Ten JIGs have been approved by the Jabber Council,See http://www.jabber.org/jigs.html for the official list. 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.

    -

    In perhaps the best measure of success or failure, only one JIG has produced a specification for submission to the Jabber Council, and that specification (&xep0009;) was essentially created outside the JIG structure at JabberCon 2001. Perhaps most ominously, no other JIG has shown any signs of progress toward completing a specification, or even starting work on one. With the possible exception of XEP-0009, all of the specifications created so far have come from individuals or small, ad-hoc groups -- not through the efforts of the JIGs.

    -

    In other words, an honest assessment forces us to conclude that the JIGs are not working.

    +

    &xep0002; defined a SIG as "a working group approved by the XMPP Council to address specific areas of growth or concern within the Jabber community", and specified that the function of a SIG is to "produce acceptable enhancements to XMPP within a reasonably limited period of time". In early January of 2002, XEP-0002 was modified to incorporate language about disbanding a SIG after a defined period of inactivity on the SIG's mailing list (normally six months).

    +

    Unfortunately, it is widely recognized in our community that the SIGs are not working. Ten SIGs have been approved by the XMPP Council, eight of them over six months ago in July and August of 2001. Two of the special-purpose SIGs (OOB and Presence) have seen no activity whatsoever and thus are clearly eligible to be disbanded. The other special-purpose SIGs (Conference, Formatting, Forms, Profiles, RPC, and Whiteboard) have seen extremely limited activity and it is a judgment call whether some of them should be allowed to continue according to the current standards defined in XEP-0002. Only the two "standing" SIGs (Security and Standards) have experienced significant and continued mailing list activity, mainly because the Standards SIG has assumed the role of discussion forum for specifications before they are submitted to the XMPP Council.

    +

    In perhaps the best measure of success or failure, only one SIG has produced a specification for submission to the XMPP Council, and that specification (&xep0009;) was essentially created outside the SIG structure at JabberCon 2001. Perhaps most ominously, no other SIG has shown any signs of progress toward completing a specification, or even starting work on one. With the possible exception of XEP-0009, all of the specifications created so far have come from individuals or small, ad-hoc groups -- not through the efforts of the SIGs.

    +

    In other words, an honest assessment forces us to conclude that the SIGs are not working.

     -

    I see several possible solutions to the JIG problem:

    +

    I see several possible solutions to the SIG problem:

      -
    1. "Crack the whip" -- encourage and cajole the existing JIGs into becoming more active, and energetically manage them so that they produce specifications.
      2. -
    2. "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).
      3. -
    3. "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.
      4. +
    4. "Crack the whip" -- encourage and cajole the existing SIGs into becoming more active, and energetically manage them so that they produce specifications.
      5. +
    5. "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).
      6. +
    6. "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.
    -

    Given the lack of activity in the JIGs so far (and the lack of time available to those who would manage them), I am skeptical that "cracking the whip" will produce results, and I believe the onus of proof is on those who would argue that the existing JIGs can be successful. Similarly, taking a "wait and see" attitude will simply let a bad situation continue unchecked, and in my opinion will at some point require us to choose between option 1 and option 3. Rather than postpone the day of reckoning, I argue that we need to address the problem head-on and take action to streamline the JIGs and find a better way of working.

    -

    But what is that "better way"? In order to figure that out, we need to understand why things are not working now. I don't think it's that the current JIG members are lazy, stupid, or incompetent -- after all, these are the same people who have in many instances created good Jabber-based software. Nor do I think it's that members of the Jabber community are incapable of creating specifications, because individually and in small, ad-hoc groups they have created quite a few.

    -

    I see several reasons why the JIGs are not working:

    +

    Given the lack of activity in the SIGs so far (and the lack of time available to those who would manage them), I am skeptical that "cracking the whip" will produce results, and I believe the onus of proof is on those who would argue that the existing SIGs can be successful. Similarly, taking a "wait and see" attitude will simply let a bad situation continue unchecked, and in my opinion will at some point require us to choose between option 1 and option 3. Rather than postpone the day of reckoning, I argue that we need to address the problem head-on and take action to streamline the SIGs and find a better way of working.

    +

    But what is that "better way"? In order to figure that out, we need to understand why things are not working now. I don't think it's that the current SIG members are lazy, stupid, or incompetent -- after all, these are the same people who have in many instances created good XMPP-based software. Nor do I think it's that members of the XMPP community are incapable of creating specifications, because individually and in small, ad-hoc groups they have created quite a few.

    +

    I see several reasons why the SIGs are not working:

      -
    1. The Jabber community right now is too small to be split up successfully into smaller interest groups.
      2. -
    2. 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.
      3. -
    3. 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.
      4. +
    4. The XMPP community right now is too small to be split up successfully into smaller interest groups.
      5. +
    5. 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.
      6. +
    6. 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.
    -

    If we reflect on what is working, we see that specifications are being produced by individuals and small, ad-hoc groups. We also see that active discussion of those proposals is taking place in the Standards JIG, which contains everyone who is strongly interested in the Jabber protocols. Finally, we notice that the special-purpose JIGs have not played any appreciable role in our success so far.

    +

    If we reflect on what is working, we see that specifications are being produced by individuals and small, ad-hoc groups. We also see that active discussion of those proposals is taking place in the Standards SIG, which contains everyone who is strongly interested in XMPP. Finally, we notice that the special-purpose SIGs have not played any appreciable role in our success so far.

     -

    My proposed solution takes into account everything we have learned to date about producing specifications and advancing the state of the Jabber protocols. Specifically, I propose that we take the following steps:

    +

    My proposed solution takes into account everything we have learned to date about producing specifications and advancing the state of XMPP. Specifically, I propose that we take the following steps:

      -
    1. Immediately disband all but the Standards JIG. 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.
      2. +
    2. Immediately disband all but the Standards SIG. 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.
    3. Rely on individuals and small, ad-hoc groups to create specifications.
      4. -
    4. Continue to use the Standards JIG as the preferred forum for discussion of experimental specifications before they are submitted to the Jabber Council.
      5. -
    5. 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. One option would be to send interested parties off to their own ad-hoc mailing list (e.g., on JabberStudio, http://www.jabberstudio.org/). 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.
      6. +
    6. Continue to use the Standards SIG as the preferred forum for discussion of experimental specifications before they are submitted to the XMPP Council.
      7. +
    7. 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. One option would be to send interested parties off to their own ad-hoc mailing list (e.g., on JabberStudio, http://www.jabberstudio.org/). 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.
    -

    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. 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 http://www.jabber.org/bylaws.html.)

    +

    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. 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 http://www.jabber.org/bylaws.html.)

         diff --git a/xep-0020.xml b/xep-0020.xml index 7a9e2777..130d6c27 100644 --- a/xep-0020.xml +++ b/xep-0020.xml @@ -12,7 +12,7 @@ 0020 Draft Standards Track - Standards JIG + Standards XMPP Core XEP-0004 diff --git a/xep-0021.xml b/xep-0021.xml index fbbdceba..d309f8e1 100644 --- a/xep-0021.xml +++ b/xep-0021.xml @@ -14,7 +14,7 @@ 0021 Retracted Standards Track - Standards + Standards None XEP-0060 None @@ -28,7 +28,7 @@ 0.2 2003-04-22 psa - 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. + At the request of the author, the status of this document has been changed to Retracted since it has been superseded by XEP-0060. 0.1 diff --git a/xep-0022.xml b/xep-0022.xml index c958e758..36d8b408 100644 --- a/xep-0022.xml +++ b/xep-0022.xml @@ -12,7 +12,7 @@ 0022 Active Historical - Standards JIG + Standards XMPP Core diff --git a/xep-0023.xml b/xep-0023.xml index 9f982210..aedc2177 100644 --- a/xep-0023.xml +++ b/xep-0023.xml @@ -12,7 +12,7 @@ 0023 Deprecated Historical - Standards JIG + Standards XMPP Core @@ -70,7 +70,7 @@
    -

    Note Well: The protocol described herein has been deprecated by the &JSF;. The recommended protocol for implementing message expiration functionality is now &xep0079;.

    +

    Note Well: The protocol described herein has been deprecated by the &XSF;. The recommended protocol for implementing message expiration functionality is now &xep0079;.

    It is sometimes helpful to indicate that a piece of information has a finite useful life or time-to-live (TTL). In the context of instant messaging, the main use of a TTL is to indicate that a message must or should be used by or read by a certain time, usually because the message has meaning or purpose only within a finite amount of time. In normal usage, such a message should be discarded after the specified time has passed if it has not been used or read by that time.

    In Jabber, TTL functionality has been implemented informally using the jabber:x:expire namespace. Support for this namespace was added to the &jabberd; server as well as some clients and components in early 2001. Specifically, that support has involved the following two areas of responsibility:

      diff --git a/xep-0024.xml b/xep-0024.xml index 6eeb10c0..b0f640be 100644 --- a/xep-0024.xml +++ b/xep-0024.xml @@ -12,7 +12,7 @@ 0024 Retracted Standards Track - Standards + Standards None XEP-0060 None @@ -32,7 +32,7 @@ 0.2 2003-04-22 psa - 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. + At the request of the authors, the status of this document has been changed to Retracted since it has been superseded by XEP-0060. 0.1 diff --git a/xep-0025.xml b/xep-0025.xml index e279a841..eb6afd3f 100644 --- a/xep-0025.xml +++ b/xep-0025.xml @@ -12,7 +12,7 @@ 0025 Deprecated Historical - Standards JIG + Standards XMPP Core diff --git a/xep-0026.xml b/xep-0026.xml index 8ba6c508..c0ca5f1c 100644 --- a/xep-0026.xml +++ b/xep-0026.xml @@ -12,7 +12,7 @@ 0026 Retracted Standards Track - Standards + Standards None None XMPP Core @@ -27,7 +27,7 @@ 0.2 2003-11-05 psa - 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. + The status of this document has been changed to Retracted since it has been superseded by &xmppcore;. 0.1 diff --git a/xep-0027.xml b/xep-0027.xml index 10c7c2c8..3ce24b3b 100644 --- a/xep-0027.xml +++ b/xep-0027.xml @@ -12,7 +12,7 @@ 0027 Active Historical - Standards JIG + Standards XMPP Core diff --git a/xep-0028.xml b/xep-0028.xml index 649ee6fd..9a440b80 100644 --- a/xep-0028.xml +++ b/xep-0028.xml @@ -7,7 +7,7 @@
      No Such XEP - This XEP was removed from the JSF website and source control at the request of the author. + This XEP was removed from the XSF website and source control at the request of the author. 0028
      diff --git a/xep-0029.xml b/xep-0029.xml index 539c4f6c..8fe86401 100644 --- a/xep-0029.xml +++ b/xep-0029.xml @@ -12,7 +12,7 @@ 0029 Retracted Standards Track - Standards JIG + Standards None None XMPP Core diff --git a/xep-0030.xml b/xep-0030.xml index cbf3809d..73b5a8ba 100644 --- a/xep-0030.xml +++ b/xep-0030.xml @@ -12,7 +12,7 @@ 0030 Final Standards Track - Standards JIG + Standards XMPP Core @@ -135,7 +135,7 @@ 0.11 2002-12-17 psa - Added support for the 'node' attribute per discussion on the Standards-JIG list in order to support items that are not JID-addressable. + Added support for the 'node' attribute per discussion on the Standards list in order to support items that are not JID-addressable.       0.10 @@ -765,7 +765,7 @@ -

      The XMPP Registrar shall maintain a registry of values for the 'category' and 'type' attributes of the <identity/> element in the 'http://jabber.org/protocol/disco#info' namespace; see <http://www.jabber.org/registrar/disco-categories.html>.

      +

      The XMPP Registrar maintains a registry of values for the 'category' and 'type' attributes of the <identity/> element in the 'http://jabber.org/protocol/disco#info' namespace; see &DISCOCATEGORIES;.

      ®PROCESS;       -

      The XMPP Registrar shall maintain a registry of features for use as values of the 'var' attribute of the <feature/> element in the 'http://jabber.org/protocol/disco#info' namespace; see <http://www.jabber.org/registrar/disco-vars.html>.

      +

      The XMPP Registrar maintains a registry of features for use as values of the 'var' attribute of the <feature/> element in the 'http://jabber.org/protocol/disco#info' namespace; see &DISCOFEATURES;.

      ®PROCESS;       -

      A using protocol may specify one or more service discovery nodes that have a special and well-defined meaning in the context of that protocol. For the purpose of reserving these node names globally across all Jabber protocols, the XMPP Registrar shall maintain a registry of well-known service discovery nodes; see <http://www.jabber.org/registrar/disco-nodes.html>.

      +

      A using protocol may specify one or more service discovery nodes that have a special and well-defined meaning in the context of that protocol. For the purpose of reserving these node names globally across all Jabber protocols, the XMPP Registrar maintains a registry of well-known service discovery nodes at &DISCONODES;.

      ®PROCESS; - + Standards - + diff --git a/xep-0032.xml b/xep-0032.xml index 571e5c98..692bb896 100644 --- a/xep-0032.xml +++ b/xep-0032.xml @@ -12,7 +12,7 @@ 0032 Retracted Standards Track - Standards JIG + Standards None None RFC 4622 diff --git a/xep-0033.xml b/xep-0033.xml index 861f9d33..d613f36e 100644 --- a/xep-0033.xml +++ b/xep-0033.xml @@ -12,7 +12,7 @@ 0033 Draft Standards Track - Standards JIG + Standards XMPP Core XEP-0030 diff --git a/xep-0034.xml b/xep-0034.xml index bc842c93..5ba9e1b5 100644 --- a/xep-0034.xml +++ b/xep-0034.xml @@ -14,7 +14,7 @@ 0034 Retracted Standards Track - Standards + Standards None None XMPP Core @@ -41,7 +41,7 @@ 1.1 2003-11-05 psa - The status of this specification has been changed to Retracted since it has been superseded by &xmppcore;. This specification will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations. + The status of this specification has been changed to Retracted since it has been superseded by &xmppcore;.       1.0 diff --git a/xep-0035.xml b/xep-0035.xml index 5f8cf67d..ae53e86f 100644 --- a/xep-0035.xml +++ b/xep-0035.xml @@ -14,7 +14,7 @@ 0035 Retracted Standards Track - Standards + Standards None None XMPP Core @@ -29,7 +29,7 @@ 0.2 2003-11-05 psa - 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. + The status of this specification has been changed to Retracted since it has been superseded by &xmppcore;. 0.1 diff --git a/xep-0036.xml b/xep-0036.xml index d1b48ea3..d42a4b5b 100644 --- a/xep-0036.xml +++ b/xep-0036.xml @@ -12,7 +12,7 @@ 0036 Retracted Standards Track - Standards + Standards None XEP-0060 None @@ -22,7 +22,7 @@ 0.2 2003-04-22 psa - 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. + At the request of the authors, the status of this specification has been changed to Retracted since it has been superseded by XEP-0060. 0.1 diff --git a/xep-0037.xml b/xep-0037.xml index 53af321f..3ca61f97 100644 --- a/xep-0037.xml +++ b/xep-0037.xml @@ -11,7 +11,7 @@ 0037 Rejected Standards Track - Standards JIG + Standards David Sutton diff --git a/xep-0038.xml b/xep-0038.xml index 48610e1c..5dc4ed78 100644 --- a/xep-0038.xml +++ b/xep-0038.xml @@ -12,7 +12,7 @@ 0038 Deferred Standards Track - Standards JIG + Standards None None None @@ -228,7 +228,7 @@ -

      The JSF shall register and maintain a MIME type and file extension for icon style packages with the IANA. Ones have already been registered by Sebastiaan Deckers (aka 'CBAS') as application/vnd.jisp and .jisp, respectively. The registration can be found at http://www.iana.org/assignments/media-types/application/vnd.jisp. Sebastiaan's registration shall be considered the official MIME type and file extension of this specification.

      +

      The &XSF; shall register and maintain a MIME type and file extension for icon style packages with the IANA. Ones have already been registered by Sebastiaan Deckers (aka 'CBAS') as application/vnd.jisp and .jisp, respectively. The registration can be found at http://www.iana.org/assignments/media-types/application/vnd.jisp. Sebastiaan's registration shall be considered the official MIME type and file extension of this specification.

      Also, this specification uses other MIME types that are maintained by IANA for the object and xml files that are included in the icon style packages.

       diff --git a/xep-0039.xml b/xep-0039.xml index d7e2f0b3..ee62cc50 100644 --- a/xep-0039.xml +++ b/xep-0039.xml @@ -12,7 +12,7 @@ 0039 Deferred Standards Track - Standards + Standards Paul Curtis diff --git a/xep-0040.xml b/xep-0040.xml index dd1631bd..b875ac1e 100644 --- a/xep-0040.xml +++ b/xep-0040.xml @@ -12,7 +12,7 @@ 0040 Retracted Standards Track - Standards + Standards None None XEP-0060 diff --git a/xep-0041.xml b/xep-0041.xml index 9d8e3363..bd224c16 100644 --- a/xep-0041.xml +++ b/xep-0041.xml @@ -12,7 +12,7 @@ 0041 Retracted Standards Track - Standards JIG + Standards XMPP Core, XEP-0020, XEP-0030 None XEP-0065 @@ -27,7 +27,7 @@ 0.2 2003-09-30 psa - 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. + At the request of the author, the status of this specification has been changed to Retracted since it has been superseded by &xep0065;.       0.8 diff --git a/xep-0042.xml b/xep-0042.xml index aeb27e80..ff050550 100644 --- a/xep-0042.xml +++ b/xep-0042.xml @@ -12,7 +12,7 @@ 0042 Retracted Standards Track - Standards + Standards XEP-0004 (OPTIONAL), XEP-0011 (RECOMMENDED) XEP-0029 (REQUIRED) None XEP-0065 @@ -27,7 +27,7 @@ 0.5 2003-04-11 psa - 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. + At the request of the author, changed status to Retracted. 0.4 diff --git a/xep-0043.xml b/xep-0043.xml index ee8d7d4c..e4581be8 100644 --- a/xep-0043.xml +++ b/xep-0043.xml @@ -12,7 +12,7 @@ 0043 Retracted Standards Track - Standards + Standards Justin Kirby diff --git a/xep-0044.xml b/xep-0044.xml index 72560ade..9c856624 100644 --- a/xep-0044.xml +++ b/xep-0044.xml @@ -14,7 +14,7 @@ 0044 Deferred Standards Track - Standards + Standards Robert Norris diff --git a/xep-0045.xml b/xep-0045.xml index d2270821..8a66d735 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -14,7 +14,7 @@ 0045 Draft Standards Track - Standards JIG + Standards XMPP Core XMPP IM @@ -225,7 +225,7 @@ 0.20 2002-10-29 psa -

      Specified that messages sent to change the room subject must be of type "groupchat"; updated the legal notice to conform to the JSF IPR policy.

       +

      Specified that messages sent to change the room subject must be of type "groupchat"; updated the legal notice to conform to the XSF IPR policy.

             0.19 @@ -5250,6 +5250,6 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password -

      The author would like to thank the following individuals for their many helpful comments on various drafts of this proposal: David Sutton, Peter Millard, Joe Hildebrand, Craig Kaes, Alexey Shchepin, David Waite, Jean-Louis Seguineau, Jacek Konieczny, Gaston Dombiak, and many others in the jdev@conference.jabber.org conference room and on the Standards-JIG mailing list.

      +

      The author would like to thank the following individuals for their many helpful comments on various drafts of this proposal: David Sutton, Peter Millard, Joe Hildebrand, Craig Kaes, Alexey Shchepin, David Waite, Jean-Louis Seguineau, Jacek Konieczny, Gaston Dombiak, and many others in the jdev@conference.jabber.org conference room and on the Standards mailing list.

       diff --git a/xep-0046.xml b/xep-0046.xml index 8511fa4e..f316915b 100644 --- a/xep-0046.xml +++ b/xep-0046.xml @@ -12,7 +12,7 @@ 0046 Retracted Standards Track - Standards + Standards None None XEP-0065 @@ -27,7 +27,7 @@ 0.8 2003-04-11 psa - 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. + At the request of the author, changed status to Retracted.       0.7 diff --git a/xep-0047.xml b/xep-0047.xml index d52ce42b..8d7520a3 100644 --- a/xep-0047.xml +++ b/xep-0047.xml @@ -12,7 +12,7 @@ 0047 Draft Standards Track - Standards JIG + Standards XMPP Core XEP-0079 diff --git a/xep-0048.xml b/xep-0048.xml index a034dea2..f17941e2 100644 --- a/xep-0048.xml +++ b/xep-0048.xml @@ -12,7 +12,7 @@ 0048 Active Historical - Standards JIG + Standards XMPP Core XEP-0049 diff --git a/xep-0049.xml b/xep-0049.xml index 09fa5614..c33a2250 100644 --- a/xep-0049.xml +++ b/xep-0049.xml @@ -12,7 +12,7 @@ 0049 Active Historical - Standards JIG + Standards XMPP Core diff --git a/xep-0050.xml b/xep-0050.xml index 8592fe30..4b9807e6 100644 --- a/xep-0050.xml +++ b/xep-0050.xml @@ -12,7 +12,7 @@ 0050 Draft Standards Track - Standards JIG + Standards XMPP Core XEP-0004 diff --git a/xep-0051.xml b/xep-0051.xml index afdd9061..31b4cb80 100644 --- a/xep-0051.xml +++ b/xep-0051.xml @@ -14,7 +14,7 @@ 0051 Deferred Standards Track - Standards JIG + Standards Klaus Wolf diff --git a/xep-0052.xml b/xep-0052.xml index 66cab3b8..ee048c2a 100644 --- a/xep-0052.xml +++ b/xep-0052.xml @@ -12,7 +12,7 @@ 0052 Retracted Standards Track - Standards JIG + Standards XMPP Core, XMPP IM, XEP-0004, XEP-0020, XEP-0030 None XEP-0095, XEP-0096 @@ -39,7 +39,7 @@ 0.2 2003-09-30 psa - 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. + 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. 0.1 diff --git a/xep-0053.xml b/xep-0053.xml index 22b3f1fd..f6abc0f8 100644 --- a/xep-0053.xml +++ b/xep-0053.xml @@ -7,12 +7,12 @@
      XMPP Registrar Function - This document defines the roles and processes of the XMPP Registrar function within the Jabber Software Foundation. + This document defines the roles and processes of the XMPP Registrar function within the XMPP Standards Foundation. &LEGALNOTICE; 0053 Active Procedural - None + None Board @@ -29,7 +29,7 @@ 1.2 2006-10-04 psa -

      As approved by the members of the Jabber Software Foundation, changed Jabber Registrar to XMPP Registrar.

       +

      As approved by the members of the XMPP Standards Foundation, changed Jabber Registrar to XMPP Registrar.

       1.1 @@ -47,7 +47,7 @@ 0.5 2003-01-21 psa - Changed name to XMPP Registrar in response to feedback from the JSF Board of Directors. + Changed name to XMPP Registrar in response to feedback from the XSF Board of Directors. 0.4 @@ -75,7 +75,7 @@
      -

      Because the &JSF; publishes a relatively large number of protocol specifications (see &xep0001;), it is important to keep track of the namespaces defined by those specifications as well as the parameters used in the context of the relevant protocols. (Examples of such parameters include the features and options used in &xep0020; and the identities and features used in &xep0030;.) In particular, the common use of protocols published by the JSF requires that namespaces and particular parameter values be assigned uniquely. It is the role of the XMPP Registrar to make those unique assignments and to maintain registries of the currently assigned values. The XMPP Registrar shall also function as a single point of contact between the Jabber/XMPP developer community and &IANA;.

      +

      Because the &XSF; publishes a relatively large number of protocol specifications (see &xep0001;), it is important to keep track of the namespaces defined by those specifications as well as the parameters used in the context of the relevant protocols. (Examples of such parameters include the features and options used in &xep0020; and the identities and features used in &xep0030;.) In particular, the common use of protocols published by the XSF requires that namespaces and particular parameter values be assigned uniquely. It is the role of the XMPP Registrar to make those unique assignments and to maintain registries of the currently assigned values. The XMPP Registrar shall also function as a single point of contact between the Jabber/XMPP developer community and &IANA;.

      Until there is a perceived need for a more formal governing body, the functions of the XMPP Registrar shall be managed by the &EDITOR;. In the future, the &COUNCIL; and/or the &BOARD; may decide to create a more formal panel to oversee the functions of the XMPP Registrar; if they do, this document shall be updated to reflect the change.

      @@ -83,11 +83,11 @@

      Every XMPP Extension Protocol specification (XEP) must contain a section devoted to "XMPP Registrar Considerations", detailing the namespaces and parameters to be registered with the XMPP Registrar, as well as any new registries to be created as a result of the XEP.

      The registry additions or creations specified in an XMPP Extension Protocol specification shall not take effect until the document advances to a status of Draft (Standards-Track XEPs) or Active (Informational and Historical XEPs). Registration of namespaces shall be handled as described in the Namespace Issuance section of this document. Registration of particular parameters used within a specification shall be initiated by the XMPP Extensions Editor if specified in the XEP, and may also be initiated by implementors of the XMPP Extension Protocol document after it has advanced to Active, Draft, or Final. Creation of new registries shall be initiated by the XMPP Registrar; if a document specifies the creation of a new registry, the author is strongly encouraged to consult with the XMPP Registrar before seeking a Last Call on the XEP.

      -

      Requests for parameter assignments must be sent to the XMPP Registrar in accordance with the process specified in the document (usually a XEP) that defines the relevant registry, normally by sending an appropriately formatted email message to <mailto:registrar@jabber.org>. If, in the Registrar's judgment, discussion of a request is required, the Registrar shall initiate such discussion within the &SJIG;. The Registrar shall add registry items at its discretion based on discussion within the Standards JIG if necessary, but shall not unduly restrict registration of parameter values. If a document author or implementor thinks that a request was unfairly denied by the Registrar, an appeal of the decision may be directed to the XMPP Council.

      -

      The XMPP Registrar shall maintain registries of assigned namespaces and parameters at <http://www.xmpp.org/registrar/> and shall update those registries in a timely fashion. Changes to the registries shall be announced on the Standards-JIG mailing list.

      +

      Requests for parameter assignments must be sent to the XMPP Registrar in accordance with the process specified in the document (usually a XEP) that defines the relevant registry, normally by sending an appropriately formatted email message to <mailto:registrar@jabber.org>. If, in the Registrar's judgment, discussion of a request is required, the Registrar shall initiate such discussion within the &SSIG;. The Registrar shall add registry items at its discretion based on discussion within the Standards SIG if necessary, but shall not unduly restrict registration of parameter values. If a document author or implementor thinks that a request was unfairly denied by the Registrar, an appeal of the decision may be directed to the XMPP Council.

      +

      The XMPP Registrar shall maintain registries of assigned namespaces and parameters at <http://www.xmpp.org/registrar/> and shall update those registries in a timely fashion. Changes to the registries shall be announced on the Standards mailing list.

       -

      The XMPP Registrar shall be responsible for issuing namespaces to be used in XMPP protocol extensions developed through the Jabber Software Foundation's standards process as specified in XEP-0001. The policies and procedures for namespace issuance shall be as follows:

      +

      The XMPP Registrar shall be responsible for issuing namespaces to be used in XMPP protocol extensions developed through the XMPP Standards Foundation's standards process as specified in XEP-0001. The policies and procedures for namespace issuance shall be as follows:

      1. 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;).

      2. @@ -107,7 +107,7 @@

        Security considerations are primarily the responsibility of the protocols in which specific parameters are used. The XMPP Registrar shall respect the security considerations defined in XMPP Extension Protocol specifications, and shall endeavor to ensure that registered parameter values do not compromise privacy or security in any way.

        -

        The XMPP Registrar shall be responsible for interacting with the IANA on behalf of the Jabber Software Foundation and Jabber/XMPP developer community. If an XMPP Extension Protocol specification requires interaction with the IANA, that fact shall be noted by the document author and discussed on the Standards-JIG mailing list along with normal discussion of the XEP. The XMPP Registrar shall collaborate with the author to present an appropriate request to the IANA.

        +

        The XMPP Registrar shall be responsible for interacting with the IANA on behalf of the XMPP Standards Foundation and Jabber/XMPP developer community. If an XMPP Extension Protocol specification requires interaction with the IANA, that fact shall be noted by the document author and discussed on the Standards mailing list along with normal discussion of the XEP. The XMPP Registrar shall collaborate with the author to present an appropriate request to the IANA.

        This entire document defines the processes and procedures of the XMPP Registrar.

        diff --git a/xep-0054.xml b/xep-0054.xml index 38550ac0..39ba928e 100644 --- a/xep-0054.xml +++ b/xep-0054.xml @@ -12,7 +12,7 @@ 0054 Active Historical - Standards JIG + Standards XMPP Core @@ -79,10 +79,10 @@ stpeter - http://www.jabber.org/people/stpeter.php + http://www.xmpp.org/xsf/people/stpeter.shtml 1966-08-06 - Jabber Software Foundation + XMPP Standards Foundation Executive Director @@ -242,7 +242,7 @@ PARTICULAR PURPOSE. @@ -388,7 +388,7 @@ PARTICULAR PURPOSE. @@ -465,7 +465,7 @@ PARTICULAR PURPOSE. diff --git a/xep-0055.xml b/xep-0055.xml index 97da54a4..1d88cdeb 100644 --- a/xep-0055.xml +++ b/xep-0055.xml @@ -12,7 +12,7 @@ 0055 Active Historical - Standards JIG + Standards XMPP Core XEP-0004 diff --git a/xep-0056.xml b/xep-0056.xml index db3faa54..c9515a5e 100644 --- a/xep-0056.xml +++ b/xep-0056.xml @@ -12,7 +12,7 @@ 0056 Deferred Standards Track -Standards JIG +Standards None Ulrich diff --git a/xep-0057.xml b/xep-0057.xml index 0caa687e..019e402b 100644 --- a/xep-0057.xml +++ b/xep-0057.xml @@ -12,7 +12,7 @@ 0057 Retracted Standards Track - Standards JIG + Standards None None None @@ -26,7 +26,7 @@ 0.2 2003-04-28 psa - 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. + 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. 0.1 diff --git a/xep-0058.xml b/xep-0058.xml index 73cf0fc5..28a524cb 100644 --- a/xep-0058.xml +++ b/xep-0058.xml @@ -12,7 +12,7 @@ 0058 Deferred Standards Track - Standards + Standards Alexey Shchepin diff --git a/xep-0059.xml b/xep-0059.xml index 48e84684..dea8e31a 100644 --- a/xep-0059.xml +++ b/xep-0059.xml @@ -12,7 +12,7 @@ 0059 Draft Standards Track - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0060.xml b/xep-0060.xml index 948301be..83b22c57 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -15,7 +15,7 @@ 0060 Draft Standards Track - Standards JIG + Standards XMPP Core XEP-0004 diff --git a/xep-0061.xml b/xep-0061.xml index f8fabeb8..0fdcc498 100644 --- a/xep-0061.xml +++ b/xep-0061.xml @@ -12,7 +12,7 @@ 0061 Deferred Informational - Standards JIG + Standards XMPP Core None None diff --git a/xep-0062.xml b/xep-0062.xml index 22a25170..38d089b3 100644 --- a/xep-0062.xml +++ b/xep-0062.xml @@ -15,7 +15,7 @@ 0062 Deferred Informational - Standards JIG + Standards XMPP Core, XEP-0030 None None diff --git a/xep-0063.xml b/xep-0063.xml index 3bd1d9b0..79815304 100644 --- a/xep-0063.xml +++ b/xep-0063.xml @@ -15,7 +15,7 @@ 0063 Deferred Informational - Standards JIG + Standards XEP-0062 None None diff --git a/xep-0064.xml b/xep-0064.xml index e7f9798d..37ad47e7 100644 --- a/xep-0064.xml +++ b/xep-0064.xml @@ -15,7 +15,7 @@ 0064 Deferred Informational - Standards JIG + Standards XEP-0062 None None diff --git a/xep-0065.xml b/xep-0065.xml index 06641848..4f0a8268 100644 --- a/xep-0065.xml +++ b/xep-0065.xml @@ -12,7 +12,7 @@ 0065 Draft Standards Track - Standards JIG + Standards XMPP Core RFC 1928 diff --git a/xep-0066.xml b/xep-0066.xml index 322b1a8b..ca9266c4 100644 --- a/xep-0066.xml +++ b/xep-0066.xml @@ -12,7 +12,7 @@ 0066 Draft Standards Track - Standards JIG + Standards XMPP Core diff --git a/xep-0067.xml b/xep-0067.xml index 48cf47dc..2dabc1eb 100644 --- a/xep-0067.xml +++ b/xep-0067.xml @@ -12,7 +12,7 @@ 0067 Deferred Standards Track -Standards JIG +Standards XEP-0060 Ulrich diff --git a/xep-0068.xml b/xep-0068.xml index 5201c66e..a7faf729 100644 --- a/xep-0068.xml +++ b/xep-0068.xml @@ -12,7 +12,7 @@ 0068 Active Informational - Standards JIG + Standards XMPP Core XEP-0004 @@ -78,8 +78,8 @@

        The first decision-point is whether a FORM_TYPE needs to be registered with the XMPP Registrar. The following rules apply:

          -
        1. If the FORM_TYPE is used in the context of a form defined in a XEP, it MUST be registered.
          2. -
        2. 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.
          3. +
        3. If the FORM_TYPE is used in the context of a form defined in a XEP published by the &XSF;, it MUST be registered.
          4. +
        4. 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.
        5. If the FORM_TYPE is used in the context of a custom protocol, it MAY be registered.
         @@ -87,8 +87,8 @@

        While the value of the FORM_TYPE attribute SHOULD be considered an opaque string from the application perspective, the following rules apply:

        1. For custom protocols, the name SHOULD be an HTTP URI that is managed by the namespace "owner".
          2. -
        2. For all new protocols approved by the JSF, the name MUST be an HTTP URI or IETF-style URN.
          3. -
        3. For "legacy" protocols managed by the JSF, the name SHOULD use the old-style "jabber:*:*" format.
          4. +
        4. For all new protocols approved by the XSF, the name MUST be an HTTP URI or IETF-style URN.
          5. +
        5. For "legacy" protocols managed by the XSF, the name SHOULD use the old-style "jabber:*:*" format.
        diff --git a/xep-0069.xml b/xep-0069.xml index 14f05a4f..3cee553e 100644 --- a/xep-0069.xml +++ b/xep-0069.xml @@ -6,19 +6,14 @@
        - Compliance JIG - A proposal to form a JIG devoted to issues related to protocol compliance. + Compliance SIG + A proposal to form a SIG devoted to issues related to protocol compliance. &LEGALNOTICE; 0069 Deferred - JIG Formation - None - - Peter - Saint-Andre - stpeter@jabber.org - stpeter@jabber.org - + SIG Formation + None + &stpeter; 0.1 2003-01-29 @@ -27,20 +22,20 @@
        -

        The Jabber Software Foundation has an initiative underway to define and implement compliance testing of software that is based on XMPP and JSF-approved protocols. To date, participation in this compliance program has been limited to elected members of the JSF. However, not all matters related to the compliance program need to be limited to JSF members. In particular, it would be valuable to receive community feedback and input regarding test plans, testing software, and the like. In order to broaden participation, we propose that the JSF form a standing Jabber Interest Group devoted to compliance.

        +

        The XMPP Standards Foundation has an initiative underway to define and implement compliance testing of software that is based on XMPP and XSF-approved protocols. To date, participation in this compliance program has been limited to elected members of the XSF. However, not all matters related to the compliance program need to be limited to XSF members. In particular, it would be valuable to receive community feedback and input regarding test plans, testing software, and the like. In order to broaden participation, we propose that the XSF form a standing Jabber Interest Group devoted to compliance.

         -

        The Compliance JIG shall provide a public forum for discussion and development of systems for testing compliance with the protocols defined and accepted by the JSF. It shall not have ultimate accountability for the JSF compliance program; rather, that accountability shall rest with the members-only Compliance Team. The Compliance JIG shall act in an advisory capacity in relation to the Compliance Team. In essence, the relationship between the Compliance JIG and the Compliance Team is analagous to the relationship between the Standards JIG and the Jabber Council.

        -

        In particular, the Compliance JIG shall work with the Compliance Team to define the processes, standards, test cases, and testing software required by the compliance program. However, the Compliance JIG shall not be privy to actual testing results, which shall be available only to the Compliance Team.

        +

        The Compliance SIG shall provide a public forum for discussion and development of systems for testing compliance with the protocols defined and accepted by the XSF. It shall not have ultimate accountability for the XSF compliance program; rather, that accountability shall rest with the members-only Compliance Team. The Compliance SIG shall act in an advisory capacity in relation to the Compliance Team. In essence, the relationship between the Compliance SIG and the Compliance Team is analagous to the relationship between the Standards SIG and the Jabber Council.

        +

        In particular, the Compliance SIG shall work with the Compliance Team to define the processes, standards, test cases, and testing software required by the compliance program. However, the Compliance SIG shall not be privy to actual testing results, which shall be available only to the Compliance Team.

         -

        The Compliance JIG shall be open to the public and shall not be limited to elected members of the Jabber Software Foundation. Compliance JIG discussions shall be conducted on a dedicated mailing list <compliance-jig@jabber.org> as well as in the <foundation@conference.jabber.org> chatroom.

        +

        The Compliance SIG shall be open to the public and shall not be limited to elected members of the XMPP Standards Foundation. Compliance SIG discussions shall be conducted on a dedicated mailing list <compliance-jig@jabber.org> as well as in the <foundation@conference.jabber.org> chatroom.

         -

        The Compliance JIG shall be a standing JIG, and shall exist as long as the JSF compliance program is in operation.

        +

        The Compliance SIG shall be a standing SIG, and shall exist as long as the XSF compliance program is in operation.

         -

        The Compliance JIG shall produce at least the following deliverables:

        +

        The Compliance SIG shall produce at least the following deliverables:

        • Documentation of the testing process
        • Compliance test plans
          • diff --git a/xep-0070.xml b/xep-0070.xml index 5d35e622..75a55a18 100644 --- a/xep-0070.xml +++ b/xep-0070.xml @@ -12,7 +12,7 @@ 0070 Draft Standards Track - Standards JIG + Standards XMPP Core RFC 2616 diff --git a/xep-0071.xml b/xep-0071.xml index 39cc4405..480eebe9 100644 --- a/xep-0071.xml +++ b/xep-0071.xml @@ -12,7 +12,7 @@ 0071 Draft Standards Track - Standards JIG + Standards XMPP Core XMPP IM @@ -76,7 +76,7 @@ 0.15 2004-07-29 psa - 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. + 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. 0.14 @@ -168,10 +168,10 @@

          In the past, there have existed several incompatible methods within the Jabber community for exchanging instant messages that contain lightweight text markup. The most notable such methods have included derivatives of &w3xhtml; as well as of &rtf;.

          -

          Although it is sometimes easier for client developers to implement RTF support (this is especially true on certain Microsoft Windows operating systems), there are several reasons (consistent with the &xep0134;) for the &JSF; to avoid the use of RTF in developing a protocol for lightweight text markup. Specifically:

          +

          Although it is sometimes easier for client developers to implement RTF support (this is especially true on certain Microsoft Windows operating systems), there are several reasons (consistent with the &xep0134;) for the &XSF; to avoid the use of RTF in developing a protocol for lightweight text markup. Specifically:

          1. RTF is not a structured vocabulary derived from SGML (as is &w3html;) or, more relevantly, from XML (as is XHTML 1.0).
            2. -
          2. 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.
            3. +
          3. 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.

          Conversely, there are several reasons to prefer XHTML for lightweight text markup:

            @@ -785,7 +785,7 @@ That seems fine to me.

            The fields of this FPI are as follows:

            1. The leading field is "-", which indicates that this is a privately-defined resource.
              2. -
            2. The second field is "JSF" (an abbreviation for Jabber Software Foundation), which identifies the organization that maintains the named item.
              3. +
            3. 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.
            4. The third field contains two constructs:
              1. The public text class is "DTD", which adheres to ISO 8879 Clause 10.2.2.1.
                2. @@ -801,15 +801,15 @@ That seems fine to me.

                1. W3C TEXT: If a user agent encounters an element it does not recognize, it must continue to process the children of that element. If the content is text, the text must be presented to the user.

                  -

                  JSF COMMENT: This behavior is different from that defined by XMPP Core, and in the context of XHTML-IM implementations applies only to XML elements qualified by the 'http://www.w3.org/1999/xhtml' namespace as defined herein. This criterion MUST be applied to all XHTML 1.0 elements except those explicitly included in XHTML-IM as described in the XHTML-IM Integration Set and Recommended Profile sections of this document. Therefore, an XHTML-IM implementation MUST process all XHTML 1.0 child elements of the XHTML-IM <html/> element even if such child elements are not included in the XHTML 1.0 Integration Set defined herein, and MUST present to the recipient the XML character data contained in such child elements.

                  +

                  XSF COMMENT: This behavior is different from that defined by XMPP Core, and in the context of XHTML-IM implementations applies only to XML elements qualified by the 'http://www.w3.org/1999/xhtml' namespace as defined herein. This criterion MUST be applied to all XHTML 1.0 elements except those explicitly included in XHTML-IM as described in the XHTML-IM Integration Set and Recommended Profile sections of this document. Therefore, an XHTML-IM implementation MUST process all XHTML 1.0 child elements of the XHTML-IM <html/> element even if such child elements are not included in the XHTML 1.0 Integration Set defined herein, and MUST present to the recipient the XML character data contained in such child elements.

                2. W3C TEXT: If a user agent encounters an attribute it does not recognize, it must ignore the entire attribute specification (i.e., the attribute and its value).

                  -

                  JSF COMMENT: This criterion MUST be applied to all XHTML 1.0 attributes except those explicitly included in XHTML-IM as described in the XHTML-IM Integration Set and Recommended Profile sections of this document. Therefore, an XHTML-IM implementation MUST ignore all attributes of elements qualified by the 'http://www.w3.org/1999/xhtml' namespace if such attributes are not explicitly included in the XHTML 1.0 Integration Set defined herein.

                  +

                  XSF COMMENT: This criterion MUST be applied to all XHTML 1.0 attributes except those explicitly included in XHTML-IM as described in the XHTML-IM Integration Set and Recommended Profile sections of this document. Therefore, an XHTML-IM implementation MUST ignore all attributes of elements qualified by the 'http://www.w3.org/1999/xhtml' namespace if such attributes are not explicitly included in the XHTML 1.0 Integration Set defined herein.

                3. W3C TEXT: If a user agent encounters an attribute value it doesn't recognize, it must use the default attribute value.

                  -

                  JSF COMMENT: Since not one of the attributes included in XHTML-IM has a default value defined for it in XHTML 1.0, in practice this criterion does not apply to XHTML-IM implementations.

                  +

                  XSF COMMENT: Since not one of the attributes included in XHTML-IM has a default value defined for it in XHTML 1.0, in practice this criterion does not apply to XHTML-IM implementations.

                @@ -817,7 +817,7 @@ That seems fine to me.

                For information regarding XHTML modularization in XML schema for the XHTML 1.0 Integration Set defined in this specification, refer to the Schema Driver section of this document.

                -

                The XHTML 1.0 Integration Set defined herein has been reviewed informally by an editor of the XHTML Modularization in XML Schema specification but has not undergone formal review by the W3C; before this specification proceeds to a status of Final within the Jabber Software Foundation's standards process, it should undergo a formal review through communication with the Hypertext Coordination Group within the W3C.

                +

                The XHTML 1.0 Integration Set defined herein has been reviewed informally by an editor of the XHTML Modularization in XML Schema specification but has not undergone formal review by the W3C; before this specification proceeds to a status of Final within the XMPP Standards Foundation's standards process, it should undergo a formal review through communication with the Hypertext Coordination Group within the W3C.

                The W3C is actively working on &w3xhtml2; and may produce additional versions of XHTML in the future. This specification addresses XHTML 1.0 only, but it may be superseded or supplemented in the future by a XMPP Extension Protocol specification that defines methods for encapsulating XHTML 2.0 content in XMPP.

                @@ -858,7 +858,7 @@ That seems fine to me. Full documentation of this Integration Set is contained in "XEP-0071: XHTML-IM", a specification published by the - Jabber Software Foundation. + XMPP Standards Foundation. http://www.xmpp.org/extensions/xep-0071.html @@ -916,7 +916,7 @@ That seems fine to me. Full documentation of this Integration Set is contained in "XEP-0071: XHTML-IM", a specification published by the - Jabber Software Foundation, which is available at the + XMPP Standards Foundation, which is available at the following URL: http://www.xmpp.org/extensions/xep-0071.html @@ -990,7 +990,7 @@ That seems fine to me. Full documentation of this Integration Set is contained in "XEP-0071: XHTML-IM", a specification published by the - Jabber Software Foundation. + XMPP Standards Foundation. http://www.xmpp.org/extensions/xep-0071.html @@ -1173,6 +1173,6 @@ That seems fine to me.                 -

                This specification formalizes and extends earlier work by Jeremie Miller and Julian Missig on XHTML formatting of Jabber messages. Many thanks to Shane McCarron for his assistance regarding XHTML modularization and conformance issues. Thanks also to contributors on the Standards-JIG list for their feedback and suggestions.

                +

                This specification formalizes and extends earlier work by Jeremie Miller and Julian Missig on XHTML formatting of Jabber messages. Many thanks to Shane McCarron for his assistance regarding XHTML modularization and conformance issues. Thanks also to contributors on the Standards list for their feedback and suggestions.

                 diff --git a/xep-0072.xml b/xep-0072.xml index 98960dab..5bc6a4a2 100644 --- a/xep-0072.xml +++ b/xep-0072.xml @@ -12,7 +12,7 @@ 0072 Draft Standards Track - Standards JIG + Standards XMPP Core SOAP 1.2 @@ -1034,9 +1034,9 @@ -

                The main body of text that addresses the requirements of the W3C with regard to SOAP bindings is provided in the SOAP XMPP Binding section of this document. The current section addresses only the topic of organizational interaction between the W3C and the &JSF; regarding the SOAP XMPP Binding.

                +

                The main body of text that addresses the requirements of the W3C with regard to SOAP bindings is provided in the SOAP XMPP Binding section of this document. The current section addresses only the topic of organizational interaction between the W3C and the &XSF; regarding the SOAP XMPP Binding.

                -

                As was done with &xep0071;, the SOAP XMPP Binding defined herein has been reviewed informally by one or more appropriate experts from the W3C before the &COUNCIL; advanced it to a status of Draft within the JSF's standards process. Before this specification proceeds to a status of Final within the JSF's standards process, it should undergo a formal review through communication with the W3C's XML Protocol Working Group. To that end, revised versions of this specification will be announced on the W3C's public xml-dist-app@w3.org mailing list.

                +

                As was done with &xep0071;, the SOAP XMPP Binding defined herein has been reviewed informally by one or more appropriate experts from the W3C before the &COUNCIL; advanced it to a status of Draft within the XSF's standards process. Before this specification proceeds to a status of Final within the XSF's standards process, it should undergo a formal review through communication with the W3C's XML Protocol Working Group. To that end, revised versions of this specification will be announced on the W3C's public xml-dist-app@w3.org mailing list.

                This specification addresses SOAP 1.2 only. This specification may be superseded or supplemented in the future by a XMPP Extension Protocol specification that defines methods for encapsulating content defined by future versions of SOAP as published by the W3C.

                diff --git a/xep-0073.xml b/xep-0073.xml index ddf1c2fe..9dc11f3f 100644 --- a/xep-0073.xml +++ b/xep-0073.xml @@ -12,7 +12,7 @@ 0073 Draft Standards Track - Standards JIG + Standards XMPP Core XMPP IM @@ -94,7 +94,7 @@

Given the large number of Jabber/XMPP protocols, - 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 RFC 3920 (&xmppcore;) and RFC 3921 (&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. + 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 RFC 3920 (&xmppcore;) and RFC 3921 (&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. 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.

 diff --git a/xep-0074.xml b/xep-0074.xml index 8a29f727..9cdca022 100644 --- a/xep-0074.xml +++ b/xep-0074.xml @@ -12,7 +12,7 @@ 0074 Retracted Standards Track - Standards JIG + Standards XEP-0030 None None diff --git a/xep-0075.xml b/xep-0075.xml index 653c833a..463550f4 100644 --- a/xep-0075.xml +++ b/xep-0075.xml @@ -16,7 +16,7 @@ 0075 Deferred Standards Track - Standards JIG + Standards None None None diff --git a/xep-0076.xml b/xep-0076.xml index 1a45c2f4..141688c5 100644 --- a/xep-0076.xml +++ b/xep-0076.xml @@ -12,7 +12,7 @@ 0076 Active Humorous - Standards JIG + Standards XMPP Core RFC 3514 @@ -30,7 +30,7 @@ -

&rfc3514;, published just today (2003-04-01), defines a mechanism for specifying the "evil bit" in IPv4 in order to determine if a packet was sent with malicious intent. In Section 5 ("Related Work") of that RFC, reference is made to complementary mechanisms for other forms of evil such as IPv6 support and the application/evil MIME type. Because the &JSF; desires to maintain compliance with protocols developed by core Internet standards bodies, the current document defines a complementary mechanism for Jabber support of evil.

+

&rfc3514;, published just today (2003-04-01), defines a mechanism for specifying the "evil bit" in IPv4 in order to determine if a packet was sent with malicious intent. In Section 5 ("Related Work") of that RFC, reference is made to complementary mechanisms for other forms of evil such as IPv6 support and the application/evil MIME type. Because the &XSF; desires to maintain compliance with protocols developed by core Internet standards bodies, the current document defines a complementary mechanism for Jabber support of evil.

There are three basic Jabber stanza types that may be sent within XML streams:

diff --git a/xep-0077.xml b/xep-0077.xml index 74a15227..e45224ad 100644 --- a/xep-0077.xml +++ b/xep-0077.xml @@ -12,7 +12,7 @@ 0077 Final Standards Track - Standards JIG + Standards XMPP Core diff --git a/xep-0078.xml b/xep-0078.xml index 6a550c66..ff44eee6 100644 --- a/xep-0078.xml +++ b/xep-0078.xml @@ -12,7 +12,7 @@ 0078 Deprecated Standards Track - Standards JIG + Standards XMPP Core RFC 3174 diff --git a/xep-0079.xml b/xep-0079.xml index 9bb37c76..18e10676 100644 --- a/xep-0079.xml +++ b/xep-0079.xml @@ -12,7 +12,7 @@ 0079 Draft Standards Track - Standards JIG + Standards XMPP Core XEP-0030 @@ -90,7 +90,7 @@ 0.7 2003-12-10 lw - 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 + 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 0.6 @@ -1045,7 +1045,7 @@ -

The XMPP Registrar maintains a registry of AMP <rule/> conditions (see <http://www.jabber.org/registrar/amp-conditions.html>).

+

The XMPP Registrar maintains a registry of AMP <rule/> conditions at &CONDITIONS;.

®PROCESS; -

The XMPP Registrar maintains a registry of AMP <rule/> actions (see <http://www.jabber.org/registrar/amp-actions.html>).

+

The XMPP Registrar maintains a registry of AMP <rule/> actions at &ACTIONS;.

®PROCESS; 0080 Draft Standards Track - Standards JIG + Standards XMPP Core XEP-0060 @@ -95,7 +95,7 @@ 0.2 2003-07-29 psa -

Incorporated Standards JIG feedback; changed document type to Informational.

 +

Incorporated Standards list feedback; changed document type to Informational.

 0.1 diff --git a/xep-0081.xml b/xep-0081.xml index 738390b8..6578b03f 100644 --- a/xep-0081.xml +++ b/xep-0081.xml @@ -12,7 +12,7 @@ 0081 Retracted Standards Track - Standards JIG + Standards XMPP Core XMPP IM @@ -205,9 +205,9 @@ Encoding considerations: Same as encoding considerations of of RFC 3920, the encoding must be UTF-8. Security considerations: All of the security considerations specified in RFC 3023 and RFC 3920 apply to this XML media - type. Refer to Section 11 of JSF XEP-0081. + type. Refer to Section 11 of XSF XEP-0081. Interoperability considerations: (none) -Specification: JSF XEP-0081 +Specification: XSF XEP-0081 Applications which use this media type: non-XMPP applications (e.g., web browsers or email clients) that wish to invoke XMPP-compliant applications for instant messaging and @@ -218,7 +218,7 @@ Additional information: This media type is not to be confused Person and email address to contact for further information: XMPP Registrar, Intended usage: COMMON -Author/Change controller: JSF, XMPP Registrar +Author/Change controller: XSF, XMPP Registrar ]]> diff --git a/xep-0082.xml b/xep-0082.xml index f2e10cd0..ad9dc008 100644 --- a/xep-0082.xml +++ b/xep-0082.xml @@ -12,7 +12,7 @@ 0082 Active Informational - Standards JIG + Standards XMPP Core ISO 8601 @@ -133,7 +133,7 @@

The primary standard notation recommended by ISO 8601 includes the separators ("-" for dates and ":" for times), although ISO 8601 allows omission of the separators for applications in which compactness is more important than human readability. It is arguable whether Jabber applications using 'jabber:iq:time' and 'jabber:x:delay' require such compactness, but these protocols are in wide use today and have been implemented using the format shown above. Therefore, applications receiving data in those namespaces SHOULD be liberal in what they accept by handling datetimes either in the "CCYYMMDDThh:mm:ss" format or in the lexical representation defined in XML Schema and specified by this document. Applications generating data in those namespaces SHOULD use the existing format ("CCYYMMDDThh:mm:ss"), and are effectively "grandfathered" with respect to the date and time formats defined herein. While eventually it would be good to deprecate the older datetime representation for these protocols, the schedule for such deprecation (if any) shall be specified in official XEPs for these older protocols.

Jabber-RPC is a special case, since the specification for &xmlrpc; includes only one example for datetimes, which is of the format "CCYYMMDDThh:mm:ss". Apparently many implementations of XML-RPC have taken this lexical representation as canonical, and do not support any other representation; because Jabber-RPC normally provides an interface to software that is outside the Jabber network, it is prudent for Jabber-RPC implementations to generate dates in the format shown in the XML-RPC specification, not that defined in this document.

-

New protocols approved by the Jabber Software Foundation MUST use the lexical representations defined in this document.

+

New protocols approved by the XMPP Standards Foundation MUST use the lexical representations defined in this document.

The 'date', 'dateTime', and 'time' datatypes defined in XML Schema address several "edge cases" such as dates before the year 0000 and after the year 9999, as well as odd timezones no longer in use; most Jabber applications can safely ignore these edge cases, since it is highly unlikely that a Jabber entity will generate such representations.

diff --git a/xep-0083.xml b/xep-0083.xml index 8f06379b..1ad373c8 100644 --- a/xep-0083.xml +++ b/xep-0083.xml @@ -12,7 +12,7 @@ 0083 Active Informational - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0084.xml b/xep-0084.xml index 72e5d570..3f0b493d 100644 --- a/xep-0084.xml +++ b/xep-0084.xml @@ -10,9 +10,9 @@ This document defines an XMPP protocol extension for exchanging user avatars. &LEGALNOTICE; 0084 - Experimental + Deferred Standards Track - Standards JIG + Standards XMPP Core XEP-0030 @@ -28,6 +28,12 @@ &pgmillard; &temas; &xvirge; + + 0.9 + 2007-01-04 + psa +

Updated to reflect pubsub and PEP changes; added implementation notes about multiple resources and avatar synchronization.

 + 0.8 2006-06-19 @@ -555,6 +561,6 @@ -

Peter Millard, a co-author of this specification from version 0.1 through version 0.7, died on April 26, 2006. The remaining authors are thankful for his work on this specification.

+

Peter Millard, a co-author of this specification from version 0.1 through version 0.7, died on April 26, 2006. The remaining authors are thankful for his work on user avatars.

 diff --git a/xep-0085.xml b/xep-0085.xml index 1e044572..3a9c31c3 100644 --- a/xep-0085.xml +++ b/xep-0085.xml @@ -12,7 +12,7 @@ 0085 Draft Standards Track - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0086.xml b/xep-0086.xml index ab602063..12d68346 100644 --- a/xep-0086.xml +++ b/xep-0086.xml @@ -12,7 +12,7 @@ 0086 Active Informational - Standards JIG + Standards XMPP Core diff --git a/xep-0087.xml b/xep-0087.xml index 6af4cce0..ac03dd6f 100644 --- a/xep-0087.xml +++ b/xep-0087.xml @@ -12,7 +12,7 @@ 0087 Retracted Standards Track - Standards JIG + Standards XEP-0030 None XEP-0095 diff --git a/xep-0088.xml b/xep-0088.xml index 1f5791ab..91dd9c96 100644 --- a/xep-0088.xml +++ b/xep-0088.xml @@ -12,7 +12,7 @@ 0088 Deferred Informational - Standards JIG + Standards XMPP Core XEP-0030 diff --git a/xep-0089.xml b/xep-0089.xml index 4470be35..7c1bffa5 100644 --- a/xep-0089.xml +++ b/xep-0089.xml @@ -12,7 +12,7 @@ 0089 Deferred Standards Track - Standards JIG + Standards None None None diff --git a/xep-0090.xml b/xep-0090.xml index 869fde9e..cef02591 100644 --- a/xep-0090.xml +++ b/xep-0090.xml @@ -12,7 +12,7 @@ 0090 Active Historical - Standards JIG + Standards XMPP Core diff --git a/xep-0091.xml b/xep-0091.xml index db011fe4..b45bb5fb 100644 --- a/xep-0091.xml +++ b/xep-0091.xml @@ -12,7 +12,7 @@ 0091 Active Historical - Standards JIG + Standards Council XMPP Core diff --git a/xep-0092.xml b/xep-0092.xml index e141f52b..e0148686 100644 --- a/xep-0092.xml +++ b/xep-0092.xml @@ -12,7 +12,7 @@ 0092 Active Historical - Standards JIG + Standards XMPP Core diff --git a/xep-0093.xml b/xep-0093.xml index f9c44236..3aadf963 100644 --- a/xep-0093.xml +++ b/xep-0093.xml @@ -12,7 +12,7 @@ 0093 Deprecated Historical - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0094.xml b/xep-0094.xml index e46c2212..dcfea0b9 100644 --- a/xep-0094.xml +++ b/xep-0094.xml @@ -12,7 +12,7 @@ 0094 Obsolete Historical - Standards JIG + Standards XMPP Core diff --git a/xep-0095.xml b/xep-0095.xml index 3f834a71..e1e29581 100644 --- a/xep-0095.xml +++ b/xep-0095.xml @@ -12,7 +12,7 @@ 0095 Draft Standards Track - Standards JIG + Standards XMPP Core XEP-0030 @@ -308,7 +308,7 @@ -

The XMPP Registrar shall maintain a registry of stream initiation profiles, located at <http://www.jabber.org/registrar/si-profiles.html>. Any such profile defined in a XMPP Extension Protocol specification MUST be submitted to the XMPP Registrar; profiles defined in non-standard protocol extensions SHOULD be submitted to the XMPP Registrar.

+

The XMPP Registrar shall maintain a registry of stream initiation profiles, located at &SIPROFILES;. Any such profile defined in a XMPP Extension Protocol specification MUST be submitted to the XMPP Registrar; profiles defined in non-standard protocol extensions SHOULD be submitted to the XMPP Registrar.

®PROCESS; 0096 Draft Standards Track - Standards JIG + Standards XMPP Core XEP-0095 diff --git a/xep-0097.xml b/xep-0097.xml index 5cf01ce8..3fc3640f 100644 --- a/xep-0097.xml +++ b/xep-0097.xml @@ -12,7 +12,7 @@ 0097 Deferred Standards Track - Standards + Standards XEP-0030 None None @@ -89,7 +89,7 @@ SEQUENCE:3 SUMMARY:XEPs LOCATION:foundation@conference.jabber.org - CATEGORIES:JSF + CATEGORIES:XSF CLASS:PUBLIC TRANSP:OPAQUE LAST-MODIFIED:20030418T014527Z diff --git a/xep-0098.xml b/xep-0098.xml index a6e6161f..0f5114f7 100644 --- a/xep-0098.xml +++ b/xep-0098.xml @@ -12,7 +12,7 @@ 0098 Deferred Standards Track - Standards JIG + Standards None None None diff --git a/xep-0099.xml b/xep-0099.xml index bda34b4d..feb4dab6 100644 --- a/xep-0099.xml +++ b/xep-0099.xml @@ -12,7 +12,7 @@ 0099 Deferred Standards Track - Standards JIG + Standards None None None diff --git a/xep-0100.xml b/xep-0100.xml index d55273f5..f4179f0e 100644 --- a/xep-0100.xml +++ b/xep-0100.xml @@ -12,7 +12,7 @@ 0100 Active Informational - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0101.xml b/xep-0101.xml index 5efa2a7f..0e934832 100644 --- a/xep-0101.xml +++ b/xep-0101.xml @@ -12,7 +12,7 @@ 0101 Deferred Standards Track - Standards JIG + Standards RFC 2616, RFC 2617, XEP-0030 XMPP Core diff --git a/xep-0102.xml b/xep-0102.xml index 398b246b..77300951 100644 --- a/xep-0102.xml +++ b/xep-0102.xml @@ -12,7 +12,7 @@ 0102 Deferred Standards Track - Standards JIG + Standards None None None diff --git a/xep-0103.xml b/xep-0103.xml index d1913a79..6db98a09 100644 --- a/xep-0103.xml +++ b/xep-0103.xml @@ -12,7 +12,7 @@ 0103 Deferred Standards Track - Standards JIG + Standards XMPP Core XEP-0095 diff --git a/xep-0104.xml b/xep-0104.xml index e8c1c567..ae0960ef 100644 --- a/xep-0104.xml +++ b/xep-0104.xml @@ -12,7 +12,7 @@ 0104 Deferred Standards Track - Standards JIG + Standards XMPP Core RFC 3986 diff --git a/xep-0105.xml b/xep-0105.xml index c39d2615..1805b0a8 100644 --- a/xep-0105.xml +++ b/xep-0105.xml @@ -12,7 +12,7 @@ 0105 Deferred Standards Track - Standards JIG + Standards XEP-0095, XEP-0096 None None diff --git a/xep-0106.xml b/xep-0106.xml index 9a0dc1e2..0033d906 100644 --- a/xep-0106.xml +++ b/xep-0106.xml @@ -12,7 +12,7 @@ 0106 Draft Standards Track - Standards JIG + Standards XMPP Core XEP-0030 diff --git a/xep-0107.xml b/xep-0107.xml index dd55baee..51c1afad 100644 --- a/xep-0107.xml +++ b/xep-0107.xml @@ -12,7 +12,7 @@ 0107 Draft Standards Track - Standards JIG + Standards XMPP Core XEP-0060 diff --git a/xep-0108.xml b/xep-0108.xml index 800096b7..b4695a14 100644 --- a/xep-0108.xml +++ b/xep-0108.xml @@ -12,7 +12,7 @@ 0108 Draft Standards Track - Standards JIG + Standards XMPP Core XEP-0060 diff --git a/xep-0109.xml b/xep-0109.xml index 4dde2081..d935a657 100644 --- a/xep-0109.xml +++ b/xep-0109.xml @@ -12,7 +12,7 @@ 0109 Deferred Informational - Standards JIG + Standards XEP-0030, XEP-0082 None None diff --git a/xep-0110.xml b/xep-0110.xml index 7a37bb30..c8c88b4f 100644 --- a/xep-0110.xml +++ b/xep-0110.xml @@ -12,7 +12,7 @@ 0110 Deferred Standards Track - Standards JIG + Standards None None None diff --git a/xep-0111.xml b/xep-0111.xml index 155ba401..c4db77d4 100644 --- a/xep-0111.xml +++ b/xep-0111.xml @@ -12,7 +12,7 @@ 0111 Retracted Standards Track - Standards JIG + Standards XMPP Core RFC 2327 diff --git a/xep-0112.xml b/xep-0112.xml index 2aa8c0e5..99705536 100644 --- a/xep-0112.xml +++ b/xep-0112.xml @@ -12,7 +12,7 @@ 0112 Obsolete Standards Track - Standards JIG + Standards XMPP Core XEP-0060 diff --git a/xep-0113.xml b/xep-0113.xml index f5852364..e71bc6c7 100644 --- a/xep-0113.xml +++ b/xep-0113.xml @@ -12,7 +12,7 @@ 0113 Deferred Informational - Standards JIG + Standards None None None @@ -37,7 +37,7 @@ -

As explained in the now obsolete XEP-0010: Whiteboarding JIG XEP-0010: Whiteboarding JIG http://www.xmpp.org/extensions/xep-0010.html: "Jabber is often thought of simply as a system for instant messaging, albeit an open one. However, Jabber technology can be used, and is being used, in applications quite different from simple IM. One of these applications is whiteboarding. In collaborative work, the ability to draw (for example, to design sketches, UML schemas, house architectures, and organizational plans) is essential, as exemplified by the success of real-world whiteboarding applications such as Microsoft NetMeeting. Whiteboarding can also be used for entertainment purposes such as games and quizzes. Because of the value of whiteboarding as an important real-time collaboration tool, other IM services are beginning to offer these capabilities. For these and other reasons, I believe that a good protocol for whiteboarding in Jabber would be of great value".

+

As explained in the now obsolete XEP-0010: Whiteboarding XEP-0010: Whiteboarding SIG http://www.xmpp.org/extensions/xep-0010.html: "Jabber is often thought of simply as a system for instant messaging, albeit an open one. However, Jabber technology can be used, and is being used, in applications quite different from simple IM. One of these applications is whiteboarding. In collaborative work, the ability to draw (for example, to design sketches, UML schemas, house architectures, and organizational plans) is essential, as exemplified by the success of real-world whiteboarding applications such as Microsoft NetMeeting. Whiteboarding can also be used for entertainment purposes such as games and quizzes. Because of the value of whiteboarding as an important real-time collaboration tool, other IM services are beginning to offer these capabilities. For these and other reasons, I believe that a good protocol for whiteboarding in Jabber would be of great value".

The increasing penetration of pen-based devices, such as PDAs and tablet PCs, makes the need for a protocol that allows for sending freehand drawing information more urgent.

Several attempts have been made to create a whiteboarding protocol for Jabber:

    diff --git a/xep-0114.xml b/xep-0114.xml index 57764d9c..884adc02 100644 --- a/xep-0114.xml +++ b/xep-0114.xml @@ -12,7 +12,7 @@ 0114 Active Historical - Standards JIG + Standards XMPP Core diff --git a/xep-0115.xml b/xep-0115.xml index c6815d33..8e06a449 100644 --- a/xep-0115.xml +++ b/xep-0115.xml @@ -12,7 +12,7 @@ 0115 Draft Standards Track - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0116.xml b/xep-0116.xml index 9559ee23..3c7287e5 100644 --- a/xep-0116.xml +++ b/xep-0116.xml @@ -51,7 +51,7 @@ 0116 Experimental Standards Track - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0117.xml b/xep-0117.xml index f3238a64..36aaf0f0 100644 --- a/xep-0117.xml +++ b/xep-0117.xml @@ -12,7 +12,7 @@ 0117 Draft Standards Track - Standards JIG + Standards XMPP Core XMPP IM @@ -84,7 +84,7 @@
    • It addresses common needs of instant messaging users that are addressed by virtually all other popular IM services or systems.
    • It is more advanced than basic IM and presence.
      • -
    • It has achieved a status of at least Draft within the Jabber Software Foundation's standards process (as defined in &xep0001;).
      • +
    • It has achieved a status of at least Draft within the XMPP Standards Foundation's standards process (as defined in &xep0001;).
    diff --git a/xep-0118.xml b/xep-0118.xml index 3cde4f3d..545dfed8 100644 --- a/xep-0118.xml +++ b/xep-0118.xml @@ -12,7 +12,7 @@ 0118 Draft Standards Track - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0119.xml b/xep-0119.xml index b84ce120..c4bd729d 100644 --- a/xep-0119.xml +++ b/xep-0119.xml @@ -12,7 +12,7 @@ 0119 Retracted Standards Track - Standards JIG + Standards XMPP Core XMPP IM @@ -117,7 +117,7 @@ Service | Manager

    A protocol is deemed worthy of inclusion in this protocol suite if:

    • It addresses "extended presence" data that is defined in other presence services or protocols (e.g., Wireless Village or SIMPLE), or that is felt to be needed within the Jabber/XMPP community.
      • -
    • It has achieved a status of at least Draft within the Jabber Software Foundation's standards process (as defined in &xep0001;).
      • +
    • It has achieved a status of at least Draft within the XMPP Standards Foundation's standards process (as defined in &xep0001;).
     @@ -156,7 +156,7 @@ Service | Manager REQUIRED * -

    * Note: The User Avatar specification (XEP-0084) has not yet advanced to a status of Draft within the JSF's standards process, and the Extended Presence Protocol Suite will not be submitted for approval until it does so.

    +

    * Note: The User Avatar specification (XEP-0084) has not yet advanced to a status of Draft within the XSF's standards process, and the Extended Presence Protocol Suite will not be submitted for approval until it does so.

    Discovery of extended presence pubsub nodes is expedited through the use of Personal Eventing via Pubsub (PEP), since in PEP services there is a one-to-one relationship between payload types and NodeIDs. The NodeIDs MUST be as follows:

    diff --git a/xep-0120.xml b/xep-0120.xml index de4a74d0..5fdb9abc 100644 --- a/xep-0120.xml +++ b/xep-0120.xml @@ -15,7 +15,7 @@ 0120 Retracted Standards Track - Standards JIG + Standards XMPP Core None None diff --git a/xep-0121.xml b/xep-0121.xml index b3628b1d..5c9b4062 100644 --- a/xep-0121.xml +++ b/xep-0121.xml @@ -15,7 +15,7 @@ 0121 Retracted Informational - Standards JIG + Standards XEP-0120 None None diff --git a/xep-0122.xml b/xep-0122.xml index 890992bf..bedf5622 100644 --- a/xep-0122.xml +++ b/xep-0122.xml @@ -12,7 +12,7 @@ 0122 Draft Standards Track - Standards JIG + Standards XMPP Core XEP-0004 @@ -339,7 +339,7 @@ -

    The XMPP Registrar maintains a registry of datatype prefixes used in the context of Data Forms Validation (see http://www.jabber.org/registrar/xdv-prefixes.html), where each prefix denotes a group of related datatypes.

    +

    The XMPP Registrar maintains a registry of datatype prefixes used in the context of Data Forms Validation (see &XDVPREFIXES;), where each prefix denotes a group of related datatypes.

    ®PROCESS;     -

    The XMPP Registrar maintains a registry of datatypes used in the context of Data Forms Validation (see http://www.jabber.org/registrar/xdv-datatypes.html), where each datatype name includes the relevant prefix (e.g., "xs:anyURI").

    +

    The XMPP Registrar maintains a registry of datatypes used in the context of Data Forms Validation (see &XDVTYPES;), where each datatype name includes the relevant prefix (e.g., "xs:anyURI").

    ®PROCESS; 0123 Retracted Standards Track - Standards JIG + Standards XMPP Core, XMPP IM, XEP-0030, XEP-0120 None None @@ -53,7 +53,7 @@
    1. Applicable not just to people but to any entity on the network, including but not limited to servers, components, bots, &xep0045; rooms, &xep0060; nodes, and in general anything that can be addressed as a Jabber ID (as defined in &xmppcore;).
    2. Usable in encapsulating any information about the entity itself (name, address, description, title, etc.).
      3. -
    3. Extensible enough to handle any metadata that may be needed for current and future applications (including, at a minimum, everything that can be defined in vCard); it must be possible to use it for public protocols defined by the IETF or Jabber Software Foundation as well as for custom or private protocols.
      4. +
    4. Extensible enough to handle any metadata that may be needed for current and future applications (including, at a minimum, everything that can be defined in vCard); it must be possible to use it for public protocols defined by the IETF or XMPP Standards Foundation as well as for custom or private protocols.
    5. Well-defined enough, through datatyping and public registries where applicable, to enable robust searching and filtering based on defined data fields and their values.
     diff --git a/xep-0124.xml b/xep-0124.xml index c249d127..9ea792db 100644 --- a/xep-0124.xml +++ b/xep-0124.xml @@ -12,7 +12,7 @@ 0124 Draft Standards Track - Standards JIG + Standards XMPP Core RFC 1945 diff --git a/xep-0125.xml b/xep-0125.xml index 77333671..258b556a 100644 --- a/xep-0125.xml +++ b/xep-0125.xml @@ -15,7 +15,7 @@ 0125 Retracted Informational - Standards JIG + Standards XEP-0120 None None diff --git a/xep-0126.xml b/xep-0126.xml index cdf04ec0..9195770b 100644 --- a/xep-0126.xml +++ b/xep-0126.xml @@ -12,7 +12,7 @@ 0126 Active Informational - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0127.xml b/xep-0127.xml index 6a6b5ed1..fd55bae9 100644 --- a/xep-0127.xml +++ b/xep-0127.xml @@ -12,7 +12,7 @@ 0127 Active Informational - Standards JIG + Standards XMPP Core Common Alerting Protocol diff --git a/xep-0128.xml b/xep-0128.xml index 92aa6377..6ef50fe6 100644 --- a/xep-0128.xml +++ b/xep-0128.xml @@ -12,7 +12,7 @@ 0128 Active Informational - Standards JIG + Standards XMPP Core XEP-0004 @@ -63,7 +63,7 @@ ]]>

    Note: A <field/> element MAY contain more than one <value/> child if appropriate.

    -

    If the data fields are to be used in the context of a protocol approved by the Jabber Software Foundation, they SHOULD be described in the relevant XMPP Extension Protocol specification and registered in accordance with the rules defined in XEP-0068, resulting in the inclusion of a <field/> element whose 'var' attribute has a value of "FORM_TYPE" and whose 'type' attribute has a value of "hidden".

    +

    If the data fields are to be used in the context of a protocol approved by the XMPP Standards Foundation, they SHOULD be described in the relevant XMPP Extension Protocol specification and registered in accordance with the rules defined in XEP-0068, resulting in the inclusion of a <field/> element whose 'var' attribute has a value of "FORM_TYPE" and whose 'type' attribute has a value of "hidden".

    An entity MUST NOT supply extended information about associated children communicated via the 'http://jabber.org/protocol/disco#items' namespace, since a core principle of Service Discovery is that an entity must define its own identity only and must not define the identity of any children associated with the entity.

    @@ -156,7 +156,7 @@ -

    In general, the Jabber Software Foundation may choose to define at most one FORM_TYPE for each service discovery identity (category+type) registered with the XMPP Registrar. In addition, particular applications may define application-specific FORM_TYPEs as well, and one entity may have multiple service discovery identities (e.g., an XMPP server might also function as a publish-subscribe service). Therefore, it is possible (and allowed) for a single service discovery result to contain multiple service discovery extension elements (potentially up to two elements for each identity). However, in practice it is unlikely that any given service discovery result will contain more than one service discovery extension element.

    +

    In general, the XMPP Standards Foundation may choose to define at most one FORM_TYPE for each service discovery identity (category+type) registered with the XMPP Registrar. In addition, particular applications may define application-specific FORM_TYPEs as well, and one entity may have multiple service discovery identities (e.g., an XMPP server might also function as a publish-subscribe service). Therefore, it is possible (and allowed) for a single service discovery result to contain multiple service discovery extension elements (potentially up to two elements for each identity). However, in practice it is unlikely that any given service discovery result will contain more than one service discovery extension element.

    Applications SHOULD ensure that information disclosed in a disco extension is appropriate for discovery by any entity on the network.

    diff --git a/xep-0129.xml b/xep-0129.xml index 49090726..f6efcf3e 100644 --- a/xep-0129.xml +++ b/xep-0129.xml @@ -12,7 +12,7 @@ 0129 Deferred Informational - Standards JIG + Standards XMPP Core RFC 2518 diff --git a/xep-0130.xml b/xep-0130.xml index eed8a045..943cc2b4 100644 --- a/xep-0130.xml +++ b/xep-0130.xml @@ -12,7 +12,7 @@ 0130 Active Historical - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0131.xml b/xep-0131.xml index 5f88f879..f3c168e8 100644 --- a/xep-0131.xml +++ b/xep-0131.xml @@ -12,7 +12,7 @@ 0131 Draft Standards Track - Standards JIG + Standards XMPP Core XEP-0030 diff --git a/xep-0132.xml b/xep-0132.xml index 0561f3e7..43eee6cc 100644 --- a/xep-0132.xml +++ b/xep-0132.xml @@ -12,7 +12,7 @@ 0132 Active Humorous - None + None XMPP Core XMPP IM @@ -177,7 +177,7 @@     -

    Determination of physical presence necessarily involves an invasion of the target entity's "personal space". The &JSF; shall not be held liable for any use of this protocol. Client implementations MUST enable the user to disable support for this protocol via configuration options.

    +

    Determination of physical presence necessarily involves an invasion of the target entity's "personal space". The &XSF; shall not be held liable for any use of this protocol. Client implementations MUST enable the user to disable support for this protocol via configuration options.

    Responding entities (whether server or client) MUST NOT return physical presence information to requesting entities that are not entitled to discover such information.

    diff --git a/xep-0133.xml b/xep-0133.xml index 05ec5646..ac242ebb 100644 --- a/xep-0133.xml +++ b/xep-0133.xml @@ -12,7 +12,7 @@ 0133 Active Informational - Standards JIG + Standards RFC 3920 XEP-0050 diff --git a/xep-0134.xml b/xep-0134.xml index 2a7c3ae4..41777978 100644 --- a/xep-0134.xml +++ b/xep-0134.xml @@ -12,7 +12,7 @@ 0134 Active Informational - Standards JIG + Standards Council @@ -56,7 +56,7 @@

    Background

    -

    When the &JSF; submitted the XMPP Core and XMPP IM specifications to the &IETF;, it ceded change control over the core XML streaming technology developed by the Jabber community. However, the JSF has reserved the right to define extensions to XMPP; furthermore, that right is not exclusive to the JSF, since anyone can define their own public or private extensions to XMPP. These extensions are usually in the form of structured XML data that is qualified by a unique namespace other than those currently reserved by the IETF or the JSF.

    +

    When the &XSF; submitted the XMPP Core and XMPP IM specifications to the &IETF;, it ceded change control over the core XML streaming technology developed by the Jabber community. However, the XSF has reserved the right to define extensions to XMPP; furthermore, that right is not exclusive to the XSF, since anyone can define their own public or private extensions to XMPP. These extensions are usually in the form of structured XML data that is qualified by a unique namespace other than those currently reserved by the IETF or the XSF.

    Meaning

    When we say that "XMPP is Sacred", we mean that good protocol design must work within the context of XMPP and not require changes to the core protocols. For one thing, any such changes would need to be pursued within the IETF. Further, the core semantics most likely provide everything that a protocol designer needs. If you think that you need to define a new kind of top-level stanza (other than &MESSAGE;, &PRESENCE;, and &IQ;) or a new value of the 'type' attribute for any stanza kind, then you need to think again. Treat XMPP as a transport layer and build extensions on top of that layer (among other things, this implies that you must not modify the foundation when you are working on higher-level structures, for example by adding adding elements and attributes to the XMPP schemas on the theory that if applications will ignore them; define your own extensions in a separate namespace). A further implication of respecting XMPP is using structured data formats (e.g., applications of &w3xml; rather than binary or plaintext formats) whenever possible. Finally, as explained in XMPP Core, the &PRESENCE; stanza exists to broadcast network and communications availability only; for more advanced information publishing, use &xep0060;.

    Examples

    @@ -80,7 +80,7 @@

    Background

    The Jabber community has been developing wire protocols for XML streaming, presence, and instant messaging since 1999. In that time, members of the community have defined a number of building blocks that can be used as the basis for further development. Furthermore, many smart people have created open protocols within other standards development organizations, including the IETF, the &W3C;, &OASIS;, the &ITU;, and the &DUBLINCORE;.

    Meaning

    -

    Good protocol designers "stand on the shoulders of giants" by re-using protocols that have been defined within the JSF and within other standards development organizations. That does not mean we don't define new protocols, because sometimes that is necessary. However, we are aware of work completed by others and we make use of it, especially when that work is outside the Jabber community's core competence areas (e.g., security or multimedia data formats rather than XML streaming, presence, and real-time messaging). Furthermore, the JSF prefers to re-use open protocols wherever possible. Finally, just as with XMPP, so also with XMPP extensions defined through the JSF: do not modify existing schemas (e.g., adding new elements and attributes) except through the XMPP extension process; instead, define extensions in a separate namespace).

    +

    Good protocol designers "stand on the shoulders of giants" by re-using protocols that have been defined within the XSF and within other standards development organizations. That does not mean we don't define new protocols, because sometimes that is necessary. However, we are aware of work completed by others and we make use of it, especially when that work is outside the Jabber community's core competence areas (e.g., security or multimedia data formats rather than XML streaming, presence, and real-time messaging). Furthermore, the XSF prefers to re-use open protocols wherever possible. Finally, just as with XMPP, so also with XMPP extensions defined through the XSF: do not modify existing schemas (e.g., adding new elements and attributes) except through the XMPP extension process; instead, define extensions in a separate namespace).

    Examples

    Examples of re-using existing Jabber protocols include &xep0095; (which re-uses &xep0020;) and XEP-0126: Invisibility (which re-uses the privacy lists protocol defined in XMPP IM). Examples of re-using non-Jabber protocols include &xep0065; (which makes use of &rfc1928;) and &xep0127; (which defines a way to send &oasiscap; data via Jabber). Here again XEP-0071 provides an example: it re-uses XHTML 1.0 (an open protocol developed by a recognized standards development organization) rather than RTF (a closed protocol under the control of the Microsoft Corporation).

     @@ -122,7 +122,7 @@

    Background

    Since the beginning, privacy and security have been important priorities within the Jabber community. That must not change.

    Meaning

    -

    Good protocols respect the confidentiality of data generated or communicated by users and applications as well as the security of the system or network as a whole. Although privacy and security considerations have been dealt with at the core XMPP layer, application-level protocols must not compromise privacy and security. Attention to these matters, along with rigorous cross-area review and close scrutiny by protocol designers (in the form of the &COUNCIL; and &SJIG;), will help ensure that the protocols we develop will provide a strong foundation for communication over the Internet.

    +

    Good protocols respect the confidentiality of data generated or communicated by users and applications as well as the security of the system or network as a whole. Although privacy and security considerations have been dealt with at the core XMPP layer, application-level protocols must not compromise privacy and security. Attention to these matters, along with rigorous cross-area review and close scrutiny by protocol designers (in the form of the &COUNCIL; and &SSIG;), will help ensure that the protocols we develop will provide a strong foundation for communication over the Internet.

    Examples

    As is well-known, the presence subscription model developed by the Jabber community and specified in XMPP IM requires approval before a contact can view a user's presence. Similarly, Jabber has always included strong authentication methods, which have been further improved through the use of SASL (&rfc4422;).

    diff --git a/xep-0135.xml b/xep-0135.xml index 2a17f726..e5bb6797 100644 --- a/xep-0135.xml +++ b/xep-0135.xml @@ -12,7 +12,7 @@ 0135 Deferred Standards Track - Standards JIG + Standards XMPP Core XEP-0030 diff --git a/xep-0136.xml b/xep-0136.xml index bd6e648c..956dbfb0 100644 --- a/xep-0136.xml +++ b/xep-0136.xml @@ -12,7 +12,7 @@ 0136 Proposed Standards Track - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0137.xml b/xep-0137.xml index 6a7670cf..5b9e4747 100644 --- a/xep-0137.xml +++ b/xep-0137.xml @@ -12,7 +12,7 @@ 0137 Draft Standards Track - Standards JIG + Standards XMPP Core XEP-0030 diff --git a/xep-0138.xml b/xep-0138.xml index 3557372b..22923ec3 100644 --- a/xep-0138.xml +++ b/xep-0138.xml @@ -12,7 +12,7 @@ 0138 Draft Standards Track - Standards JIG + Standards XMPP Core @@ -218,7 +218,7 @@

    The XMPP Registrar includes 'http://jabber.org/protocol/compress' in its registry of protocol namespaces.

    -

    The XMPP Registrar maintains a registry of compression methods at <http://www.jabber.org/registrar/compress.html>.

    +

    The XMPP Registrar maintains a registry of compression methods at &COMPRESSMETHODS;.

    ®PROCESS;
    - Security JIG - This document proposes the formation of a Jabber Interest Group devoted to the analysis of security threats related to Jabber technologies. + Security SIG + This document proposes the formation of a Special Interest Group devoted to the analysis of security threats related to Jabber technologies. &LEGALNOTICE; 0139 Retracted - JIG Formation - None + SIG Formation + None @@ -28,7 +28,7 @@ 0.2 2004-09-15 psa - Changed status to Retracted since it now appears unnecessary to form a JIG in order to complete this work; rather, it should be sufficient to write a XEP and solicit feedback from appropriate security experts before the Last Call. However, such a XEP should use the process described herein. + Changed status to Retracted since it now appears unnecessary to form a SIG in order to complete this work; rather, it should be sufficient to write a XEP and solicit feedback from appropriate security experts before the Last Call. However, such a XEP should use the process described herein. 0.1 @@ -44,22 +44,22 @@
    -

    Because security is a core value within the Jabber community, it is appropriate for the Jabber Software Foundation to assess potential security threats related to technologies that implement the Jabber protocols (including XMPP and defined XMPP extensions), as well as ways to address the threats (for general information about the Internet threat model, see &rfc3552;). Furthermore, since security threats are wide-ranging and of broad concern, it would be valuable for interested members of the entire Jabber community to discuss these matters. Unfortunately, security discussions can often be theoretical, contentious, and inconclusive. Thus it is imperative that discussion proceed based on a methodical process of threat identification, risk analysis, and prioritization before moving on to documentation of threat responses (preferably in protocol specifications such as &xep0001;). This document proposes a forum and process for such security discussions in the form of a Jabber Interest Group (see &xep0002;) that shall report to the &COUNCIL; in accordance with Article VIII of the &BYLAWS;.

    +

    Because security is a core value within the Jabber community, it is appropriate for the XMPP Standards Foundation to assess potential security threats related to technologies that implement the Jabber protocols (including XMPP and defined XMPP extensions), as well as ways to address the threats (for general information about the Internet threat model, see &rfc3552;). Furthermore, since security threats are wide-ranging and of broad concern, it would be valuable for interested members of the entire Jabber community to discuss these matters. Unfortunately, security discussions can often be theoretical, contentious, and inconclusive. Thus it is imperative that discussion proceed based on a methodical process of threat identification, risk analysis, and prioritization before moving on to documentation of threat responses (preferably in protocol specifications such as &xep0001;). This document proposes a forum and process for such security discussions in the form of a Special Interest Group (see &xep0002;) that shall report to the &COUNCIL; in accordance with Article VIII of the &BYLAWS;.

     -

    The role of the Security JIG shall be to identify and describe security threats related to Jabber technologies, analyze their potential risk, assign priorities to each threat, provide references to existing responses, and (where appropriate) provisionally recommend improvements in Jabber protocols and technologies in order to address the identified threats. The Security JIG shall not itself develop or approve protocols, which tasks shall remain under the purview of the &SJIG; and the Jabber Council respectively.

    +

    The role of the Security SIG shall be to identify and describe security threats related to Jabber technologies, analyze their potential risk, assign priorities to each threat, provide references to existing responses, and (where appropriate) provisionally recommend improvements in Jabber protocols and technologies in order to address the identified threats. The Security SIG shall not itself develop or approve protocols, which tasks shall remain under the purview of the &SSIG; and the Jabber Council respectively.

     -

    The Security JIG shall be open to the public and shall not be limited to elected members of the Jabber Software Foundation. Security JIG discussions shall be conducted in open forums, including a dedicated mailing list at <security-jig@jabber.org>. The process for moderating such discussions shall be decided by the members of the Security JIG, but such moderation is strongly encouraged in order to follow the orderly process of threat identification and risk analysis outlined below.

    +

    The Security SIG shall be open to the public and shall not be limited to elected members of the XMPP Standards Foundation. Security SIG discussions shall be conducted in open forums, including a dedicated mailing list at <security-jig@jabber.org>. The process for moderating such discussions shall be decided by the members of the Security SIG, but such moderation is strongly encouraged in order to follow the orderly process of threat identification and risk analysis outlined below.

     -

    The Security JIG shall be a standing JIG, and shall exist as long as the Jabber Council deems it useful.

    +

    The Security SIG shall be a standing SIG, and shall exist as long as the Jabber Council deems it useful.

     -

    The Security JIG shall produce at least the following deliverables:

    +

    The Security SIG shall produce at least the following deliverables:

    1. -

      A brief document specifying the process by which the JIG shall identify, define, analyze, and prioritize a collection of documented security-related threats. This process document will not identify threats or define ways to address them, but instead specify the process to be followed in Steps 2 and 3 below. In defining the process, the JIG should also describe some of its guiding principles, such as:

      +

      A brief document specifying the process by which the SIG shall identify, define, analyze, and prioritize a collection of documented security-related threats. This process document will not identify threats or define ways to address them, but instead specify the process to be followed in Steps 2 and 3 below. In defining the process, the SIG should also describe some of its guiding principles, such as:

      1. Rough consensus and running code are superior to "perfect" solutions
      2. Security measures that cannot or will not be implemented are useless
        3. diff --git a/xep-0140.xml b/xep-0140.xml index 206d2b82..50e092bb 100644 --- a/xep-0140.xml +++ b/xep-0140.xml @@ -12,7 +12,7 @@ 0140 Retracted Informational - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0141.xml b/xep-0141.xml index 089c2d0d..ff40ef1e 100644 --- a/xep-0141.xml +++ b/xep-0141.xml @@ -12,7 +12,7 @@ 0141 Draft Standards Track - Standards JIG + Standards XMPP Core XEP-0004 @@ -66,7 +66,7 @@

        All of the use cases refer to the following form:

        - JSF Application + XSF Application Please fill out this form @@ -100,14 +100,14 @@

        One of the simplest layout usages is to partition fields into pages. This is done by including one or more <page/> elements within the x:data form. Each <page/> element SHOULD possess a "label" attribute to label the page, MAY contain a <text/> child element for additional information, and SHOULD contain a <fieldref/> element for each field to be included in the page. To reference an x:data field, the <fieldref/> element's "var" attribute MUST be the same as the intended <field/> element's "var" attribute.

        - JSF Application + XSF Application Please fill out this form This is page one of three. - Note: In accordance with the JSF privacy policy, your personal information will + Note: In accordance with the XSF privacy policy, your personal information will never be shared outside the organization in any way for any purpose; however, - your name and JID may be published in the JSF membership directory. + your name and JID may be published in the XSF membership directory. @@ -130,7 +130,7 @@ You're almost done! This is where you describe your future plans and why you think you - deserve to be a member of the Jabber Software Foundation. + deserve to be a member of the XMPP Standards Foundation. @@ -165,14 +165,14 @@

        The next usage of layout is to partition pages into sections. This is done by including one or more <section/> elements within each <page/> element. Each <section/> element SHOULD possess a "label" attribute to identify the section, MAY contain a <text/> child element for additional information, and SHOULD contain a <fieldref/> element for each field to be included in the section. A <section/> element MUST contain at least one <fieldref/> element or <reportedref/> element. To reference an x:data field, the <fieldref/> element's "var" attribute MUST be the same as the intended <field/> element's "var" attribute.

        - JSF Application + XSF Application Please fill out this form
        - Note: In accordance with the JSF privacy policy, your personal information will + Note: In accordance with the XSF privacy policy, your personal information will never be shared outside the organization in any way for any purpose; however, - your name and JID may be published in the JSF membership directory. + your name and JID may be published in the XSF membership directory. @@ -193,7 +193,7 @@ You're almost done! This is where you describe your future plans and why you think you - deserve to be a member of the Jabber Software Foundation. + deserve to be a member of the XMPP Standards Foundation. @@ -232,9 +232,9 @@
        - Note: In accordance with the JSF privacy policy, your personal information will + Note: In accordance with the XSF privacy policy, your personal information will never be shared outside the organization in any way for any purpose; however, - your name and JID may be published in the JSF membership directory. + your name and JID may be published in the XSF membership directory.
        Who are you? @@ -260,7 +260,7 @@
        This is where you describe your future plans and why you think you - deserve to be a member of the Jabber Software Foundation. + deserve to be a member of the XMPP Standards Foundation. diff --git a/xep-0142.xml b/xep-0142.xml index 317a4b38..03d191f4 100644 --- a/xep-0142.xml +++ b/xep-0142.xml @@ -12,7 +12,7 @@ 0142 Deferred Standards Track - Standards JIG + Standards XMPP Core XEP-0030 diff --git a/xep-0143.xml b/xep-0143.xml index 102d0c17..a2e786fa 100644 --- a/xep-0143.xml +++ b/xep-0143.xml @@ -12,7 +12,7 @@ 0143 Active Procedural - Standards JIG + Standards Council XEP-0001 @@ -53,8 +53,8 @@ -

        The &JSF; receives a significant number of proposals for defining extensions to the core XMPP protocols specified in &xmppcore;. However, it is not always clear to authors how to best structure a proposal in order for it to be accepted as an XMPP Extension Protocol (XEP) and then advance through the JSF's standards process. Therefore, this document provides guidelines that are intended to help authors write better XMPP Extension Protocol specifications.

        -

        These guidelines assume that the reader is familiar with the XEP series of documents and the processes for handling them within the JSF, as defined in &xep0001;.

        +

        The &XSF; receives a significant number of proposals for defining extensions to the core XMPP protocols specified in &xmppcore;. However, it is not always clear to authors how to best structure a proposal in order for it to be accepted as an XMPP Extension Protocol (XEP) and then advance through the XSF's standards process. Therefore, this document provides guidelines that are intended to help authors write better XMPP Extension Protocol specifications.

        +

        These guidelines assume that the reader is familiar with the XEP series of documents and the processes for handling them within the XSF, as defined in &xep0001;.

        The prospective author is strongly encouraged to complete some research before submitting a proposal for consideration as an XMPP Extension Protocol. In particular, the author should do the following:

        @@ -62,7 +62,7 @@
      3. Review the XMPP RFCs and experimental or approved XMPP Extension Protocols to determine if the proposed protocol extension is truly needed in order to fill a gap in existing Jabber/XMPP technologies and protocols.
      4. Review rejected and deferred XMPP Extension Protocol specifications to determine if similar extensions have been proposed in the past but not approved by the &COUNCIL;.
      5. Review protocols developed within other standards development organizations, such as the &IETF; and &W3C;, to determine if they might be more appropriate than a new XMPP extension.
        6. -
      6. Review discussions within the &SJIG; to determine if similar functionality has been discussed in the past or is currently under discussion.
        7. +
      7. Review discussions within the &SSIG; to determine if similar functionality has been discussed in the past or is currently under discussion.

        8. After completing this research, the prospective author may conclude that a new protocol extension is needed. If so, the author is strongly advised to do the following:

          @@ -78,7 +78,7 @@
          1. Contact the &EDITOR; so that he knows to expect your submission.
          2. Write your proposal following the guidelines described herein.
            3. -
          3. Make sure you read, understand, and agree to the &JSFIPR; before you submit your proposal.
            4. +
          4. Make sure you read, understand, and agree to the &XSFIPR; before you submit your proposal.
          5. Send your XML file (or a URL for the file) to the XMPP Extensions Editor.
          @@ -96,7 +96,7 @@

          The XML character data of the <title/> element is the title of your XEP. Choose a descriptive title that is less than five words long. The XMPP Extensions Editor may change this in consultation with the author.

          The XML character data of the <abstract/> element SHOULD be one sentence that captures the essence of your proposal (usually beginning "This document defines a protocol that..."). The XMPP Extensions Editor has been known to modify the abstract so that it accurately describes the proposal.

          The XML character data of the <legal/> element MUST be as follows:

          -

          This XMPP Extension Protocol is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy (<http://www.xmpp.org/extensions/ipr-policy.shtml>). This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

          +

          This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy (<http://www.xmpp.org/extensions/ipr-policy.shtml>). This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

          The XML character data of the <number/> element SHOULD be "xxxx"; this will be changed to the next sequential XEP number by the XMPP Extensions Editor if the XMPP Council accepts the proposal as an XMPP Extensions Protocol.

          The XML character data of the <status/> element SHOULD be "ProtoXEP" since all proposals start out as "proto-XEPs"; this will be changed to "Experimental" if the XMPP Council accepts the proposal as an XMPP Extensions Protocol.

          The XML character data of the <type/> element SHOULD be either "Standards Track" or "Informational" (there are also Historical, Humorous, and Procedural XEPs, but these are uncommon and usually written by the XMPP Extensions Editor). A Standards Track XEP defines a XMPP extension intended to be used as a common part of Jabber/XMPP technologies. An Informational XEP defines best practices or a usage profile related to XMPP or an XMPP Extension Protocol (e.g., &xep0175;).

          @@ -140,7 +140,7 @@
        1. Describe the expected behavior of Jabber/XMPP clients, servers, and components when using this protocol.
        2. Include lots of protocol examples.
          3. -

          We just said so, but we will repeat ourselves: include lots of protocol examples. Examples help not only implementors but also those who will review your proposal in the Standards JIG and XMPP Council. You get extra credit with the XMPP Extensions Editor if you follow Jabber tradition by using characters and situations from the plays of Shakespeare:

          +

          We just said so, but we will repeat ourselves: include lots of protocol examples. Examples help not only implementors but also those who will review your proposal in the Standards SIG and XMPP Council. You get extra credit with the XMPP Extensions Editor if you follow Jabber tradition by using characters and situations from the plays of Shakespeare:

          This section is REQUIRED. The IANA is the Internet Assigned Numbers Authority, the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. Most proposals do not require interaction with the IANA, in which case the text of this section SHOULD read "This document requires no interaction with the Internet Assigned Numbers Authority (IANA)." If your proposal requires interaction with the IANA, discuss the matter with the XMPP Extensions Editor. Do not contact the IANA on your own!

          -

          This section is REQUIRED. The XMPP Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. If your proposal does not require interaction with the XMPP Registrar, the text of this section SHOULD read "No namespaces or parameters need to be registered with the XMPP Registrar as a result of this document." Refer to Draft or Final XEPs for appropriate text in other cases, or consult with the XMPP Extensions Editor.

          +

          This section is REQUIRED. The XMPP Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the XMPP Standards Foundation. If your proposal does not require interaction with the XMPP Registrar, the text of this section SHOULD read "No namespaces or parameters need to be registered with the XMPP Registrar as a result of this document." Refer to Draft or Final XEPs for appropriate text in other cases, or consult with the XMPP Extensions Editor.

          An XML Schema is required in order for protocols to be approved by the XMPP Council. The XMPP Extensions Editor can assist you in defining an XML Schema for the protocol you are proposing.

          @@ -244,7 +244,7 @@ echo -n 'bard@shakespeare.lit' | openssl dgst -sha1

          An element or attribute is qualified by (rather than "scoped by" or "in") a particular namespace.

           -

          For precision, the JSF follows IETF usage by placing all punctuation outside the quotation marks unless one is quoting text that includes the punctuation. Example: the port used for client communications is "5222".

          +

          For precision, the XSF follows IETF usage by placing all punctuation outside the quotation marks unless one is quoting text that includes the punctuation. Example: the port used for client communications is "5222".

           diff --git a/xep-0144.xml b/xep-0144.xml index 4192fe99..4af79e3d 100644 --- a/xep-0144.xml +++ b/xep-0144.xml @@ -12,7 +12,7 @@ 0144 Draft Standards Track - Standards JIG + Standards XMPP Core XMPP IM @@ -82,7 +82,7 @@ -

          The Jabber protocols have long included a method for sending roster items from one entity to another, making use of the 'jabber:x:roster' namespace. Because this protocol extension was not required by &rfc2779;, it was removed from &xmppim; and documented for historical purposes in &xep0093;. However, since that time discussions in the &SJIG; have revealed that it would be helpful to use roster item exchange in the problem spaces of "shared groups" (e.g., predefined roster groups used within an organization) and roster synchronization (e.g., keeping a Jabber roster in sync with a contact list on a legacy IM service). These problem spaces require a slightly more sophisticated kind of roster item exchange than was documented in XEP-0093, specifically the ability to indicate whether a roster item is to be added, deleted, or modified. Therefore this document redefines roster item exchange to provide this functionality in a way that is backwards-compatible with existing implementations, albeit using a modern namespace URI of 'http://jabber.org/protocol/rosterx' rather than the old 'jabber:x:roster' namespace name. Further specifications will define how to solve the problems of shared groups and roster synchronization using the protocol defined herein.

          +

          The Jabber protocols have long included a method for sending roster items from one entity to another, making use of the 'jabber:x:roster' namespace. Because this protocol extension was not required by &rfc2779;, it was removed from &xmppim; and documented for historical purposes in &xep0093;. However, since that time discussions in the &SSIG; have revealed that it would be helpful to use roster item exchange in the problem spaces of "shared groups" (e.g., predefined roster groups used within an organization) and roster synchronization (e.g., keeping a Jabber roster in sync with a contact list on a legacy IM service). These problem spaces require a slightly more sophisticated kind of roster item exchange than was documented in XEP-0093, specifically the ability to indicate whether a roster item is to be added, deleted, or modified. Therefore this document redefines roster item exchange to provide this functionality in a way that is backwards-compatible with existing implementations, albeit using a modern namespace URI of 'http://jabber.org/protocol/rosterx' rather than the old 'jabber:x:roster' namespace name. Further specifications will define how to solve the problems of shared groups and roster synchronization using the protocol defined herein.

          XEP-0093 did not define the requirements for roster item exchange. This section remedies that oversight.

          @@ -237,7 +237,7 @@

        These are described more completely below.

        -

        Roster item exchange as developed within the early Jabber community and documented in XEP-0093 was used to send a roster item from one user to another in a manner more structured than simply typing a third party's JID in a chat window. This usage is still encouraged. However, if the sender is a human user and/or the sending application has a primary Service Discovery category of "client" (e.g., a bot) See <http://www.jabber.org/registrar/disco-categories.html#client>., the sending application SHOULD NOT specify an 'action' attribute other than "add", the receiving application MAY ignore values of the 'action' attribute other than "add", and the receiving application MUST prompt a human user regarding whether to add the suggested item or items to the user's roster.

        +

        Roster item exchange as developed within the early Jabber community and documented in XEP-0093 was used to send a roster item from one user to another in a manner more structured than simply typing a third party's JID in a chat window. This usage is still encouraged. However, if the sender is a human user and/or the sending application has a primary Service Discovery category of "client" (e.g., a bot) See <http://www.xmpp.org/registrar/disco-categories.html#client>., the sending application SHOULD NOT specify an 'action' attribute other than "add", the receiving application MAY ignore values of the 'action' attribute other than "add", and the receiving application MUST prompt a human user regarding whether to add the suggested item or items to the user's roster.

        The nature of client proxy gateways (i.e., entities with a service discovery category of "gateway") is specified more fully in &xep0100;. Herein we describe how such gateways should use roster item exchange, and how receiving applications should treat roster items received from such gateways.

        diff --git a/xep-0145.xml b/xep-0145.xml index f79be12d..cb00076d 100644 --- a/xep-0145.xml +++ b/xep-0145.xml @@ -12,7 +12,7 @@ 0145 Active Historical - Standards JIG + Standards Council XMPP Core diff --git a/xep-0146.xml b/xep-0146.xml index 4c9c984e..08cf16e3 100644 --- a/xep-0146.xml +++ b/xep-0146.xml @@ -13,7 +13,7 @@ 0146 Active Informational - Standards JIG + Standards XMPP Core XEP-0050 diff --git a/xep-0147.xml b/xep-0147.xml index 3a72fb5b..87fb3dff 100644 --- a/xep-0147.xml +++ b/xep-0147.xml @@ -12,7 +12,7 @@ 0147 Active Informational - Standards JIG + Standards Council XMPP Core @@ -116,7 +116,7 @@
      8. Initiating a file transfer with another entity (see &xep0096;).

      For each such action, the XMPP Registrar maintains a RECOMMENDED "querytype" (this can be thought of as an action name or "verb"; see RFC 4622 for syntax and semantics) as well as an OPTIONAL list of keys to be used in key-value pairs if appropriate.

      -

      The querytypes and key-value pairs related to RFC 3920 and RFC 3921 are defined herein; the querytypes and key-value pairs related to protocols defined in the JSF's XEP series are defined in the relevant XMPP Extension Protocol specifications.

      +

      The querytypes and key-value pairs related to RFC 3920 and RFC 3921 are defined herein; the querytypes and key-value pairs related to protocols defined in the XMPP Standards Foundation's XEP series are defined in the relevant XMPP Extension Protocol specifications.

      It may desirable for an XMPP IRI/URI to trigger a specialized interface for sending an XMPP message stanza. The RECOMMENDED querytype for this action is "message". If no key-value pair is provided, interacting with an XMPP IRI/URI that contains a querytype of "message" SHOULD trigger an interface that enables the user to input the text of an XMPP message and other relevant parameters (e.g., a message subject or &xep0071; markup).

      0148 Active Humorous - Standards JIG + Standards Council XMPP Core diff --git a/xep-0149.xml b/xep-0149.xml index 6170b156..40b320c6 100644 --- a/xep-0149.xml +++ b/xep-0149.xml @@ -12,7 +12,7 @@ 0149 Active Informational - Standards JIG + Standards Council XMPP Core diff --git a/xep-0150.xml b/xep-0150.xml index 2c2e7753..2ea5d231 100644 --- a/xep-0150.xml +++ b/xep-0150.xml @@ -12,7 +12,7 @@ 0150 Experimental Informational - Standards JIG + Standards Council XMPP Core diff --git a/xep-0151.xml b/xep-0151.xml index e25ea08b..6aaed621 100644 --- a/xep-0151.xml +++ b/xep-0151.xml @@ -12,7 +12,7 @@ 0151 Experimental Standards Track - Standards JIG + Standards XMPP Core XEP-0045 diff --git a/xep-0152.xml b/xep-0152.xml index afef76e4..1a8be9f6 100644 --- a/xep-0152.xml +++ b/xep-0152.xml @@ -12,7 +12,7 @@ 0152 Experimental Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0153.xml b/xep-0153.xml index 27a76b45..10e042c8 100644 --- a/xep-0153.xml +++ b/xep-0153.xml @@ -12,7 +12,7 @@ 0153 Active Historical - Standards JIG + Standards Council XMPP Core diff --git a/xep-0154.xml b/xep-0154.xml index 90eb3361..443f75d8 100644 --- a/xep-0154.xml +++ b/xep-0154.xml @@ -12,7 +12,7 @@ 0154 Experimental Standards Track - Standards JIG + Standards Council XMPP Core @@ -993,7 +993,7 @@

      The Data Forms field that represents a biographical URL is "bio".

      - http://www.jabber.org/people/stpeter.shtml + http://www.xmpp.org/xsf/people/stpeter.shtml http://www.saint-andre.com/me/ ]]> @@ -1231,7 +1231,7 @@ - Jabber Software Foundation + XMPP Standards Foundation ]]> diff --git a/xep-0155.xml b/xep-0155.xml index d7ef443d..7f78f322 100644 --- a/xep-0155.xml +++ b/xep-0155.xml @@ -12,7 +12,7 @@ 0155 Proposed Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0156.xml b/xep-0156.xml index a1390f42..5e49d1c3 100644 --- a/xep-0156.xml +++ b/xep-0156.xml @@ -12,7 +12,7 @@ 0156 Deferred Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0157.xml b/xep-0157.xml index a86bcd2f..1c4ee366 100644 --- a/xep-0157.xml +++ b/xep-0157.xml @@ -12,7 +12,7 @@ 0157 Proposed Informational - Standards JIG + Standards Council XMPP Core diff --git a/xep-0158.xml b/xep-0158.xml index b9d82c99..bdb4dd37 100644 --- a/xep-0158.xml +++ b/xep-0158.xml @@ -12,7 +12,7 @@ 0158 Experimental Standards Track - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0159.xml b/xep-0159.xml index ec1b9f04..8cb5e4ab 100644 --- a/xep-0159.xml +++ b/xep-0159.xml @@ -12,7 +12,7 @@ 0159 Experimental Standards Track - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0160.xml b/xep-0160.xml index 8be5090d..db8f7cc3 100644 --- a/xep-0160.xml +++ b/xep-0160.xml @@ -12,7 +12,7 @@ 0160 Active Informational - Standards JIG + Standards Council XMPP Core diff --git a/xep-0161.xml b/xep-0161.xml index d109db86..55080c1c 100644 --- a/xep-0161.xml +++ b/xep-0161.xml @@ -12,7 +12,7 @@ 0161 Experimental Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0162.xml b/xep-0162.xml index 4df0cc06..c295655b 100644 --- a/xep-0162.xml +++ b/xep-0162.xml @@ -15,7 +15,7 @@ None None None - Standards JIG + Standards Lucas Nussbaum @@ -45,7 +45,7 @@ 0.0.2 2005-10-07 lnu - Integrated some feedback for standards-jig. + Integrated some feedback from Standards list discussion. 0.0.1 diff --git a/xep-0163.xml b/xep-0163.xml index 54059d5a..2e15121b 100644 --- a/xep-0163.xml +++ b/xep-0163.xml @@ -12,7 +12,7 @@ 0163 Draft Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0164.xml b/xep-0164.xml index 21172916..88cbbd8a 100644 --- a/xep-0164.xml +++ b/xep-0164.xml @@ -12,7 +12,7 @@ 0164 Deferred Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0165.xml b/xep-0165.xml index f4256674..c94de758 100644 --- a/xep-0165.xml +++ b/xep-0165.xml @@ -12,7 +12,7 @@ 0165 Experimental Informational - Standards JIG + Standards Council XMPP Core diff --git a/xep-0166.xml b/xep-0166.xml index 656392ce..9449efbd 100644 --- a/xep-0166.xml +++ b/xep-0166.xml @@ -12,7 +12,7 @@ 0166 Experimental Standards Track - Standards JIG + Standards Council XMPP Core @@ -168,7 +168,7 @@
    2. Define a full-featured protocol for XMPP signalling.

    Implementation experience indicates that a dual-stack approach may not be feasible on all the computing platforms for which Jabber clients have been written, or even desirable on platforms where it is feasible. Therefore, it seems reasonable to define an XMPP signalling protocol that can provide the necessary signalling semantics while also making it relatively straightforward to interoperate with existing Internet standards.

    -

    As a result of feedback received on XEP-0111, the original authors of this document (Joe Hildebrand and Peter Saint-Andre) began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team, Google Talk is a messaging and voice chat service and client provided by Google; see <http://www.google.com/talk/>. it was discovered that the emerging Jingle approach was conceptually (and even syntactically) quite similar to the signalling protocol used in the Google Talk application. Therefore, in the interest of interoperability and adoption, we decided to harmonize the two approaches. The signalling protocol specified herein is, therefore, substantially equivalent to the existing Google Talk protocol, with several adjustments based on feedback received from implementors as well as for publication within the Jabber Software Foundation's standards process.

    +

    As a result of feedback received on XEP-0111, the original authors of this document (Joe Hildebrand and Peter Saint-Andre) began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team, Google Talk is a messaging and voice chat service and client provided by Google; see <http://www.google.com/talk/>. it was discovered that the emerging Jingle approach was conceptually (and even syntactically) quite similar to the signalling protocol used in the Google Talk application. Therefore, in the interest of interoperability and adoption, we decided to harmonize the two approaches. The signalling protocol specified herein is, therefore, substantially equivalent to the existing Google Talk protocol, with several adjustments based on feedback received from implementors as well as for publication within the XMPP Standards Foundation's standards process.

    The purpose of Jingle is not to supplant or replace SIP. Because dual-stack XMPP+SIP clients are difficult to build, given that they essentially have two centers of program control, For example, one large ISP recently decided to switch to a pure XMPP approach after having implemented and deployed a dual-stack client for several years. we have designed Jingle as a pure XMPP signalling protocol. However, Jingle is intended to interwork with SIP so that the millions of deployed XMPP clients can be added onto the existing open VoIP networks, rather than limiting XMPP users to a separate and distinct VoIP network.

     @@ -893,6 +893,6 @@ PENDING o---------------------+ |     -

    The authors would like to thank Rohan Mahy for his valuable input on early versions of this document. Rob Taylor, Dafydd Harries, Jussi Laako, Saku Vainio, Antti Ijäs, Brian West, Anthony Minessale, Matt O'Gorman, and others have also provided helpful input. Thanks also to those who have commented on the &SJIG; and (earlier) Jingle Before this specification was accepted as a XMPP Extension Protocol specification, it was discussed on the semi-private <jingle@jabber.org> mailing list; although that list is no longer used (the Standards-JIG list is the preferred discussion venue), for historical purposes it is publicly archived at <http://mail.jabber.org/pipermail/jingle/>. mailing lists.

    +

    The authors would like to thank Rohan Mahy for his valuable input on early versions of this document. Rob Taylor, Dafydd Harries, Jussi Laako, Saku Vainio, Antti Ijäs, Brian West, Anthony Minessale, Matt O'Gorman, and others have also provided helpful input. Thanks also to those who have commented on the &SSIG; and (earlier) Jingle Before this specification was accepted as a XMPP Extension Protocol specification, it was discussed on the semi-private <jingle@jabber.org> mailing list; although that list is no longer used (the Standards list is the preferred discussion venue), for historical purposes it is publicly archived at <http://mail.jabber.org/pipermail/jingle/>. mailing lists.

     diff --git a/xep-0167.xml b/xep-0167.xml index 3d5c2530..95f65a4e 100644 --- a/xep-0167.xml +++ b/xep-0167.xml @@ -12,7 +12,7 @@ 0167 Experimental Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0168.xml b/xep-0168.xml index 95275893..41e7e8a4 100644 --- a/xep-0168.xml +++ b/xep-0168.xml @@ -12,7 +12,7 @@ 0168 Experimental Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0169.xml b/xep-0169.xml index bd9138b2..690443b5 100644 --- a/xep-0169.xml +++ b/xep-0169.xml @@ -12,7 +12,7 @@ 0169 Active Humorous - Standards JIG + Standards Council XMPP IM diff --git a/xep-0170.xml b/xep-0170.xml index ec7d211d..89045faa 100644 --- a/xep-0170.xml +++ b/xep-0170.xml @@ -12,7 +12,7 @@ 0170 Active Informational - Standards JIG + Standards Council XMPP Core diff --git a/xep-0171.xml b/xep-0171.xml index 20b4e9a4..29ced342 100644 --- a/xep-0171.xml +++ b/xep-0171.xml @@ -12,7 +12,7 @@ 0171 Deferred Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0172.xml b/xep-0172.xml index 8ab25f65..b03bb252 100644 --- a/xep-0172.xml +++ b/xep-0172.xml @@ -12,7 +12,7 @@ 0172 Draft Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0173.xml b/xep-0173.xml index ba810d7d..54793a87 100644 --- a/xep-0173.xml +++ b/xep-0173.xml @@ -12,7 +12,7 @@ 0173 Deferred Historical - Standards JIG + Standards Council XMPP Core diff --git a/xep-0174.xml b/xep-0174.xml index 33154f9c..1aa02fb4 100644 --- a/xep-0174.xml +++ b/xep-0174.xml @@ -12,7 +12,7 @@ 0174 Experimental Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0175.xml b/xep-0175.xml index 17ed6a47..0612e6cd 100644 --- a/xep-0175.xml +++ b/xep-0175.xml @@ -12,7 +12,7 @@ 0175 Active Informational - Standards JIG + Standards Council XMPP Core diff --git a/xep-0176.xml b/xep-0176.xml index fe74d282..5d77cbe7 100644 --- a/xep-0176.xml +++ b/xep-0176.xml @@ -13,7 +13,7 @@ 0176 Experimental Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0177.xml b/xep-0177.xml index 77002430..bf2f111d 100644 --- a/xep-0177.xml +++ b/xep-0177.xml @@ -12,7 +12,7 @@ 0177 Experimental Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0178.xml b/xep-0178.xml index aa96945e..361b06eb 100644 --- a/xep-0178.xml +++ b/xep-0178.xml @@ -12,7 +12,7 @@ 0178 Experimental Informational - Standards JIG + Standards Council XMPP Core diff --git a/xep-0179.xml b/xep-0179.xml index 147a9683..cd3537ad 100644 --- a/xep-0179.xml +++ b/xep-0179.xml @@ -11,7 +11,7 @@ 0179 Deferred Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0180.xml b/xep-0180.xml index 58911137..aff27a7b 100644 --- a/xep-0180.xml +++ b/xep-0180.xml @@ -12,7 +12,7 @@ 0180 Experimental Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0181.xml b/xep-0181.xml index c5f91bc3..f2d5e9d5 100644 --- a/xep-0181.xml +++ b/xep-0181.xml @@ -12,7 +12,7 @@ 0181 Experimental Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0182.xml b/xep-0182.xml index fbcfd119..43830305 100644 --- a/xep-0182.xml +++ b/xep-0182.xml @@ -12,7 +12,7 @@ 0182 Active Procedural - Standards JIG + Standards Council XMPP Core @@ -65,7 +65,7 @@

    The XMPP Registrar maintains a registry of application-specific error conditions (see &APPERRORS;).

    -

    All application-specific error conditions that are defined in XMPP Extension Protocol specifications MUST be included in this registry. Application-specific error conditions that are defined outside of the Jabber Software Foundation's standards process (see &xep0001;) MAY be included in this registry, but it is not required for them to be so registered.

    +

    All application-specific error conditions that are defined in XMPP Extension Protocol specifications MUST be included in this registry. Application-specific error conditions that are defined outside of the XMPP Standards Foundation's standards process (see &xep0001;) MAY be included in this registry, but it is not required for them to be so registered.

    ®PROCESS; 0183 Active Humorous - Standards JIG + Standards Council XMPP Core diff --git a/xep-0184.xml b/xep-0184.xml index 991712f8..87ac0a81 100644 --- a/xep-0184.xml +++ b/xep-0184.xml @@ -10,9 +10,9 @@ This document specifies an XMPP protocol extension for message receipts. &LEGALNOTICE; 0184 - Proposed + Experimenal Standards Track - Standards JIG + Standards Council XMPP Core @@ -230,7 +230,7 @@ controlled by the intended recipient has received and processed the message, including presentation to a human user if appropriate. - XEP-xxxx + XEP-0184 ]]>     diff --git a/xep-0185.xml b/xep-0185.xml index 85dd0cda..25fe1efe 100644 --- a/xep-0185.xml +++ b/xep-0185.xml @@ -12,7 +12,7 @@ 0185 Proposed Informational - Standards JIG + Standards Council XMPP Core diff --git a/xep-0186.xml b/xep-0186.xml index cc0112b8..60a06845 100644 --- a/xep-0186.xml +++ b/xep-0186.xml @@ -12,7 +12,7 @@ 0186 Experimental Standards Track - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0187.xml b/xep-0187.xml index e27b0ca8..d73970e5 100644 --- a/xep-0187.xml +++ b/xep-0187.xml @@ -49,7 +49,7 @@ 0187 Experimental Standards Track - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0188.xml b/xep-0188.xml index 3cf61b5d..d1fafe38 100644 --- a/xep-0188.xml +++ b/xep-0188.xml @@ -62,7 +62,7 @@ 0188 Experimental Informational - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0189.xml b/xep-0189.xml index 923667d6..99a715e6 100644 --- a/xep-0189.xml +++ b/xep-0189.xml @@ -12,7 +12,7 @@ 0189 Experimental Standards Track - Standards JIG + Standards XMPP Core XEP-0060 diff --git a/xep-0190.xml b/xep-0190.xml index 8fab4ee4..898f3540 100644 --- a/xep-0190.xml +++ b/xep-0190.xml @@ -12,7 +12,7 @@ 0190 Active Informational - Standards JIG + Standards XMPP Core diff --git a/xep-0191.xml b/xep-0191.xml index 5da87c92..a3e64cf8 100644 --- a/xep-0191.xml +++ b/xep-0191.xml @@ -12,7 +12,7 @@ 0191 Draft Standards Track - Standards JIG + Standards XMPP Core XMPP IM @@ -22,6 +22,12 @@ None blocking &stpeter; + + 1.1pre1 + in progress, last updated 2007-01-05 + psa +

    Further clarified relationship to privacy lists.

     +     1.0 2006-11-21 @@ -83,8 +89,16 @@
-

The simple communications blocking protocol specified herein is intended to be a user-friendly "front end" to a subset of the functionality defined by the privacy lists protocol (XEP-0016). If a service deploys both privacy lists and simple communications blocking, both protocols MUST use the same back-end data store.

-

Wherever possible, this document attempts to define a protocol that is fully consistent with XEP-0016. If a particular aspect of functionality is not specified herein, the relevant text in XEP-0016 shall be taken to apply.

+

The simple communications blocking protocol specified herein is intended to be a user-friendly "front end" to a subset of the functionality defined by the privacy lists protocol (XEP-0016). If a service deploys both privacy lists and simple communications blocking, the service MUST use the same back-end data store for both protocols. (Note: Wherever possible, this document attempts to define a protocol that is fully consistent with XEP-0016; if a particular aspect of functionality is not specified herein, the relevant text in XEP-0016 shall be taken to apply.)

+

A service SHOULD map the blocklist to the default privacy list, where each blocked JID is represented as a privacy list item of type "jid" and action "deny". If this is done and none of the user's clients ever use the privacy lists protocol, then the blocklist will always apply. This mapping has the following implications:

+
    +

  1. If all of a user's clients always use simple communications blocking, then the default privacy list will be equivalent to the blocklist and the default privacy list will be a kind of "virtual list" (in the sense that it is never modified directly by any of the clients).

    2. +

  2. If one of a user's clients uses privacy lists instead of blocklists and modifies the default privacy list by removing a blocked JID or blocking a new JID, then that change will be reflected in the blocklist.

    3. +

  3. If one of a user's clients uses privacy lists and does anything but block or unblock a JID, then that change will not be reflected in the blocklist (since blocklists cannot represent anything except blocked JIDs).

    4. +

  4. If one of a user's clients removes the default privacy list and substitutes a new list for the old list, the blocked JIDs in the new default privacy list (if any) will become the new blocklist.

    5. +

  5. If one of a user's clients makes active something other than the default privacy list, the user may receive communications from contacts who are blocked in the default list.

    6. +
+

Because of the potential for confusion between block lists and privacy lists, it is NOT RECOMMENDED for a client to request both the block list and privacy lists in the same session.

Matching of JIDs as specified in the 'jid' attribute of the <item/> element SHOULD proceed in the following order (this is consistent with XEP-0016):

diff --git a/xep-0192.xml b/xep-0192.xml index 1e6e697d..2923d861 100644 --- a/xep-0192.xml +++ b/xep-0192.xml @@ -12,7 +12,7 @@ 0192 Proposed Standards Track - Standards JIG + Standards XMPP Core @@ -49,7 +49,7 @@

Those shortcomings are addressed in this document, and the recommendations described herein have been incorporated into rfc3920bis.

 -

The XMPP stream feature for Transport Layer Security (TLS) includes a <required/> child element that can be used to indicate that negotiation of TLS must be completed before proceeding with the rest of the stream negotiation. However, as defined in RFC 3920 the remaining stream features do not include the ability to flag that negotiation of the feature is required in order to (1) proceed with the negotiation or (2) begin sending XML stanzas. Because the non-TLS features lack a required flag, it is not possible for the initiating entity to know definitively how to proceed at any given stage in the stream negotiation, and the only way for the initiating entity to know whether it may begin sending XML stanzas is to attempt to send them (the receiving entity will return a ¬authorized; stream error if not all required features have been negotiated). This state of affairs is suboptimal. Therefore, we recommend that every stream feature must include the ability to flag the feature as required or not required.

+

The XMPP stream feature for Transport Layer Security (TLS) includes a <required/> child element that can be used to indicate that negotiation of TLS must be completed before proceeding with the rest of the stream negotiation. However, as defined in RFC 3920 the remaining stream features do not include the ability to flag that negotiation of the feature is required in order to (1) proceed with the negotiation or (2) begin sending XML stanzas. Because the non-TLS features lack a required flag, it is not possible for the initiating entity to know definitively how to proceed at any given stage in the stream negotiation, and the only way for the initiating entity to know whether it may begin sending XML stanzas is to attempt to send them (the receiving entity will return a ¬authorized; stream error if not all required features have been negotiated). This state of affairs is suboptimal. Therefore, every stream feature must include the ability to flag the feature as required or not required. When the initiating entity receives a stream features element with no features containing a <required/> element, it knows thatt the receiving party will accept XML stanzas over the stream.

The following examples show a possible flow of stream negotiation between a client and a server, using the required flag for all but one of the features and following the order specified in &xep0170;. (This example is more verbose than a typical stream negotiation flow, but is provided here for the sake of completeness.)

0193 Proposed Standards Track - Standards JIG + Standards XMPP Core diff --git a/xep-0194.xml b/xep-0194.xml index 7028aba7..13cdc5db 100644 --- a/xep-0194.xml +++ b/xep-0194.xml @@ -12,7 +12,7 @@ 0194 Experimental Standards Track - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0195.xml b/xep-0195.xml index 8f8be92f..8bc14f6d 100644 --- a/xep-0195.xml +++ b/xep-0195.xml @@ -12,7 +12,7 @@ 0195 Experimental Standards Track - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0196.xml b/xep-0196.xml index 5d938e3e..a5d217ba 100644 --- a/xep-0196.xml +++ b/xep-0196.xml @@ -12,7 +12,7 @@ 0196 Experimental Standards Track - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0197.xml b/xep-0197.xml index 3482e475..5fb717a6 100644 --- a/xep-0197.xml +++ b/xep-0197.xml @@ -12,7 +12,7 @@ 0197 Experimental Standards Track - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0198.xml b/xep-0198.xml index b22683dd..dcf72cb1 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -12,7 +12,7 @@ 0198 Experimental Standards Track - Standards JIG + Standards XMPP Core None None diff --git a/xep-0199.xml b/xep-0199.xml index 47bd553a..c1c795f0 100644 --- a/xep-0199.xml +++ b/xep-0199.xml @@ -12,7 +12,7 @@ 0199 Experimental Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0200.xml b/xep-0200.xml index 4234f1fb..39fa5b29 100644 --- a/xep-0200.xml +++ b/xep-0200.xml @@ -26,7 +26,7 @@ 0200 Experimental Standards Track - Standards JIG + Standards XMPP Core XMPP IM diff --git a/xep-0201.xml b/xep-0201.xml index 4d7b4e98..a8db4bec 100644 --- a/xep-0201.xml +++ b/xep-0201.xml @@ -12,7 +12,7 @@ 0201 Experimental Informational - Standards JIG + Standards Council XMPP Core diff --git a/xep-0202.xml b/xep-0202.xml index 5c18feb3..9ebe77cd 100644 --- a/xep-0202.xml +++ b/xep-0202.xml @@ -12,7 +12,7 @@ 0202 Experimental Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-0203.xml b/xep-0203.xml index 9fa47dcf..0ac36048 100644 --- a/xep-0203.xml +++ b/xep-0203.xml @@ -12,7 +12,7 @@ 0203 Experimental Standards Track - Standards JIG + Standards Council XMPP Core diff --git a/xep-README.xml b/xep-README.xml index 8bd2e3c0..68914b6d 100644 --- a/xep-README.xml +++ b/xep-README.xml @@ -12,7 +12,7 @@ README Experimental Procedural - N/A + N/A N/A XEP-0001 @@ -56,7 +56,7 @@ -

Since the inception of the &JSF;, the &EDITOR; has been Peter Saint-Andre. However, if he gets hit by a bus or is replaced by someone else, this document may prove useful.

+

Since the inception of the &XSF;, the &EDITOR; has been Peter Saint-Andre. However, if he gets hit by a bus or is replaced by someone else, this document may prove useful.

The XMPP Extensions Editor manages the XMPP extensions process as defined in &xep0001;. In addition, the XMPP Extensions Editor functions as the XMPP Registrar as defined in &xep0053;. Read those documents first, since this README focuses on mechanics rather than philosophy.

 @@ -84,7 +84,7 @@
  • Convert XML to HTML and check the results for accuracy.
  • Place HTML at http://www.xmpp.org/extensions/inbox/ (/var/www/xmpp.org/extensions/inbox/)
  • Place XML in the editor's working CVS directory on webserver (e.g., ~/cvs/xmpp/extensions/inbox/docname.xml)
    • -
  • Send a note to the Standards-JIG list by running the "protoxep.py" script.
    • +
  • Send a note to the Standards list by running the "protoxep.py" script.
  • Wait until the Council decides whether to accept the proposal as a XEP (this may involve poking the Council Chair).
  • If rejected, retain in the "inbox".
  • @@ -99,7 +99,7 @@
  • Add a reference for the new XEP in the xep.ent file.
  • Update CVS on the server.
  • Run the "gen.sh" script.
    • -
  • Run the "announce.py" script (see below), which updates the database and sends a message to the Standards-JIG list.
    • +
  • Run the "announce.py" script (see below), which updates the database and sends a message to the Standards list.
  • Redirect the "inbox" file to the new XEP URL.
    • @@ -150,7 +150,7 @@
  • Change the <status/> element to "Proposed" in the XML file.
  • Check your changes into CVS.
  • Update CVS on the server.
    • -
  • Run the "lastcall.py" script, which updates the database and sends a message to the Standards-JIG list.
    • +
  • Run the "lastcall.py" script, which updates the database and sends a message to the Standards list.
  • Review the XMPP Registrar Considerations section to ensure accuracy.
    • diff --git a/xep-template.xml b/xep-template.xml index fc21c6a4..794d5abb 100644 --- a/xep-template.xml +++ b/xep-template.xml @@ -8,11 +8,11 @@
    XEP Template An example of the format for XMPP Extension Protocols. - This XMPP Extension Protocol is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy (<http://www.xmpp.org/extensions/ipr-policy.shtml>). This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>). + This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy (<http://www.xmpp.org/extensions/ipr-policy.shtml>). This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>). xxxx ProtoXEP Standards Track - Standards JIG + Standards Council XMPP Core