doc: Add RFC documents

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]
+