idnits 2.17.1 draft-saintandre-sip-xmpp-core-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2009) is 5527 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4395 (ref. 'URL-GUIDE') (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 3490 (ref. 'IDNA') (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3454 (ref. 'STRINGPREP') (Obsoleted by RFC 7564) -- Obsolete informational reference (is this intentional?): RFC 3921 (ref. 'XMPP-IM') (Obsoleted by RFC 6121) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Cisco 4 Intended status: Informational A. Houri 5 Expires: September 9, 2009 IBM 6 J. Hildebrand 7 Cisco 8 March 8, 2009 10 Interworking between the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (XMPP): Core 12 draft-saintandre-sip-xmpp-core-01 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on September 9, 2009. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 As a foundation for the definition of application-specific, bi- 60 directional protocol mappings between the Session Initiation Protocol 61 (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this 62 document specifies the architectural assumptions underlying such 63 mappings as well as the mapping of addresses and error conditions. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Architectural Assumptions . . . . . . . . . . . . . . . . . . 4 69 3. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.3. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 8 73 4. Error Condition Mapping . . . . . . . . . . . . . . . . . . . 9 74 4.1. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.2. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 9 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 79 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 The IETF has worked on two signalling technologies that can be used 85 for multimedia session negotiation, messaging, presence, capabilities 86 discovery, notifications, and other application-level functionality: 88 o The Session Initiation Protocol [SIP], along with various SIP 89 extensions developed within the SIP for Instant Messaging and 90 Presence Leveraging Extensions (SIMPLE) Working Group. 91 o The Extensible Messaging and Presence Protocol [XMPP], along with 92 various XMPP extensions developed by the IETF as well as by the 93 XMPP Standards Foundation. 95 Because these technologies are widely deployed, it is important to 96 clearly define mappings between them for the sake of interworking. 97 This document inaugurates a series of SIP-XMPP interworking 98 specifications by defining the architectural assumptions underlying 99 such mappings as well as the mapping of addresses and error 100 conditions. 102 Note: The capitalized key words "MUST", "MUST NOT", "REQUIRED", 103 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 104 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 105 interpreted as described in RFC 2119 [TERMS]. 107 2. Architectural Assumptions 109 Protocol translation between SIP and XMPP could occur in a number of 110 different entities, depending on the architecture of presence and 111 messaging deployments. For example, protocol translation could occur 112 within a multi-protocol server, within a multi-protocol client, or 113 within a gateway that acts as a dedicated protocol translator. 115 This document assumes that the protocol translation will occur within 116 a gateway. (This assumption not meant to discourage protocol 117 translation within multi-protocol clients or servers; instead, this 118 assumption is followed mainly to clarify the discussion and examples 119 so that the protocol translation principles can be more easily 120 understood and can be applied by client and server implementors with 121 appropriate modifications to the examples and terminology.) 122 Specifically, we assume that the protocol translation will occur 123 within an "XMPP-to-SIP gateway" that translates XMPP syntax and 124 semantics on behalf of an XMPP service when communicating with SIP 125 services and/or within a "SIP-to-XMPP gateway" that translates SIP 126 syntax and semantics on behalf of a SIP service when communicating 127 with XMPP services. 129 This document assumes that a gateway will translate directly from one 130 protocol to the other. We further assume that protocol translation 131 will occur within a gateway in the source domain, so that messages 132 and presence information generated by the user of an XMPP service 133 will be translated by a gateway within the trust domain of that XMPP 134 service, and messages and presence information generated by the user 135 of a SIP service will be translated by a gateway within the trust 136 domain of that SIP service. 138 An architectural diagram for a typical gateway deployment is shown 139 below, where the entities have the following significance and the "#" 140 character is used to show the boundary of a trust domain: 142 o romeo@example.net -- a SIP user. 143 o example.net -- a SIP service. 144 o s2x.example.net -- a SIP-to-XMPP gateway. 145 o juliet@example.com -- an XMPP user. 146 o example.com -- an XMPP service. 147 o x2s.example.com -- an XMPP-to-SIP gateway. 149 ##################################################################### 150 # # # 151 # +-- s2x.example.net---#------------- example.com # 152 # | # | | # 153 # example.net -----------------#--- x2s.example.com | # 154 # | # | # 155 # | # | # 156 # romeo@example.net # juliet@example.com # 157 # # # 158 ##################################################################### 160 3. Address Mapping 162 3.1. Overview 164 The basic SIP address format is a "sip:" or "sips:" URI as specified 165 in [SIP]. When a SIP entity supports extensions for instant 166 messageing it may be identified by an 'im:' URI as specified in 167 [CPIM] (see [SIP-IM]) and when a SIP entity spports extensions for 168 presence it may be identified by a 'pres:' URI as specified in [CPP] 169 (see [SIP-PRES]). 171 The XMPP address format is specified in [XMPP]; as specified in 172 [XMPP-IM], instant messaging and presence applications of XMPP must 173 also support 'im:' and 'pres:' URIs as specified in [CPIM] and [CPP] 174 respectively, although such support may simply involve leaving 175 resolution of such addresses up to an XMPP server. 177 In this document we describe mappings for addresses of the form 178 only, ignoring (for the purpose of address mapping) any 179 protocol-specific extensions such as SIP telephone numbers and 180 passwords or XMPP resource identifiers. In addition, we have ruled 181 the mapping of domain names as out of scope for now since that is a 182 matter for the Domain Name System; specifically, the issue for 183 interworking between SIP and XMPP relates to the translation of fully 184 internationalized domain names (which the SIP address format does not 185 allow, but which the XMPP address format does allow via [IDNA]) into 186 non-internationalized domain names. Therefore, in the following 187 sections we discuss local-part addresses only (these are called 188 variously "usernames", "instant inboxes", "presentities", and "node 189 identifiers" in the protocols at issue). 191 The sip:/sips:, im:/pres:, and XMPP address schemes allow different 192 sets of characters (although all three allow alphanumeric characters 193 and disallow both spaces and control characters). In some cases, 194 characters allowed in one scheme are disallowed in others; these 195 characters must be mapped appropriately in order to ensure 196 interworking across systems. 198 The local-part address in sip:/sips: URIs inherits from the 199 "userinfo" rule in [URI] with several changes; here we discuss the 200 SIP "user" rule only: 202 user = 1*( unreserved / escaped / user-unreserved ) 203 user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" 204 unreserved = alphanum / mark 205 mark = "-" / "_" / "." / "!" / "~" / "*" / "'" 206 / "(" / ")" 208 Here we make the simplifying assumption that the local-part address 209 in im:/pres: URIs inherits from the "dot-atom-text" rule in [RFC2822] 210 rather than the more complicated "local-part" rule: 212 dot-atom-text = 1*atext *("." 1*atext) 213 atext = ALPHA / DIGIT / ; Any character except controls, 214 "!" / "#" / ; SP, and specials. 215 "$" / "%" / ; Used for atoms 216 "&" / "'" / 217 "*" / "+" / 218 "-" / "/" / 219 "=" / "?" / 220 "^" / "_" / 221 "`" / "{" / 222 "|" / "}" / 223 "~" 225 The local-part address in XMPP addresses allows any US-ASCII 226 character except space, controls, and the " & ' / : < > @ characters. 228 Therefore, following table lists the allowed and disallowed 229 characters in the local-part addresses of each protocol (aside from 230 the alphanumeric, space, and control characters), in order by 231 hexadecimal character number (where the "A" row shows the allowed 232 characters and the "D" row shows the disallowed characters). 234 Table 1: Allowed and disallowed characters 236 +---+----------------------------------+ 237 | SIP/SIPS CHARACTERS | 238 +---+----------------------------------+ 239 | A | ! $ &'()*+,-./ ; = ? _ ~ | 240 | D | "# % : < > @[\]^ `{|} | 241 +---+----------------------------------+ 242 | IM/PRES CHARACTERS | 243 +---+----------------------------------+ 244 | A | ! #$%&' *+ - / = ? ^_`{|}~ | 245 | D | " () , . :;< > @[\] | 246 +---+----------------------------------+ 247 | XMPP CHARACTERS | 248 +---+----------------------------------+ 249 | A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ | 250 | D | " &' /: < > @ | 251 +---+----------------------------------+ 253 When transforming a local-part address from one scheme to another, an 254 application SHOULD proceed as follows: 256 1. Unescape any escaped characters in the source address (e.g., from 257 SIP to XMPP unescape "%2F" to "/" and from XMPP to SIP unescape 258 "\27" to "'"). 259 2. Leave unmodified any characters that are allowed in the 260 destination scheme. 261 3. Escape any characters that are allowed in the source scheme but 262 reserved in the destination scheme, as escaping is defined for 263 the destination scheme. In particular: 264 * Where the destination scheme is a URI (i.e., an im:, pres:, 265 sip:, or sips: URI), each reserved character MUST be percent- 266 encoded to "%hexhex" as specified in Section 2.6 of 267 [URL-GUIDE] (e.g., when transforming from XMPP to SIP, encode 268 "/" as "%2F"). 269 * Where the destination scheme is a native XMPP address, each 270 reserved character MUST be encoded to "\hexhex" as specified 271 in [XEP-0106] (e.g., when transforming from SIP to XMPP, 272 encode "'" as "\27"). 274 3.2. SIP to XMPP 276 The following is a high-level algorithm for mapping a sip:, sips:, 277 im:, or pres: URI to an XMPP address: 279 1. Remove URI scheme. 280 2. Split at the first '@' character into local-part and hostname 281 (mapping the latter is out of scope). 282 3. Translate %hexhex to equivalent octets. 283 4. Treat result as a UTF-8 string. 284 5. Translate "&" to "\26", "'" to "\27", and "/" to "\2f" 285 respectively in order to properly handle the characters 286 disallowed in XMPP addresses but allowed in sip:/sips: URIs and 287 im:/pres: URIs as shown in Column 3 of Table 3 above (this is 288 consistent with [XEP-0106]). 289 6. Apply Nodeprep profile of [STRINGPREP] (as specified in [XMPP]) 290 for canonicalization (OPTIONAL). 291 7. Recombine local-part with mapped hostname to form local@domain 292 address. 294 3.3. XMPP to SIP 296 The following is a high-level algorithm for mapping an XMPP address 297 to a sip:, sips:, im:, or pres: URI: 299 1. Split XMPP address into node identifier (local-part; mapping 300 described in remaining steps), domain identifier (hostname; 301 mapping is out of scope), and resource identifier (specifier for 302 particular device or connection; discard this for cross-system 303 interworking). 304 2. Apply Nodeprep profile of [STRINGPREP] (as specified in [XMPP]) 305 for canonicalization (OPTIONAL). 306 3. Translate "\26" to "&", "\27" to "'", and "\2f" to "/" 307 respectively (this is consistent with [XEP-0106]). 308 4. Determine if the foreign domain supports im: and pres: URIs 309 (discovered via [SRV] lookup as specified in [XMPP-IM]), else 310 assume that the foreign domain supports sip:/sips: URIs. 311 5. If converting into im: or pres: URI, for each byte, if the byte 312 is in the set (),.;[\] (i.e., the partial complement from Row 3, 313 Column 2 of Table 3 above) or is a UTF-8 character outside the 314 US-ASCII range then transform that byte to %hexhex. If 315 converting into sip: or sips: URI, for each byte, if the byte is 316 in the set #%[\]^`{|} (i.e., the partial complement from Row 3, 317 Column 1 of Table 3 above) or is a UTF-8 character outside the 318 US-ASCII range then transform that byte to %hexhex. 319 6. Combine resulting local-part with mapped hostname to form 320 local@domain address. 322 7. Prepend with 'im:' scheme (for XMPP stanzas) or 323 'pres:' scheme (for XMPP stanzas) if foreign domain 324 supports these, else prepend with 'sip:' or 'sips:' scheme 325 according to local service policy. 327 4. Error Condition Mapping 329 SIP response codes are specified in [SIP] and XMPP error conditions 330 are specified in [XMPP]. 332 4.1. XMPP to SIP 334 Table 8: Mapping of XMPP error conditions to SIP response codes 336 +------------------------------+---------------------+ 337 | XMPP Error Condition | SIP Response Code | 338 +------------------------------+---------------------+ 339 | | 400 | 340 | | 400 | 341 | | 501 | 342 | | 403 | 343 | | 410 | 344 | | 500 | 345 | | 404 | 346 | | 484 | 347 | | 406 | 348 | | 405 | 349 | | 401 | 350 | | 402 | 351 | | 480 | 352 | | 300 | 353 | | 407 | 354 | | 502 | 355 | | 504 | 356 | | 500 | 357 | | 503 | 358 | | 407 | 359 | | 400 | 360 | | 491 | 361 +------------------------------+---------------------+ 363 4.2. SIP to XMPP 365 The mapping of SIP response codes to XMPP error conditions SHOULD be 366 as follows (note that XMPP does not include 100-series or 200-series 367 response codes, only error conditions): 369 Table 9: Mapping of SIP response codes to XMPP error conditions 370 +---------------------+------------------------------+ 371 | SIP Response Code | XMPP Error Condition | 372 +---------------------+------------------------------+ 373 | 300 | | 374 | 301 | | 375 | 302 | | 376 | 305 | | 377 | 380 | | 378 | 400 | | 379 | 401 | | 380 | 402 | | 381 | 403 | | 382 | 404 | | 383 | 405 | | 384 | 406 | | 385 | 407 | | 386 | 408 | | 387 | 410 | | 388 | 413 | | 389 | 414 | | 390 | 415 | | 391 | 416 | | 392 | 420 | | 393 | 421 | | 394 | 423 | | 395 | 480 | | 396 | 481 | | 397 | 482 | | 398 | 483 | | 399 | 484 | | 400 | 485 | | 401 | 486 | | 402 | 487 | | 403 | 488 | | 404 | 491 | | 405 | 493 | | 406 | 500 | | 407 | 501 | | 408 | 502 | | 409 | 503 | | 410 | 504 | | 411 | 505 | | 412 | 513 | | 413 | 600 | | 414 | 603 | | 415 | 604 | | 416 | 606 | | 417 +---------------------+------------------------------+ 419 5. Security Considerations 421 Detailed security considerations for SIP are given in [SIP] and for 422 XMPP in [XMPP]. 424 6. References 426 6.1. Normative References 428 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 429 A., Peterson, J., Sparks, R., Handley, M., and E. 430 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 431 June 2002. 433 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 434 Requirement Levels", BCP 14, RFC 2119, March 1997. 436 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 437 Resource Identifier (URI): Generic Syntax", STD 66, 438 RFC 3986, January 2005. 440 [URL-GUIDE] 441 Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 442 Registration Procedures for New URI Schemes", RFC 4395, 443 February 2006. 445 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 446 Protocol (XMPP): Core", RFC 3920, October 2004. 448 6.2. Informative References 450 [CPIM] Peterson, J., "Common Profile for Instant Messaging 451 (CPIM)", RFC 3860, August 2004. 453 [CPP] Peterson, J., "Common Profile for Presence (CPP)", 454 RFC 3859, August 2004. 456 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, 457 "Internationalizing Domain Names in Applications (IDNA)", 458 RFC 3490, March 2003. 460 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 461 April 2001. 463 [SIP-IM] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 464 and D. Gurle, "Session Initiation Protocol (SIP) Extension 465 for Instant Messaging", RFC 3428, December 2002. 467 [SIP-PRES] 468 Rosenberg, J., "A Presence Event Package for the Session 469 Initiation Protocol (SIP)", RFC 3856, August 2004. 471 [SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 472 specifying the location of services (DNS SRV)", RFC 2782, 473 February 2000. 475 [STRINGPREP] 476 Hoffman, P. and M. Blanchet, "Preparation of 477 Internationalized Strings ("STRINGPREP")", RFC 3454, 478 December 2002. 480 [XEP-0106] 481 Saint-Andre, P. and J. Hildebrand, "JID Escaping", XSF 482 XEP 0106, May 2005. 484 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 485 Protocol (XMPP): Instant Messaging and Presence", 486 RFC 3921, October 2004. 488 Authors' Addresses 490 Peter Saint-Andre 491 Cisco 493 Email: psaintan@cisco.com 495 Avshalom Houri 496 IBM 497 Building 18/D, Kiryat Weizmann Science Park 498 Rehovot 76123 499 Israel 501 Email: avshalom@il.ibm.com 503 Joe Hildebrand 504 Cisco 506 Email: jhildebr@cisco.com