From de16d335547466b7b91e26f6c364d3b4b354cbb6 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 4 Oct 2006 17:23:05 +0000 Subject: [PATCH] JEP to XEP git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@47 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0150.xml | 32 ++++++++-------- xep-0151.xml | 24 ++++++------ xep-0152.xml | 34 ++++++++--------- xep-0153.xml | 28 +++++++------- xep-0154.xml | 102 +++++++++++++++++++++++++-------------------------- xep-0155.xml | 44 +++++++++++----------- xep-0156.xml | 24 ++++++------ xep-0157.xml | 22 +++++------ xep-0158.xml | 40 ++++++++++---------- xep-0159.xml | 26 ++++++------- 10 files changed, 188 insertions(+), 188 deletions(-) diff --git a/xep-0150.xml b/xep-0150.xml index a9581fc6..2c2e7753 100644 --- a/xep-0150.xml +++ b/xep-0150.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
Use of Entity Tags in XMPP Extensions This document defines best practices for the use of Entity Tags in XMPP extensions. @@ -17,7 +17,7 @@ XMPP Core RFC 2616 - JEP-0131 + XEP-0131 @@ -34,7 +34,7 @@ 0.1 2005-06-02 psa -

Initial JEP version.

 +

Initial version.

 0.0.1 @@ -45,10 +45,10 @@

When a Jabber instant messaging client connects to its server, it typically retrieves a great deal of information, such as a user's roster, privacy lists, and service discovery information. However, this information may not have changed since the client last retrieved the data. In order to improve client start-up time or conserve bandwidth in certain environments, it would be desirable if the client could cache the information and retrieve it only if it has changed.

-

Such a mechanism exists as part of &rfc2616; in the form of the Entity Tags, which are included in the ETag and If-None-Match headers used for HTTP caching. Since &jep0131; enables an XMPP entity to communicate any HTTP header, it should be possible to re-use existing Entity Tag semantics for caching information sent over an XMPP network. This JEP defines best practices for such functionality, which could be used between any two XMPP entities that support SHIM headers (though it is envisioned to be most useful for clients that retrieve information from servers and services).

+

Such a mechanism exists as part of &rfc2616; in the form of the Entity Tags, which are included in the ETag and If-None-Match headers used for HTTP caching. Since &xep0131; enables an XMPP entity to communicate any HTTP header, it should be possible to re-use existing Entity Tag semantics for caching information sent over an XMPP network. This document defines best practices for such functionality, which could be used between any two XMPP entities that support SHIM headers (though it is envisioned to be most useful for clients that retrieve information from servers and services).

 -

This JEP addresses the following requirements:

+

This document addresses the following requirements:

  1. Enable caching of information sent over an XMPP network (i.e., retrieval of information only if it has changed since it was last retrieved).
  2. Re-use existing HTTP Entity Tag semantics.
    3. @@ -56,7 +56,7 @@

    In HTTP, an "entity" is the information transferred as the payload of a request or response, and an "Entity Tag" is an opaque string that uniquely identifies that payload. For example, when an HTTP server sends an entity in an HTTP response, it can include an ETag header that identifies the payload as cacheable, and the client can cache that entity; in future requests, the client can include the same value in an If-None-Match header and the server will either return an HTTP 304 ("Not Modified") error if the entity has not changed or return the entity in the HTTP response if it has changed. (Note: For information about the semantics of Entity Tags, the ETag header, and the If-None-Match header, refer to Sections 3.11, 14.19, and 14.26 respectively of RFC 2616.)

    -

    Similarly, the basic concept behind XMPP Entity Tag use is semantically equivalent to the use in HTTP; this is made possible by a straightforward application of SHIM headers as specified in JEP-0131. In the context of an IQ request-response interaction, the responding entity will include an ETag SHIM header in its IQ response (indicating that the data can be cached), the requesting entity will include that identical value in an If-None-Match SHIM header when it queries the server for the same entity, and the responding entity will return either an IQ result with the changed entity or an IQ error indicating that the entity has not changed.

    +

    Similarly, the basic concept behind XMPP Entity Tag use is semantically equivalent to the use in HTTP; this is made possible by a straightforward application of SHIM headers as specified in XEP-0131. In the context of an IQ request-response interaction, the responding entity will include an ETag SHIM header in its IQ response (indicating that the data can be cached), the requesting entity will include that identical value in an If-None-Match SHIM header when it queries the server for the same entity, and the responding entity will return either an IQ result with the changed entity or an IQ error indicating that the entity has not changed.

    Here is an example of such a request-response flow (the example is that of roster retrieval):

    ]]> -

    Note: The <not-modified/> error is not specified as a stanza error in &rfc3920; and an error code of 304 was not included in the older Jabber error codes (see &jep0086;). The authors of this proposal will request that the <not-modified/> error condition be added to the successor to RFC 3920 during the process of revising the XMPP specifications within the Internet Standards Process.

    +

    Note: The <not-modified/> error is not specified as a stanza error in &rfc3920; and an error code of 304 was not included in the older Jabber error codes (see &xep0086;). The authors of this proposal will request that the <not-modified/> error condition be added to the successor to RFC 3920 during the process of revising the XMPP specifications within the Internet Standards Process.

    Note: In HTTP, an Entity Tag may be either "strong" or "weak" (see Section 13.3.3 of RFC 2616); Entity Tags as used in XMPP extensions MUST be considered strong rather than weak.

    -

    Note: The ETag and If-None-Match headers SHOULD be used only in &IQ; stanzas, although they MAY be used in &MESSAGE; stanza interactions if IQ request-response semantics are not appropriate, for example in &jep0072; and in certain applications that use &jep0004;.

    +

    Note: The ETag and If-None-Match headers SHOULD be used only in &IQ; stanzas, although they MAY be used in &MESSAGE; stanza interactions if IQ request-response semantics are not appropriate, for example in &xep0072; and in certain applications that use &xep0004;.

     -

    JEP-0131 specifies how support for a particular SHIM header can be determined using &jep0030;. To review, the protocol flow between a client and a server would be as follows:

    +

    XEP-0131 specifies how support for a particular SHIM header can be determined using &xep0030;. To review, the protocol flow between a client and a server would be as follows:

    The client now knows that the server supports the ETag and If-None-Match SHIM headers and can proceed accordingly.

    Note: If an XMPP entity supports Entity Tags, it MUST at a minimum support both the ETag and If-None-Match SHIM headers.

    -

    Note: Even if an entity supports the ETag and If-None-Match SHIM headers, it is not required to support Entity Tag functionality for all namespaces. For example, a server could support Entity Tags only for rosters and privacy lists but not for the 'jabber:iq:last' or 'jabber:iq:version' namespaces. Similarly, a &jep0045; service could support Entity Tags only for room lists (retrieved via a "disco#items" request) but not for other requests. As noted, if an entity does not support Entity Tags for a given namespace or request, it SHOULD proceed as if the ETag or If-None-Match SHIM header had not been included in the request.

    +

    Note: Even if an entity supports the ETag and If-None-Match SHIM headers, it is not required to support Entity Tag functionality for all namespaces. For example, a server could support Entity Tags only for rosters and privacy lists but not for the 'jabber:iq:last' or 'jabber:iq:version' namespaces. Similarly, a &xep0045; service could support Entity Tags only for room lists (retrieved via a "disco#items" request) but not for other requests. As noted, if an entity does not support Entity Tags for a given namespace or request, it SHOULD proceed as if the ETag or If-None-Match SHIM header had not been included in the request.

    Optionally, an entity MAY communicate the namespaces for which it supports Entity Tag functionality by listing those namespaces in its response to a "disco#info" request sent to a node of "http://jabber.org/protocol/shim#ETag":

    This proposal requires no interaction with &IANA;.

     - +

    This proposal requires no interaction with the ®ISTRAR;.

     -

    This JEP describes best practices for use of JEP-0131 and therefore does not require a dedicated schema.

    +

    This document describes best practices for use of XEP-0131 and therefore does not require a dedicated schema.

    Is the ETag tied to a bare JID or full JID?

     - + diff --git a/xep-0151.xml b/xep-0151.xml index 52d20521..e25ea08b 100644 --- a/xep-0151.xml +++ b/xep-0151.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
    Virtual Presence - This JEP proposes extensions to the Jabber groupchat protocol for virtual presence on Web pages. + This document proposes extensions to the Jabber groupchat protocol for virtual presence on Web pages. &LEGALNOTICE; 0151 Experimental @@ -15,7 +15,7 @@ Standards JIG XMPP Core - JEP-0045 + XEP-0045 None None @@ -38,7 +38,7 @@ 0.1 2005-06-02 psa -

    Initial JEP version.

     +

    Initial version.

     0.0.8 @@ -124,7 +124,7 @@

    The traffic goals can be met by using only the initial &PRESENCE; stanza, which carries all required information, so that no peer-to-peer messages are required on entering. VP clients which gather additional information about peers (e.g. avatar images) should cache the data so that it can be re-used. This is especially important since users browsing virtually connected locations (i.e. linked pages) may meet very often in a short time.

    -

    The virtual presence extensions make use of Jabber group chat. Virtual locations are implemented as public Jabber chat channels. The proposed protocol works with &jep0045; rooms and GroupChat 1.0 compatible services. Its core functionality described here uses only groupchat features.

    +

    The virtual presence extensions make use of Jabber group chat. Virtual locations are implemented as public Jabber chat channels. The proposed protocol works with &xep0045; rooms and GroupChat 1.0 compatible services. Its core functionality described here uses only groupchat features.

    The virtual presence extensions are supposed to be implemented by Jabber IM clients in addition to the IM functions or by pure virtual presence (Jabber VP) clients.

    @@ -201,7 +201,7 @@ ]]> -

    Juliet gets the equivalent. Romeo's VP client shows Juliet's presence by adding a second avatar to the page. They now engage in a vivid conversation. In deviation to the original text Juliet would not ask "Who art thou, Romeo?", because she only knows the nickname and on the other hand she actually knows where Romeo is: he is on the same web page. There is nothing new until now. Everything happened according to GroupChat 1.0 (JEP-0045) without MUC features. Of course, users can join the same room with any client that supports GroupChat, if they know the room's JID.

    +

    Juliet gets the equivalent. Romeo's VP client shows Juliet's presence by adding a second avatar to the page. They now engage in a vivid conversation. In deviation to the original text Juliet would not ask "Who art thou, Romeo?", because she only knows the nickname and on the other hand she actually knows where Romeo is: he is on the same web page. There is nothing new until now. Everything happened according to GroupChat 1.0 (XEP-0045) without MUC features. Of course, users can join the same room with any client that supports GroupChat, if they know the room's JID.

    Extensions come into the play in order to make the virtual presence more attractive and more vivid.

    @@ -790,8 +790,8 @@ http://www.shakespeare.com/_vpi.xml]]>

    The fact that clients may disclose their JID in order to provide access to their avatar server storage and in order to enable caching is a weak point. A different but equally unique ID could be for caching purposes, provided that it is part of the &PRESENCE; stanza. But traffic restrictions on the client connection prevent that additional data is exchanged between peers in a room. The data could be broadcast to the room, but this could end up in many people always broadcasting avatars while entering a room (web page). The chosen solution is to let peers download from public server storage. A better solution might be to let the conference component fetch from the server storage. In this case clients would need only the room-JID of the user, not the real JID.

    - -

    These namespaces need to be reviewed and/or registered with the Jabber Registrar as a result of this JEP. + +

    These namespaces need to be reviewed and/or registered with the XMPP Registrar as a result of this document.

    • firebat:user:jid
    • firebat:avatar:position
      • @@ -825,4 +825,4 @@ http://www.shakespeare.com/_vpi.xml]]> There are definitely more features possible. Suggestions are welcome

      - + diff --git a/xep-0152.xml b/xep-0152.xml index 7bcd7f0b..ab3f5a80 100644 --- a/xep-0152.xml +++ b/xep-0152.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
      Reachability Addresses This document defines an XMPP protocol extension for communicating reachability information related to non-XMPP devices. @@ -33,7 +33,7 @@ 0.1 2005-06-16 psa -

      Initial JEP version.

       +

      Initial version.

       0.0.1 @@ -45,14 +45,14 @@

      Sometimes it is desirable or necessary to switch from instant messaging (IM) to another real-time communications medium, such as a telephone conversation conducted over the traditional public switched telephone network (PSTN) or more recent Voice over Internet Protocol (VoIP) applications. In order to facilitate switching from IM to telephony or some other medium, a user needs to advertise the address(es) at which they can be reached. There are several possible ways to do this:

        -

      • Publish the reachability address(es) in the user's vCard (see &jep0054;); this is convenient, but is not very dynamic (e.g., reachability addresses might change when the user moves to a new conference room in an office building).

        • -

      • Publish the user's reachability status (but not addresses) as a feature bundle within &jep0115; information; this is somewhat dynamic (subscribers can be informed when reachability information is available) but requires every interested subscriber to perform service discovery in order to determine the reachability address(es).

        • -

      • Send the reachability address(es) within a &PRESENCE; stanza; this option is described in the Presence Broadcast section of this JEP and is consistent with Section 5.1.2 of &rfc3921; since reachability is one aspect of a user's availability for communication.

        • -

      • Send reachability address(es) to the appropriate &jep0163; node; this option is described in the PEP Transport section of this JEP but may not be available at all service providers.

        • +

      • Publish the reachability address(es) in the user's vCard (see &xep0054;); this is convenient, but is not very dynamic (e.g., reachability addresses might change when the user moves to a new conference room in an office building).

        • +

      • Publish the user's reachability status (but not addresses) as a feature bundle within &xep0115; information; this is somewhat dynamic (subscribers can be informed when reachability information is available) but requires every interested subscriber to perform service discovery in order to determine the reachability address(es).

        • +

      • Send the reachability address(es) within a &PRESENCE; stanza; this option is described in the Presence Broadcast section of this document and is consistent with Section 5.1.2 of &rfc3921; since reachability is one aspect of a user's availability for communication.

        • +

      • Send reachability address(es) to the appropriate &xep0163; node; this option is described in the PEP Transport section of this document but may not be available at all service providers.

       -

      This JEP addresses the following requirements:

      +

      This document addresses the following requirements:

      • Enable clients to dynamically publish reachability addresses.
      • Minimize network traffic.
        • @@ -80,12 +80,12 @@ ]]> -

        As described below, this JEP specifies two methods of advertising reachability addresses:

        +

        As described below, this document specifies two methods of advertising reachability addresses:

        • Presence broadcast
        • Personal eventing via publish-subscribe (PEP)
        -

        This JEP does not recommend one transport method over the other.

        +

        This document does not recommend one transport method over the other.

        In addition, a contact MAY request a user's reachability addresses using an &IQ; request-response sequence.

        In order to broadcast reachability addresses in presence information, a user's client includes the <reach/> element in the &PRESENCE; stanza it sends to its server:

        @@ -111,7 +111,7 @@ ]]>         -

        In order to publish reachability via the publish-subscribe transport, an entity MUST first create the appropriate node as explained in JEP-0060. Here we assume that the node already exists.

        +

        In order to publish reachability via the publish-subscribe transport, an entity MUST first create the appropriate node as explained in XEP-0060. Here we assume that the node already exists.

         -

        If a client supports the reachability addresses protocol described herein, it SHOULD include a &jep0030; feature of 'http://jabber.org/protocol/reach' in its replies to disco#info requests:

        +

        If a client supports the reachability addresses protocol described herein, it SHOULD include a &xep0030; feature of 'http://jabber.org/protocol/reach' in its replies to disco#info requests:

        @@ -195,12 +195,12 @@

        If included, the <desc/> element SHOULD possess an 'xml:lang' attribute specifying the language of the human-readable descriptive text for a particular address.

         -

        This document introduces no security considerations above and beyond those described in RFC 3920, RFC 3921, and (for the personal eventing transport) JEP-0163.

        +

        This document introduces no security considerations above and beyond those described in RFC 3920, RFC 3921, and (for the personal eventing transport) XEP-0163.

        This document requires no interaction with &IANA;.

         - +

        The ®ISTRAR; shall include 'http://jabber.org/protocol/reach' in its registry of protocol namespaces.

         @@ -237,4 +237,4 @@ ]]>         - + diff --git a/xep-0153.xml b/xep-0153.xml index 84b27d9d..3742a0af 100644 --- a/xep-0153.xml +++ b/xep-0153.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
        vCard-Based Avatars This document provides historical documentation of a vCard-based protocol for exchanging user avatars. @@ -17,13 +17,13 @@ XMPP Core XMPP IM - JEP-0054 + XEP-0054 vcard-avatar - http://jabber.org/protocol/vcard-avatar/vcard-avatar.xsd + http://www.xmpp.org/schemas/vcard-avatar.xsd &stpeter; @@ -70,7 +70,7 @@
        -

        There exist several proposed protocols for communicating user avatar information over Jabber/XMPP (see &jep0008; and &jep0084;). This document describes another such protocol that is in use today on the Jabber/XMPP network. This document is historical and does not purport to propose a standards-track protocol. However, a future protocol may improve on the approach documented herein.

        +

        There exist several proposed protocols for communicating user avatar information over Jabber/XMPP (see &xep0008; and &xep0084;). This document describes another such protocol that is in use today on the Jabber/XMPP network. This document is historical and does not purport to propose a standards-track protocol. However, a future protocol may improve on the approach documented herein.

        The protocol described herein seems to have been designed with the following requirements in mind:

        @@ -83,7 +83,7 @@         -

        Before informing contacts of the user's avatar, the user's client first publishes the avatar data to the user's public vCard using the protocol defined in &jep0054;.

        +

        Before informing contacts of the user's avatar, the user's client first publishes the avatar data to the user's public vCard using the protocol defined in &xep0054;.

        The user's server then broadcasts that presence information to all contacts who are subscribed to the user's presence information.

         -

        When the recipient's client receives the hash of the avatar image, it SHOULD check the hash to determine if it already has a cached copy of that avatar image. If not, it retrieves the sender's full vCard in accordance with the protocol flow describerd in JEP-0054 (note that this request is sent to the user's bare JID, not full JID):

        +

        When the recipient's client receives the hash of the avatar image, it SHOULD check the hash to determine if it already has a cached copy of that avatar image. If not, it retrieves the sender's full vCard in accordance with the protocol flow describerd in XEP-0054 (note that this request is sent to the user's bare JID, not full JID):

        The following rules apply to inclusion of the update child element (<x xmlns='vcard-temp:x:update'/>) in presence broadcasts:

          -

        1. If a client supports the protocol defined herein, it MUST include the update child element in every presence broadcast it sends and SHOULD also include the update child in directed presence stanzas (e.g., directed presence sent when joining &jep0045; rooms).

          2. +

        2. If a client supports the protocol defined herein, it MUST include the update child element in every presence broadcast it sends and SHOULD also include the update child in directed presence stanzas (e.g., directed presence sent when joining &xep0045; rooms).

        3. If a client is not yet ready to advertise an image, it MUST send an empty update child element, i.e.:

          If the image data exceeds the 8 KB restriction, the processing application SHOULD process the data.

          -

          This document introduces no security considerations above and beyond those described in &rfc3920;, &rfc3921;, and &jep0054;.

          +

          This document introduces no security considerations above and beyond those described in &rfc3920;, &rfc3921;, and &xep0054;.

          This document requires no interaction with &IANA;.

           - +

          The ®ISTRAR; includes 'vcard-temp:x:update' in its registry of protocol namespaces (see &NAMESPACES;).

           @@ -263,7 +263,7 @@ The protocol documented by this schema is defined in - JEP-0153: http://www.jabber.org/jeps/jep-0153.html + XEP-0153: http://www.xmpp.org/extensions/xep-0153.html @@ -281,4 +281,4 @@

          The author wishes to thank the helpful developers who have implemented this protocol and provided feedback regarding its documentation.

           - + diff --git a/xep-0154.xml b/xep-0154.xml index efe164b4..4166e25c 100644 --- a/xep-0154.xml +++ b/xep-0154.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
          User Profile This document specifies how to represent and manage profile data about IM users and other XMPP entities using the XMPP Data Forms extension. @@ -16,13 +16,13 @@ Council XMPP Core - JEP-0004 - JEP-0060 - JEP-0068 - JEP-0163 + XEP-0004 + XEP-0060 + XEP-0068 + XEP-0163 - JEP-0054 + XEP-0054 profile @@ -31,7 +31,7 @@ 0.5 2006-08-02 psa -

          Updated to reflect changes to JEP-0163; added some mappings to the eduPerson object class.

           +

          Updated to reflect changes to XEP-0163; added some mappings to the eduPerson object class.

           0.4 @@ -55,7 +55,7 @@ 0.1 2005-06-16 psa -

          Initial JEP version.

           +

          Initial version.

                     0.0.5 @@ -89,27 +89,27 @@
          -

          It is widely acknowledged within the Jabber/XMPP community that the &jep0054; specification (JEP-0054) has outlived its usefulness. There are several reasons for this conclusion:

          +

          It is widely acknowledged within the Jabber/XMPP community that the &xep0054; specification (XEP-0054) has outlived its usefulness. There are several reasons for this conclusion:

            -
          1. JEP-0054 is not fully consistent with the Internet-Draft on which it was based.
            2. +
          2. XEP-0054 is not fully consistent with the Internet-Draft on which it was based.
          3. The Internet-Draft on which it was based was never approved by the IETF.
          4. Because of confusion over aspects of the vcard-temp specification, there exist incompatible implementations.
          5. vCard (&rfc2426;) captures only a limited set of information.
            6. -
          6. vCard (even in its XML representation For links to the experimental XML representation of vCard, see JEP-0054.) is not easily extensible, leading those who develop profiles for specialized communities to "roll their own" protocols, to the detriment of interoperability.
            7. +
          7. vCard (even in its XML representation For links to the experimental XML representation of vCard, see XEP-0054.) is not easily extensible, leading those who develop profiles for specialized communities to "roll their own" protocols, to the detriment of interoperability.
          8. vCard data tends to be monolithic (the basic unit of information is the full vCard, not parts thereof).
            9. -
          9. The publication model for JEP-0054 is to set the full vCard, rather than only the parts that need to be modified.
            10. -
          10. The retrieval model for JEP-0054 is to get the full vCard, rather than only the parts that have been modified.
            11. +
          11. The publication model for XEP-0054 is to set the full vCard, rather than only the parts that need to be modified.
            12. +
          12. The retrieval model for XEP-0054 is to get the full vCard, rather than only the parts that have been modified.

          Given the weaknesses of vCard, there is interest across the broader Internet community in replacing vCard with something more modern and extensible. Unfortunately, no other standards development organization has developed an alternative to vCard. Part of the challenge is that quite detailed ontologies have been developed that might replace parts of the vCard specification (e.g., the Extensible Name and Address Language See <http://xml.coverpages.org/xnal.html>. developed by &OASIS;) while less-formal ontologies are being used to represent other parts of the problem space (e.g., &foaf;). The relevant protocols are in flux and it is unclear when (or even if) stability will emerge.

          -

          Because of the unsettled landspace and the strong desire within the Jabber/XMPP community to move beyond JEP-0054, this JEP specifies methods for the representation of profile data in terms of the &jep0004; protocol (further qualified using the standardization concepts specified in &jep0068;) and for the management of profile data using standard IQ request-response semantics as well as, for more frequently-modified data, &jep0060; semantics (specifically the simplified subset of those semantics specified in &jep0163;). The rationale behind these design decisions is provided below.

          +

          Because of the unsettled landspace and the strong desire within the Jabber/XMPP community to move beyond XEP-0054, this document specifies methods for the representation of profile data in terms of the &xep0004; protocol (further qualified using the standardization concepts specified in &xep0068;) and for the management of profile data using standard IQ request-response semantics as well as, for more frequently-modified data, &xep0060; semantics (specifically the simplified subset of those semantics specified in &xep0163;). The rationale behind these design decisions is provided below.

           -

          This JEP addresses the following requirements for data management:

          +

          This document addresses the following requirements for data management:

          1. Enable an entity to publish profile data about itself.
          2. Enable requesting entities to retrieve profile data about other entities.
          -

          This JEP addresses the following requirements for data representation:

          +

          This document addresses the following requirements for data representation:

          1. Specify how to represent profile data in an XMPP-friendly manner for communication over the wire.
          2. Ensure that the protocol is extensible (e.g., not limited to existing vCard fields). @@ -124,11 +124,11 @@

            1. IQ (request-and-response) semantics.

              -

              In the simplest case, an entity may store its own profile data and provide only the complete profile and only on request, using the request-response semantics of the XMPP &IQ; stanza type. This model is most appropriate for stable entities that are always online and whose profile data does not change frequently, such as servers and server-side components (entities that are not always online or that frequently modify their profile data, such as IM users, may prefer to publish their information to entities that are always online, such as an IM user's server). While it may seem desirable to embed profile data in the responses an entity provides to service discovery information requests using &jep0128;, it is likely that profile data will be quite extensive; therefore, we define a standalone "wrapper" element for profile data, qualified by the 'http://jabber.org/protocol/profile' namespace.

              +

              In the simplest case, an entity may store its own profile data and provide only the complete profile and only on request, using the request-response semantics of the XMPP &IQ; stanza type. This model is most appropriate for stable entities that are always online and whose profile data does not change frequently, such as servers and server-side components (entities that are not always online or that frequently modify their profile data, such as IM users, may prefer to publish their information to entities that are always online, such as an IM user's server). While it may seem desirable to embed profile data in the responses an entity provides to service discovery information requests using &xep0128;, it is likely that profile data will be quite extensive; therefore, we define a standalone "wrapper" element for profile data, qualified by the 'http://jabber.org/protocol/profile' namespace.

            2. Pubsub (publish-and-subscribe) semantics.

              -

              A more complex model is for an entity to publish its profile data to a publish-subscribe node or nodes and allow other entities to subscribe to that node or nodes, thus receiving notifications whenever the profiled entity updates its data. This model is more appropriate for entities that modify their profile data on a regular basis or when other entities wish to be informed when the profile data changes. Because this model will most likely be used most often by IM users and other intermittently-connected network endpoints, we use the simplified subset of the XMPP publish-subscribe extension defined in JEP-0163 to implement this model.

              +

              A more complex model is for an entity to publish its profile data to a publish-subscribe node or nodes and allow other entities to subscribe to that node or nodes, thus receiving notifications whenever the profiled entity updates its data. This model is more appropriate for entities that modify their profile data on a regular basis or when other entities wish to be informed when the profile data changes. Because this model will most likely be used most often by IM users and other intermittently-connected network endpoints, we use the simplified subset of the XMPP publish-subscribe extension defined in XEP-0163 to implement this model.

            @@ -136,7 +136,7 @@

            As with data management, there are several possible approaches to representing profile data for communication over XMPP networks, including the following:

            • -

              Structured data formats, such as &jep0080; and &jep0112;.

              +

              Structured data formats, such as &xep0080; and &xep0112;.

              Such data formats have the advantage of being human-readable. However:

              1. They are not easily extensible: developers of specialized community services would need to write their own structured data formats, even to add one new field.
                2. @@ -148,26 +148,26 @@

                A format represented by means of &w3rdf;.

                An argument could be made that RDF is a reasonable approach for representing profile data for communication over the XMPP network; however, such an argument will not be made in the current proposal. The author has considered RDF and has concluded that there are several reasons why RDF is undesirable as an XMPP wire protocol:

                  -
                1. RDF exists in an XML representation but the semantics of RDF impose a more complex conceptual structure (data triples) than does XML, which is sub-optimal since unnecessary complexity is to be avoided (see &jep0134;).
                  2. +
                2. RDF exists in an XML representation but the semantics of RDF impose a more complex conceptual structure (data triples) than does XML, which is sub-optimal since unnecessary complexity is to be avoided (see &xep0134;).
                3. RDF requires a specialized parser rather than the normal XML parser that comes standard with all XMPP implementations.
                4. As long as it is possible to define a consistent mapping of profile data to RDF representations, it should be straightforward to convert the XMPP data formats into those RDF representations if desired (e.g., to output a FOAF file).
              2. -

                A format represented by means of Data Forms (JEP-0004).

                -

                The Data Forms protocol defined in JEP-0004 has several advantages for use over XMPP:

                +

                A format represented by means of Data Forms (XEP-0004).

                +

                The Data Forms protocol defined in XEP-0004 has several advantages for use over XMPP:

                1. It can be parsed using an off-the-shelf XML parser.
                2. It is already widely deployed in existing Jabber/XMPP clients, servers, and components.
                3. The data forms protocol is easily extensible.
                  4. -
                4. The Jabber/XMPP community possesses consistent methods for profiling and scoping data forms (as specified in JEP-0068).
                  5. +
                5. The Jabber/XMPP community possesses consistent methods for profiling and scoping data forms (as specified in XEP-0068).
                6. Data forms have a generic schema that is easy to map to common data storage mechanisms (usually databases).
                7. Data forms provide a consistent abstraction layer for XMPP applications, thus shielding them from changes in the profile data formats being defined by other Internet projects and standards development organizations.
                8. The use of data forms as the medium of representation for communication over the wire does not prevent applications from storing backend profile data in some other underlying format (e.g., RDF or a database).
            -

            Therefore, this proposal specifies that profile data shall be scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', in accordance with the field standardization methods defined in JEP-0068. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the ®ISTRAR; (although they may or may not be defined in a Jabber Enhancement Proposal). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of JEP-0068. Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.

            +

            Therefore, this proposal specifies that profile data shall be scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', in accordance with the field standardization methods defined in XEP-0068. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the ®ISTRAR; (although they may or may not be defined in a Jabber Enhancement Proposal). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of XEP-0068. Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.

            The following is a simple and incomplete example of profile data represented via the Data Forms protocol, containing two registered data fields and one unregistered field:

            @@ -190,7 +190,7 @@ ]]>

            By specifying that all fields are scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', this proposal does not mean to imply that all profile data will or should be gathered in one data form. In reality, most such data will probably be gathered at the time of registration either at a website or via a "wizard" interface that breaks the process into smaller bundles (such as "Basic Personal Data", "Physical Location", "Internet Addresses", "Hobbies and Interests", and "Favorite Things"). The use of one FORM_TYPE is simply meant to scope the data fields so that each field is unique within the context of profile data. Any form that uses these fields along with a FORM_TYPE of 'http://jabber.org/protocol/profile' is of the "profile type" (i.e., is a specific instance of that type), which does not limit the number of forms that can be of that type.

            However, scoping all data fields with a single FORM_TYPE implies it is necessary to define separate data fields for similar kinds of information. For example, the vCard specification (RFC 2426) defines "types" for certains kinds of data, such as email addresses, telephone numbers, and physical addresses, making it possible to specify that a telephone number corresponds to a fax machine or mobile phone or that a physical address corresponds to one's home or work location. In the Data Forms representation, any desired piece of information (e.g., work phone) must be represented with a separate data field.

            -

            In order to address most (if not all) of the pieces of information described in existing profile specifications, this JEP defines a great number of data fields. Even so, the data fields specified herein are not exhaustive, and it is expected that additional fields will be registered in the future through the mechanisms specified in the Jabber Registrar Considerations section of this JEP.

            +

            In order to address most (if not all) of the pieces of information described in existing profile specifications, this document defines a great number of data fields. Even so, the data fields specified herein are not exhaustive, and it is expected that additional fields will be registered in the future through the mechanisms specified in the XMPP Registrar Considerations section of this document.

            @@ -226,7 +226,7 @@

            Otherwise it MUST return an error. If the server does not support the profile data functionality, the error MUST be &unavailable;.

            -

            In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "http://jabber.org/protocol/profile" at its server using the PEP subset of the publish-subscribe extension, as specified in JEP-0163.

            +

            In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "http://jabber.org/protocol/profile" at its server using the PEP subset of the publish-subscribe extension, as specified in XEP-0163.

            @@ -270,7 +270,7 @@             -

            If an entity can provide profile data directly using the standalone 'http://jabber.org/protocol/profile' namespace, it SHOULD advertise that feature in response to &jep0030; information requests:

            +

            If an entity can provide profile data directly using the standalone 'http://jabber.org/protocol/profile' namespace, it SHOULD advertise that feature in response to &xep0030; information requests:

            ]]> -

            If the server allows the subscription, it MUST return an IQ-result (see JEP-0163 for error scenarios):

            +

            If the server allows the subscription, it MUST return an IQ-result (see XEP-0163 for error scenarios):

             -

            The following subsections specify common fields for defining various aspects of a person, which shall form the initial submission to the Jabber Registrar; many of these fields map to elements specified in vCard, xNAL, FOAF, LDAP (see &rfc2252;, &rfc2256;, and &rfc2798;) This specification does not require that profile data fields mapped to LDAP fields must adhere to the X.500 data types that are re-used by LDAP. However, implementations MAY enforce those data types if desired., and LDAP object classes such as Person, organizationalPerson, inetOrgPerson, and eduPerson.

            +

            The following subsections specify common fields for defining various aspects of a person, which shall form the initial submission to the XMPP Registrar; many of these fields map to elements specified in vCard, xNAL, FOAF, LDAP (see &rfc2252;, &rfc2256;, and &rfc2798;) This specification does not require that profile data fields mapped to LDAP fields must adhere to the X.500 data types that are re-used by LDAP. However, implementations MAY enforce those data types if desired., and LDAP object classes such as Person, organizationalPerson, inetOrgPerson, and eduPerson.

            Mappings are provided to vCard, LDAP, xNAL, and FOAF.

            @@ -586,16 +586,16 @@             -

            Mappings are provided to vCard, xNAL, and JEP-0112 (&jep0112;).

            +

            Mappings are provided to vCard, xNAL, and XEP-0112 (&xep0112;).

            A country is the sovereign nation in which a person is located. Sometimes also called a "nation".

            The Data Forms fields that represent a country are "country", "home_country", and "work_country" for generic addresses, home addresses, and work addresses respectively.

            This field maps to:

              -
            • vCard COUNTRY (or JEP-0054 CTRY), optionally supplemented with the "HOME" or "WORK" type
              • +
            • vCard COUNTRY (or XEP-0054 CTRY), optionally supplemented with the "HOME" or "WORK" type
            • LDAP c
            • xNAL CountryName
              • -
            • JEP-0112 country
              • +
            • XEP-0112 country
            @@ -612,7 +612,7 @@
          3. vCard REGION, optionally supplemented with the "HOME" or "WORK" type
          4. LDAP st
          5. xNAL AdministrativeAreaName
            6. -
          6. JEP-0112 region
            7. +
          7. XEP-0112 region
      @@ -628,7 +628,7 @@
    • vCard LOCALITY, optionally supplemented with the "HOME" or "WORK" type
    • LDAP l
    • xNAL LocalityName
      • -
    • JEP-0112 locality
      • +
    • XEP-0112 locality
    @@ -642,7 +642,7 @@

    This field maps to:

    • xNAL DependentLocalityName
      • -
    • JEP-0112 area
      • +
    • XEP-0112 area
    @@ -658,7 +658,7 @@
  3. vCard STREET, optionally supplemented with the "HOME" or "WORK" type
  4. LDAP street
  5. xNAL ThoroughfareNumber + ThoroughfareName
    6. -
  6. JEP-0112 street
    7. +
  7. XEP-0112 street
    8. @@ -673,7 +673,7 @@
    • vCard EXTADR, optionally supplemented with the "HOME" or "WORK" type
    • xNAL BuildingName
      • -
    • JEP-0112 building
      • +
    • XEP-0112 building
    @@ -688,7 +688,7 @@
    • vCard EXTADR, optionally supplemented with the "HOME" or "WORK" type
    • xNAL SubPremiseNumber
      • -
    • JEP-0112 floor
      • +
    • XEP-0112 floor
    @@ -704,7 +704,7 @@
  8. vCard EXTADR, optionally supplemented with the "HOME" or "WORK" type
  9. LDAP roomNumber
  10. xNAL SubPremiseNumber
    11. -
  11. JEP-0112 room
    12. +
  12. XEP-0112 room
    13. @@ -734,7 +734,7 @@
  13. vCard PCODE, optionally supplemented with the "HOME" or "WORK" type
  14. LDAP postalCode
  15. xNAL PostalCodeNumber
    16. -
  16. JEP-0112 postalcode
    17. +
  17. XEP-0112 postalcode
    18. @@ -760,13 +760,13 @@ -

    Mappings are provided to vCard and JEP-0080 (&jep0080;).

    +

    Mappings are provided to vCard and XEP-0080 (&xep0080;).

    Altitude is a person's height or depth in relationship to sea level, where positive altitude is meters above sea level and negative altitude is meters below sea level.

    The Data Forms field that represents altitude is "alt".

    This field maps to:

      -
    • JEP-0080 alt
      • +
    • XEP-0080 alt
    @@ -780,7 +780,7 @@

    This field maps to:

    • vCard LAT
      • -
    • JEP-0080 lat
      • +
    • XEP-0080 lat
    @@ -794,7 +794,7 @@

    This field maps to:

    • vCard LON
      • -
    • JEP-0080 lon
      • +
    • XEP-0080 lon
    @@ -1920,16 +1920,16 @@ XhK8hFkPvXjudl7xAJ95+2fAHfmHheZJVaO8VaJiL54Tvw==

    Profile data can be personally significant and even security critical. Due care should be taken in determining who shall have access to such information. In particular, an entity SHOULD ensure that its public profile contains only information that it deems safe to be world-readable, SHOULD ensure that any pubsub node it may create for profile data has an access model of "presence" or "roster", and SHOULD NOT publish private or restricted data except to such a pubsub node.

     -

    This JEP requires no interaction with &IANA;.

    +

    This document requires no interaction with &IANA;.

     - +

    To follow.

         - + diff --git a/xep-0155.xml b/xep-0155.xml index 0868c858..c273578b 100644 --- a/xep-0155.xml +++ b/xep-0155.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
    Chat Session Negotiation This document specifies a feature negotiation profile for initiating a one-to-one chat session. @@ -17,8 +17,8 @@ XMPP Core XMPP IM - JEP-0020 - JEP-0068 + XEP-0020 + XEP-0068 @@ -35,7 +35,7 @@ 0.7 2006-07-14 psa -

    Added secure field from JEP-0116.

     +

    Added secure field from XEP-0116.

     0.6 @@ -65,7 +65,7 @@ 0.2 2005-07-15 psa -

    Further described contexts in which chat session negotiation could be useful; added more examples; added reference to SIP RFC and explained basic mapping to SIP INVITE method; added Jabber Registrar considerations.

     +

    Further described contexts in which chat session negotiation could be useful; added more examples; added reference to SIP RFC and explained basic mapping to SIP INVITE method; added XMPP Registrar considerations.

         0.1 @@ -83,12 +83,12 @@

    The traditional model for one-to-one chat "sessions" in Jabber/XMPP is for a user to simply send a message to a contact without any formal negotiation of chat session parameters (e.g., see &xmppim;). This informal approach to initiation of a chat session is perfectly acceptable in many contexts, environments, and cultures. However, it may be desirable to formally request the chat and negotiate its parameters before beginning the chat session in some circumstances, such as:

      -
    • Whenever parameters specific to a chat session must be agreed. e.g., security and privacy parameters (see &jep0116; and &jep0136;).
      • -
    • The parties are unknown to each other, have not exchanged presence, or have not discovered their respective capabilities via &jep0030; or &jep0115;.
      • +
    • Whenever parameters specific to a chat session must be agreed. e.g., security and privacy parameters (see &xep0116; and &xep0136;).
      • +
    • The parties are unknown to each other, have not exchanged presence, or have not discovered their respective capabilities via &xep0030; or &xep0115;.
    • When an XMPP-based system interfaces with a SIP-based system built on top of &rfc3261;. In essence, a chat state negotiation request as specified herein is functionally equivalent to a SIP INVITE request, and acceptance of such a request is functionally equivalent to sending a SIP 200 OK response; see Section 17 of RFC 3261.
    • Within an organization or culture in which one would not simply begin chatting with another person (e.g., a superior) without first receiving permission to do so.
    -

    This proposal defines best practices for such a negotiation, re-using the protocol defined in &jep0020;.

    +

    This proposal defines best practices for such a negotiation, re-using the protocol defined in &xep0020;.

     @@ -140,7 +140,7 @@ ]]> -

    In the foregoing example, Romeo requests a chat with Juliet and also queries her regarding whether she wants to disable all message logging (see &jep0136;) A client MUST NOT set the 'otr' field to 'true' unless it has confirmed that its server will allow it to switch off Automated Archiving (see Message Archiving). and support &jep0071; and &jep0085; extensions during this chat session. (Note: These fields are examples only; a full set of chat session negotiation parameters will be registered as described in the Jabber Registrar Considerations section of this document.)

    +

    In the foregoing example, Romeo requests a chat with Juliet and also queries her regarding whether she wants to disable all message logging (see &xep0136;) A client MUST NOT set the 'otr' field to 'true' unless it has confirmed that its server will allow it to switch off Automated Archiving (see Message Archiving). and support &xep0071; and &xep0085; extensions during this chat session. (Note: These fields are examples only; a full set of chat session negotiation parameters will be registered as described in the XMPP Registrar Considerations section of this document.)

    Juliet's server delivers Romeo's request to her most available resource (which happens to be "balcony").

    In any response to the request, the contact's client MUST mirror the 'id' attribute and &THREAD;value so that the user's client can correctly track the response.

    We assume that Juliet accepts the chat and specifies that she does not want to log messages or use XHTML formatting but that she does want to use Chat State Notifications:

    @@ -486,7 +486,7 @@

    A client MAY require a human user to approve each chat session negotiation request or MAY auto-accept and auto-reject requests based on some user-configurable policy.

    If a party receives XMPP presence of type "unavailable" from the full JID (&FULLJID;) of the other party (i.e., the resource with which it has had an active session) during a chat session, the receiving party MAY assume that the other client will still be unable to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated chat until it reconnects and receives "offline" messages). -However, if the receiving party assumes that the other client will not be able to continue the session, then it MUST explicitly terminate the session (see Terminating a Chat) - since its assumption could be incorrect. If the receiving party later receives presence of type "available" from that same resource or another resource associated with the other party and the receiving party desires to restart the chat session, it MUST initiate a new chat session (including a newly-generated ThreadID) with the other party rather than renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in JEP-0085.)

    +However, if the receiving party assumes that the other client will not be able to continue the session, then it MUST explicitly terminate the session (see Terminating a Chat) - since its assumption could be incorrect. If the receiving party later receives presence of type "available" from that same resource or another resource associated with the other party and the receiving party desires to restart the chat session, it MUST initiate a new chat session (including a newly-generated ThreadID) with the other party rather than renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in XEP-0085.)

    If a contact accepts a user's request or returns an error to the user, the user will effectively discover the contact's presence (at least the presence of one of the contact's resources). Due care must therefore be exercised in determining whether to accept the request or return an error. For examples, the contact's client SHOULD NOT automatically (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribing to the contact's presence (and the contact's presence is not currently "invisible" to the user). Furthermore, the contact's client MUST NOT take either action if the user is in the contact's block list.

    @@ -494,23 +494,23 @@ However, if the receiving party assumes that the other client will not

    This JEP requires no interaction with &IANA;.

     - +

    The ®ISTRAR; shall include 'http://jabber.org/protocol/chatneg' in its registry of Service Discovery features.

    http://jabber.org/protocol/chatneg Support for Chat Session Negotiation and its FORM_TYPE - JEP-0155 + XEP-0155 ]]>     -

    &jep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. The following fields shall be registered for use in Chat Session Negotiation:

    +

    &xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. The following fields shall be registered for use in Chat Session Negotiation:

    http://jabber.org/protocol/chatneg - JEP-0155 + XEP-0155 Forms enabling negotation of a one-to-one chat session between two entities. @@ -522,15 +522,15 @@ However, if the receiving party assumes that the other client will not + label='Whether to enable Chat State Notifications per XEP-0085'/> + label='Whether to enable XHTML-IM formatting per XEP-0071'/> + label='Off-The-Record: whether to disable absolutely all message logging including automatic archiving - see XEP-0136'/> not     -

    This proposal re-uses the format defined in JEP-0020 and therefore does not require a separate schema.

    +

    This proposal re-uses the format defined in XEP-0020 and therefore does not require a separate schema.

    Thanks to Thomas Charron and Jean-Louis Seguineau for their feedback.

     - + diff --git a/xep-0156.xml b/xep-0156.xml index 4821ccd1..ad7a0a16 100644 --- a/xep-0156.xml +++ b/xep-0156.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
    A DNS TXT Resource Record Format for XMPP Connection Methods This document defines a DNS TXT Resource Record format for use in specifying methods of connecting to an XMPP server. @@ -61,7 +61,7 @@
    -

    Although &rfc3920; specifies the use of TCP as the method of connecting to an XMPP server, other connection methods are possible. These include the older &jep0025; method, the more recent &jep0124; method, and less common methods such as &wap;. For some of these methods, it is necessary to discover further parameters before connecting, such as the HTTP URL of an alternative connection manager. Currently, if a client application needs to discover connection methods before connecting to an XMPP service, the relevant information must be provided manually by a human user, which is cumbersome and error-prone. Thankfully, there are several potential ways to complete this pre-connection service discovery in an automated fashion:

    +

    Although &rfc3920; specifies the use of TCP as the method of connecting to an XMPP server, other connection methods are possible. These include the older &xep0025; method, the more recent &xep0124; method, and less common methods such as &wap;. For some of these methods, it is necessary to discover further parameters before connecting, such as the HTTP URL of an alternative connection manager. Currently, if a client application needs to discover connection methods before connecting to an XMPP service, the relevant information must be provided manually by a human user, which is cumbersome and error-prone. Thankfully, there are several potential ways to complete this pre-connection service discovery in an automated fashion:

    1. Specify a &w3wsdl; definition (or other XML file format) and a canonical URL for that definition at a domain that offers XMPP services. Unfortunately, this approach requires access to the HTTP server for the domain (and quite possibly to the root directory thereof), which may be difficult for XMPP server administrators to arrange. In addition, it requires a client to retrieve the relevant file via HTTP before performing DNS lookups and XMPP connection; it would be more efficient to use recognized DNS methods since DNS lookups are already required by RFC 3920.

    2. Specify a way to define the required service discovery information as part of the existing DNS SRV records (see &rfc2782;) for a domain that offers XMPP services. While this approach sounds promising, it is not feasible since the DNS SRV Target field can be used only to specify domain names and cannot be used to specify full URIs (such as the URL for an HTTP connection manager).

      3. @@ -81,7 +81,7 @@
    3. It is RECOMMENDED for the owner to be "_xmppconnect".
    4. The class field SHOULD be IN.
    5. The ttl field is OPTIONAL.
      6. -
    6. The attribute name SHOULD begin with the string "_xmpp-client-" or "_xmpp-server-" and SHOULD be registered as described in the Jabber Registrar Considerations section of this document.
      7. +
    7. The attribute name SHOULD begin with the string "_xmpp-client-" or "_xmpp-server-" and SHOULD be registered as described in the XMPP Registrar Considerations section of this document.
    8. If the txt-data field contains only an attribute name (i.e., no unquoted "=" character followed by additional characters), the receiving application SHOULD interpret it as indicating the presence of the attribute or feature with no defined value.
    9. If the txt-data field contains an unquoted "=" character, it MUST also contain an attribute value.
    @@ -95,7 +95,7 @@
-

The following examples show three DNS TXT resource records: the first indicates support for the httpbind connection method defined in JEP-0124 including the appropriate URL, the second indicates support for the httppoll connection method defined in JEP-0025 including the appropriate URL, and the third indicates support for WAP connections including the appropriate URL.

+

The following examples show three DNS TXT resource records: the first indicates support for the httpbind connection method defined in XEP-0124 including the appropriate URL, the second indicates support for the httppoll connection method defined in XEP-0025 including the appropriate URL, and the third indicates support for WAP connections including the appropriate URL.

This JEP requires no interaction with &IANA;.

 - + -

The Jabber Registrar shall maintain a registry of attributes for use in DNS TXT resource records that advertise XMPP connection methods.

+

The XMPP Registrar shall maintain a registry of attributes for use in DNS TXT resource records that advertise XMPP connection methods.

®PROCESS; _xmpp-client-httpbind the HTTP Binding connection method the http: or https: URL at which to contact the HTTP Binding connection manager or proxy - JEP-0124 + XEP-0124 _xmpp-client-httppoll the HTTP Polling connection method the http: or https: URL at which to contact the HTTP Polling connection manager or proxy - JEP-0025 + XEP-0025 @@ -157,4 +157,4 @@ _xmppconnect IN TXT "_xmpp-client-wap=http://wap.jabber.org/connector.cgi" - + diff --git a/xep-0157.xml b/xep-0157.xml index eb2ae9a9..50c1a915 100644 --- a/xep-0157.xml +++ b/xep-0157.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
Contact Addresses for XMPP Services This document defines a method for specifying contact addresses related to an XMPP service. @@ -43,13 +43,13 @@ 0.1 2005-09-08 psa -

Initial JEP version.

 +

Initial version.

 0.0.2 2005-09-06 psa -

Added security considerations and Jabber Registrar considerations.

 +

Added security considerations and XMPP Registrar considerations.

 0.0.1 @@ -70,7 +70,7 @@ - + diff --git a/xep-0158.xml b/xep-0158.xml index f5b5988b..86c10838 100644 --- a/xep-0158.xml +++ b/xep-0158.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
Robot Challenges This document specifies an XMPP protocol extension that entities may use to discover whether the sender of an XML stanza is a human user or a robot. @@ -16,8 +16,8 @@ XMPP Core XMPP IM - JEP-0004 - JEP-0066 + XEP-0004 + XEP-0066 None None @@ -45,7 +45,7 @@ 0.1 2005-09-14 ip - Initial JEP version. + Initial version. 0.0.1 @@ -59,7 +59,7 @@

The appearance of large public IM services based on &rfc3920; and &rfc3921; makes it desirable to implement protocols that discourage the sending of large quantities of IM SPAM (SPIM) from XMPP clients (connected to legitimate servers) and XMPP servers (with virtual clients) -- all hosted on networks of 'zombie' machines. SPIM is defined here as any type of unsolicited XMPP stanza sent by a 'robot' and delivered to a human, including messages and subscription requests. SPIM has the potential to disrupt people even more than SPAM, because each message interrupts the receiver (humans typically filter SPAM in batch mode).

Several of the most effective techniques developed to combat SPAM require humans to be differentiated from bots using a "Completely Automated Public Turing Test to Tell Computers and Humans Apart" or CAPTCHA (see <http://www.captcha.net/>). These challenge techniques are easily adapted to discourage SPIM. The very occasional inconvenience of responding to a CAPTCHA (for example, when creating an IM account or sending a message to a new correspondent) is small and perfectly acceptable -- especially when compared to the countless robot-generated interruptions people might otherwise have to filter every day.

An alternative technique to CAPTCHAs requires Desktop PC clients to undertake a Hashcash Hashcash <http://hashcash.org/>. challenge. These are completely transparent to PC users. They require clients to perform specified CPU-intensive work, making it difficult to send large amounts of SPIM.

-

The generic challenge protocol described in this document is designed for incorporation into other protocols like &jep0077; and &jep0159;.

+

The generic challenge protocol described in this document is designed for incorporation into other protocols like &xep0077; and &xep0159;.

@@ -72,7 +72,7 @@ -

This protocol requires multimedia to be included within &jep0004;. This section defines a new namespace ('http://jabber.org/protocols/media') for that purpose. The root element for the namespace is <media/>. It MUST be contained within a <field/> element qualified by the 'jabber:x:data' namespace.

+

This protocol requires multimedia to be included within &xep0004;. This section defines a new namespace ('http://jabber.org/protocols/media') for that purpose. The root element for the namespace is <media/>. It MUST be contained within a <field/> element qualified by the 'jabber:x:data' namespace.

If the media is an image or video then the <media/> element SHOULD include 'width' and 'height' attributes specifying the recommended display size of the media in pixels.

The <media/> element SHOULD contain at least one <uri/> element to specify the out-of-band location of the media data. Constrained execution environments prevent some clients rendering media unless it has been received out-of-band (e.g., Web clients). The <uri/> element MUST contain a URI that indicates the location.

The <media/> element MAY also contain one or more <data/> elements for distributing the media in-band. The <data/> element MUST contain the Base64 encoded (in accordance with Section 3 of &rfc3548;) media data. The encoded data SHOULD NOT be larger than 8 KB. Note that if a stanza contains more than one <data/> element then the sending entity MUST take care not to trigger karma limits.

@@ -102,8 +102,8 @@ ]]> -

Each of the challenge form's <field/> elements (see Data Forms) that are not hidden MAY contain a different challenge and any media required for the challenge. The hidden 'from' field MUST contain the value of the 'to' attribute of the client's stanza that triggered the challenge. If the stanza from the client included an 'id' attribute then the hidden 'sid' field MUST be set to that value. The 'xml:lang' attribute of the challenge stanza SHOULD be the same as the one received from the client. The hidden 'FORM_TYPE' field MUST have a value of "http://jabber.org/protocol/challenge" in accordance with &jep0068;.

-

The challenger SHOULD include an explanation (in the &BODY; element) for clients that do not support this protocol. The challenger MAY also include a URL (typically a Web page with instructions) using &jep0066; as an alternative for clients that do not support the challenge form. Note: even if it provides a URL, a challenger MUST always provide a challenge form. A constrained client, like a mobile phone, cannot present a Web page to its user.

+

Each of the challenge form's <field/> elements (see Data Forms) that are not hidden MAY contain a different challenge and any media required for the challenge. The hidden 'from' field MUST contain the value of the 'to' attribute of the client's stanza that triggered the challenge. If the stanza from the client included an 'id' attribute then the hidden 'sid' field MUST be set to that value. The 'xml:lang' attribute of the challenge stanza SHOULD be the same as the one received from the client. The hidden 'FORM_TYPE' field MUST have a value of "http://jabber.org/protocol/challenge" in accordance with &xep0068;.

+

The challenger SHOULD include an explanation (in the &BODY; element) for clients that do not support this protocol. The challenger MAY also include a URL (typically a Web page with instructions) using &xep0066; as an alternative for clients that do not support the challenge form. Note: even if it provides a URL, a challenger MUST always provide a challenge form. A constrained client, like a mobile phone, cannot present a Web page to its user.

-

This JEP introduces no security considerations above and beyond those described in RFC 3920 and RFC 3921.

+

This document introduces no security considerations above and beyond those described in RFC 3920 and RFC 3921.

 -

This JEP requires no interaction with &IANA;.

+

This document requires no interaction with &IANA;.

- + -

Upon approval of this JEP, the ®ISTRAR; shall register the following protocol namespaces:

+

Upon approval of this document, the ®ISTRAR; shall register the following protocol namespaces:

  • http://jabber.org/protocol/challenge
  • http://jabber.org/protocol/media
    • @@ -559,11 +559,11 @@ -

    Upon approval of this JEP, the Jabber Registrar shall register the following new FORM_TYPE. Additional fields will be defined in future submissions.

    +

    Upon approval of this document, the XMPP Registrar shall register the following new FORM_TYPE. Additional fields will be defined in future submissions.

    http://jabber.org/protocol/challenge - JEP-0158 + XEP-0158 forms enabling robot challenges     -

    Upon approval of this JEP, the Jabber Registrar shall register the following new fields for the existing jabber:iq:register FORM_TYPE. Additional fields will be defined in future submissions.

    +

    Upon approval of this document, the XMPP Registrar shall register the following new fields for the existing jabber:iq:register FORM_TYPE. Additional fields will be defined in future submissions.

    jabber:iq:register - JEP-0077 + XEP-0077

    Another protocol could allow users to edit the challenges their server will make on their behalf. For example, the number of SHA-256 bits, a personal or original question and answer, a picture, a video, or a sound recording... Of course Aunt Tillie would typically only use this feature if she was plagued by SPIM.

    - + diff --git a/xep-0159.xml b/xep-0159.xml index 802c0a18..30f3a71b 100644 --- a/xep-0159.xml +++ b/xep-0159.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
    SPIM-Blocking Control - This JEP allows clients to control how their servers may block SPIM that is addressed to them. It specifies a default privacy list fall-through action. + This document defines an XMPP protocol extension that enables clients to control how their servers may block SPIM that is addressed to them. It specifies a default privacy list fall-through action. &LEGALNOTICE; 0159 Deferred @@ -16,7 +16,7 @@ XMPP Core XMPP IM - JEP-0030 + XEP-0030 None None @@ -26,7 +26,7 @@ 0.1 2005-09-14 ip - Initial JEP version. + Initial version. 0.0.1 @@ -45,7 +45,7 @@
  • Client implementations are simplified.
  • Client-to-server bandwidth is saved.
  • Consistency with the stanza blocking protocol specified by RFC 3921.
    • -
  • The use of interactive SPIM recognition techniques (like &jep0158;) does not leak information about the destination client's presence.
    • +
  • The use of interactive SPIM recognition techniques (like &xep0158;) does not leak information about the destination client's presence.
  • If the destination client is not online when the stanza is sent, then all SPIM would need to be stored by the server until the user comes back online to decide if it is SPIM.
  • Furthermore, if the sending client is no longer online when the stanza is received, then it would not be possible for the receiving client to use interactive SPIM recognition techniques.
@@ -78,7 +78,7 @@ -

A client MAY confirm that its server supports SPIM-Blocking Control using &jep0030;.

+

A client MAY confirm that its server supports SPIM-Blocking Control using &xep0030;.

-

This JEP requires no interaction with &IANA;.

+

This document requires no interaction with &IANA;.

- + -

Upon approval of this JEP, the Jabber Registrar shall register the following well-known Service Discovery node:

+

Upon approval of this document, the XMPP Registrar shall register the following well-known Service Discovery node:

  • http://jabber.org/protocol/spim-control
 - +