<remark>Modified text regarding address transformations and added reference to XEP-0106; corrected several small errors in the text and examples.</remark>
<remark>Editorial review: made a number of minor textual changes and clarifications throughout; added introductory paragraph to each use case; specified that groupchat is out of scope.</remark>
</revision>
<revision>
<version>0.7</version>
<date>2004-03-31</date>
<initials>psa</initials>
<remark>Cleaned up several notes, examples, and business rules based on feedback received on list.</remark>
</revision>
<revision>
<version>0.6</version>
<date>2004-03-08</date>
<initials>psa</initials>
<remark>Added note about 'from' address on presence notifications and messages received through gateways from legacy users.</remark>
</revision>
<revision>
<version>0.5</version>
<date>2004-01-21</date>
<initials>psa</initials>
<remark>Further specified the rationale for deprecating the "jabber:iq:gateway" protocol.</remark>
</revision>
<revision>
<version>0.4</version>
<date>2004-01-05</date>
<initials>psa</initials>
<remark>Added Edit Registration use case; modified handling of legacy contact lists to conform to RFC 3921; modified addressing rules; defined gateway startup and shutdown behavior; included XMPP error handling.</remark>
</revision>
<revision>
<version>0.3</version>
<date>2003-12-10</date>
<initials>psa</initials>
<remark>Added security considerations; defined handling of legacy contact lists.</remark>
</revision>
<revision>
<version>0.2</version>
<date>2003-12-03</date>
<initials>psa</initials>
<remark>Corrected some errors; clarified some ambiguities; added protocol flows.</remark>
<p>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, Windows Live 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.</p>
<p>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.</p>
<td>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.</td>
<td>A human user who has registered an account with a Jabber server; a Jabber User who wants to use a Gateway must first have also registered an account with a Legacy Service.</td>
</tr>
<tr>
<td>Legacy Service</td>
<td>A non-XMPP instant messaging service.</td>
</tr>
<tr>
<td>Legacy User</td>
<td>A human user who has registered an account with a Legacy Service.</td>
</tr>
<tr>
<td>Server</td>
<td>An instant messaging server as defined in <cite>RFC 3921</cite>.</td>
<p>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.</p>
<p>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.</p>
<p>All existing client proxy gateways require a Jabber User to register with the Gateway before sending messages or presence through the gateway. Although strictly speaking registration is not required (e.g., a Gateway could prompt the Jabber User for credentials every time the user attempted to communicate through the gateway, or once per "session"), in practice this step is required.</p>
<p>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).</p>
<p>Note: Although many existing gateway implementations support only the older Agent Information protocol, it is RECOMMENDED that gateways support the Service Discovery protocol, since the former protocol is deprecated in favor of the latter. Until existing gateways are upgraded, clients SHOULD support both.</p>
</li>
<li>
<p>Gateway and/or parent returns identity information to Jabber User's Client.</p>
<examplecaption="Gateway Returns Service Discovery Identity"><![CDATA[
<p>Note: Given the foregoing, a client can determine the identity of the gateway, specifically (1) that it is a gateway and (2) to which legacy service it provides a gateway.</p>
<p>Note: The XML character data of the <username/> element SHOULD be the Jabber User's LegacyUserAddress as described under <linkurl='#addressing'>Addressing</link>, such as an AOL screen name, ICQ number, Windows Live Messenger (formerly MSN Messenger) address, or Yahoo! ID.</p>
<p>Gateway verifies that registration information provided by Jabber User is valid (using whatever means appropriate for the Legacy Service) and informs Jabber User of success [A1].</p>
<examplecaption="Gateway Informs Jabber User of Success"><![CDATA[
<iqtype='result'
from='aim.shakespeare.lit'
to='romeo@montague.net/orchard'
id='reg2'/>
]]></example>
</li>
<li><p>If Gateway logged into Legacy Service in preceding step, Gateway buffers any translatable events (e.g., messages and presence) queued up for Jabber User on Legacy Service.</p></li>
<li>
<p>Optionally, Jabber User sends IQ-set qualified by the 'jabber:iq:roster' namespace to its server (see &rfc3921;), containing a roster item for Gateway.</p>
<p>Gateway sends subscription request to Jabber User (i.e., by sending a presence stanza of type "subscribe" to Jabber User's bare JID).</p>
<examplecaption="Gateway Subscribes to User's Presence"><![CDATA[
<presencetype='subscribe'
from='aim.shakespeare.lit'
to='romeo@montague.net'/>
]]></example>
</li>
<li>
<p>Jabber User's client SHOULD approve the subscription request (i.e., by sending a presence stanza of type "subscribed" to Gateway).</p>
<examplecaption="Jabber User Approves Subscription Request"><![CDATA[
<presencetype='subscribed'
from='romeo@montague.net'
to='aim.shakespeare.lit'/>
]]></example>
<p>Note: As specified in <cite>RFC 3921</cite>, Jabber User's server will generate a "roster push" at this point if client did not previously perform a roster set to add Gateway to user's roster (as mentioned above).</p>
</li>
<li>
<p>Jabber User sends subscription request to Gateway (i.e., by sending a presence stanza of type "subscribe" to Gateway).</p>
<examplecaption="Jabber User Subscribes to Gateway's Presence"><![CDATA[
<presencetype='subscribe'
from='romeo@montague.net'
to='aim.shakespeare.lit'/>
]]></example>
</li>
<li>
<p>Gateway sends approves subscription request (i.e., by sending a presence stanza of type "subscribed" to Jabber User's bare JID).</p>
<p>After a Jabber User has registered with a Gateway, the user may wish to modify his or her existing registration information (e.g., because the user has changed his or her password on the legacy IM service).</p>
<p>Gateway returns IQ-result to Jabber User, specifying registration information on record and including empty <registered/> element to signify that user is already registered. <note>The fact that the Gateway can determine the Jabber User's legacy username based on the JID of the 'from' address indicates that the client proxy model assumes one registration per Jabber User.</note></p>
<examplecaption="Gateway Returns Registration Information of Record"><![CDATA[
<iqtype='result'
from='aim.shakespeare.lit'
to='romeo@montague.net/orchard'
id='edit1'>
<queryxmlns='jabber:iq:register'>
<registered/>
<username>RomeoMyRomeo</username>
<password>ILoveJuliet</password>
</query>
</iq>
]]></example>
</li>
<li>
<p>Jabber User sends IQ-set qualified by the 'jabber:iq:register' namespace to Gateway, containing all information (i.e., not just the "delta").</p>
<p>Gateway verifies that, if changed, information provided by Jabber User is still valid (using whatever means appropriate for the Legacy Service) and informs Jabber User of success [A1].</p>
<examplecaption="Gateway Informs Jabber User of Success"><![CDATA[
<p>After a Jabber User has registered with a Gateway, the user may choose to unregister with the Gateway, effectively ending his or her relationship with the Gateway (e.g., the user will no longer be allowed to communicate through the gateway with legacy users).</p>
<p>Gateway sends unavailable presence to Jabber User.</p>
<examplecaption="Gateway Logs User Out"><![CDATA[
<presencetype='unavailable'
from='aim.shakespeare.lit'
to='romeo@montague.net'/>
]]></example>
</li>
<li><p>Jabber User's client SHOULD delete from the user's roster (1) the gateway itself, and (2) all legacy Contacts associated with the gateway.</p></li>
<p>After a Jabber User has registered with a Gateway, the Jabber User may subsequently log in to the Gateway, effectively creating a "session" with the Gateway and enabling the Gateway to log into the Legacy Service on behalf of the user by sending the user's legacy credentials to the Legacy Service.</p>
<p>Jabber User sends available presence broadcast to Server or sends directed presence to Gateway or a Legacy User.</p>
<examplecaption="Jabber User Sends Available Presence"><![CDATA[
<presence/>
]]></example>
<examplecaption="Jabber User's Server Broadcasts Available Presence"><![CDATA[
<presencefrom='romeo@montague.net/orchard'
to='juliet@aim.shakespeare.lit'/>
<presencefrom='romeo@montague.net/orchard'
to='aim.shakespeare.lit'/>
...
]]></example>
</li>
<li><p>Upon receiving the first presence notification stanza from Jabber User to Gateway or Legacy User, Gateway logs Jabber User into Legacy Service [A1].</p></li>
<li>
<p>Gateway sends presence stanza to Jabber User expressing availability.</p>
<examplecaption="Gateway Sends Presence to Jabber User"><![CDATA[
<presencefrom='aim.shakespeare.lit'
to='romeo@montague.net'/>
]]></example>
</li>
<li><p>Optionally, Gateway handles Legacy Service contact list; see the <linkurl="#rosters">Contact Lists</link> section of this document.</p></li>
<li>
<p>Gateway forwards current presence information from Legacy Users to Jabber User, if possible mapping availability status (e.g., "away").</p>
<examplecaption="Gateway Sends Presence from Legacy Users to Jabber User"><![CDATA[
<presencefrom='juliet@aim.shakespeare.lit'
to='romeo@montague.net'>
<show>away</show>
</presence>
]]></example>
<p>Note: If the Legacy Service to which the Gateway connects does not support the concept of "resources", the 'from' address of presence notification stanzas generated by a gateway SHOULD NOT include a resource identifier (i.e., they SHOULD be of the form <user@host> rather than <user@host/resource>). However, the 'from' address MAY include a resource if the Gateway determines that this is appropriate in the context of its communications with the Legacy Service.</p>
</li>
<li>
<p>Gateway forwards all subsequent presence stanzas to Legacy Users (except those of type "probe" and those addressed to the Gateway itself).</p>
<examplecaption="Jabber User Modifies Presence"><![CDATA[
<p>At any time after logging in to the Gateway, the Jabber User may log out of the Gateway and thereby end his or her session on the Legacy Service. This may happen automatically when the Jabber User terminates his or her session with a Jabber server, or independently of any session on the Jabber network by manually logging out of the Gateway.</p>
<p>Jabber User sends unavailable presence broadcast to Server or sends directed presence stanza of type "unavailable" to Gateway or (if Gateway does not support directed presence) Legacy User.</p>
<examplecaption="Jabber User Sends Unavailable Presence"><![CDATA[
<presencetype='unavailable'/>
]]></example>
<examplecaption="Jabber User's Server Broadcasts Unavailable Presence"><![CDATA[
<presencetype='unavailable'
from='romeo@montague.net/orchard'
to='aim.shakespeare.lit'/>
]]></example>
</li>
<li><p>Gateway transforms unavailable presence stanzas received from the Jabber User's server and routes them to all of the Jabber User's contacts on Legacy Service.</p></li>
<li><p>Gateway logs Jabber User out of Legacy Service [A1].</p></li>
<li>
<p>Gateway sends presence stanza of type "unavailable" to Jabber User.</p>
<p>Jabber User sends presence stanza of type "subscribe" to Legacy User.</p>
<examplecaption="Jabber User Sends Subscription Request to Legacy User"><![CDATA[
<presencetype='subscribe'
from='romeo@montague.net'
to='CapuletNurse@aim.shakespeare.lit'/>
]]></example>
<p>Note: As specified in <cite>RFC 3921</cite>, sending this packet will result in a "roster push" from the Server to all of the Jabber User's available resources.</p>
</li>
<li><p>Gateway transforms subscription request and routes it to Legacy User.</p></li>
<li>
<p>If Legacy User approves subscription request, Gateway sends presence stanza of type "subscribed" to Jabber User on behalf of Legacy User. [A1]</p>
<examplecaption="Gateway Approves Subscription Request on Behalf of Legacy User"><![CDATA[
<presencetype='subscribed'
from='CapuletNurse@aim.shakespeare.lit'
to='romeo@montague.net'/>
]]></example>
</li>
<li>
<p>Gateway sends available presence stanza to Jabber User on behalf of Legacy User.</p>
<examplecaption="Gateway Sends Legacy User's Current Presence Information to Jabber User"><![CDATA[
<presencefrom='CapuletNurse@aim.shakespeare.lit'
to='romeo@montague.net/orchard'/>
]]></example>
</li>
<li>
<p>Gateway sends presence stanza of type "subscribe" to Jabber User on behalf of Legacy User.</p>
<examplecaption="Gateway Sends Subscription Request to Jabber User on Behalf of Legacy User"><![CDATA[
<presencetype='subscribe'
from='CapuletNurse@aim.shakespeare.lit'
to='romeo@montague.net'/>
]]></example>
</li>
<li>
<p>Jabber User sends presence stanza of type "subscribed" to Legacy User.</p>
<examplecaption="Jabber User Approves Subscription Request"><![CDATA[
<p>Jabber User sends IQ-set qualified by the 'jabber:iq:roster' namespace, containing subscription attribute with value of "remove".</p>
<examplecaption="User Removes Roster Entry for Legacy User"><![CDATA[
<iqtype='set'
from='romeo@montague.net/orchard'
id='remove1'>
<queryxmlns='jabber:iq:roster'>
<itemjid='CapuletNurse@aim.shakespeare.lit'
subscription='remove'/>
</query>
</iq>
]]></example>
</li>
<li>
<p>Server sends normal "roster push" to Jabber User (see <cite>RFC 3921</cite>) and sends presence stanzas of type "unsubscribe", "unsubscribed", and "unavailable" to Legacy User.</p>
<examplecaption="Server Sends Presence Changes to Legacy User"><![CDATA[
<presencetype='unsubscribe'
from='romeo@montague.net'
to='CapuletNurse@aim.shakespeare.lit'/>
<presencetype='unsubscribed'
from='romeo@montague.net'
to='CapuletNurse@aim.shakespeare.lit'/>
<presencetype='unavailable'
from='romeo@montague.net/orchard'
to='CapuletNurse@aim.shakespeare.lit'/>
]]></example>
</li>
<li><p>Gateway cleans up subscription state, informs Legacy User that Jabber User is unavailable, and MUST NOT send future changes in Jabber User's presence to Legacy User.</p></li>
<p>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).</p>
<p>The Legacy User may want to add the Jabber User to his or her contact list on the Legacy Service. Because the Jabber User has an account on the Legacy Service by definition, the Legacy User will actually add the Jabber User's legacy address to his or her contact list, not the Jabber User's address on the Jabber/XMPP network.</p>
<li><p>Legacy User requests subscription to Jabber User's legacy address (using legacy protocol).</p></li>
<li>
<p>Gateway sends presence stanza of type "subscribe" to Jabber User on behalf of Legacy User. (Note: Gateway MUST NOT send presence stanza of type "subscribed".)</p>
<examplecaption="Gateway Sends Subscription Request on Behalf of Legacy User"><![CDATA[
<presencetype='subscribe'
from='CapuletNurse@aim.shakespeare.lit'
to='romeo@montague.net'/>
]]></example>
</li>
<li>
<p>Jabber User approves subscription request by sending presence stanza of type "subscribed" to Legacy User [A1].</p>
<examplecaption="Jabber User Approves Subscription Request"><![CDATA[
<presencetype='subscribed'
from='romeo@montague.net'
to='CapuletNurse@aim.shakespeare.lit'/>
]]></example>
</li>
<li><p>Gateway sends Jabber User's presence information to Legacy User.</p></li>
<li>
<p>Jabber User's Client sends presence stanza of type "subscribe" to Legacy User.</p>
<examplecaption="Jabber User Sends Subscription Request to Legacy User"><![CDATA[
<presencetype='subscribe'
from='romeo@montague.net'
to='CapuletNurse@aim.shakespeare.lit'/>
]]></example>
</li>
<li>
<p>Gateway sends presence stanza of type "subscribed" to Jabber User on behalf of Legacy User.</p>
<examplecaption="Gateway Approves Subscription Request on Behalf of Legacy User"><![CDATA[
<presencetype='subscribed'
from='CapuletNurse@aim.shakespeare.lit'
to='romeo@montague.net'/>
]]></example>
</li>
<li>
<p>Gateway sends Legacy User's presence information to Jabber User.</p>
<examplecaption="Gateway Sends Legacy User's Current Presence Information to Jabber User"><![CDATA[
<li><p>Legacy User deletes Jabber User's legacy address (using legacy protocol).</p></li>
<li>
<p>Gateway sends presence stanzas of type "unsubscribe", "unsubscribed", and "unavailable" to Jabber User on behalf of Legacy User.</p>
<examplecaption="Gateway Cleans Up Subscription on Behalf of Legacy User"><![CDATA[
<presencetype='unsubscribe'
from='CapuletNurse@aim.shakespeare.lit'
to='romeo@montague.net'/>
<presencetype='unsubscribed'
from='CapuletNurse@aim.shakespeare.lit'
to='romeo@montague.net'/>
<presencetype='unavailable'
from='CapuletNurse@aim.shakespeare.lit'
to='romeo@montague.net/orchard'/>
]]></example>
</li>
<li><p>Jabber User's server performs defined functionality for handling presence stanzas of type "unsubscribe" and "unsubscribed" (see <cite>RFC 3921</cite>).</p></li>
<li><p>Legacy User sends message to Jabber User using legacy protocol.</p></li>
<li>
<p>Gateway transforms message and routes to Jabber User.</p>
<examplecaption="Legacy User Sends Message to Jabber User"><![CDATA[
<messagefrom='juliet@aim.shakespeare.lit'
to='romeo@montague.net'>
<body>Art thou not Romeo, and a Montague?</body>
</message>
]]></example>
<p>Note: If the Legacy Service to which the Gateway connects does not support a concept equivalent to that of Jabber "resources" as described in &rfc3920;, the 'from' address of message stanzas generated by a gateway SHOULD NOT include a resource identifier (i.e., they SHOULD be of the form <user@host> rather than <user@host/resource>). However, the 'from' address MAY include a resource if the Gateway determines that this is appropriate in the context of its communications with the Legacy Service.</p>
</li>
<li><p>Jabber User's Server delivers message or (optionally) stores it for later retrieval.</p></li>
<p>The address of a gateway itself SHOULD be a hostname only, and that hostname SHOULD NOT be supplemented with a resource identifier when referring to the gateway's address (e.g., when storing the gateway in a roster). The hostname SHOULD be a subdomain of a primary Jabber host (e.g., icq.jabber.org might be the ICQ gateway run by the jabber.org server).</p>
</section2>
<section2topic='Users'anchor='addressing-user'>
<p>The Jabber Identifier corresponding to a Legacy User's address is typically of the form <LegacyUserAddress@gateway.example.com>, where LegacyUserAddress is the Legacy User's address on the Legacy Service and where gateway.example.com is the Jabber address of the gateway.</p>
<p>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 <cite>RFC 3920</cite>. 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>.</p>
<p>There are two possible ways to solve this problem:</p>
<li>Use the older 'jabber:iq:gateway' protocol (as documented in the following section).</li>
</ol>
<p>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.</p>
<p>The 'jabber:iq:gateway' protocol performs two functions:</p>
<ol>
<li><p>It enables a client to determine the text for the "prompt" to show to a Jabber User when the user wants to add a legacy contact to the user's roster (e.g., "Please enter the AOL Screen Name of the person you would like to contact"), as well as the preferred name for the prompted item (e.g., "Screen Name"). To do so, the client sends an empty <query/> element and the gateway returns a <prompt/> element (the name for the prompted item) and optionally a <desc/> element (the text of the prompt itself).</p></li>
<li><p>It enables a client to send a legacy username to the gateway and receive a properly-formatted JID in return. To do so, the client sends the legacy address to the gateway as the character data of the <prompt/> element and the gateway returns a valid JID as the character data of the <jid/> element.</p></li>
<td>gateway/msn <note>The service discovery type was originally defined as "msn" to reflect the name of the service as "MSN Messenger"; this type is retained even though the service has been renamed to "Windows Live Messenger".</note></td>
<td>Contact ID</td>
<td>Please enter the Windows Live Messenger address of the person you would like to contact.</td>
<td>Please enter the Yahoo ID of the person you would like to contact.</td>
</tr>
</table>
<p>If the client provides an 'xml:lang' attribute with the IQ-get, the gateway SHOULD return localized prompt names and text if available, or default to English if not available.</p>
<p>Once the user enters a legacy username or address, the client MUST send it to the gateway as the character data of the <prompt/> element in an IQ-set; the gateway MUST then return a properly-formed JID based on the provided by the client.</p>
<p>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 <cite>RFC 3921</cite>. Therefore, a gateway SHOULD instead send the legacy contact list items to the Jabber User via the &xep0144; protocol.</p>
<li><p>A client SHOULD send a <cite>Service Discovery</cite> request to the gateway (and/or an <cite>Agent Information</cite> request to the gateway's parent) before requesting registration information.</p></li>
<li><p>A gateway SHOULD support the <cite>Service Discovery</cite> protocol.</p></li>
<li><p>A gateway SHOULD support the <cite>Agent Information</cite> protocol, although it is deprecated.</p></li>
<li><p>A gateway SHOULD map, as best it can, the legacy registration fields onto the fields defined for the 'jabber:iq:register' namespace.</p></li>
<li><p>A gateway SHOULD NOT attempt to emulate offline message storage functionality for legacy services that lack such functionality.</p></li>
<p>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:</p>
<li><p>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.</p></li>
<li><p>On shutdown, a gateway SHOULD send unavailable presence to all registered users of the gateway.</p></li>
<p>As defined herein, a gateway is a <em>client proxy</em>, since it "masquerades" as a user on a legacy instant messaging service. In order to act as a client proxy, the gateway logs into the user's account on the legacy service. This implies two things:</p>
<ul>
<li>The gateway must gather the legacy credentials from the user, and perhaps store them on the user's behalf.</li>
<li>The gateway must provide the user's credentials to the legacy service.</li>
</ul>
<p>There are obvious security concerns with this approach. The concerns include:</p>
<ol>
<li>The user's credentials on the legacy service may be sent in the clear from the gateway to the legacy service if the legacy service does not support channel encryption or strong authentication.</li>
<li>When the user informs the gateway of the user's legacy credentials, the credentials may be sent in the clear between the user's Jabber client and the user's Jabber server (if client-to-server channel encryption is not enabled) or between the user's Jabber server and the gateway (if the gateway is not in the user's "home" domain and server-to-server channel encryption is not enabled).</li>
<li>If the gateway stores the user's legacy credentials after registration (this is the default behavior of most or all existing gateway implementations), the user's credentials could be acquired by a malicious user if the server hosting the gateway is compromised.</li>
</ol>
<p>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.</p>
