idnits 2.17.1 draft-saintandre-xmpp-iri-03.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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 906. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 883. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 890. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 896. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 == 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 (November 29, 2005) is 6722 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 777, but no explicit reference was found in the text == Unused Reference: 'IMP-REQS' is defined on line 781, but no explicit reference was found in the text == Unused Reference: 'NAMEPREP' is defined on line 824, but no explicit reference was found in the text == Unused Reference: 'URL-GUIDE' is defined on line 848, but no explicit reference was found in the text == Unused Reference: 'URL-REG' is defined on line 852, but no explicit reference was found in the text == Unused Reference: 'US-ASCII' is defined on line 855, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3920 (ref. 'XMPP-CORE') (Obsoleted by RFC 6120) -- 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 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) -- Obsolete informational reference (is this intentional?): RFC 3454 (ref. 'STRINGPREP') (Obsoleted by RFC 7564) -- Obsolete informational reference (is this intentional?): RFC 2718 (ref. 'URL-GUIDE') (Obsoleted by RFC 4395) -- Obsolete informational reference (is this intentional?): RFC 2717 (ref. 'URL-REG') (Obsoleted by RFC 4395) -- Obsolete informational reference (is this intentional?): RFC 3921 (ref. 'XMPP-IM') (Obsoleted by RFC 6121) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft JSF 4 Expires: June 2, 2006 November 29, 2005 6 Internationalized Resource Identifiers (IRIs) and Uniform Resource 7 Identifiers (URIs) for the Extensible Messaging and Presence Protocol 8 (XMPP) 9 draft-saintandre-xmpp-iri-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 21 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 2, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document defines the use of Internationalized Resource 43 Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in 44 identifying or interacting with entities that can communicate via the 45 Extensible Messaging and Presence Protocol (XMPP). 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Use of XMPP IRIs and URIs . . . . . . . . . . . . . . . . . . 3 52 2.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.2 Form . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.3 Authority Component . . . . . . . . . . . . . . . . . . . 6 55 2.4 Path Component . . . . . . . . . . . . . . . . . . . . . . 7 56 2.5 Query Component . . . . . . . . . . . . . . . . . . . . . 7 57 2.6 Fragment Identifier Component . . . . . . . . . . . . . . 8 58 2.7 Generation of XMPP IRIs/URIs . . . . . . . . . . . . . . . 9 59 2.8 Processing of XMPP IRIs/URIs . . . . . . . . . . . . . . . 11 60 2.9 Internationalization . . . . . . . . . . . . . . . . . . . 14 61 3. IANA Registration of xmpp URI Scheme . . . . . . . . . . . . . 14 62 3.1 URI scheme name . . . . . . . . . . . . . . . . . . . . . 14 63 3.2 URI scheme syntax . . . . . . . . . . . . . . . . . . . . 14 64 3.3 Character encoding considerations . . . . . . . . . . . . 15 65 3.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . 15 66 3.5 Applications and/or protocols which use this scheme 67 name . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 3.6 Security considerations . . . . . . . . . . . . . . . . . 16 69 3.7 Relevant publications . . . . . . . . . . . . . . . . . . 16 70 3.8 Person and email address to contact for further 71 information . . . . . . . . . . . . . . . . . . . . . . . 16 72 3.9 Author/change controller . . . . . . . . . . . . . . . . . 16 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 6.1 Normative References . . . . . . . . . . . . . . . . . . . 17 77 6.2 Informative References . . . . . . . . . . . . . . . . . . 17 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 79 Intellectual Property and Copyright Statements . . . . . . . . 20 81 1. Introduction 83 The Extensible Messaging and Presence Protocol (XMPP) is a streaming 84 XML technology that enables any two entities on a network to exchange 85 well-defined but extensible XML elements (called "XML stanzas") in 86 close to real time. 88 As specified in [XMPP-CORE], entity addresses as used in 89 communications over an XMPP network must not be prepended with a 90 Uniform Resource Identifier (URI) scheme (as specified in [URI]). 91 However, applications external to an XMPP network may need to 92 identify XMPP entities either as URIs or, in a more modern fashion, 93 as Internationalized Resource Identifiers (IRIs; see [IRI]). 94 Examples of such external applications include databases that need to 95 store XMPP addresses and non-native user agents such as web browsers 96 and calendaring applications that provide interfaces to XMPP 97 services. 99 The format for an XMPP address is defined in [XMPP-CORE]. Such an 100 address may contain nearly any [UNICODE] character and must adhere to 101 various profiles of [STRINGPREP]. The result is that an XMPP address 102 is fully internationalizable and is very close to being an IRI 103 without a scheme. However, given that there is no freestanding 104 registry of IRI schemes, it is necessary to define XMPP identifiers 105 primarily as URIs rather than as IRIs, and to register an xmpp URI 106 scheme rather than an IRI scheme. Therefore this document does the 107 following: 109 o Specifies how to identify XMPP entities as IRIs or URIs. 110 o Specifies how to interact with XMPP entities as IRIs or URIs. 111 o Formally defines the syntax for XMPP IRIs and URIs. 112 o Specifies how to transform XMPP IRIs into URIs and vice-versa. 113 o Registers the xmpp URI scheme. 115 1.1 Terminology 117 This document inherits terminology from [IRI], [URI], and [XMPP- 118 CORE]. 120 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 121 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in RFC 123 2119 [TERMS]. 125 2. Use of XMPP IRIs and URIs 126 2.1 Rationale 128 As described in [XMPP-IM], instant messaging and presence 129 applications of XMPP must handle im: and pres: URIs (as specified by 130 [CPIM] and [CPP]). However, there are many other applications of 131 XMPP (including network management, workflow systems, generic 132 publish-subscribe, remote procedure calls, content syndication, 133 gaming, and middleware), and these applications do not implement 134 instant messaging and presence semantics. Neither does a generic 135 XMPP entity implement the semantics of any existing URI scheme, such 136 as the http:, ftp:, or mailto: scheme. Therefore, it is appropriate 137 to define a new URI scheme that makes it possible to identify or 138 interact with any XMPP entity (not just instant messaging and 139 presence entities) as an IRI or URI. 141 XMPP IRIs and URIs are defined for use by non-native interfaces and 142 applications, and primarily for the purpose of identification rather 143 than interaction (on the latter distinction, see Section 1.2.2 of 144 [URI]). In order to ensure interoperability on XMPP networks, when 145 data is routed to an XMPP entity (e.g., when an XMPP address is 146 contained in the 'to' or 'from' attribute of an XML stanza) or an 147 XMPP entity is otherwise identified in standard XMPP protocol 148 elements, the entity MUST be addressed as <[node@]domain[/resource]> 149 (i.e., without a prepended scheme), where the "node identifier", 150 "domain identifier", and "resource identifier" portions of an XMPP 151 address conform to the definitions provided in Section 3 of [XMPP- 152 CORE]. 154 (Note: For historical reasons, the term "resource identifier" is used 155 in XMPP to refer to the optional portion of an XMPP address that 156 follows the domain identifier and the "/" separator character (for 157 details, refer to Section 3.4 of [XMPP-CORE]); this use of the term 158 "resource identifier" is not to be confused with the meanings of 159 "resource" and "identifier" provided in Section 1.1 of [URI].) 161 2.2 Form 163 As described in [XMPP-CORE], an XMPP address used natively on an XMPP 164 network is a string of Unicode characters that (1) conforms to a 165 certain set of [STRINGPREP] profiles and [IDNA] restrictions, (2) 166 follows a certain set of syntax rules, and (3) is encoded as [UTF-8]. 167 The form of such an address can be represented using Augmented 168 Backus-Naur Form ([ABNF]) as: 170 [ node "@" ] domain [ "/" resource ] 172 In this context, the "node" and "resource" rules rely on distinct 173 profiles of [STRINGPREP] and the "domain" rule relies on the concept 174 of an internationalized domain name as described in [IDNA]. (Note: 175 there is no need to refer to punycode in the IRI syntax itself, since 176 any punycode representation would occur only inside an XMPP 177 application in order to represent internationalized domain names; 178 however, it is the responsibility of the processing application to 179 convert [IRI] syntax into [IDNA] syntax before addressing XML stanzas 180 to the specified entity on an XMPP network). 182 Naturally, in order to be converted into an IRI or URI, an XMPP 183 address must be prepended with a scheme (specifically the xmpp 184 scheme) and may also need to undergo transformations that adhere to 185 the rules defined in [IRI] and [URI]. Furthermore, in order to 186 enable more advanced interaction with an XMPP entity rather than 187 simple identification, it is desirable to take advantage of 188 additional aspects of URI syntax and semantics, such as authority 189 components, query components, and fragment identifier components. 191 Therefore, the ABNF syntax for an XMPP IRI is defined as shown below 192 using Augmented Backus-Naur Form as specified by [ABNF], where the 193 "ifragment", "ihost", and "iunreserved" rules are defined in [IRI] 194 and the "pct-encoded" rule is defined in [URI]: 196 xmppiri = "xmpp" ":" ihierxmpp 197 [ "?" iquerycomp ] 198 [ "#" ifragment ] 199 ihierxmpp = iauthpath / ipathxmpp 200 iauthpath = "//" iauthxmpp [ "/" ipathxmpp ] 201 iauthxmpp = inodeid "@" ihost 202 ipathxmpp = [ inodeid "@" ] ihost [ "/" iresid ] 203 inodeid = *( iunreserved / pct-encoded / nodeallow ) 204 nodeallow = "!" / "$" / "(" / ")" / "*" / "+" / "," / ";" / 205 "=" / "[" / "\" / "]" / "^" / "`" / "{" / "|" / 206 "}" 207 iresid = *( iunreserved / pct-encoded / resallow ) 208 resallow = "!" / '"' / "$" / "'" / "(" / ")" / "*" / "+" / 209 "," / ":" / ";" / "<" / "=" / ">" / "[" / "\" / 210 "]" / "^" / "`" / "{" / "|" / "}" 211 iquerycomp = iquerytype [ *ipair ] 212 iquerytype = *iunreserved 213 ipair = ";" ikey "=" ivalue 214 ikey = *iunreserved 215 ivalue = *( iunreserved / pct-encoded ) 217 However, the foregoing syntax is not appropriate for inclusion in the 218 registration of the xmpp URI scheme, since the IANA recognizes only 219 URI schemes rather than IRI schemes. Therefore, the ABNF syntax for 220 an XMPP URI rather than IRI is defined as shown in Section 3.2 221 section of this document (see below under "IANA Registration"). If 222 it is necessary to convert the IRI syntax into URI syntax, an 223 application MUST adhere to the mapping procedure specified in Section 224 3.1 of [IRI]. 226 The following is an example of a basic XMPP IRI/URI used for purposes 227 of identifying a node associated with an XMPP server: 229 xmpp:node@example.com 231 Descriptions of the various components of an XMPP IRI/URI are 232 provided in the following sections. 234 2.3 Authority Component 236 As explained in Section 2.8 of this document, in the absence of an 237 authority component the processing application would authenticate as 238 a configured user at a configured XMPP server. That is, the 239 authority component section is unnecessary and should be ignored if 240 the processing application has been configured with a set of default 241 credentials. 243 In accordance with Section 3.2 of RFC 3986, the authority component 244 is preceded by a double slash ("//") and is terminated by the next 245 slash ("/"), question mark ("?"), or number sign ("#") character, or 246 by the end of the IRI/URI. As explained more fully in Section 2.8.1 247 of this document, the presence of an authority component signals the 248 processing application to authenticate as the node@domain specified 249 in the authority component, rather than as a configured node@domain. 250 (While it is unlikely that the authority component will be included 251 in most XMPP IRIs or URIs, the scheme allows for its inclusion if 252 appropriate.) Thus, the following XMPP IRI/URI indicates to 253 authenticate as "guest@example.com": 255 xmpp://guest@example.com 257 Note well that this is quite different from the following XMPP IRI/ 258 URI, which identifies a node "guest@example.com" but does not signal 259 the processing application to authenticate as that node: 261 xmpp:guest@example.com 263 Similarly, using a possible query component of "?message" to trigger 264 an interface for sending a message, the following XMPP IRI/URI 265 signals the processing application to authenticate as 266 "guest@example.com" and send a message to "support@example.com": 268 xmpp://guest@example.com/support@example.com?message 270 By contrast, the following XMPP IRI/URI signals the processing 271 application to authenticate as its configured default account and 272 send a message to "support@example.com": 274 xmpp:support@example.com?message 276 2.4 Path Component 278 The path component of an XMPP IRI/URI identifies an XMPP address or 279 specifies the XMPP address to which an XML stanza shall be directed 280 at the end of IRI/URI processing. 282 For example, the following XMPP IRI/URI identifies a node associated 283 with an XMPP server: 285 xmpp:example-node@example.com 287 The following XMPP IRI/URI identifies a node associated with an XMPP 288 server along with a particular XMPP resource identifier associated 289 with that node: 291 xmpp:example-node@example.com/some-resource 293 Inclusion of a node is optional in XMPP addresses, so that the 294 following XMPP IRI/URI simply identifies an XMPP server: 296 xmpp:example.com 298 2.5 Query Component 300 There are many potential use cases for encapsulating information in 301 the query component of an XMPP IRI/URI; examples include but are not 302 limited to: 304 o Sending an XMPP message stanza (see [XMPP-IM]). 305 o Adding a roster item (see [XMPP-IM]). 306 o Sending a presence subscription (see [XMPP-IM]). 307 o Probing for current presence information (see [XMPP-IM]). 308 o Triggering a remote procedure call (see [JEP-0009]). 309 o Discovering the identity or capabilities of another entity (see 310 [JEP-0030]). 311 o Joining an XMPP-based text chat room (see [JEP-0045]). 312 o Interacting with publish-subscribe channels (see [JEP-0060]). 313 o Providing a SOAP interface (see [JEP-0072]). 315 o Registering with another entity (see [JEP-0077]). 317 Many of these potential use cases are application-specific, and the 318 full range of such applications cannot be foreseen in advance given 319 the continued expansion in XMPP development; however, there is 320 agreement within the Jabber/XMPP developer community that all of the 321 uses envisioned to date can be encapsulated via a "query type", 322 optionally supplemented by one or more "key-value" pairs (this is 323 similar to the "application/x-www-form-urlencoded" MIME type 324 described in [HTML]). 326 As an example, an XMPP IRI/URI intended to launch an interface for 327 sending a message to the XMPP entity "example-node@example.com" might 328 be represented as follows: 330 xmpp:example-node@example.com?message 332 Similarly, an XMPP IRI/URI intended to launch an interface for 333 sending a message to the XMPP entity "example-node@example.com" with 334 a particular subject might be represented as follows: 336 xmpp:example-node@example.com?message;subject=Hello%20World 338 If included in an XMPP IRI, the query component MUST first be encoded 339 as a [UTF-8] string and then (if necessary) transformed to conform to 340 the "iquerycomp" rule specified above; if included in an XMPP URI, 341 the query component MUST be transformed to conform to the "querycomp" 342 rule specified in Section 3.2 of this document. 344 If the processing application does not understand query components, 345 it MUST ignore the query component and treat the IRI/URI as 346 consisting of, for example, rather 347 than . If the processing 348 application does not understand a particular key within the query 349 component, it MUST ignore that key and its associated value. 351 (Note: In pursuit of interoperability, it may be helpful to maintain 352 a registry of query types and perhaps even of keys for use in XMPP 353 query components. Given that such values will most likely be 354 specific to particular applications of XMPP rather than core to XMPP 355 itself, it seems reasonable that such a registry, if created, would 356 be maintained by the Jabber Registrar function of the Jabber Software 357 Foundation as described in [JEP-0053], rather than by the IANA. A 358 proposal for creating such a registry can be found in [JEP-0147].) 360 2.6 Fragment Identifier Component 362 As stated in Section 3.5 of [URI], "The fragment identifier component 363 of a URI allows indirect identification of a secondary resource by 364 reference to a primary resource and additional identifying 365 information." Because the resource identified by an XMPP IRI/URI 366 does not make available any media type (see [MIME]) and therefore (in 367 the terminology of [URI]) no representation exists at an XMPP 368 resource, the semantics of the fragment identifier component in XMPP 369 IRIs/URIs are to be "considered unknown and, effectively, 370 unconstrained" (ibid.). Particular XMPP applications MAY make use of 371 the fragment identifier component for their own purposes. However, 372 if a processing application does not understand fragment identifier 373 components or the syntax of a particular fragment identifier 374 component included in an XMPP IRI/URI, it MUST ignore the fragment 375 identifier component. 377 If included in an XMPP IRI, the fragment identifier component MUST 378 first be encoded as a [UTF-8] string and then (if necessary) 379 transformed to conform to the "ifragment" rule defined in [IRI]; if 380 included in an XMPP URI, the fragment identifier component MUST be 381 transformed to conform to the "fragment" rule defined in [URI]. 383 2.7 Generation of XMPP IRIs/URIs 385 2.7.1 Generation Method 387 In order to form an XMPP IRI from an XMPP node identifier, domain 388 identifier, and resource identifier, the generating application MUST 389 concatenate: 391 1. the "xmpp" scheme and the ":" character 392 2. optionally (if an authority component is to be included before 393 the node identifier), the characters "//", an authority component 394 of the form node@domain, and the character "/" 395 3. optionally (if the XMPP address contained an XMPP "node 396 identifier"), a string of Unicode characters that conforms to the 397 "inodeid" rule, followed by the "@" character 398 4. a string of Unicode characters that conforms to the "ihost" rule 399 5. optionally (if the XMPP address contained an XMPP "resource 400 identifier"), the character "/" and a string of Unicode 401 characters that conforms to the "iresid" rule 402 6. optionally (if a query component is to be included), the "?" 403 character and query component 404 7. optionally (if a fragment identifier component is to be 405 included), the "#" character and fragment identifier component 407 In order to form an XMPP URI from the resulting IRI, an application 408 MUST adhere to the mapping procedure specified in Section 3.1 of 409 [IRI]. 411 2.7.2 Generation Notes 413 Certain characters are allowed in the node identifier, domain 414 identifier, and resource identifier portions of a native XMPP address 415 but prohibited by the "inodeid", "ihost", and "iresid" rules of an 416 XMPP IRI. Specifically, the "#" and "?" characters are allowed in 417 node identifiers and the "/", "?", "#", and "@" characters are 418 allowed in resource identifiers, but these characters are used as 419 delimiters in XMPP IRIs; in addition, the " " (US-ASCII space) 420 character is allowed in resource identifiers but prohibited in IRIs. 421 Therefore, all of the foregoing characters MUST be percent-encoded 422 when transforming an XMPP address into an XMPP IRI. 424 Consider the following nasty node in an XMPP address: 426 nasty!#$%()*+,-.;=?[\]^_`{|}~node@example.com 428 That address would be transformed into the following XMPP IRI: 430 xmpp:nasty!%23$%()*+,-.;=%3F[\]^_`{|}~node@example.com 432 Consider the following repulsive resource in an XMPP address (split 433 into two lines for layout purposes): 435 node@example.com 436 /repulsive !#"$%&'()*+,-./:;<=>?@[\]^_`{|}~resource 438 That address would be transformed into the following XMPP IRI (split 439 into two lines for layout purposes): 441 xmpp:node@example.com 442 /repulsive%20!%23"$%&'()*+,-.%2F:;<=>%3F%40[\]^_`{|}~resource 444 Furthermore, virtually any non-US-ASCII character is allowed in an 445 XMPP address and therefore also in an XMPP IRI, but URI syntax 446 forbids such characters directly and specifies that such characters 447 MUST be percent-encoded. In order to determine the URI associated 448 with an XMPP IRI, an application MUST adhere to the mapping procedure 449 specified in Section 3.1 of [IRI]. 451 2.7.3 Generation Example 453 Consider the following XMPP address: 455 457 (Note: The string "ř" stands for the Unicode character LATIN 458 SMALL LETTER R WITH CARON and the string "č" stands for the 459 Unicode character LATIN SMALL LETTER C WITH CARON, following the "XML 460 Notation" used in [IRI] to represent characters that cannot be 461 rendered in ASCII-only documents (note also that these characters are 462 represented in their stringprep canonical form). The '<' and '>' 463 characters are not part of the address itself, but are provided to 464 set off the address for legibility. For those who do not read Czech, 465 this example could be Anglicized as "george@czech-lands.example/In 466 Prague".) 468 In accordance with the process specified above, the generating 469 application would do the following to generate a valid XMPP IRI from 470 this address: 472 1. Ensure that the XMPP address conforms to the rules specified in 473 [XMPP-CORE], including application of the relevant [STRINGPREP] 474 profiles and encoding as a [UTF-8] string. 475 2. Concatenate the following: 476 1. the "xmpp" scheme and the ":" character 477 2. an "authority component" if included (not shown in this 478 example) 479 3. a string of Unicode characters that represents the XMPP 480 address, transformed in accordance with the "inodeid", 481 "ihost", and "iresid" rules 482 4. the "?" character followed by a "query component" if 483 appropriate to the application (not shown in this example) 484 5. the "#" character followed by a "fragment identifier 485 component" if appropriate to the application (not shown in 486 this example) 488 The result is this XMPP IRI: 490 492 In order to generate a valid XMPP URI from the foregoing IRI, the 493 application MUST adhere to the procedure specified in Section 3.1 of 494 [IRI], resulting in the following URI: 496 498 2.8 Processing of XMPP IRIs/URIs 500 2.8.1 Processing Method 502 If a processing application is presented with an XMPP URI rather than 503 an XMPP IRI, it MUST first convert the URI into an IRI by following 504 the procedure specified in Section 3.2 of [IRI]. 506 In order to decompose an XMPP IRI for interaction with the entity it 507 identifies, a processing application MUST separate: 509 1. the "xmpp" scheme and the ":" character 510 2. the authority component if included (the string of Unicode 511 characters between the "//" characters and the next "/" 512 character, the "?" character, the "#" character, or the end of 513 the IRI) 514 3. a string of Unicode characters that represents an XMPP address as 515 transformed in accordance with the "inodeid", "ihost", and 516 "iresid" rules 517 4. optionally the query component if included, using the "?" 518 character as a separator 519 5. optionally the fragment identifier component if included, using 520 the "#" character as a separator 522 At this point, the processing application would either (1) complete 523 further XMPP handling itself or (2) invoke a helper application to 524 complete XMPP handling; such XMPP handling would most likely consist 525 of the following steps: 527 1. If not already connected to an XMPP server, connecting either as 528 the user specified in the authority component or as the 529 configured user at the configured XMPP server, normally by 530 adhering to the XMPP connection procedures defined in [XMPP- 531 CORE]. (Note: the processing application SHOULD ignore the 532 authority component if it has been configured with a set of 533 default credentials.) 534 2. Optionally determining the nature of the intended recipient 535 (e.g., via [JEP-0030]). 536 3. Optionally presenting an appropriate interface to a user based on 537 the nature of the intended recipient and/or the contents of the 538 query component. 539 4. Generating an XMPP stanza that translates any user or application 540 inputs into their corresponding XMPP equivalents. 541 5. Sending the XMPP stanza via the authenticated server connection 542 for delivery to the intended recipient. 544 2.8.2 Processing Notes 546 It may help implementors to note that the first two steps of "further 547 XMPP handling" as described at the end of Section 2.8.1 are similar 548 to HTTP authentication ([HTTP-AUTH]), while the next three steps are 549 similar to the handling of mailto: URIs ([MAILTO]). 551 As noted in Section 2.7.2 of this document, certain characters are 552 allowed in the node identifier, domain identifier, and resource 553 identifier portions of a native XMPP address but prohibited by the 554 "inodeid", "ihost", and "iresid" rules of an XMPP IRI. The percent- 555 encoded octets corresponding to these characters in XMPP IRIs MUST be 556 transformed into the characters allowed in XMPP addresses when 557 processing an XMPP IRI for interaction with the represented XMPP 558 entity. 560 Consider the following nasty node in an XMPP IRI: 562 xmpp:nasty!%23$%()*+,-.;=%3F[\]^_`{|}~node@example.com 564 That IRI would be transformed into the following XMPP address: 566 nasty!#$%()*+,-.;=?[\]^_`{|}~node@example.com 568 Consider the following repulsive resource in an XMPP IRI (split into 569 two lines for layout purposes): 571 xmpp:node@example.com 572 /repulsive%20!%23"$%&'()*+,-.%2F:;<=>%3F%40[\]^_`{|}~resource 574 That IRI would be transformed into the following XMPP address (split 575 into two lines for layout purposes): 577 node@example.com 578 /repulsive !#"$%&'()*+,-./:;<=>?@[\]^_`{|}~resource 580 2.8.3 Processing Example 582 Consider the XMPP URI that resulted from the previous example: 584 586 In order to generate a valid XMPP IRI from that URI, the application 587 MUST adhere to the procedure specified in Section 3.2 of [IRI], 588 resulting in the following IRI: 590 592 In accordance with the process specified above, the processing 593 application would remove the "xmpp" scheme and ":" character to 594 extract the XMPP address from this XMPP IRI, converting any percent- 595 encoded octets from the "inodeid", "ihost", and "iresid" rules into 596 their character equivalents (e.g., "%20" into the space character). 598 The result is this XMPP address: 600 602 2.9 Internationalization 604 Because XMPP addresses are [UTF-8] strings and because the non-US- 605 ASCII octets in XMPP addresses can be easily converted to percent- 606 encoded octets, XMPP addresses are designed to work well with 607 Internationalized Resource Identifiers ([IRI]). In particular, with 608 the exception of stringprep verification, the conversion of syntax- 609 relevant US-ASCII characters (e.g., "?"), and the conversion of 610 percent-encoded octets from the "inodeid", "ihost", and "iresid" 611 rules into their character equivalents (e.g., "%20" into the US-ASCII 612 space character), an XMPP IRI can be constructed directly by 613 prepending the "xmpp" scheme and ":" character to an XMPP address. 614 Furthermore, an XMPP IRI can be converted into URI syntax by adhering 615 to the procedure specified in Section 3.1 of [IRI] and an XMPP URI 616 can be converted into IRI syntax by adhering to the procedure 617 specified in Section 3.2 of [IRI], thus ensuring interoperability 618 with applications that are able to process URIs but unable to process 619 IRIs. 621 3. IANA Registration of xmpp URI Scheme 623 This section provides the information required to register the xmpp 624 URI scheme. 626 3.1 URI scheme name 628 xmpp 630 3.2 URI scheme syntax 632 The syntax for an xmpp URI is defined below using Augmented Backus- 633 Naur Form as specified by [ABNF], where the "fragment", "host", "pct- 634 encoded", and "unreserved" rules are defined in [URI]: 636 xmppuri = "xmpp" ":" hierxmpp [ "?" querycomp ] [ "#" fragment ] 637 hierxmpp = authpath / pathxmpp 638 authpath = "//" authxmpp [ "/" pathxmpp ] 639 authxmpp = nodeid "@" host 640 pathxmpp = [ nodeid "@" ] host [ "/" resid ] 641 nodeid = *( unreserved / pct-encoded / nodeallow ) 642 nodeallow = "!" / "$" / "(" / ")" / "*" / "+" / "," / ";" / 643 "=" / "[" / "\" / "]" / "^" / "`" / "{" / "|" / 644 "}" 645 resid = *( unreserved / pct-encoded / resallow ) 646 resallow = "!" / '"' / "$" / "'" / "(" / ")" / "*" / "+" / 647 "," / ":" / ";" / "<" / "=" / ">" / "[" / "\" / 648 "]" / "^" / "`" / "{" / "|" / "}" 649 querycomp = querytype [ *pair ] 650 querytype = *( unreserved / pct-encoded ) 651 pair = ";" key "=" value 652 key = *( unreserved / pct-encoded ) 653 value = *( unreserved / pct-encoded ) 655 3.3 Character encoding considerations 657 In addition to XMPP URIs, there will also be XMPP Internationalized 658 Resource Identifiers (IRIs). Prior to converting an Extensible 659 Messaging and Presence Protocol (XMPP) address into an IRI (and in 660 accordance with [XMPP-CORE]), the XMPP address must be represented as 661 [UTF-8] by the generating application (e.g., by transforming an 662 application's internal representation of the address as a UTF-16 663 string into a UTF-8 string) and the UTF-8 string must then be 664 prepended with the "xmpp" scheme and ":" character. However, because 665 an XMPP URI must contain only US-ASCII characters, the UTF-8 string 666 of an XMPP IRI must be transformed into URI syntax by adhering to the 667 procedure specified in RFC 3987. 669 3.4 Intended usage 671 The xmpp URI scheme identifies entities that natively communicate 672 using the Extensible Messaging and Presence Protocol (XMPP), and is 673 mainly used for identification rather than processing. However, an 674 application that processes an xmpp URI SHOULD reconstruct the 675 encapsulated XMPP address, connect to the appropriate XMPP server, 676 and send an appropriate XMPP "stanza" (XML fragment) to the XMPP 677 address. There is no MIME type associated with the xmpp URI scheme. 679 3.5 Applications and/or protocols which use this scheme name 681 The xmpp URI scheme is intended to be used by interfaces to an XMPP 682 network from non-native user agents such as web browsers, as well as 683 by non-native applications that need to identify XMPP entities as 684 full URIs or IRIs. 686 3.6 Security considerations 688 See Security Considerations (Section 5) of XXXX. 690 3.7 Relevant publications 692 [XMPP-CORE] 694 3.8 Person and email address to contact for further information 696 Peter Saint-Andre [mailto:stpeter@jabber.org] 698 3.9 Author/change controller 700 This scheme is registered under the IETF tree. As such, the IETF 701 maintains change control. 703 4. IANA Considerations 705 This document registers a URI scheme. The registration template can 706 be found in Section 3 of this document. 708 5. Security Considerations 710 The security considerations discussed in [IRI], [URI], and [XMPP- 711 CORE] apply to XMPP IRIs, and the security considerations discussed 712 in [URI] and [XMPP-CORE] apply to XMPP URIs. 714 Providing an interface to XMPP services from non-native applications 715 introduces new security concerns. For example, the ability to 716 interact with XMPP entities via a web browser may expose sensitive 717 information to attacks that are not possible or that are unlikely on 718 a native XMPP network. Due care must be taken in deciding what 719 information is appropriate for representation in XMPP IRIs or URIs. 720 Care must also be taken in exposing XMPP addresses in the authority 721 and path components of XMPP IRIs or URIs that are publicly 722 accessible. 724 Advertising XMPP IRIs/URIs in publicly accessible locations (e.g., on 725 websites) may make it easier for malicious users to harvest XMPP 726 addresses and therefore to send unsolicited bulk communications to 727 the users or applications represented by those addresses. Care 728 should be taken in balancing the benefits of open information 729 exchange against the potential costs of unwanted communications. 731 Passwords and other user credentials are forbidden in the authority 732 component (and in fact are not needed since the use of [SASL] in XMPP 733 makes it possible to use the SASL ANONYMOUS mechanism if desired). 735 6. References 737 6.1 Normative References 739 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 740 Specifications: ABNF", RFC 2234, November 1997. 742 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 743 Identifiers (IRIs)", RFC 3987, January 2005. 745 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, March 1997. 748 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 749 Resource Identifier (URI): Generic Syntax", STD 66, 750 RFC 3986, January 2005. 752 [XMPP-CORE] 753 Saint-Andre, P., "Extensible Messaging and Presence 754 Protocol (XMPP): Core", RFC 3920, October 2004. 756 6.2 Informative References 758 [CPIM] Peterson, J., "Common Profile for Instant Messaging 759 (CPIM)", RFC 3860, August 2004. 761 [CPP] Peterson, J., "Common Profile for Presence (CPP)", 762 RFC 3859, August 2004. 764 [HTML] Raggett, D., "HTML 4.0 Specification", W3C REC REC-html40- 765 19980424, April 1998. 767 [HTTP-AUTH] 768 Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 769 Leach, P., Luotonen, A., and L. Stewart, "HTTP 770 Authentication: Basic and Digest Access Authentication", 771 RFC 2617, June 1999. 773 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, 774 "Internationalizing Domain Names in Applications (IDNA)", 775 RFC 3490, March 2003. 777 [IMP-MODEL] 778 Day, M., Rosenberg, J., and H. Sugano, "A Model for 779 Presence and Instant Messaging", RFC 2778, February 2000. 781 [IMP-REQS] 782 Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 783 / Presence Protocol Requirements", RFC 2779, 784 February 2000. 786 [JEP-0009] 787 Adams, D., "Jabber-RPC", JSF JEP 0009, December 2002. 789 [JEP-0030] 790 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 791 Andre, "Service Discovery", JSF JEP 0030, March 2005. 793 [JEP-0045] 794 Saint-Andre, P., "Multi-User Chat", JSF JEP 0045, 795 April 2005. 797 [JEP-0053] 798 Saint-Andre, P., "Jabber Registrar", JSF JEP 0053, 799 May 2004. 801 [JEP-0060] 802 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 803 Subscribe", JSF JEP 0060, March 2005. 805 [JEP-0072] 806 Forno, F. and P. Saint-Andre, "SOAP Over XMPP", JSF 807 JEP 0072, September 2005. 809 [JEP-0077] 810 Saint-Andre, P., "In-Band Registration", JSF JEP 0077, 811 July 2005. 813 [JEP-0147] 814 Saint-Andre, P., "XMPP IRI/URI Query Components", JSF 815 JEP 0147, September 2005. 817 [MAILTO] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto 818 URL scheme", RFC 2368, July 1998. 820 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 821 Extensions (MIME) Part Two: Media Types", RFC 2046, 822 November 1996. 824 [NAMEPREP] 825 Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 826 Profile for Internationalized Domain Names (IDN)", 827 RFC 3491, March 2003. 829 [SASL] Myers, J., "Simple Authentication and Security Layer 830 (SASL)", RFC 2222, October 1997. 832 [STRINGPREP] 833 Hoffman, P. and M. Blanchet, "Preparation of 834 Internationalized Strings ("STRINGPREP")", RFC 3454, 835 December 2002. 837 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 838 3.2.0", 2000. 840 The Unicode Standard, Version 3.2.0 is defined by The 841 Unicode Standard, Version 3.0 (Reading, MA, Addison- 842 Wesley, 2000. ISBN 0-201-61633-5), as amended by the 843 Unicode Standard Annex #27: Unicode 3.1 844 (http://www.unicode.org/reports/tr27/) and by the Unicode 845 Standard Annex #28: Unicode 3.2 846 (http://www.unicode.org/reports/tr28/). 848 [URL-GUIDE] 849 Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 850 "Guidelines for new URL Schemes", RFC 2718, November 1999. 852 [URL-REG] Petke, R. and I. King, "Registration Procedures for URL 853 Scheme Names", BCP 35, RFC 2717, November 1999. 855 [US-ASCII] 856 American National Standards Institute, "Coded Character 857 Set - 7-bit American Standard Code for Information 858 Interchange", ANSI X3.4, 1986. 860 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 861 10646", STD 63, RFC 3629, November 2003. 863 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 864 Protocol (XMPP): Instant Messaging and Presence", 865 RFC 3921, October 2004. 867 Author's Address 869 Peter Saint-Andre 870 Jabber Software Foundation 872 Email: stpeter@jabber.org 874 Intellectual Property Statement 876 The IETF takes no position regarding the validity or scope of any 877 Intellectual Property Rights or other rights that might be claimed to 878 pertain to the implementation or use of the technology described in 879 this document or the extent to which any license under such rights 880 might or might not be available; nor does it represent that it has 881 made any independent effort to identify any such rights. Information 882 on the procedures with respect to rights in RFC documents can be 883 found in BCP 78 and BCP 79. 885 Copies of IPR disclosures made to the IETF Secretariat and any 886 assurances of licenses to be made available, or the result of an 887 attempt made to obtain a general license or permission for the use of 888 such proprietary rights by implementers or users of this 889 specification can be obtained from the IETF on-line IPR repository at 890 http://www.ietf.org/ipr. 892 The IETF invites any interested party to bring to its attention any 893 copyrights, patents or patent applications, or other proprietary 894 rights that may cover technology that may be required to implement 895 this standard. Please address the information to the IETF at 896 ietf-ipr@ietf.org. 898 Disclaimer of Validity 900 This document and the information contained herein are provided on an 901 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 902 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 903 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 904 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 905 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 906 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 908 Copyright Statement 910 Copyright (C) The Internet Society (2005). This document is subject 911 to the rights, licenses and restrictions contained in BCP 78, and 912 except as set forth therein, the authors retain all their rights. 914 Acknowledgment 916 Funding for the RFC Editor function is currently provided by the 917 Internet Society.