Network Working Group P. Saint-Andre
Internet-Draft XMPP Standards Foundation
Intended status: Informational A. Houri
Expires: July 7, 2008 IBM
J. Hildebrand
Jabber, Inc.
January 4, 2008
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.
Copyright Notice
Copyright (C) The IETF Trust (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
Saint-Andre, et al. Expires July 7, 2008 [Page 1]
Internet-Draft SIP-XMPP Interworking: Core January 2008
mappings as well as the mapping of addresses and error conditions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architectural Assumptions . . . . . . . . . . . . . . . . . . 3
3. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 7
4. Error Condition Mapping . . . . . . . . . . . . . . . . . . . 8
4.1. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Saint-Andre, et al. Expires July 7, 2008 [Page 2]
Internet-Draft SIP-XMPP Interworking: Core January 2008
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:
o The Session Initiation Protocol [SIP], along with various SIP
extensions developed within the SIP for Instant Messaging and
Presence Leveraging Extensions (SIMPLE) Working Group.
o The Extensible Messaging and Presence Protocol [XMPP], 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 [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.
Saint-Andre, et al. Expires July 7, 2008 [Page 3]
Internet-Draft SIP-XMPP Interworking: Core January 2008
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:
o romeo@example.net -- a SIP user.
o example.net -- a SIP service.
o s2x.example.net -- a SIP-to-XMPP gateway.
o juliet@example.com -- an XMPP user.
o example.com -- an XMPP service.
o 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]. When a SIP entity supports extensions for instant
messageing it may be identified by an 'im:' URI as specified in
[CPIM] (see [SIP-IM]) and when a SIP entity spports extensions for
presence it may be identified by a 'pres:' URI as specified in [CPP]
(see [SIP-PRES]).
The XMPP address format is specified in [XMPP]; as specified in
[XMPP-IM], instant messaging and presence applications of XMPP must
also support 'im:' and 'pres:' URIs as specified in [CPIM] and [CPP]
respectively, although such support may simply involve leaving
resolution of such addresses up to an XMPP server.
Saint-Andre, et al. Expires July 7, 2008 [Page 4]
Internet-Draft SIP-XMPP Interworking: Core January 2008
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]) 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] 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]
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
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
Saint-Andre, et al. Expires July 7, 2008 [Page 5]
Internet-Draft SIP-XMPP Interworking: Core January 2008
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] (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] (e.g., when transforming from SIP to XMPP,
encode "'" as "\27").
Saint-Andre, et al. Expires July 7, 2008 [Page 6]
Internet-Draft SIP-XMPP Interworking: Core January 2008
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]).
6. Apply Nodeprep profile of [STRINGPREP] (as specified in [XMPP])
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] (as specified in [XMPP])
for canonicalization (OPTIONAL).
3. Translate "\26" to "&", "\27" to "'", and "\2f" to "/"
respectively (this is consistent with [XEP-0106]).
4. Determine if the foreign domain supports im: and pres: URIs
(discovered via [SRV] lookup as specified in [XMPP-IM]), 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.
Saint-Andre, et al. Expires July 7, 2008 [Page 7]
Internet-Draft SIP-XMPP Interworking: Core January 2008
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] and XMPP error conditions
are specified in [XMPP].
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):
Saint-Andre, et al. Expires July 7, 2008 [Page 8]
Internet-Draft SIP-XMPP Interworking: Core January 2008
Table 9: Mapping of SIP response codes to XMPP error conditions
Saint-Andre, et al. Expires July 7, 2008 [Page 9]
Internet-Draft SIP-XMPP Interworking: Core January 2008
+---------------------+------------------------------+
| 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/> |
+---------------------+------------------------------+
Saint-Andre, et al. Expires July 7, 2008 [Page 10]
Internet-Draft SIP-XMPP Interworking: Core January 2008
5. Security Considerations
Detailed security considerations for SIP are given in [SIP] and for
XMPP in [XMPP].
6. References
6.1. Normative References
[SIP] 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.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[URL-GUIDE]
Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", RFC 4395,
February 2006.
[XMPP] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004.
6.2. Informative References
[CPIM] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", RFC 3860, August 2004.
[CPP] Peterson, J., "Common Profile for Presence (CPP)",
RFC 3859, August 2004.
[IDNA] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[SIP-IM] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
Saint-Andre, et al. Expires July 7, 2008 [Page 11]
Internet-Draft SIP-XMPP Interworking: Core January 2008
[SIP-PRES]
Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[STRINGPREP]
Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("STRINGPREP")", RFC 3454,
December 2002.
[XEP-0106]
Saint-Andre, P. and J. Hildebrand, "JID Escaping", XSF
XEP 0106, May 2005.
[XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
RFC 3921, October 2004.
Authors' Addresses
Peter Saint-Andre
XMPP Standards Foundation
P.O. Box 1641
Denver, CO 80201
USA
Email: stpeter@jabber.org
Avshalom Houri
IBM
Building 18/D, Kiryat Weizmann Science Park
Rehovot 76123
Israel
Email: avshalom@il.ibm.com
Saint-Andre, et al. Expires July 7, 2008 [Page 12]
Internet-Draft SIP-XMPP Interworking: Core January 2008
Joe Hildebrand
Jabber, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO 80202
USA
Email: jhildebrand@jabber.com
Saint-Andre, et al. Expires July 7, 2008 [Page 13]
Internet-Draft SIP-XMPP Interworking: Core January 2008
Full Copyright Statement
Copyright (C) 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Saint-Andre, et al. Expires July 7, 2008 [Page 14]