| Network Working Group | P. Saint-Andre |
| Internet-Draft | Cisco Systems, Inc. |
| Intended status: Standards Track | A. Houri |
| Expires: March 09, 2014 | IBM |
| J. Hildebrand | |
| Cisco Systems, Inc. | |
| September 05, 2013 |
Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling
draft-ietf-stox-core-04
As a foundation for the definition of bidirectional 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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 09, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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:
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.
The discussion venue for this document is the mailing list of the STOX WG; visit https://www.ietf.org/mailman/listinfo/stox for subscription information and discussion archives.
A number of terms used here are explained in [RFC3261] and [RFC6120].
Several examples use the "XML Notation" from the IRI specification [RFC3987] to represent Unicode characters outside the ASCII range (e.g., the string "ř" stands for the Unicode character LATIN SMALL LETTER R WITH CARON).
The 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 [RFC2119].
Protocol translation between SIP and XMPP could occur in a number of different entities, depending on the architecture of real-time communication deployments. For example, protocol translation could occur within a multi-protocol server (which uses application-specific connection managers to initiate traffic to and accept traffic from clients or other servers natively using SIP/SIMPLE, XMPP, etc.), within a multi-protocol client (which enables a user to establish connections natively with various servers using SIP/SIMPLE, XMPP, etc.), or within a gateway that acts as a dedicated protocol translator (which takes one protocol as input and provides another protocol as output).
This document assumes that the protocol translation will occur within a gateway. (This assumption is 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 (naturally, these logical functions could occur in one and the same actual translator).
This document assumes that a gateway will translate directly from one protocol to the other. For the sake of the examples, we further assume that protocol translation will occur within a gateway in the source domain, so that information generated by the user of an XMPP service will be translated by a gateway within the trust domain of that XMPP service, and information generated by the user of a SIP service will be translated by a gateway within the trust domain of that SIP service. However, nothing in this document ought to be taken as recommending against protocol translation at the destination domain.
An architectural diagram for a possible 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:
##@#######################################################
# # #
# +-------------+----+ # +----+-------------+ #
# | example.net | GW |---#---| GW | example.com | #
# +-------------+----+ # +----+-------------+ #
# | # | #
# romeo@example.net # juliet@example.com #
# # #
##########################################################
The architecture assumptions underlying this document imply that communication between a SIP-based service and an XMPP-based service will take place using interdomain federation.
When an XMPP service receives an XMPP stanza whose 'to' address specifies or includes a domain other than the domain of the XMPP service, it needs to determine whether the destination domain offers an XMPP service or a SIP service. To do so, it performs one or more DNS SRV lookups [RFC2782] for "_xmpp-server" records as specified in [RFC6120]. If the response returns a hostname, the service can attempt XMPP communication. If not, the service can attempt to locate a SIP service for that domain using the procedures specified in [RFC3263].
Similarly, when a SIP service receives a SIP message whose Request-URI specifies or includes a domain other than the domain of the SIP service, it needs to determine whether the destination domain offers a SIP service or an XMPP service. To do so, it uses the procedures specified in [RFC3263]. If that response returns a hostname, the service can attempt SIP communication. If not, the service can perform one or more DNS SRV lookups [RFC2782] for "_xmpp-server" records as specified in [RFC6120].
In both cases, the service in question might have previously determined that the foreign domain is a SIP service or an XMPP service, in which case it would not need to perform the relevant DNS lookups. The caching of such information is a matter of implementation and local service policy, and is therefore out of scope for this document.
The basic SIP address format is a 'sip' or 'sips' URI as specified in [RFC3261]. When a SIP entity supports extensions for instant messaging it might be identified by an 'im' URI as specified in the Common Profile for Instant Messaging [RFC3860] (see [RFC3428]) and when a SIP entity spports extensions for presence it might be identified by a 'pres' URI as specified in the Common Profile for Presence [RFC3859] (see [RFC3856]). SIP entities typically also support the 'tel' URI scheme [RFC3966] and might support other URI schemes as well.
The XMPP address format is specified in [RFC6122] (although note that XMPP URIs [RFC5122] are not used natively on the XMPP network); in addition, [RFC6121] encourages instant messaging and presence applications of XMPP to also support 'im' and 'pres' URIs as specified in [RFC3860] and [RFC3859] respectively, although such support might simply involve leaving resolution of such addresses up to an XMPP server.
In this document we primarily describe mappings for addresses of the form <user@domain>; however, we also provide guidelines for mapping the addresses of specific user agent instances, which take the form of Globally Routable User Agent URIs (GRUUs) in SIP and "resourceparts" in XMPP. Mapping of protocol-specific identifiers (such as telephone numbers) is out of scope for this specification. 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 (IDNs) into non-internationalized domain names (IDNs are not allowed in the SIP address format, but are allowed in the XMPP address via Internationalized Domain Names in Applications, see [RFC6122] and [I-D.ietf-xmpp-6122bis]). Therefore, in the following sections we focus primarily on the local part of an address (these are called variously "usernames", "instant inboxes", "presentities", and "localparts" in the protocols at issue), secondarily on the instance-specific part of an address, and not at all on the domain-name part of an address.
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 need to be mapped appropriately in order to ensure interworking across systems.
The local part of a sip:/sips: URI inherits from the "userinfo" rule in [RFC3986] 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 of an im:/pres: URI inherits from the "dot-atom-text" rule in [RFC5322] 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 of an XMPP address allows any ASCII character except space, controls, and the " & ' / : < > @ characters.
To summarize the foregoing information, the following table lists the allowed and disallowed characters in the local part of identifiers for each protocol (aside from the alphanumeric, space, and control characters), in order by hexadecimal character number (where each "A" row shows the allowed characters and each "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 the local part of an address from one scheme to another, an application SHOULD proceed as follows:
The meaning of a resourcepart in XMPP (i.e., the portion of a JID after the slash character, such as "foo" in "user@example.com/foo") matches that of a Globally Routable User Agent URI (GRUU) in SIP [RFC5627]. In both cases, these constructs identify a particular device associated with the bare JID ("localpart@domainpart") of an XMPP entity or with the Address of Record (AOR) of a SIP entity. Therefore, it is reasonable to map the value of a "gr" URI parameter to an XMPP resourcepart, and vice-versa.
The mapping described here does not apply to temporary GRUUs, only to GRUUs associated with an Address of Record.
The "gr" URI parameter in SIP can contain only characters from the ASCII range (although characters outside the ASCII range can be percent-encoded in accordance with [RFC3986], whereas an XMPP resourcepart can contain nearly any Unicode character [UNICODE]. Therefore Unicode characters outside the ASCII range need to be mapped to characters in the ASCII range, as described below.
The following is a high-level algorithm for mapping a sip:, sips:, im:, or pres: URI to an XMPP address:
Several examples follow, illustrating steps 3, 5, and 8 described above (the percent-encoded string "%C3%BC" and XML Notation string "�FC;" both represent the Unicode character LATIN SMALL LETTER U WITH DIAERESIS).
+----------------------------+--------------------------+
| SIP URI | XMPP Address |
+----------------------------+--------------------------+
| sip:f%C3%BC@sip.example | f�FC;@sip.example |
| sip:o'malley@sip.example | o\27malley@sip.example |
| sip:foo@sip.example;gr=bar | foo@sip.example/bar |
+----------------------------+--------------------------+
The following is a high-level algorithm for mapping an XMPP address to a sip:, sips:, im:, or pres: URI:
Several examples follow, illustrating steps 3, 5, and 8 described above (the percent-encoded string "%C3%BC" and XML Notation string "�FC;" both represent the Unicode character LATIN SMALL LETTER U WITH DIAERESIS).
+---------------------------+---------------------------------+
| XMPP Address | SIP URI |
+---------------------------+---------------------------------+
| tsch�FCss@xmpp.example | sip:tsch%C3%BCss@xmpp.example |
| m\26m@xmpp.example | sip:m&m@xmpp.example |
| baz@xmpp.example/qux | sip:baz@xmpp.example;gr=qux |
+---------------------------+---------------------------------+
Various differences between XMPP error conditions and SIP response codes make it hard to provide a comprehensive and consistent mapping between the protocols:
As a result of these and other factors, the mapping of error conditions and response codes is more of an art than a science. This document provides suggested mappings, but implementations are free to deviate from these mappings if needed. Also, because no XMPP error conditions are equivalent to the provisional (1xx) and successful (2xx) response codes in SIP, this document suggests mappings only for the SIP redirection (3xx), request failure (4xx), server failure (5xx), and global failure (6xx) response code families.
Supplementary information about SIP response codes can be expressed in the "Reason-Phrase" in the Status-Line header, and detailed information about XMPP error conditions can be expressed in the <text/> child of the <error/> element. Although the semantics of these constructs are specified in a slightly different way, it is reasonable for a gateway to map these constructs to each other if they are found in a SIP response or XMPP error stanza.
The mapping of specific XMPP error conditions to SIP response codes SHOULD be as described in the following table.
Table 2: Mapping of XMPP error conditions to SIP response codes
+------------------------------+---------------------+
| XMPP Error Condition | SIP Response Code |
+------------------------------+---------------------+
| <bad-request/> | 400 |
| <conflict/> | 400 |
| <feature-not-implemented/> | 405 or 501 (1) |
| <forbidden/> | 403 or 603 (2) |
| <gone/> | 410 |
| <internal-server-error/> | 500 |
| <item-not-found/> | 404 or 604 (2) |
| <jid-malformed/> | 400 |
| <not-acceptable/> | 406 or 606 (2) |
| <not-allowed/> | 403 |
| <not-authorized/> | 401 |
| <policy-violation/> | 403 |
| <recipient-unavailable/> | 480 or 600 (2) |
| <redirect/> | 302 |
| <registration-required/> | 407 |
| <remote-server-not-found/> | 404 or 408 (3) |
| <remote-server-timeout/> | 408 |
| <resource-constraint/> | 500 |
| <service-unavailable/> | see note (4) below |
| <subscription-required/> | 407 |
| <undefined-condition/> | 400 |
| <unexpected-request/> | 491 or 400 |
+------------------------------+---------------------+
The mapping of SIP response codes to XMPP error conditions SHOULD be as described in the following table.
The codes listed below are limited to those defined in the core SIP specification [RFC3261] and in RFCs that formally update [RFC3261]. If a gateway encounters a SIP response code that is not listed below, it SHOULD map a 3xx-series code to <redirect/>, a 4xx-series code to <bad-request/>, a 5xx-series code to <internal-server-error>, and a 6xx-series code to <recipient-unavailable/>.
Table 3: Mapping of SIP response codes to XMPP error conditions
+---------------------+---------------------------------+
| SIP Response Code | XMPP Error Condition |
+---------------------+---------------------------------+
| 3xx | <redirect/> |
| 300 | <redirect/> |
| 301 | <gone/> |
| 302 | <redirect/> |
| 305 | <redirect/> |
| 380 | <not-acceptable/> |
| 4xx | <bad-request/> |
| 400 | <bad-request/> |
| 401 | <not-authorized/> |
| 402 | see note (1) below |
| 403 | <forbidden/> (2) |
| 404 | <item-not-found/> (3) |
| 405 | <feature-not-implemented/> |
| 406 | <not-acceptable/> |
| 407 | <registration-required/> |
| 408 | <remote-server-timeout/> (4) |
| 410 | <gone/> |
| 413 | <policy-violation/> |
| 414 | <policy-violation/> |
| 415 | <not-acceptable/> |
| 416 | <not-acceptable/> |
| 420 | <feature-not-implemented/> |
| 421 | <not-acceptable/> |
| 423 | <resource-constraint/> |
| 430 | <recipient-unavailable/> (5) |
| 439 | <feature-not-implemented/> (5) |
| 440 | <policy-violation/> (6) |
| 480 | <recipient-unavailable/> |
| 481 | <item-not-found/> |
| 482 | <not-acceptable/> |
| 483 | <not-acceptable/> |
| 484 | <item-not-found/> |
| 485 | <item-not-found/> |
| 486 | <recipient-unavailable/> |
| 487 | <recipient-unavailable/> |
| 488 | <not-acceptable/> |
| 489 | <policy-violation/> (7) |
| 491 | <unexpected-request/> |
| 493 | <bad-request/> |
| 5xx | <internal-server-error/> |
| 500 | <internal-server-error/> |
| 501 | <feature-not-implemented/> |
| 502 | <remote-server-not-found/> |
| 503 | see note in Section 6.1 |
| 504 | <remote-server-timeout/> |
| 505 | <not-acceptable/> |
| 513 | <policy-violation/> |
| 6xx | <recipient-unavailable/> |
| 600 | <recipient-unavailable/> |
| 603 | <recipient-unavailable/> |
| 604 | <item-not-found/> |
| 606 | <not-acceptable/> |
+---------------------+---------------------------------+
This document makes no requests of IANA.
Detailed security considerations for SIP are given in [RFC3261] and for XMPP in [RFC6120].
A gateway between SIP and XMPP (in either direction) effectively acts as a SIP back-to-back user agent ("B2BUA"). The amplification vulnerability described in [RFC5393] can manifest itself with B2BUAs (see also [I-D.ietf-straw-b2bua-loop-detection]), and a gateway SHOULD implement the loop-detection methods defined in that specification to help mitigate the possibility of amplification attacks. Note that, although it would be possible to signal the Max-Forwards and Max-Breadth SIP headers over XMPP using the Stanza Headers and Internet Metadata (SHIM) extension [XEP-0131], that extension is not widely implemented; therefore, defenses against excessive looping and amplification attacks when messages pass back and forth through SIP and XMPP networks is out of scope for this document. However, it ought to be addressed in the future, and implementations are strongly encouraged to incorporate appropriate counter measures wherever possible.
The authors wish to thank the following individuals for their feedback: Mary Barnes, Mike De Vries, Fabio Forno, Adrian Georgescu, Philipp Hancke, Saul Ibarra Corretge, Markus Isomaki, Olle Johansson, Paul Kyzivat, Salvatore Loreto, Daniel-Constantin Mierla, Tory Patnoe, and Robert Sparks.