One distinguishing characteristic of Jabber technologies from their earliest days has been the existence of gateways (also called "transports") between the Jabber network and legacy instant messaging services such as AOL Instant Messenger (AIM), ICQ, MSN Messenger, and Yahoo! Messenger. Surprisingly, the recommended behavior of such gateways, including the protocol elements used by a client to interact with a gateway, has never been fully documented. This JEP attempts to fill that void by codifying best practices for gateway interaction.
-Note well that this JEP defines protocol usage with regard to client proxy gateways, i.e., gateways that "masquerade" as a client on a non-Jabber IM service. Gateways that perform direct protocol translation without proxying for an account on a non-Jabber service are not addressed in this JEP. Furthermore, this JEP does not define any interaction between a gateway and the non-Jabber service, only interactions between a Jabber client and the gateway. Although what happens on the other side of the gateway is highly dependent on the nature of the legacy service, gateways should at least provide a common interface on the Jabber side of the gateway so that Jabber clients can be written in a consistent fashion.
+One distinguishing characteristic of Jabber technologies from their earliest days has been the existence of gateways (also called "transports") between the Jabber network and legacy instant messaging services such as AOL Instant Messenger (AIM), ICQ, MSN Messenger, and Yahoo! Messenger. Surprisingly, the recommended behavior of such gateways, including the protocol elements used by a client to interact with a gateway, has never been fully documented. This document attempts to fill that void by codifying best practices for gateway interaction.
+Note well that this document defines protocol usage with regard to client proxy gateways, i.e., gateways that "masquerade" as a client on a non-Jabber IM service. Gateways that perform direct protocol translation without proxying for an account on a non-Jabber service are not addressed in this document. Furthermore, this document does not define any interaction between a gateway and the non-Jabber service, only interactions between a Jabber client and the gateway. Although what happens on the other side of the gateway is highly dependent on the nature of the legacy service, gateways should at least provide a common interface on the Jabber side of the gateway so that Jabber clients can be written in a consistent fashion.
| Gateway | -A service on the Jabber network that translates between the Jabber/XMPP protocols and the protocol used by a Legacy Service; in the context of this JEP, by "gateway" we mean a "client proxy service" that acts as a client with regard to a Legacy Service and thereby "masquerades" as a user on such a service. | +A service on the Jabber network that translates between the Jabber/XMPP protocols and the protocol used by a Legacy Service; in the context of this document, by "gateway" we mean a "client proxy service" that acts as a client with regard to a Legacy Service and thereby "masquerades" as a user on such a service. |
| Jabber User | @@ -128,7 +128,7 @@
The requirements defined by this JEP are captured in two sets of use cases: one set from the perspective of the Jabber User, and a smaller set from the perspective of the Legacy User who wants to interact with the Jabber User.
+The requirements defined by this document are captured in two sets of use cases: one set from the perspective of the Jabber User, and a smaller set from the perspective of the Legacy User who wants to interact with the Jabber User.
The Jabber User use cases are:
While more advanced use cases (e.g., sending files and joining chat rooms) are of inherent interest, they are not covered in this JEP because registration, contact list management, and message exchange define the baseline functionality included in all gateway implementations; future JEPs may address the more advanced use cases.
+While more advanced use cases (e.g., sending files and joining chat rooms) are of inherent interest, they are not covered in this document because registration, contact list management, and message exchange define the baseline functionality included in all gateway implementations; future specifications may address the more advanced use cases.
Jabber User sends IQ-get qualified by the &jep0030; information namespace to the Gateway, and/or IQ-get qualified by the &jep0094; namespace to the Gateway's parent (the latter method is deprecated but still in use).
+Jabber User sends IQ-get qualified by the &xep0030; information namespace to the Gateway, and/or IQ-get qualified by the &xep0094; namespace to the Gateway's parent (the latter method is deprecated but still in use).
Jabber User sends IQ-get qualified by the &jep0077; (jabber:iq:register) namespace to Gateway.
+Jabber User sends IQ-get qualified by the &xep0077; (jabber:iq:register) namespace to Gateway.
User information not verified:
Gateway returns ¬acceptable; error to Jabber User. (For detailed information regarding error conditions, refer to &jep0086;.)
+Gateway returns ¬acceptable; error to Jabber User. (For detailed information regarding error conditions, refer to &xep0086;.)
Naturally, the Jabber User may want to exchange messages with a Legacy User. For the purposes of this JEP, we discuss one-to-one messaging only (i.e., groupchat messages, such as those defined in &jep0045;, are out of scope).
+Naturally, the Jabber User may want to exchange messages with a Legacy User. For the purposes of this document, we discuss one-to-one messaging only (i.e., groupchat messages, such as those defined in &xep0045;, are out of scope).
Unfortunately, usernames on some Legacy Services may allow characters that are disallowed in Jabber usernames as specified by the Nodeprep profile of stringprep defined in RFC 3920. For example, the usernames for a Legacy Service may be of the form <user@domain>, which would result in an illegal JID such as <user@domain@gateway.example.com>.
There are two possible ways to solve this problem:
Gateways and clients SHOULD implement at least one of these protocols; at a minimum, it is RECOMMENDED for gateways and clients to implement the 'jabber:iq:gateway' protocol.
@@ -952,7 +952,7 @@Some legacy services maintain server-side contact lists, which are sent to the gateway when it logs in to the legacy service on behalf of the user. The gateway MAY initiate adding of the legacy contact list items to the user's Jabber roster. Some existing gateways do this by sending a presence stanza of type "subscribed" from the legacy contact's JID (e.g., <LegacyUser@gateway.jabberserver.com>) to the Jabber user; unfortunately, this behavior violates the presence stanza handling rules specified in RFC 3921. Therefore, a gateway SHOULD instead send the legacy contact list items to the Jabber User via the &jep0144; protocol.
+Some legacy services maintain server-side contact lists, which are sent to the gateway when it logs in to the legacy service on behalf of the user. The gateway MAY initiate adding of the legacy contact list items to the user's Jabber roster. Some existing gateways do this by sending a presence stanza of type "subscribed" from the legacy contact's JID (e.g., <LegacyUser@gateway.jabberserver.com>) to the Jabber user; unfortunately, this behavior violates the presence stanza handling rules specified in RFC 3921. Therefore, a gateway SHOULD instead send the legacy contact list items to the Jabber User via the &xep0144; protocol.
The following business rules apply:
@@ -963,7 +963,7 @@A gateway SHOULD map, as best it can, the legacy registration fields onto the fields defined for the 'jabber:iq:register' namespace.
A gateway SHOULD NOT attempt to emulate offline message storage functionality for legacy services that lack such functionality.
Existing gateway implementations do not strictly adhere to the bi-directional nature of Jabber presence notifications, since they do not broadcast presence from the gateway itself to registered users of the gateway, but rather wait for a registered user to send presence to the gateway before sending presence to the user. This sidesteps scalability challenges but may be sub-optimal; while this JEP does not require existing gateways to change their current behavior, it does RECOMMEND that they broadcast presence notifications to registered users in accordance with the standard Jabber presence model. Specifically:
+Existing gateway implementations do not strictly adhere to the bi-directional nature of Jabber presence notifications, since they do not broadcast presence from the gateway itself to registered users of the gateway, but rather wait for a registered user to send presence to the gateway before sending presence to the user. This sidesteps scalability challenges but may be sub-optimal; while this document does not require existing gateways to change their current behavior, it does RECOMMEND that they broadcast presence notifications to registered users in accordance with the standard Jabber presence model. Specifically:
On startup, a gateway (1) SHOULD send presence to all registered users of that gateway but (2) MAY wait to receive presence changes from each registered user.
On shutdown, a gateway SHOULD send unavailable presence to all registered users of the gateway.
There is no foreseeable solution to these concerns, since they are instrinsic to the client proxy model. Some assurance regarding the second and third concerns can be achieved if the user runs his or her own Jabber server and gateways. However, the only true solution is to move beyond the client proxy model, either by using Jabber for all IM communications or to convince legacy IM services to allow federated server-to-server communications using open protocols such as Jabber/XMPP, thus obviating the need for client proxy gateways entirely.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; includes 'jabber:iq:gateway' in its registry of protocol namespaces.
Tickets also mean the jabber ticket provider and the web server do not need to be tightly integrated for authentication to work, also because its not tightly integrated it means webmasters do not need to setup their own jabber server to provide tickets, they can use a third party provider even a central "tickets.jabber.org". Also because tickets are not tightly integrated it makes it far easier for webmasters to integrate with Jabber, it also makes web farms far more scalable and reliable.
The motivations for this JEP are:
+The motivations for this document are:
The HTTP authentication scheme "JabberTicket" may need to be registered with IANA.
The ®ISTRAR; will need to register the new namespace of "http://jabber.org/protocol/ticket".
The generator is: 2.
-As Jabber becomes more widely utilized, applications of the protocol are veering away from traditional use as an IM product and are utilizing it for more generic data transportation and negotiation. While many advances are being made to facilitate non-IM data transportation, they do not address the use of already-established mechanisms of transporting data via URLs. This JEP provides a method that is compatible with these data transportation mechanisms and that is based on standard Internet Uniform Resource Locators (see &rfc3986;).
+As Jabber becomes more widely utilized, applications of the protocol are veering away from traditional use as an IM product and are utilizing it for more generic data transportation and negotiation. While many advances are being made to facilitate non-IM data transportation, they do not address the use of already-established mechanisms of transporting data via URLs. This document provides a method that is compatible with these data transportation mechanisms and that is based on standard Internet Uniform Resource Locators (see &rfc3986;).
The requirements this protocol fulfills are:
If more information is necessary for successfully using the URL, the sender includes meta-information in a scheme-specific format such as that defined in &jep0104;:
+If more information is necessary for successfully using the URL, the sender includes meta-information in a scheme-specific format such as that defined in &xep0104;:
The above example illustrates supplying a HTTP URL with a cookie header. Additional information could be provided, such as HTTP authentication requirements or even POST data.
-To support the use of bulk publishing methods such as &jep0060; or messages of type "headline", the <desc/> element is used to provide a textual description:
+To support the use of bulk publishing methods such as &xep0060; or messages of type "headline", the <desc/> element is used to provide a textual description:
To use "url-data" in conjunction with SI, the "sid" attribute of <url-data/> is used. This attribute MUST be equal to the SI session id.
-The general process flow for using "url-data" with SI is as follows
The general process flow for using "url-data" with SI is as follows
The sender starts with an SI request, using the semantics from JEP-0095:
+The sender starts with an SI request, using the semantics from XEP-0095:
This JEP does not yet have any security considerations.
+This document does not yet have any security considerations.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; shall register the namespace "http://jabber.org/protocol/url-data" as a standard namespace. Also, the Jabber Registrar shall register the &jep0020; option "url-data" for use with Stream Initiation.
+The ®ISTRAR; shall register the namespace "http://jabber.org/protocol/url-data" as a standard namespace. Also, the XMPP Registrar shall register the &xep0020; option "url-data" for use with Stream Initiation.
The most common URL scheme distributed over the Internet is HTTP and HTTPS. This JEP defines a structure that extends &jep0103; to enable more advanced access to such URLs within Jabber.
+The most common URL scheme distributed over the Internet is HTTP and HTTPS. This document defines a structure that extends &xep0103; to enable more advanced access to such URLs within Jabber.
This JEP supplements JEP-0103 to provide more detailed information about HTTP and HTTPS URLs. The requirements this JEP fulfills are:
+This document supplements XEP-0103 to provide more detailed information about HTTP and HTTPS URLs. The requirements this document fulfills are:
The intent of this information is to provide an HTTP client with enough information in order to construct the HTTP request and entity headers necessary, as defined in &rfc2616;.
-The use of this JEP in conjunction with JEP-0103 is OPTIONAL. The entity sending the URL is not required to provide any of this information, and receiving entities MAY ignore it.
+The use of this document in conjunction with XEP-0103 is OPTIONAL. The entity sending the URL is not required to provide any of this information, and receiving entities MAY ignore it.
The two most typical types of information that can be necessary for accessing an HTTP URL are authentication details and cookies. In some cases, custom headers MAY also be necessary for successful use. Authentication information is provided in a scheme-independent format. Cookie data provided includes what would be necessary for a client to properly persist the value.
At a minimum, this JEP allows for an entity to indicate what authentication scheme is in use:
+At a minimum, this document allows for an entity to indicate what authentication scheme is in use:
This JEP allows complete authentication information to be passed. This information is only as secure as the connection-path between the provider and acceptor.
+This document allows complete authentication information to be passed. This information is only as secure as the connection-path between the provider and acceptor.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; shall register the "http://jabber.org/protocol/url-data/scheme/http" namespace.
The tree transfer profile is in the "http://jabber.org/protocol/si/profile/tree-transfer" namespace. The profile is fairly simple: it consists of the root element with child elements that specify a directory structure of files with stream ids that will be used for each file.
-This profile requires support for the File Transfer profile described in &jep0096;. Once you have accepted this SI, a new SI using the File Transfer profile will be offered for each file in the tree. This profile provides a mapping of files with paths and reserved stream ids which will be used to auto-accept a File Transfer SI that uses that same stream id from the sender.
+This profile requires support for the File Transfer profile described in &xep0096;. Once you have accepted this SI, a new SI using the File Transfer profile will be offered for each file in the tree. This profile provides a mapping of files with paths and reserved stream ids which will be used to auto-accept a File Transfer SI that uses that same stream id from the sender.
The root element is <tree> and has two attributes. The attributes are used only during the offer stage of stream initiation:
The size and numfiles attributes MUST be present in the profile.
-The only possible child element of the root is <directory/> since there are other JEPs that handle single file transfers. The directory structure is sent in a hierarchical manner with nested <directory/> and/or <file/> tags. One or more <file/> elements will be sent, one for each file. One or more <directory/> elements will be sent, one for each directory.
+The only possible child element of the root is <directory/> since there are other specifications that handle single file transfers. The directory structure is sent in a hierarchical manner with nested <directory/> and/or <file/> tags. One or more <file/> elements will be sent, one for each file. One or more <directory/> elements will be sent, one for each directory.
The <directory/> element has one attribute:
Both attributes are REQUIRED on each <file/> element. The total number of <file> elements MUST equal the numfiles attribute sent in the <tree/> element.
The stream-method that is accepted for a Tree Profile SI MUST be remembered and the subsequent File Transfer SIs MUST NOT provide a Feature Negotiation packet. The stream-method has already been chosen and should be used for all of the streams.
-Implementations of this profile MUST support &jep0095; and JEP-0096.
+Implementations of this profile MUST support &xep0095; and XEP-0096.
- No interaction with &IANA; is required as a result of this JEP. + No interaction with &IANA; is required as a result of this document.
- The profile described in this JEP will be registered with ®ISTRAR; as a valid Stream + The profile described in this document will be registered with ®ISTRAR; as a valid Stream Initiation profile.
This JEP addresses the following requirements:
+This document addresses the following requirements:
If an entity needs to discover whether another entity supports JID escaping, it MUST send a disco#info request to the other entity as specified in &jep0030;.
+If an entity needs to discover whether another entity supports JID escaping, it MUST send a disco#info request to the other entity as specified in &xep0030;.
This JEP specifies encoding each disallowed character as \hexhex -- where "hexhex" is the hexadecimal value of the Unicode code point in question, ignoring the leading "00" in the code point (e.g., 27 for the ' character, resulting in an encoding of \27). (Note: This escaping method is quite similar to that used for disallowed characters in LDAP distinguished names, as specified in &rfc2253;.) Full encoding and decoding transformations for all nine disallowed characters are provided in the following sections. In addition, encoding and decoding transformations are shown for the \ character in case it needs to be "double-escaped" when it occurs in a non-XMPP address as part of a string that corresponds to one of the other encoded characters.
+This document specifies encoding each disallowed character as \hexhex -- where "hexhex" is the hexadecimal value of the Unicode code point in question, ignoring the leading "00" in the code point (e.g., 27 for the ' character, resulting in an encoding of \27). (Note: This escaping method is quite similar to that used for disallowed characters in LDAP distinguished names, as specified in &rfc2253;.) Full encoding and decoding transformations for all nine disallowed characters are provided in the following sections. In addition, encoding and decoding transformations are shown for the \ character in case it needs to be "double-escaped" when it occurs in a non-XMPP address as part of a string that corresponds to one of the other encoded characters.
Note: All transformations are exactly as specified below. CASE IS SIGNIFICANT. Lowercase was selected since Nodeprep will case fold to lowercase for US-ASCII characters such as A, C, E, and F.
When a client attempts to communicate with another entity through a gateway, it needs to know which encoding mechanism to use. A client MUST assume that the gateway does not support the JID escaping mechanism unless it explicitly discovers support for the jid\20escaping [sic] feature via Service Discovery as shown above. If there any errors in the service discovery exchange or if support for JID escaping is not discovered, the client SHOULD proceed as follows:
Unlike the foregoing address types, IMPS addresses are allowed to contain backslashes. This implies that it is possible for an IMPS address to contain a string that corresponds to one of the encoded character representations for code points that are disallowed in XMPP node identifiers. An example would be the IMPS address <wv:\3and\2is\5@example.com>, where the string "\3a" could be interpreted as the : character if that IMPS address is directly converted into a JID. Therefore, the leading \ character MUST be transformed to "\5c" in order to avoid possible ambiguity. Thus the transformed JID would be <\5c3and\2is\5@example.com>, which would be presented to a user as <\3and\2is\5@example.com>.
-If an IMPS address contains a private resource, a gateway between XMPP and IMPS should process the resource and append it to the end of the JID; however, such gateway behavior is out of scope for this JEP.
+If an IMPS address contains a private resource, a gateway between XMPP and IMPS should process the resource and append it to the end of the JID; however, such gateway behavior is out of scope for this document.
The foregoing example showed how to transform a wv: URI into a JID. However, it also may be necessary to convert a JID into a wv: URI, as shown in the following example.
Naturally, a more intelligent gateway could use the Domain Components to construct a more readable JID, such as <D\27Artagnan\20Saint-André@example.com>; however, such gateway behavior is out of scope for this JEP.
+Naturally, a more intelligent gateway could use the Domain Components to construct a more readable JID, such as <D\27Artagnan\20Saint-André@example.com>; however, such gateway behavior is out of scope for this document.
The foregoing example showed how to transform an LDAP distinguished name into a JID. However, it also may be necessary to convert a JID into an LDAP distinguished name, as shown in the following example.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; includes the jid\20escaping [sic] feature in its registry of service discovery features.
The <mood/> element SHOULD be communicated by means of &jep0060; but MAY be provided in a message as well. Because mood information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.
+The <mood/> element SHOULD be communicated by means of &xep0060; but MAY be provided in a message as well. Because mood information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.
If the user wishes to publish his mood to all of those who are subscribed to his mood information, the user SHOULD use publish-subscribe.
As mentioned in JEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &jep0033; protocol) to provide an explicit association between the published data and the user:
+As mentioned in XEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &xep0033; protocol) to provide an explicit association between the published data and the user:
The <mood/> element could even contain a URL reference structured according to the &jep0066; protocol:
+The <mood/> element could even contain a URL reference structured according to the &xep0066; protocol:
This JEP requires no interaction with &IANA;.
The ®ISTRAR; includes 'http://jabber.org/protocol/mood' in its registry of protocol namespaces.
This JEP defines an extension mechanism for capturing "extended presence" data about user activities, above and beyond availability as defined in &xmppim; (e.g., the 'away', 'extended away', and 'dnd' values of the <show/> child of the <presence/> stanza).
+This document defines an extension mechanism for capturing "extended presence" data about user activities, above and beyond availability as defined in &xmppim; (e.g., the 'away', 'extended away', and 'dnd' values of the <show/> child of the <presence/> stanza).
In accordance with &xmppcore;, the receiving application MUST ignore a specific activity element or detailed activity element if it does not understand the namespace that qualifies the element.
The <activity/> element SHOULD be communicated by means of &jep0060;. Because activity information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.
+The <activity/> element SHOULD be communicated by means of &xep0060;. Because activity information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.
As mentioned in JEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &jep0033; protocol) to provide an explicit association between the published data and the user:
+As mentioned in XEP-0060, the stanza containing the event notification or payload MAY also include 'replyto' data (as specified by the &xep0033; protocol) to provide an explicit association between the published data and the user:
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; includes 'http://jabber.org/protocol/activity' in its registry of protocol namespaces.
Before attempting to set or retrieve its current vacation settings, a user SHOULD first verify that their server supports vacation messages. To do this, the user makes a &jep0030; "#info" query to their server. If supported, the server includes a feature of "http://www.jabber.org/protocol/vacation" in the result.
+Before attempting to set or retrieve its current vacation settings, a user SHOULD first verify that their server supports vacation messages. To do this, the user makes a &xep0030; "#info" query to their server. If supported, the server includes a feature of "http://www.jabber.org/protocol/vacation" in the result.
<start/> and <end/> define the times between which this vacation message is valid. These are in the format specified by &jep0082;.
+<start/> and <end/> define the times between which this vacation message is valid. These are in the format specified by &xep0082;.
<message/> contains the text of the message that will be sent to a remote user that sends the user a message while they have active vacation settings.
If the user has no stored vacation settings, the user will receive a result like the following:
@@ -166,10 +166,10 @@None yet defined.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The 'http://jabber.org/protocol/vacation' namespace shall be registered with the ®ISTRAR; as a result of this JEP.
+The 'http://jabber.org/protocol/vacation' namespace shall be registered with the ®ISTRAR; as a result of this document.