summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7247.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7247.txt')
-rw-r--r--doc/rfc/rfc7247.txt1347
1 files changed, 1347 insertions, 0 deletions
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 <user@domain>; 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&#xFC;@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 "&#xFC;" 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 <message/> stanzas) or
+ 'pres:' (for XMPP <presence/> 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&#xFC;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 "&#xFC;" 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
+ <text/> child of the <error/> 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 |
+ +------------------------------+---------------------+
+ | <bad-request/> | 400 |
+ +------------------------------+---------------------+
+ | <conflict/> | 400 |
+ +------------------------------+---------------------+
+ | <feature-not-implemented/> | 405 or 501 (1) |
+ +------------------------------+---------------------+
+ | <forbidden/> | 403 or 603 (2) |
+ +------------------------------+---------------------+
+ | <gone/> | 301 or 410 (3) |
+ +------------------------------+---------------------+
+ | <internal-server-error/> | 500 |
+ +------------------------------+---------------------+
+ | <item-not-found/> | 404 or 604 (2) |
+ +------------------------------+---------------------+
+ | <jid-malformed/> | 400 |
+ +------------------------------+---------------------+
+ | <not-acceptable/> | 406 or 606 (2) |
+ +------------------------------+---------------------+
+ | <not-allowed/> | 403 |
+ +------------------------------+---------------------+
+ | <not-authorized/> | 401 |
+ +------------------------------+---------------------+
+ | <policy-violation/> | 403 |
+ +------------------------------+---------------------+
+ | <recipient-unavailable/> | 480 or 600 (2) |
+ +------------------------------+---------------------+
+ | <redirect/> | 302 |
+ +------------------------------+---------------------+
+ | <registration-required/> | 407 |
+ +------------------------------+---------------------+
+ | <remote-server-not-found/> | 404 or 408 (4) |
+ +------------------------------+---------------------+
+ | <remote-server-timeout/> | 408 |
+ +------------------------------+---------------------+
+
+
+
+
+
+Saint-Andre, et al. Standards Track [Page 15]
+
+RFC 7247 SIP-XMPP Interworking: Core May 2014
+
+
+ +------------------------------+---------------------+
+ | <resource-constraint/> | 500 |
+ +------------------------------+---------------------+
+ | <service-unavailable/> | see note (5) below |
+ +------------------------------+---------------------+
+ | <subscription-required/> | 400 |
+ +------------------------------+---------------------+
+ | <undefined-condition/> | 400 |
+ +------------------------------+---------------------+
+ | <unexpected-request/> | 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 <gone/> 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 <remote-server-not-found/> 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 <service-unavailable/> 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 <service-unavailable/> 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 <service-unavailable/> 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 <service-unavailable/> 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 <redirect/>, a 4xx-series code to <bad-request/>, a 5xx-
+ series code to <internal-server-error>, and a 6xx-series code to
+ <recipient-unavailable/>.
+
+ +---------------------+---------------------------------+
+ | SIP Response Code | XMPP Error Condition |
+ +---------------------+---------------------------------+
+ | 3xx | <redirect/> |
+ +---------------------+---------------------------------+
+ | 300 | <redirect/> |
+ +---------------------+---------------------------------+
+ | 301 | <gone/> (1) |
+ +---------------------+---------------------------------+
+ | 302 | <redirect/> |
+ +---------------------+---------------------------------+
+ | 305 | <redirect/> |
+ +---------------------+---------------------------------+
+ | 380 | <not-acceptable/> |
+ +---------------------+---------------------------------+
+ | 4xx | <bad-request/> |
+ +---------------------+---------------------------------+
+ | 400 | <bad-request/> |
+ +---------------------+---------------------------------+
+ | 401 | <not-authorized/> |
+ +---------------------+---------------------------------+
+ | 402 | <bad-request/> (2) |
+ +---------------------+---------------------------------+
+ | 403 | <forbidden/> (3) |
+ +---------------------+---------------------------------+
+ | 404 | <item-not-found/> (4) |
+ +---------------------+---------------------------------+
+ | 405 | <feature-not-implemented/> |
+ +---------------------+---------------------------------+
+ | 406 | <not-acceptable/> |
+ +---------------------+---------------------------------+
+ | 407 | <registration-required/> |
+ +---------------------+---------------------------------+
+
+
+
+
+Saint-Andre, et al. Standards Track [Page 17]
+
+RFC 7247 SIP-XMPP Interworking: Core May 2014
+
+
+ +---------------------+---------------------------------+
+ | 408 | <remote-server-timeout/> (5) |
+ +---------------------+---------------------------------+
+ | 410 | <gone/> (1) |
+ +---------------------+---------------------------------+
+ | 413 | <policy-violation/> |
+ +---------------------+---------------------------------+
+ | 414 | <policy-violation/> |
+ +---------------------+---------------------------------+
+ | 415 | <not-acceptable/> |
+ +---------------------+---------------------------------+
+ | 416 | <not-acceptable/> |
+ +---------------------+---------------------------------+
+ | 420 | <feature-not-implemented/> |
+ +---------------------+---------------------------------+
+ | 421 | <not-acceptable/> |
+ +---------------------+---------------------------------+
+ | 423 | <resource-constraint/> |
+ +---------------------+---------------------------------+
+ | 430 | <recipient-unavailable/> (6) |
+ +---------------------+---------------------------------+
+ | 439 | <feature-not-implemented/> (6) |
+ +---------------------+---------------------------------+
+ | 440 | <policy-violation/> (7) |
+ +---------------------+---------------------------------+
+ | 480 | <recipient-unavailable/> |
+ +---------------------+---------------------------------+
+ | 481 | <item-not-found/> |
+ +---------------------+---------------------------------+
+ | 482 | <not-acceptable/> |
+ +---------------------+---------------------------------+
+ | 483 | <not-acceptable/> |
+ +---------------------+---------------------------------+
+ | 484 | <item-not-found/> |
+ +---------------------+---------------------------------+
+ | 485 | <item-not-found/> |
+ +---------------------+---------------------------------+
+ | 486 | <recipient-unavailable/> |
+ +---------------------+---------------------------------+
+ | 487 | <recipient-unavailable/> |
+ +---------------------+---------------------------------+
+ | 488 | <not-acceptable/> |
+ +---------------------+---------------------------------+
+ | 489 | <policy-violation/> (8) |
+ +---------------------+---------------------------------+
+ | 491 | <unexpected-request/> |
+ +---------------------+---------------------------------+
+
+
+
+
+Saint-Andre, et al. Standards Track [Page 18]
+
+RFC 7247 SIP-XMPP Interworking: Core May 2014
+
+
+ +---------------------+---------------------------------+
+ | 493 | <bad-request/> |
+ +---------------------+---------------------------------+
+ | 5xx | <internal-server-error/> |
+ +---------------------+---------------------------------+
+ | 500 | <internal-server-error/> |
+ +---------------------+---------------------------------+
+ | 501 | <feature-not-implemented/> |
+ +---------------------+---------------------------------+
+ | 502 | <remote-server-not-found/> |
+ +---------------------+---------------------------------+
+ | 503 | <internal-server-error/> (9) |
+ +---------------------+---------------------------------+
+ | 504 | <remote-server-timeout/> |
+ +---------------------+---------------------------------+
+ | 505 | <not-acceptable/> |
+ +---------------------+---------------------------------+
+ | 513 | <policy-violation/> |
+ +---------------------+---------------------------------+
+ | 6xx | <recipient-unavailable/> |
+ +---------------------+---------------------------------+
+ | 600 | <recipient-unavailable/> |
+ +---------------------+---------------------------------+
+ | 603 | <recipient-unavailable/> |
+ +---------------------+---------------------------------+
+ | 604 | <item-not-found/> |
+ +---------------------+---------------------------------+
+ | 606 | <not-acceptable/> |
+ +---------------------+---------------------------------+
+
+ Table 3: Mapping of SIP Response Codes to XMPP Error Conditions
+
+ (1) When mapping SIP 301 to XMPP <gone/>, the <gone/> element MUST
+ include XML character data specifying the new address. When
+ mapping SIP 410 to XMPP <gone/>, the <gone/> element MUST NOT
+ include XML character data specifying a new address.
+
+ (2) The XMPP <payment-required/> error condition was removed in
+ [RFC6120]. Therefore, a mapping to XMPP <bad-request/> is
+ suggested instead.
+
+ (3) Depending on the scenario, other possible translations for
+ SIP 403 are <not-allowed/> and <policy-violation/>.
+
+ (4) Depending on the scenario, another possible translation for
+ SIP 404 is <remote-server-not-found/>.
+
+
+
+
+
+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 <remote-server-not-found/>.
+
+ (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
+ <service-unavailable/> 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,
+ <http://www.unicode.org/versions/Unicode6.3.0/>.
+
+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,
+ <http://unicode.org/reports/tr39/>.
+
+ [XEP-0106] Hildebrand, J. and P. Saint-Andre, "JID Escaping",
+ XSF XEP 0106, June 2007,
+ <http://www.xmpp.org/extensions/xep-0106.html>.
+
+ [XEP-0131] Saint-Andre, P. and J. Hildebrand, "Stanza Headers and
+ Internet Metadata", XSF XEP 0131, July 2006,
+ <http://xmpp.org/extensions/xep-0131.html>.
+
+ [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]
+