idnits 2.17.1 draft-ietf-stox-core-11.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 date (February 11, 2014) is 3728 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6122 (Obsoleted by RFC 7622) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' == Outdated reference: A later version (-23) exists of draft-ietf-precis-framework-14 == Outdated reference: A later version (-24) exists of draft-ietf-xmpp-6122bis-10 -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) Summary: 3 errors (**), 0 flaws (~~), 3 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 &yet 4 Intended status: Standards Track A. Houri 5 Expires: August 15, 2014 IBM 6 J. Hildebrand 7 Cisco Systems, Inc. 8 February 11, 2014 10 Interworking between the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (XMPP): Architecture, 12 Addresses, and Error Handling 13 draft-ietf-stox-core-11 15 Abstract 17 As a foundation for the definition of bidirectional protocol mappings 18 between the Session Initiation Protocol (SIP) and the Extensible 19 Messaging and Presence Protocol (XMPP), this document specifies the 20 architectural assumptions underlying such mappings as well as the 21 mapping of addresses and error conditions. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 15, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Intended Audience . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Architectural Assumptions . . . . . . . . . . . . . . . . . . 3 61 5. Interdomain Federation . . . . . . . . . . . . . . . . . . . 5 62 6. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6.2. Local Part Mapping . . . . . . . . . . . . . . . . . . . 8 65 6.3. Instance-Specific Mapping . . . . . . . . . . . . . . . . 10 66 6.4. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 10 67 6.5. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 11 68 7. Error Mapping . . . . . . . . . . . . . . . . . . . . . . . . 12 69 7.1. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 13 70 7.2. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 15 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 75 10.2. Informative References . . . . . . . . . . . . . . . . . 21 76 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 79 1. Introduction 81 The IETF has worked on two signalling technologies that can be used 82 for multimedia session negotiation, messaging, presence, capabilities 83 discovery, notifications, and other application-level functionality: 85 o The Session Initiation Protocol [RFC3261], along with various SIP 86 extensions developed within the SIP for Instant Messaging and 87 Presence Leveraging Extensions (SIMPLE) Working Group. 89 o The Extensible Messaging and Presence Protocol [RFC6120], along 90 with various XMPP extensions developed by the IETF as well as by 91 the XMPP Standards Foundation (XSF). 93 Because these technologies are widely deployed, it is important to 94 clearly define mappings between them for the sake of interworking. 95 This document provides the basis for a series of SIP-XMPP 96 interworking specifications by defining architectural assumptions, 97 address translation methods, and error condition mappings. Other 98 documents in this series define mappings for presence, messaging, and 99 media sessions. 101 The guidelines in this series are based on implementation and 102 deployment experience, and describe techniques that have worked well 103 in the field with existing systems. In practice, interworking has 104 been achieved through direct protocol mappings, not through mapping 105 to an abstract model as described in, for example, [RFC3859] and 106 [RFC3860]. Therefore this series describes the direct mapping 107 approach in enough detail for developers of new implementations to 108 achieve practical interworking between SIP systems and XMPP systems. 110 2. Intended Audience 112 The documents in this series are intended for use by software 113 developers who have an existing system based on one of these 114 technologies (e.g., SIP), and would like to enable communication from 115 that existing system to systems based on the other technology (e.g., 116 XMPP). With regard to this document we assume that readers are 117 familiar with the core specifications for both SIP and XMPP, and with 118 regard to the other documents in this series we assume that readers 119 are familiar with the relevant SIP and XMPP extensions. 121 3. Terminology 123 A number of terms used here are explained in [RFC3261] and [RFC6120]. 125 Several examples use the "XML Notation" from the IRI specification 126 [RFC3987] to represent Unicode characters outside the ASCII range 127 (e.g., the string "ue" stands for the Unicode character LATIN SMALL 128 LETTER U WITH DIAERESIS, U+00FC). 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in 133 [RFC2119]. 135 4. Architectural Assumptions 137 Protocol translation between SIP and XMPP could occur in a number of 138 different entities, depending on the architecture of real-time 139 communication deployments. For example, protocol translation could 140 occur within a multi-protocol server (which uses protocol-specific 141 connection managers to initiate traffic to and accept traffic from 142 clients or other servers natively using SIP/SIMPLE, XMPP, etc.), 143 within a multi-protocol client (which enables a user to establish 144 connections natively with various servers using SIP/SIMPLE, XMPP, 145 etc.), or within a gateway that acts as a dedicated protocol 146 translator (which takes one protocol as input and provides another 147 protocol as output). 149 This document assumes that the protocol translation will occur within 150 a gateway, specifically: 152 o When information needs to flow from an XMPP-based system to a SIP- 153 based system, protocol translation will occur within an "XMPP-to- 154 SIP gateway" that translates XMPP syntax and semantics on behalf 155 of an "XMPP server" (together, these two logical functions 156 comprise an "XMPP service"). 158 o When information needs to flow from a SIP-based system to an XMP- 159 based system, protocol translation will occur within a "SIP-to- 160 XMPP gateway" that translates SIP syntax and semantics on behalf 161 of a "SIP server" (together, these two logical functions comprise 162 a "SIP service"). 164 Naturally, these logical functions could occur in one and the same 165 actual entity; we differentiate between them mainly for explanatory 166 purposes (although, in practice, such gateways are indeed fairly 167 common). 169 Note: This assumption is not meant to discourage protocol 170 translation within multi-protocol clients or servers; instead, 171 this assumption is followed mainly to clarify the discussion and 172 examples so that the protocol translation principles can be more 173 easily understood and can be applied by client and server 174 implementors with appropriate modifications to the examples and 175 terminology. 177 This document assumes that a gateway will translate directly from one 178 protocol to the other. For the sake of the examples, we further 179 assume that protocol translation will occur within a gateway in the 180 source domain, so that information generated by the user of an XMPP 181 system will be translated by a gateway within the trust domain of 182 that XMPP system, and information generated by the user of a SIP 183 system will be translated by a gateway within the trust domain of 184 that SIP system. However, nothing in this document ought to be taken 185 as recommending against protocol translation at the destination 186 domain. 188 An architectural diagram for a possible gateway deployment is shown 189 below, where the entities have the following significance and the "#" 190 character is used to show the boundary of a trust domain: 192 o romeo@example.net -- a SIP user. 194 o example.net -- a SIP server with an associated gateway ("S2X GW") 195 to XMPP. 197 o juliet@example.com -- an XMPP user. 199 o example.com -- an XMPP server with an associated gateway ("X2S 200 GW") to SIP. 202 ######################################################### 203 # # 204 # +-----+ # 205 # | S2X | # 206 # +-------------+ GW |<...........>+-------------+ # 207 # | SIP Server +-----+ | XMPP Server | # 208 # | example.net | +-----+ example.com | # 209 # +-------------+<***********>| X2S +-------------+ # 210 # * | GW | : # 211 # * +-----+ : # 212 # * : # 213 # romeo@example.net juliet@example.com # 214 # # 215 ######################################################### 217 Legend: 218 XMPP = ... or : 219 SIP = * 221 Figure 1: Possible Gateway Deployment Architecture 223 Note that bidirectional communication between the SIP server and the 224 XMPP server can be established either over SIP or over XMPP. If the 225 XMPP user initiates the interaction, then the XMPP server would 226 invoke its XMPP-to-SIP gateway and thus the communication would occur 227 over SIP. If the SIP user initiates the interaction, then the SIP 228 server would invoke its SIP-to-XMPP gateway on thus the communication 229 would occur over XMPP. 231 5. Interdomain Federation 233 The architectural assumptions underlying this document imply that 234 communication between a SIP system and an XMPP system will take place 235 using interdomain federation: the SIP server invokes its associated 236 SIP-to-XMPP gateway, which communicates with the XMPP server using 237 native XMPP server-to-server methods; similarly, the XMPP server 238 invokes its associated XMPP-to-SIP gateway, which communicates with 239 the SIP server using native SIP server-to-server methods. 241 When an XMPP server receives an XMPP stanza whose 'to' address 242 specifies or includes a domain other than the domain of the XMPP 243 server, it needs to determine whether the destination domain 244 communicates via XMPP or SIP. To do so, it performs one or more DNS 245 SRV lookups [RFC2782] for "_xmpp-server" records as specified in 246 [RFC6120]. If the response returns a hostname, the XMPP server can 247 attempt XMPP communication. If not, it can determine the appropriate 248 location for SIP communication at the target domain using the 249 procedures specified in [RFC3263]. 251 Similarly, when a SIP server receives a SIP message whose Request-URI 252 specifies or includes a domain other than the domain of the SIP 253 server, it needs to determine whether the destination domain 254 communicates via SIP or XMPP. To do so, it uses the procedures 255 specified in [RFC3263]. If that response returns a hostname, the SIP 256 server can attempt SIP communication. If not, it can perform one or 257 more DNS SRV lookups [RFC2782] for "_xmpp-server" records as 258 specified in [RFC6120]. 260 In both cases, the server in question might have previously 261 determined that the foreign domain communicates via SIP or XMPP, in 262 which case it would not need to perform the relevant DNS lookups. 263 The caching of such information is a matter of implementation and 264 local service policy, and is therefore out of scope for this 265 document. 267 Existing SIP and XMPP server implementations do not typically include 268 the ability to communicate using the other technology (XMPP for SIP 269 implementations, SIP for XMPP implementations). One common 270 architectural pattern is to associate a gateway with the core server 271 implementation (e.g., in XMPP such a gateway might be called a 272 "connection manager"). How exactly such a gateway interacts with the 273 core server to complete tasks such as address lookups and 274 communication with systems that use the other technology is a matter 275 of implementation (e.g., the gateway might be an add-on module that 276 is trusted by the core server to act as a fallback delivery mechanism 277 if the remote domain does not support the server's native 278 communication technology). 280 Because [RFC6120] specifies a binding of XMPP to TCP, a gateway from 281 SIP to XMPP will need to support TCP as the underlying transport 282 protocol. By contrast, as specified in [RFC3261], either TCP or UDP 283 can be used as the underlying transport for SIP messages, and a given 284 SIP deployment might support only UDP; therefore, a gateway from XMPP 285 to SIP might need to communicate with a SIP server using either TCP 286 or UDP. 288 6. Address Mapping 290 6.1. Overview 292 The basic SIP address format is a 'sip' or 'sips' URI as specified in 293 [RFC3261]. When a SIP entity supports extensions for instant 294 messaging it might be identified by an 'im' URI as specified in the 295 Common Profile for Instant Messaging [RFC3860] (see [RFC3428]) and 296 when a SIP entity supports extensions for presence it might be 297 identified by a 'pres' URI as specified in the Common Profile for 298 Presence [RFC3859] (see [RFC3856]). SIP entities typically also 299 support the 'tel' URI scheme [RFC3966] and might support other URI 300 schemes as well. 302 The XMPP address format is specified in [RFC6122] (although note that 303 XMPP URIs [RFC5122] are not used natively on the XMPP network); in 304 addition, [RFC6121] encourages instant messaging and presence 305 applications of XMPP to also support 'im' and 'pres' URIs as 306 specified in [RFC3860] and [RFC3859] respectively, although such 307 support might simply involve leaving resolution of such addresses up 308 to an XMPP server. 310 In this document we primarily describe mappings for addresses of the 311 form ; however, we also provide guidelines for mapping 312 the addresses of specific user agent instances, which take the form 313 of Globally Routable User Agent URIs (GRUUs) in SIP and 314 "resourceparts" in XMPP. Mapping of protocol-specific identifiers 315 (such as telephone numbers) is out of scope for this specification. 316 In addition, we have ruled the mapping of domain names as out of 317 scope for now since that is a matter for the Domain Name System; 318 specifically, the issue for interworking between SIP and XMPP relates 319 to the translation of fully internationalized domain names (IDNs) 320 into non-internationalized domain names (IDNs are not allowed in the 321 SIP address format, but are allowed in the XMPP address via 322 Internationalized Domain Names in Applications, see [RFC6122] and 323 [I-D.ietf-xmpp-6122bis]). Therefore, in the following sections we 324 focus primarily on the local part of an address (these are called 325 variously "usernames", "instant inboxes", "presentities", and 326 "localparts" in the protocols at issue), secondarily on the instance- 327 specific part of an address, and not at all on the domain-name part 328 of an address. 330 The sip:/sips:, im:/pres:, and XMPP address schemes allow different 331 sets of characters (although all three allow alphanumeric characters 332 and disallow both spaces and control characters). In some cases, 333 characters allowed in one scheme are disallowed in others; these 334 characters need to be mapped appropriately in order to ensure 335 interworking across systems. 337 6.2. Local Part Mapping 339 The local part of a sip:/sips: URI inherits from the "userinfo" rule 340 in [RFC3986] with several changes; here we discuss the SIP "user" 341 rule only: 343 user = 1*( unreserved / escaped / user-unreserved ) 344 user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" 345 unreserved = alphanum / mark 346 mark = "-" / "_" / "." / "!" / "~" / "*" / "'" 347 / "(" / ")" 349 Here we make the simplifying assumption that the local part of an im: 350 /pres: URI inherits from the "dot-atom-text" rule in [RFC5322] rather 351 than the more complicated "local-part" rule: 353 dot-atom-text = 1*atext *("." 1*atext) 354 atext = ALPHA / DIGIT / ; Any character except 355 "!" / "#" / "$" / ; controls, SP, and 356 "%" / "&" / "'" / ; specials. Used for 357 "*" / "+" / "-" / ; atoms. 358 "/" / "=" / "?" / 359 "^" / "_" / "`" / 360 "{" / "|" / "}" / 361 "~" 363 The local part of an XMPP address allows any ASCII character except 364 space, controls, and the " & ' / : < > @ characters. 366 To summarize the foregoing information, the following table lists the 367 allowed and disallowed characters in the local part of identifiers 368 for each protocol (aside from the alphanumeric, space, and control 369 characters), in order by hexadecimal character number (where each "A" 370 row shows the allowed characters and each "D" row shows the 371 disallowed characters). 373 Table 1: Allowed and disallowed characters 375 +---+----------------------------------+ 376 | SIP/SIPS CHARACTERS | 377 +---+----------------------------------+ 378 | A | ! $ &'()*+,-./ ; = ? _ ~ | 379 | D | "# % : < > @[\]^ `{|} | 380 +---+----------------------------------+ 381 | IM/PRES CHARACTERS | 382 +---+----------------------------------+ 383 | A | ! #$%&' *+ - / = ? ^_`{|}~ | 384 | D | " () , . :;< > @[\] | 385 +---+----------------------------------+ 386 | XMPP CHARACTERS | 387 +---+----------------------------------+ 388 | A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ | 389 | D | " &' /: < > @ | 390 +---+----------------------------------+ 392 When transforming the local part of an address from one scheme to 393 another, an application SHOULD proceed as follows: 395 1. Unescape any escaped characters in the source address (e.g., from 396 SIP to XMPP unescape "%23" to "#" per [RFC3986] and from XMPP to 397 SIP unescape "\27" to "'" per [XEP-0106]). 399 2. Leave unmodified any characters that are allowed in the 400 destination scheme. 402 3. Escape any characters that are allowed in the source scheme but 403 reserved in the destination scheme, as escaping is defined for 404 the destination scheme. In particular: 406 * Where the destination scheme is a URI (i.e., an im:, pres:, 407 sip:, or sips: URI), each reserved character MUST be percent- 408 encoded to "%hexhex" as specified in Section 2.5 of [RFC3986] 409 (e.g., when transforming from XMPP to SIP, encode "#" as 410 "%23"). 412 * Where the destination scheme is a native XMPP address, each 413 reserved character MUST be encoded to "\hexhex" as specified 414 in [XEP-0106] (e.g., when transforming from SIP to XMPP, 415 encode "'" as "\27"). 417 6.3. Instance-Specific Mapping 419 The meaning of a resourcepart in XMPP (i.e., the portion of a JID 420 after the slash character, such as "foo" in "user@example.com/foo") 421 matches that of a Globally Routable User Agent URI (GRUU) in SIP 422 [RFC5627]. In both cases, these constructs identify a particular 423 device associated with the bare JID ("localpart@domainpart") of an 424 XMPP entity or with the Address of Record (AOR) of a SIP entity. 425 Therefore, it is reasonable to map the value of a "gr" URI parameter 426 to an XMPP resourcepart, and vice-versa. 428 The mapping described here does not apply to temporary GRUUs, only to 429 GRUUs associated with an Address of Record. 431 The "gr" URI parameter in SIP can contain only characters from the 432 ASCII range (although characters outside the ASCII range can be 433 percent-encoded in accordance with [RFC3986]), whereas an XMPP 434 resourcepart can contain nearly any Unicode character [UNICODE]. 435 Therefore Unicode characters outside the ASCII range need to be 436 mapped to characters in the ASCII range, as described below. 438 6.4. SIP to XMPP 440 The following is a high-level algorithm for mapping a sip:, sips:, 441 im:, or pres: URI to an XMPP address: 443 1. Remove URI scheme. 445 2. Split at the first '@' character into local part and hostname 446 (mapping the latter is out of scope). 448 3. Translate any percent-encoded strings ("%hexhex") to percent- 449 decoded octets. 451 4. Treat result as a UTF-8 string. 453 5. Translate "&" to "\26", "'" to "\27", and "/" to "\2f" 454 respectively in order to properly handle the characters 455 disallowed in XMPP addresses but allowed in sip:/sips: URIs and 456 im:/pres: URIs as shown in Table 1 above (this is consistent with 457 [XEP-0106]). 459 6. Apply Nodeprep profile of Stringprep [RFC3454] or its replacement 460 (see [RFC6122] and [I-D.ietf-xmpp-6122bis]) for canonicalization 461 (OPTIONAL). 463 7. Recombine local part with mapped hostname to form a bare JID 464 ("localpart@domainpart"). 466 8. If the (SIP) address contained a "gr" URI parameter, append a 467 slash character "/" and the "gr" value to the bare JID to form a 468 full JID ("localpart@domainpart/resourcepart"). 470 Several examples follow, illustrating steps 3, 5, and 8 described 471 above. 473 +----------------------------+--------------------------+ 474 | SIP URI | XMPP Address | 475 +----------------------------+--------------------------+ 476 | sip:f%C3%BC@sip.example | fü@sip.example | 477 +----------------------------+--------------------------+ 478 | sip:o'malley@sip.example | o\27malley@sip.example | 479 +----------------------------+--------------------------+ 480 | sip:foo@sip.example;gr=bar | foo@sip.example/bar | 481 +----------------------------+--------------------------+ 483 In the first example the string "%C3%BC" is a percent-encoded 484 representation of the UTF-8-encoded Unicode character LATIN SMALL 485 LETTER U WITH DIAERESIS (U+00FC), whereas the string "ü" is the 486 same character shown for documentation purposes using the XML 487 Notation defined in [RFC3987] (in XMPP it would be sent directly as a 488 UTF-8-encoded Unicode character and not percent-encoded as in a SIP 489 URI to comply with the URI syntax defined in [RFC3986]). 491 6.5. XMPP to SIP 493 The following is a high-level algorithm for mapping an XMPP address 494 to a sip:, sips:, im:, or pres: URI: 496 1. Split XMPP address into localpart (mapping described in remaining 497 steps), domainpart (hostname; mapping is out of scope), and 498 resourcepart (specifier for particular device or connection, for 499 which an OPTIONAL mapping is described below). 501 2. Apply Nodeprep profile of [RFC3454] or its replacement (see 502 [RFC6122] and [I-D.ietf-xmpp-6122bis]) for canonicalization of 503 the XMPP localpart (OPTIONAL). 505 3. Translate "\26" to "&", "\27" to "'", and "\2f" to "/" 506 respectively (this is consistent with [XEP-0106]). 508 4. Determine if the foreign domain supports im: and pres: URIs 509 (discovered via [RFC2782] lookup as specified in [RFC6121]), else 510 assume that the foreign domain supports sip:/sips: URIs. 512 5. If converting into im: or pres: URI, for each byte, if the byte 513 is in the set (),.;[\] or is a UTF-8 character outside the ASCII 514 range then percent-encode that byte to "%hexhex" format. If 515 converting into sip: or sips: URI, for each byte, if the byte is 516 in the set #%[\]^`{|} or is a UTF-8 character outside the ASCII 517 range then percent-encode that byte to "%hexhex" format. 519 6. Combine resulting local part with mapped hostname to form 520 local@domain address. 522 7. Prepend with 'im:' scheme (for XMPP stanzas) or 523 'pres:' scheme (for XMPP stanzas) if foreign domain 524 supports these, else prepend with 'sip:' or 'sips:' scheme 525 according to local service policy. 527 8. If the XMPP address included a resourcepart and the destination 528 URI scheme is 'sip:' or 'sips:', optionally append the slash 529 character '/' and then append the resourcepart (making sure to 530 percent-encode any UTF-8 characters outside the ASCII range) as 531 the "gr" URI parameter. 533 Several examples follow, illustrating steps 3, 5, and 8 described 534 above. 536 +---------------------------+---------------------------------+ 537 | XMPP Address | SIP URI | 538 +---------------------------+---------------------------------+ 539 | m\26m@xmpp.example | sip:m&m@xmpp.example | 540 | tschüss@xmpp.example | sip:tsch%C3%BCss@xmpp.example | 541 | baz@xmpp.example/qux | sip:baz@xmpp.example;gr=qux | 542 +---------------------------+---------------------------------+ 544 As above, in the first example the string "ü" is the Unicode 545 character LATIN SMALL LETTER U WITH DIAERESIS (U+00FC) shown for 546 documentation purposes using the XML Notation defined in [RFC3987] 547 (in XMPP it would be sent directly as a UTF-8-encoded Unicode 548 character and not percent-encoded, whereas the string "%C3%BC" is a 549 percent-encoded representation of the of the same character. 551 7. Error Mapping 553 Various differences between XMPP error conditions and SIP response 554 codes make it hard to provide a comprehensive and consistent mapping 555 between the protocols: 557 o Whereas the set of XMPP error conditions is fixed in the core XMPP 558 specification (and supplemented where needed by application- 559 specific extensions), the set of SIP response codes is more open 560 to change, as evidenced by the IANA registry of SIP response 561 codes. 563 o XMPP has defined fewer error conditions related to stanza handling 564 (22 are defined in [RFC6120]) than SIP has defined response codes 565 related to message handling (at the date of this writing, 71 SIP 566 response codes are registered with IANA as defined in [RFC3261] 567 and numerous SIP extensions). 569 o In many cases, the SIP response codes are more specific than the 570 XMPP error conditions (e.g., from an XMPP perspective the SIP 571 codes "413 Request Entity Too Large" and "414 Request-URI Too 572 Long" are just two forms of a bad request, and the SIP codes "415 573 Unsupported Media Type" and "416 Unsupported URI Scheme" are just 574 two forms of a request that is not acceptable). 576 o SIP differentiates between responses about a particular endpoint 577 or resource (the 4xx series) and responses about a user, i.e., all 578 of a user's endpoints or resources (the 6xx series). There is no 579 such distinction in XMPP, since the same error condition can be 580 returned in relation to the "bare JID" (localpart@domainpart) of a 581 user or the "full JID" (localpart@domainpart/resourcepart) of a 582 particular endpoint or resource, depending on the 'to' address of 583 the original request. 585 As a result of these and other factors, the mapping of error 586 conditions and response codes is more of an art than a science. This 587 document provides suggested mappings, but implementations are free to 588 deviate from these mappings if needed. Also, because no XMPP error 589 conditions are equivalent to the provisional (1xx) and successful 590 (2xx) response codes in SIP, this document suggests mappings only for 591 the SIP redirection (3xx), request failure (4xx), server failure 592 (5xx), and global failure (6xx) response code families. 594 Supplementary information about SIP response codes can be expressed 595 in the "Reason-Phrase" in the Status-Line header, and detailed 596 information about XMPP error conditions can be expressed in the child of the element. Although the semantics of these 598 constructs are specified in a slightly different way, it is 599 reasonable for a gateway to map these constructs to each other if 600 they are found in a SIP response or XMPP error stanza. 602 7.1. XMPP to SIP 604 The mapping of specific XMPP error conditions to SIP response codes 605 SHOULD be as described in the following table. 607 Table 2: Mapping of XMPP error conditions to SIP response codes 608 +------------------------------+---------------------+ 609 | XMPP Error Condition | SIP Response Code | 610 +------------------------------+---------------------+ 611 | | 400 | 612 +------------------------------+---------------------+ 613 | | 400 | 614 +------------------------------+---------------------+ 615 | | 405 or 501 (1) | 616 +------------------------------+---------------------+ 617 | | 403 or 603 (2) | 618 +------------------------------+---------------------+ 619 | | 301 or 410 (3) | 620 +------------------------------+---------------------+ 621 | | 500 | 622 +------------------------------+---------------------+ 623 | | 404 or 604 (2) | 624 +------------------------------+---------------------+ 625 | | 400 | 626 +------------------------------+---------------------+ 627 | | 406 or 606 (2) | 628 +------------------------------+---------------------+ 629 | | 403 | 630 +------------------------------+---------------------+ 631 | | 401 | 632 +------------------------------+---------------------+ 633 | | 403 | 634 +------------------------------+---------------------+ 635 | | 480 or 600 (2) | 636 +------------------------------+---------------------+ 637 | | 302 | 638 +------------------------------+---------------------+ 639 | | 407 | 640 +------------------------------+---------------------+ 641 | | 404 or 408 (4) | 642 +------------------------------+---------------------+ 643 | | 408 | 644 +------------------------------+---------------------+ 645 | | 500 | 646 +------------------------------+---------------------+ 647 | | see note (5) below | 648 +------------------------------+---------------------+ 649 | | 400 | 650 +------------------------------+---------------------+ 651 | | 400 | 652 +------------------------------+---------------------+ 653 | | 491 or 400 | 654 +------------------------------+---------------------+ 656 1. If the error relates to a "full JID" (localpart@domainpart/ 657 resourcepart), the SIP 405 response code is RECOMMENDED. If the 658 error relates to a "bare JID" (localpart@domainpart), the SIP 501 659 response code is RECOMMENDED. 661 2. If the error relates to a "full JID" (localpart@domainpart/ 662 resourcepart), the SIP response code from the 4xx series is 663 RECOMMENDED. If the error relates to a "bare JID" 664 (localpart@domainpart), the SIP response code from the 6xx series 665 is RECOMMENDED. 667 3. If the element includes XML character data specifying the 668 new address, the error MUST be mapped to SIP 301; if not, it MUST 669 be mapped to SIP 410. 671 4. The XMPP error can mean either that 672 the remote server (a) does not exist or (b) cannot be resolved. 673 SIP has two different response codes here, 404 to cover (a) and 674 408 to cover (b). 676 5. The XMPP error condition is widely used to 677 inform the requesting entity that the intended recipient does not 678 support the relevant feature, to signal that a server cannot 679 perform the requested service either generally or in relation to 680 a particular user, and to avoid disclosing whether a given 681 account exists at all. This is quite different from the 682 semantics of the SIP 503 Service Unavailable response code, which 683 is used to signal that communication with a server is impossible 684 (e.g., even if the XMPP error condition is 685 returned in relation to a specific user, the SIP 503 response 686 code will be interpreted as applying to all future requests to 687 this server, not just requests for the specific user). 688 Therefore, mapping the XMPP error 689 condition to the SIP 503 Service Unavailable response code is NOT 690 RECOMMENDED. Although no precise mapping is available, the SIP 691 403 Forbidden and 405 Method Not Allowed response codes are 692 closest in meaning to the XMPP error 693 condition. 695 7.2. SIP to XMPP 697 The mapping of SIP response codes to XMPP error conditions SHOULD be 698 as described in the following table. If a gateway encounters a SIP 699 response code that is not listed below, it SHOULD map a 3xx-series 700 code to , a 4xx-series code to , a 5xx- 701 series code to , and a 6xx-series code to 702 . 704 Table 3: Mapping of SIP response codes to XMPP error conditions 706 +---------------------+---------------------------------+ 707 | SIP Response Code | XMPP Error Condition | 708 +---------------------+---------------------------------+ 709 | 3xx | | 710 +---------------------+---------------------------------+ 711 | 300 | | 712 +---------------------+---------------------------------+ 713 | 301 | (1) | 714 +---------------------+---------------------------------+ 715 | 302 | | 716 +---------------------+---------------------------------+ 717 | 305 | | 718 +---------------------+---------------------------------+ 719 | 380 | | 720 +---------------------+---------------------------------+ 721 | 4xx | | 722 +---------------------+---------------------------------+ 723 | 400 | | 724 +---------------------+---------------------------------+ 725 | 401 | | 726 +---------------------+---------------------------------+ 727 | 402 | (2) | 728 +---------------------+---------------------------------+ 729 | 403 | (3) | 730 +---------------------+---------------------------------+ 731 | 404 | (4) | 732 +---------------------+---------------------------------+ 733 | 405 | | 734 +---------------------+---------------------------------+ 735 | 406 | | 736 +---------------------+---------------------------------+ 737 | 407 | | 738 +---------------------+---------------------------------+ 739 | 408 | (5) | 740 +---------------------+---------------------------------+ 741 | 410 | (1) | 742 +---------------------+---------------------------------+ 743 | 413 | | 744 +---------------------+---------------------------------+ 745 | 414 | | 746 +---------------------+---------------------------------+ 747 | 415 | | 748 +---------------------+---------------------------------+ 749 | 416 | | 750 +---------------------+---------------------------------+ 751 | 420 | | 752 +---------------------+---------------------------------+ 753 | 421 | | 754 +---------------------+---------------------------------+ 755 | 423 | | 756 +---------------------+---------------------------------+ 757 | 430 | (6) | 758 +---------------------+---------------------------------+ 759 | 439 | (6) | 760 +---------------------+---------------------------------+ 761 | 440 | (7) | 762 +---------------------+---------------------------------+ 763 | 480 | | 764 +---------------------+---------------------------------+ 765 | 481 | | 766 +---------------------+---------------------------------+ 767 | 482 | | 768 +---------------------+---------------------------------+ 769 | 483 | | 770 +---------------------+---------------------------------+ 771 | 484 | | 772 +---------------------+---------------------------------+ 773 | 485 | | 774 +---------------------+---------------------------------+ 775 | 486 | | 776 +---------------------+---------------------------------+ 777 | 487 | | 778 +---------------------+---------------------------------+ 779 | 488 | | 780 +---------------------+---------------------------------+ 781 | 489 | (8) | 782 +---------------------+---------------------------------+ 783 | 491 | | 784 +---------------------+---------------------------------+ 785 | 493 | | 786 +---------------------+---------------------------------+ 787 | 5xx | | 788 +---------------------+---------------------------------+ 789 | 500 | | 790 +---------------------+---------------------------------+ 791 | 501 | | 792 +---------------------+---------------------------------+ 793 | 502 | | 794 +---------------------+---------------------------------+ 795 | 503 | (9) | 796 +---------------------+---------------------------------+ 797 | 504 | | 798 +---------------------+---------------------------------+ 799 | 505 | | 800 +---------------------+---------------------------------+ 801 | 513 | | 802 +---------------------+---------------------------------+ 803 | 6xx | | 804 +---------------------+---------------------------------+ 805 | 600 | | 806 +---------------------+---------------------------------+ 807 | 603 | | 808 +---------------------+---------------------------------+ 809 | 604 | | 810 +---------------------+---------------------------------+ 811 | 606 | | 812 +---------------------+---------------------------------+ 814 1. When mapping SIP 310 to XMPP , the element MUST 815 include XML character data specifying the new address. When 816 mapping SIP 410 to XMPP , the element MUST NOT 817 include XML character data specifying a new address. 819 2. The XMPP error condition was removed in 820 [RFC6120]. Therefore, a mapping to XMPP . 822 3. Depending on the scenario, other possible translations for SIP 823 403 are and . 825 4. Depending on the scenario, another possible translation for SIP 826 404 is . 828 5. Depending on the scenario, another possible translation for SIP 829 408 is . 831 6. Codes 430 and 439 are defined in [RFC5626]. 833 7. Code 440 is defined in [RFC5393]. 835 8. Code 489 is defined in [RFC6665]. 837 9. Regarding the semantic mismatch between XMPP and SIP code 503, see note under Section 6.1 of this document. 840 8. IANA Considerations 842 This document makes no requests of IANA. 844 9. Security Considerations 846 Detailed security considerations for SIP are given in [RFC3261] and 847 for XMPP in [RFC6120]. 849 To protect information sent between SIP and XMPP systems, deployed 850 gateways SHOULD use Transport Layer Security (TLS) [RFC5246] when 851 communicating over TCP and Datagram Transport Layer Security (DTLS) 852 [RFC6347] when communicating over UDP. 854 As specified in Section 26.4.4 of [RFC3261] and updated by [RFC5630], 855 a To header or a Request-URI containing a SIPS URI is used to 856 indicate that all hops in a communication path need to be protected 857 using TLS. Because XMPP lacks a way to signal that all hops need to 858 be protected, if the To header or Request-URI of a SIP message is a 859 SIPS URI then the SIP-to-XMPP gateway MUST NOT translate the SIP 860 message into an XMPP stanza and MUST NOT route it to the destination 861 XMPP server (there might be exceptions to such a policy, such as 862 explicit agreement among two operators to enforce per-hop security, 863 but currently they are quite rare). 865 A gateway between SIP and XMPP (in either direction) effectively acts 866 as a SIP back-to-back user agent ("B2BUA"). The amplification 867 vulnerability described in [RFC5393] can manifest itself with B2BUAs 868 (see also [I-D.ietf-straw-b2bua-loop-detection]), and a gateway 869 SHOULD implement the loop-detection methods defined in that 870 specification to help mitigate the possibility of amplification 871 attacks. Note that, although it would be possible to signal the Max- 872 Forwards and Max-Breadth SIP headers over XMPP using the Stanza 873 Headers and Internet Metadata (SHIM) extension [XEP-0131], that 874 extension is not widely implemented; therefore, defenses against 875 excessive looping and amplification attacks when messages pass back 876 and forth through SIP and XMPP networks is out of scope for this 877 document. However, it ought to be addressed in the future, and 878 implementations are strongly encouraged to incorporate appropriate 879 counter measures wherever possible. 881 The ability to use a wide range of Unicode characters [UNICODE] can 882 lead to security issues, especially the possibility of user confusion 883 over identifiers containing visually similar characters (also called 884 "confusable characters" or "confusables"). The PRECIS framework 885 specification [I-D.ietf-precis-framework] describes some of these 886 security issues, and additional guidance can be found in [UTS39]. 888 10. References 890 10.1. Normative References 892 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 893 Requirement Levels", BCP 14, RFC 2119, March 1997. 895 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 896 A., Peterson, J., Sparks, R., Handley, M., and E. 897 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 898 June 2002. 900 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 901 Protocol (SIP): Locating SIP Servers", RFC 3263, June 902 2002. 904 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 905 Resource Identifier (URI): Generic Syntax", STD 66, RFC 906 3986, January 2005. 908 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 909 Identifiers (IRIs)", RFC 3987, January 2005. 911 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 912 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 914 [RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen, 915 "Addressing an Amplification Vulnerability in Session 916 Initiation Protocol (SIP) Forking Proxies", RFC 5393, 917 December 2008. 919 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 920 Agent URIs (GRUUs) in the Session Initiation Protocol 921 (SIP)", RFC 5627, October 2009. 923 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 924 Initiation Protocol (SIP)", RFC 5630, October 2009. 926 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 927 Protocol (XMPP): Core", RFC 6120, March 2011. 929 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 930 Protocol (XMPP): Address Format", RFC 6122, March 2011. 932 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 933 Security Version 1.2", RFC 6347, January 2012. 935 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 936 6.2", 2012, 937 . 939 10.2. Informative References 941 [I-D.ietf-precis-framework] 942 Saint-Andre, P. and M. Blanchet, "Precis Framework: 943 Handling Internationalized Strings in Protocols", draft- 944 ietf-precis-framework-14 (work in progress), February 945 2014. 947 [I-D.ietf-straw-b2bua-loop-detection] 948 Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for 949 Session Initiation Protocol (SIP) Back-to- Back User 950 Agents (B2BUAs)", draft-ietf-straw-b2bua-loop-detection-04 951 (work in progress), February 2014. 953 [I-D.ietf-xmpp-6122bis] 954 Saint-Andre, P., "Extensible Messaging and Presence 955 Protocol (XMPP): Address Format", draft-ietf-xmpp- 956 6122bis-10 (work in progress), January 2014. 958 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 959 specifying the location of services (DNS SRV)", RFC 2782, 960 February 2000. 962 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 963 and D. Gurle, "Session Initiation Protocol (SIP) Extension 964 for Instant Messaging", RFC 3428, December 2002. 966 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 967 Internationalized Strings ("STRINGPREP")", RFC 3454, 968 December 2002. 970 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 971 Initiation Protocol (SIP)", RFC 3856, August 2004. 973 [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 974 3859, August 2004. 976 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 977 (CPIM)", RFC 3860, August 2004. 979 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 980 3966, December 2004. 982 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 983 (IRIs) and Uniform Resource Identifiers (URIs) for the 984 Extensible Messaging and Presence Protocol (XMPP)", RFC 985 5122, February 2008. 987 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 988 October 2008. 990 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 991 Initiated Connections in the Session Initiation Protocol 992 (SIP)", RFC 5626, October 2009. 994 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 995 Protocol (XMPP): Instant Messaging and Presence", RFC 996 6121, March 2011. 998 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 999 July 2012. 1001 [UTS39] The Unicode Consortium, "Unicode Technical Standard #39: 1002 Unicode Security Mechanisms", November 2013, 1003 . 1005 [XEP-0106] 1006 Saint-Andre, P. and J. Hildebrand, "JID Escaping", XSF XEP 1007 0106, June 2007. 1009 [XEP-0131] 1010 Saint-Andre, P. and J. Hildebrand, "Stanza Headers and 1011 Internet Metadata", XSF XEP 0131, July 2006. 1013 Appendix A. Acknowledgements 1015 The authors wish to thank the following individuals for their 1016 feedback: Mary Barnes, Dave Cridland, Dave Crocker, Mike De Vries, 1017 Fabio Forno, Adrian Georgescu, Philipp Hancke, Saul Ibarra Corretge, 1018 Markus Isomaki, Olle Johansson, Paul Kyzivat, Salvatore Loreto, 1019 Daniel-Constantin Mierla, Tory Patnoe, and Robert Sparks. 1021 Dan Romascanu reviewed the document on behalf of the General Area 1022 Review Team. 1024 During IESG review, Stephen Farrell, Ted Lemon, Pete Resnick, and 1025 Sean Turner caught several issues that needed to be addressed. 1027 The authors gratefully acknowledge the assistance of Markus Isomaki 1028 and Yana Stamcheva as the working group chairs and Gonzalo Camarillo 1029 as the sponsoring Area Director. 1031 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for 1032 employing him during his work on earlier versions of this document. 1034 Authors' Addresses 1036 Peter Saint-Andre 1037 &yet 1039 Email: ietf@stpeter.im 1041 Avshalom Houri 1042 IBM 1043 Rorberg Building, Pekris 3 1044 Rehovot 76123 1045 Israel 1047 Email: avshalom@il.ibm.com 1049 Joe Hildebrand 1050 Cisco Systems, Inc. 1051 1899 Wynkoop Street, Suite 600 1052 Denver, CO 80202 1053 USA 1055 Email: jhildebr@cisco.com