idnits 2.17.1 draft-saintandre-xmpp-iri-04.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 1022. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 999. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1006. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1012. ** 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 (March 31, 2006) is 6601 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 894, but no explicit reference was found in the text == Unused Reference: 'IMP-REQS' is defined on line 898, but no explicit reference was found in the text == Unused Reference: 'NAMEPREP' is defined on line 941, but no explicit reference was found in the text == Unused Reference: 'US-ASCII' is defined on line 970, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** 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 4395 (ref. 'URI-SCHEMES') (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 3921 (ref. 'XMPP-IM') (Obsoleted by RFC 6121) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 15 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: October 2, 2006 March 31, 2006 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-04 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 October 2, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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 Status . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 3.3 URI scheme syntax . . . . . . . . . . . . . . . . . . . . 14 65 3.4 URI scheme semantics . . . . . . . . . . . . . . . . . . . 15 66 3.5 Encoding considerations . . . . . . . . . . . . . . . . . 15 67 3.6 Applications/protocols that use this URI scheme name . . . 16 68 3.7 Interoperability considerations . . . . . . . . . . . . . 16 69 3.8 Security considerations . . . . . . . . . . . . . . . . . 16 70 3.9 Contact . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 3.10 Author/change controller . . . . . . . . . . . . . . . . 16 72 3.11 References . . . . . . . . . . . . . . . . . . . . . . . 16 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 74 5. Security Considerations . . . . . . . . . . . . . . . . . . 16 75 5.1 Reliability and Consistency . . . . . . . . . . . . . . . 17 76 5.2 Malicious Construction . . . . . . . . . . . . . . . . . . 17 77 5.3 Back-End Transcoding . . . . . . . . . . . . . . . . . . . 18 78 5.4 Sensitive Information . . . . . . . . . . . . . . . . . . 18 79 5.5 Semantic Attacks . . . . . . . . . . . . . . . . . . . . . 18 80 5.6 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 6.1 Normative References . . . . . . . . . . . . . . . . . . . 19 83 6.2 Informative References . . . . . . . . . . . . . . . . . . 19 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . 22 85 Intellectual Property and Copyright Statements . . . . . . . 23 87 1. Introduction 89 The Extensible Messaging and Presence Protocol (XMPP) is a streaming 90 XML technology that enables any two entities on a network to exchange 91 well-defined but extensible XML elements (called "XML stanzas") in 92 close to real time. 94 As specified in [XMPP-CORE], entity addresses as used in 95 communications over an XMPP network must not be prepended with a 96 Uniform Resource Identifier (URI) scheme (as specified in [URI]). 97 However, applications external to an XMPP network may need to 98 identify XMPP entities either as URIs or, in a more modern fashion, 99 as Internationalized Resource Identifiers (IRIs; see [IRI]). 100 Examples of such external applications include databases that need to 101 store XMPP addresses and non-native user agents such as web browsers 102 and calendaring applications that provide interfaces to XMPP 103 services. 105 The format for an XMPP address is defined in [XMPP-CORE]. Such an 106 address may contain nearly any [UNICODE] character and must adhere to 107 various profiles of [STRINGPREP]. The result is that an XMPP address 108 is fully internationalizable and is very close to being an IRI 109 without a scheme. However, given that there is no freestanding 110 registry of IRI schemes, it is necessary to define XMPP identifiers 111 primarily as URIs rather than as IRIs, and to register an xmpp URI 112 scheme rather than an IRI scheme. Therefore this document does the 113 following: 115 o Specifies how to identify XMPP entities as IRIs or URIs. 116 o Specifies how to interact with XMPP entities as IRIs or URIs. 117 o Formally defines the syntax for XMPP IRIs and URIs. 118 o Specifies how to transform XMPP IRIs into URIs and vice-versa. 119 o Registers the xmpp URI scheme. 121 1.1 Terminology 123 This document inherits terminology from [IRI], [URI], and [XMPP- 124 CORE]. 126 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 127 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in RFC 129 2119 [TERMS]. 131 2. Use of XMPP IRIs and URIs 132 2.1 Rationale 134 As described in [XMPP-IM], instant messaging and presence 135 applications of XMPP must handle im: and pres: URIs (as specified by 136 [CPIM] and [CPP]). However, there are many other applications of 137 XMPP (including network management, workflow systems, generic 138 publish-subscribe, remote procedure calls, content syndication, 139 gaming, and middleware), and these applications do not implement 140 instant messaging and presence semantics. Neither does a generic 141 XMPP entity implement the semantics of any existing URI scheme, such 142 as the http:, ftp:, or mailto: scheme. Therefore, it is appropriate 143 to define a new URI scheme that makes it possible to identify or 144 interact with any XMPP entity (not just instant messaging and 145 presence entities) as an IRI or URI. 147 XMPP IRIs and URIs are defined for use by non-native interfaces and 148 applications, and primarily for the purpose of identification rather 149 than interaction (on the latter distinction, see Section 1.2.2 of 150 [URI]). In order to ensure interoperability on XMPP networks, when 151 data is routed to an XMPP entity (e.g., when an XMPP address is 152 contained in the 'to' or 'from' attribute of an XML stanza) or an 153 XMPP entity is otherwise identified in standard XMPP protocol 154 elements, the entity MUST be addressed as <[node@]domain[/resource]> 155 (i.e., without a prepended scheme), where the "node identifier", 156 "domain identifier", and "resource identifier" portions of an XMPP 157 address conform to the definitions provided in Section 3 of [XMPP- 158 CORE]. 160 (Note: For historical reasons, the term "resource identifier" is used 161 in XMPP to refer to the optional portion of an XMPP address that 162 follows the domain identifier and the "/" separator character (for 163 details, refer to Section 3.4 of [XMPP-CORE]); this use of the term 164 "resource identifier" is not to be confused with the meanings of 165 "resource" and "identifier" provided in Section 1.1 of [URI].) 167 2.2 Form 169 As described in [XMPP-CORE], an XMPP address used natively on an XMPP 170 network is a string of Unicode characters that (1) conforms to a 171 certain set of [STRINGPREP] profiles and [IDNA] restrictions, (2) 172 follows a certain set of syntax rules, and (3) is encoded as [UTF-8]. 173 The form of such an address can be represented using Augmented 174 Backus-Naur Form ([ABNF]) as: 176 [ node "@" ] domain [ "/" resource ] 178 In this context, the "node" and "resource" rules rely on distinct 179 profiles of [STRINGPREP] and the "domain" rule relies on the concept 180 of an internationalized domain name as described in [IDNA]. (Note: 181 there is no need to refer to punycode in the IRI syntax itself, since 182 any punycode representation would occur only inside an XMPP 183 application in order to represent internationalized domain names; 184 however, it is the responsibility of the processing application to 185 convert [IRI] syntax into [IDNA] syntax before addressing XML stanzas 186 to the specified entity on an XMPP network). 188 Naturally, in order to be converted into an IRI or URI, an XMPP 189 address must be prepended with a scheme (specifically the xmpp 190 scheme) and may also need to undergo transformations that adhere to 191 the rules defined in [IRI] and [URI]. Furthermore, in order to 192 enable more advanced interaction with an XMPP entity rather than 193 simple identification, it is desirable to take advantage of 194 additional aspects of URI syntax and semantics, such as authority 195 components, query components, and fragment identifier components. 197 Therefore, the ABNF syntax for an XMPP IRI is defined as shown below 198 using Augmented Backus-Naur Form as specified by [ABNF], where the 199 "ifragment", "ihost", and "iunreserved" rules are defined in [IRI], 200 the "pct-encoded" rule is defined in [URI], and DQUOTE is defined in 201 [ABNF]: 203 xmppiri = "xmpp" ":" ihierxmpp 204 [ "?" iquerycomp ] 205 [ "#" ifragment ] 206 ihierxmpp = iauthpath / ipathxmpp 207 iauthpath = "//" iauthxmpp [ "/" ipathxmpp ] 208 iauthxmpp = inodeid "@" ihost 209 ipathxmpp = [ inodeid "@" ] ihost [ "/" iresid ] 210 inodeid = *( iunreserved / pct-encoded / nodeallow ) 211 nodeallow = "!" / "$" / "(" / ")" / "*" / "+" / "," / ";" / 212 "=" / "[" / "\" / "]" / "^" / "`" / "{" / "|" / 213 "}" 214 iresid = *( iunreserved / pct-encoded / resallow ) 215 resallow = "!" / DQUOTE / "$" / "(" / ")" / "*" / "+" / 216 "," / ":" / ";" / "<" / "=" / ">" / "[" / 217 "\" / "]" / "^" / "`" / "{" / "|" / "}" 218 iquerycomp = iquerytype [ *ipair ] 219 iquerytype = *iunreserved 220 ipair = ";" ikey "=" ivalue 221 ikey = *iunreserved 222 ivalue = *( iunreserved / pct-encoded ) 224 However, the foregoing syntax is not appropriate for inclusion in the 225 registration of the xmpp URI scheme, since the IANA recognizes only 226 URI schemes rather than IRI schemes. Therefore, the ABNF syntax for 227 an XMPP URI rather than IRI is defined as shown in Section 3.3 228 section of this document (see below under "IANA Registration"). If 229 it is necessary to convert the IRI syntax into URI syntax, an 230 application MUST adhere to the mapping procedure specified in Section 231 3.1 of [IRI]. 233 The following is an example of a basic XMPP IRI/URI used for purposes 234 of identifying a node associated with an XMPP server: 236 xmpp:node@example.com 238 Descriptions of the various components of an XMPP IRI/URI are 239 provided in the following sections. 241 2.3 Authority Component 243 As explained in Section 2.8 of this document, in the absence of an 244 authority component the processing application would authenticate as 245 a configured user at a configured XMPP server. That is, the 246 authority component section is unnecessary and should be ignored if 247 the processing application has been configured with a set of default 248 credentials. 250 In accordance with Section 3.2 of RFC 3986, the authority component 251 is preceded by a double slash ("//") and is terminated by the next 252 slash ("/"), question mark ("?"), or number sign ("#") character, or 253 by the end of the IRI/URI. As explained more fully in Section 2.8.1 254 of this document, the presence of an authority component signals the 255 processing application to authenticate as the node@domain specified 256 in the authority component rather than as a configured node@domain 257 (see the Security Considerations section of this document regarding 258 authentication). (While it is unlikely that the authority component 259 will be included in most XMPP IRIs or URIs, the scheme allows for its 260 inclusion if appropriate.) Thus, the following XMPP IRI/URI 261 indicates to authenticate as "guest@example.com": 263 xmpp://guest@example.com 265 Note well that this is quite different from the following XMPP IRI/ 266 URI, which identifies a node "guest@example.com" but does not signal 267 the processing application to authenticate as that node: 269 xmpp:guest@example.com 271 Similarly, using a possible query component of "?message" to trigger 272 an interface for sending a message, the following XMPP IRI/URI 273 signals the processing application to authenticate as 274 "guest@example.com" and send a message to "support@example.com": 276 xmpp://guest@example.com/support@example.com?message 278 By contrast, the following XMPP IRI/URI signals the processing 279 application to authenticate as its configured default account and 280 send a message to "support@example.com": 282 xmpp:support@example.com?message 284 2.4 Path Component 286 The path component of an XMPP IRI/URI identifies an XMPP address or 287 specifies the XMPP address to which an XML stanza shall be directed 288 at the end of IRI/URI processing. 290 For example, the following XMPP IRI/URI identifies a node associated 291 with an XMPP server: 293 xmpp:example-node@example.com 295 The following XMPP IRI/URI identifies a node associated with an XMPP 296 server along with a particular XMPP resource identifier associated 297 with that node: 299 xmpp:example-node@example.com/some-resource 301 Inclusion of a node is optional in XMPP addresses, so that the 302 following XMPP IRI/URI simply identifies an XMPP server: 304 xmpp:example.com 306 2.5 Query Component 308 There are many potential use cases for encapsulating information in 309 the query component of an XMPP IRI/URI; examples include but are not 310 limited to: 312 o Sending an XMPP message stanza (see [XMPP-IM]). 313 o Adding a roster item (see [XMPP-IM]). 314 o Sending a presence subscription (see [XMPP-IM]). 315 o Probing for current presence information (see [XMPP-IM]). 316 o Triggering a remote procedure call (see [JEP-0009]). 317 o Discovering the identity or capabilities of another entity (see 318 [JEP-0030]). 319 o Joining an XMPP-based text chat room (see [JEP-0045]). 321 o Interacting with publish-subscribe channels (see [JEP-0060]). 322 o Providing a SOAP interface (see [JEP-0072]). 323 o Registering with another entity (see [JEP-0077]). 325 Many of these potential use cases are application-specific, and the 326 full range of such applications cannot be foreseen in advance given 327 the continued expansion in XMPP development; however, there is 328 agreement within the Jabber/XMPP developer community that all of the 329 uses envisioned to date can be encapsulated via a "query type", 330 optionally supplemented by one or more "key-value" pairs (this is 331 similar to the "application/x-www-form-urlencoded" MIME type 332 described in [HTML]). 334 As an example, an XMPP IRI/URI intended to launch an interface for 335 sending a message to the XMPP entity "example-node@example.com" might 336 be represented as follows: 338 xmpp:example-node@example.com?message 340 Similarly, an XMPP IRI/URI intended to launch an interface for 341 sending a message to the XMPP entity "example-node@example.com" with 342 a particular subject might be represented as follows: 344 xmpp:example-node@example.com?message;subject=Hello%20World 346 If the processing application does not understand query components or 347 the specified query type, it MUST ignore the query component and 348 treat the IRI/URI as consisting of, for example, 349 rather than 350 . If the processing application 351 does not understand a particular key within the query component, it 352 MUST ignore that key and its associated value. 354 As noted, there exist many kinds of XMPP applications (both actual 355 and potential), and such applications may define query types and keys 356 for use in the query component portion of XMPP URIs. The Jabber 357 Registrar function (see [JEP-0053]) of the Jabber Software Foundation 358 maintains a registry of such query types and keys at 359 . To help ensure 360 interoperability, any application using the formats defined in this 361 document SHOULD submit any associated query types and keys to that 362 registry in accordance with the procedures specified in [JEP-0147]. 364 2.6 Fragment Identifier Component 366 As stated in Section 3.5 of [URI], "The fragment identifier component 367 of a URI allows indirect identification of a secondary resource by 368 reference to a primary resource and additional identifying 369 information." Because the resource identified by an XMPP IRI/URI 370 does not make available any media type (see [MIME]) and therefore (in 371 the terminology of [URI]) no representation exists at an XMPP 372 resource, the semantics of the fragment identifier component in XMPP 373 IRIs/URIs are to be "considered unknown and, effectively, 374 unconstrained" (ibid.). Particular XMPP applications MAY make use of 375 the fragment identifier component for their own purposes. However, 376 if a processing application does not understand fragment identifier 377 components or the syntax of a particular fragment identifier 378 component included in an XMPP IRI/URI, it MUST ignore the fragment 379 identifier component. 381 2.7 Generation of XMPP IRIs/URIs 383 2.7.1 Generation Method 385 In order to form an XMPP IRI from an XMPP node identifier, domain 386 identifier, and resource identifier, the generating application MUST 387 first ensure that the XMPP address conforms to the rules specified in 388 [XMPP-CORE], including application of the relevant [STRINGPREP]; it 389 MUST then 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$%25()*+,-.;=%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"$%25&'()*+,-.%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 MUST ensure that the 523 resulting XMPP address conforms to the rules specified in [XMPP- 524 CORE], including application of the relevant [STRINGPREP]. The 525 processing application then would either (1) complete further XMPP 526 handling itself or (2) invoke a helper application to complete XMPP 527 handling; such XMPP handling would most likely consist of the 528 following steps: 530 1. If not already connected to an XMPP server, connecting either as 531 the user specified in the authority component or as the 532 configured user at the configured XMPP server, normally by 533 adhering to the XMPP connection procedures defined in [XMPP- 534 CORE]. (Note: the processing application SHOULD ignore the 535 authority component if it has been configured with a set of 536 default credentials.) 537 2. Optionally determining the nature of the intended recipient 538 (e.g., via [JEP-0030]). 539 3. Optionally presenting an appropriate interface to a user based on 540 the nature of the intended recipient and/or the contents of the 541 query component. 542 4. Generating an XMPP stanza that translates any user or application 543 inputs into their corresponding XMPP equivalents. 544 5. Sending the XMPP stanza via the authenticated server connection 545 for delivery to the intended recipient. 547 2.8.2 Processing Notes 549 It may help implementors to note that the first two steps of "further 550 XMPP handling" as described at the end of Section 2.8.1 are similar 551 to HTTP authentication ([HTTP-AUTH]), while the next three steps are 552 similar to the handling of mailto: URIs ([MAILTO]). 554 As noted in Section 2.7.2 of this document, certain characters are 555 allowed in the node identifier, domain identifier, and resource 556 identifier portions of a native XMPP address but prohibited by the 557 "inodeid", "ihost", and "iresid" rules of an XMPP IRI. The percent- 558 encoded octets corresponding to these characters in XMPP IRIs MUST be 559 transformed into the characters allowed in XMPP addresses when 560 processing an XMPP IRI for interaction with the represented XMPP 561 entity. 563 Consider the following nasty node in an XMPP IRI: 565 xmpp:nasty!%23$%()*+,-.;=%3F[\]^_`{|}~node@example.com 567 That IRI would be transformed into the following XMPP address: 569 nasty!#$%()*+,-.;=?[\]^_`{|}~node@example.com 571 Consider the following repulsive resource in an XMPP IRI (split into 572 two lines for layout purposes): 574 xmpp:node@example.com 575 /repulsive%20!%23"$%25&'()*+,-.%2F:;<=>%3F%40[\]^_`{|}~resource 577 That IRI would be transformed into the following XMPP address (split 578 into two lines for layout purposes): 580 node@example.com 581 /repulsive !#"$%&'()*+,-./:;<=>?@[\]^_`{|}~resource 583 2.8.3 Processing Example 585 Consider the XMPP URI that resulted from the previous example: 587 589 In order to generate a valid XMPP IRI from that URI, the application 590 MUST adhere to the procedure specified in Section 3.2 of [IRI], 591 resulting in the following IRI: 593 595 In accordance with the process specified above, the processing 596 application would remove the "xmpp" scheme and ":" character to 597 extract the XMPP address from this XMPP IRI, converting any percent- 598 encoded octets from the "inodeid", "ihost", and "iresid" rules into 599 their character equivalents (e.g., "%20" into the space character). 601 The result is this XMPP address: 603 605 2.9 Internationalization 607 Because XMPP addresses are [UTF-8] strings and because the non-US- 608 ASCII octets in XMPP addresses can be easily converted to percent- 609 encoded octets, XMPP addresses are designed to work well with 610 Internationalized Resource Identifiers ([IRI]). In particular, with 611 the exception of stringprep verification, the conversion of syntax- 612 relevant US-ASCII characters (e.g., "?"), and the conversion of 613 percent-encoded octets from the "inodeid", "ihost", and "iresid" 614 rules into their character equivalents (e.g., "%20" into the US-ASCII 615 space character), an XMPP IRI can be constructed directly by 616 prepending the "xmpp" scheme and ":" character to an XMPP address. 617 Furthermore, an XMPP IRI can be converted into URI syntax by adhering 618 to the procedure specified in Section 3.1 of [IRI] and an XMPP URI 619 can be converted into IRI syntax by adhering to the procedure 620 specified in Section 3.2 of [IRI], thus ensuring interoperability 621 with applications that are able to process URIs but unable to process 622 IRIs. 624 3. IANA Registration of xmpp URI Scheme 626 In accordance with [URI-SCHEMES], this section provides the 627 information required to register the xmpp URI scheme. 629 3.1 URI scheme name 631 xmpp 633 3.2 Status 635 permanent 637 3.3 URI scheme syntax 639 The syntax for an xmpp URI is defined below using Augmented Backus- 640 Naur Form as specified by [ABNF], where the "fragment", "host", "pct- 641 encoded", and "unreserved" rules are defined in [URI] and DQUOTE is 642 defined in [ABNF]: 644 xmppuri = "xmpp" ":" hierxmpp [ "?" querycomp ] [ "#" fragment ] 645 hierxmpp = authpath / pathxmpp 646 authpath = "//" authxmpp [ "/" pathxmpp ] 647 authxmpp = nodeid "@" host 648 pathxmpp = [ nodeid "@" ] host [ "/" resid ] 649 nodeid = *( unreserved / pct-encoded / nodeallow ) 650 nodeallow = "!" / "$" / "(" / ")" / "*" / "+" / "," / ";" / 651 "=" / "[" / "\" / "]" / "^" / "`" / "{" / "|" / 652 "}" 653 resid = *( unreserved / pct-encoded / resallow ) 654 resallow = "!" / DQUOTE / "$" / "(" / ")" / "*" / "+" / 655 "," / ":" / ";" / "<" / "=" / ">" / "[" / 656 "\" / "]" / "^" / "`" / "{" / "|" / "}" 657 querycomp = querytype [ *pair ] 658 querytype = *( unreserved / pct-encoded ) 659 pair = ";" key "=" value 660 key = *( unreserved / pct-encoded ) 661 value = *( unreserved / pct-encoded ) 663 3.4 URI scheme semantics 665 The xmpp URI scheme identifies entities that natively communicate 666 using the Extensible Messaging and Presence Protocol (XMPP), and is 667 mainly used for identification rather than resource location. 668 However, if an application that processes an xmpp URI enables 669 interaction with the XMPP address identified by the URI, it MUST 670 follow the methodology defined in the Use of XMPP IRIs and URIs 671 (Section 2) section of XXXX to reconstruct the encapsulated XMPP 672 address, connect to an appropriate XMPP server, and send an 673 appropriate XMPP "stanza" (XML fragment) to the XMPP address. (Note: 674 There is no MIME type associated with the xmpp URI scheme.) 676 3.5 Encoding considerations 678 In addition to XMPP URIs, there will also be XMPP Internationalized 679 Resource Identifiers (IRIs). Prior to converting an Extensible 680 Messaging and Presence Protocol (XMPP) address into an IRI (and in 681 accordance with [XMPP-CORE]), the XMPP address must be represented as 682 [UTF-8] by the generating application (e.g., by transforming an 683 application's internal representation of the address as a UTF-16 684 string into a UTF-8 string) and the UTF-8 string must then be 685 prepended with the "xmpp" scheme and ":" character. However, because 686 an XMPP URI must contain only US-ASCII characters, the UTF-8 string 687 of an XMPP IRI must be transformed into URI syntax by adhering to the 688 procedure specified in RFC 3987. 690 3.6 Applications/protocols that use this URI scheme name 692 The xmpp URI scheme is intended to be used by interfaces to an XMPP 693 network from non-native user agents such as web browsers, as well as 694 by non-native applications that need to identify XMPP entities as 695 full URIs or IRIs. 697 3.7 Interoperability considerations 699 There are no known interoperability concerns related to use of the 700 xmpp URI scheme. In order to help ensure interoperability, the 701 Jabber Registrar function of the Jabber Software Foundation maintains 702 a registry of query types and keys that can be used in the query 703 components of XMPP URIs and IRIs, located at 704 . 706 3.8 Security considerations 708 See the Security Considerations (Section 5) section of XXXX. 710 3.9 Contact 712 Peter Saint-Andre [mailto:stpeter@jabber.org, 713 xmpp:stpeter@jabber.org] 715 3.10 Author/change controller 717 This scheme is registered under the IETF tree. As such, the IETF 718 maintains change control. 720 3.11 References 722 [XMPP-CORE] 724 4. IANA Considerations 726 This document registers a URI scheme. The registration template can 727 be found in Section 3 of this document. In order to help ensure 728 interoperability, the Jabber Registrar function of the Jabber 729 Software Foundation maintains a registry of query types and keys that 730 can be used in the query components of XMPP URIs and IRIs, located at 731 . 733 5. Security Considerations 735 Providing an interface to XMPP services from non-native applications 736 introduces new security concerns. The security considerations 737 discussed in [IRI], [URI], and [XMPP-CORE] apply to XMPP IRIs, and 738 the security considerations discussed in [URI] and [XMPP-CORE] apply 739 to XMPP URIs. In accordance with Section 2.7 of [URI-SCHEMES] and 740 Section 7 of [URI], particular security considerations are specified 741 in the following sections. 743 5.1 Reliability and Consistency 745 Given that XMPP addresses of the form node@domain.tld are typically 746 created via registration at an XMPP server or provisioned by an 747 administrator of such a server, it is possible that such addresses 748 may also be unregistered or deprovisioned; therefore the XMPP IRI/URI 749 that identifies such an XMPP address may not reliably and 750 consistently be associated with the same principal, account owner, 751 application, or device. 753 XMPP addresses of the form node@domain.tld/resouce are typically even 754 more ephemeral (since a given XMPP resource identifier is typically 755 associated with a particular, temporary session of an XMPP client at 756 an XMPP server); therefore the XMPP IRI/URI that identifies such an 757 XMPP address probably will not reliably and consistently be 758 associated with the same session. However, the procedures specified 759 in Section 10 of [XMPP-CORE] effectively eliminate any potential 760 confusion that might be introduced by the lack of reliability and 761 consistency for the XMPP IRI/URI that identifies such an XMPP 762 address. 764 XMPP addresses of the form domain.tld are typically long-lived XMPP 765 servers or associated services; although naturally it is possible for 766 server or service administrators to de-commission the server or 767 service at any time, typically the IRIs/URIs that identify such 768 servers or services are the most reliable and consistent of XMPP 769 IRIs/URIs. 771 XMPP addresses of the form domain.tld/resource are not yet common on 772 XMPP networks; however, the reliability and consistency of XMPP IRIs/ 773 URIs that identify such XMPP addresses would likely fall somewhere 774 between those that identify XMPP addresses of the form domain.tld and 775 those that identify XMPP addresses of the form node@domain.tld. 777 5.2 Malicious Construction 779 Malicious construction of XMPP IRIs/URIs is made less likely by the 780 prohibition on port numbers in XMPP IRIs/URIs (since port numbers are 781 to be discovered using [DNS-SRV] records as specified in [XMPP- 782 CORE]). 784 5.3 Back-End Transcoding 786 Because the base XMPP protocol is designed to implement the exchange 787 of messages and presence information rather than the retrieval of 788 files or invocation of similar system functions, it is deemed 789 unlikely that the use of XMPP IRIs/URIs would result in harmful 790 dereferencing. However, if an XMPP protocol extension defines 791 methods for information retrieval, it MUST define appropriate 792 controls over access to that information. In addition, XMPP servers 793 SHOULD NOT natively parse XMPP IRIs/URIs but instead SHOULD accept 794 only the XML wire protocol specified in [XMPP-CORE] and any desired 795 extensions thereto. 797 5.4 Sensitive Information 799 The ability to interact with XMPP entities via a web browser or other 800 non-native application may expose sensitive information (such as 801 support for particular XMPP application protocol extensions) and 802 thereby make it possible to launch attacks that are not possible or 803 that are unlikely on a native XMPP network. Due care must be taken 804 in deciding what information is appropriate for representation in 805 XMPP IRIs or URIs. 807 In particular, advertising XMPP IRIs/URIs in publicly accessible 808 locations (e.g., on websites) may make it easier for malicious users 809 to harvest XMPP addresses from the authority and path components of 810 XMPP IRIs/URIs and therefore to send unsolicited bulk communications 811 to the users or applications represented by those addresses. Due 812 care should be taken in balancing the benefits of open information 813 exchange against the potential costs of unwanted communications. 815 To help prevent leaking of sensitive information, passwords and other 816 user credentials are forbidden in the authority component of XMPP 817 IRIs/URIs; in fact they are not needed, since the fact that 818 authentication in XMPP occurs via [SASL] makes it possible to use the 819 SASL ANONYMOUS mechanism if desired. 821 5.5 Semantic Attacks 823 Despite the existence of non-hierarchical URI schemes such as 824 [MAILTO], by association human users may expect all URIs to include 825 the "//" characters after the scheme name and ":" character. 826 However, in XMPP IRIs/URIs the "//" characters precede the authority 827 component rather than the path component. Thus 828 xmpp://guest@example.com indicates to authenticate as 829 "guest@example.com" whereas xmpp:guest@example.com identifies the 830 node "guest@example.com". Processing applications MUST clearly 831 differentiate between these forms and user agents SHOULD discourage 832 human users from including the "//" characters in XMPP IRIs/URIs 833 since use of the authority component is envisioned to be helpful only 834 in specialized scenarios, not more generally. 836 5.6 Spoofing 838 The ability to include effectively the full range of Unicode 839 characters in an XMPP IRI may make it easier to execute certain forms 840 of address mimicking (also called "spoofing"). However, XMPP IRIs 841 are no different from other IRIs in this regard, and applications 842 that will present XMPP IRIs to human users must adhere to best 843 practices regarding address mimicking in order to help prevent 844 attacks that result from spoofed addresses (e.g., the phenonmenon 845 known as "phishing"). For details, refer to the Security 846 Considerations of [IRI]. 848 6. References 850 6.1 Normative References 852 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 853 Specifications: ABNF", RFC 4234, October 2005. 855 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 856 Identifiers (IRIs)", RFC 3987, January 2005. 858 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 859 Requirement Levels", BCP 14, RFC 2119, March 1997. 861 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 862 Resource Identifier (URI): Generic Syntax", STD 66, 863 RFC 3986, January 2005. 865 [XMPP-CORE] 866 Saint-Andre, P., "Extensible Messaging and Presence 867 Protocol (XMPP): Core", RFC 3920, October 2004. 869 6.2 Informative References 871 [CPIM] Peterson, J., "Common Profile for Instant Messaging 872 (CPIM)", RFC 3860, August 2004. 874 [CPP] Peterson, J., "Common Profile for Presence (CPP)", 875 RFC 3859, August 2004. 877 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 878 specifying the location of services (DNS SRV)", RFC 2782, 879 February 2000. 881 [HTML] Raggett, D., "HTML 4.0 Specification", W3C REC REC-html40- 882 19980424, April 1998. 884 [HTTP-AUTH] 885 Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 886 Leach, P., Luotonen, A., and L. Stewart, "HTTP 887 Authentication: Basic and Digest Access Authentication", 888 RFC 2617, June 1999. 890 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, 891 "Internationalizing Domain Names in Applications (IDNA)", 892 RFC 3490, March 2003. 894 [IMP-MODEL] 895 Day, M., Rosenberg, J., and H. Sugano, "A Model for 896 Presence and Instant Messaging", RFC 2778, February 2000. 898 [IMP-REQS] 899 Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 900 / Presence Protocol Requirements", RFC 2779, 901 February 2000. 903 [JEP-0009] 904 Adams, D., "Jabber-RPC", JSF JEP 0009, February 2006. 906 [JEP-0030] 907 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 908 Andre, "Service Discovery", JSF JEP 0030, January 2006. 910 [JEP-0045] 911 Saint-Andre, P., "Multi-User Chat", JSF JEP 0045, 912 September 2005. 914 [JEP-0053] 915 Saint-Andre, P., "Jabber Registrar", JSF JEP 0053, 916 May 2004. 918 [JEP-0060] 919 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 920 Subscribe", JSF JEP 0060, March 2005. 922 [JEP-0072] 923 Forno, F. and P. Saint-Andre, "SOAP Over XMPP", JSF 924 JEP 0072, December 2005. 926 [JEP-0077] 927 Saint-Andre, P., "In-Band Registration", JSF JEP 0077, 928 January 2006. 930 [JEP-0147] 931 Saint-Andre, P., "XMPP IRI/URI Query Components", JSF 932 JEP 0147, March 2006. 934 [MAILTO] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto 935 URL scheme", RFC 2368, July 1998. 937 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 938 Extensions (MIME) Part Two: Media Types", RFC 2046, 939 November 1996. 941 [NAMEPREP] 942 Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 943 Profile for Internationalized Domain Names (IDN)", 944 RFC 3491, March 2003. 946 [SASL] Myers, J., "Simple Authentication and Security Layer 947 (SASL)", RFC 2222, October 1997. 949 [STRINGPREP] 950 Hoffman, P. and M. Blanchet, "Preparation of 951 Internationalized Strings ("STRINGPREP")", RFC 3454, 952 December 2002. 954 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 955 3.2.0", 2000. 957 The Unicode Standard, Version 3.2.0 is defined by The 958 Unicode Standard, Version 3.0 (Reading, MA, Addison- 959 Wesley, 2000. ISBN 0-201-61633-5), as amended by the 960 Unicode Standard Annex #27: Unicode 3.1 961 (http://www.unicode.org/reports/tr27/) and by the Unicode 962 Standard Annex #28: Unicode 3.2 963 (http://www.unicode.org/reports/tr28/). 965 [URI-SCHEMES] 966 Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 967 Registration Procedures for New URI Schemes", RFC 4395, 968 February 2006. 970 [US-ASCII] 971 American National Standards Institute, "Coded Character 972 Set - 7-bit American Standard Code for Information 973 Interchange", ANSI X3.4, 1986. 975 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 976 10646", STD 63, RFC 3629, November 2003. 978 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 979 Protocol (XMPP): Instant Messaging and Presence", 980 RFC 3921, October 2004. 982 Author's Address 984 Peter Saint-Andre 985 Jabber Software Foundation 987 Email: stpeter@jabber.org 988 URI: xmpp:stpeter@jabber.org 990 Intellectual Property Statement 992 The IETF takes no position regarding the validity or scope of any 993 Intellectual Property Rights or other rights that might be claimed to 994 pertain to the implementation or use of the technology described in 995 this document or the extent to which any license under such rights 996 might or might not be available; nor does it represent that it has 997 made any independent effort to identify any such rights. Information 998 on the procedures with respect to rights in RFC documents can be 999 found in BCP 78 and BCP 79. 1001 Copies of IPR disclosures made to the IETF Secretariat and any 1002 assurances of licenses to be made available, or the result of an 1003 attempt made to obtain a general license or permission for the use of 1004 such proprietary rights by implementers or users of this 1005 specification can be obtained from the IETF on-line IPR repository at 1006 http://www.ietf.org/ipr. 1008 The IETF invites any interested party to bring to its attention any 1009 copyrights, patents or patent applications, or other proprietary 1010 rights that may cover technology that may be required to implement 1011 this standard. Please address the information to the IETF at 1012 ietf-ipr@ietf.org. 1014 Disclaimer of Validity 1016 This document and the information contained herein are provided on an 1017 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1018 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1019 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1020 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1021 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1022 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1024 Copyright Statement 1026 Copyright (C) The Internet Society (2006). This document is subject 1027 to the rights, licenses and restrictions contained in BCP 78, and 1028 except as set forth therein, the authors retain all their rights. 1030 Acknowledgment 1032 Funding for the RFC Editor function is currently provided by the 1033 Internet Society.