idnits 2.17.1 draft-ietf-stox-core-06.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 (September 30, 2013) is 3854 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' == Outdated reference: A later version (-04) exists of draft-ietf-straw-b2bua-loop-detection-02 -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) == Outdated reference: A later version (-24) exists of draft-ietf-xmpp-6122bis-07 Summary: 2 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 Cisco Systems, Inc. 4 Intended status: Standards Track A. Houri 5 Expires: April 3, 2014 IBM 6 J. Hildebrand 7 Cisco Systems, Inc. 8 September 30, 2013 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-06 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 April 3, 2014. 40 Copyright Notice 42 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Architectural Assumptions . . . . . . . . . . . . . . . . . . 3 60 4. Interdomain Federation . . . . . . . . . . . . . . . . . . . . 5 61 5. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.2. Local Part Mapping . . . . . . . . . . . . . . . . . . . . 7 64 5.3. Instance-Specific Mapping . . . . . . . . . . . . . . . . 8 65 5.4. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.5. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 10 67 6. Error Mapping . . . . . . . . . . . . . . . . . . . . . . . . 11 68 6.1. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 12 69 6.2. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 13 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 78 1. Introduction 80 The IETF has worked on two signalling technologies that can be used 81 for multimedia session negotiation, messaging, presence, capabilities 82 discovery, notifications, and other application-level functionality: 84 o The Session Initiation Protocol [RFC3261], along with various SIP 85 extensions developed within the SIP for Instant Messaging and 86 Presence Leveraging Extensions (SIMPLE) Working Group. 87 o The Extensible Messaging and Presence Protocol [RFC6120], along 88 with various XMPP extensions developed by the IETF as well as by 89 the XMPP Standards Foundation. 91 Because these technologies are widely deployed, it is important to 92 clearly define mappings between them for the sake of interworking. 93 This document inaugurates a series of SIP-XMPP interworking 94 specifications by defining the architectural assumptions underlying 95 such mappings as well as the mapping of addresses and error 96 conditions. 98 The discussion venue for this document is the mailing list of the 99 STOX WG; visit https://www.ietf.org/mailman/listinfo/stox for 100 subscription information and discussion archives. 102 2. Terminology 104 A number of terms used here are explained in [RFC3261] and [RFC6120]. 106 Several examples use the "XML Notation" from the IRI specification 107 [RFC3987] to represent Unicode characters outside the ASCII range 108 (e.g., the string "ř" stands for the Unicode character LATIN 109 SMALL LETTER R WITH CARON). 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in 114 [RFC2119]. 116 3. Architectural Assumptions 118 Protocol translation between SIP and XMPP could occur in a number of 119 different entities, depending on the architecture of real-time 120 communication deployments. For example, protocol translation could 121 occur within a multi-protocol server (which uses application-specific 122 connection managers to initiate traffic to and accept traffic from 123 clients or other servers natively using SIP/SIMPLE, XMPP, etc.), 124 within a multi-protocol client (which enables a user to establish 125 connections natively with various servers using SIP/SIMPLE, XMPP, 126 etc.), or within a gateway that acts as a dedicated protocol 127 translator (which takes one protocol as input and provides another 128 protocol as output). 130 This document assumes that the protocol translation will occur within 131 a gateway. (This assumption is not meant to discourage protocol 132 translation within multi-protocol clients or servers; instead, this 133 assumption is followed mainly to clarify the discussion and examples 134 so that the protocol translation principles can be more easily 135 understood and can be applied by client and server implementors with 136 appropriate modifications to the examples and terminology.) 137 Specifically, we assume that the protocol translation will occur 138 within an "XMPP-to-SIP gateway" that translates XMPP syntax and 139 semantics on behalf of an XMPP service when communicating with SIP 140 services and/or within a "SIP-to-XMPP gateway" that translates SIP 141 syntax and semantics on behalf of a SIP service when communicating 142 with XMPP services (naturally, these logical functions could occur in 143 one and the same actual translator). 145 This document assumes that a gateway will translate directly from one 146 protocol to the other. For the sake of the examples, we further 147 assume that protocol translation will occur within a gateway in the 148 source domain, so that information generated by the user of an XMPP 149 service will be translated by a gateway within the trust domain of 150 that XMPP service, and information generated by the user of a SIP 151 service will be translated by a gateway within the trust domain of 152 that SIP service. However, nothing in this document ought to be 153 taken as recommending against protocol translation at the destination 154 domain. 156 An architectural diagram for a possible gateway deployment is shown 157 below, where the entities have the following significance and the "#" 158 character is used to show the boundary of a trust domain: 160 o romeo@example.net -- a SIP user. 161 o example.net -- a SIP service with a gateway ("GW") to XMPP. 162 o juliet@example.com -- an XMPP user. 163 o example.com -- an XMPP service with a gateway ("GW") to SIP. 165 ##@####################################################### 166 # # # 167 # +-------------+----+ # +----+-------------+ # 168 # | example.net | GW |---#---| GW | example.com | # 169 # +-------------+----+ # +----+-------------+ # 170 # | # | # 171 # romeo@example.net # juliet@example.com # 172 # # # 173 ########################################################## 175 4. Interdomain Federation 177 The architecture assumptions underlying this document imply that 178 communication between a SIP-based service and an XMPP-based service 179 will take place using interdomain federation. 181 When an XMPP service receives an XMPP stanza whose 'to' address 182 specifies or includes a domain other than the domain of the XMPP 183 service, it needs to determine whether the destination domain offers 184 an XMPP service or a SIP service. To do so, it performs one or more 185 DNS SRV lookups [RFC2782] for "_xmpp-server" records as specified in 186 [RFC6120]. If the response returns a hostname, the service can 187 attempt XMPP communication. If not, the service can attempt to 188 locate a SIP service for that domain using the procedures specified 189 in [RFC3263]. 191 Similarly, when a SIP service receives a SIP message whose Request- 192 URI specifies or includes a domain other than the domain of the SIP 193 service, it needs to determine whether the destination domain offers 194 a SIP service or an XMPP service. To do so, it uses the procedures 195 specified in [RFC3263]. If that response returns a hostname, the 196 service can attempt SIP communication. If not, the service can 197 perform one or more DNS SRV lookups [RFC2782] for "_xmpp-server" 198 records as specified in [RFC6120]. 200 In both cases, the service in question might have previously 201 determined that the foreign domain is a SIP service or an XMPP 202 service, in which case it would not need to perform the relevant DNS 203 lookups. The caching of such information is a matter of 204 implementation and local service policy, and is therefore out of 205 scope for this document. 207 Because [RFC6120] specifies a binding of XMPP to TCP, a gateway from 208 SIP to XMPP will need to support TCP as the underlying transport 209 protocol. By contrast, as specified in [RFC3261], either TCP or UDP 210 can be used as the underlying transport for SIP messages, and a given 211 SIP deployment might support only UDP; therefore, a gateway from XMPP 212 to SIP might need to communicate with a SIP service using either TCP 213 or UDP. 215 5. Address Mapping 217 5.1. Overview 219 The basic SIP address format is a 'sip' or 'sips' URI as specified in 220 [RFC3261]. When a SIP entity supports extensions for instant 221 messaging it might be identified by an 'im' URI as specified in the 222 Common Profile for Instant Messaging [RFC3860] (see [RFC3428]) and 223 when a SIP entity supports extensions for presence it might be 224 identified by a 'pres' URI as specified in the Common Profile for 225 Presence [RFC3859] (see [RFC3856]). SIP entities typically also 226 support the 'tel' URI scheme [RFC3966] and might support other URI 227 schemes as well. 229 The XMPP address format is specified in [RFC6122] (although note that 230 XMPP URIs [RFC5122] are not used natively on the XMPP network); in 231 addition, [RFC6121] encourages instant messaging and presence 232 applications of XMPP to also support 'im' and 'pres' URIs as 233 specified in [RFC3860] and [RFC3859] respectively, although such 234 support might simply involve leaving resolution of such addresses up 235 to an XMPP server. 237 In this document we primarily describe mappings for addresses of the 238 form ; however, we also provide guidelines for mapping 239 the addresses of specific user agent instances, which take the form 240 of Globally Routable User Agent URIs (GRUUs) in SIP and 241 "resourceparts" in XMPP. Mapping of protocol-specific identifiers 242 (such as telephone numbers) is out of scope for this specification. 243 In addition, we have ruled the mapping of domain names as out of 244 scope for now since that is a matter for the Domain Name System; 245 specifically, the issue for interworking between SIP and XMPP relates 246 to the translation of fully internationalized domain names (IDNs) 247 into non-internationalized domain names (IDNs are not allowed in the 248 SIP address format, but are allowed in the XMPP address via 249 Internationalized Domain Names in Applications, see [RFC6122] and 250 [I-D.ietf-xmpp-6122bis]). Therefore, in the following sections we 251 focus primarily on the local part of an address (these are called 252 variously "usernames", "instant inboxes", "presentities", and 253 "localparts" in the protocols at issue), secondarily on the instance- 254 specific part of an address, and not at all on the domain-name part 255 of an address. 257 The sip:/sips:, im:/pres:, and XMPP address schemes allow different 258 sets of characters (although all three allow alphanumeric characters 259 and disallow both spaces and control characters). In some cases, 260 characters allowed in one scheme are disallowed in others; these 261 characters need to be mapped appropriately in order to ensure 262 interworking across systems. 264 5.2. Local Part Mapping 266 The local part of a sip:/sips: URI inherits from the "userinfo" rule 267 in [RFC3986] with several changes; here we discuss the SIP "user" 268 rule only: 270 user = 1*( unreserved / escaped / user-unreserved ) 271 user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" 272 unreserved = alphanum / mark 273 mark = "-" / "_" / "." / "!" / "~" / "*" / "'" 274 / "(" / ")" 276 Here we make the simplifying assumption that the local part of an 277 im:/pres: URI inherits from the "dot-atom-text" rule in [RFC5322] 278 rather than the more complicated "local-part" rule: 280 dot-atom-text = 1*atext *("." 1*atext) 281 atext = ALPHA / DIGIT / ; Any character except 282 "!" / "#" / "$" / ; controls, SP, and 283 "%" / "&" / "'" / ; specials. Used for 284 "*" / "+" / "-" / ; atoms. 285 "/" / "=" / "?" / 286 "^" / "_" / "`" / 287 "{" / "|" / "}" / 288 "~" 290 The local part of an XMPP address allows any ASCII character except 291 space, controls, and the " & ' / : < > @ characters. 293 To summarize the foregoing information, the following table lists the 294 allowed and disallowed characters in the local part of identifiers 295 for each protocol (aside from the alphanumeric, space, and control 296 characters), in order by hexadecimal character number (where each "A" 297 row shows the allowed characters and each "D" row shows the 298 disallowed characters). 300 Table 1: Allowed and disallowed characters 302 +---+----------------------------------+ 303 | SIP/SIPS CHARACTERS | 304 +---+----------------------------------+ 305 | A | ! $ &'()*+,-./ ; = ? _ ~ | 306 | D | "# % : < > @[\]^ `{|} | 307 +---+----------------------------------+ 308 | IM/PRES CHARACTERS | 309 +---+----------------------------------+ 310 | A | ! #$%&' *+ - / = ? ^_`{|}~ | 311 | D | " () , . :;< > @[\] | 312 +---+----------------------------------+ 313 | XMPP CHARACTERS | 314 +---+----------------------------------+ 315 | A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ | 316 | D | " &' /: < > @ | 317 +---+----------------------------------+ 319 When transforming the local part of an address from one scheme to 320 another, an application SHOULD proceed as follows: 322 1. Unescape any escaped characters in the source address (e.g., from 323 SIP to XMPP unescape "%23" to "#" per [RFC3986] and from XMPP to 324 SIP unescape "\27" to "'" per [XEP-0106]). 325 2. Leave unmodified any characters that are allowed in the 326 destination scheme. 327 3. Escape any characters that are allowed in the source scheme but 328 reserved in the destination scheme, as escaping is defined for 329 the destination scheme. In particular: 330 * Where the destination scheme is a URI (i.e., an im:, pres:, 331 sip:, or sips: URI), each reserved character MUST be percent- 332 encoded to "%hexhex" as specified in Section 2.5 of [RFC3986] 333 (e.g., when transforming from XMPP to SIP, encode "#" as 334 "%23"). 335 * Where the destination scheme is a native XMPP address, each 336 reserved character MUST be encoded to "\hexhex" as specified 337 in [XEP-0106] (e.g., when transforming from SIP to XMPP, 338 encode "'" as "\27"). 340 5.3. Instance-Specific Mapping 342 The meaning of a resourcepart in XMPP (i.e., the portion of a JID 343 after the slash character, such as "foo" in "user@example.com/foo") 344 matches that of a Globally Routable User Agent URI (GRUU) in SIP 345 [RFC5627]. In both cases, these constructs identify a particular 346 device associated with the bare JID ("localpart@domainpart") of an 347 XMPP entity or with the Address of Record (AOR) of a SIP entity. 349 Therefore, it is reasonable to map the value of a "gr" URI parameter 350 to an XMPP resourcepart, and vice-versa. 352 The mapping described here does not apply to temporary GRUUs, only to 353 GRUUs associated with an Address of Record. 355 The "gr" URI parameter in SIP can contain only characters from the 356 ASCII range (although characters outside the ASCII range can be 357 percent-encoded in accordance with [RFC3986], whereas an XMPP 358 resourcepart can contain nearly any Unicode character [UNICODE]. 359 Therefore Unicode characters outside the ASCII range need to be 360 mapped to characters in the ASCII range, as described below. 362 5.4. SIP to XMPP 364 The following is a high-level algorithm for mapping a sip:, sips:, 365 im:, or pres: URI to an XMPP address: 367 1. Remove URI scheme. 368 2. Split at the first '@' character into local part and hostname 369 (mapping the latter is out of scope). 370 3. Translate any percent-encoded strings ("%hexhex") to percent- 371 decoded octets. 372 4. Treat result as a UTF-8 string. 373 5. Translate "&" to "\26", "'" to "\27", and "/" to "\2f" 374 respectively in order to properly handle the characters 375 disallowed in XMPP addresses but allowed in sip:/sips: URIs and 376 im:/pres: URIs as shown in Table 1 above (this is consistent with 377 [XEP-0106]). 378 6. Apply Nodeprep profile of Stringprep [RFC3454] or its replacement 379 (see [RFC6122] and [I-D.ietf-xmpp-6122bis]) for canonicalization 380 (OPTIONAL). 381 7. Recombine local part with mapped hostname to form a bare JID 382 ("localpart@domainpart"). 383 8. If the (SIP) address contained a "gr" URI parameter, append a 384 slash character "/" and the "gr" value to the bare JID to form a 385 full JID ("localpart@domainpart/resourcepart"). 387 Several examples follow, illustrating steps 3, 5, and 8 described 388 above (the percent-encoded string "%C3%BC" and XML Notation string 389 "�FC;" both represent the Unicode character LATIN SMALL LETTER U 390 WITH DIAERESIS). 392 +----------------------------+--------------------------+ 393 | SIP URI | XMPP Address | 394 +----------------------------+--------------------------+ 395 | sip:f%C3%BC@sip.example | f�FC;@sip.example | 396 | sip:o'malley@sip.example | o\27malley@sip.example | 397 | sip:foo@sip.example;gr=bar | foo@sip.example/bar | 398 +----------------------------+--------------------------+ 400 5.5. XMPP to SIP 402 The following is a high-level algorithm for mapping an XMPP address 403 to a sip:, sips:, im:, or pres: URI: 405 1. Split XMPP address into localpart (mapping described in remaining 406 steps), domainpart (hostname; mapping is out of scope), and 407 resourcepart (specifier for particular device or connection, for 408 which an OPTIONAL mapping is described below). 409 2. Apply Nodeprep profile of [RFC3454] or its replacement (see 410 [RFC6122] and [I-D.ietf-xmpp-6122bis]) for canonicalization of 411 the XMPP localpart (OPTIONAL). 412 3. Translate "\26" to "&", "\27" to "'", and "\2f" to "/" 413 respectively (this is consistent with [XEP-0106]). 414 4. Determine if the foreign domain supports im: and pres: URIs 415 (discovered via [RFC2782] lookup as specified in [RFC6121]), else 416 assume that the foreign domain supports sip:/sips: URIs. 417 5. If converting into im: or pres: URI, for each byte, if the byte 418 is in the set (),.;[\] or is a UTF-8 character outside the ASCII 419 range then percent-encode that byte to "%hexhex" format. If 420 converting into sip: or sips: URI, for each byte, if the byte is 421 in the set #%[\]^`{|} or is a UTF-8 character outside the ASCII 422 range then percent-encode that byte to "%hexhex" format. 423 6. Combine resulting local part with mapped hostname to form 424 local@domain address. 425 7. Prepend with 'im:' scheme (for XMPP stanzas) or 426 'pres:' scheme (for XMPP stanzas) if foreign domain 427 supports these, else prepend with 'sip:' or 'sips:' scheme 428 according to local service policy. 429 8. If the XMPP address included a resourcepart and the destination 430 URI scheme is 'sip:' or 'sips:', optionally append the slash 431 character '/' and then append the resourcepart (making sure to 432 percent-encode any UTF-8 characters outside the ASCII range) as 433 the "gr" URI parameter. 435 Several examples follow, illustrating steps 3, 5, and 8 described 436 above (the percent-encoded string "%C3%BC" and XML Notation string 437 "�FC;" both represent the Unicode character LATIN SMALL LETTER U 438 WITH DIAERESIS). 440 +---------------------------+---------------------------------+ 441 | XMPP Address | SIP URI | 442 +---------------------------+---------------------------------+ 443 | tsch�FCss@xmpp.example | sip:tsch%C3%BCss@xmpp.example | 444 | m\26m@xmpp.example | sip:m&m@xmpp.example | 445 | baz@xmpp.example/qux | sip:baz@xmpp.example;gr=qux | 446 +---------------------------+---------------------------------+ 448 6. Error Mapping 450 Various differences between XMPP error conditions and SIP response 451 codes make it hard to provide a comprehensive and consistent mapping 452 between the protocols: 454 o Whereas the set of XMPP error conditions is fixed in the core XMPP 455 specification (and supplemented where needed by application- 456 specific extensions), the set of SIP response codes is more open 457 to change, as evidenced by the IANA registry of SIP response 458 codes. 459 o XMPP has defined fewer error conditions related to stanza handling 460 (22 are defined in [RFC6120]) than SIP has defined response codes 461 related to message handling (at the date of this writing, 71 SIP 462 response codes are registered with IANA as defined in [RFC3261] 463 and numerous SIP extensions). 464 o In many cases, the SIP response codes are more specific than the 465 XMPP error conditions (e.g., from an XMPP perspective the SIP 466 codes "413 Request Entity Too Large" and "414 Request-URI Too 467 Long" are just two forms of a bad request, and the SIP codes "415 468 Unsupported Media Type" and "416 Unsupported URI Scheme" are just 469 two forms of a request that is not acceptable). 470 o SIP differentiates between responses about a particular endpoint 471 or resource (the 4xx series) and responses about a user, i.e., all 472 of a user's endpoints or resources (the 6xx series). There is no 473 such distinction in XMPP, since the same error condition can be 474 returned in relation to the "bare JID" (localpart@domainpart) of a 475 user or the "full JID" (localpart@domainpart/resourcepart) of a 476 particular endpoint or resource, depending on the 'to' address of 477 the original request. 479 As a result of these and other factors, the mapping of error 480 conditions and response codes is more of an art than a science. This 481 document provides suggested mappings, but implementations are free to 482 deviate from these mappings if needed. Also, because no XMPP error 483 conditions are equivalent to the provisional (1xx) and successful 484 (2xx) response codes in SIP, this document suggests mappings only for 485 the SIP redirection (3xx), request failure (4xx), server failure 486 (5xx), and global failure (6xx) response code families. 488 Supplementary information about SIP response codes can be expressed 489 in the "Reason-Phrase" in the Status-Line header, and detailed 490 information about XMPP error conditions can be expressed in the 491 child of the element. Although the semantics of 492 these constructs are specified in a slightly different way, it is 493 reasonable for a gateway to map these constructs to each other if 494 they are found in a SIP response or XMPP error stanza. 496 6.1. XMPP to SIP 498 The mapping of specific XMPP error conditions to SIP response codes 499 SHOULD be as described in the following table. 501 Table 2: Mapping of XMPP error conditions to SIP response codes 503 +------------------------------+---------------------+ 504 | XMPP Error Condition | SIP Response Code | 505 +------------------------------+---------------------+ 506 | | 400 | 507 | | 400 | 508 | | 405 or 501 (1) | 509 | | 403 or 603 (2) | 510 | | 410 | 511 | | 500 | 512 | | 404 or 604 (2) | 513 | | 400 | 514 | | 406 or 606 (2) | 515 | | 403 | 516 | | 401 | 517 | | 403 | 518 | | 480 or 600 (2) | 519 | | 302 | 520 | | 407 | 521 | | 404 or 408 (3) | 522 | | 408 | 523 | | 500 | 524 | | see note (4) below | 525 | | 407 | 526 | | 400 | 527 | | 491 or 400 | 528 +------------------------------+---------------------+ 530 1. If the error relates to a "full JID" 531 (localpart@domainpart/resourcepart), the SIP 405 response code is 532 RECOMMENDED. If the error relates to a "bare JID" 533 (localpart@domainpart), the SIP 501 response code is RECOMMENDED. 535 2. If the error relates to a "full JID" 536 (localpart@domainpart/resourcepart), the SIP response code from 537 the 4xx series is RECOMMENDED. If the error relates to a "bare 538 JID" (localpart@domainpart), the SIP response code from the 6xx 539 series is RECOMMENDED. 540 3. The XMPP error can mean either that 541 the remote server (a) does not exist or (b) cannot be resolved. 542 SIP has two different response codes here, 404 to cover (a) and 543 408 to cover (b). 544 4. The XMPP error condition is widely used to 545 inform the requesting entity that the intended recipient does not 546 support the relevant feature, to signal that a server cannot 547 perform the requested service either generally or in relation to 548 a particular user, and to avoid disclosing whether a given 549 account exists at all. This is quite different from the 550 semantics of the SIP 503 Service Unavailable response code, which 551 is used to signal that communication with a server is impossible 552 (e.g., even if the XMPP error condition is 553 returned in relation to a specific user, the SIP 503 response 554 code will be interpreted as applying to the entire domain, not 555 only the specific user). Therefore, mapping the XMPP error condition to the SIP 503 Service Unavailable 557 response code is NOT RECOMMENDED. Although no precise mapping is 558 available, the SIP 403 Forbidden and 405 Method Not Allowed 559 response codes are closest in meaning to the XMPP error condition. 562 6.2. SIP to XMPP 564 The mapping of SIP response codes to XMPP error conditions SHOULD be 565 as described in the following table. If a gateway encounters a SIP 566 response code that is not listed below, it SHOULD map a 3xx-series 567 code to , a 4xx-series code to , a 5xx- 568 series code to , and a 6xx-series code to 569 . 571 Table 3: Mapping of SIP response codes to XMPP error conditions 573 +---------------------+---------------------------------+ 574 | SIP Response Code | XMPP Error Condition | 575 +---------------------+---------------------------------+ 576 | 3xx | | 577 | 300 | | 578 | 301 | | 579 | 302 | | 580 | 305 | | 581 | 380 | | 582 | 4xx | | 583 | 400 | | 584 | 401 | | 585 | 402 | see note (1) below | 586 | 403 | (2) | 587 | 404 | (3) | 588 | 405 | | 589 | 406 | | 590 | 407 | | 591 | 408 | (4) | 592 | 410 | | 593 | 413 | | 594 | 414 | | 595 | 415 | | 596 | 416 | | 597 | 420 | | 598 | 421 | | 599 | 423 | | 600 | 430 | (5) | 601 | 439 | (5) | 602 | 440 | (6) | 603 | 480 | | 604 | 481 | | 605 | 482 | | 606 | 483 | | 607 | 484 | | 608 | 485 | | 609 | 486 | | 610 | 487 | | 611 | 488 | | 612 | 489 | (7) | 613 | 491 | | 614 | 493 | | 615 | 5xx | | 616 | 500 | | 617 | 501 | | 618 | 502 | | 619 | 503 | see note in Section 6.1 | 620 | 504 | | 621 | 505 | | 622 | 513 | | 623 | 6xx | | 624 | 600 | | 625 | 603 | | 626 | 604 | | 627 | 606 | | 628 +---------------------+---------------------------------+ 630 1. The XMPP error condition was removed in 631 [RFC6120]. 632 2. Depending on the scenario, other possible translations for SIP 633 403 are and . 634 3. Depending on the scenario, another possible translation for SIP 635 404 is . 636 4. Depending on the scenario, another possible translation for SIP 637 408 is . 638 5. Codes 430 and 439 are defined in [RFC5626]. 639 6. Code 440 is defined in [RFC5393]. 640 7. Code 489 is defined in [RFC6665]. 642 7. IANA Considerations 644 This document makes no requests of IANA. 646 8. Security Considerations 648 Detailed security considerations for SIP are given in [RFC3261] and 649 for XMPP in [RFC6120]. 651 As specified in Section 26.4.4 of [RFC3261] and updated by [RFC5630], 652 a To header or a Request-URI containing a SIPS URI is used to 653 indicate that all hops in a communication path need to be protected 654 using Transport Layer Security [RFC5246]. Because XMPP lacks a way 655 to signal that all hops need to be encrypted, if the To header or 656 Request-URI of a SIP message is a SIPS URI then the SIP-to-XMPP 657 gateway MUST NOT translate the SIP message into an XMPP stanza and 658 MUST NOT route it to the destination XMPP server. 660 A gateway between SIP and XMPP (in either direction) effectively acts 661 as a SIP back-to-back user agent ("B2BUA"). The amplification 662 vulnerability described in [RFC5393] can manifest itself with B2BUAs 663 (see also [I-D.ietf-straw-b2bua-loop-detection]), and a gateway 664 SHOULD implement the loop-detection methods defined in that 665 specification to help mitigate the possibility of amplification 666 attacks. Note that, although it would be possible to signal the Max- 667 Forwards and Max-Breadth SIP headers over XMPP using the Stanza 668 Headers and Internet Metadata (SHIM) extension [XEP-0131], that 669 extension is not widely implemented; therefore, defenses against 670 excessive looping and amplification attacks when messages pass back 671 and forth through SIP and XMPP networks is out of scope for this 672 document. However, it ought to be addressed in the future, and 673 implementations are strongly encouraged to incorporate appropriate 674 counter measures wherever possible. 676 9. References 678 9.1. Normative References 680 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 681 Requirement Levels", BCP 14, RFC 2119, March 1997. 683 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 684 A., Peterson, J., Sparks, R., Handley, M., and E. 685 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 686 June 2002. 688 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 689 Protocol (SIP): Locating SIP Servers", RFC 3263, 690 June 2002. 692 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 693 Resource Identifier (URI): Generic Syntax", STD 66, 694 RFC 3986, January 2005. 696 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 697 Identifiers (IRIs)", RFC 3987, January 2005. 699 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 700 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 702 [RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen, 703 "Addressing an Amplification Vulnerability in Session 704 Initiation Protocol (SIP) Forking Proxies", RFC 5393, 705 December 2008. 707 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 708 Agent URIs (GRUUs) in the Session Initiation Protocol 709 (SIP)", RFC 5627, October 2009. 711 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 712 Initiation Protocol (SIP)", RFC 5630, October 2009. 714 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 715 Protocol (XMPP): Core", RFC 6120, March 2011. 717 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 718 Protocol (XMPP): Address Format", RFC 6122, March 2011. 720 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 721 6.2", 2012, 722 . 724 9.2. Informative References 726 [I-D.ietf-straw-b2bua-loop-detection] 727 Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for 728 Session Initiation Protocol (SIP) Back-to- Back User 729 Agents (B2BUAs)", draft-ietf-straw-b2bua-loop-detection-02 730 (work in progress), September 2013. 732 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 733 specifying the location of services (DNS SRV)", RFC 2782, 734 February 2000. 736 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 737 and D. Gurle, "Session Initiation Protocol (SIP) Extension 738 for Instant Messaging", RFC 3428, December 2002. 740 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 741 Internationalized Strings ("STRINGPREP")", RFC 3454, 742 December 2002. 744 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 745 Initiation Protocol (SIP)", RFC 3856, August 2004. 747 [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", 748 RFC 3859, August 2004. 750 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 751 (CPIM)", RFC 3860, August 2004. 753 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 754 RFC 3966, December 2004. 756 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 757 (IRIs) and Uniform Resource Identifiers (URIs) for the 758 Extensible Messaging and Presence Protocol (XMPP)", 759 RFC 5122, February 2008. 761 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 762 October 2008. 764 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 765 Initiated Connections in the Session Initiation Protocol 766 (SIP)", RFC 5626, October 2009. 768 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 769 Protocol (XMPP): Instant Messaging and Presence", 770 RFC 6121, March 2011. 772 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 773 July 2012. 775 [I-D.ietf-xmpp-6122bis] 776 Saint-Andre, P., "Extensible Messaging and Presence 777 Protocol (XMPP): Address Format", 778 draft-ietf-xmpp-6122bis-07 (work in progress), April 2013. 780 [XEP-0106] 781 Saint-Andre, P. and J. Hildebrand, "JID Escaping", XSF 782 XEP 0106, May 2005. 784 [XEP-0131] 785 Saint-Andre, P. and J. Hildebrand, "Stanza Headers and 786 Internet Metadata", XSF XEP 0131, July 2006. 788 Appendix A. Acknowledgements 790 The authors wish to thank the following individuals for their 791 feedback: Mary Barnes, Mike De Vries, Fabio Forno, Adrian Georgescu, 792 Philipp Hancke, Saul Ibarra Corretge, Markus Isomaki, Olle Johansson, 793 Paul Kyzivat, Salvatore Loreto, Daniel-Constantin Mierla, Tory 794 Patnoe, and Robert Sparks. 796 Authors' Addresses 798 Peter Saint-Andre 799 Cisco Systems, Inc. 800 1899 Wynkoop Street, Suite 600 801 Denver, CO 80202 802 USA 804 Phone: +1-303-308-3282 805 Email: psaintan@cisco.com 807 Avshalom Houri 808 IBM 809 Rorberg Building, Pekris 3 810 Rehovot 76123 811 Israel 813 Email: avshalom@il.ibm.com 814 Joe Hildebrand 815 Cisco Systems, Inc. 816 1899 Wynkoop Street, Suite 600 817 Denver, CO 80202 818 USA 820 Email: jhildebr@cisco.com