The HTTP Client responds with an Authorization Request as defined in RFC 2616. The following rules apply:
The Authorization Request process is described in the following subsections.
This document requires no interaction with &IANA;.
The ®ISTRAR; includes "http://jabber.org/protocol/http-auth" in its registry of protocol namespaces.
This JEP defines methods for exchanging instant messages that contain lightweight text markup. In the context of this JEP, "lightweight text markup" is to be understood as a combination of minimal structural elements and presentational styles that can easily be rendered on a wide variety of devices without requiring a full rich-text rendering engine such as a web browser. Examples of lightweight text markup include basic text blocks (e.g., paragraphs), lists, hyperlinks, image references, and font styles (e.g., sizes and colors).
+This document defines methods for exchanging instant messages that contain lightweight text markup. In the context of this document, "lightweight text markup" is to be understood as a combination of minimal structural elements and presentational styles that can easily be rendered on a wide variety of devices without requiring a full rich-text rendering engine such as a web browser. Examples of lightweight text markup include basic text blocks (e.g., paragraphs), lists, hyperlinks, image references, and font styles (e.g., sizes and colors).
In the past, there have existed several incompatible methods within the Jabber community for exchanging instant messages that contain lightweight text markup. The most notable such methods have included derivatives of &w3xhtml; as well as of &rtf;.
-Although it is sometimes easier for client developers to implement RTF support (this is especially true on certain Microsoft Windows operating systems), there are several reasons (consistent with the &jep0134;) for the &JSF; to avoid the use of RTF in developing a protocol for lightweight text markup. Specifically:
+Although it is sometimes easier for client developers to implement RTF support (this is especially true on certain Microsoft Windows operating systems), there are several reasons (consistent with the &xep0134;) for the &JSF; to avoid the use of RTF in developing a protocol for lightweight text markup. Specifically:
Therefore, this JEP defines support for lightweight text markup in the form of an XMPP extension that encapsulates content defined by an XHTML 1.0 Integration Set that we label "XHTML-IM". The remainder of this JEP discusses lightweight text markup in terms of XHTML 1.0 only and does not further consider RTF or other technologies.
+Therefore, this document defines support for lightweight text markup in the form of an XMPP extension that encapsulates content defined by an XHTML 1.0 Integration Set that we label "XHTML-IM". The remainder of this document discusses lightweight text markup in terms of XHTML 1.0 only and does not further consider RTF or other technologies.
HTML was originally designed for authoring and presenting stuctured documents on the World Wide Web, and was subsequently extended to handle more advanced functionality such as image maps and interactive forms. However, the requirements for publishing documents (or developing transactional websites) for presentation by dedicated XHTML clients on traditional computers or small-screen devices are fundamentally different from the requirements for lightweight text markup of instant messages; for this reason, only a reduced set of XHTML features is needed for XHTML-IM. In particular:
@@ -186,9 +186,9 @@IM clients are not XHTML clients: their primary purpose is not to read pre-existing XHTML documents, but to read and generate relatively large numbers of fairly small instant messages.
The underlying context for XHTML content in Jabber/XMPP instant messaging is provided not by a full XHTML document, but by an XML stream, and specifically by a message stanza within that stream. Thus the <head/> element and all its children are unnecessary. Only the <body/> element and some of its children are appropriate for use in instant messaging.
The XHTML content that is read by one's IM client is normally generated on the fly by one's conversation partner (or, to be precise, by his or her IM client). Thus there is an inherent limit to the sophistication of the XHTML markup involved. Even in normal XHTML documents, fairly basic structural and rendering elements such as definition lists, abbreviations, addresses, and computer input handling (e.g., <kbd/> and <var/>) are relatively rare. There is little or no foreseeable need for such elements within the context of instant messaging.
The foregoing is doubly true of more advanced markup such as tables, frames, and forms (however, there exists an XMPP extension that provides an instant messaging equivalent of the latter, as defined in &jep0004;).
The foregoing is doubly true of more advanced markup such as tables, frames, and forms (however, there exists an XMPP extension that provides an instant messaging equivalent of the latter, as defined in &xep0004;).
Although ad-hoc styles are useful for messaging (by means of the 'style' attribute), full support for &w3css; (defined by the <style/> element or a standalone .css file, and implemented via the 'class' attribute) would be overkill since many CSS1 properties (e.g., box, classification, and text properties) were developed especially for sophisticated page layout.
Background images, audio, animated text, layers, applets, scripts, and other multimedia content types are unnecessary, especially given the existence of XMPP extensions such as &jep0096;.
Background images, audio, animated text, layers, applets, scripts, and other multimedia content types are unnecessary, especially given the existence of XMPP extensions such as &xep0096;.
Content transformations such as those defined by &w3xslt; must not be necessary in order for an instant messaging application to present lightweight text markup to an end user.
As explained below, some of these requirements are addressed by the definition of the XHTML-IM Integration Set itself, while others are addressed by a recommended "profile" for that Integration Set in the context of instant messaging applications.
@@ -222,7 +222,7 @@This section defines an XHTML 1.0 Integration Set for use in the context of instant messaging. Given its intended usage, we label it "XHTML-IM".
-Modularization of XHTML provides the ability to formally define subsets of XHTML 1.0 via the concept of "modularization" (which may be familiar from &w3xhtmlbasic;). Many of the defined modules are not necessary or useful in the context of instant messaging, and in the context of Jabber/XMPP instant messaging specifically some modules have been superseded by well-defined XMPP extensions. This JEP specifies that XHTML-IM shall be based on the following XHTML 1.0 modules:
+Modularization of XHTML provides the ability to formally define subsets of XHTML 1.0 via the concept of "modularization" (which may be familiar from &w3xhtmlbasic;). Many of the defined modules are not necessary or useful in the context of instant messaging, and in the context of Jabber/XMPP instant messaging specifically some modules have been superseded by well-defined XMPP extensions. This document specifies that XHTML-IM shall be based on the following XHTML 1.0 modules:
Although a compliant implementation MAY generate or process other style properties defined in CSS1, such behavior is NOT RECOMMENDED by this JEP.
+Although a compliant implementation MAY generate or process other style properties defined in CSS1, such behavior is NOT RECOMMENDED by this document.
Here's my .plan for today:
Here's my .plan for today:
This section describes methods for discovering whether a Jabber client or other XMPP entity supports the protocol defined herein.
The primary means of discovering support for XHTML-IM is &jep0030;.
+The primary means of discovering support for XHTML-IM is &xep0030;.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
This specification formalizes and extends earlier work by Jeremie Miller and Julian Missig on XHTML formatting of Jabber messages. Many thanks to Shane McCarron for his assistance regarding XHTML modularization and conformance issues. Thanks also to contributors on the Standards-JIG list for their feedback and suggestions.
The usual architecture of XMPP is described in Section 2 of RFC 3920. In essence, XMPP is most commonly deployed using a client-server (or logical peer-to-peer) architecture quite similar to that of the email system, except that XMPP does not have multiple hops between servers, enforces domain names to prevent address spoofing, and enables channel encryption (via TLS) and authentication (via SASL) between client and server as well as among servers.
-The binding of SOAP to XMPP assumes that most SOAP-enabled XMPP entities will be implemented as XMPP clients that communicate with other entities as logical peers. However, in order to deploy more scalable services, such entities could also be implemented as server-side components (see &jep0114;) or even as special-purpose XMPP servers.
-The SOAP specification defines the concepts of "SOAP intermediary" and "ultimate SOAP receiver" (see Section 1.5.3 of SOAP Version 1.2 Part 1). In general, this specification assumes that XMPP entities that support the SOAP XMPP Binding will be ultimate SOAP receivers, since SOAP intermediaries tend to be artifacts of the existing SOAP bindings (HTTP and SMTP) rather than applicable to all possible bindings. SOAP intermediaries are usually deployed in order to (1) cross trust boundaries in protocols that do not enforce domain names or authenticate end-points, (2) ensure scalability, (3) secure messages sent over unencrypted channels, and (4) provide message tracing. However, these issues are addressed natively in XMPP (e.g., channel encryption is defined in RFC 3920), in XMPP extensions (e.g., message tracing is defined in &jep0079;), or in deployment decisions such as business level agreements between XMPP domains. One final justification for SOAP intermediaries is to act as gateways between different transport mechanisms (e.g., between HTTP and SMTP), and XMPP entities may well be SOAP intermediaries for that reason. For further details about gateways between XMPP and other SOAP bindings, refer to the Implementation Notes section of this document.
+The binding of SOAP to XMPP assumes that most SOAP-enabled XMPP entities will be implemented as XMPP clients that communicate with other entities as logical peers. However, in order to deploy more scalable services, such entities could also be implemented as server-side components (see &xep0114;) or even as special-purpose XMPP servers.
+The SOAP specification defines the concepts of "SOAP intermediary" and "ultimate SOAP receiver" (see Section 1.5.3 of SOAP Version 1.2 Part 1). In general, this specification assumes that XMPP entities that support the SOAP XMPP Binding will be ultimate SOAP receivers, since SOAP intermediaries tend to be artifacts of the existing SOAP bindings (HTTP and SMTP) rather than applicable to all possible bindings. SOAP intermediaries are usually deployed in order to (1) cross trust boundaries in protocols that do not enforce domain names or authenticate end-points, (2) ensure scalability, (3) secure messages sent over unencrypted channels, and (4) provide message tracing. However, these issues are addressed natively in XMPP (e.g., channel encryption is defined in RFC 3920), in XMPP extensions (e.g., message tracing is defined in &xep0079;), or in deployment decisions such as business level agreements between XMPP domains. One final justification for SOAP intermediaries is to act as gateways between different transport mechanisms (e.g., between HTTP and SMTP), and XMPP entities may well be SOAP intermediaries for that reason. For further details about gateways between XMPP and other SOAP bindings, refer to the Implementation Notes section of this document.
In order to determine whether a potential responding entity supports the SOAP XMPP Binding, a requesting entity SHOULD send a &jep0030; information request to the potential responding entity:
+In order to determine whether a potential responding entity supports the SOAP XMPP Binding, a requesting entity SHOULD send a &xep0030; information request to the potential responding entity:
Examples of both approaches are provided below, encapsulating the SOAP message examples (a travel reservation flow) to be found in &w3soap0;.
The transport with &IQ; stanzas is performed in a way similar to that described for XML-RPC in &jep0009;. Request envelopes are carried by &IQ; stanzas of type "set", and answer envelopes by &IQ; stanzas of type "result". SOAP errors are encoded with standard SOAP envelopes, and returned in stanzas of type "error" with appropriate codes in order to distinguish them from errors specific to the XMPP transport layer (see Error Handling for details).
+The transport with &IQ; stanzas is performed in a way similar to that described for XML-RPC in &xep0009;. Request envelopes are carried by &IQ; stanzas of type "set", and answer envelopes by &IQ; stanzas of type "result". SOAP errors are encoded with standard SOAP envelopes, and returned in stanzas of type "error" with appropriate codes in order to distinguish them from errors specific to the XMPP transport layer (see Error Handling for details).
Each &IQ; stanza of type "set" MUST contain a SOAP envelope as the first-level child element, since it already represents a properly namespaced XML subtree qualified by the 'http://www.w3.org/2003/05/soap-envelope' namespace.
The recommended approaches (file transfer and including a link) are described more fully below.
The recommended method for sending associated data is to use the file transfer protocol described in JEP-0096. Because this is the common and standardized method for XMPP entities to transfer large or binary files outside the XMPP band, it SHOULD be used.
-In particular, the entity that has the file SHOULD advertise the availability of the associated stream using JEP-0137 by including the SI-pub data extension along with the XMPP &MESSAGE; stanza with which the data is associated:
The recommended method for sending associated data is to use the file transfer protocol described in XEP-0096. Because this is the common and standardized method for XMPP entities to transfer large or binary files outside the XMPP band, it SHOULD be used.
+In particular, the entity that has the file SHOULD advertise the availability of the associated stream using XEP-0137 by including the SI-pub data extension along with the XMPP &MESSAGE; stanza with which the data is associated:
For details regarding file transfer and advertising of file transfer stream initiation requests, refer to JEP-0096 and JEP-0137.
+For details regarding file transfer and advertising of file transfer stream initiation requests, refer to XEP-0096 and XEP-0137.
If the file transfer method is not possible (e.g., because file transfer is not implemented or transfer attempts fails), the entity that is sending the associated data MAY as a fallback publish the associated data as a file (e.g., at an HTTP or FTP URL) and include a link to the file as out-of-band content by including the out-of-band data extension along with the XMPP &MESSAGE; stanza with which the data is associated:
Although there is no standard procedure for publishing WSDL documents, usually they are made available through HTTP at some URL discoverable with public registries such as UDDI servers. WSDL descriptions for XMPP bindings MAY follow the same publishing process, or MAY be discoverable through Jabber/XMPP specific mechanisms such as &jep0030; or &jep0060;.
+Although there is no standard procedure for publishing WSDL documents, usually they are made available through HTTP at some URL discoverable with public registries such as UDDI servers. WSDL descriptions for XMPP bindings MAY follow the same publishing process, or MAY be discoverable through Jabber/XMPP specific mechanisms such as &xep0030; or &xep0060;.
The main body of text that addresses the requirements of the W3C with regard to SOAP bindings is provided in the SOAP XMPP Binding section of this document. The current section addresses only the topic of organizational interaction between the W3C and the &JSF; regarding the SOAP XMPP Binding.
As was done with &jep0071;, the SOAP XMPP Binding defined herein has been reviewed informally by one or more appropriate experts from the W3C before the &COUNCIL; advanced it to a status of Draft within the JSF's standards process. Before this specification proceeds to a status of Final within the JSF's standards process, it should undergo a formal review through communication with the W3C's XML Protocol Working Group. To that end, revised versions of this specification will be announced on the W3C's public xml-dist-app@w3.org mailing list.
+As was done with &xep0071;, the SOAP XMPP Binding defined herein has been reviewed informally by one or more appropriate experts from the W3C before the &COUNCIL; advanced it to a status of Draft within the JSF's standards process. Before this specification proceeds to a status of Final within the JSF's standards process, it should undergo a formal review through communication with the W3C's XML Protocol Working Group. To that end, revised versions of this specification will be announced on the W3C's public xml-dist-app@w3.org mailing list.
This specification addresses SOAP 1.2 only. This specification may be superseded or supplemented in the future by a Jabber Enhancement Proposal that defines methods for encapsulating content defined by future versions of SOAP as published by the W3C.
@@ -1047,7 +1047,7 @@SOAP provides its own encoding scheme for errors due to message processing or application execution, and it uses SOAP envelopes for reporting. In the SOAP HTTP Binding, these errors are mapped to corresponding HTTP status codes. In the SOAP XMPP Binding, they are mapped to the catch-all XMPP error of &undefined; along with application-specific error condition elements qualified by the 'http://jabber.org/protocol/soap#fault' namespace (this is consistent with Section 9.3.3 of RFC 3920, see also &jep0086;). The element names of these application-specific error conditions map directly to the SOAP fault codes specified in Section 5.4.6 of SOAP Version 1.2 Part 1.
+SOAP provides its own encoding scheme for errors due to message processing or application execution, and it uses SOAP envelopes for reporting. In the SOAP HTTP Binding, these errors are mapped to corresponding HTTP status codes. In the SOAP XMPP Binding, they are mapped to the catch-all XMPP error of &undefined; along with application-specific error condition elements qualified by the 'http://jabber.org/protocol/soap#fault' namespace (this is consistent with Section 9.3.3 of RFC 3920, see also &xep0086;). The element names of these application-specific error conditions map directly to the SOAP fault codes specified in Section 5.4.6 of SOAP Version 1.2 Part 1.
The following table provides a mapping between SOAP, HTTP, and application-specific XMPP errors.
REQUIRED | ||
JEP-0078: Non-SASL Authentication | +XEP-0078: Non-SASL Authentication | REQUIRED |
JEP-0086: Error Condition Mappings | +XEP-0086: Error Condition Mappings | REQUIRED for servers; RECOMMENDED for clients |
JEP-0030: Service Discovery | +XEP-0030: Service Discovery | REQUIRED |
JEP-0077: In-Band Registration | +XEP-0077: In-Band Registration | REQUIRED for servers; RECOMMENDED for clients |
RFC 3920 requires support for SASL and TLS as must-implement protocols, and that support is not modified herein. Refer to JEP-0078: Non-SASL Authentication for an explanation of the older authentication method still in use by various existing client and server implementations and deployments, as well as the proper order of precedence between SASL authentication (RFC 3920) and non-SASL authentication (JEP-0078).
+RFC 3920 requires support for SASL and TLS as must-implement protocols, and that support is not modified herein. Refer to XEP-0078: Non-SASL Authentication for an explanation of the older authentication method still in use by various existing client and server implementations and deployments, as well as the proper order of precedence between SASL authentication (RFC 3920) and non-SASL authentication (XEP-0078).
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 <acl> element provides the container for the query. It MUST have the three attributes: actor, oper, and target.
The actor attribute is set to the Jabber ID which is attempting to perform an operation. This need not be the JID sending the acl, although it may be. Remember this is to allow for the question, "Can X do Y to Z?", which is a question anyone can ask.
The oper attribute is application-specific and refers to the operation for which a permission check is required (e.g., read/write operations). This also defines the scope of the ACL check, so the implementation is responsible for interpreting the actor and target values based on the value of the 'oper' attribute.
-The target is the object which the actor is trying to perform the operation on. This MUST be a node queryable via &jep0030;.
+The target is the object which the actor is trying to perform the operation on. This MUST be a node queryable via &xep0030;.
Requests MUST be in the form of an empty <acl/> element with ALL the attributes specified. If not all attributes are specified, the request is incomplete and ambiguities arise; therefore the entity receving the request MUST return a "bad request" error to the sender.
Responses MUST be in one of three forms: allowed, denied, error.
The response is inserted into the <acl/> as a child element. If the response is allowed, then <allowed/> is inserted. If the JID is denied then <denied/> is returned. If there is inadequate information then <error/> is used following the standard Jabber error scheme.
@@ -152,10 +152,10 @@To follow.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
As a result of this JEP, the ®ISTRAR; will need to register the 'http://jabber.org/protocol/sac' namespace.
+As a result of this document, the ®ISTRAR; will need to register the 'http://jabber.org/protocol/sac' namespace.
A method is a unit of behavior that makes up part of an object. Methods in JOAP are compatible with &xmlrpc;, as - specified in &jep0009;. In particular, methods have a name, a + specified in &xep0009;. In particular, methods have a name, a return type, and 0 or more parameters, each of which has a type.
The one exception to XML-RPC compatibility is that method @@ -1089,7 +1089,7 @@
Method calls in JOAP are simply XML-RPC calls, as defined in
- JEP-0009. This JEP requires no interaction with the IANA. This protocol defines one new namespace, 'jabber:iq:joap'. Experimental implementations of this protocol should use the
- namespace 'http://www.jabber.org/jeps/jep-0075.html#0.3' to
+ namespace 'http://www.xmpp.org/extensions/xep-0075.html#0.3' to
avoid conflicts with future versions.
Because the 'http://jabber.org/protocol/evil' namespace flags an XML stanza as malicious, it is critically important that an entity appropriately process an XML stanza that contains the evil extension. Mission-critical applications SHOULD ignore any stanzas tagged with the evil extension. Evil servers MAY pass through evil stanzas unmodified. Really evil servers MAY silently delete the evil extension. Jabber entities that are evil to the core SHOULD support channel-level evil as defined in RFC 3514, since this JEP defines per-stanza evil only.
+Because the 'http://jabber.org/protocol/evil' namespace flags an XML stanza as malicious, it is critically important that an entity appropriately process an XML stanza that contains the evil extension. Mission-critical applications SHOULD ignore any stanzas tagged with the evil extension. Evil servers MAY pass through evil stanzas unmodified. Really evil servers MAY silently delete the evil extension. Jabber entities that are evil to the core SHOULD support channel-level evil as defined in RFC 3514, since this document defines per-stanza evil only.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; shall register the 'http://jabber.org/protocol/evil' namespace as a result of this JEP.
+The ®ISTRAR; shall register the 'http://jabber.org/protocol/evil' namespace as a result of this document.
In-band registration must make it possible for an entity to register with a host, cancel an existing registration with a host, or change a password with a host. By "host" is meant either of the following:
If needed, extensibility with regard to information gathered should be done using &jep0004;.
+If needed, extensibility with regard to information gathered should be done using &xep0004;.
The fields defined for the 'jabber:iq:register' namespace are strictly limited to those specified in the schema. If a host needs to gather additional information, JEP-0004: Data Forms ("x:data") SHOULD be used according to the following rules:
+The fields defined for the 'jabber:iq:register' namespace are strictly limited to those specified in the schema. If a host needs to gather additional information, XEP-0004: Data Forms ("x:data") SHOULD be used according to the following rules:
Support for extensibility via Data Forms is RECOMMENDED but is not required for compliance with this JEP.
A given deployment MAY wish to redirect users to another medium (e.g., a website) for registration, rather than allowing in-band registration. The recommended approach is to include only the <instructions/> element rather than the required fields or a data form in the IQ result, as well as a URL encoded using &jep0066; (see the Precedence Order section below for further details).
+A given deployment MAY wish to redirect users to another medium (e.g., a website) for registration, rather than allowing in-band registration. The recommended approach is to include only the <instructions/> element rather than the required fields or a data form in the IQ result, as well as a URL encoded using &xep0066; (see the Precedence Order section below for further details).
As defined herein, the 'jabber:iq:register' namespace supports both the old (HTTP-style) error codes and the extensible error classes and conditions specified in XMPP Core. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both. For mappings of HTTP-style errors to XMPP-style conditions, refer to &jep0086;.
+As defined herein, the 'jabber:iq:register' namespace supports both the old (HTTP-style) error codes and the extensible error classes and conditions specified in XMPP Core. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both. For mappings of HTTP-style errors to XMPP-style conditions, refer to &xep0086;.
In-band registration is usually not included in other messaging protocols (for example, SMTP does not include a method for registering with an email server), often for reasons of security. The registration methods defined herein are known to be insecure and SHOULD NOT be used unless the channel between the registrant and the entity that accepts registration has been secured. For these reasons, the deployment of in-band registration is a policy matter and a given deployment MAY choose to disable in-band registration and password changes. Furthermore, this JEP should be deprecated as soon as a successor protocol is defined and implemented.
@@ -610,15 +610,15 @@This JEP requires no interaction with &IANA;.
The ®ISTRAR; includes the 'jabber:iq:register' namespace in its registry of protocol namespaces.
The Jabber Registrar includes the 'http://jabber.org/features/iq-register' namespace in its registry of stream feature namespaces.
+The XMPP Registrar includes the 'http://jabber.org/features/iq-register' namespace in its registry of stream feature namespaces.
As authorized by &jep0147;, the Jabber Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).
+As authorized by &xep0147;, the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).
As described below, the registered querytypes for registration management are "register" and "unregister".
The 'jabber:iq:register' namespace include a mechanism for creating a registration. The registered querytype for doing so is "register".
@@ -654,7 +654,7 @@ xmpp:marlowe.shakespeare.lit?register
jabber:iq:register
- JEP-0077
+ XEP-0077
Standardization of fields related to registration use case.
jabber:iq:register:cancel
- JEP-0077
+ XEP-0077
Standardization of fields related to cancellation use case.
jabber:iq:register:cancel
- JEP-0077
+ XEP-0077
Standardization of fields related to change password use case.
The protocol documented by this schema is defined in
- JEP-0077: http://www.jabber.org/jeps/jep-0077.html
+ XEP-0077: http://www.xmpp.org/extensions/xep-0077.html
@@ -881,7 +881,7 @@ xmpp:marlowe.shakespeare.lit?unregister
The protocol documented by this schema is defined in
- JEP-0077: http://www.jabber.org/jeps/jep-0077.html
+ XEP-0077: http://www.xmpp.org/extensions/xep-0077.html
@@ -897,4 +897,4 @@ xmpp:marlowe.shakespeare.lit?unregister
]]>
Changed SHOULD to MUST regarding priority of SASL (RFC 3920) over jabber:iq:auth (JEP-0078).
Changed SHOULD to MUST regarding priority of SASL (RFC 3920) over jabber:iq:auth (XEP-0078).
Moved change password use case to JEP-0077.
Moved change password use case to XEP-0077.
Note Well: The protocol specified herein has been deprecated in favor of SASL authentication as specified in &rfc3920;.
-Jabber technologies have long included a wire protocol that enables a client to authenticate with a server.
Jabber technologies have long included a wire protocol that enables a client to authenticate with a server.
The 'jabber:iq:auth' method specified herein has been deprecated. However, because it will take some time for existing implementations and deployments to be upgraded to SASL, client and server software implementations still need to include support for 'jabber:iq:auth' in order to interoperate, and this document provides canonical documentation of the 'jabber:iq:auth' method. Nevertheless, implementation and deployment of SASL authentication is strongly recommended, since the 'jabber:iq:auth' method will eventually be obsoleted entirely.
Note: This JEP does not include the so-called "zero-knowledge" method; that method did not provide stronger security than digest authentication and thus is unnecessary.
+Note: This document does not include the so-called "zero-knowledge" method; that method did not provide stronger security than digest authentication and thus is unnecessary.
As defined herein, the 'jabber:iq:auth' namespace supports both the old (HTTP-style) error codes and the extensible error classes and conditions specified in RFC 3920. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both.
In accordance with Section 8 of &jep0001;, on 2004-10-20 this JEP was advanced to a status of Final with the understanding that it would expire in six months. On 2006-09-13, the Jabber Council changed the status of this JEP to Deprecated. The Jabber Council will review this JEP every six months to determine whether to change its status to Obsolete or to extend the expiration date for an additional six months; this process will continue until the JEP is obsoleted. For the latest expiration date, refer to the JEP Information block at the beginning of this document.
+In accordance with Section 8 of &xep0001;, on 2004-10-20 this document was advanced to a status of Final with the understanding that it would expire in six months. On 2006-09-13, the Jabber Council changed the status of this document to Deprecated. The Jabber Council will review this document every six months to determine whether to change its status to Obsolete or to extend the expiration date for an additional six months; this process will continue until the document is obsoleted. For the latest expiration date, refer to the XEP Information block at the beginning of this document.
Use of the 'jabber:iq:auth' method for client-server authentication is not as secure as SASL authentication (defined in RFC 3920). If both client and server implement SASL, they MUST use SASL. If a client attempts to authenticate using the 'jabber:iq:auth' namespace after an attempt at SASL authentication fails, the server MUST refuse the 'jabber:iq:auth' attempt by returning a <policy-violation/> stream error to the client.
@@ -293,14 +293,14 @@Authentication using the 'jabber:iq:auth' method is known to be less secure than SASL authentication, which is one reason why the 'jabber:iq:auth' method has been deprecated.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; includes the 'jabber:iq:auth' namespace in its registry of protocol namespaces.
The Jabber Registrar includes the 'http://jabber.org/features/iq-auth' namespace in its registry of stream feature namespaces.
+The XMPP Registrar includes the 'http://jabber.org/features/iq-auth' namespace in its registry of stream feature namespaces.
This JEP defines a protocol that enables an end-point entity to specify additional delivery semantics for an XMPP <message/> stanza. This protocol is typically used by clients to inform the receiving server how to deliver a particular stanza, such as providing an expiration time or a resource-matching strategy.
+This document defines a protocol that enables an end-point entity to specify additional delivery semantics for an XMPP <message/> stanza. This protocol is typically used by clients to inform the receiving server how to deliver a particular stanza, such as providing an expiration time or a resource-matching strategy.
The built-in delivery semantics for <message/> stanzas (defined in &xmppcore; and, for instant messaging applications, also in &xmppim;) are adequate for most current applications. However, there are various cases where more stringent delivery semantics are necessary. The most common cases discussed in this JEP are:
+The built-in delivery semantics for <message/> stanzas (defined in &xmppcore; and, for instant messaging applications, also in &xmppim;) are adequate for most current applications. However, there are various cases where more stringent delivery semantics are necessary. The most common cases discussed in this document are:
This protocol is mostly handled by the server or servers processing the <message/>. The protocol consists of a list of rules, with conditions and actions for each rule. Upon receipt of an appropriately marked message, the server interprets the rules in the order they are received, looking for met conditions. When a condition is met, the action for that rule is executed, and message processing stops.
-Each rule is flagged for the scope it applies to, whether it be the overall route, or for each hop in the route. Additionally, while this JEP defines a default set of conditions and actions, the protocol is extensible enough to allow for more to be defined in the future.
+Each rule is flagged for the scope it applies to, whether it be the overall route, or for each hop in the route. Additionally, while this document defines a default set of conditions and actions, the protocol is extensible enough to allow for more to be defined in the future.
The namespace for the protocol is "http://jabber.org/protocol/amp".
Sending entities that wish to use AMP SHOULD discover support for this protocol (using &jep0030;) along the intended path. Typically, this would involve sending disco#info queries to the sending entity's own server and the server of the intended recipient. The results of these queries MAY be cached for up to 24 hours, unless otherwise expired.
+Sending entities that wish to use AMP SHOULD discover support for this protocol (using &xep0030;) along the intended path. Typically, this would involve sending disco#info queries to the sending entity's own server and the server of the intended recipient. The results of these queries MAY be cached for up to 24 hours, unless otherwise expired.
If a server supports Advanced Message Processing, it MUST report that by including a service discovery feature of "http://jabber.org/protocol/amp" in the service discovery information result that it returns to the requesting entity.
The preceding sections of this JEP define the general behavior regarding AMP. This section outlines how <rule/> action and condition sets are specified. It also provides defined action and condition sets; these action and condition sets SHOULD be supported by any implementation of Advanced Message Processing, but support for any given action or condition set it not required. (Note: The action and condition sets defined herein may be supplemented in the future via registration of additional action and condition sets with the Jabber Registrar.)
+The preceding sections of this document define the general behavior regarding AMP. This section outlines how <rule/> action and condition sets are specified. It also provides defined action and condition sets; these action and condition sets SHOULD be supported by any implementation of Advanced Message Processing, but support for any given action or condition set it not required. (Note: The action and condition sets defined herein may be supplemented in the future via registration of additional action and condition sets with the XMPP Registrar.)
The definition of a <rule/> condition MUST provide the following information:
The condition defines how or when a particular rule is triggered. The value of the condition attribute determines what the contents of the <rule/> mean.
-The following conditions are defined by this JEP and SHOULD be supported by any implementation.
+The following conditions are defined by this document and SHOULD be supported by any implementation.
In the following sections, the terms "content" and "contents" refers to the XML character data contained by the <rule/> element.
The "deliver" condition is used to ensure delivery (or non-delivery) in one of five ways:
@@ -364,8 +364,8 @@This condition MAY be applied to each "hop" in the server route.
The "expire-at" condition is used to ensure delivery before an absolute point in time. Naturally, this does not guarantee
The content of the 'value' attribute specifies some point after the exact moment the message is sent; the content MUST be a DateTime as specified in &jep0082;, and the timezone MUST be UTC.
+The "expire-at" condition is used to ensure delivery before an absolute point in time. Naturally, this does not guarantee
The content of the 'value' attribute specifies some point after the exact moment the message is sent; the content MUST be a DateTime as specified in &xep0082;, and the timezone MUST be UTC.
The condition is met if the message would be delivered to the recipient after the specified datetime. To determine the datetime to compare to, the processor first determines if and when a message can be dispatched (e.g. not stored offline). The processor then records this datetime, and compares it with the specified datetime. If the current datetime is on or after that specified, the condition is met.
This condition MAY be applied to each "hop" in the server route.
The condition is met if the resource for the actual destination JID matches the intended JID using the above rules. For instance, if a message is intended for "romeo@montague.net/work" with the "match-resource" condition of "exact", the condition is met if the message can be immediately delivered only to "romeo@montague.net/work".
For purposes of this condition, an intended JID with no resource has the following behavior:
This condition MUST NOT be applied to each "hop" in the server route, only at the edge servers. If an <amp/> element includes this condition and also indicates that it should be processed per hop, this <rule/> shall be ignored.
@@ -406,7 +406,7 @@The action defines what occurs when a particular rule is triggered. The value of the action attribute determines the behavior if the rule's condition is met.
-The following actions are defined by this JEP.
+The following actions are defined by this document.
The "alert" action triggers a reply &MESSAGE; stanza to the sending entity. This &MESSAGE; stanza MUST contain the element <amp status='alert'/>, which itself contains the <rule/> that triggered this action. In all other respects, this action behaves as "drop".
Each semantic rule is specified with a <rule/> element. This element possesses attributes for the condition, value, and action.
- The 'action' attribute defines the result for this rule. This attribute MUST be present, and MUST be either a value defined in the Defined Actions section, or one registered with the Jabber Registrar.
- The 'condition' attribute defines the overall condition this rule applies to. This attribute MUST be present, and MUST be either a value defined in the Defined Conditions section, or one registered with the Jabber Registrar.
+ The 'action' attribute defines the result for this rule. This attribute MUST be present, and MUST be either a value defined in the Defined Actions section, or one registered with the XMPP Registrar.
+ The 'condition' attribute defines the overall condition this rule applies to. This attribute MUST be present, and MUST be either a value defined in the Defined Conditions section, or one registered with the XMPP Registrar.
The 'value' attribute defines how the condition is matched. This attribute MUST be present, and MUST NOT be an empty string (""). The interpretation of this attribute's value is determined by the 'condition' attribute.
The &MESSAGE; stanza is nearly ideal for data transport, but to ensure reliability it is often desirable that such messages not be delivered to any resource but that specified. To facilitate this, the sending entity includes a <rule action='drop' condition='match-resource' value='other'/> (if failure notification is unnecessary) or <rule action='error' condition='match-resource' value='other'/> (if failure notification is required). The following example illustrates this using &jep0047;:
+The &MESSAGE; stanza is nearly ideal for data transport, but to ensure reliability it is often desirable that such messages not be delivered to any resource but that specified. To facilitate this, the sending entity includes a <rule action='drop' condition='match-resource' value='other'/> (if failure notification is unnecessary) or <rule action='error' condition='match-resource' value='other'/> (if failure notification is required). The following example illustrates this using &xep0047;:
This section shows examples of the error conditions described in the previous section (for information regarding mapping of XMPP error conditions to Jabber error codes, refer to &jep0086;).
+This section shows examples of the error conditions described in the previous section (for information regarding mapping of XMPP error conditions to Jabber error codes, refer to &xep0086;).
No interaction with &IANA; is necessary as a result of this JEP.
+No interaction with &IANA; is necessary as a result of this document.
The ®ISTRAR; includes 'http://jabber.org/protocol/amp' and 'http://jabber.org/protocol/amp#errors' in its registry of protocol namespaces.
The Jabber Registrar includes the 'http://jabber.org/features/amp' namespace in its registry of stream feature namespaces.
+The XMPP Registrar includes the 'http://jabber.org/features/amp' namespace in its registry of stream feature namespaces.
The Jabber Registrar includes 'http://jabber.org/protocol/amp' in its registry of well-known Service Discovery nodes.
+The XMPP Registrar includes 'http://jabber.org/protocol/amp' in its registry of well-known Service Discovery nodes.
The Jabber Registrar maintains a registry of AMP <rule/> conditions (see <http://www.jabber.org/registrar/amp-conditions.html>).
+The XMPP Registrar maintains a registry of AMP <rule/> conditions (see <http://www.jabber.org/registrar/amp-conditions.html>).
values that result in message processing
- the document (e.g., JEP) in which this condition is specified
+ the document (e.g., XEP) in which this condition is specified
]]>
The registrant may register more than one condition at a time, each contained in a separate <condition/> element.
@@ -1080,19 +1080,19 @@ the message cannot be delivered at all, or (5) the value is "stored" and the message can be stored for later delivery. -The Jabber Registrar maintains a registry of AMP <rule/> actions (see <http://www.jabber.org/registrar/amp-actions.html>).
+The XMPP Registrar maintains a registry of AMP <rule/> actions (see <http://www.jabber.org/registrar/amp-actions.html>).
the value of the 'action' attribute
the namespace to be used as a service discovery feature
the expected behavior if the rule is triggered
- the document (e.g., JEP) in which this action is specified
+ the document (e.g., XEP) in which this action is specified
]]>
The registrant may register more than one action at a time, each contained in a separate <action/> element.
@@ -1138,7 +1138,7 @@ The message is silently discarded but an alert is returned to the sender. -Thanks to Marshall Rose and Craig Kaes for their comments.