From 8eeba9ccd39a3103a59a623d36b7e57ffd1d777b Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 4 Oct 2006 16:37:57 +0000 Subject: [PATCH] JEP to XEP git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@43 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0120.xml | 30 +++++++++++++++--------------- xep-0121.xml | 26 +++++++++++++------------- xep-0122.xml | 48 ++++++++++++++++++++++++------------------------ xep-0123.xml | 30 +++++++++++++++--------------- xep-0124.xml | 48 ++++++++++++++++++++++++------------------------ xep-0125.xml | 26 +++++++++++++------------- xep-0126.xml | 2 +- xep-0127.xml | 30 +++++++++++++++--------------- xep-0128.xml | 36 ++++++++++++++++++------------------ xep-0129.xml | 42 +++++++++++++++++++++--------------------- 10 files changed, 159 insertions(+), 159 deletions(-) diff --git a/xep-0120.xml b/xep-0120.xml index d8041889..2a692aa9 100644 --- a/xep-0120.xml +++ b/xep-0120.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
Infobits NOTE: This proposal was retracted by the author on 2004-02-19. @@ -38,7 +38,7 @@ 0.3 2003-10-22 psa - Major overhaul. Moved entity and relationship elements to JEP-0123, and focused this JEP only on the information format itself, which in all cases must be contained within another protocol. + Major overhaul. Moved entity and relationship elements to XEP-0123, and focused this document only on the information format itself, which in all cases must be contained within another protocol. 0.2 @@ -54,7 +54,7 @@
-

Many Jabber protocols need to define metadata about "things" on the Jabber network; such things are not limited to entities that are addressable as JIDs (e.g., users, servers, services, and chatrooms) nor even to things that are addressable as &jep0060; or &jep0030; nodes (e.g., &jep0050;), but may include anything that Jabber entities can communicate about, including files sent via Jabber file transfer protocols (e.g., &jep0066; and &jep0096;), information published via pubsub protocols (e.g., &jep0118;), and other Jabber phenomena. To date, Jabber protocols have used disparate, specialized formats for capturing such meta-information. This JEP provides a generic information format that can be included whenever a protocol needs to define metadata about something on the network.

+

Many Jabber protocols need to define metadata about "things" on the Jabber network; such things are not limited to entities that are addressable as JIDs (e.g., users, servers, services, and chatrooms) nor even to things that are addressable as &xep0060; or &xep0030; nodes (e.g., &xep0050;), but may include anything that Jabber entities can communicate about, including files sent via Jabber file transfer protocols (e.g., &xep0066; and &xep0096;), information published via pubsub protocols (e.g., &xep0118;), and other Jabber phenomena. To date, Jabber protocols have used disparate, specialized formats for capturing such meta-information. This document provides a generic information format that can be included whenever a protocol needs to define metadata about something on the network.

The format defined herein uses a simple "key-value" structure. Although this may seem contrary to the XML basis of Jabber technologies, there are at least two good reasons for pursuing this approach:

@@ -67,16 +67,16 @@

The "infobits" protocol defined herein provides a data format only. The container element is <info/>, which is qualified by the 'http://jabber.org/protocol/infobits' namespace. There is one allowable child of the <info/> element -- <bundle/> -- and one allowable child of the <bundle/> element -- <bit/>. In order to provide the relevant metadata, the <info/> element MAY contain an unbounded number of <bundle/> elements, each of which MAY contain an unbounded number of <bit/> elements.

Each <bundle/> element MUST possess a 'type' attribute, whose value specifies the aspect of reality to which the enclosed bits apply (e.g., geographical location). A <bundle/> element MAY also possess a 'context' attribute, whose value provides further specifying information about the kind of entities described by this bundle (e.g., a home address as opposed to a work address).

-

Each <bit/> element MUST possess a 'key' attribute, whose value specifies the name of the key (this MUST be an NMTOKEN as defined in &w3xml;). A <bit/> element MAY also possess a 'datatype' attribute, whose value specifies the datatype of the key (which SHOULD be a datatype specified in &w3xmlschema2; or in a registry of values maintained by the Jabber Registrar, such as those described in &jep0122;). The <bit/> element SHOULD contain XML character data that specifies the relevant value of the 'key'. A <bundle/> element MAY contain more than one <bit/> element with the same value for the 'key' attribute when necessary (e.g., two instances of 'weblog' if the person has multiple weblogs), but obviously SHOULD NOT do so if a collision would occur (e.g., two instances of 'lat' and 'lon' to define a geographical location).

-

Note well: no keys are defined in this JEP. All such keys MUST be defined in separate specifications. Keys and associated values shown in this JEP are provided for explanatory purposes only.

+

Each <bit/> element MUST possess a 'key' attribute, whose value specifies the name of the key (this MUST be an NMTOKEN as defined in &w3xml;). A <bit/> element MAY also possess a 'datatype' attribute, whose value specifies the datatype of the key (which SHOULD be a datatype specified in &w3xmlschema2; or in a registry of values maintained by the Jabber Registrar, such as those described in &xep0122;). The <bit/> element SHOULD contain XML character data that specifies the relevant value of the 'key'. A <bundle/> element MAY contain more than one <bit/> element with the same value for the 'key' attribute when necessary (e.g., two instances of 'weblog' if the person has multiple weblogs), but obviously SHOULD NOT do so if a collision would occur (e.g., two instances of 'lat' and 'lon' to define a geographical location).

+

Note well: no keys are defined in this document. All such keys MUST be defined in separate specifications. Keys and associated values shown in this document are provided for explanatory purposes only.

 -

When an entity is queried via &jep0030; regarding the features it supports, it SHOULD include the 'http://jabber.org/protocol/infobits' namespace.

+

When an entity is queried via &xep0030; regarding the features it supports, it SHOULD include the 'http://jabber.org/protocol/infobits' namespace.

 -

This set of examples is borrowed from &jep0080;.

+

This set of examples is borrowed from &xep0080;.

 -

This set of examples is borrowed from &jep0118;.

+

This set of examples is borrowed from &xep0118;.

Info key names registered with the Jabber Registrar MUST be considered as identifiers, not English-language words. For purposes of internationalization, an identifier SHOULD be rendered as a word or phrase that is appropriate to the end user's preferred language.

 -

This JEP requires no interaction with &IANA;.

+

This document requires no interaction with &IANA;.

 @@ -235,12 +235,12 @@

The Jabber Registrar shall maintain a registry of infobit keynames and associated information.

All keynames MUST begin with a short prefix string (letters and numbers only), followed by the '.' character used as a separator, followed by the name of the key as determined by the particular specification or organization that is identified with the prefix. Arbitrary keynames SHOULD begin with a prefix consisting of the capital 'X' character.

-

The Jabber Registrar shall at its discretion reserve certain keyname prefixes for use in specifying particular classes of information. One example is the prefix 'DC', which is reserved for use by infobits specified by the &DUBLINCORE; (for details, see &jep0121;). Furthermore, the Jabber Registrar shall reserve the "XMPP" prefix for infobits related to documents created by the &XMPPWG; or its successors, and shall reserve the upper-case versions of all protocol "shortnames" specified in Jabber Enhancement Proposals (e.g., a prefix of "MUC" for infobits related to &jep0045;).

+

The Jabber Registrar shall at its discretion reserve certain keyname prefixes for use in specifying particular classes of information. One example is the prefix 'DC', which is reserved for use by infobits specified by the &DUBLINCORE; (for details, see &xep0121;). Furthermore, the Jabber Registrar shall reserve the "XMPP" prefix for infobits related to documents created by the &XMPPWG; or its successors, and shall reserve the upper-case versions of all protocol "shortnames" specified in Jabber Enhancement Proposals (e.g., a prefix of "MUC" for infobits related to &xep0045;).

In order to prevent naming collisions, infobits that will be used in public protocols that may interoperate with other protocols on the network SHOULD be registered with the Jabber Registrar, and MUST be so registered if they are defined in Jabber Enhancement Proposals (however, registration of private keys is NOT REQUIRED). Registration with the Jabber Registrar shall be considered to entail reservation of that infobit on the network, and a registered bit MUST NOT be re-used by other protocols and applications for purposes other than those implied by the registry entry.

In addition to the key name, the following data may be provided (but is not required) for each bit:

  1. datatype -- provide only if well-defined; otherwise assume string
    2. -
  2. doc -- the public identifier (e.g., JEP number or RFC number) of the document in which the info name is defined
    3. +
  3. doc -- the public identifier (e.g., XEP number or RFC number) of the document in which the info name is defined
  4. valid values -- a series of <value/> elements, encapsulated within a <values/> parent whose 'type' attribute is set to "exhaustive" (these are the only valid values) or "nonexhaustive" (these are some of the valid values, but this list is not exhaustive and other values may be provided)

The registry format is as follows:

@@ -307,4 +307,4 @@

Given these and other concerns, the primary author concluded that the best course would be to define an extensible XML protocol that can be processed using tools that are standard within existing Jabber/XMPP implementations, that allows only the entity itself to define metadata about itself, and that is under the control of the Jabber/XMPP community.

 - + diff --git a/xep-0121.xml b/xep-0121.xml index be2baceb..b3314188 100644 --- a/xep-0121.xml +++ b/xep-0121.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
Dublin Core Infobits Mapping NOTE: This proposal was retracted by the author on 2004-02-19. @@ -16,7 +16,7 @@ Retracted Informational Standards JIG - JEP-0120 + XEP-0120 None None N/A @@ -43,7 +43,7 @@ 0.3 2003-10-22 psa - Updated to track changes in JEP-0120. + Updated to track changes in XEP-0120. 0.2 @@ -59,13 +59,13 @@
-

&jep0120; defines a protocol for capturing granular information (or "infobits") about users, servers, services, rooms, nodes, commands, files, and other phenomena on the Jabber/XMPP network; however, that document defines the protocol only, not the infobits themselves. This JEP specifies how to encapsulate one sort of metadata in infobits: the common metadata elements defined by the &DUBLINCORE;. Note well that this JEP is decidedly not meant to provide an exhaustive catalog of possible infobits. Future registrations, whether in Jabber Enhancement Proposals or direct submissions to the ®ISTRAR;, will specify additional infobits.

+

&xep0120; defines a protocol for capturing granular information (or "infobits") about users, servers, services, rooms, nodes, commands, files, and other phenomena on the Jabber/XMPP network; however, that document defines the protocol only, not the infobits themselves. This document specifies how to encapsulate one sort of metadata in infobits: the common metadata elements defined by the &DUBLINCORE;. Note well that this document is decidedly not meant to provide an exhaustive catalog of possible infobits. Future registrations, whether in Jabber Enhancement Proposals or direct submissions to the ®ISTRAR;, will specify additional infobits.

The Dublin Core Metadata Initiative defines a number of common elements and element refinements that can be used to specify metadata about entities (especially but not exclusively publications). The semantics of any Dublin Core term can be represented as a Jabber infobit, where the infobit keyname consists of the term name (not label) prepended by a 'DC' prefix and a '.' separator character. Thus "DC.creator" is a valid infobit name and can be used to describe, for example, an IM user's relationship to the URI identifying the user's homepage or weblog. Infobit keynames beginning with the 'DC' prefix are reserved for &dcmiterms; only (the canonical list of these terms is available from the Dublin Core Metadata Initiative and is included here only for explanatory purposes).

 -

The following example is borrowed from &jep0118;.

+

The following example is borrowed from &xep0118;.

 -

This JEP introduces no security considerations above and beyond those already defined in JEP-0120.

+

This document introduces no security considerations above and beyond those already defined in XEP-0120.

 -

This JEP requires no interaction with &IANA;.

+

This document requires no interaction with &IANA;.

 - -

The following is a submission to the infobits registry called for by JEP-0120.

+ +

The following is a submission to the infobits registry called for by XEP-0120.

@@ -193,4 +193,4 @@ ]]> - + diff --git a/xep-0122.xml b/xep-0122.xml index 380fc85e..890992bf 100644 --- a/xep-0122.xml +++ b/xep-0122.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
Data Forms Validation - This JEP defines an extension to the Data Forms protocol that enables applications to specify additional validation guidelines. + This document defines an extension to the Data Forms protocol that enables applications to specify additional validation guidelines. &LEGALNOTICE; 0122 Draft @@ -15,13 +15,13 @@ Standards JIG XMPP Core - JEP-0004 + XEP-0004 xdata-validate - http://jabber.org/protocol/xdata-validate/xdata-validate.xsd + http://www.xmpp.org/schemas/xdata-validate.xsd &linuxwolf; @@ -41,7 +41,7 @@ 0.7 2004-08-23 lw - Replaced method attribute with dedicated elements; removed Formal Definition section in favor of defining requirements within the use-cases and XML schema; included display considerations; added reference to JEP-0115. + Replaced method attribute with dedicated elements; removed Formal Definition section in favor of defining requirements within the use-cases and XML schema; included display considerations; added reference to XEP-0115. 0.6 @@ -81,10 +81,10 @@
-

&jep0004; ("x:data") provides a simple and interoperable way to request and present information for both applications and humans. However, the simple nature of "x:data" requires the form interpreter at times to guess as to exactly what type of information is being requested or provided. This JEP builds upon "x:data" to provide this additional validation.

+

&xep0004; ("x:data") provides a simple and interoperable way to request and present information for both applications and humans. However, the simple nature of "x:data" requires the form interpreter at times to guess as to exactly what type of information is being requested or provided. This document builds upon "x:data" to provide this additional validation.

 -

The requirements for this JEP are:

+

The requirements for this document are:

  • Backwards compatible with the existing "x:data" protocol.
  • Provide extended datatypes (such as dates, times, and numbers).
    • @@ -95,7 +95,7 @@
-

This JEP defines a new namespace, "http://jabber.org/protocols/xdata-validate". The root element for this namespace is <validate/>, and MUST be contained within a <field/> element (qualified by the 'jabber:x:data' namespace) for each Data Forms field that possesses additional validation information.

+

This document defines a new namespace, "http://jabber.org/protocols/xdata-validate". The root element for this namespace is <validate/>, and MUST be contained within a <field/> element (qualified by the 'jabber:x:data' namespace) for each Data Forms field that possesses additional validation information.

The simplest usage is to provide a more-granular datatype for a <field/> element used in Data Forms. To provide this datatype information, a <validate/> element is included whose 'datatype' attribute specifies the data type of any <value/> contained within the <field/> element:

 -

In addition to datatypes, the validation method can also be provided. The method is specified via a child element. The validation methods defined in this JEP are:

+

In addition to datatypes, the validation method can also be provided. The method is specified via a child element. The validation methods defined in this document are:

  • <basic/> for validation only against the datatype itself
  • <open/> for open-ended validation against the datatype
    • @@ -222,7 +222,7 @@

    If an implementation does not understand the specified datatype, it MUST validate according to the default "xs:string" datatype. If an implementation does not understand the specified method, it MUST validate according to the <basic/> method.

    -

    While all elements associated with this JEP MUST be qualified by the 'http://jabber.org/protocol/xdata-validate' namespace, explicitly declaring the default namespace for each instance can be overly verbose. However, Jabber/XMPP implementations have historically been very lax regarding namespacing, thus requiring some careful use of prefixes.

    +

    While all elements associated with this document MUST be qualified by the 'http://jabber.org/protocol/xdata-validate' namespace, explicitly declaring the default namespace for each instance can be overly verbose. However, Jabber/XMPP implementations have historically been very lax regarding namespacing, thus requiring some careful use of prefixes.

    The use of namespace prefixes is RECOMMENDED for large forms, to reduce the data size. To maintain the highest level of compatibility, implementations sending the form using prefixes SHOULD use the namespace prefix "xdv", and SHOULD declare the namespace prefix mapping in the ancestor <x xmlns='jabber:x:data'/> element:

     -

    This JEP relies on the internationalization/localization mechanisms provided by &xmppcore;. As much as possible, all datatype formats MUST be locale-independent.

    +

    This document relies on the internationalization/localization mechanisms provided by &xmppcore;. As much as possible, all datatype formats MUST be locale-independent.

    Form processors MUST NOT assume that a form with validation has actually been validated when submitted. There is no realistic expectation that form interpreters honor validation.

     -

    While this JEP is compatible with the existing "x:data" definition, form providers SHOULD first determine support for it, using either &jep0115; if presence-aware or &jep0030;. This is especially important for limited-connection and/or limited-capabilities devices, such as cell phones.

    +

    While this document is compatible with the existing "x:data" definition, form providers SHOULD first determine support for it, using either &xep0115; if presence-aware or &xep0030;. This is especially important for limited-connection and/or limited-capabilities devices, such as cell phones.

    Although primarily intended for validating form submission, validation MAY have an impact on display, and MAY be applied to data forms that are not submitted (e.g. 'result' type forms). The following table outlines which field types a particular validation method is or is not appropriate for, and how a display SHOULD interpret the validation methods if consideredIf a particular field type is not listed, the display MAY include validation support, but is not expected to do so.:

    @@ -328,18 +328,18 @@     -

    This JEP introduces no security concerns above and beyond those specified in JEP-0004: Data Forms.

    +

    This document introduces no security concerns above and beyond those specified in XEP-0004: Data Forms.

     -

    This JEP requires no interaction with &IANA;.

    +

    This document requires no interaction with &IANA;.

     - + -

    The Jabber Registrar includes 'http://jabber.org/protocol/xdata-validate' in its registry of protocol namespaces.

    +

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

     -

    The Jabber 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 http://www.jabber.org/registrar/xdv-prefixes.html), where each prefix denotes a group of related datatypes.

    ®PROCESS; The registrant may register more than one prefix at a time, each contained in a separate <datatype-prefix/> element.

     -

    As part of this JEP, the following datatype prefixes shall be registered:

    +

    As part of this document, the following datatype prefixes shall be registered:

    x An ad-hoc datatype - JEP-0122 + XEP-0122 xs @@ -368,7 +368,7 @@     -

    The Jabber 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 http://www.jabber.org/registrar/xdv-datatypes.html), where each datatype name includes the relevant prefix (e.g., "xs:anyURI").

    ®PROCESS; ]]>     - + diff --git a/xep-0123.xml b/xep-0123.xml index ce21857c..ed53a681 100644 --- a/xep-0123.xml +++ b/xep-0123.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
    Entity Metadata NOTE: This proposal was retracted by the author on 2004-02-19. @@ -16,7 +16,7 @@ Retracted Standards Track Standards JIG - XMPP Core, XMPP IM, JEP-0030, JEP-0120 + XMPP Core, XMPP IM, XEP-0030, XEP-0120 None None N/A @@ -25,7 +25,7 @@ 0.3 2003-12-16 psa - Incorporated infobits changes and vCard infobit mappings; metadata about relationships to be moved to forthcoming JEP. + Incorporated infobits changes and vCard infobit mappings; metadata about relationships to be moved to forthcoming specification. 0.2 @@ -37,11 +37,11 @@ 0.1 2003-10-22 psa - Initial version, split off from JEP-0120. + Initial version, split off from XEP-0120.
    -

    Traditionally, the only mechanism for communicating detailed information about entities on the Jabber network has been an XML version of the vCard format for electronic business cards (see &jep0054;). Unfortunately, the vCard format has several major drawbacks:

    +

    Traditionally, the only mechanism for communicating detailed information about entities on the Jabber network has been an XML version of the vCard format for electronic business cards (see &xep0054;). Unfortunately, the vCard format has several major drawbacks:

    1. It is mainly limited to data about persons (although it has been used on the Jabber network to describe things like servers).
    2. The format contains relatively few data fields.
      3. @@ -51,14 +51,14 @@

    It is becoming increasingly important to define a robust, extensible format for describing entities on the Jabber network. Such a format should be:

      -
    1. Applicable not just to people but to any entity on the network, including but not limited to servers, components, bots, &jep0045; rooms, &jep0060; nodes, and in general anything that can be addressed as a Jabber ID (as defined in &xmppcore;).
      2. +
    2. 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;).
    3. Usable in encapsulating any information about the entity itself (name, address, description, title, etc.).
    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 Jabber Software 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.
     -

    Information about entities is provided using the &jep0120; protocol and registered infobit keynames (mainly those specified in &jep0125; although entity metadata is by no means limited to vCard information and could include infobits such as those specified in &jep0121;). The metadata is discovered by interacting with a common &jep0030; node named "metadata". The queried entity replies with a service discovery result containing any infobits that the entity wishes to reveal about itself to the requesting entity. This information is always metadata about the entity itself, not any other entities or any relationships that the entity may have to other entities.

    +

    Information about entities is provided using the &xep0120; protocol and registered infobit keynames (mainly those specified in &xep0125; although entity metadata is by no means limited to vCard information and could include infobits such as those specified in &xep0121;). The metadata is discovered by interacting with a common &xep0030; node named "metadata". The queried entity replies with a service discovery result containing any infobits that the entity wishes to reveal about itself to the requesting entity. This information is always metadata about the entity itself, not any other entities or any relationships that the entity may have to other entities.

     @@ -126,18 +126,18 @@
  • directories of pubsub nodes
  • server directories
-

Although such directories will be a valuable addition to the network, it is imperative to understand that the canonical source for metadata about an entity is the entity itself. Mechanisms for keeping directories synchronized with entities are outside the scope of this JEP, and in any case a directory may not be privy to all information about an entity (since in general a user should publish to a directory only the information that he or she deems world-readable).

-

Directories SHOULD require registration using &jep0077;. Before registering with a directory, an entity SHOULD adjust its access controls or privacy rules accordingly, including appropriate definition of classes and addition of the directory server's JID to the relevant privacy rules. Upon accepting registration from an entity, a directory SHOULD immediately send a metadata request to the registering entity. Synchronization of metadata is a matter for the directory implementation to determine, and perhaps negotiate with the registering entity; all such synchronization and negotiation is out of scope for this JEP.

+

Although such directories will be a valuable addition to the network, it is imperative to understand that the canonical source for metadata about an entity is the entity itself. Mechanisms for keeping directories synchronized with entities are outside the scope of this document, and in any case a directory may not be privy to all information about an entity (since in general a user should publish to a directory only the information that he or she deems world-readable).

+

Directories SHOULD require registration using &xep0077;. Before registering with a directory, an entity SHOULD adjust its access controls or privacy rules accordingly, including appropriate definition of classes and addition of the directory server's JID to the relevant privacy rules. Upon accepting registration from an entity, a directory SHOULD immediately send a metadata request to the registering entity. Synchronization of metadata is a matter for the directory implementation to determine, and perhaps negotiate with the registering entity; all such synchronization and negotiation is out of scope for this document.

Metadata MAY be world-readable. Entities MUST take care to ensure that they exercise proper control over access to such information. Users of IM clients SHOULD be warned that their data may be world-readable and be given the option to not publish such information or control it via appropriate mechanisms (such as privacy rules).

 -

This JEP requires no interaction with &IANA;.

+

This document requires no interaction with &IANA;.

 - +

Upon advancement of this proposal to a status of Draft, the ®ISTRAR; shall add the 'metadata' node to its registry of common Service Discovery nodes.

 - + diff --git a/xep-0124.xml b/xep-0124.xml index 7861c807..b79f7691 100644 --- a/xep-0124.xml +++ b/xep-0124.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
HTTP Binding - This JEP defines a binding of Jabber/XMPP communications to a transport layer of HTTP rather than TCP. + This document defines a binding of XMPP communications to a transport layer of HTTP rather than TCP. &LEGALNOTICE; 0124 Draft @@ -23,7 +23,7 @@ httpbind - http://jabber.org/protocol/httpbind/httpbind.xsd + http://www.xmpp.org/schemas/httpbind.xsd &ianpaterson; &dizzyd; @@ -126,11 +126,11 @@
-

&xmppcore; defines XML streams bound to TCP (see &rfc0793;) as the standard transport layer for Jabber/XMPP communications. However, the binding of XMPP to TCP is not always feasible because of client runtime environment and/or network constraints. This JEP describes the usage of the Hypertext Transfer Protocol (HTTP, see &rfc2068; and &rfc1945;) as an alternative transport binding that supports such constrained environments, normally via deployment of a specialized server-side connection manager that communicates with clients via HTTP rather than TCP.

-

Before the authors pursued publication of this JEP, other approaches were explored. One possible approach might have been to apply state to a series of HTTP transactions via HTTP "cookies" as specified in &rfc2965;. However, there are several significant computing platforms which provide only limited access to underlying HTTP requests/responses; worse, some platforms hide or remove cookie-related headers. Therefore the cookie approach was rejected.

-

Another approach might have been to modify or extend &jep0025;. This informational protocol has been used by Jabber clients without runtime constraints to access XMPP servers from behind firewalls. Unfortunately, the method defined in JEP-0025 also depends on cookies, does not meet most of the requirements described below, and cannot be extended without breaking all existing implementations.

-

Therefore, this JEP specifies a new way of transporting XMPP via HTTP. All information is encoded in the body of standard HTTP POST requests and responses. Each HTTP body contains a single <body/> XML wrapper element (not to be confused with the <body/> child of the <message/> stanza as defined in &xmppim;), which encapsulates zero or more XML stanzas.

-

Although this JEP documents some XMPP-specific features, the binding is not part of XMPP. In fact, the protocol is extensible and could be used to implement any bidirectional stream of XML stanzas.

+

&xmppcore; defines XML streams bound to TCP (see &rfc0793;) as the standard transport layer for Jabber/XMPP communications. However, the binding of XMPP to TCP is not always feasible because of client runtime environment and/or network constraints. This document describes the usage of the Hypertext Transfer Protocol (HTTP, see &rfc2068; and &rfc1945;) as an alternative transport binding that supports such constrained environments, normally via deployment of a specialized server-side connection manager that communicates with clients via HTTP rather than TCP.

+

Before the authors pursued publication of this document, other approaches were explored. One possible approach might have been to apply state to a series of HTTP transactions via HTTP "cookies" as specified in &rfc2965;. However, there are several significant computing platforms which provide only limited access to underlying HTTP requests/responses; worse, some platforms hide or remove cookie-related headers. Therefore the cookie approach was rejected.

+

Another approach might have been to modify or extend &xep0025;. This informational protocol has been used by Jabber clients without runtime constraints to access XMPP servers from behind firewalls. Unfortunately, the method defined in XEP-0025 also depends on cookies, does not meet most of the requirements described below, and cannot be extended without breaking all existing implementations.

+

Therefore, this document specifies a new way of transporting XMPP via HTTP. All information is encoded in the body of standard HTTP POST requests and responses. Each HTTP body contains a single <body/> XML wrapper element (not to be confused with the <body/> child of the <message/> stanza as defined in &xmppim;), which encapsulates zero or more XML stanzas.

+

Although this specification documents some XMPP-specific features, the binding is not part of XMPP. In fact, the protocol is extensible and could be used to implement any bidirectional stream of XML stanzas.

 @@ -170,7 +170,7 @@ Connection Manager | HTTP Client ]]> -

This JEP addresses communications between an HTTP client and the connection manager only. It does not address communications between the connection manager and the XMPP server, since such communications are implementation-specific (e.g., the connection manager and the XMPP server may use &jep0114; or an API defined by the XMPP server implementation in order to communicate; alternatively, the XMPP server may natively support the HTTP binding, in which case the connection manager will be a logical entity rather than a physical entity).

+

This document addresses communications between an HTTP client and the connection manager only. It does not address communications between the connection manager and the XMPP server, since such communications are implementation-specific (e.g., the connection manager and the XMPP server may use &xep0114; or an API defined by the XMPP server implementation in order to communicate; alternatively, the XMPP server may natively support the HTTP binding, in which case the connection manager will be a logical entity rather than a physical entity).

Furthermore, no aspect of the HTTP binding limits its use to client-to-server communications; i.e., it could be used for server-to-server or component-to-server communications as well (probably through a slight change to the XML schema). However, this document focuses exclusively on use of the HTTP binding by clients that cannot maintain persistent TCP connections to a server and that therefore cannot use the TCP binding defined in RFC 3920. We assume that servers and components are under no such restrictions and thus would use the TCP binding.

@@ -179,7 +179,7 @@ Connection Manager

Clients MAY include an HTTP Accept-Encoding header in any request. If the connection manager receives a request with an Accept-Encoding header, it MAY include an HTTP Content-Encoding header in the response (indicating one of the encodings specified in the request) and compress the response body accordingly.

-

TLS compression (as defined in RFC 3920) and Stream Compression (as defined in &jep0138;) are NOT RECOMMENDED since compression SHOULD be negotiated at the HTTP layer and with the 'accept' attribute (see the Session Creation section below). TLS compression and Stream Compression SHOULD NOT be used simultaneously with HTTP content encoding.

+

TLS compression (as defined in RFC 3920) and Stream Compression (as defined in &xep0138;) are NOT RECOMMENDED since compression SHOULD be negotiated at the HTTP layer and with the 'accept' attribute (see the Session Creation section below). TLS compression and Stream Compression SHOULD NOT be used simultaneously with HTTP content encoding.

The body of each HTTP request and response contains a single <body/> wrapper element. The <body/> element MUST contain zero or more complete XML elements. It MUST NOT contain partial XML elements.

@@ -225,7 +225,7 @@ Content-Length: 104 wait='60' xml:lang='en' xmlns='http://jabber.org/protocol/httpbind'/>]]> -

Note: Unlike the protocol defined in JEP-0025, an opening <stream:stream> tag is not sent. The protocol defined herein abstracts from XML streams between the connection manager and the client. Any XML streams between the connection manager and an XMPP server are the responsibility of the connection manager.

+

Note: Unlike the protocol defined in XEP-0025, an opening <stream:stream> tag is not sent. The protocol defined herein abstracts from XML streams between the connection manager and the client. Any XML streams between the connection manager and an XMPP server are the responsibility of the connection manager.

Note: All requests after the first one MUST include a valid 'sid' attribue (provided by the connection manager in the session creation response below). The initialization request is unique in that the <body/> element MUST NOT possess a 'sid' attribute.

@@ -252,7 +252,7 @@ Content-Length: 128 secure='true' charsets='ISO_8859-1 ISO-2022-JP' xmlns='http://jabber.org/protocol/httpbind'/>]]> -

Note: The 'authid' attribute contains the value of the XMPP stream ID generated by the XMPP server. The connection manager MUST retrieve the stream ID and pass it unmodified to the client. This value is needed by the client to successfully complete digest authentication using &jep0078; (see the jabber:iq:auth section below).

+

Note: The 'authid' attribute contains the value of the XMPP stream ID generated by the XMPP server. The connection manager MUST retrieve the stream ID and pass it unmodified to the client. This value is needed by the client to successfully complete digest authentication using &xep0078; (see the jabber:iq:auth section below).

Note: If the 'authid' attribute is not included in the connection manager's response to the session creation request (e.g., because the connection manager has not yet received a stream ID from the XMPP server), then the client SHOULD send empty request elements (see the "Requesting XML Stanzas" example below) until it receives a response with an 'authid' attribute. In any case, the connection manager MUST return the 'authid' in a response to the client as soon as possible after it receives the stream ID from the XMPP server.

Separate 'sid' and 'authid' attributes are required because the connection manager is not necessarily part of a single XMPP server (e.g., it may handle HTTP connections on behalf of multiple XMPP servers).

If it established a secure connection to the XMPP server (as defined in Initiating an HTTP Session), then the connection manager SHOULD include the 'secure' attribute set to 'true' or '1' in the response to the client that contains the 'authid' attribute.

@@ -455,7 +455,7 @@ Content-Length: 175 -

A success case for simultaneous authentication, resource binding, and IM session creation using the original "jabber:iq:auth" protocol is shown below. For further details regarding use of this protocol, refer to JEP-0078. If digest authentication is used, then the stream ID value used to compute the hashed password MUST be the value of the 'authid' attribute provided by the connection manager in the response to the initialization element or in a subsequent response (see the Session Creation section above).

+

A success case for simultaneous authentication, resource binding, and IM session creation using the original "jabber:iq:auth" protocol is shown below. For further details regarding use of this protocol, refer to XEP-0078. If digest authentication is used, then the stream ID value used to compute the hashed password MUST be the value of the 'authid' attribute provided by the connection manager in the response to the initialization element or in a subsequent response (see the Session Creation section above).

HTTP ConditionsThe connection manager responds to an invalid client request with a standard HTTP error. These are used for binding syntax errors, possible attacks, etc. Note that constrained clients are unable to differentiate between HTTP errors. Terminal Binding ConditionsThese error conditions may be read by constrained clients. They are used for connection manager problems, abstracting stream errors, and communication problems between the connection manager and the XMPP server. Recoverable Binding ConditionsThese report communication problems between the connection manager and the client. They do not terminate the session. Clients recover from these errors by resending all the preceding <body/> wrapper elements that have not received responses. - XMPP Stanza ConditionsXMPP errors relating to XML stanzas within <body/> wrapper elements are, in general, defined in the appropriate RFC or JEP. They do not terminate the session. (An example of such usage is shown in jabber:iq:auth above.) + XMPP Stanza ConditionsXMPP errors relating to XML stanzas within <body/> wrapper elements are, in general, defined in the appropriate RFC or XEP. They do not terminate the session. (An example of such usage is shown in jabber:iq:auth above.)

Full descriptions are provided below.

The following HTTP error and status codes are used in particular ways by this protocol (other HTTP error and status codes may be used as appropriate). Upon receiving an HTTP error (400, 403, 404), the HTTP client MUST consider the HTTP session to be null and void.

-

Note: These are pure HTTP codes as defined in the HTTP specification, and are not to be confused with the HTTP-style error codes traditionally used in Jabber protocols and documented in &jep0086;.

+

Note: These are pure HTTP codes as defined in the HTTP specification, and are not to be confused with the HTTP-style error codes traditionally used in Jabber protocols and documented in &xep0086;.

@@ -971,7 +971,7 @@ Content-Length: 68 xmlns='http://jabber.org/protocol/httpbind'/>]]> -

Application-level error conditions will normally be generated by a third entity (e.g., an IM contact) and routed to the client through the connection manager; therefore they are out of scope for the transport binding defined herein and are described in the appropriate RFC or JEP.

+

Application-level error conditions will normally be generated by a third entity (e.g., an IM contact) and routed to the client through the connection manager; therefore they are out of scope for the transport binding defined herein and are described in the appropriate RFC or XEP.

However, it is possible that a connection manager will receive a stanza for delivery to a client even though the client connection is no longer active (e.g., before the connection manager is able to inform a server that the connection has died). In this case, the connection manager would return an error to the server; it is RECOMMENDED that the connection manager proceed as follows, since the situation is similar to that addressed by point #2 of Section 11.1 of RFC 3921:

  1. If the delivered stanza was &PRESENCE;, silently drop the stanza and do not return an error to the sender.
    2. @@ -992,12 +992,12 @@ Content-Length: 68
  2. If the client sends a wrapper element that is part of a 'secure session' over a connection that either is not encrypted or uses a different certificate then the connection manager SHOULD simply close the connection. The connection manager SHOULD NOT terminate the session since that would facilitate denial of service attacks.

    3. The session identifier (SID) and initial request identifier (RID) are security-critical and therefore MUST be both unpredictable and nonrepeating (see &rfc1750; for recommendations regarding randomness of SIDs and initial RIDs for security purposes).

    -

    In cases where the connection manager acts as a 'proxy' independent of the XMPP server, it creates another security vulnerability in addition to those on the XMPP servers. It is RECOMMENDED that clients ensure the security of stanzas sent through the connection manager (and XMPP servers) in both directions by encrypting them end-to-end (e.g., by establishing &jep0116;).

    +

    In cases where the connection manager acts as a 'proxy' independent of the XMPP server, it creates another security vulnerability in addition to those on the XMPP servers. It is RECOMMENDED that clients ensure the security of stanzas sent through the connection manager (and XMPP servers) in both directions by encrypting them end-to-end (e.g., by establishing &xep0116;).

    -

    This JEP requires no interaction with &IANA;.

    +

    This document requires no interaction with &IANA;.

     - +

    The ®ISTRAR; includes 'http://jabber.org/protocol/httpbind' in its registry of protocol namespaces.

     @@ -1016,7 +1016,7 @@ Content-Length: 68 The protocol documented by this schema is defined in - JEP-0124: http://www.jabber.org/jeps/jep-0124.html + XEP-0124: http://www.xmpp.org/extensions/xep-0124.html @@ -1098,4 +1098,4 @@ Content-Length: 68 ]]>     - + diff --git a/xep-0125.xml b/xep-0125.xml index 626df27a..f82639af 100644 --- a/xep-0125.xml +++ b/xep-0125.xml @@ -1,10 +1,10 @@ - + %ents; ]> - - + +
    vCard Infobits Mapping NOTE: This proposal was retracted by the author on 2004-02-19. @@ -16,7 +16,7 @@ Retracted Informational Standards JIG - JEP-0120 + XEP-0120 None None N/A @@ -25,14 +25,14 @@ 0.1 2003-12-15 psa - Initial version, split off from version 0.5 of JEP-0121 (with revisions to more clearly map vCard elements); further mapping and description required. + Initial version, split off from version 0.5 of XEP-0121 (with revisions to more clearly map vCard elements); further mapping and description required.
    -

    &jep0120; defines a protocol for capturing granular information (or "infobits") about users, servers, services, rooms, nodes, commands, files, and other phenomena on the Jabber/XMPP network; however, that document defines the protocol only, not the infobits themselves. This JEP specifies how to encapsulate one sort of metadata in infobits: the metadata elements about entities defined by &rfc2426; (supplemented by vCard-like metadata that is not defined in RFC 2426), thus enabling the Jabber community to supersede &jep0054;. Note well that this JEP is decidedly not meant to provide an exhaustive catalog of possible infobits. Future registrations, whether in Jabber Enhancement Proposals or direct submissions to the ®ISTRAR;, will specify additional infobits.

    +

    &xep0120; defines a protocol for capturing granular information (or "infobits") about users, servers, services, rooms, nodes, commands, files, and other phenomena on the Jabber/XMPP network; however, that document defines the protocol only, not the infobits themselves. This document specifies how to encapsulate one sort of metadata in infobits: the metadata elements about entities defined by &rfc2426; (supplemented by vCard-like metadata that is not defined in RFC 2426), thus enabling the Jabber community to supersede &xep0054;. Note well that this document is decidedly not meant to provide an exhaustive catalog of possible infobits. Future registrations, whether in Jabber Enhancement Proposals or direct submissions to the ®ISTRAR;, will specify additional infobits.

     -

    In order to supersede the vCard-XML protocol currently in use within the Jabber community, it is necessary to define infobits that correspond to the data elements defined by the vCard-XML DTD (more precisely, the vCard Profile Features specified in section 3 of RFC 2426). These are shown in the following table. (Note: this mapping uses the vCard entity names specified in &dawson3;, not those specified in JEP-0054.)

    +

    In order to supersede the vCard-XML protocol currently in use within the Jabber community, it is necessary to define infobits that correspond to the data elements defined by the vCard-XML DTD (more precisely, the vCard Profile Features specified in section 3 of RFC 2426). These are shown in the following table. (Note: this mapping uses the vCard entity names specified in &dawson3;, not those specified in XEP-0054.)

Code
@@ -260,13 +260,13 @@
Infobit Key
 -

This JEP introduces no security considerations above and beyond those already defined in JEP-0120.

+

This document introduces no security considerations above and beyond those already defined in XEP-0120.

 -

This JEP requires no interaction with &IANA;.

+

This document requires no interaction with &IANA;.

 - -

The following is a submission to the infobits registry called for by JEP-0120.

+ +

The following is a submission to the infobits registry called for by XEP-0120.

To follow.

 @@ -274,4 +274,4 @@

To follow.

 - + diff --git a/xep-0126.xml b/xep-0126.xml index 25c76ad3..cdf04ec0 100644 --- a/xep-0126.xml +++ b/xep-0126.xml @@ -415,7 +415,7 @@

This document requires no interaction with &IANA;.

 - +

No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this specification.

 diff --git a/xep-0127.xml b/xep-0127.xml index cc0bd32a..6a6b5ed1 100644 --- a/xep-0127.xml +++ b/xep-0127.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
Common Alerting Protocol (CAP) Over XMPP - This JEP specifies a method for sending Common Alerting Protocol (CAP) data over XMPP. + This document specifies a method for sending Common Alerting Protocol (CAP) data over XMPP. &LEGALNOTICE; 0127 Active @@ -37,7 +37,7 @@ 0.2 2004-11-09 psa - Added references to JEP-0033 and JEP-0131. + Added references to XEP-0033 and XEP-0131. 0.1 @@ -55,8 +55,8 @@

Because the alerts and notifications structured via CAP require a "push" medium, they SHOULD be sent via the XML &MESSAGE; stanza defined in XMPP Core. The message could be sent using either of the following methods:

    -
  1. Directly from the sender to a single recipient, a list of recipients (using &jep0033;), or a &jep0045; room
    2. -
  2. Published to a list of subscribers via &jep0060;
    3. +
  3. Directly from the sender to a single recipient, a list of recipients (using &xep0033;), or a &xep0045; room
    4. +
  4. Published to a list of subscribers via &xep0060;

Both methods are described below.

@@ -112,7 +112,7 @@ ]]> -

The publish-subscribe protocol defined in JEP-0060 provides a way to send information to a number of subscribers, and to control the list of subscribers.

+

The publish-subscribe protocol defined in XEP-0060 provides a way to send information to a number of subscribers, and to control the list of subscribers.

The following example shows Example A.2 from the CAP specification published to a pubsub node.

 -

Security considerations for CAP are defined in Common Alerting Protocol, v. 1.0; security considerations for XMPP are defined in RFC 3920: XMPP Core; security considerations for the XMPP publish-subscribe extension are defined in JEP-0060: Publish Subscribe.

-

Furthermore, it may be appropriate to include the "Classification", "Distribute", and/or "Store" headers specified in &jep0131; in order to safeguard CAP data.

+

Security considerations for CAP are defined in Common Alerting Protocol, v. 1.0; security considerations for XMPP are defined in RFC 3920: XMPP Core; security considerations for the XMPP publish-subscribe extension are defined in XEP-0060: Publish Subscribe.

+

Furthermore, it may be appropriate to include the "Classification", "Distribute", and/or "Store" headers specified in &xep0131; in order to safeguard CAP data.

 -

This JEP requires no interaction with &IANA;.

+

This document requires no interaction with &IANA;.

 - -

No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this JEP.

+ +

No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this document.

The CAP information format is defined by an XML schema. The reader is referred to the CAP specification for the relevant schema definition.

 - + diff --git a/xep-0128.xml b/xep-0128.xml index 369fb759..d061864a 100644 --- a/xep-0128.xml +++ b/xep-0128.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
Service Discovery Extensions - This JEP specifies best practices for including extended information in Service Discovery results. + This document specifies best practices for including extended information in Service Discovery results. &LEGALNOTICE; 0128 Active @@ -15,9 +15,9 @@ Standards JIG XMPP Core - JEP-0004 - JEP-0030 - JEP-0068 + XEP-0004 + XEP-0030 + XEP-0068 @@ -43,10 +43,10 @@
-

Developers periodically wonder why &jep0030; does not include more bits of information. For example, why does the <identity/> element not include a 'description' attribute, and can we add one now? The answer is: well, it just doesn't, and at this point it's too late to make further changes (since JEP-0030 is Final). So the best approach is to specify a well-defined extension mechanism.

-

Let us consider an example. A &jep0045; room might want to include additional information in its service discovery results, such as the full room description, the current discussion topic (room subject), the number of occupants in the room, and the JID of the room owner.

-

Adding one new attribute to the service discovery schema (even if that were an option) would not solve the problem, since a MUC service might want to provide certain bits of information, whereas a &jep0060; service might want to provide other bits.

-

A better solution would be to include extended information qualified by a namespace that provides a way to flexibly define structured data formats. Thankfully, we already possess such a protocol: &jep0004;. In addition, we possess a way to define common fields used in data forms: &jep0068;. Using these building blocks, we can define some best practices for extending service discovery results.

+

Developers periodically wonder why &xep0030; does not include more bits of information. For example, why does the <identity/> element not include a 'description' attribute, and can we add one now? The answer is: well, it just doesn't, and at this point it's too late to make further changes (since XEP-0030 is Final). So the best approach is to specify a well-defined extension mechanism.

+

Let us consider an example. A &xep0045; room might want to include additional information in its service discovery results, such as the full room description, the current discussion topic (room subject), the number of occupants in the room, and the JID of the room owner.

+

Adding one new attribute to the service discovery schema (even if that were an option) would not solve the problem, since a MUC service might want to provide certain bits of information, whereas a &xep0060; service might want to provide other bits.

+

A better solution would be to include extended information qualified by a namespace that provides a way to flexibly define structured data formats. Thankfully, we already possess such a protocol: &xep0004;. In addition, we possess a way to define common fields used in data forms: &xep0068;. Using these building blocks, we can define some best practices for extending service discovery results.

If an entity desires to provide extended information about itself in an IQ results stanza within the context of the Service Discovery protocol, it SHOULD do so by including each bit of information as the XML character data of the <value/> child of a distinct <field/> element, with the entire set of fields contained within an <x/> element of type "result" qualified by the 'jabber:x:data' namespace; this <x/> element SHOULD be a child of the <query/> element qualified by the 'http://jabber.org/protocol/disco#info' namespace. Thus the IQ result SHOULD be of the following form:

@@ -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 Jabber Enhancement Proposal and registered in accordance with the rules defined in JEP-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 Jabber Software Foundation, they SHOULD be described in the relevant Jabber Enhancement Proposal 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,15 +156,15 @@ -

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 Jabber 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 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.

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

 -

This JEP requires no interaction with &IANA;.

+

This document requires no interaction with &IANA;.

 - -

This JEP requires no interaction with the ®ISTRAR;; however, JEPs following the best practices defined herein may register FORM_TYPEs and field values with the Jabber Registrar.

+ +

This document requires no interaction with the ®ISTRAR;; however, specifications following the best practices defined herein may register FORM_TYPEs and field values with the XMPP Registrar.

 - + diff --git a/xep-0129.xml b/xep-0129.xml index 413fb982..d8b9d118 100644 --- a/xep-0129.xml +++ b/xep-0129.xml @@ -1,13 +1,13 @@ - + %ents; ]> - - + +
WebDAV File Transfers - This JEP specifies best practices for completing Jabber file transfers using WebDAV. + This document specifies best practices for completing Jabber file transfers using WebDAV. &LEGALNOTICE; 0129 Deferred @@ -16,9 +16,9 @@ XMPP Core RFC 2518 - JEP-0030 - JEP-0066 - JEP-0070 + XEP-0030 + XEP-0066 + XEP-0070 @@ -39,11 +39,11 @@
-

&jep0096; defines mechanisms for transferring files between Jabber users, and defines the preferred approach for file transfers in Jabber applications. Unfortunately, the mechanisms defined therein require that both the sender and recipient be online at the same time. However, sometimes it is desirable for the sender to initiate a file transfer while the recipient is offline. One way to make this possible is for the sender to upload the file to a unique URL, then inform the recipient of the URL. The sender could do this by uploading the file to his or her own web server, but not everyone has their own web server. Fortunately, there is a well-defined protocol for such file management operations: a set of HTTP extensions known as WebDAV and defined in &rfc2518;.

-

The use case in which the recipient is offline is the main driver behind this JEP. Another WebDAV use case presents itself in environments that use, or even require, WebDAV for file transfers using other protocols (e.g., files attached to email messages). The usual rationale for such deployments is virus-checking: the file is put onto the WebDAV server (either by an end-user or a script that, for example, strips attached files off email messages) and then checked for viruses; only after the virus check successfully completes is the recipient allowed to retrieve the file. A further benefit of such deployments is that it enables the sender to provide the file to multiple recipients. Thus the approach defined herein provides the added benefit of being usable in generic WebDAV environments as well.

+

&xep0096; defines mechanisms for transferring files between Jabber users, and defines the preferred approach for file transfers in Jabber applications. Unfortunately, the mechanisms defined therein require that both the sender and recipient be online at the same time. However, sometimes it is desirable for the sender to initiate a file transfer while the recipient is offline. One way to make this possible is for the sender to upload the file to a unique URL, then inform the recipient of the URL. The sender could do this by uploading the file to his or her own web server, but not everyone has their own web server. Fortunately, there is a well-defined protocol for such file management operations: a set of HTTP extensions known as WebDAV and defined in &rfc2518;.

+

The use case in which the recipient is offline is the main driver behind this document. Another WebDAV use case presents itself in environments that use, or even require, WebDAV for file transfers using other protocols (e.g., files attached to email messages). The usual rationale for such deployments is virus-checking: the file is put onto the WebDAV server (either by an end-user or a script that, for example, strips attached files off email messages) and then checked for viruses; only after the virus check successfully completes is the recipient allowed to retrieve the file. A further benefit of such deployments is that it enables the sender to provide the file to multiple recipients. Thus the approach defined herein provides the added benefit of being usable in generic WebDAV environments as well.

 -

This JEP addresses the following requirements:

+

This document addresses the following requirements:

  1. Enable file transfers when recipient is offline.
  2. Use WebDAV for file puts and gets.
    3. @@ -51,11 +51,11 @@ -

    This JEP inherits terms from RFC 2518, &rfc2616;, and &rfc2617;.

    +

    This document inherits terms from RFC 2518, &rfc2616;, and &rfc2617;.

         -

    In order to discover a WebDAV server that supports this protocol, a client SHOULD use &jep0030;. Support for this protocol MUST be advertised by means of a service discovery feature named "http://jabber.org/protocol/webdav-filexfer". An example of the discovery flow is shown below.

    +

    In order to discover a WebDAV server that supports this protocol, a client SHOULD use &xep0030;. Support for this protocol MUST be advertised by means of a service discovery feature named "http://jabber.org/protocol/webdav-filexfer". An example of the discovery flow is shown below.

    -

    Because the WebDAV server supports &jep0070;, the initial request fails (since the user did not provide Jabber authentication).

    +

    Because the WebDAV server supports &xep0070;, the initial request fails (since the user did not provide Jabber authentication).

    -

    Upon receipt of the HEAD request, the server then proceeds to verify the request using the x-xmpp-auth mechanism defined in JEP-0070. If the verification successfully completed, the server MAY cache further operations on this particular URL for the duration of the HTTP connection. It is recommended that clients keep the HTTP connection open, in accordance with HTTP/1.1 semantics.

    +

    Upon receipt of the HEAD request, the server then proceeds to verify the request using the x-xmpp-auth mechanism defined in XEP-0070. If the verification successfully completed, the server MAY cache further operations on this particular URL for the duration of the HTTP connection. It is recommended that clients keep the HTTP connection open, in accordance with HTTP/1.1 semantics.

    In the "happy" path, the server responds that the requested URL was not found.

    ]]> -

    Now that the file is available via WebDAV and the client has specified what Jabber IDs may access the URL, the sender sends a message to the target user(s) containing the URL of the file, encoded using &jep0066; to ensure backwards compatibility. (The example below shows the file being sent to multiple users using the &jep0033; protocol.)

    +

    Now that the file is available via WebDAV and the client has specified what Jabber IDs may access the URL, the sender sends a message to the target user(s) containing the URL of the file, encoded using &xep0066; to ensure backwards compatibility. (The example below shows the file being sent to multiple users using the &xep0033; protocol.)

    @@ -198,7 +198,7 @@ Host: files.shakespeare.lit Authorization: xmpp-auth (base64 encoded JID; juliet@capulet.com) ]]> -

    The server then checks to ensure that the provided JID is on the jidlist property, and then authorizes the user via JEP-0070; if a JID not on the jidlist attempts to access the file, the server MUST return an HTTP 403 (Forbidden) error. On completion, the server then allows the file to be retrieved.

    +

    The server then checks to ensure that the provided JID is on the jidlist property, and then authorizes the user via XEP-0070; if a JID not on the jidlist attempts to access the file, the server MUST return an HTTP 403 (Forbidden) error. On completion, the server then allows the file to be retrieved.

     -

    See RFC 2518, XMPP Core, and JEP-0070 for security considerations related to those protocols, which are used by the profile defined herein. The initiating client MUST ensure that appropriate access controls are specified, normally by performing a PROPPATCH request to set the list of Jabber IDs authorized to retrieve the file. The server MUST NOT allow access to the file until access controls have been specified. In addition, the server MUST NOT allow access to the file by any unauthorized entity.

    +

    See RFC 2518, XMPP Core, and XEP-0070 for security considerations related to those protocols, which are used by the profile defined herein. The initiating client MUST ensure that appropriate access controls are specified, normally by performing a PROPPATCH request to set the list of Jabber IDs authorized to retrieve the file. The server MUST NOT allow access to the file until access controls have been specified. In addition, the server MUST NOT allow access to the file by any unauthorized entity.

     -

    This JEP requires no interaction with &IANA;.

    +

    This document requires no interaction with &IANA;.

     -

    Upon advancement of this JEP to a status of Active, the ®ISTRAR; shall add the string "http://jabber.org/protocol/webdav-filexfer" to its registry of service discovery features.

    +

    Upon advancement of this document to a status of Active, the ®ISTRAR; shall add the string "http://jabber.org/protocol/webdav-filexfer" to its registry of service discovery features.

     - +