JEP-0100: Gateway Interaction

This JEP specifies best practices for interactions between Jabber clients and client proxy gateways to legacy IM services.

WARNING: This Informational JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the best practice or protocol profile described herein is encouraged in exploratory implementations, although production systems should not deploy implementations of this protocol until it advances to a status of Draft.

JEP Information

Status: Experimental
Type: Informational
Number: 0100
Version: 0.8
Last Updated: 2004-05-07
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, XMPP IM, JEP-0030, JEP-0077, JEP-0093
Supersedes: None
Superseded By: None
Short Name: N/A

Author Information

Peter Saint-Andre

Email: stpeter@jabber.org
JID: stpeter@jabber.org

Dave Smith

Email: dizzyd@jabber.org
JID: dizzyd@jabber.org

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2004 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.php>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core and XMPP IM specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocols defined in this JEP have been developed outside the Internet Standards Process and are to be understood as extensions to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Table of Contents

1. Introduction
2. Terminology
2.1. Architectural Terms
3. Requirements
4. Jabber User Use Cases
4.1. Register
4.1.1. Primary Flow
4.1.2. Alternate Flows
4.2. Edit Registration
4.2.1. Primary Flow
4.2.2. Alternate Flows
4.3. Unregister
4.3.1. Primary Flow
4.3.2. Alternate Flows
4.4. Log In
4.4.1. Primary Flow
4.4.2. Alternate Flows
4.5. Log Out
4.5.1. Primary Flow
4.5.2. Alternate Flows
4.6. Add Contact
4.6.1. Primary Flow
4.6.2. Alternate Flows
4.7. Delete Contact
4.7.1. Primary Flow
4.7.2. Alternate Flows
4.8. Send Message
4.8.1. Primary Flow
4.8.2. Alternate Flows
5. Legacy User Use Cases
5.1. Add Contact
5.1.1. Primary Flow
5.1.2. Alternate Flows
5.2. Delete Contact
5.2.1. Primary Flow
5.2.2. Alternate Flows
5.3. Send Message
5.3.1. Primary Flow
5.3.2. Alternate Flows
6. Addressing
7. Contact Lists
8. Business Rules
9. Security Considerations
10. IANA Considerations
11. Jabber Registrar Considerations
Notes
Revision History

1. Introduction

One distinguishing characteristic of Jabber from its 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! Instant 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.

2. Terminology

2.1 Architectural Terms

Table 1: Glossary

Term Definition
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.
Jabber User 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.
Legacy Service A non-XMPP instant messaging service.
Legacy User A human user who has registered an account with a Legacy Service.
Server An instant messaging server as defined in XMPP Core

3. Requirements

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 Jabber User use cases are:

  1. Register
  2. Edit Registration
  3. Unregister
  4. Log In
  5. Log Out
  6. Add Contact
  7. Delete Contact
  8. Send Message

The Legacy User use cases are:

  1. Add Contact
  2. Delete Contact
  3. Send Message

4. Jabber User Use Cases

4.1 Register

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.

4.1.1 Primary Flow

  1. Jabber User sends IQ get in the Service Discovery [1] information namespace to the Gateway, and/or IQ get in the Agent Information [2] namespace to the Gateway's parent (the latter method is deprecated but still in use).

    Example 1. User Queries Gateway Regarding Service Discovery Identity

    <iq type='get'
    from='romeo@montague.net/orchard'
    to='aim.shakespeare.lit'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

    Example 2. User Queries Gateway's Parent Regarding Agent Information

    <iq type='get'
    from='romeo@montague.net/orchard'
    to='shakespeare.lit'
    id='agent1'>
  <query xmlns='jabber:iq:agents'/>
</iq>

    Note: Although most 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.

  2. Gateway and/or parent returns identity information to Jabber User's Client.

    Example 3. Gateway Returns Service Discovery Identity

    <iq type='result'
    from='aim.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='gateway'
              type='aim'
              name='AIM Gateway'/>
    <feature var='jabber:iq:register'/>
    <feature var='jabber:iq:time'/>
    <feature var='jabber:iq:version'/>
  </query>
</iq>

    Example 4. Gateway's Parent Returns Agent Information

    <iq type='get'
    from='romeo@montague.net/orchard'
    to='shakespeare.lit'
    id='agent1'>
  <query xmlns='jabber:iq:agents'>
    <agent jid='aim.shakespeare.lit'>
      <name>AIM Gateway</name>
      <service>aim</service>
      <transport/>
      <register/>
    </agent>
  </query>
</iq>

    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.

  3. Jabber User sends IQ get in the In-Band Registration [3] (jabber:iq:register) namespace to Gateway.

    Example 5. User Queries Gateway Regarding Registration Requirements

    <iq type='get'
    from='romeo@montague.net/orchard'
    to='aim.shakespeare.lit'
    id='reg1'>
  <query xmlns='jabber:iq:register'/>
</iq>

  4. Gateway returns IQ result to Jabber User, specifying information that is required in order to register.

    Example 6. Gateway Returns Registration Requirements

    <iq type='result'
    from='aim.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='reg1'>
  <query xmlns='jabber:iq:register'>
    <instructions>
      Please provide your AIM username and password.
    </instructions>
    <username/>
    <password/>
  </query>
</iq>

  5. Jabber User sends IQ set qualified by the 'jabber:iq:register' namespace to Gateway, containing information required to register.

    Example 7. User Provides Registration Information

    <iq type='set'
    from='romeo@montague.net/orchard'
    to='aim.shakespeare.lit'
    id='reg2'>
  <query xmlns='jabber:iq:register'>
    <username>RomeoMyRomeo</username>
    <password>ILoveJuliet</password>
  </query>
</iq>

  6. 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].

    Example 8. Gateway Informs Jabber User of Success

    <iq type='result'
    from='aim.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='reg2'/>

  7. Optionally, Jabber User sends IQ set qualified by the 'jabber:iq:roster' namespace to its server (see XMPP IM [4]), containing a roster item for Gateway.

    Example 9. User Creates Roster Entry

    <iq type='set'
    from='romeo@montague.net/orchard'
    id='roster1'>
  <query xmlns='jabber:iq:roster'>
    <item jid='aim.shakespeare.lit' name='AIM Gateway'/>
  </query>
</iq>

    Example 10. Server Response

    <iq type='result'
    to='romeo@montague.net/orchard'
    id='roster1'/>

  8. If Gateway logged using into Legacy Service in preceding step, Gateway buffers any translatable events (e.g., messages and presence) queued up for Jabber User on Legacy Service.

  9. Gateway sends subscription request to Jabber User (i.e., by sending a presence stanza of type "subscribe" to Jabber User's bare JID).

    Example 11. Gateway Subscribes to User's Presence

    <presence type='subscribe'
          from='aim.shakespeare.lit'
          to='romeo@montague.net'/>

  10. Jabber User's client SHOULD approve the subscription request (i.e., by sending a presence stanza of type "subscribed" to Gateway).

    Example 12. Jabber User Approves Subscription Request

    <presence type='subscribed'
          from='romeo@montague.net'
          to='aim.shakespeare.lit'/>

    Note: As specified in XMPP IM, 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 in Step 7).

  11. Jabber User sends subscription request to Gateway (i.e., by sending a presence stanza of type "subscribe" to Gateway).

    Example 13. Jabber User Approves Subscription Request

    <presence type='subscribe'
          from='romeo@montague.net'
          to='aim.shakespeare.lit'/>

  12. Gateway sends approves subscription request (i.e., by sending a presence stanza of type "subscribed" to Jabber User's bare JID).

    Example 14. Gateway Approves Subscription Request

    <presence type='subscribed'
          from='aim.shakespeare.lit'
          to='romeo@montague.net'/>

  13. Execute "Log In" use case.

  14. Gateway sends any buffered messages to Jabber User.

  15. Use Case Ends.

4.1.2 Alternate Flows

  1. User information not verified:

    1. Gateway returns "Not Acceptable" error to Jabber User.

      Example 15. Gateway Informs Jabber User of Registration Error

      <iq type='error'
    from='aim.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='reg2'>
  <query xmlns='jabber:iq:register'>
    <username>RomeoMyRomeo</username>
    <password>ILoveJuliet</password>
  </query>
  <error code='406' type='modify'>
    <not-acceptable
        xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

    2. Use Case Ends unsuccessfully.

4.2 Edit Registration

After a Jabber User has registered with a Gateway, the user may wish to modify its existing registration information (e.g., because the user has changed his or her password on the legacy IM service).

4.2.1 Primary Flow

  1. Jabber User sends IQ get qualified by the 'jabber:iq:register' namespace to Gateway.

    Example 16. User Queries Gateway Regarding Registration Requirements

    <iq type='get'
    from='romeo@montague.net/orchard'
    to='aim.shakespeare.lit'
    id='edit1'>
  <query xmlns='jabber:iq:register'/>
</iq>

  2. Gateway returns IQ result to Jabber User, specifying registration information of record and including empty <registered/> element to signify that user is already registered.

    Example 17. Gateway Returns Registration Information of Record

    <iq type='result'
    from='aim.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='edit1'>
  <query xmlns='jabber:iq:register'>
    <registered/>
    <username>RomeoMyRomeo</username>
    <password>ILoveJuliet</password>
  </query>
</iq>

  3. Jabber User sends IQ set qualified by the 'jabber:iq:register' namespace to Gateway, containing all information (i.e., not just the "delta").

    Example 18. User Provides Registration Information

    <iq type='set'
    from='romeo@montague.net/orchard'
    to='aim.shakespeare.lit'
    id='edit2'>
  <query xmlns='jabber:iq:register'>
    <username>RomeoMyRomeo</username>
    <password>B4lc0ny</password>
  </query>
</iq>

  4. 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].

    Example 19. Gateway Informs Jabber User of Success

    <iq type='result'
    from='aim.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='edit2'/>

4.2.2 Alternate Flows

  1. Edit unsuccessful:

    1. Gateway returns "Not Acceptable" error to Jabber User.

      Example 20. Gateway Informs Jabber User of Registration Error

      <iq type='error'
    from='aim.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='edit2'>
  <query xmlns='jabber:iq:register'>
    <username>RomeoMyRomeo</username>
    <password>B4lc0ny</password>
  </query>
  <error code='406' type='modify'>
    <not-acceptable
        xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

    2. Use Case Ends unsuccessfully.

4.3 Unregister

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

4.3.1 Primary Flow

  1. Jabber User sends IQ set in 'jabber:iq:register' namespace to Gateway, containing empty <remove/> element.

    Example 21. User Unregisters

    <iq type='set'
    from='romeo@montague.net/orchard'
    to='aim.shakespeare.lit'
    id='unreg1'>
  <query xmlns='jabber:iq:register'>
    <remove/>
  </query>
</iq>

  2. Gateway sends unavailable presence from Jabber User to Legacy Users and logs Jabber User out of Legacy Service.

  3. Gateway deletes Jabber User's information.

  4. Gateway sends IQ result to Jabber User.

    Example 22. Gateway Informs Jabber User of Success

    <iq type='result'
    from='aim.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='unreg1'/>

  5. Gateway cancels subscriptions.

    Example 23. Gateway Cancels Subscriptions

    <presence type='unsubscribe'
          from='aim.shakespeare.lit'
          to='romeo@montague.net'/>

<presence type='unsubscribed'
          from='aim.shakespeare.lit'
          to='romeo@montague.net'/>

  6. Gateway sends unavailable presence to Jabber User.

    Example 24. Gateway Logs User Out

    <presence type='unavailable'
          from='aim.shakespeare.lit'
          to='romeo@montague.net'/>

  7. Jabber User's client SHOULD delete from the user's roster (1) the gateway itself, and (2) all legacy cOntacts associated with the gateway.

  8. Use Case Ends.

4.3.2 Alternate Flows

None.

4.4 Log In

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.

4.4.1 Primary Flow

  1. Jabber User sends available presence broadcast to Server or sends directed presence to Gateway or a Legacy User.

    Example 25. Jabber User Sends Available Presence

    <presence/>

    Example 26. Jabber User's Server Broadcasts Available Presence

    <presence from='romeo@montague.net/orchard'
          to='juliet@aim.shakespeare.lit'/>
<presence from='romeo@montague.net/orchard'
          to='aim.shakespeare.lit'/>
...

  2. Upon receiving first presence notification stanza from Jabber User to Gateway or Legacy User, Gateway logs Jabber User into Legacy Service [A1].

  3. Gateway sends presence stanza to Jabber User expressing availability.

    Example 27. Gateway Sends Presence to Jabber User

    <presence from='aim.shakespeare.lit'
          to='romeo@montague.net'/>

  4. Optionally, Gateway handles Legacy Service contact list; see the Contact Lists section of this document.

  5. Gateway forwards current presence information from Legacy Users to Jabber User, if possible mapping availability status (e.g., "away").

    Example 28. Gateway Sends Presence from Legacy Users to Jabber User

    <presence from='juliet@aim.shakespeare.lit'
          to='romeo@montague.net'>
  <show>away</show>
</presence>

    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.

  6. Gateway forwards all subsequent presence stanzas to Legacy Users (except those of type "probe" and those addressed to the Gateway itself).

    Example 29. Jabber User Modifies Presence

    <presence from='romeo@montague.net/orchard'
          to='juliet@aim.shakespeare.lit'>
  <show>dnd</show>
  <status>Wooing Juliet</status>
</presence>

  7. Use Case Ends.

4.4.2 Alternate Flows

  1. Login fails:

    1. Gateway sends appropriate presence error to Jabber User (Not Authorized" if password is bad, "Remote Server Timeout" if Legacy Service is down, etc.).

      Example 30. Gateway Informs Jabber User of Failed Login

      <presence to='aim.shakespeare.lit'
          from='romeo@shakespeare.lit'>
  <error code='504' type='wait'>
    <remote-server-timeout
        xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>

    2. Use Case Ends unsuccessfully.

4.5 Log Out

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.

4.5.1 Primary Flow

  1. Jabber User sends unavailable presence broadcast to Server or sends directed presence stanza of type "unavailable" to Gateway or Legacy User.

    Example 31. Jabber User Sends Unavailable Presence

    <presence type='unavailable'/>

    Example 32. Jabber User's Server Broadcasts Unavailable Presence

    <presence type='unavailable'
          from='romeo@montague.net/orchard'
          to='aim.shakespeare.lit'/>

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

  3. Gateway logs Jabber User out of Legacy Service [A1].

  4. Gateway sends presence stanza of type "unavailable" to Jabber User.

    Example 33. Gateway Logs User Out

    <presence type='unavailable'
          from='aim.shakespeare.lit'
          to='romeo@montague.net/orchard'/>

  5. Use Case Ends.

4.5.2 Alternate Flows

  1. Legacy Service supports directed presence and Gateway receives presence stanza of type "unavailable" directed to a Legacy User:

    1. Gateway passes through directed unavailable presence to Legacy User.

      Example 34. Jabber User Becomes Unavailable

      <presence type='unavailable'
          from='romeo@montague.net/orchard'
          to='juliet@aim.shakespeare.lit'/>

    2. Use Case Ends.

4.6 Add Contact

After registering with the Gateway, the Jabber User may want to add Legacy Users to his or her Jabber roster.

4.6.1 Primary Flow

  1. Jabber User sends presence stanza of type "subscribe" to Legacy User.

    Example 35. Jabber User Sends Subscription Request to Legacy User

    <presence type='subscribe'
          from='romeo@montague.net'
          to='CapuletNurse@aim.shakespeare.lit'/>

    Note: As specified in XMPP IM, sending this packet will result in a "roster push" from the Server to all of the Jabber User's available resources.

  2. Gateway transforms subscription request and routes it to Legacy User.

  3. If Legacy User approves subscription request, Gateway sends presence stanza of type "subscribed" to Jabber User on behalf of Legacy User. [A1]

    Example 36. Gateway Approves Subscription Request on Behalf of Legacy User

    <presence type='subscribed'
          from='CapuletNurse@aim.shakespeare.lit'
          to='romeo@montague.net'/>

  4. Gateway sends available presence stanza to Jabber User on behalf of Legacy User.

    Example 37. Gateway Sends Legacy User's Current Presence Infromation to Jabber User

    <presence from='CapuletNurse@aim.shakespeare.lit'
          to='romeo@montague.net/orchard'/>

  5. Gateway sends presence stanza of type "subscribe" to Jabber User on behalf of Legacy User.

    Example 38. Gateway Sends Subscription Request to Jabber User on Behalf of Legacy User

    <presence type='subscribe'
          from='CapuletNurse@aim.shakespeare.lit'
          to='romeo@montague.net'/>

  6. Jabber User sends presence stanza of type "subscribed" to Legacy User.

    Example 39. Jabber User Approves Subscription Request

    <presence type='subscribed'
          from='romeo@montague.net'
          to='CapuletNurse@aim.shakespeare.lit'/>

  7. Use Case Ends.

4.6.2 Alternate Flows

  1. Legacy User denies subscription request:

    1. Gateway transforms subscription denial and routes it to Jabber User.

      Example 40. Legacy User Denies Subscription Request

      <presence type='unsubscribed'
          from='juliet@aim.shakespeare.lit'
          to='romeo@montague.net'/>

    2. Use Case Ends unsuccessfully.

4.7 Delete Contact

After adding a Legacy User to his or her Jabber roster, the Jabber User may want to delete that contact.

4.7.1 Primary Flow

  1. Jabber User sends IQ set qualified by the 'jabber:iq:roster' namespace, containing subscription attribute with value of "remove".

    Example 41. User Removes Roster Entry for Legacy User

    <iq type='set'
    from='romeo@montague.net/orchard'
    id='remove1'>
  <query xmlns='jabber:iq:roster'>
    <item jid='CapuletNurse@aim.shakespeare.lit'
          subscription='remove'/>
  </query>
</iq>

  2. Server sends normal "roster push" to Jabber User (see XMPP IM) and sends presence stanzas of type "unsubscribe", "unsubscribed", and "unavailable" to Legacy User.

    Example 42. Server Sends Presence Changes to Legacy User

    <presence type='unsubscribe'
          from='romeo@montague.net'
          to='CapuletNurse@aim.shakespeare.lit'/>

<presence type='unsubscribed'
          from='romeo@montague.net'
          to='CapuletNurse@aim.shakespeare.lit'/>

<presence type='unavailable'
          from='romeo@montague.net/orchard'
          to='CapuletNurse@aim.shakespeare.lit'/>

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

  4. Use Case Ends.

4.7.2 Alternate Flows

None.

4.8 Send Message

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 Multi-User Chat [5], are out of scope).

4.8.1 Primary Flow

  1. Jabber User sends message stanza to Legacy User.

    Example 43. Jabber User Sends Message to Legacy User

    <message from='romeo@montague.net/orchard'
         to='juliet@aim.shakespeare.lit'
         type='chat'>
  <body>Neither, fair saint, if either thee dislike.</body>
</message>

  2. Gateway transforms message to legacy protocol and sends to Legacy User [A1].

  3. Use Case Ends.

4.8.2 Alternate Flows

  1. Legacy Service reports error.

  2. Gateway sends appropriate error to Jabber User:

    • "Not Found" -- Legacy User address is not valid).

    • "Registration Required" -- Jabber User is not registered with Gateway).

    • "Service Unavailable" -- Legacy User is offline and Legacy Service does not provide offline message storage).

    • "Remote Server Error" -- Legacy Service cannot be reached).

    For mapping of these error codes to XMPP-compliant error conditions, refer to Error Condition Mappings [6].

  3. Use Case Ends unsuccessfully.

5. Legacy User Use Cases

5.1 Add Contact

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.

5.1.1 Primary Flow

  1. Legacy User requests subscription to Jabber User (using legacy protocol).

  2. 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").

    Example 44. Gateway Sends Subscription Request on Behalf of Legacy User

    <presence type='subscribe'
          from='CapuletNurse@aim.shakespeare.lit'
          to='romeo@montague.net'/>

  3. Jabber User approves subscription request by sending presence stanza of type "subscribed" to Legacy User [A1].

    Example 45. Jabber User Approves Subscription Request

    <presence type='subscribed'
          from='romeo@montague.net'
          to='CapuletNurse@aim.shakespeare.lit'/>

  4. Gateway sends Jabber User's presence information to Legacy User.

  5. Jabber User's Client sends presence stanza of type "subscribe" to Legacy User.

    Example 46. Jabber User Sends Subscription Request to Legacy User

    <presence type='subscribe'
          from='romeo@montague.net'
          to='CapuletNurse@aim.shakespeare.lit'/>

  6. Gateway sends presence stanza of type "subscribed" to Jabber User on behalf of Legacy User.

    Example 47. Gateway Approves Subscription Request on Behalf of Legacy User

    <presence type='subscribed'
          from='CapuletNurse@aim.shakespeare.lit'
          to='romeo@montague.net'/>

  7. Gateway sends Legacy User's presence information to Jabber User.

    Example 48. Gateway Sends Legacy User's Current Presence Information to Jabber User

    <presence from='CapuletNurse@aim.shakespeare.lit'
          to='romeo@montague.net/orchard'/>

  8. Use Case Ends.

5.1.2 Alternate Flows

  1. Jabber User denies subscription request:

    1. Jabber User sends presence stanza of type "unsubscribed" to Legacy User.

      Example 49. Jabber User Denies Subscription Request

      <presence type='unsubscribed'
          from='romeo@montague.net'
          to='CapuletNurse@aim.shakespeare.lit'/>

    2. Gateway cleans up subscription state and MUST NOT send Jabber User's presence to Legacy User.

    3. Use Case Ends unsuccessfully.

5.2 Delete Contact

After adding the Jabber User to his or her legacy contact list, the Legacy User may want to delete the Jabber User.

5.2.1 Primary Flow

  1. Legacy User deletes Jabber User (using legacy protocol).

  2. Gateway sends presence stanzas of type "unsubscribe" and "unsubscribed" to Jabber User on behalf of Legacy User.

    Example 50. Gateway Cleans Up Subscription on Behalf of Legacy User

    <presence type='unsubscribe'
          from='CapuletNurse@aim.shakespeare.lit'
          to='romeo@montague.net'/>

<presence type='unsubscribed'
          from='CapuletNurse@aim.shakespeare.lit'
          to='romeo@montague.net'/>

<presence type='unavailable'
          from='CapuletNurse@aim.shakespeare.lit'
          from='romeo@montague.net/orchard'/>

  3. Jabber User's server performs defined functionality for handling presence stanzas of type "unsubscribe" and "unsubscribed" (see XMPP IM).

  4. Use Case Ends.

5.2.2 Alternate Flows

None.

5.3 Send Message

Naturally, the Legacy User may want to exchange messages with the Jabber User. Here again, groupchat messages are out of scope.

5.3.1 Primary Flow

  1. Legacy User sends message to Jabber User using legacy protocol.

  2. Gateway transforms message and routes to Jabber User.

    Example 51. Legacy User Sends Message to Jabber User

    <message from='juliet@aim.shakespeare.lit'
         to='romeo@montague.net/orchard'>
  <body>Art thou not Romeo, and a Montague?</body>
</message>

    Note: If the Legacy Service to which the Gateway connects does not support a concept equivalent to that of Jabber "resources" as described in XMPP Core, 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.

  3. Jabber User's Server delivers message or (optionally) stores it for later retrieval.

  4. Use Case Ends.

5.3.2 Alternate Flows

None.

6. Addressing

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

Usernames on legacy IM services are not necessarily compatible with Jabber usernames as specified by the Nodeprep profile of stringprep defined in XMPP Core [7], and some legacy services use addresses of the form <user@domain>. Both of these cases must be handled by the Jabber gateway to the relevant service, as well as by the Jabber clients which interact with that gateway. There are two known cases:

  1. AOL screen names used in AIM are allowed to contain spaces, which are illegal in the node identifier portion of a Jabber Identifier. However, AOL screen names containing spaces (e.g., "King Lear") are equivalent to the same screen name without spaces ("KingLear"); therefore, spaces in the legacy address MUST be removed when constructing a JabberID for the legacy user (e.g., "KingLear@aim.shakespeare.lit").

  2. MSN addresses used in MSN Messenger are of the form <user@domain>. Because the '@' character is illegal in the node identifier portion of a Jabber Identifier, it MUST be escaped or transformed when constructing a JabberID for the legacy user. The traditional convention in the Jabber community has been to replace the '@' character with the '%' character. Although we might not design such a method today, there is no good reason to define a new method that breaks backward compatibility; therefore, the traditional substitution MUST be used.

There are no known issues with addresses used in legacy services other than AIM and MSN (e.g., ICQ and Yahoo).

In the past, some gateways and clients used the undocumented 'jabber:iq:gateway' namespace to "negotiate" address conversion for any particular contact address on the legacy service. This use is not recommended, for several reasons:

  1. The only known issues with address mapping are those described above, so a generalized solution is not necessary.

  2. The jabber:iq:gateway protocol provided text for the "prompt" shown to the user (e.g., "Please enter the AOL Screen Name of the person you would like to contact") as well as a name for the prompted item (e.g., "Screen Name"); however, this text is provided in English and does not take into account localization for non-English speakers or customization in particular clients, so it is better to let the client determine both the descriptive text and the prompt name based on the identity of the gateway as determined using Service Discovery or Agent Information.

Naturally, clients and gateways are free to continue using the "jabber:iq:gateway" protocol, which may be documented for historical purposes in a future specification.

The following table will assist implementers with mapping of gateway identities to English-language prompt items (client developers or translators creating non-English-language interfaces should determine the localized name for these prompt items if available):

Table 2: Prompt Item Mapping (English)

Legacy Service Service Discovery Identity Prompt Item
AOL Instant Messenger <identity category='gateway' type='aim'/> Screen Name
ICQ <identity category='gateway' type='icq'/> UIN
MSN Messenger <identity category='gateway' type='msn'/> Address
Yahoo! Instant Messenger <identity category='gateway' type='yahoo'/> ID

7. Contact Lists

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 XMPP IM. Therefore, a gateway SHOULD instead send the legacy contact list items to the Jabber User via the Roster Item Exchange [8] protocol.

8. Business Rules

The following business rules apply:

  1. A client SHOULD send a Service Discovery request to the gateway (and/or an Agent Information request to the gateway's parent) before requesting registration information.

  2. A gateway SHOULD support the Service Discovery protocol.

  3. A gateway SHOULD support the Agent Information protocol, although it is deprecated.

  4. A gateway SHOULD map, as best it can, the legacy registration fields onto the fields defined for the 'jabber:iq:register' namespace.

  5. A gateway SHOULD NOT attempt to emulate offline message storage functionality for legacy services that lack such functionality.

  6. 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:

9. Security Considerations

As defined herein, a gateway is a client proxy, 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:

There are obvious security concerns with this approach. The concerns include:

  1. 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.
  2. 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).
  3. 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.

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 use open protocols such as Jabber/XMPP, thus making it possible to deploy secure server federation between a legacy service and Jabber/XMPP domains.

10. IANA Considerations

This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [9].

11. Jabber Registrar Considerations

No namespaces or parameters need to be registered with the Jabber Registrar [10] as a result of this JEP.

Notes

1. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.

2. JEP-0094: Agent Information <http://www.jabber.org/jeps/jep-0094.html>.

3. JEP-0077: In-Band Registration <http://www.jabber.org/jeps/jep-0077.html>.

4. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.

5. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.

6. JEP-0086: Error Condition Mappings <http://www.jabber.org/jeps/jep-0086.html>.

7. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.

8. JEP-0093: Roster Item Exchange <http://www.jabber.org/jeps/jep-0093.html>.

9. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

10. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.

Revision History

Version 0.8 (2004-05-07)

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. (psa)

Version 0.7 (2004-03-31)

Cleaned up several notes, examples, and business rules based on feedback received on list. (psa)

Version 0.6 (2004-03-08)

Added note about 'from' address on presence notifications and messages received through gateways from legacy users. (psa)

Version 0.5 (2004-01-21)

Further specified the rationale for deprecating the "jabber:iq:gateway" protocol. (psa)

Version 0.4 (2004-01-05)

Added Edit Registration use case; modified handling of legacy contact lists to conform to XMPP IM; modified addressing rules; defined gateway startup and shutdown behavior; included XMPP error handling. (psa)

Version 0.3 (2003-12-10)

Added security considerations; defined handling of legacy contact lists. (psa)

Version 0.2 (2003-12-03)

Corrected some errors; clarified some ambiguities; added protocol flows. (psa)

Version 0.1 (2003-06-25)

Initial version. (psa/dss)

END