One document matched: draft-saintandre-sip-xmpp-core-05.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<rfc category='std' docName='draft-saintandre-sip-xmpp-core-05' ipr='trust200902'>
<front>
<title abbrev="SIP-XMPP Interworking: Core">Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Addresses and Error Conditions</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3282</phone>
<email>psaintan@cisco.com</email>
</address>
</author>
<author initials="A." surname="Houri" fullname="Avshalom Houri">
<organization>IBM</organization>
<address>
<postal>
<street>Building 18/D, Kiryat Weizmann Science Park</street>
<city>Rehovot</city>
<code>76123</code>
<country>Israel</country>
</postal>
<email>avshalom@il.ibm.com</email>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<email>jhildebr@cisco.com</email>
</address>
</author>
<date/>
<area>RAI</area>
<keyword>XMPP</keyword>
<keyword>SIP</keyword>
<abstract>
<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>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<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>
<t>
<list style='symbols'>
<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>
<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.</t>
</list>
</t>
<t>Because these technologies are widely deployed, it is important to clearly define mappings between them for the sake of interworking. This document inaugurates a series of SIP-XMPP interworking specifications by defining the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.</t>
<t>The discussion venue for this document is the mailing list of the DISPATCH WG; visit https://www.ietf.org/mailman/listinfo/dispatch for subscription information and discussion archives.</t>
</section>
<section title="Terminology" anchor="terms">
<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>
</section>
<section title="Architectural Assumptions" anchor="intro-arch">
<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 application-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>
<t>This document assumes that the protocol translation will occur within a gateway. (This assumption 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.) Specifically, we assume that the protocol translation will occur within an "XMPP-to-SIP gateway" that translates XMPP syntax and semantics on behalf of an XMPP service when communicating with SIP services and/or within a "SIP-to-XMPP gateway" that translates SIP syntax and semantics on behalf of a SIP service when communicating with XMPP services (naturally, these logical functions could occur in one and the same actual translator).</t>
<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 service will be translated by a gateway within the trust domain of that XMPP service, and information generated by the user of a SIP service will be translated by a gateway within the trust domain of that SIP service. However, nothing in this document ought to be taken as recommending against protocol translation at the destination domain.</t>
<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>
<t>
<list style='symbols'>
<t>romeo@example.net -- a SIP user.</t>
<t>example.net -- a SIP service with a gateway ("GW") to XMPP.</t>
<t>juliet@example.com -- an XMPP user.</t>
<t>example.com -- an XMPP service with a gateway ("GW") to SIP.</t>
</list>
</t>
<figure>
<artwork><![CDATA[
##@#######################################################
# # #
# +-------------+----+ # +----+-------------+ #
# | example.net | GW |---#---| GW | example.com | #
# +-------------+----+ # +----+-------------+ #
# | # | #
# romeo@example.net # juliet@example.com #
# # #
##########################################################
]]></artwork>
</figure>
</section>
<section title="Address Mapping" anchor="addr">
<section title="Overview" anchor="addr-over">
<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 spports 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"/>).</t>
<t>The XMPP address format is specified in <xref target="RFC6122"/>; as discussed in <xref target="RFC6121"/>, instant messaging and presence applications of XMPP also need to 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>
<t>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 <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>
<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>
</section>
<section title="Local Part Mapping" anchor="addr-localpart">
<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>
<figure>
<artwork><![CDATA[
user = 1*( unreserved / escaped / user-unreserved )
user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
/ "(" / ")"
]]></artwork>
</figure>
<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>
<figure>
<artwork><![CDATA[
dot-atom-text = 1*atext *("." 1*atext)
atext = ALPHA / DIGIT / ; Any character except
"!" / "#" / "$" / ; controls, SP, and
"%" / "&" / "'" / ; specials. Used for
"*" / "+" / "-" / ; atoms.
"/" / "=" / "?" /
"^" / "_" / "`" /
"{" / "|" / "}" /
"~"
]]></artwork>
</figure>
<t>The local part of an XMPP address allows any ASCII character except space, controls, and the " & ' / : < > @ characters.</t>
<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>
<figure>
<preamble>Table 1: Allowed and disallowed characters</preamble>
<artwork><![CDATA[
+---+----------------------------------+
| SIP/SIPS CHARACTERS |
+---+----------------------------------+
| A | ! $ &'()*+,-./ ; = ? _ ~ |
| D | "# % : < > @[\]^ `{|} |
+---+----------------------------------+
| IM/PRES CHARACTERS |
+---+----------------------------------+
| A | ! #$%&' *+ - / = ? ^_`{|}~ |
| D | " () , . :;< > @[\] |
+---+----------------------------------+
| XMPP CHARACTERS |
+---+----------------------------------+
| A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ |
| D | " &' /: < > @ |
+---+----------------------------------+
]]></artwork>
</figure>
<t>When transforming the local part of an address from one scheme to another, an application SHOULD proceed as follows:</t>
<t>
<list style='numbers'>
<t>Unescape any escaped characters in the source address (e.g., from SIP to XMPP unescape "%2F" to "/" and from XMPP to SIP unescape "\27" to "'").</t>
<t>Leave unmodified any characters that are allowed in the destination scheme.</t>
<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:
<list style='symbols'>
<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.6 of <xref target='RFC4395'/> (e.g., when transforming from XMPP to SIP, encode "/" as "%2F").</t>
<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>
</list>
</t>
</list>
</t>
</section>
<section title="Instance-Specific Mapping" anchor="addr-instance">
<t>The meaning of a resourcepart in XMPP (i.e., the portion of a 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 <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 resource part, and vice-versa.</t>
<t>Note that the "gr" URI parameter in SIP can contain only characters from the ASCII range, 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>
</section>
<section title="SIP to XMPP" anchor="addr-sip">
<t>The following is a high-level algorithm for mapping a sip:, sips:, im:, or pres: URI to an XMPP address:</t>
<t>
<list style='numbers'>
<t>Remove URI scheme.</t>
<t>Split at the first '@' character into local part and hostname (mapping the latter is out of scope).</t>
<t>Translate any percent-encoded strings ("%hexhex") to percent-decoded octets.</t>
<t>Treat result as a UTF-8 string.</t>
<t>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 <xref target="XEP-0106"/>).</t>
<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>
<t>Recombine local part with mapped hostname to form a bare JID ("localpart@domainpart").</t>
<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>
</list>
</t>
</section>
<section title="XMPP to SIP" anchor="addr-xmpp">
<t>The following is a high-level algorithm for mapping an XMPP address to a sip:, sips:, im:, or pres: URI:</t>
<t>
<list style='numbers'>
<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>
<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>
<t>Translate "\26" to "&", "\27" to "'", and "\2f" to "/" respectively (this is consistent with <xref target="XEP-0106"/>).</t>
<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>
<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>
<t>Combine resulting local part with mapped hostname to form local@domain address.</t>
<t>Prepend with 'im:' scheme (for XMPP <message/> stanzas) or 'pres:' scheme (for XMPP <presence/> stanzas) if foreign domain supports these, else prepend with 'sip:' or 'sips:' scheme according to local service policy.</t>
<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>
</list>
</t>
</section>
</section>
<section title='Error Condition Mapping' anchor="errors">
<t>SIP response codes are specified in <xref target='RFC3261'/> and XMPP error conditions are specified in <xref target='RFC6120'/>. Because there is no equivalent in XMPP for the provisional (1xx) and successful (2xx) response codes in SIP, mappings are provided only for the redirection (3xx), request failure (4xx), server failure (5xx), and glogal failure (6xx) codes.</t>
<section title="XMPP to SIP" anchor="errors-xmpp">
<figure>
<preamble>Table 8: Mapping of XMPP error conditions to SIP response codes</preamble>
<artwork><![CDATA[
+------------------------------+---------------------+
| XMPP Error Condition | SIP Response Code |
+------------------------------+---------------------+
| <bad-request/> | 400 |
| <conflict/> | 400 |
| <feature-not-implemented/> | 501 |
| <forbidden/> | 403 |
| <gone/> | 410 |
| <internal-server-error/> | 500 |
| <item-not-found/> | 404 |
| <jid-malformed/> | 484 |
| <not-acceptable/> | 406 |
| <not-allowed/> | 405 |
| <not-authorized/> | 401 |
| <recipient-unavailable/> | 480 |
| <redirect/> | 300 |
| <registration-required/> | 407 |
| <remote-server-not-found/> | 502 |
| <remote-server-timeout/> | 504 |
| <resource-constraint/> | 500 |
| <service-unavailable/> | 503 |
| <subscription-required/> | 407 |
| <undefined-condition/> | 400 |
| <unexpected-request/> | 491 |
+------------------------------+---------------------+
]]></artwork>
</figure>
</section>
<section title="SIP to XMPP" anchor="errors-sip">
<t>The mapping of SIP response codes to XMPP error conditions SHOULD be as follows (note that XMPP does not include 100-series or 200-series response codes, only error conditions):</t>
<figure>
<preamble>Table 9: Mapping of SIP response codes to XMPP error conditions</preamble>
<artwork><![CDATA[
+---------------------+------------------------------+
| SIP Response Code | XMPP Error Condition |
+---------------------+------------------------------+
| 300 | <redirect/> |
| 301 | <gone/> |
| 302 | <redirect/> |
| 305 | <redirect/> |
| 380 | <not-acceptable/> |
| 400 | <bad-request/> |
| 401 | <not-authorized/> |
| 402 | see note [1] |
| 403 | <forbidden/> |
| 404 | <item-not-found/> |
| 405 | <not-allowed/> |
| 406 | <not-acceptable/> |
| 407 | <registration-required/> |
| 408 | <recipient-unavailable/> |
| 410 | <gone/> |
| 413 | <bad-request/> |
| 414 | <bad-request/> |
| 415 | <bad-request/> |
| 416 | <bad-request/> |
| 420 | <bad-request/> |
| 421 | <bad-request/> |
| 423 | <bad-request/> |
| 480 | <recipient-unavailable/> |
| 481 | <item-not-found/> |
| 482 | <not-acceptable/> |
| 483 | <not-acceptable/> |
| 484 | <jid-malformed/> |
| 485 | <item-not-found/> |
| 486 | <recipient-unavailable/> |
| 487 | <recipient-unavailable/> |
| 488 | <not-acceptable/> |
| 491 | <unexpected-request/> |
| 493 | <bad-request/> |
| 500 | <internal-server-error/> |
| 501 | <feature-not-implemented/> |
| 502 | <remote-server-not-found/> |
| 503 | <service-unavailable/> |
| 504 | <remote-server-timeout/> |
| 505 | <not-acceptable/> |
| 513 | <bad-request/> |
| 600 | <recipient-unavailable/> |
| 603 | <recipient-unavailable/> |
| 604 | <item-not-found/> |
| 606 | <not-acceptable/> |
+---------------------+------------------------------+
]]></artwork>
</figure>
<t>
<list style='numbers'>
<t>The XMPP <payment-required/> error condition was removed in <xref target='RFC6120'/>.</t>
</list>
</t>
</section>
</section>
<section title='Security Considerations' anchor="sec">
<t>Detailed security considerations for SIP are given in <xref target="RFC3261"/> and for XMPP in <xref target="RFC6120"/>.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>This document requests no actions of IANA.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>-</email>
</address>
</author>
<date month='March' year='1997'></date>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<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:
<list>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.</t>
</list>
</t>
<t>Note that the force of these words is modified by the requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
</reference>
<reference anchor='RFC3261'>
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
<organization /></author>
<author initials='G.' surname='Camarillo' fullname='G. Camarillo'>
<organization /></author>
<author initials='A.' surname='Johnston' fullname='A. Johnston'>
<organization /></author>
<author initials='J.' surname='Peterson' fullname='J. Peterson'>
<organization /></author>
<author initials='R.' surname='Sparks' fullname='R. Sparks'>
<organization /></author>
<author initials='M.' surname='Handley' fullname='M. Handley'>
<organization /></author>
<author initials='E.' surname='Schooler' fullname='E. Schooler'>
<organization /></author>
<date month='June' year='2002' /></front>
<seriesInfo name='RFC' value='3261' />
<format type='TXT' octets='647976' target='ftp://ftp.isi.edu/in-notes/rfc3261.txt' />
</reference>
<reference anchor='RFC3986'>
<front>
<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>Massachusetts Institute of Technology</street>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country></postal>
<phone>+1-617-253-5702</phone>
<facsimile>+1-617-258-5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3.org/People/Berners-Lee/</uri></address></author>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='Day Software'>Day Software</organization>
<address>
<postal>
<street>5251 California Ave., Suite 110</street>
<city>Irvine</city>
<region>CA</region>
<code>92617</code>
<country>USA</country></postal>
<phone>+1-949-679-2960</phone>
<facsimile>+1-949-679-2972</facsimile>
<email>fielding@gbiv.com</email>
<uri>http://roy.gbiv.com/</uri></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Adobe Systems'>Adobe Systems Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country></postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri></address></author>
<date year='2005' month='January' />
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<abstract>
<t>
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
</t></abstract></front>
<seriesInfo name='STD' value='66' />
<seriesInfo name='RFC' value='3986' />
<format type='TXT' octets='141811' target='ftp://ftp.isi.edu/in-notes/rfc3986.txt' />
<format type='HTML' octets='200858' target='http://xml.resource.org/public/rfc/html/rfc3986.html' />
<format type='XML' octets='165759' target='http://xml.resource.org/public/rfc/xml/rfc3986.xml' />
</reference>
<reference anchor='RFC4395'>
<front>
<title>Guidelines and Registration Procedures for New URI Schemes</title>
<author initials='T.' surname='Hansen' fullname='Tony Hansen'>
<organization>AT&T Laboratories</organization>
<address>
<postal>
<street>200 Laurel Ave.</street>
<city>Middletown</city>
<region>NJ</region>
<code>07748</code>
<country>US</country></postal>
<email>tony+urireg@maillennium.att.com</email></address></author>
<author initials='T.' surname='Hardie' fullname='Ted Hardie'>
<organization>Qualcomm, Inc.</organization>
<address>
<postal>
<street>675 Campbell Technology Parkway</street>
<city>Campbell</city>
<region>CA</region>
<country>US</country></postal>
<email>hardie@qualcomm.com</email></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization>Adobe Systems</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>US</country></postal>
<email>LMM@acm.org</email></address></author>
<date month='February' year='2006' />
<abstract>
<t>This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718.</t></abstract></front>
<seriesInfo name='RFC' value='4395' />
<format type='TXT' octets='31933' target='ftp://ftp.isi.edu/in-notes/rfc4395.txt' />
</reference>
<reference anchor='RFC5627'>
<front>
<title>Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<date year='2009' month='October' />
<abstract>
<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>
<seriesInfo name='RFC' value='5627' />
<format type='TXT' octets='94790' target='http://www.rfc-editor.org/rfc/rfc5627.txt' />
</reference>
<reference anchor='RFC6120'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<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>
<seriesInfo name='RFC' value='6120' />
<format type='TXT' octets='451942' target='http://www.rfc-editor.org/rfc/rfc6120.txt' />
</reference>
<reference anchor='RFC6122'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Address Format</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<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>
<seriesInfo name='RFC' value='6122' />
<format type='TXT' octets='50646' target='http://www.rfc-editor.org/rfc/rfc6122.txt' />
</reference>
<reference anchor="UNICODE" target="http://www.unicode.org/versions/Unicode6.2.0/">
<front>
<title>The Unicode Standard, Version 6.2</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date year="2012" />
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor='RFC2782'>
<front>
<title abbrev='DNS SRV RR'>A DNS RR for specifying the location of services (DNS SRV)</title>
<author initials='A.' surname='Gulbrandsen' fullname='Arnt Gulbrandsen'>
<organization>Troll Tech</organization>
<address>
<postal>
<street>Waldemar Thranes gate 98B</street>
<city>Oslo</city>
<region />
<code>N-0175</code>
<country>NO</country></postal>
<phone>+47 22 806390</phone>
<facsimile>+47 22 806380</facsimile>
<email>arnt@troll.no</email></address></author>
<author initials='P.' surname='Vixie' fullname='Paul Vixie'>
<organization>Internet Software Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country></postal>
<phone>+1 650 779 7001</phone></address></author>
<author initials='L.' surname='Esibov' fullname='Levon Esibov'>
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country></postal>
<email>levone@microsoft.com</email></address></author>
<date month='February' year='2000' />
<abstract>
<t>This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.</t></abstract></front>
<seriesInfo name='RFC' value='2782' />
<format type='TXT' octets='24013' target='ftp://ftp.isi.edu/in-notes/rfc2782.txt' />
</reference>
<reference anchor="RFC3428">
<front>
<title>Session Initiation Protocol (SIP) Extension for Instant Messaging</title>
<author initials='B.' surname='Campbell' fullname='B. Campbell'>
<organization /></author>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
<organization /></author>
<author initials='C.' surname='Huitema' fullname='C. Huitema'>
<organization /></author>
<author initials='D.' surname='Gurle' fullname='D. Gurle'>
<organization /></author>
<date month='December' year='2002' /></front>
<seriesInfo name='RFC' value='3428' />
<format type='TXT' octets='41475' target='ftp://ftp.isi.edu/in-notes/rfc3428.txt' />
</reference>
<reference anchor="RFC3454">
<front>
<title>Preparation of Internationalized Strings ("STRINGPREP")</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='M.' surname='Blanchet' fullname='M. Blanchet'>
<organization /></author>
<date month='December' year='2002' /></front>
<seriesInfo name='RFC' value='3454' />
<format type='TXT' octets='138684' target='ftp://ftp.isi.edu/in-notes/rfc3454.txt' />
</reference>
<reference anchor="RFC3856">
<front>
<title>A Presence Event Package for the Session Initiation Protocol (SIP)</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<date year='2004' month='August' /></front>
<seriesInfo name='RFC' value='3856' />
<format type='TXT' octets='62956' target='ftp://ftp.isi.edu/in-notes/rfc3856.txt' />
</reference>
<reference anchor="RFC3859">
<front>
<title>Common Profile for Presence (CPP)</title>
<author initials='J.' surname='Peterson' fullname='J. Peterson'>
<organization /></author>
<date year='2004' month='August' /></front>
<seriesInfo name='RFC' value='3859' />
<format type='TXT' octets='30537' target='ftp://ftp.isi.edu/in-notes/rfc3859.txt' />
</reference>
<reference anchor="RFC3860">
<front>
<title>Common Profile for Instant Messaging (CPIM)</title>
<author initials='J.' surname='Peterson' fullname='J. Peterson'>
<organization /></author>
<date year='2004' month='August' /></front>
<seriesInfo name='RFC' value='3860' />
<format type='TXT' octets='26486' target='ftp://ftp.isi.edu/in-notes/rfc3860.txt' />
</reference>
<reference anchor='RFC5322'>
<front>
<title>Internet Message Format</title>
<author initials='P.' surname='Resnick' fullname='Peter W.
Resnick' role='editor'>
<organization>Qualcomm Incorporated</organization>
<address>
<postal>
<street>5775 Morehouse Drive</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-1714</code>
<country>US</country></postal>
<phone>+1 858 651 4478</phone>
<email>presnick@qualcomm.com</email>
<uri>http://www.qualcomm.com/~presnick/</uri></address></author>
<date year='2008' month='October' />
<abstract>
<t>This document specifies the Internet
Message Format (IMF), a syntax for text messages
that are sent between computer users, within
the framework of "electronic mail"
messages. This specification is a revision of
Request For Comments (RFC) 2822, which
itself superseded Request For Comments (RFC)
822, "Standard for the Format of ARPA
Internet Text Messages", updating it to
reflect current practice and incorporating
incremental changes that were specified in
other RFCs.</t></abstract></front>
<seriesInfo name='RFC' value='5322' />
<format type='TXT' octets='122322' target='http://www.rfc-editor.org/rfc/rfc5322.txt' />
<format type='HTML' octets='213342' target='http://xml.resource.org/public/rfc/html/rfc5322.html' />
<format type='XML' octets='174183' target='http://xml.resource.org/public/rfc/xml/rfc5322.xml' />
</reference>
<reference anchor='RFC6121'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<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>
<seriesInfo name='RFC' value='6121' />
<format type='TXT' octets='244800' target='http://www.rfc-editor.org/rfc/rfc6121.txt' />
</reference>
<reference anchor='I-D.ietf-xmpp-6122bis'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Address Format</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<date month='April' day='25' year='2013' />
<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>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-xmpp-6122bis-07' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-xmpp-6122bis-07.txt' />
</reference>
<reference anchor="XEP-0106">
<front>
<title>JID Escaping</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization/>
<address>
<email>jhildebrand@jabber.com</email>
</address>
</author>
<date day="12" month="May" year="2005"/>
</front>
<seriesInfo name="XSF XEP" value="0106"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0106.html"/>
</reference>
</references>
<section title="Acknowledgements" anchor="ack">
<t>The authors wish to thank the following individuals for their feedback: Fabio Forno, Adrian Georgescu, Saul Ibarra, Markus Isomaki, Salvatore Loreto, Daniel-Constantin Mierla, Tory Patnoe, and Robert Sparks.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:39:41 |