source: draft-ietf-stox-core.xml

Last change on this file was 76, checked in by stpeter@…, 9 years ago

address and Unicode reference

  • Property svn:mime-type set to text/plain
File size: 75.5 KB
1<?xml version="1.0"?>
2<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
3<?rfc compact="yes"?>
4<?rfc sortrefs="no"?>
5<?rfc strict="yes"?>
6<?rfc symrefs="yes"?>
7<?rfc toc="yes"?>
8<?rfc tocdepth="3"?>
9<rfc category='std' docName='draft-ietf-stox-core-11' ipr='trust200902'>
11  <front>
12    <title abbrev="SIP-XMPP Interworking: Core">Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling</title>
13    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
14      <organization>&amp;yet</organization>
15      <address>
16        <postal>
17          <street>P.O. Box 787</street>
18          <city>Parker</city>
19          <region>CO</region>
20          <code>80134</code>
21          <country>USA</country>
22        </postal>
23        <email></email>
24      </address>
25    </author>
26    <author initials="A." surname="Houri" fullname="Avshalom Houri">
27      <organization>IBM</organization>
28      <address>
29        <postal>
30          <street>Rorberg Building, Pekris 3</street>
31          <city>Rehovot</city>
32          <code>76123</code>
33          <country>Israel</country>
34        </postal>
35        <email></email>
36      </address>
37    </author>
38    <author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
39      <organization>Cisco Systems, Inc.</organization>
40      <address>
41        <postal>
42          <street>1899 Wynkoop Street, Suite 600</street>
43          <city>Denver</city>
44          <region>CO</region>
45          <code>80202</code>
46          <country>USA</country>
47        </postal>
48        <email></email>
49      </address>
50    </author>
51    <date/>
52    <area>RAI</area>
53    <keyword>XMPP</keyword>
54    <keyword>SIP</keyword>
55    <abstract>
56      <t>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.</t>
57    </abstract>
58  </front>
60  <middle>
62    <section title="Introduction" anchor="intro">
63      <t>The IETF has worked on two signalling technologies that can be used for multimedia session negotiation, messaging, presence, capabilities discovery, notifications, and other application-level functionality:</t>
64      <t>
65        <list style='symbols'>
66          <t>The Session Initiation Protocol <xref target="RFC3261"/>, along with various SIP extensions developed within the SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Working Group.</t>
67          <t>The Extensible Messaging and Presence Protocol <xref target='RFC6120'/>, along with various XMPP extensions developed by the IETF as well as by the XMPP Standards Foundation (XSF).</t>
68        </list>
69      </t>
70      <t>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.</t>
71      <t>The guidelines in this series are based on implementation and deployment experience, and 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, <xref target='RFC3859'/> and <xref target='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.</t>
72    </section>
74    <section title="Intended Audience" anchor="audience">
75      <t>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, and with regard to the other documents in this series we assume that readers are familiar with the relevant SIP and XMPP extensions.</t>
76    </section>
78    <section title="Terminology" anchor="terms">
79      <t>A number of terms used here are explained in <xref target='RFC3261'/> and <xref target='RFC6120'/>.</t>
80      <t>Several examples use the "XML Notation" from the IRI specification <xref target='RFC3987'/> to represent Unicode characters outside the ASCII range (e.g., the string "&#xFC;" stands for the Unicode character LATIN SMALL LETTER U WITH DIAERESIS, U+00FC).</t>
81      <t>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 <xref target='RFC2119'/>.</t>
82    </section>
84    <section title="Architectural Assumptions" anchor="intro-arch">
85      <t>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 multi-protocol 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 multi-protocol 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).</t>
86      <t>This document assumes that the protocol translation will occur within a gateway, specifically:</t>
87      <t>
88        <list style='symbols'>
89          <t>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").</t>
90          <t>When information needs to flow from a SIP-based system to an XMP-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").</t>
91        </list>
92      </t>
93      <t>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).</t>
94      <t><list style='empty'><t>Note: This assumption is not meant to discourage protocol translation within multi-protocol 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.</t></list></t>
95      <t>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.</t>
96      <t>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:</t>
97      <t>
98        <list style='symbols'>
99          <t> -- a SIP user.</t>
100          <t> -- a SIP server with an associated gateway ("S2X GW") to XMPP.</t>
101          <t> -- an XMPP user.</t>
102          <t> -- an XMPP server with an associated gateway ("X2S GW") to SIP.</t>
103        </list>
104      </t>
105      <figure anchor='figure-1' title='Possible Gateway Deployment Architecture'>
106        <artwork><![CDATA[
107   #########################################################
108   #                                                       #
109   #                 +-----+                               #
110   #                 | S2X |                               #
111   #   +-------------+ GW  |<...........>+-------------+   #
112   #   | SIP Server  +-----+             | XMPP Server |   #
113   #   | |             +-----+ |   #
114   #   +-------------+<***********>| X2S +-------------+   #
115   #         *                     | GW  |  :              #
116   #         *                     +-----+  :              #
117   #         *                              :              #
118   #      #
119   #                                                       #
120   #########################################################
122         Legend:
123           XMPP = ... or :
124            SIP = *
125        ]]></artwork>
126      </figure>
127      <t>Note that bidirectional communication between the SIP server and the XMPP server can be established either over SIP or over XMPP.  If the XMPP user initiates the interaction, then the XMPP server would invoke its XMPP-to-SIP gateway and 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 on thus the communication would occur over XMPP.</t>
128    </section>
130    <section title="Interdomain Federation" anchor="fed">
131      <t>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.</t>
132      <t>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 <xref target="RFC2782"/> for "_xmpp-server" records as specified in <xref target="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 <xref target='RFC3263'/>.</t>
133      <t>Similarly, when a SIP server receives a SIP message whose Request-URI 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 <xref target='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 <xref target="RFC2782"/> for "_xmpp-server" records as specified in <xref target="RFC6120"/>.</t>
134      <t>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.</t>
135      <t>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).</t>
136      <t>Because <xref target='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 <xref target='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.</t>
137    </section>
139    <section title="Address Mapping" anchor="addr">
140      <section title="Overview" anchor="addr-over">
141        <t>The basic SIP address format is a 'sip' or 'sips' URI as specified in <xref target='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 <xref target="RFC3860"/> (see <xref target="RFC3428"/>) and when a SIP entity supports extensions for presence it might be identified by a 'pres' URI as specified in the Common Profile for Presence <xref target="RFC3859"/> (see <xref target="RFC3856"/>).  SIP entities typically also support the 'tel' URI scheme <xref target='RFC3966'/> and might support other URI schemes as well.</t>
142        <t>The XMPP address format is specified in <xref target="RFC6122"/> (although note that XMPP URIs <xref target='RFC5122'/> are not used natively on the XMPP network); in addition, <xref target="RFC6121"/> encourages instant messaging and presence applications of XMPP to also support 'im' and 'pres' URIs as specified in <xref target="RFC3860"/> and <xref target="RFC3859"/> respectively, although such support might simply involve leaving resolution of such addresses up to an XMPP server.</t>
143        <t>In this document we primarily describe mappings for addresses of the form &lt;user@domain&gt;; 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 <xref target="RFC6122"/> and <xref target='I-D.ietf-xmpp-6122bis'/>).  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.</t>
144        <t>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.</t>
145      </section>
146      <section title="Local Part Mapping" anchor="addr-localpart">
147        <t>The local part of a sip:/sips: URI inherits from the "userinfo" rule in <xref target="RFC3986"/> with several changes; here we discuss the SIP "user" rule only:</t>
148        <figure>
149          <artwork><![CDATA[
150   user             =  1*( unreserved / escaped / user-unreserved )
151   user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
152   unreserved       =  alphanum / mark
153   mark             =  "-" / "_" / "." / "!" / "~" / "*" / "'"
154                       / "(" / ")"
155          ]]></artwork>
156        </figure>
157        <t>Here we make the simplifying assumption that the local part of an im:/pres: URI inherits from the "dot-atom-text" rule in <xref target="RFC5322"/> rather than the more complicated "local-part" rule:</t>
158        <figure>
159          <artwork><![CDATA[
160   dot-atom-text =  1*atext *("." 1*atext)
161   atext         =  ALPHA / DIGIT /    ; Any character except
162                    "!" / "#" / "$" /  ; controls, SP, and
163                    "%" / "&" / "'" /  ; specials. Used for
164                    "*" / "+" / "-" /  ; atoms.
165                    "/" / "=" / "?" /
166                    "^" / "_" / "`" /
167                    "{" / "|" / "}" /
168                    "~"
169          ]]></artwork>
170        </figure>
171        <t>The local part of an XMPP address allows any ASCII character except space, controls, and the " &amp; ' / : &lt; &gt; @ characters.</t>
172        <t>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).</t>
173        <figure>
174          <preamble>Table 1: Allowed and disallowed characters</preamble>
175          <artwork><![CDATA[
177| SIP/SIPS CHARACTERS                  |
179| A | !  $ &'()*+,-./ ; = ?     _    ~ |
180| D |  "# %          : < > @[\]^ `{|}  |
182| IM/PRES CHARACTERS                   |
184| A | ! #$%&'  *+ - /   = ?    ^_`{|}~ |
185| D |  "     ()  , . :;< > @[\]        |
187| XMPP CHARACTERS                      |
189| A | ! #$%  ()*+,-.  ; = ? [\]^_`{|}~ |
190| D |  "   &'       /: < > @           |
192          ]]></artwork>
193        </figure>
194        <t>When transforming the local part of an address from one scheme to another, an application SHOULD proceed as follows:</t>
195        <t>
196          <list style='numbers'>
197            <t>Unescape any escaped characters in the source address (e.g., from SIP to XMPP unescape "%23" to "#" per <xref target='RFC3986'/> and from XMPP to SIP unescape "\27" to "'" per <xref target='XEP-0106'/>).</t>
198            <t>Leave unmodified any characters that are allowed in the destination scheme.</t>
199            <t>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:
200              <list style='symbols'>
201                <t>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 <xref target='RFC3986'/> (e.g., when transforming from XMPP to SIP, encode "#" as "%23").</t>
202                <t>Where the destination scheme is a native XMPP address, each reserved character MUST be encoded to "\hexhex" as specified in <xref target='XEP-0106'/> (e.g., when transforming from SIP to XMPP, encode "'" as "\27").</t>
203              </list>
204            </t>
205          </list>
206        </t>
207      </section>
208      <section title="Instance-Specific Mapping" anchor="addr-instance">
209        <t>The meaning of a resourcepart in XMPP (i.e., the portion of a JID after the slash character, such as "foo" in "") matches that of a Globally Routable User Agent URI (GRUU) in SIP <xref target='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.</t>
210        <t>The mapping described here does not apply to temporary GRUUs, only to GRUUs associated with an Address of Record.</t>
211        <t>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 <xref target='RFC3986'/>), whereas an XMPP resourcepart can contain nearly any Unicode character <xref target='UNICODE'/>.  Therefore Unicode characters outside the ASCII range need to be mapped to characters in the ASCII range, as described below.</t>
212      </section>
213      <section title="SIP to XMPP" anchor="addr-sip">
214        <t>The following is a high-level algorithm for mapping a sip:, sips:, im:, or pres: URI to an XMPP address:</t>
215        <t>
216          <list style='numbers'>
217            <t>Remove URI scheme.</t>
218            <t>Split at the first '@' character into local part and hostname (mapping the latter is out of scope).</t>
219            <t>Translate any percent-encoded strings ("%hexhex") to percent-decoded octets.</t>
220            <t>Treat result as a UTF-8 string.</t>
221            <t>Translate "&amp;" 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 <xref target="XEP-0106"/>).</t>
222            <t>Apply Nodeprep profile of Stringprep <xref target="RFC3454"/> or its replacement (see <xref target="RFC6122"/> and <xref target='I-D.ietf-xmpp-6122bis'/>) for canonicalization (OPTIONAL).</t>
223            <t>Recombine local part with mapped hostname to form a bare JID ("localpart@domainpart").</t>
224            <t>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").</t>
225          </list>
226        </t>
227        <t>Several examples follow, illustrating steps 3, 5, and 8 described above.</t>
228        <figure>
229          <artwork><![CDATA[
230   +----------------------------+--------------------------+
231   | SIP URI                    |  XMPP Address            |
232   +----------------------------+--------------------------+
233   | sip:f%C3%BC@sip.example    |  f&#xFC;@sip.example     |
234   +----------------------------+--------------------------+
235   | sip:o'malley@sip.example   |  o\27malley@sip.example  |
236   +----------------------------+--------------------------+
237   | sip:foo@sip.example;gr=bar |  foo@sip.example/bar     |
238   +----------------------------+--------------------------+
239          ]]></artwork>
240        </figure>
241        <t>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 "&amp;#xFC;" is the same character shown for documentation purposes using the XML Notation defined in <xref target='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 <xref target='RFC3986'/>).</t>
242      </section>
243      <section title="XMPP to SIP" anchor="addr-xmpp">
244        <t>The following is a high-level algorithm for mapping an XMPP address to a sip:, sips:, im:, or pres: URI:</t>
245        <t>
246          <list style='numbers'>
247            <t>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).</t>
248            <t>Apply Nodeprep profile of <xref target="RFC3454"/> or its replacement (see <xref target="RFC6122"/> and <xref target='I-D.ietf-xmpp-6122bis'/>) for canonicalization of the XMPP localpart (OPTIONAL).</t>
249            <t>Translate "\26" to "&amp;", "\27" to "'", and "\2f" to "/" respectively (this is consistent with <xref target="XEP-0106"/>).</t>
250            <t>Determine if the foreign domain supports im: and pres: URIs (discovered via <xref target="RFC2782"/> lookup as specified in <xref target="RFC6121"/>), else assume that the foreign domain supports sip:/sips: URIs.</t>
251            <t>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.</t>
252            <t>Combine resulting local part with mapped hostname to form local@domain address.</t>
253            <t>Prepend with 'im:' scheme (for XMPP &lt;message/&gt; stanzas) or 'pres:' scheme (for XMPP &lt;presence/&gt; stanzas) if foreign domain supports these, else prepend with 'sip:' or 'sips:' scheme according to local service policy.</t>
254            <t>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.</t>
255          </list>
256        </t>
257        <t>Several examples follow, illustrating steps 3, 5, and 8 described above.</t>
258        <figure>
259          <artwork><![CDATA[
260   +---------------------------+---------------------------------+
261   | XMPP Address              |  SIP URI                        |
262   +---------------------------+---------------------------------+
263   | m\26m@xmpp.example        |  sip:m&m@xmpp.example           |
264   +---------------------------+---------------------------------+
265   | tsch&#xFC;ss@xmpp.example |  sip:tsch%C3%BCss@xmpp.example  |
266   +---------------------------+---------------------------------+
267   | baz@xmpp.example/qux      |  sip:baz@xmpp.example;gr=qux    |
268   +---------------------------+---------------------------------+
269          ]]></artwork>
270        </figure>
271        <t>As above, in the first example the string "&amp;#xFC;" is the Unicode character LATIN SMALL LETTER U WITH DIAERESIS (U+00FC) shown for documentation purposes using the XML Notation defined in <xref target='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 of the same character.</t>
272      </section>
273    </section>
275    <section title='Error Mapping' anchor="errors">
277      <t>Various differences between XMPP error conditions and SIP response codes make it hard to provide a comprehensive and consistent mapping between the protocols:</t>
278      <t>
279        <list style='symbols'>
280          <t>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.</t>
281          <t>XMPP has defined fewer error conditions related to stanza handling (22 are defined in <xref target='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 <xref target='RFC3261'/> and numerous SIP extensions).</t>
282          <t>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 just two forms of a bad request, and the SIP codes "415 Unsupported Media Type" and "416 Unsupported URI Scheme" are just two forms of a request that is not acceptable).</t>
283          <t>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.</t>
284        </list>
285      </t>
286      <t>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.</t>
287      <t>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 &lt;text/&gt; child of the &lt;error/&gt; element.  Although the semantics of 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.</t>
289      <section title="XMPP to SIP" anchor="errors-xmpp">
290        <t>The mapping of specific XMPP error conditions to SIP response codes SHOULD be as described in the following table.</t>
291        <figure>
292          <preamble>Table 2: Mapping of XMPP error conditions to SIP response codes</preamble>
293          <artwork><![CDATA[
294   +------------------------------+---------------------+
295   |  XMPP Error Condition        |  SIP Response Code  |
296   +------------------------------+---------------------+
297   |  <bad-request/>              | 400                 |
298   +------------------------------+---------------------+
299   |  <conflict/>                 | 400                 |
300   +------------------------------+---------------------+
301   |  <feature-not-implemented/>  | 405 or 501 (1)      |
302   +------------------------------+---------------------+
303   |  <forbidden/>                | 403 or 603 (2)      |
304   +------------------------------+---------------------+
305   |  <gone/>                     | 301 or 410 (3)      |
306   +------------------------------+---------------------+
307   |  <internal-server-error/>    | 500                 |
308   +------------------------------+---------------------+
309   |  <item-not-found/>           | 404 or 604 (2)      |
310   +------------------------------+---------------------+
311   |  <jid-malformed/>            | 400                 |
312   +------------------------------+---------------------+
313   |  <not-acceptable/>           | 406 or 606 (2)      |
314   +------------------------------+---------------------+
315   |  <not-allowed/>              | 403                 |
316   +------------------------------+---------------------+
317   |  <not-authorized/>           | 401                 |
318   +------------------------------+---------------------+
319   |  <policy-violation/>         | 403                 |
320   +------------------------------+---------------------+
321   |  <recipient-unavailable/>    | 480 or 600 (2)      |
322   +------------------------------+---------------------+
323   |  <redirect/>                 | 302                 |
324   +------------------------------+---------------------+
325   |  <registration-required/>    | 407                 |
326   +------------------------------+---------------------+
327   |  <remote-server-not-found/>  | 404 or 408 (4)      |
328   +------------------------------+---------------------+
329   |  <remote-server-timeout/>    | 408                 |
330   +------------------------------+---------------------+
331   |  <resource-constraint/>      | 500                 |
332   +------------------------------+---------------------+
333   |  <service-unavailable/>      | see note (5) below  |
334   +------------------------------+---------------------+
335   |  <subscription-required/>    | 400                 |
336   +------------------------------+---------------------+
337   |  <undefined-condition/>      | 400                 |
338   +------------------------------+---------------------+
339   |  <unexpected-request/>       | 491 or 400          |
340   +------------------------------+---------------------+
341          ]]></artwork>
342        </figure>
343        <t>
344          <list style='numbers'>
345            <t>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.</t>
346            <t>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.</t>
347            <t>If the &lt;gone/&gt; 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.</t>
348            <t>The XMPP &lt;remote-server-not-found/&gt; error can mean either that the remote server (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).</t>
349            <t>The XMPP &lt;service-unavailable/&gt; 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 &lt;service-unavailable/&gt; 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 &lt;service-unavailable/&gt; error condition to the SIP 503 Service Unavailable response code is 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 &lt;service-unavailable/&gt; error condition.</t>
350          </list>
351        </t>
352      </section>
353      <section title="SIP to XMPP" anchor="errors-sip">
354        <t>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 &lt;redirect/&gt;, a 4xx-series code to &lt;bad-request/&gt;, a 5xx-series code to &lt;internal-server-error&gt;, and a 6xx-series code to &lt;recipient-unavailable/&gt;.</t>
355        <figure>
356          <preamble>Table 3: Mapping of SIP response codes to XMPP error conditions</preamble>
357          <artwork><![CDATA[
358   +---------------------+---------------------------------+
359   |  SIP Response Code  |  XMPP Error Condition           |
360   +---------------------+---------------------------------+
361   |  3xx                |  <redirect/>                    |
362   +---------------------+---------------------------------+
363   |  300                |  <redirect/>                    |
364   +---------------------+---------------------------------+
365   |  301                |  <gone/> (1)                    |
366   +---------------------+---------------------------------+
367   |  302                |  <redirect/>                    |
368   +---------------------+---------------------------------+
369   |  305                |  <redirect/>                    |
370   +---------------------+---------------------------------+
371   |  380                |  <not-acceptable/>              |
372   +---------------------+---------------------------------+
373   |  4xx                |  <bad-request/>                 |
374   +---------------------+---------------------------------+
375   |  400                |  <bad-request/>                 |
376   +---------------------+---------------------------------+
377   |  401                |  <not-authorized/>              |
378   +---------------------+---------------------------------+
379   |  402                |  <bad-request/> (2)             |
380   +---------------------+---------------------------------+
381   |  403                |  <forbidden/> (3)               |
382   +---------------------+---------------------------------+
383   |  404                |  <item-not-found/> (4)          |
384   +---------------------+---------------------------------+
385   |  405                |  <feature-not-implemented/>     |
386   +---------------------+---------------------------------+
387   |  406                |  <not-acceptable/>              |
388   +---------------------+---------------------------------+
389   |  407                |  <registration-required/>       |
390   +---------------------+---------------------------------+
391   |  408                |  <remote-server-timeout/> (5)   |
392   +---------------------+---------------------------------+
393   |  410                |  <gone/> (1)                    |
394   +---------------------+---------------------------------+
395   |  413                |  <policy-violation/>            |
396   +---------------------+---------------------------------+
397   |  414                |  <policy-violation/>            |
398   +---------------------+---------------------------------+
399   |  415                |  <not-acceptable/>              |
400   +---------------------+---------------------------------+
401   |  416                |  <not-acceptable/>              |
402   +---------------------+---------------------------------+
403   |  420                |  <feature-not-implemented/>     |
404   +---------------------+---------------------------------+
405   |  421                |  <not-acceptable/>              |
406   +---------------------+---------------------------------+
407   |  423                |  <resource-constraint/>         |
408   +---------------------+---------------------------------+
409   |  430                |  <recipient-unavailable/> (6)   |
410   +---------------------+---------------------------------+
411   |  439                |  <feature-not-implemented/> (6) |
412   +---------------------+---------------------------------+
413   |  440                |  <policy-violation/> (7)        |
414   +---------------------+---------------------------------+
415   |  480                |  <recipient-unavailable/>       |
416   +---------------------+---------------------------------+
417   |  481                |  <item-not-found/>              |
418   +---------------------+---------------------------------+
419   |  482                |  <not-acceptable/>              |
420   +---------------------+---------------------------------+
421   |  483                |  <not-acceptable/>              |
422   +---------------------+---------------------------------+
423   |  484                |  <item-not-found/>              |
424   +---------------------+---------------------------------+
425   |  485                |  <item-not-found/>              |
426   +---------------------+---------------------------------+
427   |  486                |  <recipient-unavailable/>       |
428   +---------------------+---------------------------------+
429   |  487                |  <recipient-unavailable/>       |
430   +---------------------+---------------------------------+
431   |  488                |  <not-acceptable/>              |
432   +---------------------+---------------------------------+
433   |  489                |  <policy-violation/> (8)        |
434   +---------------------+---------------------------------+
435   |  491                |  <unexpected-request/>          |
436   +---------------------+---------------------------------+
437   |  493                |  <bad-request/>                 |
438   +---------------------+---------------------------------+
439   |  5xx                |  <internal-server-error/>       |
440   +---------------------+---------------------------------+
441   |  500                |  <internal-server-error/>       |
442   +---------------------+---------------------------------+
443   |  501                |  <feature-not-implemented/>     |
444   +---------------------+---------------------------------+
445   |  502                |  <remote-server-not-found/>     |
446   +---------------------+---------------------------------+
447   |  503                |  <internal-server-error/> (9)   |
448   +---------------------+---------------------------------+
449   |  504                |  <remote-server-timeout/>       |
450   +---------------------+---------------------------------+
451   |  505                |  <not-acceptable/>              |
452   +---------------------+---------------------------------+
453   |  513                |  <policy-violation/>            |
454   +---------------------+---------------------------------+
455   |  6xx                |  <recipient-unavailable/>       |
456   +---------------------+---------------------------------+
457   |  600                |  <recipient-unavailable/>       |
458   +---------------------+---------------------------------+
459   |  603                |  <recipient-unavailable/>       |
460   +---------------------+---------------------------------+
461   |  604                |  <item-not-found/>              |
462   +---------------------+---------------------------------+
463   |  606                |  <not-acceptable/>              |
464   +---------------------+---------------------------------+
465          ]]></artwork>
466        </figure>
467        <t>
468          <list style='numbers'>
469            <t>When mapping SIP 310 to XMPP &lt;gone/&gt;, the &lt;gone/&gt; element MUST include XML character data specifying the new address.  When mapping SIP 410 to XMPP &lt;gone/&gt;, the &lt;gone/&gt; element MUST NOT include XML character data specifying a new address.</t>
470            <t>The XMPP &lt;payment-required/&gt; error condition was removed in <xref target='RFC6120'/>.  Therefore, a mapping to XMPP &lt;bad-request/&gt;.</t>
471            <t>Depending on the scenario, other possible translations for SIP 403 are &lt;not-allowed/&gt; and &lt;policy-violation/&gt;.</t>
472            <t>Depending on the scenario, another possible translation for SIP 404 is &lt;remote-sever-not-found/&gt;.</t>
473            <t>Depending on the scenario, another possible translation for SIP 408 is &lt;remote-server-not-found/&gt;.</t>
474            <t>Codes 430 and 439 are defined in <xref target='RFC5626'/>.</t>
475            <t>Code 440 is defined in <xref target='RFC5393'/>.</t>
476            <t>Code 489 is defined in <xref target='RFC6665'/>.</t>
477            <t>Regarding the semantic mismatch between XMPP &lt;service-unavailable/&gt; and SIP code 503, see note under Section 6.1 of this document.</t>
478          </list>
479        </t>
480      </section>
481    </section>
483    <section title="IANA Considerations" anchor="iana">
484      <t>This document makes no requests of IANA.</t>
485    </section>
487    <section title='Security Considerations' anchor="sec">
488      <t>Detailed security considerations for SIP are given in <xref target="RFC3261"/> and for XMPP in <xref target="RFC6120"/>.</t>
489      <t>To protect information sent between SIP and XMPP systems, deployed gateways SHOULD use Transport Layer Security (TLS) <xref target='RFC5246'/> when communicating over TCP and Datagram Transport Layer Security (DTLS) <xref target='RFC6347'/> when communicating over UDP.</t>
490      <t>As specified in Section 26.4.4 of <xref target='RFC3261'/> and updated by <xref target='RFC5630'/>, a To header or a Request-URI containing a 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).</t>
491      <t>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 <xref target='RFC5393'/> can manifest itself with B2BUAs (see also <xref target='I-D.ietf-straw-b2bua-loop-detection'/>), 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 <xref target='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 is out of scope for this document.  However, it ought to be addressed in the future, and implementations are strongly encouraged to incorporate appropriate counter measures wherever possible.</t>
492      <t>The ability to use a wide range of Unicode characters <xref target='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 <xref target='I-D.ietf-precis-framework'/> describes some of these security issues, and additional guidance can be found in <xref target='UTS39'/>.</t>
493    </section>
495  </middle>
497  <back>
499    <references title="Normative References">
501<reference anchor='RFC2119'>
502  <front>
503    <title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
504    <author initials='S.' surname='Bradner' fullname='Scott Bradner'>
505      <organization>Harvard University</organization>
506      <address>
507        <postal>
508          <street>1350 Mass. Ave.</street>
509          <street>Cambridge</street>
510          <street>MA 02138</street>
511        </postal>
512        <phone>- +1 617 495 3864</phone>
513        <email>-</email>
514      </address>
515    </author>
516    <date month='March' year='1997'></date>
517    <area>General</area>
518    <keyword>keyword</keyword>
519    <abstract>
520      <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
521        <list>
522          <t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;,  &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be interpreted as described in RFC 2119.</t>
523        </list>
524      </t>
525      <t>Note that the force of these words is modified by the requirement level of the document in which they are used.</t>
526    </abstract>
527  </front>
528  <seriesInfo name='BCP' value='14' />
529  <seriesInfo name='RFC' value='2119' />
532<reference anchor='RFC3261'>
534<title>SIP: Session Initiation Protocol</title>
535<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
536<organization /></author>
537<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
538<organization /></author>
539<author initials='G.' surname='Camarillo' fullname='G. Camarillo'>
540<organization /></author>
541<author initials='A.' surname='Johnston' fullname='A. Johnston'>
542<organization /></author>
543<author initials='J.' surname='Peterson' fullname='J. Peterson'>
544<organization /></author>
545<author initials='R.' surname='Sparks' fullname='R. Sparks'>
546<organization /></author>
547<author initials='M.' surname='Handley' fullname='M. Handley'>
548<organization /></author>
549<author initials='E.' surname='Schooler' fullname='E. Schooler'>
550<organization /></author>
551<date month='June' year='2002' /></front>
552<seriesInfo name='RFC' value='3261' />
553<format type='TXT' octets='647976' target='' />
556<reference anchor='RFC3263'>
558<title>Session Initiation Protocol (SIP): Locating SIP Servers</title>
559<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
560<organization /></author>
561<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
562<organization /></author>
563<date year='2002' month='June' />
565<t>The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact.  It also uses DNS to allow a server to send a response to a backup client if the primary client has failed.  This document describes those DNS procedures in detail. [STANDARDS-TRACK]</t></abstract></front>
566<seriesInfo name='RFC' value='3263' />
567<format type='TXT' octets='42310' target='' />
570<reference anchor='RFC3986'>
572<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
573<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
574<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
577<street>Massachusetts Institute of Technology</street>
578<street>77 Massachusetts Avenue</street>
587<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
588<organization abbrev='Day Software'>Day Software</organization>
591<street>5251 California Ave., Suite 110</street>
600<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
601<organization abbrev='Adobe Systems'>Adobe Systems Incorporated</organization>
604<street>345 Park Ave</street>
605<city>San Jose</city>
612<date year='2005' month='January' />
614<keyword>uniform resource identifier</keyword>
622A Uniform Resource Identifier (URI) is a compact sequence of characters
623that identifies an abstract or physical resource.  This specification
624defines the generic URI syntax and a process for resolving URI references
625that might be in relative form, along with guidelines and security
626considerations for the use of URIs on the Internet.
627The URI syntax defines a grammar that is a superset of all valid URIs,
628allowing an implementation to parse the common components of a URI
629reference without knowing the scheme-specific requirements of every
630possible identifier.  This specification does not define a generative
631grammar for URIs; that task is performed by the individual
632specifications of each URI scheme.
634<seriesInfo name='STD' value='66' />
635<seriesInfo name='RFC' value='3986' />
636<format type='TXT' octets='141811' target='' />
637<format type='HTML' octets='200858' target='' />
638<format type='XML' octets='165759' target='' />
641<reference anchor='RFC3987'>
643<title>Internationalized Resource Identifiers (IRIs)</title>
644<author initials='M.' surname='Duerst' fullname='M. Duerst'>
645<organization /></author>
646<author initials='M.' surname='Suignard' fullname='M. Suignard'>
647<organization /></author>
648<date year='2005' month='January' />
650<t>This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources.&lt;/t>&lt;t> The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.</t></abstract></front>
651<seriesInfo name='RFC' value='3987' />
652<format type='TXT' octets='111190' target='' />
655<reference anchor='RFC5246'>
657<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
658<author initials='T.' surname='Dierks' fullname='T. Dierks'>
659<organization /></author>
660<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
661<organization /></author>
662<date year='2008' month='August' />
664<t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t></abstract></front>
665<seriesInfo name='RFC' value='5246' />
666<format type='TXT' octets='222395' target='' />
669<reference anchor='RFC5393'>
671<title>Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies</title>
672<author initials='R.' surname='Sparks' fullname='R. Sparks'>
673<organization /></author>
674<author initials='S.' surname='Lawrence' fullname='S. Lawrence'>
675<organization /></author>
676<author initials='A.' surname='Hawrylyshen' fullname='A. Hawrylyshen'>
677<organization /></author>
678<author initials='B.' surname='Campen' fullname='B. Campen'>
679<organization /></author>
680<date year='2008' month='December' />
682<t>This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic.&lt;/t>&lt;t> This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request. [STANDARDS-TRACK]</t></abstract></front>
683<seriesInfo name='RFC' value='5393' />
684<format type='TXT' octets='48722' target='' />
687<reference anchor='RFC5627'>
689<title>Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)</title>
690<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
691<organization /></author>
692<date year='2009' month='October' />
694<t>Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance.  A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU).  This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog. [STANDARDS-TRACK]</t></abstract></front>
695<seriesInfo name='RFC' value='5627' />
696<format type='TXT' octets='94790' target='' />
699<reference anchor='RFC5630'>
701<title>The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)</title>
702<author initials='F.' surname='Audet' fullname='F. Audet'>
703<organization /></author>
704<date year='2009' month='October' />
706<t>This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP).  It also makes normative changes to SIP. [STANDARDS-TRACK]</t></abstract></front>
707<seriesInfo name='RFC' value='5630' />
708<format type='TXT' octets='114513' target='' />
711<reference anchor='RFC6120'>
713<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
714<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
715<organization /></author>
716<date year='2011' month='March' />
718<t>The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities.  This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions.  This document obsoletes RFC 3920. [STANDARDS-TRACK]</t></abstract></front>
719<seriesInfo name='RFC' value='6120' />
720<format type='TXT' octets='451942' target='' />
723<reference anchor='RFC6122'>
725<title>Extensible Messaging and Presence Protocol (XMPP): Address Format</title>
726<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
727<organization /></author>
728<date year='2011' month='March' />
730<t>This document defines the format for addresses used in the Extensible Messaging and Presence Protocol (XMPP), including support for non-ASCII characters.  This document updates RFC 3920. [STANDARDS-TRACK]</t></abstract></front>
731<seriesInfo name='RFC' value='6122' />
732<format type='TXT' octets='50646' target='' />
735<reference anchor='RFC6347'>
737<title>Datagram Transport Layer Security Version 1.2</title>
738<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
739<organization /></author>
740<author initials='N.' surname='Modadugu' fullname='N. Modadugu'>
741<organization /></author>
742<date year='2012' month='January' />
744<t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t></abstract></front>
745<seriesInfo name='RFC' value='6347' />
746<format type='TXT' octets='73546' target='' />
749<reference anchor="UNICODE" target="">
750  <front>
751    <title>The Unicode Standard, Version 6.3</title>
752    <author>
753      <organization>The Unicode Consortium</organization>
754    </author>
755    <date year="2013" />
756  </front>
759    </references>
761    <references title="Informative References">
763<reference anchor='I-D.ietf-precis-framework'>
765<title>Precis Framework: Handling Internationalized Strings in Protocols</title>
766<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
767    <organization>Cisco</organization>
769<author initials='M' surname='Blanchet' fullname='Marc Blanchet'>
770    <organization>Viagenie</organization>
772<date month='February' day='9' year='2014' />
773<abstract><t>Application protocols using Unicode code points in protocol strings need to prepare such strings in order to perform comparison operations (e.g., for purposes of authentication or authorization).  This document defines a framework enabling application protocols to handle various classes of strings in a way that depends on the properties of Unicode code points and that is agile with respect to versions of Unicode; as a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454).  A specification that reuses this framework can either directly use the base string classes or subclass the base string classes as needed.  This framework takes an approach similar to the revised internationalized domain names in applications (IDNA) technology (RFC 5890, RFC 5891, RFC 5892, RFC 5893, RFC 5894) and thus adheres to the high-level design goals described in RFC 4690, albeit for application technologies other than the Domain Name System (DNS).  This document obsoletes RFC 3454.</t></abstract>
775<seriesInfo name='Internet-Draft' value='draft-ietf-precis-framework-14' />
776<format type='TXT'
777        target='' />
780<reference anchor='I-D.ietf-straw-b2bua-loop-detection'>
782<title>Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to- Back User Agents (B2BUAs)</title>
783<author initials='H' surname='Kaplan' fullname='Hadriel Kaplan'>
784    <organization />
786<author initials='V' surname='Pascual' fullname='Victor Pascual'>
787    <organization />
789<date month='February' day='10' year='2014' />
790<abstract><t>SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request routing loops because, as User Agent Clients, they can generate SIP requests with new Max-Forwards values.  This document discusses the difficulties associated with loop detection for B2BUAs, and requirements for them to prevent infinite loops.</t></abstract>
792<seriesInfo name='Internet-Draft' value='draft-ietf-straw-b2bua-loop-detection-04' />
793<format type='TXT'
794        target='' />
797<reference anchor='I-D.ietf-xmpp-6122bis'>
799<title>Extensible Messaging and Presence Protocol (XMPP): Address Format</title>
800<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
801    <organization />
803<date month='January' day='23' year='2014' />
804<abstract><t>This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range.  This document obsoletes RFC 6122.</t></abstract>
806<seriesInfo name='Internet-Draft' value='draft-ietf-xmpp-6122bis-10' />
807<format type='TXT'
808        target='' />
811<reference anchor='RFC2782'>
813<title abbrev='DNS SRV RR'>A DNS RR for specifying the location of services (DNS SRV)</title>
814<author initials='A.' surname='Gulbrandsen' fullname='Arnt Gulbrandsen'>
815<organization>Troll Tech</organization>
818<street>Waldemar Thranes gate 98B</street>
820<region />
823<phone>+47 22 806390</phone>
824<facsimile>+47 22 806380</facsimile>
826<author initials='P.' surname='Vixie' fullname='Paul Vixie'>
827<organization>Internet Software Consortium</organization>
830<street>950 Charter Street</street>
831<city>Redwood City</city>
835<phone>+1 650 779 7001</phone></address></author>
836<author initials='L.' surname='Esibov' fullname='Levon Esibov'>
837<organization>Microsoft Corporation</organization>
840<street>One Microsoft Way</street>
846<date month='February' year='2000' />
848<t>This document describes a DNS RR which specifies the location of the
849   server(s) for a specific protocol and domain.</t></abstract></front>
850<seriesInfo name='RFC' value='2782' />
851<format type='TXT' octets='24013' target='' />
854<reference anchor="RFC3428">
856<title>Session Initiation Protocol (SIP) Extension for Instant Messaging</title>
857<author initials='B.' surname='Campbell' fullname='B. Campbell'>
858<organization /></author>
859<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
860<organization /></author>
861<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
862<organization /></author>
863<author initials='C.' surname='Huitema' fullname='C. Huitema'>
864<organization /></author>
865<author initials='D.' surname='Gurle' fullname='D. Gurle'>
866<organization /></author>
867<date month='December' year='2002' /></front>
868<seriesInfo name='RFC' value='3428' />
869<format type='TXT' octets='41475' target='' />
872<reference anchor="RFC3454">
874<title>Preparation of Internationalized Strings ("STRINGPREP")</title>
875<author initials='P.' surname='Hoffman' fullname='P.  Hoffman'>
876<organization /></author>
877<author initials='M.' surname='Blanchet' fullname='M.  Blanchet'>
878<organization /></author>
879<date month='December' year='2002' /></front>
880<seriesInfo name='RFC' value='3454' />
881<format type='TXT' octets='138684' target='' />
884<reference anchor="RFC3856">
886<title>A Presence Event Package for the Session Initiation Protocol (SIP)</title>
887<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
888<organization /></author>
889<date year='2004' month='August' /></front>
890<seriesInfo name='RFC' value='3856' />
891<format type='TXT' octets='62956' target='' />
894<reference anchor="RFC3859">
896<title>Common Profile for Presence (CPP)</title>
897<author initials='J.' surname='Peterson' fullname='J. Peterson'>
898<organization /></author>
899<date year='2004' month='August' /></front>
900<seriesInfo name='RFC' value='3859' />
901<format type='TXT' octets='30537' target='' />
904<reference anchor="RFC3860">
906<title>Common Profile for Instant Messaging (CPIM)</title>
907<author initials='J.' surname='Peterson' fullname='J. Peterson'>
908<organization /></author>
909<date year='2004' month='August' /></front>
910<seriesInfo name='RFC' value='3860' />
911<format type='TXT' octets='26486' target='' />
914<reference anchor='RFC3966'>
916<title>The tel URI for Telephone Numbers</title>
917<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
918<organization /></author>
919<date year='2004' month='December' />
921<t>This document specifies the URI (Uniform Resource Identifier) scheme "tel".  The "tel" URI describes resources identified by telephone numbers.  This document obsoletes RFC 2806. [STANDARDS-TRACK]</t></abstract></front>
922<seriesInfo name='RFC' value='3966' />
923<format type='TXT' octets='40783' target='' />
926<reference anchor='RFC5122'>
928<title>Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)</title>
929<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
930<organization /></author>
931<date year='2008' month='February' />
933<t>This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]</t></abstract></front>
934<seriesInfo name='RFC' value='5122' />
935<format type='TXT' octets='55566' target='' />
938<reference anchor='RFC5322'>
940<title>Internet Message Format</title>
941<author initials='P.' surname='Resnick' fullname='Peter W.
942Resnick' role='editor'>
943<organization>Qualcomm Incorporated</organization>
946<street>5775 Morehouse Drive</street>
947<city>San Diego</city>
951<phone>+1 858 651 4478</phone>
954<date year='2008' month='October' />
956<t>This document specifies the Internet
957Message Format (IMF), a syntax for text messages
958                        that are sent between computer users, within
959the framework of "electronic mail"
960                        messages. This specification is a revision of
961Request For Comments (RFC) 2822, which
962                        itself superseded Request For Comments (RFC)
963822, "Standard for the Format of ARPA
964                        Internet Text Messages", updating it to
965reflect current practice and incorporating
966                        incremental changes that were specified in
967other RFCs.</t></abstract></front>
969<seriesInfo name='RFC' value='5322' />
970<format type='TXT' octets='122322' target='' />
971<format type='HTML' octets='213342' target='' />
972<format type='XML' octets='174183' target='' />
975<reference anchor='RFC5626'>
977<title>Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)</title>
978<author initials='C.' surname='Jennings' fullname='C. Jennings'>
979<organization /></author>
980<author initials='R.' surname='Mahy' fullname='R. Mahy'>
981<organization /></author>
982<author initials='F.' surname='Audet' fullname='F. Audet'>
983<organization /></author>
984<date year='2009' month='October' />
986<t>The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams to User Agents in order to deliver requests.  However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way.  This specification defines behaviors for User Agents, registrars, and proxy servers that allow requests to be delivered on existing connections established by the User Agent.  It also defines keep-alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its registrar. [STANDARDS-TRACK]</t></abstract></front>
987<seriesInfo name='RFC' value='5626' />
988<format type='TXT' octets='116344' target='' />
991<reference anchor='RFC6121'>
993<title>Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence</title>
994<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
995<organization /></author>
996<date year='2011' month='March' />
998<t>This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779.  This document obsoletes RFC 3921. [STANDARDS-TRACK]</t></abstract></front>
999<seriesInfo name='RFC' value='6121' />
1000<format type='TXT' octets='244800' target='' />
1003<reference anchor='RFC6665'>
1005<title>SIP-Specific Event Notification</title>
1006<author initials='A.B.' surname='Roach' fullname='A.B. Roach'>
1007<organization /></author>
1008<date year='2012' month='July' />
1010<t>This document describes an extension to the Session Initiation Protocol (SIP) defined by RFC 3261. The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred.&lt;/t>&lt;t> Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification.&lt;/t>&lt;t> This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. [STANDARDS-TRACK]</t></abstract></front>
1011<seriesInfo name='RFC' value='6665' />
1012<format type='TXT' octets='125556' target='' />
1015<reference anchor="UTS39" target=''>
1016  <front>
1017    <title>Unicode Technical Standard #39: Unicode Security Mechanisms</title>
1018    <author>
1019      <organization>The Unicode Consortium</organization>
1020    </author>
1021    <date month="November" year="2013" />
1022  </front>
1025<reference anchor="XEP-0106">
1026  <front>
1027    <title>JID Escaping</title>
1028    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
1029      <organization/>
1030      <address>
1031        <email></email>
1032      </address>
1033    </author>
1034    <author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
1035      <organization/>
1036      <address>
1037        <email></email>
1038      </address>
1039    </author>
1040    <date day="18" month="June" year="2007"/>
1041  </front>
1042  <seriesInfo name="XSF XEP" value="0106"/>
1043  <format type="HTML" target=""/>
1046<reference anchor="XEP-0131">
1047  <front>
1048    <title>Stanza Headers and Internet Metadata</title>
1049    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
1050      <organization/>
1051      <address>
1052        <email></email>
1053      </address>
1054    </author>
1055    <author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
1056      <organization/>
1057      <address>
1058        <email></email>
1059      </address>
1060    </author>
1061    <date day="12" month="July" year="2006"/>
1062  </front>
1063  <seriesInfo name="XSF XEP" value="0131"/>
1064  <format type="HTML" target=""/>
1067    </references>
1069    <section title="Acknowledgements" anchor="ack">
1070      <t>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.</t>
1071      <t>Dan Romascanu reviewed the document on behalf of the General Area Review Team.</t>
1072      <t>During IESG review, Stephen Farrell, Ted Lemon, Pete Resnick, and Sean Turner caught several issues that needed to be addressed.</t>
1073      <t>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.</t>
1074      <t>Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier versions of this document.</t>
1075    </section>
1077  </back>
Note: See TracBrowser for help on using the repository browser.