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;.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
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:
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.
&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.
&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:
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:
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 considered
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.
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").
]]>
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:
It is becoming increasingly important to define a robust, extensible format for describing entities on the Jabber network. Such a format should be:
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.
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.
&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.
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.
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.
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: 175A 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).
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;.
| Code | @@ -971,7 +971,7 @@ Content-Length: 68 xmlns='http://jabber.org/protocol/httpbind'/>]]>
|---|
| Infobit Key | @@ -260,13 +260,13 @@
|---|
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.
To follow.
This document requires no interaction with &IANA;.
No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this specification.
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:
Both methods are described below.
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.
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.
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.
&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:
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.