| Network Working Group | P. Saint-Andre |
| Internet-Draft | Cisco Systems, Inc. |
| Intended status: Informational | A. Houri |
| Expires: April 16, 2013 | IBM |
| J. Hildebrand | |
| Cisco Systems, Inc. | |
| October 15, 2012 |
Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core
draft-saintandre-sip-xmpp-core-02
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.
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 April 16, 2013.
Copyright (c) 2012 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.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
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 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 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:
#####################################################################
# # #
# +-- s2x.example.net---#------------- example.com #
# | # | | #
# example.net -----------------#--- x2s.example.com | #
# | # | #
# | # | #
# romeo@example.net # juliet@example.com #
# # #
#####################################################################
The basic SIP address format is a "sip:" or "sips:" URI as specified in [RFC3261]. When a SIP entity supports extensions for instant messageing it may 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 may be identified by a 'pres:' URI as specified in the Common Profile for Presence [RFC3859] (see [RFC3856]).
The XMPP address format is specified in [RFC6122]; as specified in [RFC6121], instant messaging and presence applications of XMPP must also support 'im:' and 'pres:' URIs as specified in [RFC3860] and [RFC3859] 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 Internationalized Domain Names in Applications, see [RFC6122] and [I-D.ietf-xmpp-6122bis]) 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 [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 address in im:/pres: URIs 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 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:
The following is a high-level algorithm for mapping a sip:, sips:, im:, or pres: URI to an XMPP address:
The following is a high-level algorithm for mapping an XMPP address to a sip:, sips:, im:, or pres: URI:
SIP response codes are specified in [RFC3261] and XMPP error conditions are specified in [RFC6120].
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 |
+------------------------------+---------------------+
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/> |
+---------------------+------------------------------+
Detailed security considerations for SIP are given in [RFC3261] and for XMPP in [RFC6120].
This document requests no actions of IANA.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3261] | Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. |
| [RFC3986] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. |
| [RFC4395] | Hansen, T., Hardie, T. and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", RFC 4395, February 2006. |
| [RFC6120] | Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011. |
| [RFC6122] | Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", RFC 6122, March 2011. |