idnits 2.17.1 draft-saintandre-sip-xmpp-core-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (October 15, 2012) is 4203 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 (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 6122 (Obsoleted by RFC 7622) -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) == Outdated reference: A later version (-24) exists of draft-ietf-xmpp-6122bis-04 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 Systems, Inc. 4 Intended status: Informational A. Houri 5 Expires: April 18, 2013 IBM 6 J. Hildebrand 7 Cisco Systems, Inc. 8 October 15, 2012 10 Interworking between the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (XMPP): Core 12 draft-saintandre-sip-xmpp-core-02 14 Abstract 16 As a foundation for the definition of application-specific, bi- 17 directional protocol mappings between the Session Initiation Protocol 18 (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this 19 document specifies the architectural assumptions underlying such 20 mappings as well as the mapping of addresses and error conditions. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 18, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Architectural Assumptions . . . . . . . . . . . . . . . . . . 4 71 4. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 5 72 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4.2. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.3. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 8 75 5. Error Condition Mapping . . . . . . . . . . . . . . . . . . . 9 76 5.1. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 10 77 5.2. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 10 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 The IETF has worked on two signalling technologies that can be used 88 for multimedia session negotiation, messaging, presence, capabilities 89 discovery, notifications, and other application-level functionality: 91 o The Session Initiation Protocol [RFC3261], along with various SIP 92 extensions developed within the SIP for Instant Messaging and 93 Presence Leveraging Extensions (SIMPLE) Working Group. 94 o The Extensible Messaging and Presence Protocol [RFC6120], along 95 with various XMPP extensions developed by the IETF as well as by 96 the XMPP Standards Foundation. 98 Because these technologies are widely deployed, it is important to 99 clearly define mappings between them for the sake of interworking. 100 This document inaugurates a series of SIP-XMPP interworking 101 specifications by defining the architectural assumptions underlying 102 such mappings as well as the mapping of addresses and error 103 conditions. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in 110 [RFC2119]. 112 3. Architectural Assumptions 114 Protocol translation between SIP and XMPP could occur in a number of 115 different entities, depending on the architecture of presence and 116 messaging deployments. For example, protocol translation could occur 117 within a multi-protocol server, within a multi-protocol client, or 118 within a gateway that acts as a dedicated protocol translator. 120 This document assumes that the protocol translation will occur within 121 a gateway. (This assumption not meant to discourage protocol 122 translation within multi-protocol clients or servers; instead, this 123 assumption is followed mainly to clarify the discussion and examples 124 so that the protocol translation principles can be more easily 125 understood and can be applied by client and server implementors with 126 appropriate modifications to the examples and terminology.) 127 Specifically, we assume that the protocol translation will occur 128 within an "XMPP-to-SIP gateway" that translates XMPP syntax and 129 semantics on behalf of an XMPP service when communicating with SIP 130 services and/or within a "SIP-to-XMPP gateway" that translates SIP 131 syntax and semantics on behalf of a SIP service when communicating 132 with XMPP services. 134 This document assumes that a gateway will translate directly from one 135 protocol to the other. We further assume that protocol translation 136 will occur within a gateway in the source domain, so that messages 137 and presence information generated by the user of an XMPP service 138 will be translated by a gateway within the trust domain of that XMPP 139 service, and messages and presence information generated by the user 140 of a SIP service will be translated by a gateway within the trust 141 domain of that SIP service. 143 An architectural diagram for a typical gateway deployment is shown 144 below, where the entities have the following significance and the "#" 145 character is used to show the boundary of a trust domain: 147 o romeo@example.net -- a SIP user. 148 o example.net -- a SIP service. 149 o s2x.example.net -- a SIP-to-XMPP gateway. 150 o juliet@example.com -- an XMPP user. 151 o example.com -- an XMPP service. 152 o x2s.example.com -- an XMPP-to-SIP gateway. 154 ##################################################################### 155 # # # 156 # +-- s2x.example.net---#------------- example.com # 157 # | # | | # 158 # example.net -----------------#--- x2s.example.com | # 159 # | # | # 160 # | # | # 161 # romeo@example.net # juliet@example.com # 162 # # # 163 ##################################################################### 165 4. Address Mapping 167 4.1. Overview 169 The basic SIP address format is a "sip:" or "sips:" URI as specified 170 in [RFC3261]. When a SIP entity supports extensions for instant 171 messageing it may be identified by an 'im:' URI as specified in the 172 Common Profile for Instant Messaging [RFC3860] (see [RFC3428]) and 173 when a SIP entity spports extensions for presence it may be 174 identified by a 'pres:' URI as specified in the Common Profile for 175 Presence [RFC3859] (see [RFC3856]). 177 The XMPP address format is specified in [RFC6122]; as specified in 179 [RFC6121], instant messaging and presence applications of XMPP must 180 also support 'im:' and 'pres:' URIs as specified in [RFC3860] and 181 [RFC3859] respectively, although such support may simply involve 182 leaving resolution of such addresses up to an XMPP server. 184 In this document we describe mappings for addresses of the form 185 only, ignoring (for the purpose of address mapping) any 186 protocol-specific extensions such as SIP telephone numbers and 187 passwords or XMPP resource identifiers. In addition, we have ruled 188 the mapping of domain names as out of scope for now since that is a 189 matter for the Domain Name System; specifically, the issue for 190 interworking between SIP and XMPP relates to the translation of fully 191 internationalized domain names (which the SIP address format does not 192 allow, but which the XMPP address format does allow via 193 Internationalized Domain Names in Applications, see [RFC6122] and 194 [I-D.ietf-xmpp-6122bis]) into non-internationalized domain names. 195 Therefore, in the following sections we discuss local-part addresses 196 only (these are called variously "usernames", "instant inboxes", 197 "presentities", and "node identifiers" in the protocols at issue). 199 The sip:/sips:, im:/pres:, and XMPP address schemes allow different 200 sets of characters (although all three allow alphanumeric characters 201 and disallow both spaces and control characters). In some cases, 202 characters allowed in one scheme are disallowed in others; these 203 characters must be mapped appropriately in order to ensure 204 interworking across systems. 206 The local-part address in sip:/sips: URIs inherits from the 207 "userinfo" rule in [RFC3986] with several changes; here we discuss 208 the SIP "user" rule only: 210 user = 1*( unreserved / escaped / user-unreserved ) 211 user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" 212 unreserved = alphanum / mark 213 mark = "-" / "_" / "." / "!" / "~" / "*" / "'" 214 / "(" / ")" 216 Here we make the simplifying assumption that the local-part address 217 in im:/pres: URIs inherits from the "dot-atom-text" rule in [RFC5322] 218 rather than the more complicated "local-part" rule: 220 dot-atom-text = 1*atext *("." 1*atext) 221 atext = ALPHA / DIGIT / ; Any character except controls, 222 "!" / "#" / ; SP, and specials. 223 "$" / "%" / ; Used for atoms 224 "&" / "'" / 225 "*" / "+" / 226 "-" / "/" / 227 "=" / "?" / 228 "^" / "_" / 229 "`" / "{" / 230 "|" / "}" / 231 "~" 233 The local-part address in XMPP addresses allows any US-ASCII 234 character except space, controls, and the " & ' / : < > @ characters. 236 Therefore, following table lists the allowed and disallowed 237 characters in the local-part addresses of each protocol (aside from 238 the alphanumeric, space, and control characters), in order by 239 hexadecimal character number (where the "A" row shows the allowed 240 characters and the "D" row shows the disallowed characters). 242 Table 1: Allowed and disallowed characters 244 +---+----------------------------------+ 245 | SIP/SIPS CHARACTERS | 246 +---+----------------------------------+ 247 | A | ! $ &'()*+,-./ ; = ? _ ~ | 248 | D | "# % : < > @[\]^ `{|} | 249 +---+----------------------------------+ 250 | IM/PRES CHARACTERS | 251 +---+----------------------------------+ 252 | A | ! #$%&' *+ - / = ? ^_`{|}~ | 253 | D | " () , . :;< > @[\] | 254 +---+----------------------------------+ 255 | XMPP CHARACTERS | 256 +---+----------------------------------+ 257 | A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ | 258 | D | " &' /: < > @ | 259 +---+----------------------------------+ 261 When transforming a local-part address from one scheme to another, an 262 application SHOULD proceed as follows: 264 1. Unescape any escaped characters in the source address (e.g., from 265 SIP to XMPP unescape "%2F" to "/" and from XMPP to SIP unescape 266 "\27" to "'"). 268 2. Leave unmodified any characters that are allowed in the 269 destination scheme. 270 3. Escape any characters that are allowed in the source scheme but 271 reserved in the destination scheme, as escaping is defined for 272 the destination scheme. In particular: 273 * Where the destination scheme is a URI (i.e., an im:, pres:, 274 sip:, or sips: URI), each reserved character MUST be percent- 275 encoded to "%hexhex" as specified in Section 2.6 of [RFC4395] 276 (e.g., when transforming from XMPP to SIP, encode "/" as 277 "%2F"). 278 * Where the destination scheme is a native XMPP address, each 279 reserved character MUST be encoded to "\hexhex" as specified 280 in [XEP-0106] (e.g., when transforming from SIP to XMPP, 281 encode "'" as "\27"). 283 4.2. SIP to XMPP 285 The following is a high-level algorithm for mapping a sip:, sips:, 286 im:, or pres: URI to an XMPP address: 288 1. Remove URI scheme. 289 2. Split at the first '@' character into local-part and hostname 290 (mapping the latter is out of scope). 291 3. Translate %hexhex to equivalent octets. 292 4. Treat result as a UTF-8 string. 293 5. Translate "&" to "\26", "'" to "\27", and "/" to "\2f" 294 respectively in order to properly handle the characters 295 disallowed in XMPP addresses but allowed in sip:/sips: URIs and 296 im:/pres: URIs as shown in Column 3 of Table 3 above (this is 297 consistent with [XEP-0106]). 298 6. Apply Nodeprep profile of Stringprep [RFC3454] or its replacement 299 (see [RFC6122] and [I-D.ietf-xmpp-6122bis]) for canonicalization 300 (OPTIONAL). 301 7. Recombine local-part with mapped hostname to form local@domain 302 address. 304 4.3. XMPP to SIP 306 The following is a high-level algorithm for mapping an XMPP address 307 to a sip:, sips:, im:, or pres: URI: 309 1. Split XMPP address into node identifier (local-part; mapping 310 described in remaining steps), domain identifier (hostname; 311 mapping is out of scope), and resource identifier (specifier for 312 particular device or connection; discard this for cross-system 313 interworking). 315 2. Apply Nodeprep profile of [RFC3454] or its replacement (see 316 [RFC6122] and [I-D.ietf-xmpp-6122bis]) for canonicalization 317 (OPTIONAL). 318 3. Translate "\26" to "&", "\27" to "'", and "\2f" to "/" 319 respectively (this is consistent with [XEP-0106]). 320 4. Determine if the foreign domain supports im: and pres: URIs 321 (discovered via [RFC2782] lookup as specified in [RFC6121]), else 322 assume that the foreign domain supports sip:/sips: URIs. 323 5. If converting into im: or pres: URI, for each byte, if the byte 324 is in the set (),.;[\] (i.e., the partial complement from Row 3, 325 Column 2 of Table 3 above) or is a UTF-8 character outside the 326 US-ASCII range then transform that byte to %hexhex. If 327 converting into sip: or sips: URI, for each byte, if the byte is 328 in the set #%[\]^`{|} (i.e., the partial complement from Row 3, 329 Column 1 of Table 3 above) or is a UTF-8 character outside the 330 US-ASCII range then transform that byte to %hexhex. 331 6. Combine resulting local-part with mapped hostname to form 332 local@domain address. 333 7. Prepend with 'im:' scheme (for XMPP stanzas) or 334 'pres:' scheme (for XMPP stanzas) if foreign domain 335 supports these, else prepend with 'sip:' or 'sips:' scheme 336 according to local service policy. 338 5. Error Condition Mapping 340 SIP response codes are specified in [RFC3261] and XMPP error 341 conditions are specified in [RFC6120]. 343 5.1. XMPP to SIP 345 Table 8: Mapping of XMPP error conditions to SIP response codes 347 +------------------------------+---------------------+ 348 | XMPP Error Condition | SIP Response Code | 349 +------------------------------+---------------------+ 350 | | 400 | 351 | | 400 | 352 | | 501 | 353 | | 403 | 354 | | 410 | 355 | | 500 | 356 | | 404 | 357 | | 484 | 358 | | 406 | 359 | | 405 | 360 | | 401 | 361 | | 402 | 362 | | 480 | 363 | | 300 | 364 | | 407 | 365 | | 502 | 366 | | 504 | 367 | | 500 | 368 | | 503 | 369 | | 407 | 370 | | 400 | 371 | | 491 | 372 +------------------------------+---------------------+ 374 5.2. SIP to XMPP 376 The mapping of SIP response codes to XMPP error conditions SHOULD be 377 as follows (note that XMPP does not include 100-series or 200-series 378 response codes, only error conditions): 380 Table 9: Mapping of SIP response codes to XMPP error conditions 381 +---------------------+------------------------------+ 382 | SIP Response Code | XMPP Error Condition | 383 +---------------------+------------------------------+ 384 | 300 | | 385 | 301 | | 386 | 302 | | 387 | 305 | | 388 | 380 | | 389 | 400 | | 390 | 401 | | 391 | 402 | | 392 | 403 | | 393 | 404 | | 394 | 405 | | 395 | 406 | | 396 | 407 | | 397 | 408 | | 398 | 410 | | 399 | 413 | | 400 | 414 | | 401 | 415 | | 402 | 416 | | 403 | 420 | | 404 | 421 | | 405 | 423 | | 406 | 480 | | 407 | 481 | | 408 | 482 | | 409 | 483 | | 410 | 484 | | 411 | 485 | | 412 | 486 | | 413 | 487 | | 414 | 488 | | 415 | 491 | | 416 | 493 | | 417 | 500 | | 418 | 501 | | 419 | 502 | | 420 | 503 | | 421 | 504 | | 422 | 505 | | 423 | 513 | | 424 | 600 | | 425 | 603 | | 426 | 604 | | 427 | 606 | | 428 +---------------------+------------------------------+ 430 6. Security Considerations 432 Detailed security considerations for SIP are given in [RFC3261] and 433 for XMPP in [RFC6120]. 435 7. IANA Considerations 437 This document requests no actions of IANA. 439 8. References 441 8.1. Normative References 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, March 1997. 446 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 447 A., Peterson, J., Sparks, R., Handley, M., and E. 448 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 449 June 2002. 451 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 452 Resource Identifier (URI): Generic Syntax", STD 66, 453 RFC 3986, January 2005. 455 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 456 Registration Procedures for New URI Schemes", RFC 4395, 457 February 2006. 459 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 460 Protocol (XMPP): Core", RFC 6120, March 2011. 462 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 463 Protocol (XMPP): Address Format", RFC 6122, March 2011. 465 8.2. Informative References 467 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 468 specifying the location of services (DNS SRV)", RFC 2782, 469 February 2000. 471 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 472 and D. Gurle, "Session Initiation Protocol (SIP) Extension 473 for Instant Messaging", RFC 3428, December 2002. 475 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 476 Internationalized Strings ("STRINGPREP")", RFC 3454, 477 December 2002. 479 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 480 Initiation Protocol (SIP)", RFC 3856, August 2004. 482 [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", 483 RFC 3859, August 2004. 485 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 486 (CPIM)", RFC 3860, August 2004. 488 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 489 October 2008. 491 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 492 Protocol (XMPP): Instant Messaging and Presence", 493 RFC 6121, March 2011. 495 [I-D.ietf-xmpp-6122bis] 496 Saint-Andre, P., "Extensible Messaging and Presence 497 Protocol (XMPP): Address Format", 498 draft-ietf-xmpp-6122bis-04 (work in progress), 499 September 2012. 501 [XEP-0106] 502 Saint-Andre, P. and J. Hildebrand, "JID Escaping", XSF 503 XEP 0106, May 2005. 505 Authors' Addresses 507 Peter Saint-Andre 508 Cisco Systems, Inc. 509 1899 Wynkoop Street, Suite 600 510 Denver, CO 80202 511 USA 513 Phone: +1-303-308-3282 514 Email: psaintan@cisco.com 515 Avshalom Houri 516 IBM 517 Building 18/D, Kiryat Weizmann Science Park 518 Rehovot 76123 519 Israel 521 Email: avshalom@il.ibm.com 523 Joe Hildebrand 524 Cisco Systems, Inc. 525 1899 Wynkoop Street, Suite 600 526 Denver, CO 80202 527 USA 529 Email: jhildebr@cisco.com