Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core
draft-saintandre-sip-xmpp-core-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 7, 2008.

Abstract

As a foundation for the definition of application-specific, bi-directional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.

Table of Contents

1.  Introduction
2.  Architectural Assumptions
3.  Address Mapping
    3.1.  Overview
    3.2.  SIP to XMPP
    3.3.  XMPP to SIP
4.  Error Condition Mapping
    4.1.  XMPP to SIP
    4.2.  SIP to XMPP
5.  Security Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

The IETF has worked on two signalling technologies that can be used for multimedia session negotiation, messaging, presence, capabilities discovery, notifications, and other application-level functionality:

• The Session Initiation Protocol [SIP] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.), along with various SIP extensions developed within the SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Working Group.
• The Extensible Messaging and Presence Protocol [XMPP] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.), along with various XMPP extensions developed by the IETF as well as by the XMPP Standards Foundation.

Because these technologies are widely deployed, it is important to clearly define mappings between them for the sake of interworking. This document inaugurates a series of SIP-XMPP interworking specifications by defining the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.

Note: The capitalized key words "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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [TERMS].

2.  Architectural Assumptions

Protocol translation between SIP and XMPP could occur in a number of different entities, depending on the architecture of presence and messaging deployments. For example, protocol translation could occur within a multi-protocol server, within a multi-protocol client, or within a gateway that acts as a dedicated protocol translator.

This document assumes that the protocol translation will occur within a gateway. (This assumption not meant to discourage protocol translation within multi-protocol clients or servers; instead, this assumption is followed mainly to clarify the discussion and examples so that the protocol translation principles can be more easily understood and can be applied by client and server implementors with appropriate modifications to the examples and terminology.) Specifically, we assume that the protocol translation will occur within an "XMPP-to-SIP gateway" that translates XMPP syntax and semantics on behalf of an XMPP service when communicating with SIP services and/or within a "SIP-to-XMPP gateway" that translates SIP syntax and semantics on behalf of a SIP service when communicating with XMPP services.

This document assumes that a gateway will translate directly from one protocol to the other. We further assume that protocol translation will occur within a gateway in the source domain, so that messages and presence information generated by the user of an XMPP service will be translated by a gateway within the trust domain of that XMPP service, and messages and presence information generated by the user of a SIP service will be translated by a gateway within the trust domain of that SIP service.

An architectural diagram for a typical gateway deployment is shown below, where the entities have the following significance and the "#" character is used to show the boundary of a trust domain:

• romeo@example.net -- a SIP user.
• example.net -- a SIP service.
• s2x.example.net -- a SIP-to-XMPP gateway.
• juliet@example.com -- an XMPP user.
• example.com -- an XMPP service.
• x2s.example.com -- an XMPP-to-SIP gateway.

#####################################################################
#                               #                                   #
#         +-- s2x.example.net---#------------- example.com          #
#         |                     #               |     |             #
#  example.net -----------------#--- x2s.example.com  |             #
#       |                       #                     |             #
#       |                       #                     |             #
#  romeo@example.net            #               juliet@example.com  #
#                               #                                   #
#####################################################################

3.  Address Mapping

3.1.  Overview

The basic SIP address format is a "sip:" or "sips:" URI as specified in [SIP] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). When a SIP entity supports extensions for instant messageing it may be identified by an 'im:' URI as specified in [CPIM] (Peterson, J., “Common Profile for Instant Messaging (CPIM),” August 2004.) (see [SIP‑IM] (Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, “Session Initiation Protocol (SIP) Extension for Instant Messaging,” December 2002.)) and when a SIP entity spports extensions for presence it may be identified by a 'pres:' URI as specified in [CPP] (Peterson, J., “Common Profile for Presence (CPP),” August 2004.) (see [SIP‑PRES] (Rosenberg, J., “A Presence Event Package for the Session Initiation Protocol (SIP),” August 2004.)).

The XMPP address format is specified in [XMPP] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.); as specified in [XMPP‑IM] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” October 2004.), instant messaging and presence applications of XMPP must also support 'im:' and 'pres:' URIs as specified in [CPIM] (Peterson, J., “Common Profile for Instant Messaging (CPIM),” August 2004.) and [CPP] (Peterson, J., “Common Profile for Presence (CPP),” August 2004.) respectively, although such support may simply involve leaving resolution of such addresses up to an XMPP server.

In this document we describe mappings for addresses of the form <user@domain> only, ignoring (for the purpose of address mapping) any protocol-specific extensions such as SIP telephone numbers and passwords or XMPP resource identifiers. In addition, we have ruled the mapping of domain names as out of scope for now since that is a matter for the Domain Name System; specifically, the issue for interworking between SIP and XMPP relates to the translation of fully internationalized domain names (which the SIP address format does not allow, but which the XMPP address format does allow via [IDNA] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.)) into non-internationalized domain names. Therefore, in the following sections we discuss local-part addresses only (these are called variously "usernames", "instant inboxes", "presentities", and "node identifiers" in the protocols at issue).

The sip:/sips:, im:/pres:, and XMPP address schemes allow different sets of characters (although all three allow alphanumeric characters and disallow both spaces and control characters). In some cases, characters allowed in one scheme are disallowed in others; these characters must be mapped appropriately in order to ensure interworking across systems.

The local-part address in sip:/sips: URIs inherits from the "userinfo" rule in [URI] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) with several changes; here we discuss the SIP "user" rule only:

   user             =  1*( unreserved / escaped / user-unreserved )
   user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
   unreserved       =  alphanum / mark
   mark             =  "-" / "_" / "." / "!" / "~" / "*" / "'"
                       / "(" / ")"

Here we make the simplifying assumption that the local-part address in im:/pres: URIs inherits from the "dot-atom-text" rule in [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.) rather than the more complicated "local-part" rule:

   dot-atom-text =  1*atext *("." 1*atext)
   atext         =  ALPHA / DIGIT / ; Any character except controls,
                    "!" / "#" /     ;  SP, and specials.
                    "$" / "%" /     ;  Used for atoms
                    "&" / "'" /
                    "*" / "+" /
                    "-" / "/" /
                    "=" / "?" /
                    "^" / "_" /
                    "`" / "{" /
                    "|" / "}" /
                    "~"

The local-part address in XMPP addresses allows any US-ASCII character except space, controls, and the " & ' / : < > @ characters.

Therefore, following table lists the allowed and disallowed characters in the local-part addresses of each protocol (aside from the alphanumeric, space, and control characters), in order by hexadecimal character number (where the "A" row shows the allowed characters and the "D" row shows the disallowed characters).

Table 1: Allowed and disallowed characters

+---+----------------------------------+
| SIP/SIPS CHARACTERS                  |
+---+----------------------------------+
| A | !  $ &'()*+,-./ ; = ?     _    ~ |
| D |  "# %          : < > @[\]^ `{|}  |
+---+----------------------------------+
| IM/PRES CHARACTERS                   |
+---+----------------------------------+
| A | ! #$%&'  *+ - /   = ?    ^_`{|}~ |
| D |  "     ()  , . :;< > @[\]        |
+---+----------------------------------+
| XMPP CHARACTERS                      |
+---+----------------------------------+
| A | ! #$%  ()*+,-.  ; = ? [\]^_`{|}~ |
| D |  "   &'       /: < > @           |
+---+----------------------------------+

When transforming a local-part address from one scheme to another, an application SHOULD proceed as follows:

1. Unescape any escaped characters in the source address (e.g., from SIP to XMPP unescape "%2F" to "/" and from XMPP to SIP unescape "\27" to "'").
2. Leave unmodified any characters that are allowed in the destination scheme.
3. Escape any characters that are allowed in the source scheme but reserved in the destination scheme, as escaping is defined for the destination scheme. In particular:
   • Where the destination scheme is a URI (i.e., an im:, pres:, sip:, or sips: URI), each reserved character MUST be percent-encoded to "%hexhex" as specified in Section 2.6 of [URL‑GUIDE] (Hansen, T., Hardie, T., and L. Masinter, “Guidelines and Registration Procedures for New URI Schemes,” February 2006.) (e.g., when transforming from XMPP to SIP, encode "/" as "%2F").
   • Where the destination scheme is a native XMPP address, each reserved character MUST be encoded to "\hexhex" as specified in [XEP‑0106] (Saint-Andre, P. and J. Hildebrand, “JID Escaping,” May 2005.) (e.g., when transforming from SIP to XMPP, encode "'" as "\27").

3.2.  SIP to XMPP

The following is a high-level algorithm for mapping a sip:, sips:, im:, or pres: URI to an XMPP address:

1. Remove URI scheme.
2. Split at the first '@' character into local-part and hostname (mapping the latter is out of scope).
3. Translate %hexhex to equivalent octets.
4. Treat result as a UTF-8 string.
5. Translate "&" to "\26", "'" to "\27", and "/" to "\2f" respectively in order to properly handle the characters disallowed in XMPP addresses but allowed in sip:/sips: URIs and im:/pres: URIs as shown in Column 3 of Table 3 above (this is consistent with [XEP‑0106] (Saint-Andre, P. and J. Hildebrand, “JID Escaping,” May 2005.)).
6. Apply Nodeprep profile of [STRINGPREP] (Hoffman, P. and M. Blanchet, “Preparation of Internationalized Strings ("STRINGPREP"),” December 2002.) (as specified in [XMPP] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.)) for canonicalization (OPTIONAL).
7. Recombine local-part with mapped hostname to form local@domain address.

3.3.  XMPP to SIP

The following is a high-level algorithm for mapping an XMPP address to a sip:, sips:, im:, or pres: URI:

1. Split XMPP address into node identifier (local-part; mapping described in remaining steps), domain identifier (hostname; mapping is out of scope), and resource identifier (specifier for particular device or connection; discard this for cross-system interworking).
2. Apply Nodeprep profile of [STRINGPREP] (Hoffman, P. and M. Blanchet, “Preparation of Internationalized Strings ("STRINGPREP"),” December 2002.) (as specified in [XMPP] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.)) for canonicalization (OPTIONAL).
3. Translate "\26" to "&", "\27" to "'", and "\2f" to "/" respectively (this is consistent with [XEP‑0106] (Saint-Andre, P. and J. Hildebrand, “JID Escaping,” May 2005.)).
4. Determine if the foreign domain supports im: and pres: URIs (discovered via [SRV] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.) lookup as specified in [XMPP‑IM] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” October 2004.)), else assume that the foreign domain supports sip:/sips: URIs.
5. If converting into im: or pres: URI, for each byte, if the byte is in the set (),.;[\] (i.e., the partial complement from Row 3, Column 2 of Table 3 above) or is a UTF-8 character outside the US-ASCII range then transform that byte to %hexhex. If converting into sip: or sips: URI, for each byte, if the byte is in the set #%[\]^`{|} (i.e., the partial complement from Row 3, Column 1 of Table 3 above) or is a UTF-8 character outside the US-ASCII range then transform that byte to %hexhex.
6. Combine resulting local-part with mapped hostname to form local@domain address.
7. Prepend with 'im:' scheme (for XMPP <message/> stanzas) or 'pres:' scheme (for XMPP <presence/> stanzas) if foreign domain supports these, else prepend with 'sip:' or 'sips:' scheme according to local service policy.

4.  Error Condition Mapping

SIP response codes are specified in [SIP] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) and XMPP error conditions are specified in [XMPP] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.).

4.1.  XMPP to SIP

Table 8: Mapping of XMPP error conditions to SIP response codes

   +------------------------------+---------------------+
   |  XMPP Error Condition        |  SIP Response Code  |
   +------------------------------+---------------------+
   |  <bad-request/>              | 400                 |
   |  <conflict/>                 | 400                 |
   |  <feature-not-implemented/>  | 501                 |
   |  <forbidden/>                | 403                 |
   |  <gone/>                     | 410                 |
   |  <internal-server-error/>    | 500                 |
   |  <item-not-found/>           | 404                 |
   |  <jid-malformed/>            | 484                 |
   |  <not-acceptable/>           | 406                 |
   |  <not-allowed/>              | 405                 |
   |  <not-authorized/>           | 401                 |
   |  <payment-required/>         | 402                 |
   |  <recipient-unavailable/>    | 480                 |
   |  <redirect/>                 | 300                 |
   |  <registration-required/>    | 407                 |
   |  <remote-server-not-found/>  | 502                 |
   |  <remote-server-timeout/>    | 504                 |
   |  <resource-constraint/>      | 500                 |
   |  <service-unavailable/>      | 503                 |
   |  <subscription-required/>    | 407                 |
   |  <undefined-condition/>      | 400                 |
   |  <unexpected-request/>       | 491                 |
   +------------------------------+---------------------+

4.2.  SIP to XMPP

The mapping of SIP response codes to XMPP error conditions SHOULD be as follows (note that XMPP does not include 100-series or 200-series response codes, only error conditions):

Table 9: Mapping of SIP response codes to XMPP error conditions

   +---------------------+------------------------------+
   |  SIP Response Code  |  XMPP Error Condition        |
   +---------------------+------------------------------+
   |  300                |  <redirect/>                 |
   |  301                |  <gone/>                     |
   |  302                |  <redirect/>                 |
   |  305                |  <redirect/>                 |
   |  380                |  <not-acceptable/>           |
   |  400                |  <bad-request/>              |
   |  401                |  <not-authorized/>           |
   |  402                |  <payment-required/>         |
   |  403                |  <forbidden/>                |
   |  404                |  <item-not-found/>           |
   |  405                |  <not-allowed/>              |
   |  406                |  <not-acceptable/>           |
   |  407                |  <registration-required/>    |
   |  408                |  <service-unavailable/>      |
   |  410                |  <gone/>                     |
   |  413                |  <bad-request/>              |
   |  414                |  <bad-request/>              |
   |  415                |  <bad-request/>              |
   |  416                |  <bad-request/>              |
   |  420                |  <bad-request/>              |
   |  421                |  <bad-request/>              |
   |  423                |  <bad-request/>              |
   |  480                |  <recipient-unavailable/>    |
   |  481                |  <item-not-found/>           |
   |  482                |  <not-acceptable/>           |
   |  483                |  <not-acceptable/>           |
   |  484                |  <jid-malformed/>            |
   |  485                |  <item-not-found/>           |
   |  486                |  <service-unavailable/>      |
   |  487                |  <service-unavailable/>      |
   |  488                |  <not-acceptable/>           |
   |  491                |  <unexpected-request/>       |
   |  493                |  <bad-request/>              |
   |  500                |  <internal-server-error/>    |
   |  501                |  <feature-not-implemented/>  |
   |  502                |  <remote-server-not-found/>  |
   |  503                |  <service-unavailable/>      |
   |  504                |  <remote-server-timeout/>    |
   |  505                |  <not-acceptable/>           |
   |  513                |  <bad-request/>              |
   |  600                |  <service-unavailable/>      |
   |  603                |  <service-unavailable/>      |
   |  604                |  <item-not-found/>           |
   |  606                |  <not-acceptable/>           |
   +---------------------+------------------------------+

5.  Security Considerations

Detailed security considerations for SIP are given in [SIP] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) and for XMPP in [XMPP] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.).

6.  References

6.1. Normative References

6.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.