idnits 2.17.1 draft-saintandre-sip-xmpp-core-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 525. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 538. 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 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 4, 2008) is 5957 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 (==), 12 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 XMPP Standards Foundation 4 Intended status: Informational A. Houri 5 Expires: July 7, 2008 IBM 6 J. Hildebrand 7 Jabber, Inc. 8 January 4, 2008 10 Interworking between the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (XMPP): Core 12 draft-saintandre-sip-xmpp-core-00 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 7, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 As a foundation for the definition of application-specific, bi- 46 directional protocol mappings between the Session Initiation Protocol 47 (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this 48 document specifies the architectural assumptions underlying such 49 mappings as well as the mapping of addresses and error conditions. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Architectural Assumptions . . . . . . . . . . . . . . . . . . 3 55 3. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 7 58 3.3. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 7 59 4. Error Condition Mapping . . . . . . . . . . . . . . . . . . . 8 60 4.1. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.2. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 8 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 67 Intellectual Property and Copyright Statements . . . . . . . . . . 14 69 1. Introduction 71 The IETF has worked on two signalling technologies that can be used 72 for multimedia session negotiation, messaging, presence, capabilities 73 discovery, notifications, and other application-level functionality: 75 o The Session Initiation Protocol [SIP], along with various SIP 76 extensions developed within the SIP for Instant Messaging and 77 Presence Leveraging Extensions (SIMPLE) Working Group. 78 o The Extensible Messaging and Presence Protocol [XMPP], along with 79 various XMPP extensions developed by the IETF as well as by the 80 XMPP Standards Foundation. 82 Because these technologies are widely deployed, it is important to 83 clearly define mappings between them for the sake of interworking. 84 This document inaugurates a series of SIP-XMPP interworking 85 specifications by defining the architectural assumptions underlying 86 such mappings as well as the mapping of addresses and error 87 conditions. 89 Note: The capitalized key words "MUST", "MUST NOT", "REQUIRED", 90 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 91 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 92 interpreted as described in RFC 2119 [TERMS]. 94 2. Architectural Assumptions 96 Protocol translation between SIP and XMPP could occur in a number of 97 different entities, depending on the architecture of presence and 98 messaging deployments. For example, protocol translation could occur 99 within a multi-protocol server, within a multi-protocol client, or 100 within a gateway that acts as a dedicated protocol translator. 102 This document assumes that the protocol translation will occur within 103 a gateway. (This assumption not meant to discourage protocol 104 translation within multi-protocol clients or servers; instead, this 105 assumption is followed mainly to clarify the discussion and examples 106 so that the protocol translation principles can be more easily 107 understood and can be applied by client and server implementors with 108 appropriate modifications to the examples and terminology.) 109 Specifically, we assume that the protocol translation will occur 110 within an "XMPP-to-SIP gateway" that translates XMPP syntax and 111 semantics on behalf of an XMPP service when communicating with SIP 112 services and/or within a "SIP-to-XMPP gateway" that translates SIP 113 syntax and semantics on behalf of a SIP service when communicating 114 with XMPP services. 116 This document assumes that a gateway will translate directly from one 117 protocol to the other. We further assume that protocol translation 118 will occur within a gateway in the source domain, so that messages 119 and presence information generated by the user of an XMPP service 120 will be translated by a gateway within the trust domain of that XMPP 121 service, and messages and presence information generated by the user 122 of a SIP service will be translated by a gateway within the trust 123 domain of that SIP service. 125 An architectural diagram for a typical gateway deployment is shown 126 below, where the entities have the following significance and the "#" 127 character is used to show the boundary of a trust domain: 129 o romeo@example.net -- a SIP user. 130 o example.net -- a SIP service. 131 o s2x.example.net -- a SIP-to-XMPP gateway. 132 o juliet@example.com -- an XMPP user. 133 o example.com -- an XMPP service. 134 o x2s.example.com -- an XMPP-to-SIP gateway. 136 ##################################################################### 137 # # # 138 # +-- s2x.example.net---#------------- example.com # 139 # | # | | # 140 # example.net -----------------#--- x2s.example.com | # 141 # | # | # 142 # | # | # 143 # romeo@example.net # juliet@example.com # 144 # # # 145 ##################################################################### 147 3. Address Mapping 149 3.1. Overview 151 The basic SIP address format is a "sip:" or "sips:" URI as specified 152 in [SIP]. When a SIP entity supports extensions for instant 153 messageing it may be identified by an 'im:' URI as specified in 154 [CPIM] (see [SIP-IM]) and when a SIP entity spports extensions for 155 presence it may be identified by a 'pres:' URI as specified in [CPP] 156 (see [SIP-PRES]). 158 The XMPP address format is specified in [XMPP]; as specified in 159 [XMPP-IM], instant messaging and presence applications of XMPP must 160 also support 'im:' and 'pres:' URIs as specified in [CPIM] and [CPP] 161 respectively, although such support may simply involve leaving 162 resolution of such addresses up to an XMPP server. 164 In this document we describe mappings for addresses of the form 165 only, ignoring (for the purpose of address mapping) any 166 protocol-specific extensions such as SIP telephone numbers and 167 passwords or XMPP resource identifiers. In addition, we have ruled 168 the mapping of domain names as out of scope for now since that is a 169 matter for the Domain Name System; specifically, the issue for 170 interworking between SIP and XMPP relates to the translation of fully 171 internationalized domain names (which the SIP address format does not 172 allow, but which the XMPP address format does allow via [IDNA]) into 173 non-internationalized domain names. Therefore, in the following 174 sections we discuss local-part addresses only (these are called 175 variously "usernames", "instant inboxes", "presentities", and "node 176 identifiers" in the protocols at issue). 178 The sip:/sips:, im:/pres:, and XMPP address schemes allow different 179 sets of characters (although all three allow alphanumeric characters 180 and disallow both spaces and control characters). In some cases, 181 characters allowed in one scheme are disallowed in others; these 182 characters must be mapped appropriately in order to ensure 183 interworking across systems. 185 The local-part address in sip:/sips: URIs inherits from the 186 "userinfo" rule in [URI] with several changes; here we discuss the 187 SIP "user" rule only: 189 user = 1*( unreserved / escaped / user-unreserved ) 190 user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" 191 unreserved = alphanum / mark 192 mark = "-" / "_" / "." / "!" / "~" / "*" / "'" 193 / "(" / ")" 195 Here we make the simplifying assumption that the local-part address 196 in im:/pres: URIs inherits from the "dot-atom-text" rule in [RFC2822] 197 rather than the more complicated "local-part" rule: 199 dot-atom-text = 1*atext *("." 1*atext) 200 atext = ALPHA / DIGIT / ; Any character except controls, 201 "!" / "#" / ; SP, and specials. 202 "$" / "%" / ; Used for atoms 203 "&" / "'" / 204 "*" / "+" / 205 "-" / "/" / 206 "=" / "?" / 207 "^" / "_" / 208 "`" / "{" / 209 "|" / "}" / 210 "~" 212 The local-part address in XMPP addresses allows any US-ASCII 213 character except space, controls, and the " & ' / : < > @ characters. 215 Therefore, following table lists the allowed and disallowed 216 characters in the local-part addresses of each protocol (aside from 217 the alphanumeric, space, and control characters), in order by 218 hexadecimal character number (where the "A" row shows the allowed 219 characters and the "D" row shows the disallowed characters). 221 Table 1: Allowed and disallowed characters 223 +---+----------------------------------+ 224 | SIP/SIPS CHARACTERS | 225 +---+----------------------------------+ 226 | A | ! $ &'()*+,-./ ; = ? _ ~ | 227 | D | "# % : < > @[\]^ `{|} | 228 +---+----------------------------------+ 229 | IM/PRES CHARACTERS | 230 +---+----------------------------------+ 231 | A | ! #$%&' *+ - / = ? ^_`{|}~ | 232 | D | " () , . :;< > @[\] | 233 +---+----------------------------------+ 234 | XMPP CHARACTERS | 235 +---+----------------------------------+ 236 | A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ | 237 | D | " &' /: < > @ | 238 +---+----------------------------------+ 240 When transforming a local-part address from one scheme to another, an 241 application SHOULD proceed as follows: 243 1. Unescape any escaped characters in the source address (e.g., from 244 SIP to XMPP unescape "%2F" to "/" and from XMPP to SIP unescape 245 "\27" to "'"). 246 2. Leave unmodified any characters that are allowed in the 247 destination scheme. 248 3. Escape any characters that are allowed in the source scheme but 249 reserved in the destination scheme, as escaping is defined for 250 the destination scheme. In particular: 251 * Where the destination scheme is a URI (i.e., an im:, pres:, 252 sip:, or sips: URI), each reserved character MUST be percent- 253 encoded to "%hexhex" as specified in Section 2.6 of 254 [URL-GUIDE] (e.g., when transforming from XMPP to SIP, encode 255 "/" as "%2F"). 256 * Where the destination scheme is a native XMPP address, each 257 reserved character MUST be encoded to "\hexhex" as specified 258 in [XEP-0106] (e.g., when transforming from SIP to XMPP, 259 encode "'" as "\27"). 261 3.2. SIP to XMPP 263 The following is a high-level algorithm for mapping a sip:, sips:, 264 im:, or pres: URI to an XMPP address: 266 1. Remove URI scheme. 267 2. Split at the first '@' character into local-part and hostname 268 (mapping the latter is out of scope). 269 3. Translate %hexhex to equivalent octets. 270 4. Treat result as a UTF-8 string. 271 5. Translate "&" to "\26", "'" to "\27", and "/" to "\2f" 272 respectively in order to properly handle the characters 273 disallowed in XMPP addresses but allowed in sip:/sips: URIs and 274 im:/pres: URIs as shown in Column 3 of Table 3 above (this is 275 consistent with [XEP-0106]). 276 6. Apply Nodeprep profile of [STRINGPREP] (as specified in [XMPP]) 277 for canonicalization (OPTIONAL). 278 7. Recombine local-part with mapped hostname to form local@domain 279 address. 281 3.3. XMPP to SIP 283 The following is a high-level algorithm for mapping an XMPP address 284 to a sip:, sips:, im:, or pres: URI: 286 1. Split XMPP address into node identifier (local-part; mapping 287 described in remaining steps), domain identifier (hostname; 288 mapping is out of scope), and resource identifier (specifier for 289 particular device or connection; discard this for cross-system 290 interworking). 291 2. Apply Nodeprep profile of [STRINGPREP] (as specified in [XMPP]) 292 for canonicalization (OPTIONAL). 293 3. Translate "\26" to "&", "\27" to "'", and "\2f" to "/" 294 respectively (this is consistent with [XEP-0106]). 295 4. Determine if the foreign domain supports im: and pres: URIs 296 (discovered via [SRV] lookup as specified in [XMPP-IM]), else 297 assume that the foreign domain supports sip:/sips: URIs. 298 5. If converting into im: or pres: URI, for each byte, if the byte 299 is in the set (),.;[\] (i.e., the partial complement from Row 3, 300 Column 2 of Table 3 above) or is a UTF-8 character outside the 301 US-ASCII range then transform that byte to %hexhex. If 302 converting into sip: or sips: URI, for each byte, if the byte is 303 in the set #%[\]^`{|} (i.e., the partial complement from Row 3, 304 Column 1 of Table 3 above) or is a UTF-8 character outside the 305 US-ASCII range then transform that byte to %hexhex. 306 6. Combine resulting local-part with mapped hostname to form 307 local@domain address. 309 7. Prepend with 'im:' scheme (for XMPP stanzas) or 310 'pres:' scheme (for XMPP stanzas) if foreign domain 311 supports these, else prepend with 'sip:' or 'sips:' scheme 312 according to local service policy. 314 4. Error Condition Mapping 316 SIP response codes are specified in [SIP] and XMPP error conditions 317 are specified in [XMPP]. 319 4.1. XMPP to SIP 321 Table 8: Mapping of XMPP error conditions to SIP response codes 323 +------------------------------+---------------------+ 324 | XMPP Error Condition | SIP Response Code | 325 +------------------------------+---------------------+ 326 | | 400 | 327 | | 400 | 328 | | 501 | 329 | | 403 | 330 | | 410 | 331 | | 500 | 332 | | 404 | 333 | | 484 | 334 | | 406 | 335 | | 405 | 336 | | 401 | 337 | | 402 | 338 | | 480 | 339 | | 300 | 340 | | 407 | 341 | | 502 | 342 | | 504 | 343 | | 500 | 344 | | 503 | 345 | | 407 | 346 | | 400 | 347 | | 491 | 348 +------------------------------+---------------------+ 350 4.2. SIP to XMPP 352 The mapping of SIP response codes to XMPP error conditions SHOULD be 353 as follows (note that XMPP does not include 100-series or 200-series 354 response codes, only error conditions): 356 Table 9: Mapping of SIP response codes to XMPP error conditions 357 +---------------------+------------------------------+ 358 | SIP Response Code | XMPP Error Condition | 359 +---------------------+------------------------------+ 360 | 300 | | 361 | 301 | | 362 | 302 | | 363 | 305 | | 364 | 380 | | 365 | 400 | | 366 | 401 | | 367 | 402 | | 368 | 403 | | 369 | 404 | | 370 | 405 | | 371 | 406 | | 372 | 407 | | 373 | 408 | | 374 | 410 | | 375 | 413 | | 376 | 414 | | 377 | 415 | | 378 | 416 | | 379 | 420 | | 380 | 421 | | 381 | 423 | | 382 | 480 | | 383 | 481 | | 384 | 482 | | 385 | 483 | | 386 | 484 | | 387 | 485 | | 388 | 486 | | 389 | 487 | | 390 | 488 | | 391 | 491 | | 392 | 493 | | 393 | 500 | | 394 | 501 | | 395 | 502 | | 396 | 503 | | 397 | 504 | | 398 | 505 | | 399 | 513 | | 400 | 600 | | 401 | 603 | | 402 | 604 | | 403 | 606 | | 404 +---------------------+------------------------------+ 406 5. Security Considerations 408 Detailed security considerations for SIP are given in [SIP] and for 409 XMPP in [XMPP]. 411 6. References 413 6.1. Normative References 415 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 416 A., Peterson, J., Sparks, R., Handley, M., and E. 417 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 418 June 2002. 420 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, March 1997. 423 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 424 Resource Identifier (URI): Generic Syntax", STD 66, 425 RFC 3986, January 2005. 427 [URL-GUIDE] 428 Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 429 Registration Procedures for New URI Schemes", RFC 4395, 430 February 2006. 432 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 433 Protocol (XMPP): Core", RFC 3920, October 2004. 435 6.2. Informative References 437 [CPIM] Peterson, J., "Common Profile for Instant Messaging 438 (CPIM)", RFC 3860, August 2004. 440 [CPP] Peterson, J., "Common Profile for Presence (CPP)", 441 RFC 3859, August 2004. 443 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, 444 "Internationalizing Domain Names in Applications (IDNA)", 445 RFC 3490, March 2003. 447 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 448 April 2001. 450 [SIP-IM] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 451 and D. Gurle, "Session Initiation Protocol (SIP) Extension 452 for Instant Messaging", RFC 3428, December 2002. 454 [SIP-PRES] 455 Rosenberg, J., "A Presence Event Package for the Session 456 Initiation Protocol (SIP)", RFC 3856, August 2004. 458 [SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 459 specifying the location of services (DNS SRV)", RFC 2782, 460 February 2000. 462 [STRINGPREP] 463 Hoffman, P. and M. Blanchet, "Preparation of 464 Internationalized Strings ("STRINGPREP")", RFC 3454, 465 December 2002. 467 [XEP-0106] 468 Saint-Andre, P. and J. Hildebrand, "JID Escaping", XSF 469 XEP 0106, May 2005. 471 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 472 Protocol (XMPP): Instant Messaging and Presence", 473 RFC 3921, October 2004. 475 Authors' Addresses 477 Peter Saint-Andre 478 XMPP Standards Foundation 479 P.O. Box 1641 480 Denver, CO 80201 481 USA 483 Email: stpeter@jabber.org 485 Avshalom Houri 486 IBM 487 Building 18/D, Kiryat Weizmann Science Park 488 Rehovot 76123 489 Israel 491 Email: avshalom@il.ibm.com 492 Joe Hildebrand 493 Jabber, Inc. 494 1899 Wynkoop Street, Suite 600 495 Denver, CO 80202 496 USA 498 Email: jhildebrand@jabber.com 500 Full Copyright Statement 502 Copyright (C) The IETF Trust (2008). 504 This document is subject to the rights, licenses and restrictions 505 contained in BCP 78, and except as set forth therein, the authors 506 retain all their rights. 508 This document and the information contained herein are provided on an 509 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 510 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 511 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 512 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 513 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 514 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 516 Intellectual Property 518 The IETF takes no position regarding the validity or scope of any 519 Intellectual Property Rights or other rights that might be claimed to 520 pertain to the implementation or use of the technology described in 521 this document or the extent to which any license under such rights 522 might or might not be available; nor does it represent that it has 523 made any independent effort to identify any such rights. Information 524 on the procedures with respect to rights in RFC documents can be 525 found in BCP 78 and BCP 79. 527 Copies of IPR disclosures made to the IETF Secretariat and any 528 assurances of licenses to be made available, or the result of an 529 attempt made to obtain a general license or permission for the use of 530 such proprietary rights by implementers or users of this 531 specification can be obtained from the IETF on-line IPR repository at 532 http://www.ietf.org/ipr. 534 The IETF invites any interested party to bring to its attention any 535 copyrights, patents or patent applications, or other proprietary 536 rights that may cover technology that may be required to implement 537 this standard. Please address the information to the IETF at 538 ietf-ipr@ietf.org. 540 Acknowledgment 542 Funding for the RFC Editor function is provided by the IETF 543 Administrative Support Activity (IASA).