From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7247.txt | 1347 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1347 insertions(+) create mode 100644 doc/rfc/rfc7247.txt (limited to 'doc/rfc/rfc7247.txt') diff --git a/doc/rfc/rfc7247.txt b/doc/rfc/rfc7247.txt new file mode 100644 index 0000000..03424b7 --- /dev/null +++ b/doc/rfc/rfc7247.txt @@ -0,0 +1,1347 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Saint-Andre +Request for Comments: 7247 &yet +Category: Standards Track A. Houri +ISSN: 2070-1721 IBM + J. Hildebrand + Cisco Systems, Inc. + May 2014 + + + Interworking between the Session Initiation Protocol (SIP) and the + Extensible Messaging and Presence Protocol (XMPP): + Architecture, Addresses, and Error Handling + +Abstract + + As a foundation for the definition of bidirectional protocol mappings + between the Session Initiation Protocol (SIP) and the Extensible + Messaging and Presence Protocol (XMPP), this document specifies the + architectural assumptions underlying such mappings as well as the + mapping of addresses and error conditions. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7247. + + + + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 1] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Intended Audience ...............................................3 + 3. Terminology .....................................................4 + 4. Architectural Assumptions .......................................4 + 5. Interdomain Federation ..........................................6 + 6. Address Mapping .................................................7 + 6.1. Overview ...................................................7 + 6.2. Local Part Mapping .........................................9 + 6.3. Instance-Specific Mapping .................................11 + 6.4. SIP to XMPP ...............................................11 + 6.5. XMPP to SIP ...............................................12 + 7. Error Mapping ..................................................14 + 7.1. XMPP to SIP ...............................................15 + 7.2. SIP to XMPP ...............................................17 + 8. Security Considerations ........................................20 + 9. References .....................................................21 + 9.1. Normative References ......................................21 + 9.2. Informative References ....................................22 + Appendix A. Acknowledgements ......................................24 + + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 2] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + +1. Introduction + + The IETF has worked on two signaling technologies that can be used + for multimedia session negotiation, instant messaging, presence, + capabilities discovery, notifications, and other functions served by + real-time communication applications: + + o The Session Initiation Protocol [RFC3261], along with various SIP + extensions developed within the SIP for Instant Messaging and + Presence Leveraging Extensions (SIMPLE) Working Group. + + o The Extensible Messaging and Presence Protocol [RFC6120], along + with various XMPP extensions developed by the IETF as well as by + the XMPP Standards Foundation (XSF). + + Because these technologies are widely deployed, it is important to + clearly define mappings between them for the sake of interworking. + This document provides the basis for a series of SIP-XMPP + interworking specifications by defining architectural assumptions, + address translation methods, and error condition mappings. Other + documents in this series define mappings for presence, messaging, and + media sessions. + + The guidelines in this series are based on implementation and + deployment experience, and they describe techniques that have worked + well in the field with existing systems. In practice, interworking + has been achieved through direct protocol mappings, not through + mapping to an abstract model as described in, for example, [RFC3859] + and [RFC3860]. Therefore, this series describes the direct mapping + approach in enough detail for developers of new implementations to + achieve practical interworking between SIP systems and XMPP systems. + +2. Intended Audience + + The documents in this series are intended for use by software + developers who have an existing system based on one of these + technologies (e.g., SIP) and would like to enable communication from + that existing system to systems based on the other technology (e.g., + XMPP). With regard to this document, we assume that readers are + familiar with the core specifications for both SIP and XMPP; with + regard to the other documents in this series, we assume that readers + are familiar with this document as well as with the relevant SIP and + XMPP extensions. + + + + + + + + +Saint-Andre, et al. Standards Track [Page 3] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + +3. Terminology + + A number of terms used here are explained in [RFC3261] and [RFC6120]. + + Several examples use the "XML Notation" from the Internationalized + Resource Identifier (IRI) specification [RFC3987] to represent + Unicode characters outside the ASCII range (e.g., the string "ue" + stands for the Unicode character [UNICODE] LATIN SMALL LETTER U WITH + DIAERESIS, U+00FC). + + In architectural diagrams, SIP traffic is shown using arrows such as + "***>", whereas XMPP traffic is shown using arrows such as "...>". + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +4. Architectural Assumptions + + Protocol translation between SIP and XMPP could occur in a number of + different entities, depending on the architecture of real-time + communication deployments. For example, protocol translation could + occur within a multiprotocol server (which uses protocol-specific + connection managers to initiate traffic to and accept traffic from + clients or other servers natively using SIP/SIMPLE, XMPP, etc.), + within a multiprotocol client (which enables a user to establish + connections natively with various servers using SIP/SIMPLE, XMPP, + etc.), or within a gateway that acts as a dedicated protocol + translator (which takes one protocol as input and provides another + protocol as output). + + This document assumes that the protocol translation will occur within + a gateway, specifically: + + o When information needs to flow from an XMPP-based system to a SIP- + based system, protocol translation will occur within an "XMPP-to- + SIP gateway" that translates XMPP syntax and semantics on behalf + of an "XMPP server" (together, these two logical functions + comprise an "XMPP service"). + + o When information needs to flow from a SIP-based system to an XMPP- + based system, protocol translation will occur within a "SIP-to- + XMPP gateway" that translates SIP syntax and semantics on behalf + of a "SIP server" (together, these two logical functions comprise + a "SIP service"). + + + + + +Saint-Andre, et al. Standards Track [Page 4] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + Naturally, these logical functions could occur in one and the same + actual entity; we differentiate between them mainly for explanatory + purposes (although, in practice, such gateways are indeed fairly + common). + + Note: This assumption is not meant to discourage protocol + translation within multiprotocol clients or servers; instead, this + assumption is followed mainly to clarify the discussion and + examples so that the protocol translation principles can be more + easily understood and can be applied by client and server + implementors with appropriate modifications to the examples and + terminology. + + This document assumes that a gateway will translate directly from one + protocol to the other. For the sake of the examples, we further + assume that protocol translation will occur within a gateway in the + source domain, so that information generated by the user of an XMPP + system will be translated by a gateway within the trust domain of + that XMPP system, and information generated by the user of a SIP + system will be translated by a gateway within the trust domain of + that SIP system. However, nothing in this document ought to be taken + as recommending against protocol translation at the destination + domain. + + An architectural diagram for a possible gateway deployment is shown + below, where the entities have the following significance and the "#" + character is used to show the boundary of a trust domain: + + o romeo@example.net -- a SIP user. + + o example.net -- a SIP server with an associated gateway ("S2X GW") + to XMPP. + + o juliet@example.com -- an XMPP user. + + o example.com -- an XMPP server with an associated gateway ("X2S + GW") to SIP. + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 5] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + ######################################################### + # # + # +-----+ # + # | S2X | # + # +-------------+ GW |<...........>+-------------+ # + # | SIP Server +-----+ | XMPP Server | # + # | example.net | +-----+ example.com | # + # +-------------+<***********>| X2S +-------------+ # + # * | GW | : # + # * +-----+ : # + # * : # + # romeo@example.net juliet@example.com # + # # + ######################################################### + + Legend: + XMPP = ... or : + SIP = * + + Figure 1: Possible Gateway Deployment Architecture + + Note that bidirectional communication between the SIP server and the + XMPP server can be established over either SIP or XMPP. If the XMPP + user initiates the interaction, then the XMPP server would invoke its + XMPP-to-SIP gateway; thus, the communication would occur over SIP. + If the SIP user initiates the interaction, then the SIP server would + invoke its SIP-to-XMPP gateway; thus, the communication would occur + over XMPP. + +5. Interdomain Federation + + The architectural assumptions underlying this document imply that + communication between a SIP system and an XMPP system will take place + using interdomain federation: the SIP server invokes its associated + SIP-to-XMPP gateway, which communicates with the XMPP server using + native XMPP server-to-server methods; similarly, the XMPP server + invokes its associated XMPP-to-SIP gateway, which communicates with + the SIP server using native SIP server-to-server methods. + + When an XMPP server receives an XMPP stanza whose 'to' address + specifies or includes a domain other than the domain of the XMPP + server, it needs to determine whether the destination domain + communicates via XMPP or SIP. To do so, it performs one or more DNS + SRV lookups [RFC2782] for "_xmpp-server" records as specified in + [RFC6120]. If the response returns a hostname, the XMPP server can + attempt XMPP communication. If not, it can determine the appropriate + location for SIP communication at the target domain using the + procedures specified in [RFC3263]. + + + +Saint-Andre, et al. Standards Track [Page 6] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + Similarly, when a SIP server receives a SIP message whose Request-URI + or To header specifies or includes a domain other than the domain of + the SIP server, it needs to determine whether the destination domain + communicates via SIP or XMPP. To do so, it uses the procedures + specified in [RFC3263]. If that response returns a hostname, the SIP + server can attempt SIP communication. If not, it can perform one or + more DNS SRV lookups [RFC2782] for "_xmpp-server" records as + specified in [RFC6120]. + + In both cases, the server in question might have previously + determined that the foreign domain communicates via SIP or XMPP, in + which case it would not need to perform the relevant DNS lookups. + The caching of such information is a matter of implementation and + local service policy and is therefore out of scope for this document. + + Existing SIP and XMPP server implementations do not typically include + the ability to communicate using the other technology (XMPP for SIP + implementations, SIP for XMPP implementations). One common + architectural pattern is to associate a gateway with the core server + implementation (e.g., in XMPP such a gateway might be called a + "connection manager"). How exactly such a gateway interacts with the + core server to complete tasks such as address lookups and + communication with systems that use the other technology is a matter + of implementation (e.g., the gateway might be an add-on module that + is trusted by the core server to act as a fallback delivery mechanism + if the remote domain does not support the server's native + communication technology). + + Because [RFC6120] specifies a binding of XMPP to TCP, a gateway from + SIP to XMPP will need to support TCP as the underlying transport + protocol. By contrast, as specified in [RFC3261], either TCP or UDP + can be used as the underlying transport for SIP messages, and a given + SIP deployment might support only UDP; therefore, a gateway from XMPP + to SIP might need to communicate with a SIP server using either TCP + or UDP. + +6. Address Mapping + +6.1. Overview + + The basic SIP address format is a 'sip' or 'sips' URI as specified in + [RFC3261]. When a SIP entity supports extensions for instant + messaging it might be identified by an 'im' URI as specified in the + Common Profile for Instant Messaging [RFC3860] (see [RFC3428]), and + when a SIP entity supports extensions for presence it might be + + + + + + +Saint-Andre, et al. Standards Track [Page 7] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + identified by a 'pres' URI as specified in the Common Profile for + Presence [RFC3859] (see [RFC3856]). SIP entities typically also + support the 'tel' URI scheme [RFC3966] and might support other URI + schemes as well. + + The XMPP address format is specified in [RFC6122] (although note that + XMPP URIs [RFC5122] are not used natively on the XMPP network); in + addition, [RFC6121] encourages instant messaging and presence + applications of XMPP to also support 'im' and 'pres' URIs as + specified in [RFC3860] and [RFC3859], respectively, although such + support might simply involve leaving resolution of such addresses up + to an XMPP server. + + In this document we primarily describe mappings for addresses of the + form ; however, we also provide guidelines for mapping + the addresses of specific user agent instances, which take the form + of Globally Routable User Agent URIs (GRUUs) in SIP and + "resourceparts" in XMPP. Mapping of protocol-specific identifiers + (such as telephone numbers) is out of scope for this specification. + In addition, we have ruled the mapping of domain names as out of + scope for now, since that is a matter for the Domain Name System; + specifically, the issue for interworking between SIP and XMPP relates + to the translation of fully internationalized domain names (IDNs) + into non-internationalized domain names (IDNs are not allowed in the + SIP address format but are allowed in the XMPP address via + Internationalized Domain Names in Applications; see [RFC6122] and + [XMPP-ADDRESS-FORMAT]). Therefore, in the following sections we + focus primarily on the local part of an address (these are called + variously "usernames", "instant inboxes", "presentities", and + "localparts" in the protocols at issue), secondarily on the instance- + specific part of an address, and not at all on the domain-name part + of an address. + + The 'sip'/'sips', 'im'/'pres', and XMPP address schemes allow + different sets of characters (although all three allow alphanumeric + characters and disallow both spaces and control characters). In some + cases, characters allowed in one scheme are disallowed in others; + these characters need to be mapped appropriately in order to ensure + interworking across systems. + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 8] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + +6.2. Local Part Mapping + + The local part of a 'sip'/'sips' URI inherits from the "userinfo" + rule in [RFC3986] with several changes; here we discuss the SIP + "user" rule only (using ABNF as defined in [RFC5234]): + + user = 1*( unreserved / escaped / user-unreserved ) + user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" + unreserved = alphanum / mark + mark = "-" / "_" / "." / "!" / "~" / "*" / "'" + / "(" / ")" + + Here we make the simplifying assumption that the local part of an + 'im'/'pres' URI inherits from the "dot-atom-text" rule in [RFC5322] + rather than the more complicated "local-part" rule: + + dot-atom-text = 1*atext *("." 1*atext) + atext = ALPHA / DIGIT / ; Any character except + "!" / "#" / "$" / ; controls, SP, and + "%" / "&" / "'" / ; specials. Used for + "*" / "+" / "-" / ; atoms. + "/" / "=" / "?" / + "^" / "_" / "`" / + "{" / "|" / "}" / + "~" + + The local part of an XMPP address allows any ASCII character except + space, controls, and the " & ' / : < > @ characters. + + + + + + + + + + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 9] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + To summarize the foregoing information, the following table lists the + allowed and disallowed characters in the local part of identifiers + for each protocol (aside from the alphanumeric, space, and control + characters), in order by hexadecimal character number (where each "A" + row shows the allowed characters and each "D" row shows the + disallowed characters). + + +---+----------------------------------+ + | SIP/SIPS CHARACTERS | + +---+----------------------------------+ + | A | ! $ &'()*+,-./ ; = ? _ ~ | + | D | "# % : < > @[\]^ `{|} | + +---+----------------------------------+ + | IM/PRES CHARACTERS | + +---+----------------------------------+ + | A | ! #$%&' *+ - / = ? ^_`{|}~ | + | D | " () , . :;< > @[\] | + +---+----------------------------------+ + | XMPP CHARACTERS | + +---+----------------------------------+ + | A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ | + | D | " &' /: < > @ | + +---+----------------------------------+ + + Table 1: Allowed and Disallowed Characters + + When transforming the local part of an address from one address + format to another, an application SHOULD proceed as follows: + + 1. Unescape any escaped characters in the source address (e.g., from + SIP to XMPP unescape "%23" to "#" per [RFC3986], and from XMPP to + SIP unescape "\27" to "'" per [XEP-0106]). + + 2. Leave unmodified any characters that are allowed in the + destination scheme. + + 3. Escape any characters that are allowed in the source scheme but + reserved in the destination scheme, as escaping is defined for + the destination scheme. In particular: + + * Where the destination scheme is a URI (i.e., an 'im', 'pres', + 'sip', or 'sips' URI), each reserved character MUST be + percent-encoded to "%hexhex" as specified in Section 2.5 of + [RFC3986] (e.g., when transforming from XMPP to SIP, encode + "#" as "%23"). + + + + + + +Saint-Andre, et al. Standards Track [Page 10] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + * Where the destination scheme is a native XMPP address, each + reserved character MUST be encoded to "\hexhex" as specified + in [XEP-0106] (e.g., when transforming from SIP to XMPP, + encode "'" as "\27"). + +6.3. Instance-Specific Mapping + + The meaning of a resourcepart in XMPP (i.e., the portion of a Jabber + ID (JID) after the slash character, such as "foo" in + "user@example.com/foo") matches that of a Globally Routable User + Agent URI (GRUU) in SIP [RFC5627]. In both cases, these constructs + identify a particular device associated with the bare JID + ("localpart@domainpart") of an XMPP entity or with the Address of + Record (AOR) of a SIP entity. Therefore, it is reasonable to map the + value of a "gr" URI parameter to an XMPP resourcepart and vice versa. + + The mapping described here does not apply to temporary GRUUs -- only + to GRUUs associated with an Address of Record. + + The "gr" URI parameter in SIP can contain only characters from the + ASCII range (although characters outside the ASCII range can be + percent-encoded in accordance with [RFC3986]), whereas an XMPP + resourcepart can contain nearly any Unicode character [UNICODE]. + Therefore, Unicode characters outside the ASCII range need to be + mapped to characters in the ASCII range, as described below. + +6.4. SIP to XMPP + + The following is a high-level algorithm for mapping a 'sip', 'sips', + 'im', or 'pres' URI to an XMPP address: + + 1. Remove URI scheme. + + 2. Split at the first '@' character into local part and hostname + (mapping the latter is out of scope). + + 3. Translate any percent-encoded strings ("%hexhex") to percent- + decoded octets. + + 4. Treat result as a UTF-8 string. + + 5. Translate "&" to "\26", "'" to "\27", and "/" to "\2f", + respectively in order to properly handle the characters + disallowed in XMPP addresses but allowed in 'sip'/'sips' URIs and + 'im'/'pres' URIs as shown in Table 1 above (this is consistent + with [XEP-0106]). + + + + + +Saint-Andre, et al. Standards Track [Page 11] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + 6. Apply Nodeprep profile of stringprep [RFC3454] or its replacement + (see [RFC6122] and [XMPP-ADDRESS-FORMAT]) for canonicalization + (OPTIONAL). + + 7. Recombine local part with mapped hostname to form a bare JID + ("localpart@domainpart"). + + 8. If the (SIP) address contained a "gr" URI parameter, append a + slash character "/" and the "gr" value to the bare JID to form a + full JID ("localpart@domainpart/resourcepart"). + + Several examples follow, illustrating steps 3, 5, and 8 described + above. + + +----------------------------+--------------------------+ + | SIP URI | XMPP Address | + +----------------------------+--------------------------+ + | sip:f%C3%BC@sip.example | fü@sip.example | + +----------------------------+--------------------------+ + | sip:o'malley@sip.example | o\27malley@sip.example | + +----------------------------+--------------------------+ + | sip:foo@sip.example;gr=bar | foo@sip.example/bar | + +----------------------------+--------------------------+ + + In the first example, the string "%C3%BC" is a percent-encoded + representation of the UTF-8-encoded Unicode character LATIN SMALL + LETTER U WITH DIAERESIS (U+00FC), whereas the string "ü" is the + same character shown for documentation purposes using the XML + Notation defined in [RFC3987] (in XMPP, it would be sent directly as + a UTF-8-encoded Unicode character and not percent-encoded as in a SIP + URI to comply with the URI syntax defined in [RFC3986]). + +6.5. XMPP to SIP + + The following is a high-level algorithm for mapping an XMPP address + to a 'sip', 'sips', 'im', or 'pres' URI: + + 1. Split XMPP address into localpart (mapping described in remaining + steps), domainpart (hostname; mapping is out of scope), and + resourcepart (specifier for particular device or connection, for + which an OPTIONAL mapping is described below). + + 2. Apply Nodeprep profile of stringprep [RFC3454] or its replacement + (see [RFC6122] and [XMPP-ADDRESS-FORMAT]) for canonicalization of + the XMPP localpart (OPTIONAL). + + 3. Translate "\26" to "&", "\27" to "'", and "\2f" to "/", + respectively (this is consistent with [XEP-0106]). + + + +Saint-Andre, et al. Standards Track [Page 12] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + 4. Determine if the foreign domain supports 'im' and 'pres' URIs + (discovered via [RFC2782] lookup as specified in [RFC6121]), else + assume that the foreign domain supports 'sip'/'sips' URIs. + + 5. If converting into 'im' or 'pres' URI, for each byte, if the byte + is in the set (),.;[\] or is a UTF-8 character outside the ASCII + range, then percent-encode that byte to "%hexhex" format. If + converting into 'sip' or 'sips' URI, for each byte, if the byte + is in the set #%[\]^`{|} or is a UTF-8 character outside the + ASCII range, then percent-encode that byte to "%hexhex" format. + + 6. Combine resulting local part with mapped hostname to form + local@domain address. + + 7. Prepend with the string 'im:' (for XMPP stanzas) or + 'pres:' (for XMPP stanzas) if foreign domain supports + these, else prepend with the string 'sip:' or 'sips:' according + to local service policy. + + 8. If the XMPP address included a resourcepart and the destination + URI scheme is 'sip' or 'sips', optionally append the slash + character '/' and then append the resourcepart (making sure to + percent-encode any UTF-8 characters outside the ASCII range) as + the "gr" URI parameter. + + Several examples follow, illustrating steps 3, 5, and 8 described + above. + + +---------------------------+---------------------------------+ + | XMPP Address | SIP URI | + +---------------------------+---------------------------------+ + | m\26m@xmpp.example | sip:m&m@xmpp.example | + | tschüss@xmpp.example | sip:tsch%C3%BCss@xmpp.example | + | baz@xmpp.example/qux | sip:baz@xmpp.example;gr=qux | + +---------------------------+---------------------------------+ + + As above, in the first example the string "ü" is the Unicode + character LATIN SMALL LETTER U WITH DIAERESIS (U+00FC) shown for + documentation purposes using the XML Notation defined in [RFC3987] + (in XMPP, it would be sent directly as a UTF-8-encoded Unicode + character and not percent-encoded, whereas the string "%C3%BC" is a + percent-encoded representation of the same character. + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 13] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + +7. Error Mapping + + Various differences between XMPP error conditions and SIP response + codes make it hard to provide a comprehensive and consistent mapping + between the protocols: + + o Whereas the set of XMPP error conditions is fixed in the core XMPP + specification (and supplemented where needed by application- + specific extensions), the set of SIP response codes is more open + to change, as evidenced by the IANA registry of SIP response + codes. + + o XMPP has defined fewer error conditions related to stanza handling + (22 are defined in [RFC6120]) than SIP has defined response codes + related to message handling (at the date of this writing, 71 SIP + response codes are registered with IANA as defined in [RFC3261] + and numerous SIP extensions). + + o In many cases, the SIP response codes are more specific than the + XMPP error conditions (e.g., from an XMPP perspective the SIP + codes "413 Request Entity Too Large" and "414 Request-URI Too + Long" are simply two different types of response to the same bad + request, and the SIP codes "415 Unsupported Media Type" and "416 + Unsupported URI Scheme" are two different responses to a request + that is not acceptable). + + o SIP differentiates between responses about a particular endpoint + or resource (the 4xx series) and responses about a user, i.e., all + of a user's endpoints or resources (the 6xx series). There is no + such distinction in XMPP, since the same error condition can be + returned in relation to the "bare JID" (localpart@domainpart) of a + user or the "full JID" (localpart@domainpart/resourcepart) of a + particular endpoint or resource, depending on the 'to' address of + the original request. + + As a result of these and other factors, the mapping of error + conditions and response codes is more of an art than a science. This + document provides suggested mappings, but implementations are free to + deviate from these mappings if needed. Also, because no XMPP error + conditions are equivalent to the provisional (1xx) and successful + (2xx) response codes in SIP, this document suggests mappings only for + the SIP redirection (3xx), request failure (4xx), server failure + (5xx), and global failure (6xx) response code families. + + Supplementary information about SIP response codes can be expressed + in the "Reason-Phrase" in the Status-Line header, and detailed + information about XMPP error conditions can be expressed in the + child of the element. Although the semantics of + + + +Saint-Andre, et al. Standards Track [Page 14] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + these constructs are specified in a slightly different way, it is + reasonable for a gateway to map these constructs to each other if + they are found in a SIP response or XMPP error stanza. + +7.1. XMPP to SIP + + The mapping of specific XMPP error conditions to SIP response codes + SHOULD be as described in the following table. + + +------------------------------+---------------------+ + | XMPP Error Condition | SIP Response Code | + +------------------------------+---------------------+ + | | 400 | + +------------------------------+---------------------+ + | | 400 | + +------------------------------+---------------------+ + | | 405 or 501 (1) | + +------------------------------+---------------------+ + | | 403 or 603 (2) | + +------------------------------+---------------------+ + | | 301 or 410 (3) | + +------------------------------+---------------------+ + | | 500 | + +------------------------------+---------------------+ + | | 404 or 604 (2) | + +------------------------------+---------------------+ + | | 400 | + +------------------------------+---------------------+ + | | 406 or 606 (2) | + +------------------------------+---------------------+ + | | 403 | + +------------------------------+---------------------+ + | | 401 | + +------------------------------+---------------------+ + | | 403 | + +------------------------------+---------------------+ + | | 480 or 600 (2) | + +------------------------------+---------------------+ + | | 302 | + +------------------------------+---------------------+ + | | 407 | + +------------------------------+---------------------+ + | | 404 or 408 (4) | + +------------------------------+---------------------+ + | | 408 | + +------------------------------+---------------------+ + + + + + +Saint-Andre, et al. Standards Track [Page 15] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + +------------------------------+---------------------+ + | | 500 | + +------------------------------+---------------------+ + | | see note (5) below | + +------------------------------+---------------------+ + | | 400 | + +------------------------------+---------------------+ + | | 400 | + +------------------------------+---------------------+ + | | 491 or 400 | + +------------------------------+---------------------+ + + Table 2: Mapping of XMPP Error Conditions to SIP Response Codes + + (1) If the error relates to a "full JID" (localpart@domainpart/ + resourcepart), the SIP 405 response code is RECOMMENDED. If the + error relates to a "bare JID" (localpart@domainpart), the SIP + 501 response code is RECOMMENDED. + + (2) If the error relates to a "full JID" (localpart@domainpart/ + resourcepart), the SIP response code from the 4xx series is + RECOMMENDED. If the error relates to a "bare JID" + (localpart@domainpart), the SIP response code from the 6xx + series is RECOMMENDED. + + (3) If the element includes XML character data specifying + the new address, the error MUST be mapped to SIP 301; if not, it + MUST be mapped to SIP 410. + + (4) The XMPP error can mean that the + remote server either (a) does not exist or (b) cannot be + resolved. SIP has two different response codes here: 404 to + cover (a) and 408 to cover (b). + + (5) The XMPP error condition is widely used + to inform the requesting entity that the intended recipient does + not support the relevant feature, to signal that a server cannot + perform the requested service either generally or in relation to + a particular user, and to avoid disclosing whether a given + account exists at all. This is quite different from the + semantics of the SIP 503 Service Unavailable response code, + which is used to signal that communication with a server is + impossible (e.g., even if the XMPP error + condition is returned in relation to a specific user, the SIP + 503 response code will be interpreted as applying to all future + requests to this server, not just requests for the specific + user). Therefore, mapping the XMPP error + condition to the SIP 503 Service Unavailable response code is + + + +Saint-Andre, et al. Standards Track [Page 16] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + NOT RECOMMENDED. Although no precise mapping is available, the + SIP 403 Forbidden and 405 Method Not Allowed response codes are + closest in meaning to the XMPP error + condition. + +7.2. SIP to XMPP + + The mapping of SIP response codes to XMPP error conditions SHOULD be + as described in the following table. If a gateway encounters a SIP + response code that is not listed below, it SHOULD map a 3xx-series + code to , a 4xx-series code to , a 5xx- + series code to , and a 6xx-series code to + . + + +---------------------+---------------------------------+ + | SIP Response Code | XMPP Error Condition | + +---------------------+---------------------------------+ + | 3xx | | + +---------------------+---------------------------------+ + | 300 | | + +---------------------+---------------------------------+ + | 301 | (1) | + +---------------------+---------------------------------+ + | 302 | | + +---------------------+---------------------------------+ + | 305 | | + +---------------------+---------------------------------+ + | 380 | | + +---------------------+---------------------------------+ + | 4xx | | + +---------------------+---------------------------------+ + | 400 | | + +---------------------+---------------------------------+ + | 401 | | + +---------------------+---------------------------------+ + | 402 | (2) | + +---------------------+---------------------------------+ + | 403 | (3) | + +---------------------+---------------------------------+ + | 404 | (4) | + +---------------------+---------------------------------+ + | 405 | | + +---------------------+---------------------------------+ + | 406 | | + +---------------------+---------------------------------+ + | 407 | | + +---------------------+---------------------------------+ + + + + +Saint-Andre, et al. Standards Track [Page 17] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + +---------------------+---------------------------------+ + | 408 | (5) | + +---------------------+---------------------------------+ + | 410 | (1) | + +---------------------+---------------------------------+ + | 413 | | + +---------------------+---------------------------------+ + | 414 | | + +---------------------+---------------------------------+ + | 415 | | + +---------------------+---------------------------------+ + | 416 | | + +---------------------+---------------------------------+ + | 420 | | + +---------------------+---------------------------------+ + | 421 | | + +---------------------+---------------------------------+ + | 423 | | + +---------------------+---------------------------------+ + | 430 | (6) | + +---------------------+---------------------------------+ + | 439 | (6) | + +---------------------+---------------------------------+ + | 440 | (7) | + +---------------------+---------------------------------+ + | 480 | | + +---------------------+---------------------------------+ + | 481 | | + +---------------------+---------------------------------+ + | 482 | | + +---------------------+---------------------------------+ + | 483 | | + +---------------------+---------------------------------+ + | 484 | | + +---------------------+---------------------------------+ + | 485 | | + +---------------------+---------------------------------+ + | 486 | | + +---------------------+---------------------------------+ + | 487 | | + +---------------------+---------------------------------+ + | 488 | | + +---------------------+---------------------------------+ + | 489 | (8) | + +---------------------+---------------------------------+ + | 491 | | + +---------------------+---------------------------------+ + + + + +Saint-Andre, et al. Standards Track [Page 18] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + +---------------------+---------------------------------+ + | 493 | | + +---------------------+---------------------------------+ + | 5xx | | + +---------------------+---------------------------------+ + | 500 | | + +---------------------+---------------------------------+ + | 501 | | + +---------------------+---------------------------------+ + | 502 | | + +---------------------+---------------------------------+ + | 503 | (9) | + +---------------------+---------------------------------+ + | 504 | | + +---------------------+---------------------------------+ + | 505 | | + +---------------------+---------------------------------+ + | 513 | | + +---------------------+---------------------------------+ + | 6xx | | + +---------------------+---------------------------------+ + | 600 | | + +---------------------+---------------------------------+ + | 603 | | + +---------------------+---------------------------------+ + | 604 | | + +---------------------+---------------------------------+ + | 606 | | + +---------------------+---------------------------------+ + + Table 3: Mapping of SIP Response Codes to XMPP Error Conditions + + (1) When mapping SIP 301 to XMPP , the element MUST + include XML character data specifying the new address. When + mapping SIP 410 to XMPP , the element MUST NOT + include XML character data specifying a new address. + + (2) The XMPP error condition was removed in + [RFC6120]. Therefore, a mapping to XMPP is + suggested instead. + + (3) Depending on the scenario, other possible translations for + SIP 403 are and . + + (4) Depending on the scenario, another possible translation for + SIP 404 is . + + + + + +Saint-Andre, et al. Standards Track [Page 19] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + (5) Depending on the scenario, another possible translation for + SIP 408 is . + + (6) Codes 430 and 439 are defined in [RFC5626]. + + (7) Code 440 is defined in [RFC5393]. + + (8) Code 489 is defined in [RFC6665]. + + (9) Regarding the semantic mismatch between XMPP + and SIP code 503, see note (5) in + Section 7.1 of this document. + +8. Security Considerations + + Detailed security considerations for SIP and XMPP are given in + [RFC3261] and [RFC6120], respectively. + + To protect information sent between SIP and XMPP systems, deployed + gateways SHOULD use Transport Layer Security (TLS) [RFC5246] when + communicating over TCP and Datagram Transport Layer Security (DTLS) + [RFC6347] when communicating over UDP. + + As specified in Section 26.4.4 of [RFC3261] and updated by [RFC5630], + a To header or a Request-URI containing a Session Initiation Protocol + Secure (SIPS) URI is used to indicate that all hops in a + communication path need to be protected using TLS. Because XMPP + lacks a way to signal that all hops need to be protected, if the To + header or Request-URI of a SIP message is a SIPS URI then the SIP-to- + XMPP gateway MUST NOT translate the SIP message into an XMPP stanza + and MUST NOT route it to the destination XMPP server (there might be + exceptions to such a policy, such as explicit agreement among two + operators to enforce per-hop security, but currently they are quite + rare). + + A gateway between SIP and XMPP (in either direction) effectively acts + as a SIP back-to-back user agent ("B2BUA"). The amplification + vulnerability described in [RFC5393] can manifest itself with B2BUAs + (see also [B2BUA-LOOP-DETECT]), and a gateway SHOULD implement the + loop-detection methods defined in that specification to help mitigate + the possibility of amplification attacks. Note that although it + would be possible to signal the Max-Forwards and Max-Breadth SIP + headers over XMPP using the Stanza Headers and Internet Metadata + (SHIM) extension [XEP-0131], that extension is not widely + implemented; therefore, defenses against excessive looping and + amplification attacks when messages pass back and forth through SIP + and XMPP networks are out of scope for this document. However, it + + + + +Saint-Andre, et al. Standards Track [Page 20] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + ought to be addressed in the future, and implementations are strongly + encouraged to incorporate appropriate countermeasures wherever + possible. + + The ability to use a wide range of Unicode characters [UNICODE] can + lead to security issues, especially the possibility of user confusion + over identifiers containing visually similar characters (also called + "confusable characters" or "confusables"). The PRECIS framework + specification [PRECIS] describes some of these security issues, and + additional guidance can be found in [UTS39]. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation + Protocol (SIP): Locating SIP Servers", RFC 3263, + June 2002. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource + Identifiers (IRIs)", RFC 3987, January 2005. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen, + "Addressing an Amplification Vulnerability in Session + Initiation Protocol (SIP) Forking Proxies", RFC 5393, + December 2008. + + [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User + Agent URIs (GRUUs) in the Session Initiation Protocol + (SIP)", RFC 5627, October 2009. + + + +Saint-Andre, et al. Standards Track [Page 21] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session + Initiation Protocol (SIP)", RFC 5630, October 2009. + + [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence + Protocol (XMPP): Core", RFC 6120, March 2011. + + [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence + Protocol (XMPP): Address Format", RFC 6122, March 2011. + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, January 2012. + + [UNICODE] The Unicode Consortium, "The Unicode Standard, + Version 6.3", 2013, + . + +9.2. Informative References + + [B2BUA-LOOP-DETECT] + Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for + Session Initiation Protocol (SIP) Back-to-Back User Agents + (B2BUAs)", Work in Progress, February 2014. + + [PRECIS] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: + Preparation and Comparison of Internationalized Strings in + Application Protocols", Work in Progress, April 2014. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., + and D. Gurle, "Session Initiation Protocol (SIP) Extension + for Instant Messaging", RFC 3428, December 2002. + + [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of + Internationalized Strings ("stringprep")", RFC 3454, + December 2002. + + [RFC3856] Rosenberg, J., "A Presence Event Package for the Session + Initiation Protocol (SIP)", RFC 3856, August 2004. + + [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", + RFC 3859, August 2004. + + [RFC3860] Peterson, J., "Common Profile for Instant Messaging + (CPIM)", RFC 3860, August 2004. + + + + +Saint-Andre, et al. Standards Track [Page 22] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + + [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", + RFC 3966, December 2004. + + [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers + (IRIs) and Uniform Resource Identifiers (URIs) for the + Extensible Messaging and Presence Protocol (XMPP)", + RFC 5122, February 2008. + + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + October 2008. + + [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- + Initiated Connections in the Session Initiation Protocol + (SIP)", RFC 5626, October 2009. + + [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence + Protocol (XMPP): Instant Messaging and Presence", + RFC 6121, March 2011. + + [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, + July 2012. + + [UTS39] The Unicode Consortium, "Unicode Technical Standard #39: + Unicode Security Mechanisms", November 2013, + . + + [XEP-0106] Hildebrand, J. and P. Saint-Andre, "JID Escaping", + XSF XEP 0106, June 2007, + . + + [XEP-0131] Saint-Andre, P. and J. Hildebrand, "Stanza Headers and + Internet Metadata", XSF XEP 0131, July 2006, + . + + [XMPP-ADDRESS-FORMAT] + Saint-Andre, P., "Extensible Messaging and Presence + Protocol (XMPP): Address Format", Work in Progress, + March 2014. + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 23] + +RFC 7247 SIP-XMPP Interworking: Core May 2014 + + +Appendix A. Acknowledgements + + The authors wish to thank the following individuals for their + feedback: Mary Barnes, Dave Cridland, Dave Crocker, Mike De Vries, + Fabio Forno, Adrian Georgescu, Philipp Hancke, Saul Ibarra Corretge, + Markus Isomaki, Olle Johansson, Paul Kyzivat, Salvatore Loreto, + Daniel-Constantin Mierla, Tory Patnoe, and Robert Sparks. + + Dan Romascanu reviewed the document on behalf of the General Area + Review Team. + + During IESG review, Stephen Farrell, Ted Lemon, Pete Resnick, and + Sean Turner caught several issues that needed to be addressed. + + The authors gratefully acknowledge the assistance of Markus Isomaki + and Yana Stamcheva as the working group chairs and Gonzalo Camarillo + as the sponsoring Area Director. + + Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for + employing him during his work on earlier versions of this document. + +Authors' Addresses + + Peter Saint-Andre + &yet + + EMail: ietf@stpeter.im + + + Avshalom Houri + IBM + Rorberg Building, Pekris 3 + Rehovot 76123 + Israel + + EMail: avshalom@il.ibm.com + + + Joe Hildebrand + Cisco Systems, Inc. + 1899 Wynkoop Street, Suite 600 + Denver, CO 80202 + USA + + EMail: jhildebr@cisco.com + + + + + + +Saint-Andre, et al. Standards Track [Page 24] + -- cgit v1.2.3