idnits 2.17.1 draft-saintandre-xmpp-uri-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 875. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 859. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 865. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 432 has weird spacing: '...II-only docum...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 9, 2004) is 7071 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IMP-MODEL' is defined on line 773, but no explicit reference was found in the text == Unused Reference: 'IMP-REQS' is defined on line 777, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Normative reference to a draft: ref. 'URI' ** Obsolete normative reference: RFC 2718 (ref. 'URL-GUIDE') (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 2717 (ref. 'URL-REG') (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 3920 (ref. 'XMPP-CORE') (Obsoleted by RFC 6120) ** Obsolete normative reference: RFC 3921 (ref. 'XMPP-IM') (Obsoleted by RFC 6121) -- Obsolete informational reference (is this intentional?): RFC 2617 (ref. 'HTTP-AUTH') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 3490 (ref. 'IDNA') (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 2368 (ref. 'MAILTO') (Obsoleted by RFC 6068) -- Obsolete informational reference (is this intentional?): RFC 3491 (ref. 'NAMEPREP') (Obsoleted by RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 3454 (ref. 'STRINGPREP') (Obsoleted by RFC 7564) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Saint-Andre 2 Internet-Draft Jabber Software Foundation 3 Expires: June 9, 2005 December 9, 2004 5 A Uniform Resource Identifier (URI) Scheme for the Extensible 6 Messaging and Presence Protocol (XMPP) 7 draft-saintandre-xmpp-uri-08 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 9, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 This document defines a Uniform Resource Identifier (URI) scheme for 43 use in identifying or interacting with entities that can communicate 44 via the Extensible Messaging and Presence Protocol (XMPP). 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Description of xmpp: URI Scheme . . . . . . . . . . . . . . . 3 51 2.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.2 Form . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.3 Authority Component . . . . . . . . . . . . . . . . . . . 5 54 2.4 Path Component . . . . . . . . . . . . . . . . . . . . . . 6 55 2.5 Query Component . . . . . . . . . . . . . . . . . . . . . 6 56 2.6 Fragment Identifier Component . . . . . . . . . . . . . . 8 57 2.7 Generation of XMPP URIs . . . . . . . . . . . . . . . . . 8 58 2.8 Processing of XMPP URIs . . . . . . . . . . . . . . . . . 11 59 2.9 Internationalization . . . . . . . . . . . . . . . . . . . 14 60 3. IANA Registration of xmpp: URI Scheme . . . . . . . . . . . . 14 61 3.1 URI scheme name . . . . . . . . . . . . . . . . . . . . . 14 62 3.2 URI scheme syntax . . . . . . . . . . . . . . . . . . . . 14 63 3.3 Character encoding considerations . . . . . . . . . . . . 15 64 3.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . 15 65 3.5 Applications and/or protocols which use this URL 66 scheme name . . . . . . . . . . . . . . . . . . . . . . . 15 67 3.6 Security considerations . . . . . . . . . . . . . . . . . 15 68 3.7 Relevant publications . . . . . . . . . . . . . . . . . . 16 69 3.8 Person and email address to contact for further 70 information . . . . . . . . . . . . . . . . . . . . . . . 16 71 3.9 Author/change controller . . . . . . . . . . . . . . . . . 16 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 76 6.2 Informative References . . . . . . . . . . . . . . . . . . . 17 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 78 Intellectual Property and Copyright Statements . . . . . . . . 20 80 1. Introduction 82 The Extensible Messaging and Presence Protocol (XMPP) is a streaming 83 XML technology that enables any two entities on a network to exchange 84 well-defined but extensible XML elements (called "XML stanzas") in 85 close to real time. [XMPP-CORE] specifies that on an XMPP network 86 itself, the address of an XMPP entity MUST NOT be prepended with a 87 Uniform Resource Identifier (URI) scheme (as defined in [URI]). 88 However, many applications external to an XMPP network may need to 89 identify XMPP entities as full URIs; examples include databases that 90 need to store XMPP addresses and non-native user agents (e.g., web 91 browsers and calendaring applications) that provide interfaces to 92 XMPP services. In order to address the needs of such applications, 93 this memo defines an xmpp: URI scheme that conforms to both the 94 requirements in [URL-REG] and the recommendations in [URL-GUIDE]. 96 1.1 Terminology 98 This document inherits terminology described in [URI] and 99 [XMPP-CORE]. 101 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 102 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in RFC 104 2119 [TERMS]. 106 2. Description of xmpp: URI Scheme 108 2.1 Rationale 110 Many types of application can be built using XMPP. As specified in 111 [XMPP-IM], instant messaging and presence applications of XMPP MUST 112 handle the im: and pres: URI schemes specified by [CPIM] and [CPP]. 113 However, it is appropriate to define an XMPP-specific URI scheme for 114 other applications of XMPP (such as network management, workflow 115 applications, generic publish-subscribe, remote procedure calls, 116 content syndication, gaming, and middleware) since these applications 117 do not necessarily implement instant messaging and presence 118 semantics. Therefore, this document defines a generic URI scheme 119 that will enable applications to address as a URI any entity that can 120 communicate via XMPP. 122 The xmpp: URI scheme is provided mainly for use by non-native 123 interfaces and applications, and primarily for the purpose of 124 identification rather than interaction (on the latter distinction, 125 see Section 1.2.2 of [URI]). In order to ensure interoperability on 126 XMPP networks, when data is routed to an XMPP entity (e.g., when an 127 XMPP address is contained in the 'to' or 'from' attribute of an XML 128 stanza) or an XMPP entity is otherwise identified in standard XMPP 129 protocol elements, the entity MUST be addressed as 130 <[node@]domain[/resource]> (i.e., without a URI scheme), where the 131 "node identifier", "domain identifier", and "resource identifier" 132 portions of an XMPP address conform to the definitions provided in 133 Section 3 of [XMPP-CORE]. 135 (Note: For historical reasons, the term "resource identifier" is used 136 in XMPP to refer to the optional portion of an XMPP address that 137 follows the domain identifier and the "/" separator character (for 138 details, refer to Section 3.4 of [XMPP-CORE]); this use of the term 139 "resource identifier" is not to be confused with the meanings of 140 "resource" and "identifier" provided in Section 1.1 of [URI].) 142 2.2 Form 144 As described in [XMPP-CORE], an XMPP address (also known as a "JID") 145 used natively on an XMPP network is a string of Unicode characters 146 that (1) conforms to a certain set of [STRINGPREP] profiles and 147 [IDNA] restrictions, (2) follows a certain set of syntax rules, and 148 (3) is encoded as [UTF-8]. The form of such an address can be 149 represented using Augmented Backus-Naur Form ([ABNF]) as: 151 [ node "@" ] domain [ "/" resource ] 153 The "node" and "resource" rules rely on distinct profiles of 154 [STRINGPREP] and the "domain" rule relies on the concept of an 155 internationalized domain name as described in [IDNA]. However, 156 because a URI is allowed to contain [US-ASCII] characters only and 157 certain characters are reserved in URIs (the "reserved" rule defined 158 in [URI]), an XMPP address must be properly handled when transformed 159 into an XMPP URI (see Section 2.7 of this memo) and the ABNF syntax 160 needs to be adjusted in order to accurately capture the form of an 161 XMPP URI as opposed to a native XMPP address. Furthermore, it is 162 desirable to take advantage of more advanced aspects of URI syntax 163 and semantics in XMPP URIs, such as authority components, query 164 components, and fragment identifier components. Therefore, using the 165 "fragment", "host", "pct-encoded", "query", "sub-delims", and 166 "unreserved" rules defined in [URI], the ABNF syntax for an XMPP URI 167 is defined as follows: 169 xmppuri = "xmpp:" hier-xmpp [ "?" querycomp ] [ "#" fragment ] 170 hier-xmpp = authpath / path-xmpp 171 authpath = "//" auth-xmpp [ "/" path-xmpp ] 172 auth-xmpp = nodeid "@" host 173 path-xmpp = [ nodeid "@" ] host [ "/" resid ] 174 nodeid = *( unreserved / pct-encoded / nodeallow ) 175 nodeallow = "!" / "$" / "%" / "(" / ")" / "*" / "+" / "," 176 / ";" / "=" / "^" / "`" / "{" / "|" / "}" 177 resid = *( unreserved / pct-encoded / sub-delims ) 178 querycomp = querytype [ *pair ] 179 querytype = *( ALPHA / DIGIT / '-' / '_' / '.' / ':' ) 180 pair = "&" key "=" value 181 key = *unreserved 182 value = *( unreserved / pct-encoded ) 184 (Note: It would have been desirable to re-use the "userinfo" rule 185 from [URI]; however, this was not possible since the "userinfo" rule 186 allows characters that conform to the "sub-delims" rule, but the "&" 187 and "'" characters (which are allowed by the "sub-delims" rule) are 188 disallowed in XMPP node identifiers by the Nodeprep profile of 189 [STRINGPREP] as specified in Appendix A of [XMPP-CORE]. Furthermore, 190 there is no need to refer to punycode in the URI syntax itself, since 191 any punycode representation would occur only inside an XMPP 192 application in order to represent internationalized domain names.) 194 The following is an example of a basic XMPP URI used for purposes of 195 identifying a node associated with an XMPP server (an IM user is one 196 type of such a node, but by no means the only type): 198 xmpp:juliet@example.com 200 Further descriptions of the various components of an XMPP URI are 201 provided in the following sections. 203 2.3 Authority Component 205 As explained in Section 2.8 of this memo, in the absence of an 206 authority component the processing application would authenticate as 207 a configured user at a configured XMPP server. The presence of an 208 authority component (always preceded by "//") signals the processing 209 application to authenticate as the node@domain specified in the 210 authority component, rather than as a configured node@domain. Thus, 211 the following XMPP URI indicates to authenticate as 212 "guest@example.com": 214 xmpp://guest@example.com 216 Note well that this is quite different from the following XMPP URI, 217 which identifies a node "guest@example.com" but does not signal the 218 processing application to authenticate as that node: 220 xmpp:guest@example.com 222 Similarly, using a possible query component of "?message" to trigger 223 an interface for sending a message, the following XMPP URI signals 224 the processing application to authenticate as "guest@example.com" and 225 send a message to "support@example.com": 227 xmpp://guest@example.com/support@example.com?message 229 By contrast, the following XMPP URI signals the processing 230 application to authenticate as its configured default account and 231 send a message to "support@example.com": 233 xmpp:support@example.com?message 235 (Note: It is unlikely that the authority component will be included 236 in most XMPP URIs; however, the scheme allows for inclusion of the 237 authority component if appropriate.) 239 2.4 Path Component 241 The path component of an XMPP URI identifies an XMPP address or 242 specifies the XMPP address to which an XML stanza shall be directed 243 at the end of URI processing. 245 For example, the following XMPP URI identifies a node associated with 246 an XMPP server: 248 xmpp:juliet@example.com 250 The following XMPP URI identifies a node associated with an XMPP 251 server along with a particular XMPP resource identifier associated 252 with that node: 254 xmpp:juliet@example.com/balcony 256 Inclusion of a node is optional in XMPP addresses, so that the 257 following XMPP URI simply identifies an XMPP server: 259 xmpp:example.com 261 2.5 Query Component 263 There are many potential use cases for encapsulating information in 264 the query component of an XMPP URI; examples include but are not 265 limited to: 267 o Sending an XMPP message stanza. 268 o Adding a roster item. 269 o Sending a presence subscription. 270 o Probing for current presence information. 271 o Joining an XMPP-based text chat room (see [JEP-0045]). 272 o Registering with another entity (see [JEP-0077]). 273 o Triggering a remote procedure call (see [JEP-0009]). 274 o Providing a SOAP interface (see [JEP-0072]). 275 o Discovering the identity or capabilities of another entity (see 276 [JEP-0030]). 277 o Interacting with publish-subscribe channels (see [JEP-0060]). 279 Many of these potential use cases are application-specific, and the 280 full range of such applications cannot be foreseen in advance given 281 the continued expansion in XMPP development; however, there is 282 agreement within the Jabber/XMPP developer community that all of the 283 uses envisioned to date can be encapsulated via a "query type", 284 optionally supplemented by one or more "key-value" pairs (this is 285 similar to the "application/x-www-form-urlencoded" MIME type 286 described in [HTML]). 288 As an example, an XMPP URI intended to launch an interface for 289 sending a message to the XMPP entity "juliet@example.com" might be 290 represented as follows: 292 xmpp:juliet@example.com?message 294 Similarly, an XMPP URI intended to launch an interface for sending a 295 message to the XMPP entity "juliet@example.com" with a particular 296 subject might be represented as follows: 298 xmpp:juliet@example.com?message&subject=Hello%20World 300 If included, the query component MUST first be encoded as a [UTF-8] 301 string; any [UTF-8] encoded octets MUST then be converted into 302 US-ASCII characters, making sure to represent any reserved character 303 (i.e., any character that conforms to the "reserved" rule defined in 304 [URI]) and any character that is outside the range of the US-ASCII 305 coded character set as a percent-encoded octet (see Section 2.1 of 306 [URI]). 308 If the processing application does not understand query components, 309 it MUST ignore the query component and treat the URI as consisting 310 of, for example, rather than 311 . If the processing application does 312 not understand a particular key within the query component, it MUST 313 ignore that key and its associated value. 315 In pursuit of interoperability, it may be valuable to maintain a 316 registry of query types and perhaps even of keys for use in the query 317 component portion of XMPP URIs. Given that such values will most 318 likely be specific to particular applications of XMPP rather than 319 core to XMPP itself, it seems reasonable that such a registry, if 320 created, would be maintained by the Jabber Registrar function of the 321 Jabber Software Foundation as described in [JEP-0053], rather than by 322 the IANA. A proposal for creating such a registry is described in 323 [JEP-0147]. 325 2.6 Fragment Identifier Component 327 As stated in Section 3.5 of [URI], "The fragment identifier component 328 of a URI allows indirect identification of a secondary resource by 329 reference to a primary resource and additional identifying 330 information." Because the resource identified by an XMPP URI does 331 not make available any media type (see [MIME]) and therefore (in the 332 terminology of [URI]) no representation exists at an XMPP resource, 333 the semantics of the fragment identifier component in XMPP URIs are 334 to be "considered unknown and, effectively, unconstrained" (ibid.). 335 Particular XMPP applications MAY make use of the fragment identifier 336 component for their own purposes. However, if a processing 337 application does not understand fragment identifier components or the 338 syntax of a particular fragment identifier component included in an 339 XMPP URI, it MUST ignore the fragment identifier component. 341 If included, the fragment identifier component MUST first be encoded 342 as a [UTF-8] string; any [UTF-8] encoded octets MUST then be 343 converted into US-ASCII characters, making sure to represent any 344 reserved character (i.e., any character that conforms to the 345 "reserved" rule defined in [URI]) and any character that is outside 346 the range of the US-ASCII coded character set as a percent-encoded 347 octet (see Section 2.1 of [URI]). 349 2.7 Generation of XMPP URIs 351 2.7.1 URI Generation Method 353 When generating a conformant XMPP URI from an XMPP address, it is 354 necessary to use consistent methods for transforming (1) an XMPP 355 "node identifier" into a string of US-ASCII characters that conforms 356 to the "nodeid" rule, (2) an XMPP "domain identifier" into a string 357 of US-ASCII characters that conforms to the "host" rule, and (3) an 358 XMPP "resource identifier" into a string of US-ASCII characters that 359 conforms to the "resid" rule; such methods are described below. 361 Naturally, if the XMPP address exists in a non-UTF-8 form (e.g., 362 having been written on a piece of paper or having been represented 363 internally in a computer program as UTF-16), it MUST first be 364 converted to [UTF-8] before the XMPP URI is generated. 366 In order to transform an XMPP "node identifier" into a string of 367 US-ASCII characters that conforms to the "nodeid" rule, the node 368 identifier MUST first be constructed in accordance with the rules 369 specified in [XMPP-CORE], including application of the Nodeprep 370 profile of [STRINGPREP] (see Appendix A of [XMPP-CORE]) and encoding 371 as a [UTF-8] string; any [UTF-8] encoded octets of the XMPP "node 372 identifier" MUST then be converted into US-ASCII characters, making 373 sure to represent any reserved character (i.e., any character that 374 conforms to the "reserved" rule defined in [URI]) and any character 375 that is outside the range of the US-ASCII coded character set as a 376 percent-encoded octet (see Section 2.1 of [URI]). 378 In order to transform an XMPP "domain identifier" into a string of 379 US-ASCII characters that conforms to the "host" rule, the domain 380 identifier MUST first be constructed in accordance with the rules 381 specified in [XMPP-CORE], including application of the [NAMEPREP] 382 profile of [STRINGPREP] and encoding as a [UTF-8] string; any [UTF-8] 383 encoded octets of the XMPP "domain identifier" MUST then be converted 384 into US-ASCII characters, making sure to represent any reserved 385 character (i.e., any character that conforms to the "reserved" rule 386 defined in [URI]) and any character that is outside the range of the 387 US-ASCII coded character set as a percent-encoded octet (see Section 388 2.1 of [URI]). 390 In order to transform an XMPP "resource identifier" into a string of 391 US-ASCII characters that conforms to the "resid" rule, the resource 392 identifier MUST first be constructed in accordance with the rules 393 specified in [XMPP-CORE], including application of the Resourceprep 394 profile of [STRINGPREP] (see Appendix B of [XMPP-CORE]) and encoding 395 as a [UTF-8] string; any [UTF-8] encoded octets of the XMPP "resource 396 identifier" MUST then be converted into US-ASCII characters, making 397 sure to represent any reserved character (i.e., any character that 398 conforms to the "reserved" rule defined in [URI]) and any character 399 that is outside the range of the US-ASCII coded character set as a 400 percent-encoded octet (see Section 2.1 of [URI]). 402 In order to form an XMPP URI from the foregoing components, the 403 generating application MUST concatenate: 405 1. the "xmpp:" scheme 406 2. optionally (if an authority component is to be included), the 407 characters "//", an authority component of the form node@domain, 408 and the character "/" 410 3. optionally (if the XMPP address contained an XMPP "node 411 identifier"), a string of US-ASCII characters that conforms to 412 the "nodeid" rule, followed by the "@" character 413 4. a string of US-ASCII characters that conforms to the "host" rule 414 5. optionally (if the XMPP address contained an XMPP "resource 415 identifier"), the character "/" and a string of US-ASCII 416 characters that conforms to the "resid" rule 417 6. optionally (if a query component is to be included), the "?" 418 character and query component 419 7. optionally (if a fragment identifier component is to be 420 included), the "#" character and fragment identifier component 422 2.7.2 URI Generation Example 424 Consider the following XMPP address: 426 428 (Note: The string "ř" stands for the Unicode character LATIN 429 SMALL LETTER R WITH CARON and the string "č" stands for the 430 Unicode character LATIN SMALL LETTER C WITH CARON, following the "XML 431 Notation" used in [IRI] to represent characters that cannot be 432 rendered in ASCII-only documents. The '<' and '>' characters are 433 not part of the address itself, but are provided to set off the 434 address for legibility. For those who do not read Czech, this 435 example could be Anglicized as "george@czech-lands.example/In 436 Prague".) 438 In accordance with the process specified above, the generating 439 application would do the following to generate a valid XMPP URI from 440 this address: 442 1. First ensure that the XMPP address conforms to the rules 443 specified in [XMPP-CORE], including application of the relevant 444 [STRINGPREP] profiles and encoding as a [UTF-8] string. 445 2. Split the address into an XMPP "node identifier" ("jiři"), 446 XMPP "domain identifier" ("čechy.example"), and XMPP 447 "resource identifier" ("v Praze"). 448 3. Transform the XMPP "node identifier" into a string of US-ASCII 449 characters that conforms to the "nodeid" rule by converting the 450 [UTF-8] string to US-ASCII, including conversion of the LATIN 451 SMALL LETTER R WITH CARON character to its percent-encoded 452 representation "%C5%99"; the result is the string "ji%C5%99i". 453 4. Transform the XMPP "domain identifier" into a string of US-ASCII 454 characters that conforms to the "host" rule by converting the 455 [UTF-8] string to US-ASCII, including conversion of the LATIN 456 SMALL LETTER C WITH CARON character to its percent-encoded 457 representation "%C4%8C"; the result is the string 458 "%C4%8Cechy.example". 459 5. Transform the XMPP "resource identifier" into a string of 460 US-ASCII characters that conforms to the "resid" rule by 461 converting the [UTF-8] string to US-ASCII, including conversion 462 of the " " (SP) character to its percent-encoded representation 463 "%20"; the result is the string "v%20Praze". 464 6. Concatenate the following: 465 1. the "xmpp:" scheme 466 2. a URI "authority component" if included (not shown in this 467 example) 468 3. the string of US-ASCII characters that conforms to the 469 "nodeid" rule, followed by the "@" character 470 4. the string of US-ASCII characters that conforms to the "host" 471 rule 472 5. the "/" character followed by the string of US-ASCII 473 characters that conforms to the "resid" rule 474 6. the "?" character followed by a URI "query component" if 475 appropriate to the application (not shown in this example) 476 7. the "#" character followed by a URI "fragment identifier 477 component" if appropriate to the application (not shown in 478 this example) 480 The result is this XMPP URI: 482 484 2.8 Processing of XMPP URIs 486 2.8.1 URI Processing Method 488 As with the generation of an XMPP URI from an XMPP address, so also 489 with the processing of an XMPP URI (including the extraction of an 490 XMPP address therefrom): it is necessary to use consistent methods; 491 such methods are described below. 493 In order to decompose an XMPP URI, a processing application MUST 494 separate: 496 1. the "xmpp:" scheme 497 2. optionally (if the XMPP URI contains an authority component), the 498 authority component (the string of US-ASCII characters between 499 the "//" characters and the first "/" character or the end of the 500 URI) 501 3. optionally a string of US-ASCII characters that conforms to the 502 "nodeid" rule (if any), using the "@" character as a separator 503 4. a string of US-ASCII characters that conforms to the "host" rule 504 5. optionally a string of US-ASCII characters that conforms to the 505 "resid" rule (if any), using the "/" character as a separator 506 6. optionally the query component (if any), using the "?" character 507 as a separator 508 7. optionally the fragment identifier component (if any), using the 509 "#" character as a separator 511 In order to reconstruct the XMPP address from the foregoing 512 components, the processing application MUST: 514 o Transform the string of US-ASCII characters that conforms to the 515 "nodeid" rule into an XMPP "node identifier" by converting each 516 sequence of percent-encoded octets into the appropriate sequence 517 of reserved or non-US-ASCII octets by (1) decoding percent-encoded 518 octets into actual octets, (2) interpreting the octets as [UTF-8], 519 and (3) applying the Nodeprep profile of [STRINGPREP] as specified 520 in Appendix A of [XMPP-CORE]. 521 o Transform the string of US-ASCII characters that conforms to the 522 "host" rule into an XMPP "domain identifier" by converting each 523 sequence of percent-encoded octets into the appropriate sequence 524 of reserved or non-US-ASCII octets by (1) decoding percent-encoded 525 octets into actual octets, (2) interpreting the octets as [UTF-8], 526 and (3) applying the [NAMEPREP] profile of [STRINGPREP]. 527 o Transform the string of US-ASCII characters that conforms to the 528 "resid" rule into an XMPP "resource identifier" by converting each 529 sequence of percent-encoded octets into the appropriate sequence 530 of reserved or non-US-ASCII octets by (1) decoding percent-encoded 531 octets into actual octets, (2) interpreting the octets as [UTF-8], 532 and (3) applying the Resourceprep profile of [STRINGPREP] as 533 specified in Appendix B of [XMPP-CORE]. 534 o Concatenate the following (ensuring that the resulting string is 535 encoded as [UTF-8]): 536 1. the XMPP "node identifier" and the "@" character (if a string 537 of US-ASCII characters that conforms to the "nodeid" rule was 538 included) 539 2. the XMPP "domain identifier" 540 3. the "/" character and XMPP "resource identifier" (if a string 541 of US-ASCII characters that conforms to the "resid" rule was 542 included) 544 At this point, the processing application would either (1) complete 545 further XMPP handling itself or (2) invoke a helper application to 546 complete XMPP handling; such XMPP handling would most likely consist 547 of the following steps: 549 1. Authenticating either as the user specified in the authority 550 component or as the configured user at the configured XMPP server 551 if not already so authenticated. 553 2. Optionally determining the nature of the intended recipient 554 (e.g., via [JEP-0030]). 555 3. Optionally presenting an appropriate interface to a user based on 556 the nature of the intended recipient and/or the contents of the 557 query component. 558 4. Generating an XMPP stanza that translates any user or application 559 inputs into their corresponding XMPP equivalents. 560 5. Sending the XMPP stanza via the authenticated server connection 561 for delivery to the intended recipient. 563 Note: It may help implementors to note that the first two steps of 564 the "further XMPP handling" are similar to HTTP authentication 565 ([HTTP-AUTH]), while the next three steps are similar to the handling 566 of mailto: URIs ([MAILTO]). 568 2.8.2 URI Processing Example 570 Consider the XMPP URI that resulted from the previous example: 572 574 In accordance with the process specified above, the processing 575 application would do the following to extract the XMPP address from 576 this XMPP URI: 578 1. Split the URI into a string of US-ASCII characters that conforms 579 to the "nodeid" rule ("ji%C5%99i"), a string of US-ASCII 580 characters that conforms to the "host" rule 581 ("%C4%8Cechy.example"), and a string of US-ASCII characters that 582 conforms to the "resid" rule ("v%20Praze"). 583 2. Transform the string of US-ASCII characters that conforms to the 584 "nodeid" rule into an XMPP "node identifier" by converting the 585 percent-encoded representation "%C5%99" to its equivalent [UTF-8] 586 character (LATIN SMALL LETTER R WITH CARON), making sure that the 587 entire string is encoded as [UTF-8]; the result is an XMPP "node 588 identifier" of "jiři". 589 3. Transform the string of US-ASCII characters that conforms to the 590 "host" rule into an XMPP "domain identifier" by converting the 591 US-ASCII string to [UTF-8] and converting the percent-encoded 592 representation "%C4%8C" to its equivalent [UTF-8] character 593 (LATIN SMALL LETTER C WITH CARON), making sure that the entire 594 string is encoded as [UTF-8]; the result is an XMPP "domain 595 identifier" of "čechy.example" (encoded as a [UTF-8] 596 string). 597 4. Transform the string of US-ASCII characters that conforms to the 598 "resid" rule into an XMPP "resource identifier" by converting the 599 percent-encoded representation "%20" to its equivalent [UTF-8] 600 character (SP), making sure that the entire string is encoded as 602 [UTF-8]; the result is an XMPP "resource identifier" of "v 603 Praze". 604 5. Concatenate the following (ensuring that the resulting string is 605 encoded as [UTF-8]): 606 1. the XMPP "node identifier" and the "@" character 607 2. the XMPP "domain identifier" 608 3. the "/" character and the XMPP "resource identifier" 610 The result is this XMPP address: 612 614 2.9 Internationalization 616 Because XMPP addresses are [UTF-8] strings and because the 617 non-US-ASCII octets in XMPP addresses can be easily converted to 618 percent-encoded octets, XMPP addresses are designed to work well with 619 Internationalized Resource Identifiers ([IRI]). In particular, with 620 the exception of stringprep verification and the conversion of 621 syntax-relevant US-ASCII characters (e.g., "?"), an XMPP IRI can be 622 constructed directly by prepending "xmpp:" to an XMPP address. 624 3. IANA Registration of xmpp: URI Scheme 626 This section provides the information required to register the xmpp: 627 URI scheme. 629 3.1 URI scheme name 631 xmpp 633 3.2 URI scheme syntax 635 The syntax for an xmpp: URI is defined below using Augmented 636 Backus-Naur Form as specified by [ABNF]. The "fragment", "host", 637 "pct-encoded", "query", "sub-delims", and "unreserved" rules are 638 defined in [URI]. 640 xmppuri = "xmpp:" hier-xmpp [ "?" querycomp ] [ "#" fragment ] 641 hier-xmpp = authpath / path-xmpp 642 authpath = "//" auth-xmpp [ "/" path-xmpp ] 643 auth-xmpp = nodeid "@" host 644 path-xmpp = [ nodeid "@" ] host [ "/" resid ] 645 nodeid = *( unreserved / pct-encoded / nodeallow ) 646 nodeallow = "!" / "$" / "%" / "(" / ")" / "*" / "+" / "," 647 / ";" / "=" / "^" / "`" / "{" / "|" / "}" 648 resid = *( unreserved / pct-encoded / sub-delims ) 649 querycomp = querytype [ *pair ] 650 querytype = *( ALPHA / DIGIT / '-' / '_' / '.' / ':' ) 651 pair = "&" key "=" value 652 key = *unreserved 653 value = *( unreserved / pct-encoded ) 655 3.3 Character encoding considerations 657 Prior to any conversion into a URI and in accordance with 658 [XMPP-CORE], an Extensible Messaging and Presence Protocol (XMPP) 659 address MUST be represented as [UTF-8] by the generating application 660 (e.g., by transforming an application's internal representation of 661 the address as a UTF-16 string into a UTF-8 string). The UTF-8 662 string MUST then be converted into a US-ASCII string in order to be 663 included in a URI; as part of this conversion, non-US-ASCII octets 664 MUST be percent-encoded as described in Section 2.1 of [URI]. 666 3.4 Intended usage 668 The xmpp: URI identifies entities that natively communicate using the 669 Extensible Messaging and Presence Protocol (XMPP), and is mainly used 670 for identification rather than processing. However, an application 671 that processes an xmpp: URI SHOULD reconstruct the encapsulated XMPP 672 address, authenticate with the appropriate XMPP server, and send an 673 appropriate XMPP "stanza" (XML fragment) to the XMPP address. There 674 is no MIME type associated with this URI. 676 3.5 Applications and/or protocols which use this URL scheme name 678 The xmpp: URI is intended to be used by interfaces to an XMPP network 679 from non-native user agents such as web browsers, as well as by 680 non-native applications that need to identify XMPP entities as full 681 URIs. 683 3.6 Security considerations 685 See Security Considerations (Section 5) of XXXX. 687 3.7 Relevant publications 689 [XMPP-CORE] 691 3.8 Person and email address to contact for further information 693 Peter Saint-Andre [mailto:stpeter@jabber.org] 695 3.9 Author/change controller 697 This scheme is registered under the IETF tree. As such, the IETF 698 maintains change control. 700 4. IANA Considerations 702 This document registers a URI scheme. The registration template can 703 be found in Section 3 of this document. 705 5. Security Considerations 707 Detailed security considerations for Uniform Resource Identifiers are 708 given in [URI], and for the Extensible Messaging and Presence 709 Protocol in [XMPP-CORE]. Providing an interface to XMPP services 710 from non-native applications introduces new security concerns. For 711 example, the ability to interact with XMPP entities via a web browser 712 may expose sensitive information to attacks that are not possible or 713 that are unlikely on a native XMPP network. Due care must be taken 714 in deciding what information is appropriate for representation in 715 XMPP URIs. Care must also be taken in exposing XMPP addresses in the 716 authority and path components of XMPP URIs that are publicly 717 accessible. 719 6. References 721 6.1 Normative References 723 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 724 Specifications: ABNF", RFC 2234, November 1997. 726 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 727 Requirement Levels", BCP 14, RFC 2119, March 1997. 729 [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 730 Resource Identifier (URI): Generic Syntax", 731 draft-fielding-uri-rfc2396bis-07 (work in progress), 732 September 2004. 734 [URL-GUIDE] 735 Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke, 736 "Guidelines for new URL Schemes", RFC 2718, November 1999. 738 [URL-REG] Petke, R. and I. King, "Registration Procedures for URL 739 Scheme Names", BCP 35, RFC 2717, November 1999. 741 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 742 10646", STD 63, RFC 3629, November 2003. 744 [XMPP-CORE] 745 Saint-Andre, P., "Extensible Messaging and Presence 746 Protocol (XMPP): Core", RFC 3920, October 2004. 748 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 749 Protocol (XMPP): Instant Messaging and Presence", RFC 750 3921, October 2004. 752 6.2 Informative References 754 [CPIM] Peterson, J., "Common Profile for Instant Messaging 755 (CPIM)", RFC 3860, August 2004. 757 [CPP] Peterson, J., "Common Profile for Presence (CPP)", RFC 758 3859, August 2004. 760 [HTML] Raggett, D., "HTML 4.0 Specification", W3C REC 761 REC-html40-19980424, April 1998. 763 [HTTP-AUTH] 764 Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 765 Leach, P., Luotonen, A. and L. Stewart, "HTTP 766 Authentication: Basic and Digest Access Authentication", 767 RFC 2617, June 1999. 769 [IDNA] Faltstrom, P., Hoffman, P. and A. Costello, 770 "Internationalizing Domain Names in Applications (IDNA)", 771 RFC 3490, March 2003. 773 [IMP-MODEL] 774 Day, M., Rosenberg, J. and H. Sugano, "A Model for 775 Presence and Instant Messaging", RFC 2778, February 2000. 777 [IMP-REQS] 778 Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 779 Presence Protocol Requirements", RFC 2779, February 2000. 781 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 782 Identifiers (IRIs)", draft-duerst-iri-11 (work in 783 progress), December 2004. 785 [JEP-0009] 786 Adams, D., "Jabber-RPC", JSF JEP 0009, December 2002. 788 [JEP-0030] 789 Hildebrand, J., Millard, P., Eatmon, R. and P. 790 Saint-Andre, "Service Discovery", JSF JEP 0030, July 2004. 792 [JEP-0045] 793 Saint-Andre, P., "Multi-User Chat", JSF JEP 0045, October 794 2004. 796 [JEP-0053] 797 Saint-Andre, P., "Jabber Registrar", JSF JEP 0053, May 798 2004. 800 [JEP-0060] 801 Millard, P., "Publish-Subscribe", JSF JEP 0060, July 2004. 803 [JEP-0072] 804 Forno, F., "SOAP Over XMPP", JSF JEP 0072, May 2004. 806 [JEP-0077] 807 Saint-Andre, P., "In-Band Registration", JSF JEP 0077, 808 August 2004. 810 [JEP-0147] 811 Saint-Andre, P., "XMPP URI Query Components", JSF JEP 812 0147, November 2004. 814 [MAILTO] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL 815 scheme", RFC 2368, July 1998. 817 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 818 Extensions (MIME) Part Two: Media Types", RFC 2046, 819 November 1996. 821 [NAMEPREP] 822 Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 823 Profile for Internationalized Domain Names (IDN)", RFC 824 3491, March 2003. 826 [STRINGPREP] 827 Hoffman, P. and M. Blanchet, "Preparation of 828 Internationalized Strings ("STRINGPREP")", RFC 3454, 829 December 2002. 831 [US-ASCII] 832 American National Standards Institute, "Coded Character 833 Set - 7-bit American Standard Code for Information 834 Interchange", ANSI X3.4, 1986. 836 Author's Address 838 Peter Saint-Andre 839 Jabber Software Foundation 841 EMail: stpeter@jabber.org 843 Intellectual Property Statement 845 The IETF takes no position regarding the validity or scope of any 846 Intellectual Property Rights or other rights that might be claimed to 847 pertain to the implementation or use of the technology described in 848 this document or the extent to which any license under such rights 849 might or might not be available; nor does it represent that it has 850 made any independent effort to identify any such rights. Information 851 on the procedures with respect to rights in RFC documents can be 852 found in BCP 78 and BCP 79. 854 Copies of IPR disclosures made to the IETF Secretariat and any 855 assurances of licenses to be made available, or the result of an 856 attempt made to obtain a general license or permission for the use of 857 such proprietary rights by implementers or users of this 858 specification can be obtained from the IETF on-line IPR repository at 859 http://www.ietf.org/ipr. 861 The IETF invites any interested party to bring to its attention any 862 copyrights, patents or patent applications, or other proprietary 863 rights that may cover technology that may be required to implement 864 this standard. Please address the information to the IETF at 865 ietf-ipr@ietf.org. 867 Disclaimer of Validity 869 This document and the information contained herein are provided on an 870 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 871 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 872 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 873 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 874 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 875 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 877 Copyright Statement 879 Copyright (C) The Internet Society (2004). This document is subject 880 to the rights, licenses and restrictions contained in BCP 78, and 881 except as set forth therein, the authors retain all their rights. 883 Acknowledgment 885 Funding for the RFC Editor function is currently provided by the 886 Internet Society.