idnits 2.17.1 draft-ietf-iri-3987bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document obsoletes RFC3987, but the abstract doesn't seem to directly say this. It does mention RFC3987 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 29, 2011) is 4770 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3491 (Obsoleted by RFC 5891) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNI9' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNIV6' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTR15' -- Obsolete informational reference (is this intentional?): RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- Obsolete informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 2192 (Obsoleted by RFC 5092) -- Obsolete informational reference (is this intentional?): RFC 2368 (Obsoleted by RFC 6068) -- Obsolete informational reference (is this intentional?): RFC 2396 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internationalized Resource M. Duerst 3 Identifiers (iri) Aoyama Gakuin University 4 Internet-Draft M. Suignard 5 Obsoletes: 3987 (if approved) Unicode Consortium 6 Intended status: Standards Track L. Masinter 7 Expires: September 30, 2011 Adobe 8 March 29, 2011 10 Internationalized Resource Identifiers (IRIs) 11 draft-ietf-iri-3987bis-05 13 Abstract 15 This document defines the Internationalized Resource Identifier (IRI) 16 protocol element, as an extension of the Uniform Resource Identifier 17 (URI). An IRI is a sequence of characters from the Universal 18 Character Set (Unicode/ISO 10646). Grammar and processing rules are 19 given for IRIs and related syntactic forms. 21 In addition, this document provides named additional rule sets for 22 processing otherwise invalid IRIs, in a way that supports other 23 specifications that wish to mandate common behavior for 'error' 24 handling. In particular, rules used in some XML languages (LEIRI) 25 and web applications are given. 27 Defining IRI as new protocol element (rather than updating or 28 extending the definition of URI) allows independent orderly 29 transitions: other protocols and languages that use URIs must 30 explicitly choose to allow IRIs. 32 Guidelines are provided for the use and deployment of IRIs and 33 related protocol elements when revising protocols, formats, and 34 software components that currently deal only with URIs. 36 RFC Editor: Please remove the next paragraph before publication. 38 This document is intended to update RFC 3987 and move towards IETF 39 Draft Standard. For discussion and comments on this draft, please 40 join the IETF IRI WG by subscribing to the mailing list 41 public-iri@w3.org. For a list of open issues, please see the issue 42 tracker of the WG at http://trac.tools.ietf.org/wg/iri/trac/report/1. 43 For a list of individual edits, please see the change history at 44 http://trac.tools.ietf.org/wg/iri/trac/log/draft-ietf-iri-3987bis. 46 Status of this Memo 48 This Internet-Draft is submitted to IETF in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF), its areas, and its working groups. Note that 53 other groups may also distribute working documents as Internet- 54 Drafts. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 The list of current Internet-Drafts can be accessed at 62 http://www.ietf.org/ietf/1id-abstracts.txt. 64 The list of Internet-Draft Shadow Directories can be accessed at 65 http://www.ietf.org/shadow.html. 67 This Internet-Draft will expire on September 30, 2011. 69 Copyright Notice 71 Copyright (c) 2011 IETF Trust and the persons identified as the 72 document authors. All rights reserved. 74 This document is subject to BCP 78 and the IETF Trust's Legal 75 Provisions Relating to IETF Documents 76 (http://trustee.ietf.org/license-info) in effect on the date of 77 publication of this document. Please review these documents 78 carefully, as they describe your rights and restrictions with respect 79 to this document. Code Components extracted from this document must 80 include Simplified BSD License text as described in Section 4.e of 81 the Trust Legal Provisions and are provided without warranty as 82 described in the BSD License. 84 This document may contain material from IETF Documents or IETF 85 Contributions published or made publicly available before November 86 10, 2008. The person(s) controlling the copyright in some of this 87 material may not have granted the IETF Trust the right to allow 88 modifications of such material outside the IETF Standards Process. 89 Without obtaining an adequate license from the person(s) controlling 90 the copyright in such materials, this document may not be modified 91 outside the IETF Standards Process, and derivative works of it may 92 not be created outside the IETF Standards Process, except to format 93 it for publication as an RFC or to translate it into languages other 94 than English. 96 Table of Contents 98 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 99 1.1. Overview and Motivation . . . . . . . . . . . . . . . . . 5 100 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 101 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 102 1.4. Notation . . . . . . . . . . . . . . . . . . . . . . . . 9 103 2. IRI Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 9 104 2.1. Summary of IRI Syntax . . . . . . . . . . . . . . . . . . 10 105 2.2. ABNF for IRI References and IRIs . . . . . . . . . . . . 10 106 3. Processing IRIs and related protocol elements . . . . . . . . 13 107 3.1. Converting to UCS . . . . . . . . . . . . . . . . . . . . 14 108 3.2. Parse the IRI into IRI components . . . . . . . . . . . . 14 109 3.3. General percent-encoding of IRI components . . . . . . . 15 110 3.4. Mapping ireg-name . . . . . . . . . . . . . . . . . . . . 15 111 3.4.1. Mapping using Percent-Encoding . . . . . . . . . . . . 15 112 3.4.2. Mapping using Punycode . . . . . . . . . . . . . . . . 16 113 3.4.3. Additional Considerations . . . . . . . . . . . . . . 16 114 3.5. Mapping query components . . . . . . . . . . . . . . . . 17 115 3.6. Mapping IRIs to URIs . . . . . . . . . . . . . . . . . . 17 116 3.7. Converting URIs to IRIs . . . . . . . . . . . . . . . . . 17 117 3.7.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 19 118 4. Bidirectional IRIs for Right-to-Left Languages . . . . . . . . 20 119 4.1. Logical Storage and Visual Presentation . . . . . . . . . 21 120 4.2. Bidi IRI Structure . . . . . . . . . . . . . . . . . . . 22 121 4.3. Input of Bidi IRIs . . . . . . . . . . . . . . . . . . . 23 122 4.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 123 5. Normalization and Comparison . . . . . . . . . . . . . . . . . 25 124 5.1. Equivalence . . . . . . . . . . . . . . . . . . . . . . . 26 125 5.2. Preparation for Comparison . . . . . . . . . . . . . . . 26 126 5.3. Comparison Ladder . . . . . . . . . . . . . . . . . . . . 27 127 5.3.1. Simple String Comparison . . . . . . . . . . . . . . . 27 128 5.3.2. Syntax-Based Normalization . . . . . . . . . . . . . . 28 129 5.3.3. Scheme-Based Normalization . . . . . . . . . . . . . . 31 130 5.3.4. Protocol-Based Normalization . . . . . . . . . . . . . 32 131 6. Use of IRIs . . . . . . . . . . . . . . . . . . . . . . . . . 33 132 6.1. Limitations on UCS Characters Allowed in IRIs . . . . . . 33 133 6.2. Software Interfaces and Protocols . . . . . . . . . . . . 33 134 6.3. Format of URIs and IRIs in Documents and Protocols . . . 34 135 6.4. Use of UTF-8 for Encoding Original Characters . . . . . . 34 136 6.5. Relative IRI References . . . . . . . . . . . . . . . . . 36 137 7. Liberal Handling of Otherwise Invalid IRIs . . . . . . . . . . 36 138 7.1. LEIRI Processing . . . . . . . . . . . . . . . . . . . . 36 139 7.2. Web Address Processing . . . . . . . . . . . . . . . . . 37 140 7.3. Characters Not Allowed in IRIs . . . . . . . . . . . . . 38 141 8. URI/IRI Processing Guidelines (Informative) . . . . . . . . . 40 142 8.1. URI/IRI Software Interfaces . . . . . . . . . . . . . . . 40 143 8.2. URI/IRI Entry . . . . . . . . . . . . . . . . . . . . . . 41 144 8.3. URI/IRI Transfer between Applications . . . . . . . . . . 42 145 8.4. URI/IRI Generation . . . . . . . . . . . . . . . . . . . 42 146 8.5. URI/IRI Selection . . . . . . . . . . . . . . . . . . . . 43 147 8.6. Display of URIs/IRIs . . . . . . . . . . . . . . . . . . 43 148 8.7. Interpretation of URIs and IRIs . . . . . . . . . . . . . 44 149 8.8. Upgrading Strategy . . . . . . . . . . . . . . . . . . . 44 150 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 151 10. Security Considerations . . . . . . . . . . . . . . . . . . . 46 152 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47 153 12. Main Changes Since RFC 3987 . . . . . . . . . . . . . . . . . 47 154 12.1. Major restructuring of IRI processing model . . . . . . . 47 155 12.1.1. OLD WAY . . . . . . . . . . . . . . . . . . . . . . . 48 156 12.1.2. NEW WAY . . . . . . . . . . . . . . . . . . . . . . . 48 157 12.1.3. Extension of Syntax . . . . . . . . . . . . . . . . . 48 158 12.1.4. More to be added . . . . . . . . . . . . . . . . . . . 49 159 12.2. Change Log . . . . . . . . . . . . . . . . . . . . . . . 49 160 12.2.1. Changes after draft-ietf-iri-3987bis-01 . . . . . . . 49 161 12.2.2. Changes from draft-duerst-iri-bis-07 to 162 draft-ietf-iri-3987bis-00 . . . . . . . . . . . . . . 49 163 12.2.3. Changes from -06 to -07 of draft-duerst-iri-bis . . . 49 164 12.3. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 49 165 12.4. Changes from -05 to -06 of draft-duerst-iri-bis-00 . . . 49 166 12.5. Changes from -04 to -05 of draft-duerst-iri-bis . . . . . 50 167 12.6. Changes from -03 to -04 of draft-duerst-iri-bis . . . . . 50 168 12.7. Changes from -02 to -03 of draft-duerst-iri-bis . . . . . 50 169 12.8. Changes from -01 to -02 of draft-duerst-iri-bis . . . . . 50 170 12.9. Changes from -00 to -01 of draft-duerst-iri-bis . . . . . 50 171 12.10. Changes from RFC 3987 to -00 of draft-duerst-iri-bis . . 50 172 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 173 13.1. Normative References . . . . . . . . . . . . . . . . . . 51 174 13.2. Informative References . . . . . . . . . . . . . . . . . 52 175 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 177 1. Introduction 179 1.1. Overview and Motivation 181 A Uniform Resource Identifier (URI) is defined in [RFC3986] as a 182 sequence of characters chosen from a limited subset of the repertoire 183 of US-ASCII [ASCII] characters. 185 The characters in URIs are frequently used for representing words of 186 natural languages. This usage has many advantages: Such URIs are 187 easier to memorize, easier to interpret, easier to transcribe, easier 188 to create, and easier to guess. For most languages other than 189 English, however, the natural script uses characters other than A - 190 Z. For many people, handling Latin characters is as difficult as 191 handling the characters of other scripts is for those who use only 192 the Latin alphabet. Many languages with non-Latin scripts are 193 transcribed with Latin letters. These transcriptions are now often 194 used in URIs, but they introduce additional difficulties. 196 The infrastructure for the appropriate handling of characters from 197 additional scripts is now widely deployed in operating system and 198 application software. Software that can handle a wide variety of 199 scripts and languages at the same time is increasingly common. Also, 200 an increasing number of protocols and formats can carry a wide range 201 of characters. 203 URIs are used both as a protocol element (for transmission and 204 processing by software) and also a presentation element (for display 205 and handling by people who read, interpret, coin, or guess them). 206 The transition between these roles is more difficult and complex when 207 dealing with the larger set of characters than allowed for URIs in 208 [RFC3986]. 210 This document defines the protocol element called Internationalized 211 Resource Identifier (IRI), which allow applications of URIs to be 212 extended to use resource identifiers that have a much wider 213 repertoire of characters. It also provides corresponding 214 "internationalized" versions of other constructs from [RFC3986], such 215 as URI references. The syntax of IRIs is defined in Section 2. 217 Using characters outside of A - Z in IRIs adds a number of 218 difficulties. Section 4 discusses the special case of bidirectional 219 IRIs using characters from scripts written right-to-left. Section 5 220 discusses various forms of equivalence between IRIs. Section 6 221 discusses the use of IRIs in different situations. Section 8 gives 222 additional informative guidelines. Section 10 discusses IRI-specific 223 security considerations. 225 When originally defining IRIs, several design alternatives were 226 considered. Historically interested readers can find an overview in 227 Appendix A of [RFC3987]. For some additional background on the 228 design of URIs and IRIs, please also see [Gettys]. 230 1.2. Applicability 232 IRIs are designed to allow protocols and software that deal with URIs 233 to be updated to handle IRIs. A "URI scheme" (as defined by 234 [RFC3986] and registered through the IANA process defined in 235 [RFC4395bis] also serves as an "IRI scheme". Processing of IRIs is 236 accomplished by extending the URI syntax while retaining (and not 237 expanding) the set of "reserved" characters, such that the syntax for 238 any URI scheme may be uniformly extended to allow non-ASCII 239 characters. In addition, following parsing of an IRI, it is possible 240 to construct a corresponding URI by first encoding characters outside 241 of the allowed URI range and then reassembling the components. 243 Practical use of IRIs forms in place of URIs forms depends on the 244 following conditions being met: 246 a. A protocol or format element MUST be explicitly designated to be 247 able to carry IRIs. The intent is to avoid introducing IRIs into 248 contexts that are not defined to accept them. For example, XML 249 schema [XMLSchema] has an explicit type "anyURI" that includes 250 IRIs and IRI references. Therefore, IRIs and IRI references can 251 be in attributes and elements of type "anyURI". On the other 252 hand, in the [RFC2616] definition of HTTP/1.1, the Request URI is 253 defined as a URI, which means that direct use of IRIs is not 254 allowed in HTTP requests. 256 b. The protocol or format carrying the IRIs MUST have a mechanism to 257 represent the wide range of characters used in IRIs, either 258 natively or by some protocol- or format-specific escaping 259 mechanism (for example, numeric character references in [XML1]). 261 c. The URI scheme definition, if it explicitly allows a percent sign 262 ("%") in any syntactic component, SHOULD define the interpretation 263 of sequences of percent-encoded octets (using "%XX" hex octets) as 264 octet from sequences of UTF-8 encoded strings; this is recommended 265 in the guidelines for registering new schemes, [RFC4395bis]. For 266 example, this is the practice for IMAP URLs [RFC2192], POP URLs 267 [RFC2384] and the URN syntax [RFC2141]). Note that use of 268 percent-encoding may also be restricted in some situations, for 269 example, URI schemes that disallow percent-encoding might still be 270 used with a fragment identifier which is percent-encoded (e.g., 271 [XPointer]). See Section 6.4 for further discussion. 273 1.3. Definitions 275 The following definitions are used in this document; they follow the 276 terms in [RFC2130], [RFC2277], and [ISO10646]. 278 character: A member of a set of elements used for the organization, 279 control, or representation of data. For example, "LATIN CAPITAL 280 LETTER A" names a character. 282 octet: An ordered sequence of eight bits considered as a unit. 284 character repertoire: A set of characters (set in the mathematical 285 sense). 287 sequence of characters: A sequence of characters (one after 288 another). 290 sequence of octets: A sequence of octets (one after another). 292 character encoding: A method of representing a sequence of 293 characters as a sequence of octets (maybe with variants). Also, a 294 method of (unambiguously) converting a sequence of octets into a 295 sequence of characters. 297 charset: The name of a parameter or attribute used to identify a 298 character encoding. 300 UCS: Universal Character Set. The coded character set defined by 301 ISO/IEC 10646 [ISO10646] and the Unicode Standard [UNIV6]. 303 IRI reference: Denotes the common usage of an Internationalized 304 Resource Identifier. An IRI reference may be absolute or 305 relative. However, the "IRI" that results from such a reference 306 only includes absolute IRIs; any relative IRI references are 307 resolved to their absolute form. Note that in [RFC2396] URIs did 308 not include fragment identifiers, but in [RFC3986] fragment 309 identifiers are part of URIs. 311 URL: The term "URL" was originally used [RFC1738] for roughly what 312 is now called a "URI". Books, software and documentation often 313 refers to URIs and IRIs using the "URL" term. Some usages 314 restrict "URL" to those URIs which are not URNs. Because of the 315 ambiguity of the term using the term "URL" is NOT RECOMMENDED in 316 formal documents. 318 LEIRI (Legacy Extended IRI) processing: This term was used in 319 various XML specifications to refer to strings that, although not 320 valid IRIs, were acceptable input to the processing rules in 321 Section 7.1. 323 (Web Address, Hypertext Reference, HREF): These terms have been 324 added in this document for convenience, to allow other 325 specifications to refer to those strings that, although not valid 326 IRIs, are acceptable input to the processing rules in Section 7.2. 327 This usage corresponds to the parsing rules of some popular web 328 browsing applications. ISSUE: Need to find a good name/ 329 abbreviation for these. 331 running text: Human text (paragraphs, sentences, phrases) with 332 syntax according to orthographic conventions of a natural 333 language, as opposed to syntax defined for ease of processing by 334 machines (e.g., markup, programming languages). 336 protocol element: Any portion of a message that affects processing 337 of that message by the protocol in question. 339 presentation element: A presentation form corresponding to a 340 protocol element; for example, using a wider range of characters. 342 create (a URI or IRI): With respect to URIs and IRIs, the term is 343 used for the initial creation. This may be the initial creation 344 of a resource with a certain identifier, or the initial exposition 345 of a resource under a particular identifier. 347 generate (a URI or IRI): With respect to URIs and IRIs, the term is 348 used when the identifier is generated by derivation from other 349 information. 351 parsed URI component: When a URI processor parses a URI (following 352 the generic syntax or a scheme-specific syntax, the result is a 353 set of parsed URI components, each of which has a type 354 (corresponding to the syntactic definition) and a sequence of URI 355 characters. 357 parsed IRI component: When an IRI processor parses an IRI directly, 358 following the general syntax or a scheme-specific syntax, the 359 result is a set of parsed IRI components, each of which has a type 360 (corresponding to the syntactice definition) and a sequence of IRI 361 characters. (This definition is analogous to "parsed URI 362 component".) 364 IRI scheme: A URI scheme may also be known as an "IRI scheme" if the 365 scheme's syntax has been extended to allow non-US-ASCII characters 366 according to the rules in this document. 368 1.4. Notation 370 RFCs and Internet Drafts currently do not allow any characters 371 outside the US-ASCII repertoire. Therefore, this document uses 372 various special notations to denote such characters in examples. 374 In text, characters outside US-ASCII are sometimes referenced by 375 using a prefix of 'U+', followed by four to six hexadecimal digits. 377 To represent characters outside US-ASCII in examples, this document 378 uses two notations: 'XML Notation' and 'Bidi Notation'. 380 XML Notation uses a leading '&#x', a trailing ';', and the 381 hexadecimal number of the character in the UCS in between. For 382 example, я stands for CYRILLIC CAPITAL LETTER YA. In this 383 notation, an actual '&' is denoted by '&'. 385 Bidi Notation is used for bidirectional examples: Lower case letters 386 stand for Latin letters or other letters that are written left to 387 right, whereas upper case letters represent Arabic or Hebrew letters 388 that are written right to left. 390 To denote actual octets in examples (as opposed to percent-encoded 391 octets), the two hex digits denoting the octet are enclosed in "<" 392 and ">". For example, the octet often denoted as 0xc9 is denoted 393 here as . 395 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 396 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 397 and "OPTIONAL" are to be interpreted as described in [RFC2119]. 399 2. IRI Syntax 401 This section defines the syntax of Internationalized Resource 402 Identifiers (IRIs). 404 As with URIs, an IRI is defined as a sequence of characters, not as a 405 sequence of octets. This definition accommodates the fact that IRIs 406 may be written on paper or read over the radio as well as stored or 407 transmitted digitally. The same IRI might be represented as 408 different sequences of octets in different protocols or documents if 409 these protocols or documents use different character encodings 410 (and/or transfer encodings). Using the same character encoding as 411 the containing protocol or document ensures that the characters in 412 the IRI can be handled (e.g., searched, converted, displayed) in the 413 same way as the rest of the protocol or document. 415 2.1. Summary of IRI Syntax 417 IRIs are defined by extending the URI syntax in [RFC3986], but 418 extending the class of unreserved characters by adding the characters 419 of the UCS (Universal Character Set, [ISO10646]) beyond U+007F, 420 subject to the limitations given in the syntax rules below and in 421 Section 6.1. 423 The syntax and use of components and reserved characters is the same 424 as that in [RFC3986]. Each "URI scheme" thus also functions as an 425 "IRI scheme", in that scheme-specific parsing rules for URIs of a 426 scheme are be extended to allow parsing of IRIs using the same 427 parsing rules. 429 All the operations defined in [RFC3986], such as the resolution of 430 relative references, can be applied to IRIs by IRI-processing 431 software in exactly the same way as they are for URIs by URI- 432 processing software. 434 Characters outside the US-ASCII repertoire MUST NOT be reserved and 435 therefore MUST NOT be used for syntactical purposes, such as to 436 delimit components in newly defined schemes. For example, U+00A2, 437 CENT SIGN, is not allowed as a delimiter in IRIs, because it is in 438 the 'iunreserved' category. This is similar to the fact that it is 439 not possible to use '-' as a delimiter in URIs, because it is in the 440 'unreserved' category. 442 2.2. ABNF for IRI References and IRIs 444 An ABNF definition for IRI references (which are the most general 445 concept and the start of the grammar) and IRIs is given here. The 446 syntax of this ABNF is described in [STD68]. Character numbers are 447 taken from the UCS, without implying any actual binary encoding. 448 Terminals in the ABNF are characters, not octets. 450 The following grammar closely follows the URI grammar in [RFC3986], 451 except that the range of unreserved characters is expanded to include 452 UCS characters, with the restriction that private UCS characters can 453 occur only in query parts. The grammar is split into two parts: 454 Rules that differ from [RFC3986] because of the above-mentioned 455 expansion, and rules that are the same as those in [RFC3986]. For 456 rules that are different than those in [RFC3986], the names of the 457 non-terminals have been changed as follows. If the non-terminal 458 contains 'URI', this has been changed to 'IRI'. Otherwise, an 'i' 459 has been prefixed. The rule has been introduced in order 460 to be able to reference it from other parts of the document. 462 The following rules are different from those in [RFC3986]: 464 IRI = scheme ":" ihier-part [ "?" iquery ] 465 [ "#" ifragment ] 467 ihier-part = "//" iauthority ipath-abempty 468 / ipath-absolute 469 / ipath-rootless 470 / ipath-empty 472 IRI-reference = IRI / irelative-ref 474 absolute-IRI = scheme ":" ihier-part [ "?" iquery ] 476 irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ] 478 irelative-part = "//" iauthority ipath-abempty 479 / ipath-absolute 480 / ipath-noscheme 481 / ipath-empty 483 iauthority = [ iuserinfo "@" ] ihost [ ":" port ] 484 iuserinfo = *( iunreserved / pct-form / sub-delims / ":" ) 485 ihost = IP-literal / IPv4address / ireg-name 487 pct-form = pct-encoded 489 ireg-name = *( iunreserved / sub-delims ) 491 ipath = ipath-abempty ; begins with "/" or is empty 492 / ipath-absolute ; begins with "/" but not "//" 493 / ipath-noscheme ; begins with a non-colon segment 494 / ipath-rootless ; begins with a segment 495 / ipath-empty ; zero characters 497 ipath-abempty = *( path-sep isegment ) 498 ipath-absolute = path-sep [ isegment-nz *( path-sep isegment ) ] 499 ipath-noscheme = isegment-nz-nc *( path-sep isegment ) 500 ipath-rootless = isegment-nz *( path-sep isegment ) 501 ipath-empty = 0 502 path-sep = "/" 504 isegment = *ipchar 505 isegment-nz = 1*ipchar 506 isegment-nz-nc = 1*( iunreserved / pct-form / sub-delims 507 / "@" ) 508 ; non-zero-length segment without any colon ":" 510 ipchar = iunreserved / pct-form / sub-delims / ":" 511 / "@" 513 iquery = *( ipchar / iprivate / "/" / "?" ) 515 ifragment = *( ipchar / "/" / "?" ) 517 iunreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar 519 ucschar = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF 520 / %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD 521 / %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD 522 / %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD 523 / %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD 524 / %xD0000-DFFFD / %xE1000-EFFFD 526 iprivate = %xE000-F8FF / %xE0000-E0FFF / %xF0000-FFFFD 527 / %x100000-10FFFD 529 Some productions are ambiguous. The "first-match-wins" (a.k.a. 530 "greedy") algorithm applies. For details, see [RFC3986]. 532 The following rules are the same as those in [RFC3986]: 534 scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) 536 port = *DIGIT 538 IP-literal = "[" ( IPv6address / IPvFuture ) "]" 540 IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) 542 IPv6address = 6( h16 ":" ) ls32 543 / "::" 5( h16 ":" ) ls32 544 / [ h16 ] "::" 4( h16 ":" ) ls32 545 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 546 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 547 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 548 / [ *4( h16 ":" ) h16 ] "::" ls32 549 / [ *5( h16 ":" ) h16 ] "::" h16 550 / [ *6( h16 ":" ) h16 ] "::" 552 h16 = 1*4HEXDIG 553 ls32 = ( h16 ":" h16 ) / IPv4address 555 IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet 557 dec-octet = DIGIT ; 0-9 558 / %x31-39 DIGIT ; 10-99 559 / "1" 2DIGIT ; 100-199 560 / "2" %x30-34 DIGIT ; 200-249 561 / "25" %x30-35 ; 250-255 563 pct-encoded = "%" HEXDIG HEXDIG 565 unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" 566 reserved = gen-delims / sub-delims 567 gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" 568 sub-delims = "!" / "$" / "&" / "'" / "(" / ")" 569 / "*" / "+" / "," / ";" / "=" 571 This syntax does not support IPv6 scoped addressing zone identifiers. 573 3. Processing IRIs and related protocol elements 575 IRIs are meant to replace URIs in identifying resources within new 576 versions of protocols, formats, and software components that use a 577 UCS-based character repertoire. Protocols and components may use and 578 process IRIs directly. However, there are still numerous systems and 579 protocols which only accept URIs or components of parsed URIs; that 580 is, they only accept sequences of characters within the subset of US- 581 ASCII characters allowed in URIs. 583 This section defines specific processing steps for IRI consumers 584 which establish the relationship between the string given and the 585 interpreted derivatives. These processing steps apply to both IRIs 586 and IRI references (i.e., absolute or relative forms); for IRIs, some 587 steps are scheme specific. 589 3.1. Converting to UCS 591 Input that is already in a Unicode form (i.e., a sequence of Unicode 592 characters or an octet-stream representing a Unicode-based character 593 encoding such as UTF-8 or UTF-16) should be left as is and not 594 normalized (see Section 5.3.2.2). 596 An IRI or IRI reference is a sequence of characters from the UCS. 597 For IRIs that are not already in a Unicode form (as when written on 598 paper, read aloud, or represented in a text stream using a legacy 599 character encoding), convert the IRI to Unicode. Note that some 600 character encodings or transcriptions can be converted to or 601 represented by more than one sequence of Unicode characters. Ideally 602 the resulting IRI would use a normalized form, such as Unicode 603 Normalization Form C [UTR15] (see Section 5.3 Normalization and 604 Comparison), since that ensures a stable, consistent representation 605 that is most likely to produce the intended results. Implementers 606 and users are cautioned that, while denormalized character sequences 607 are valid, they might be difficult for other users or processes to 608 reproduce and might lead to unexpected results. 610 In other cases (written on paper, read aloud, or otherwise 611 represented independent of any character encoding) represent the IRI 612 as a sequence of characters from the UCS normalized according to 613 Unicode Normalization Form C (NFC, [UTR15]). 615 3.2. Parse the IRI into IRI components 617 Parse the IRI, either as a relative reference (no scheme) or using 618 scheme specific processing (according to the scheme given); the 619 result is a set of parsed IRI components. 621 NOTE: The result of parsing into components will correspond to 622 subtrings of the IRI that may be accessible via an API. For example, 623 in [HTML5], the protocol components of interest are SCHEME (scheme), 624 HOST (ireg-name), PORT (port), the PATH (ipath after the initial 625 "/"), QUERY (iquery), FRAGMENT (ifragment), and AUTHORITY 626 (iauthority). 628 Subsequent processing rules are sometimes used to define other 629 syntactic components. For example, [HTML5] defines APIs for IRI 630 processing; in these APIs: 632 HOSTSPECIFIC the substring that follows the substring matched by the 633 iauthority production, or the whole string if the iauthority 634 production wasn't matched. 636 HOSTPORT if there is a scheme component and a port component and the 637 port given by the port component is different than the default 638 port defined for the protocol given by the scheme component, then 639 HOSTPORT is the substring that starts with the substring matched 640 by the host production and ends with the substring matched by the 641 port production, and includes the colon in between the two. 642 Otherwise, it is the same as the host component. 644 3.3. General percent-encoding of IRI components 646 Except as noted in the following subsections, IRI components are 647 mapped to the equivalent URI components by percent-encoding those 648 characters not allowed in URIs. Previous processing steps will have 649 removed some characters, and the interpretation of reserved 650 characters will have already been done (with the syntactic reserved 651 characters outside of the IRI component). This mapping is defined 652 for all sequences of Unicode characters, whether or not they are 653 valid for the component in question. 655 For each character which is not allowed anywhere in a valid URI, 656 apply the following steps. 658 Convert to UTF-8 Convert the character to a sequence of one or more 659 octets using UTF-8 [RFC3629]. 661 Percent encode Convert each octet of this sequence to %HH, where HH 662 is the hexadecimal notation of the octet value. The hexadecimal 663 notation SHOULD use uppercase letters. (This is the general URI 664 percent-encoding mechanism in Section 2.1 of [RFC3986].) 666 Note that the mapping is an identity transformation for parsed URI 667 components of valid URIs, and is idempotent: applying the mapping a 668 second time will not change anything. 670 3.4. Mapping ireg-name 672 3.4.1. Mapping using Percent-Encoding 674 The ireg-name component SHOULD be converted according to the general 675 procedure for percent-encoding of IRI components described in 676 Section 3.3. 678 For example, the IRI 679 "http://résumé.example.org" 680 will be converted to 681 "http://r%C3%A9sum%C3%A9.example.org". 683 This conversion for ireg-name is in line with Section 3.2.2 of 684 [RFC3986], which does not mandate a particular registered name lookup 685 technology. For further background, see [RFC6055] and [Gettys]. 687 3.4.2. Mapping using Punycode 689 The ireg-name component MAY also be converted as follows: 691 Replace the ireg-name part of the IRI by the part converted using the 692 Domain Name Lookup procedure (Subsections 5.3 to 5.5) of [RFC5891]. 693 on each dot-separated label, and by using U+002E (FULL STOP) as a 694 label separator. This procedure may fail, but this would mean that 695 the IRI cannot be resolved. In such cases, if the domain name 696 conversion fails, then the entire IRI conversion fails. Processors 697 that have no mechanism for signalling a failure MAY instead 698 substitute an otherwise invalid host name, although such processing 699 SHOULD be avoided. 701 For example, the IRI 702 "http://résumé.example.org" 703 MAY be converted to 704 "http://xn--rsum-bad.example.org" 705 . 707 This conversion for ireg-name will be better able to deal with legacy 708 infrastructure that cannot handle percent-encoding in domain names. 710 3.4.3. Additional Considerations 712 Note: Domain Names may appear in parts of an IRI other than the 713 ireg-name part. It is the responsibility of scheme-specific 714 implementations (if the Internationalized Domain Name is part of 715 the scheme syntax) or of server-side implementations (if the 716 Internationalized Domain Name is part of 'iquery') to apply the 717 necessary conversions at the appropriate point. Example: Trying 718 to validate the Web page at 719 http://résumé.example.org would lead to an IRI of 720 http://validator.w3.org/check?uri=http%3A%2F%2Frésumé. 721 example.org, which would convert to a URI of 722 http://validator.w3.org/check?uri=http%3A%2F%2Fr%C3%A9sum%C3%A9. 723 example.org. The server-side implementation is responsible for 724 making the necessary conversions to be able to retrieve the Web 725 page. 727 Note: In this process, characters allowed in URI references and 728 existing percent-encoded sequences are not encoded further. (This 729 mapping is similar to, but different from, the encoding applied 730 when arbitrary content is included in some part of a URI.) For 731 example, an IRI of 732 "http://www.example.org/red%09rosé#red" (in XML notation) is 733 converted to 734 "http://www.example.org/red%09ros%C3%A9#red", not to something 735 like 736 "http%3A%2F%2Fwww.example.org%2Fred%2509ros%C3%A9%23red". 738 3.5. Mapping query components 740 ((NOTE: SEE ISSUES LIST)) For compatibility with existing deployed 741 HTTP infrastructure, the following special case applies for schemes 742 "http" and "https" and IRIs whose origin has a document charset other 743 than one which is UCS-based (e.g., UTF-8 or UTF-16). In such a case, 744 the "query" component of an IRI is mapped into a URI by using the 745 document charset rather than UTF-8 as the binary representation 746 before pct-encoding. This mapping is not applied for any other 747 scheme or component. 749 3.6. Mapping IRIs to URIs 751 The canonical mapping from a IRI to URI is defined by applying the 752 mapping above (from IRI to URI components) and then reassembling a 753 URI from the parsed URI components using the original punctuation 754 that delimited the IRI components. 756 3.7. Converting URIs to IRIs 758 In some situations, for presentation and further processing, it is 759 desirable to convert a URI into an equivalent IRI in which natural 760 characters are represented directly rather than percent encoded. Of 761 course, every URI is already an IRI in its own right without any 762 conversion, and in general there This section gives one such 763 procedure for this conversion. 765 The conversion described in this section, if given a valid URI, will 766 result in an IRI that maps back to the URI used as an input for the 767 conversion (except for potential case differences in percent-encoding 768 and for potential percent-encoded unreserved characters). However, 769 the IRI resulting from this conversion may differ from the original 770 IRI (if there ever was one). 772 URI-to-IRI conversion removes percent-encodings, but not all percent- 773 encodings can be eliminated. There are several reasons for this: 775 1. Some percent-encodings are necessary to distinguish percent- 776 encoded and unencoded uses of reserved characters. 778 2. Some percent-encodings cannot be interpreted as sequences of UTF-8 779 octets. 781 (Note: The octet patterns of UTF-8 are highly regular. Therefore, 782 there is a very high probability, but no guarantee, that percent- 783 encodings that can be interpreted as sequences of UTF-8 octets 784 actually originated from UTF-8. For a detailed discussion, see 785 [Duerst97].) 787 3. The conversion may result in a character that is not appropriate 788 in an IRI. See Section 2.2, Section 4.1, and Section 6.1 for 789 further details. 791 4. IRI to URI conversion has different rules for dealing with domain 792 names and query parameters. 794 Conversion from a URI to an IRI MAY be done by using the following 795 steps: 797 1. Represent the URI as a sequence of octets in US-ASCII. 799 2. Convert all percent-encodings ("%" followed by two hexadecimal 800 digits) to the corresponding octets, except those corresponding to 801 "%", characters in "reserved", and characters in US-ASCII not 802 allowed in URIs. 804 3. Re-percent-encode any octet produced in step 2 that is not part of 805 a strictly legal UTF-8 octet sequence. 807 4. Re-percent-encode all octets produced in step 3 that in UTF-8 808 represent characters that are not appropriate according to 809 Section 2.2, Section 4.1, and Section 6.1. 811 5. Interpret the resulting octet sequence as a sequence of characters 812 encoded in UTF-8. 814 6. URIs known to contain domain names in the reg-name component 815 SHOULD convert punycode-encoded domain name labels to the 816 corresponding characters using the ToUnicode procedure. 818 This procedure will convert as many percent-encoded characters as 819 possible to characters in an IRI. Because there are some choices 820 when step 4 is applied (see Section 6.1), results may vary. 822 Conversions from URIs to IRIs MUST NOT use any character encoding 823 other than UTF-8 in steps 3 and 4, even if it might be possible to 824 guess from the context that another character encoding than UTF-8 was 825 used in the URI. For example, the URI 826 "http://www.example.org/r%E9sum%E9.html" might with some guessing be 827 interpreted to contain two e-acute characters encoded as iso-8859-1. 828 It must not be converted to an IRI containing these e-acute 829 characters. Otherwise, in the future the IRI will be mapped to 830 "http://www.example.org/r%C3%A9sum%C3%A9.html", which is a different 831 URI from "http://www.example.org/r%E9sum%E9.html". 833 3.7.1. Examples 835 This section shows various examples of converting URIs to IRIs. Each 836 example shows the result after each of the steps 1 through 6 is 837 applied. XML Notation is used for the final result. Octets are 838 denoted by "<" followed by two hexadecimal digits followed by ">". 840 The following example contains the sequence "%C3%BC", which is a 841 strictly legal UTF-8 sequence, and which is converted into the actual 842 character U+00FC, LATIN SMALL LETTER U WITH DIAERESIS (also known as 843 u-umlaut). 845 1. http://www.example.org/D%C3%BCrst 847 2. http://www.example.org/Drst 849 3. http://www.example.org/Drst 851 4. http://www.example.org/Drst 853 5. http://www.example.org/Dürst 855 6. http://www.example.org/Dürst 857 The following example contains the sequence "%FC", which might 858 represent U+00FC, LATIN SMALL LETTER U WITH DIAERESIS, in the 859 iso-8859-1 character encoding. (It might represent other characters 860 in other character encodings. For example, the octet in iso- 861 8859-5 represents U+045C, CYRILLIC SMALL LETTER KJE.) Because 862 is not part of a strictly legal UTF-8 sequence, it is re-percent- 863 encoded in step 3. 865 1. http://www.example.org/D%FCrst 867 2. http://www.example.org/Drst 869 3. http://www.example.org/D%FCrst 871 4. http://www.example.org/D%FCrst 873 5. http://www.example.org/D%FCrst 875 6. http://www.example.org/D%FCrst 877 The following example contains "%e2%80%ae", which is the percent- 878 encoded 879 UTF-8 character encoding of U+202E, RIGHT-TO-LEFT OVERRIDE. 880 Section 4.1 forbids the direct use of this character in an IRI. 881 Therefore, the corresponding octets are re-percent-encoded in step 4. 882 This example shows that the case (upper- or lowercase) of letters 883 used in percent-encodings may not be preserved. The example also 884 contains a punycode-encoded domain name label (xn--99zt52a), which is 885 not converted. 887 1. http://xn--99zt52a.example.org/%e2%80%ae 889 2. http://xn--99zt52a.example.org/<80> 891 3. http://xn--99zt52a.example.org/<80> 893 4. http://xn--99zt52a.example.org/%E2%80%AE 895 5. http://xn--99zt52a.example.org/%E2%80%AE 897 6. http://納豆.example.org/%E2%80%AE 899 Note that the label "xn--99zt52a" is converted to U+7D0D U+8C46 900 (Japanese Natto). ((EDITOR NOTE: There is some inconsistency in this 901 note.)) 903 4. Bidirectional IRIs for Right-to-Left Languages 905 Some UCS characters, such as those used in the Arabic and Hebrew 906 scripts, have an inherent right-to-left (rtl) writing direction. 907 IRIs containing these characters (called bidirectional IRIs or Bidi 908 IRIs) require additional attention because of the non-trivial 909 relation between logical representation (used for digital 910 representation and for reading/spelling) and visual representation 911 (used for display/printing). 913 Because of the complex interaction between the logical 914 representation, the visual representation, and the syntax of a Bidi 915 IRI, a balance is needed between various requirements. The main 916 requirements are 918 1. user-predictable conversion between visual and logical 919 representation; 921 2. the ability to include a wide range of characters in various parts 922 of the IRI; and 924 3. minor or no changes or restrictions for implementations. 926 4.1. Logical Storage and Visual Presentation 928 When stored or transmitted in digital representation, bidirectional 929 IRIs MUST be in full logical order and MUST conform to the IRI syntax 930 rules (which includes the rules relevant to their scheme). This 931 ensures that bidirectional IRIs can be processed in the same way as 932 other IRIs. 934 Bidirectional IRIs MUST be rendered by using the Unicode 935 Bidirectional Algorithm [UNIV6], [UNI9]. Bidirectional IRIs MUST be 936 rendered in the same way as they would be if they were in a left-to- 937 right embedding; i.e., as if they were preceded by U+202A, LEFT-TO- 938 RIGHT EMBEDDING (LRE), and followed by U+202C, POP DIRECTIONAL 939 FORMATTING (PDF). Setting the embedding direction can also be done 940 in a higher-level protocol (e.g., the dir='ltr' attribute in HTML). 942 There is no requirement to use the above embedding if the display is 943 still the same without the embedding. For example, a bidirectional 944 IRI in a text with left-to-right base directionality (such as used 945 for English or Cyrillic) that is preceded and followed by whitespace 946 and strong left-to-right characters does not need an embedding. 947 Also, a bidirectional relative IRI reference that only contains 948 strong right-to-left characters and weak characters and that starts 949 and ends with a strong right-to-left character and appears in a text 950 with right-to-left base directionality (such as used for Arabic or 951 Hebrew) and is preceded and followed by whitespace and strong 952 characters does not need an embedding. 954 In some other cases, using U+200E, LEFT-TO-RIGHT MARK (LRM), may be 955 sufficient to force the correct display behavior. However, the 956 details of the Unicode Bidirectional algorithm are not always easy to 957 understand. Implementers are strongly advised to err on the side of 958 caution and to use embedding in all cases where they are not 959 completely sure that the display behavior is unaffected without the 960 embedding. 962 The Unicode Bidirectional Algorithm ([UNI9], section 4.3) permits 963 higher-level protocols to influence bidirectional rendering. Such 964 changes by higher-level protocols MUST NOT be used if they change the 965 rendering of IRIs. 967 The bidirectional formatting characters that may be used before or 968 after the IRI to ensure correct display are not themselves part of 969 the IRI. IRIs MUST NOT contain bidirectional formatting characters 970 (LRM, RLM, LRE, RLE, LRO, RLO, and PDF). They affect the visual 971 rendering of the IRI but do not appear themselves. It would 972 therefore not be possible to input an IRI with such characters 973 correctly. 975 4.2. Bidi IRI Structure 977 The Unicode Bidirectional Algorithm is designed mainly for running 978 text. To make sure that it does not affect the rendering of 979 bidirectional IRIs too much, some restrictions on bidirectional IRIs 980 are necessary. These restrictions are given in terms of delimiters 981 (structural characters, mostly punctuation such as "@", ".", ":", and 982 "/") and components (usually consisting mostly of letters and 983 digits). 985 The following syntax rules from Section 2.2 correspond to components 986 for the purpose of Bidi behavior: iuserinfo, ireg-name, isegment, 987 isegment-nz, isegment-nz-nc, ireg-name, iquery, and ifragment. 989 Specifications that define the syntax of any of the above components 990 MAY divide them further and define smaller parts to be components 991 according to this document. As an example, the restrictions of 992 [RFC3490] on bidirectional domain names correspond to treating each 993 label of a domain name as a component for schemes with ireg-name as a 994 domain name. Even where the components are not defined formally, it 995 may be helpful to think about some syntax in terms of components and 996 to apply the relevant restrictions. For example, for the usual name/ 997 value syntax in query parts, it is convenient to treat each name and 998 each value as a component. As another example, the extensions in a 999 resource name can be treated as separate components. 1001 For each component, the following restrictions apply: 1003 1. A component SHOULD NOT use both right-to-left and left-to-right 1004 characters. 1006 2. A component using right-to-left characters SHOULD start and end 1007 with right-to-left characters. 1009 The above restrictions are given as "SHOULD"s, rather than as 1010 "MUST"s. For IRIs that are never presented visually, they are not 1011 relevant. However, for IRIs in general, they are very important to 1012 ensure consistent conversion between visual presentation and logical 1013 representation, in both directions. 1015 Note: In some components, the above restrictions may actually be 1016 strictly enforced. For example, [RFC3490] requires that these 1017 restrictions apply to the labels of a host name for those schemes 1018 where ireg-name is a host name. In some other components (for 1019 example, path components) following these restrictions may not be 1020 too difficult. For other components, such as parts of the query 1021 part, it may be very difficult to enforce the restrictions because 1022 the values of query parameters may be arbitrary character 1023 sequences. 1025 If the above restrictions cannot be satisfied otherwise, the affected 1026 component can always be mapped to URI notation as described in 1027 Section 3.3. Please note that the whole component has to be mapped 1028 (see also Example 9 below). 1030 4.3. Input of Bidi IRIs 1032 Bidi input methods MUST generate Bidi IRIs in logical order while 1033 rendering them according to Section 4.1. During input, rendering 1034 SHOULD be updated after every new character is input to avoid end- 1035 user confusion. 1037 4.4. Examples 1039 This section gives examples of bidirectional IRIs, in Bidi Notation. 1040 It shows legal IRIs with the relationship between logical and visual 1041 representation and explains how certain phenomena in this 1042 relationship may look strange to somebody not familiar with 1043 bidirectional behavior, but familiar to users of Arabic and Hebrew. 1044 It also shows what happens if the restrictions given in Section 4.2 1045 are not followed. The examples below can be seen at [BidiEx], in 1046 Arabic, Hebrew, and Bidi Notation variants. 1048 To read the bidi text in the examples, read the visual representation 1049 from left to right until you encounter a block of rtl text. Read the 1050 rtl block (including slashes and other special characters) from right 1051 to left, then continue at the next unread ltr character. 1053 Example 1: A single component with rtl characters is inverted: 1054 Logical representation: "http://ab.CDEFGH.ij/kl/mn/op.html" 1055 Visual representation: "http://ab.HGFEDC.ij/kl/mn/op.html" 1056 Components can be read one by one, and each component can be read in 1057 its natural direction. 1059 Example 2: More than one consecutive component with rtl characters is 1060 inverted as a whole: 1061 Logical representation: "http://ab.CDE.FGH/ij/kl/mn/op.html" 1062 Visual representation: "http://ab.HGF.EDC/ij/kl/mn/op.html" 1063 A sequence of rtl components is read rtl, in the same way as a 1064 sequence of rtl words is read rtl in a bidi text. 1066 Example 3: All components of an IRI (except for the scheme) are rtl. 1067 All rtl components are inverted overall: 1068 Logical representation: "http://AB.CD.EF/GH/IJ/KL?MN=OP;QR=ST#UV" 1069 Visual representation: "http://VU#TS=RQ;PO=NM?LK/JI/HG/FE.DC.BA" 1070 The whole IRI (except the scheme) is read rtl. Delimiters between 1071 rtl components stay between the respective components; delimiters 1072 between ltr and rtl components don't move. 1074 Example 4: Each of several sequences of rtl components is inverted on 1075 its own: 1076 Logical representation: "http://AB.CD.ef/gh/IJ/KL.html" 1077 Visual representation: "http://DC.BA.ef/gh/LK/JI.html" 1078 Each sequence of rtl components is read rtl, in the same way as each 1079 sequence of rtl words in an ltr text is read rtl. 1081 Example 5: Example 2, applied to components of different kinds: 1082 Logical representation: "http://ab.cd.EF/GH/ij/kl.html" 1083 Visual representation: "http://ab.cd.HG/FE/ij/kl.html" 1084 The inversion of the domain name label and the path component may be 1085 unexpected, but it is consistent with other bidi behavior. For 1086 reassurance that the domain component really is "ab.cd.EF", it may be 1087 helpful to read aloud the visual representation following the bidi 1088 algorithm. After "http://ab.cd." one reads the RTL block 1089 "E-F-slash-G-H", which corresponds to the logical representation. 1091 Example 6: Same as Example 5, with more rtl components: 1092 Logical representation: "http://ab.CD.EF/GH/IJ/kl.html" 1093 Visual representation: "http://ab.JI/HG/FE.DC/kl.html" 1094 The inversion of the domain name labels and the path components may 1095 be easier to identify because the delimiters also move. 1097 Example 7: A single rtl component includes digits: 1098 Logical representation: "http://ab.CDE123FGH.ij/kl/mn/op.html" 1099 Visual representation: "http://ab.HGF123EDC.ij/kl/mn/op.html" 1100 Numbers are written ltr in all cases but are treated as an additional 1101 embedding inside a run of rtl characters. This is completely 1102 consistent with usual bidirectional text. 1104 Example 8 (not allowed): Numbers are at the start or end of an rtl 1105 component: 1106 Logical representation: "http://ab.cd.ef/GH1/2IJ/KL.html" 1107 Visual representation: "http://ab.cd.ef/LK/JI1/2HG.html" 1108 The sequence "1/2" is interpreted by the bidi algorithm as a 1109 fraction, fragmenting the components and leading to confusion. There 1110 are other characters that are interpreted in a special way close to 1111 numbers; in particular, "+", "-", "#", "$", "%", ",", ".", and ":". 1113 Example 9 (not allowed): The numbers in the previous example are 1114 percent-encoded: 1115 Logical representation: "http://ab.cd.ef/GH%31/%32IJ/KL.html", 1116 Visual representation: "http://ab.cd.ef/LK/JI%32/%31HG.html" 1118 Example 10 (allowed but not recommended): 1119 Logical representation: "http://ab.CDEFGH.123/kl/mn/op.html" 1120 Visual representation: "http://ab.123.HGFEDC/kl/mn/op.html" 1121 Components consisting of only numbers are allowed (it would be rather 1122 difficult to prohibit them), but these may interact with adjacent RTL 1123 components in ways that are not easy to predict. 1125 Example 11 (allowed but not recommended): 1126 Logical representation: "http://ab.CDEFGH.123ij/kl/mn/op.html" 1127 Visual representation: "http://ab.123.HGFEDCij/kl/mn/op.html" 1128 Components consisting of numbers and left-to-right characters are 1129 allowed, but these may interact with adjacent RTL components in ways 1130 that are not easy to predict. 1132 5. Normalization and Comparison 1134 Note: The structure and much of the material for this section is 1135 taken from section 6 of [RFC3986]; the differences are due to the 1136 specifics of IRIs. 1138 One of the most common operations on IRIs is simple comparison: 1139 Determining whether two IRIs are equivalent, without using the IRIs 1140 to access their respective resource(s). A comparison is performed 1141 whenever a response cache is accessed, a browser checks its history 1142 to color a link, or an XML parser processes tags within a namespace. 1143 Extensive normalization prior to comparison of IRIs may be used by 1144 spiders and indexing engines to prune a search space or reduce 1145 duplication of request actions and response storage. 1147 IRI comparison is performed for some particular purpose. Protocols 1148 or implementations that compare IRIs for different purposes will 1149 often be subject to differing design trade-offs in regards to how 1150 much effort should be spent in reducing aliased identifiers. This 1151 section describes various methods that may be used to compare IRIs, 1152 the trade-offs between them, and the types of applications that might 1153 use them. 1155 5.1. Equivalence 1157 Because IRIs exist to identify resources, presumably they should be 1158 considered equivalent when they identify the same resource. However, 1159 this definition of equivalence is not of much practical use, as there 1160 is no way for an implementation to compare two resources to determine 1161 if they are "the same" unless it has full knowledge or control of 1162 them. For this reason, determination of equivalence or difference of 1163 IRIs is based on string comparison, perhaps augmented by reference to 1164 additional rules provided by URI scheme definitions. We use the 1165 terms "different" and "equivalent" to describe the possible outcomes 1166 of such comparisons, but there are many application-dependent 1167 versions of equivalence. 1169 Even when it is possible to determine that two IRIs are equivalent, 1170 IRI comparison is not sufficient to determine whether two IRIs 1171 identify different resources. For example, an owner of two different 1172 domain names could decide to serve the same resource from both, 1173 resulting in two different IRIs. Therefore, comparison methods are 1174 designed to minimize false negatives while strictly avoiding false 1175 positives. 1177 In testing for equivalence, applications should not directly compare 1178 relative references; the references should be converted to their 1179 respective target IRIs before comparison. When IRIs are compared to 1180 select (or avoid) a network action, such as retrieval of a 1181 representation, fragment components (if any) should be excluded from 1182 the comparison. 1184 Applications using IRIs as identity tokens with no relationship to a 1185 protocol MUST use the Simple String Comparison (see Section 5.3.1). 1186 All other applications MUST select one of the comparison practices 1187 from the Comparison Ladder (see Section 5.3. 1189 5.2. Preparation for Comparison 1191 Any kind of IRI comparison REQUIRES that any additional contextual 1192 processing is first performed, including undoing higher-level 1193 escapings or encodings in the protocol or format that carries an IRI. 1194 This preprocessing is usually done when the protocol or format is 1195 parsed. 1197 Examples of contextual preprocessing steps are described in 1198 Section 7. 1200 Examples of such escapings or encodings are entities and numeric 1201 character references in [HTML4] and [XML1]. As an example, 1202 "http://example.org/rosé" (in HTML), 1203 "http://example.org/rosé" (in HTML or XML), and 1204 "http://example.org/rosé" (in HTML or XML) are all resolved into 1205 what is denoted in this document (see Section 1.4) as 1206 "http://example.org/rosé" (the "é" here standing for the 1207 actual e-acute character, to compensate for the fact that this 1208 document cannot contain non-ASCII characters). 1210 Similar considerations apply to encodings such as Transfer Codings in 1211 HTTP (see [RFC2616]) and Content Transfer Encodings in MIME 1212 ([RFC2045]), although in these cases, the encoding is based not on 1213 characters but on octets, and additional care is required to make 1214 sure that characters, and not just arbitrary octets, are compared 1215 (see Section 5.3.1). 1217 5.3. Comparison Ladder 1219 In practice, a variety of methods are used to test IRI equivalence. 1220 These methods fall into a range distinguished by the amount of 1221 processing required and the degree to which the probability of false 1222 negatives is reduced. As noted above, false negatives cannot be 1223 eliminated. In practice, their probability can be reduced, but this 1224 reduction requires more processing and is not cost-effective for all 1225 applications. 1227 If this range of comparison practices is considered as a ladder, the 1228 following discussion will climb the ladder, starting with practices 1229 that are cheap but have a relatively higher chance of producing false 1230 negatives, and proceeding to those that have higher computational 1231 cost and lower risk of false negatives. 1233 5.3.1. Simple String Comparison 1235 If two IRIs, when considered as character strings, are identical, 1236 then it is safe to conclude that they are equivalent. This type of 1237 equivalence test has very low computational cost and is in wide use 1238 in a variety of applications, particularly in the domain of parsing. 1239 It is also used when a definitive answer to the question of IRI 1240 equivalence is needed that is independent of the scheme used and that 1241 can be calculated quickly and without accessing a network. An 1242 example of such a case is XML Namespaces ([XMLNamespace]). 1244 Testing strings for equivalence requires some basic precautions. 1245 This procedure is often referred to as "bit-for-bit" or "byte-for- 1246 byte" comparison, which is potentially misleading. Testing strings 1247 for equality is normally based on pair comparison of the characters 1248 that make up the strings, starting from the first and proceeding 1249 until both strings are exhausted and all characters are found to be 1250 equal, until a pair of characters compares unequal, or until one of 1251 the strings is exhausted before the other. 1253 This character comparison requires that each pair of characters be 1254 put in comparable encoding form. For example, should one IRI be 1255 stored in a byte array in UTF-8 encoding form and the second in a 1256 UTF-16 encoding form, bit-for-bit comparisons applied naively will 1257 produce errors. It is better to speak of equality on a character- 1258 for-character rather than on a byte-for-byte or bit-for-bit basis. 1259 In practical terms, character-by-character comparisons should be done 1260 codepoint by codepoint after conversion to a common character 1261 encoding form. When comparing character by character, the comparison 1262 function MUST NOT map IRIs to URIs, because such a mapping would 1263 create additional spurious equivalences. It follows that an IRI 1264 SHOULD NOT be modified when being transported if there is any chance 1265 that this IRI might be used in a context that uses Simple String 1266 Comparison. 1268 False negatives are caused by the production and use of IRI aliases. 1269 Unnecessary aliases can be reduced, regardless of the comparison 1270 method, by consistently providing IRI references in an already 1271 normalized form (i.e., a form identical to what would be produced 1272 after normalization is applied, as described below). Protocols and 1273 data formats often limit some IRI comparisons to simple string 1274 comparison, based on the theory that people and implementations will, 1275 in their own best interest, be consistent in providing IRI 1276 references, or at least be consistent enough to negate any efficiency 1277 that might be obtained from further normalization. 1279 5.3.2. Syntax-Based Normalization 1281 Implementations may use logic based on the definitions provided by 1282 this specification to reduce the probability of false negatives. 1283 This processing is moderately higher in cost than character-for- 1284 character string comparison. For example, an application using this 1285 approach could reasonably consider the following two IRIs equivalent: 1287 example://a/b/c/%7Bfoo%7D/rosé 1288 eXAMPLE://a/./b/../b/%63/%7bfoo%7d/ros%C3%A9 1290 Web user agents, such as browsers, typically apply this type of IRI 1291 normalization when determining whether a cached response is 1292 available. Syntax-based normalization includes such techniques as 1293 case normalization, character normalization, percent-encoding 1294 normalization, and removal of dot-segments. 1296 5.3.2.1. Case Normalization 1298 For all IRIs, the hexadecimal digits within a percent-encoding 1299 triplet (e.g., "%3a" versus "%3A") are case-insensitive and therefore 1300 should be normalized to use uppercase letters for the digits A-F. 1302 When an IRI uses components of the generic syntax, the component 1303 syntax equivalence rules always apply; namely, that the scheme and 1304 US-ASCII only host are case insensitive and therefore should be 1305 normalized to lowercase. For example, the URI 1306 "HTTP://www.EXAMPLE.com/" is equivalent to "http://www.example.com/". 1307 Case equivalence for non-ASCII characters in IRI components that are 1308 IDNs are discussed in Section 5.3.3. The other generic syntax 1309 components are assumed to be case sensitive unless specifically 1310 defined otherwise by the scheme. 1312 Creating schemes that allow case-insensitive syntax components 1313 containing non-ASCII characters should be avoided. Case 1314 normalization of non-ASCII characters can be culturally dependent and 1315 is always a complex operation. The only exception concerns non-ASCII 1316 host names for which the character normalization includes a mapping 1317 step derived from case folding. 1319 5.3.2.2. Character Normalization 1321 The Unicode Standard [UNIV6] defines various equivalences between 1322 sequences of characters for various purposes. Unicode Standard Annex 1323 #15 [UTR15] defines various Normalization Forms for these 1324 equivalences, in particular Normalization Form C (NFC, Canonical 1325 Decomposition, followed by Canonical Composition) and Normalization 1326 Form KC (NFKC, Compatibility Decomposition, followed by Canonical 1327 Composition). 1329 IRIs already in Unicode MUST NOT be normalized before parsing or 1330 interpreting. In many non-Unicode character encodings, some text 1331 cannot be represented directly. For example, the word "Vietnam" is 1332 natively written "Việt Nam" (containing a LATIN SMALL LETTER E 1333 WITH CIRCUMFLEX AND DOT BELOW) in NFC, but a direct transcoding from 1334 the windows-1258 character encoding leads to "Việt Nam" 1335 (containing a LATIN SMALL LETTER E WITH CIRCUMFLEX followed by a 1336 COMBINING DOT BELOW). Direct transcoding of other 8-bit encodings of 1337 Vietnamese may lead to other representations. 1339 Equivalence of IRIs MUST rely on the assumption that IRIs are 1340 appropriately pre-character-normalized rather than apply character 1341 normalization when comparing two IRIs. The exceptions are conversion 1342 from a non-digital form, and conversion from a non-UCS-based 1343 character encoding to a UCS-based character encoding. In these 1344 cases, NFC or a normalizing transcoder using NFC MUST be used for 1345 interoperability. To avoid false negatives and problems with 1346 transcoding, IRIs SHOULD be created by using NFC. Using NFKC may 1347 avoid even more problems; for example, by choosing half-width Latin 1348 letters instead of full-width ones, and full-width instead of half- 1349 width Katakana. 1351 As an example, "http://www.example.org/résumé.html" (in XML 1352 Notation) is in NFC. On the other hand, 1353 "http://www.example.org/résumé.html" is not in NFC. 1355 The former uses precombined e-acute characters, and the latter uses 1356 "e" characters followed by combining acute accents. Both usages are 1357 defined as canonically equivalent in [UNIV6]. 1359 Note: Because it is unknown how a particular sequence of characters 1360 is being treated with respect to character normalization, it would 1361 be inappropriate to allow third parties to normalize an IRI 1362 arbitrarily. This does not contradict the recommendation that 1363 when a resource is created, its IRI should be as character 1364 normalized as possible (i.e., NFC or even NFKC). This is similar 1365 to the uppercase/lowercase problems. Some parts of a URI are case 1366 insensitive (for example, the domain name). For others, it is 1367 unclear whether they are case sensitive, case insensitive, or 1368 something in between (e.g., case sensitive, but with a multiple 1369 choice selection if the wrong case is used, instead of a direct 1370 negative result). The best recipe is that the creator use a 1371 reasonable capitalization and, when transferring the URI, 1372 capitalization never be changed. 1374 Various IRI schemes may allow the usage of Internationalized Domain 1375 Names (IDN) [RFC5890] either in the ireg-name part or elsewhere. 1376 Character Normalization also applies to IDNs, as discussed in 1377 Section 5.3.3. 1379 5.3.2.3. Percent-Encoding Normalization 1381 The percent-encoding mechanism (Section 2.1 of [RFC3986]) is a 1382 frequent source of variance among otherwise identical IRIs. In 1383 addition to the case normalization issue noted above, some IRI 1384 producers percent-encode octets that do not require percent-encoding, 1385 resulting in IRIs that are equivalent to their nonencoded 1386 counterparts. These IRIs should be normalized by decoding any 1387 percent-encoded octet sequence that corresponds to an unreserved 1388 character, as described in section 2.3 of [RFC3986]. 1390 For actual resolution, differences in percent-encoding (except for 1391 the percent-encoding of reserved characters) MUST always result in 1392 the same resource. For example, "http://example.org/~user", 1393 "http://example.org/%7euser", and "http://example.org/%7Euser", must 1394 resolve to the same resource. 1396 If this kind of equivalence is to be tested, the percent-encoding of 1397 both IRIs to be compared has to be aligned; for example, by 1398 converting both IRIs to URIs (see Section 3.1), eliminating escape 1399 differences in the resulting URIs, and making sure that the case of 1400 the hexadecimal characters in the percent-encoding is always the same 1401 (preferably upper case). If the IRI is to be passed to another 1402 application or used further in some other way, its original form MUST 1403 be preserved. The conversion described here should be performed only 1404 for local comparison. 1406 5.3.2.4. Path Segment Normalization 1408 The complete path segments "." and ".." are intended only for use 1409 within relative references (Section 4.1 of [RFC3986]) and are removed 1410 as part of the reference resolution process (Section 5.2 of 1411 [RFC3986]). However, some implementations may incorrectly assume 1412 that reference resolution is not necessary when the reference is 1413 already an IRI, and thus fail to remove dot-segments when they occur 1414 in non-relative paths. IRI normalizers should remove dot-segments by 1415 applying the remove_dot_segments algorithm to the path, as described 1416 in Section 5.2.4 of [RFC3986]. 1418 5.3.3. Scheme-Based Normalization 1420 The syntax and semantics of IRIs vary from scheme to scheme, as 1421 described by the defining specification for each scheme. 1422 Implementations may use scheme-specific rules, at further processing 1423 cost, to reduce the probability of false negatives. For example, 1424 because the "http" scheme makes use of an authority component, has a 1425 default port of "80", and defines an empty path to be equivalent to 1426 "/", the following four IRIs are equivalent: 1428 http://example.com 1429 http://example.com/ 1430 http://example.com:/ 1431 http://example.com:80/ 1433 In general, an IRI that uses the generic syntax for authority with an 1434 empty path should be normalized to a path of "/". Likewise, an 1435 explicit ":port", for which the port is empty or the default for the 1436 scheme, is equivalent to one where the port and its ":" delimiter are 1437 elided and thus should be removed by scheme-based normalization. For 1438 example, the second IRI above is the normal form for the "http" 1439 scheme. 1441 Another case where normalization varies by scheme is in the handling 1442 of an empty authority component or empty host subcomponent. For many 1443 scheme specifications, an empty authority or host is considered an 1444 error; for others, it is considered equivalent to "localhost" or the 1445 end-user's host. When a scheme defines a default for authority and 1446 an IRI reference to that default is desired, the reference should be 1447 normalized to an empty authority for the sake of uniformity, brevity, 1448 and internationalization. If, however, either the userinfo or port 1449 subcomponents are non-empty, then the host should be given explicitly 1450 even if it matches the default. 1452 Normalization should not remove delimiters when their associated 1453 component is empty unless it is licensed to do so by the scheme 1454 specification. For example, the IRI "http://example.com/?" cannot be 1455 assumed to be equivalent to any of the examples above. Likewise, the 1456 presence or absence of delimiters within a userinfo subcomponent is 1457 usually significant to its interpretation. The fragment component is 1458 not subject to any scheme-based normalization; thus, two IRIs that 1459 differ only by the suffix "#" are considered different regardless of 1460 the scheme. 1462 Some IRI schemes allow the usage of Internationalized Domain Names 1463 (IDN) [RFC5890] either in their ireg-name part or elswhere. When in 1464 use in IRIs, those names SHOULD conform to the definition of U-Label 1465 in [RFC5890]. An IRI containing an invalid IDN cannot successfully 1466 be resolved. For legibility purposes, they SHOULD NOT be converted 1467 into ASCII Compatible Encoding (ACE). 1469 Scheme-based normalization may also consider IDN components and their 1470 conversions to punycode as equivalent. As an example, 1471 "http://résumé.example.org" may be considered equivalent to 1472 "http://xn--rsum-bpad.example.org". 1474 Other scheme-specific normalizations are possible. 1476 5.3.4. Protocol-Based Normalization 1478 Substantial effort to reduce the incidence of false negatives is 1479 often cost-effective for web spiders. Consequently, they implement 1480 even more aggressive techniques in IRI comparison. For example, if 1481 they observe that an IRI such as 1483 http://example.com/data 1485 redirects to an IRI differing only in the trailing slash 1487 http://example.com/data/ 1489 they will likely regard the two as equivalent in the future. This 1490 kind of technique is only appropriate when equivalence is clearly 1491 indicated by both the result of accessing the resources and the 1492 common conventions of their scheme's dereference algorithm (in this 1493 case, use of redirection by HTTP origin servers to avoid problems 1494 with relative references). 1496 6. Use of IRIs 1498 6.1. Limitations on UCS Characters Allowed in IRIs 1500 This section discusses limitations on characters and character 1501 sequences usable for IRIs beyond those given in Section 2.2 and 1502 Section 4.1. The considerations in this section are relevant when 1503 IRIs are created and when URIs are converted to IRIs. 1505 a. The repertoire of characters allowed in each IRI component is 1506 limited by the definition of that component. For example, the 1507 definition of the scheme component does not allow characters 1508 beyond US-ASCII. 1510 (Note: In accordance with URI practice, generic IRI software 1511 cannot and should not check for such limitations.) 1513 b. The UCS contains many areas of characters for which there are 1514 strong visual look-alikes. Because of the likelihood of 1515 transcription errors, these also should be avoided. This includes 1516 the full-width equivalents of Latin characters, half-width 1517 Katakana characters for Japanese, and many others. It also 1518 includes many look-alikes of "space", "delims", and "unwise", 1519 characters excluded in [RFC3491]. 1521 Additional information is available from [UNIXML]. [UNIXML] is 1522 written in the context of running text rather than in that of 1523 identifiers. Nevertheless, it discusses many of the categories of 1524 characters not appropriate for IRIs. 1526 6.2. Software Interfaces and Protocols 1528 Although an IRI is defined as a sequence of characters, software 1529 interfaces for URIs typically function on sequences of octets or 1530 other kinds of code units. Thus, software interfaces and protocols 1531 MUST define which character encoding is used. 1533 Intermediate software interfaces between IRI-capable components and 1534 URI-only components MUST map the IRIs per Section 3.6, when 1535 transferring from IRI-capable to URI-only components. This mapping 1536 SHOULD be applied as late as possible. It SHOULD NOT be applied 1537 between components that are known to be able to handle IRIs. 1539 6.3. Format of URIs and IRIs in Documents and Protocols 1541 Document formats that transport URIs may have to be upgraded to allow 1542 the transport of IRIs. In cases where the document as a whole has a 1543 native character encoding, IRIs MUST also be encoded in this 1544 character encoding and converted accordingly by a parser or 1545 interpreter. IRI characters not expressible in the native character 1546 encoding SHOULD be escaped by using the escaping conventions of the 1547 document format if such conventions are available. Alternatively, 1548 they MAY be percent-encoded according to Section 3.6. For example, 1549 in HTML or XML, numeric character references SHOULD be used. If a 1550 document as a whole has a native character encoding and that 1551 character encoding is not UTF-8, then IRIs MUST NOT be placed into 1552 the document in the UTF-8 character encoding. 1554 ((UPDATE THIS NOTE)) Note: Some formats already accommodate IRIs, 1555 although they use different terminology. HTML 4.0 [HTML4] defines 1556 the conversion from IRIs to URIs as error-avoiding behavior. XML 1.0 1557 [XML1], XLink [XLink], XML Schema [XMLSchema], and specifications 1558 based upon them allow IRIs. Also, it is expected that all relevant 1559 new W3C formats and protocols will be required to handle IRIs 1560 [CharMod]. 1562 6.4. Use of UTF-8 for Encoding Original Characters 1564 This section discusses details and gives examples for point c) in 1565 Section 1.2. To be able to use IRIs, the URI corresponding to the 1566 IRI in question has to encode original characters into octets by 1567 using UTF-8. This can be specified for all URIs of a URI scheme or 1568 can apply to individual URIs for schemes that do not specify how to 1569 encode original characters. It can apply to the whole URI, or only 1570 to some part. For background information on encoding characters into 1571 URIs, see also Section 2.5 of [RFC3986]. 1573 For new URI schemes, using UTF-8 is recommended in [RFC4395bis]. 1574 Examples where UTF-8 is already used are the URN syntax [RFC2141], 1575 IMAP URLs [RFC2192], and POP URLs [RFC2384]. On the other hand, 1576 because the HTTP URI scheme does not specify how to encode original 1577 characters, only some HTTP URLs can have corresponding but different 1578 IRIs. 1580 For example, for a document with a URI of 1581 "http://www.example.org/r%C3%A9sum%C3%A9.html", it is possible to 1582 construct a corresponding IRI (in XML notation, see Section 1.4): 1583 "http://www.example.org/résumé.html" ("é" stands for 1584 the e-acute character, and "%C3%A9" is the UTF-8 encoded and percent- 1585 encoded representation of that character). On the other hand, for a 1586 document with a URI of "http://www.example.org/r%E9sum%E9.html", the 1587 percent-encoding octets cannot be converted to actual characters in 1588 an IRI, as the percent-encoding is not based on UTF-8. 1590 For most URI schemes, there is no need to upgrade their scheme 1591 definition in order for them to work with IRIs. The main case where 1592 upgrading makes sense is when a scheme definition, or a particular 1593 component of a scheme, is strictly limited to the use of US-ASCII 1594 characters with no provision to include non-ASCII characters/octets 1595 via percent-encoding, or if a scheme definition currently uses highly 1596 scheme-specific provisions for the encoding of non-ASCII characters. 1597 An example of this is the mailto: scheme [RFC2368]. 1599 This specification updates the IANA registry of URI schemes to note 1600 their applicability to IRIs, see Section 9. All IRIs use URI 1601 schemes, and all URIs with URI schemes can be used as IRIs, even 1602 though in some cases only by using URIs directly as IRIs, without any 1603 conversion. 1605 Scheme definitions can impose restrictions on the syntax of scheme- 1606 specific URIs; i.e., URIs that are admissible under the generic URI 1607 syntax [RFC3986] may not be admissible due to narrower syntactic 1608 constraints imposed by a URI scheme specification. URI scheme 1609 definitions cannot broaden the syntactic restrictions of the generic 1610 URI syntax; otherwise, it would be possible to generate URIs that 1611 satisfied the scheme-specific syntactic constraints without 1612 satisfying the syntactic constraints of the generic URI syntax. 1613 However, additional syntactic constraints imposed by URI scheme 1614 specifications are applicable to IRI, as the corresponding URI 1615 resulting from the mapping defined in Section 3.6 MUST be a valid URI 1616 under the syntactic restrictions of generic URI syntax and any 1617 narrower restrictions imposed by the corresponding URI scheme 1618 specification. 1620 The requirement for the use of UTF-8 generally applies to all parts 1621 of a URI. However, it is possible that the capability of IRIs to 1622 represent a wide range of characters directly is used just in some 1623 parts of the IRI (or IRI reference). The other parts of the IRI may 1624 only contain US-ASCII characters, or they may not be based on UTF-8. 1625 They may be based on another character encoding, or they may directly 1626 encode raw binary data (see also [RFC2397]). 1628 For example, it is possible to have a URI reference of 1629 "http://www.example.org/r%E9sum%E9.xml#r%C3%A9sum%C3%A9", where the 1630 document name is encoded in iso-8859-1 based on server settings, but 1631 where the fragment identifier is encoded in UTF-8 according to 1633 [XPointer]. The IRI corresponding to the above URI would be (in XML 1634 notation) 1635 "http://www.example.org/r%E9sum%E9.xml#résumé". 1637 Similar considerations apply to query parts. The functionality of 1638 IRIs (namely, to be able to include non-ASCII characters) can only be 1639 used if the query part is encoded in UTF-8. 1641 6.5. Relative IRI References 1643 Processing of relative IRI references against a base is handled 1644 straightforwardly; the algorithms of [RFC3986] can be applied 1645 directly, treating the characters additionally allowed in IRI 1646 references in the same way that unreserved characters are in URI 1647 references. 1649 7. Liberal Handling of Otherwise Invalid IRIs 1651 (EDITOR NOTE: This Section may move to an appendix.) Some technical 1652 specifications and widely-deployed software have allowed additional 1653 variations and extensions of IRIs to be used in syntactic components. 1654 This section describes two widely-used preprocessing agreements. 1655 Other technical specifications may wish to reference a syntactic 1656 component which is "a valid IRI or a string that will map to a valid 1657 IRI after this preprocessing algorithm". These two variants are 1658 known as Legacy Extended IRI or LEIRI [LEIRI], and Web Address 1659 [HTML5]). 1661 Future technical specifications SHOULD NOT allow conforming producers 1662 to produce, or conforming content to contain, such forms, as they are 1663 not interoperable with other IRI consuming software. 1665 7.1. LEIRI Processing 1667 This section defines Legacy Extended IRIs (LEIRIs). The syntax of 1668 Legacy Extended IRIs is the same as that for , except 1669 that the ucschar production is replaced by the leiri-ucschar 1670 production: 1672 leiri-ucschar = " " / "<" / ">" / '"' / "{" / "}" / "|" 1673 / "\" / "^" / "`" / %x0-1F / %x7F-D7FF 1674 / %xE000-FFFD / %x10000-10FFFF 1676 Among other extensions, processors based on this specification also 1677 did not enforce the restriction on bidirectional formatting 1678 characters in Section 4.1, and the iprivate production becomes 1679 redundant. 1681 To convert a string allowed as a LEIRI to an IRI, each character 1682 allowed in leiri-ucschar but not in ucschar must be percent-encoded 1683 using Section 3.3. 1685 7.2. Web Address Processing 1687 Many popular web browsers have taken the approach of being quite 1688 liberal in what is accepted as a "URL" or its relative forms. This 1689 section describes their behavior in terms of a preprocessor which 1690 maps strings into the IRI space for subsequent parsing and 1691 interpretation as an IRI. 1693 In some situations, it might be appropriate to describe the syntax 1694 that a liberal consumer implementation might accept as a "Web 1695 Address" or "Hypertext Reference" or "HREF". However, technical 1696 specifications SHOULD restrict the syntactic form allowed by 1697 compliant producers to the IRI or IRI reference syntax defined in 1698 this document even if they want to mandate this processing. 1700 Summary: 1702 o Leading and trailing whitespace is removed. 1704 o Some additional characters are removed. 1706 o Some additional characters are allowed and escaped (as with 1707 LEIRI). 1709 o If interpreting an IRI as a URI, the pct-encoding of the query 1710 component of the parsed URI component depends on operational 1711 context. 1713 Each string provided may have an associated charset (called the HREF- 1714 charset here); this defaults to UTF-8. For web browsers interpreting 1715 HTML, the document charset of a string is determined: 1717 If the string came from a script (e.g. as an argument to a method) 1718 The HRef-charset is the script's charset. 1720 If the string came from a DOM node (e.g. from an element) The node 1721 has a Document, and the HRef-charset is the Document's character 1722 encoding. 1724 If the string had a HRef-charset defined when the string was created 1725 or defined The HRef-charset is as defined. 1727 If the resulting HRef-charset is a unicode based character encoding 1728 (e.g., UTF-16), then use UTF-8 instead. 1730 The syntax for Web Addresses is obtained by replacing the 'ucschar', 1731 pct-form, path-sep, and ifragment rules with the href-ucschar, href- 1732 pct-form, href-path-sep, and href-ifragment rules below. In 1733 addition, some characters are stripped. 1735 href-ucschar = " " / "<" / ">" / DQUOTE / "{" / "}" / "|" 1736 / "\" / "^" / "`" / %x0-1F / %x7F-D7FF 1737 / %xE000-FFFD / %x10000-10FFFF 1738 href-pct-form = pct-encoded / "%" 1739 href-path-sep = "/" / "\" 1740 href-ifragment = *( ipchar / "/" / "?" / "#" ) ; adding "#" 1741 href-strip = 1743 (NOTE: NEED TO FIX THESE SETS TO MATCH HTML5; NOT SURE ABOUT NEXT 1744 SENTENCE) browsers did not enforce the restriction on bidirectional 1745 formatting characters in Section 4.1, and the iprivate production 1746 becomes redundant. 1748 'Web Address processing' requires the following additional 1749 preprocessing steps: 1751 1. Leading and trailing instances of space (U+0020), CR (U+000A), LF 1752 (U+000D), and TAB (U+0009) characters are removed. 1754 2. strip all characters in href-strip. 1756 3. Percent-encode all characters in href-ucschar not in ucschar. 1758 4. Replace occurrences of "%" not followed by two hexadecimal digits 1759 by "%25". 1761 5. Convert backslashes ('\') matching href-path-sep to forward 1762 slashes ('/'). 1764 7.3. Characters Not Allowed in IRIs 1766 This section provides a list of the groups of characters and code 1767 points that are allowed by LEIRI or HREF but are not allowed in IRIs 1768 or are allowed in IRIs only in the query part. For each group of 1769 characters, advice on the usage of these characters is also given, 1770 concentrating on the reasons for why they are excluded from IRI use. 1772 Space (U+0020): Some formats and applications use space as a 1773 delimiter, e.g. for items in a list. Appendix C of [RFC3986] also 1774 mentions that white space may have to be added when displaying or 1775 printing long URIs; the same applies to long IRIs. This means 1776 that spaces can disappear, or can make the what is intended as a 1777 single IRI or IRI reference to be treated as two or more separate 1778 IRIs. 1780 Delimiters "<" (U+003C), ">" (U+003E), and '"' (U+0022): Appendix 1781 C of [RFC3986] suggests the use of double-quotes 1782 ("http://example.com/") and angle brackets () 1783 as delimiters for URIs in plain text. These conventions are often 1784 used, and also apply to IRIs. Using these characters in strings 1785 intended to be IRIs would result in the IRIs being cut off at the 1786 wrong place. 1788 Unwise characters "\" (U+005C), "^" (U+005E), "`" (U+0060), "{" 1789 (U+007B), "|" (U+007C), and "}" (U+007D): These characters 1790 originally have been excluded from URIs because the respective 1791 codepoints are assigned to different graphic characters in some 1792 7-bit or 8-bit encoding. Despite the move to Unicode, some of 1793 these characters are still occasionally displayed differently on 1794 some systems, e.g. U+005C may appear as a Japanese Yen symbol on 1795 some systems. Also, the fact that these characters are not used 1796 in URIs or IRIs has encouraged their use outside URIs or IRIs in 1797 contexts that may include URIs or IRIs. If a string with such a 1798 character were used as an IRI in such a context, it would likely 1799 be interpreted piecemeal. 1801 The controls (C0 controls, DEL, and C1 controls, #x0 - #x1F #x7F - 1802 #x9F): There is generally no way to transmit these characters 1803 reliably as text outside of a charset encoding. Even when in 1804 encoded form, many software components silently filter out some of 1805 these characters, or may stop processing alltogether when 1806 encountering some of them. These characters may affect text 1807 display in subtle, unnoticable ways or in drastic, global, and 1808 irreversible ways depending on the hardware and software involved. 1809 The use of some of these characters would allow malicious users to 1810 manipulate the display of an IRI and its context in many 1811 situations. 1813 Bidi formatting characters (U+200E, U+200F, U+202A-202E): These 1814 characters affect the display ordering of characters. If IRIs 1815 were allowed to contain these characters and the resulting visual 1816 display transcribed. they could not be converted back to 1817 electronic form (logical order) unambiguously. These characters, 1818 if allowed in IRIs, might allow malicious users to manipulate the 1819 display of IRI and its context. 1821 Specials (U+FFF0-FFFD): These code points provide functionality 1822 beyond that useful in an IRI, for example byte order 1823 identification, annotation, and replacements for unknown 1824 characters and objects. Their use and interpretation in an IRI 1825 would serve no purpose and might lead to confusing display 1826 variations. 1828 Private use code points (U+E000-F8FF, U+F0000-FFFFD, U+100000- 1829 10FFFD): Display and interpretation of these code points is by 1830 definition undefined without private agreement. Therefore, these 1831 code points are not suited for use on the Internet. They are not 1832 interoperable and may have unpredictable effects. 1834 Tags (U+E0000-E0FFF): These characters provide a way to language 1835 tag in Unicode plain text. They are not appropriate for IRIs 1836 because language information in identifiers cannot reliably be 1837 input, transmitted (e.g. on a visual medium such as paper), or 1838 recognized. 1840 Non-characters (U+FDD0-FDEF, U+1FFFE-1FFFF, U+2FFFE-2FFFF, 1841 U+3FFFE-3FFFF, U+4FFFE-4FFFF, U+5FFFE-5FFFF, U+6FFFE-6FFFF, 1842 U+7FFFE-7FFFF, U+8FFFE-8FFFF, U+9FFFE-9FFFF, U+AFFFE-AFFFF, 1843 U+BFFFE-BFFFF, U+CFFFE-CFFFF, U+DFFFE-DFFFF, U+EFFFE-EFFFF, 1844 U+FFFFE-FFFFF, U+10FFFE-10FFFF): These code points are defined as 1845 non-characters. Applications may use some of them internally, but 1846 are not prepared to interchange them. 1848 LEIRI preprocessing disallowed some code points and code units: 1850 Surrogate code units (D800-DFFF): These do not represent Unicode 1851 codepoints. 1853 8. URI/IRI Processing Guidelines (Informative) 1855 This informative section provides guidelines for supporting IRIs in 1856 the same software components and operations that currently process 1857 URIs: Software interfaces that handle URIs, software that allows 1858 users to enter URIs, software that creates or generates URIs, 1859 software that displays URIs, formats and protocols that transport 1860 URIs, and software that interprets URIs. These may all require 1861 modification before functioning properly with IRIs. The 1862 considerations in this section also apply to URI references and IRI 1863 references. 1865 8.1. URI/IRI Software Interfaces 1867 Software interfaces that handle URIs, such as URI-handling APIs and 1868 protocols transferring URIs, need interfaces and protocol elements 1869 that are designed to carry IRIs. 1871 In case the current handling in an API or protocol is based on US- 1872 ASCII, UTF-8 is recommended as the character encoding for IRIs, as it 1873 is compatible with US-ASCII, is in accordance with the 1874 recommendations of [RFC2277], and makes converting to URIs easy. In 1875 any case, the API or protocol definition must clearly define the 1876 character encoding to be used. 1878 The transfer from URI-only to IRI-capable components requires no 1879 mapping, although the conversion described in Section 3.7 above may 1880 be performed. It is preferable not to perform this inverse 1881 conversion unless it is certain this can be done correctly. 1883 8.2. URI/IRI Entry 1885 Some components allow users to enter URIs into the system by typing 1886 or dictation, for example. This software must be updated to allow 1887 for IRI entry. 1889 A person viewing a visual representation of an IRI (as a sequence of 1890 glyphs, in some order, in some visual display) or hearing an IRI will 1891 use an entry method for characters in the user's language to input 1892 the IRI. Depending on the script and the input method used, this may 1893 be a more or less complicated process. 1895 The process of IRI entry must ensure, as much as possible, that the 1896 restrictions defined in Section 2.2 are met. This may be done by 1897 choosing appropriate input methods or variants/settings thereof, by 1898 appropriately converting the characters being input, by eliminating 1899 characters that cannot be converted, and/or by issuing a warning or 1900 error message to the user. 1902 As an example of variant settings, input method editors for East 1903 Asian Languages usually allow the input of Latin letters and related 1904 characters in full-width or half-width versions. For IRI input, the 1905 input method editor should be set so that it produces half-width 1906 Latin letters and punctuation and full-width Katakana. 1908 An input field primarily or solely used for the input of URIs/IRIs 1909 might allow the user to view an IRI as it is mapped to a URI. Places 1910 where the input of IRIs is frequent may provide the possibility for 1911 viewing an IRI as mapped to a URI. This will help users when some of 1912 the software they use does not yet accept IRIs. 1914 An IRI input component interfacing to components that handle URIs, 1915 but not IRIs, must map the IRI to a URI before passing it to these 1916 components. 1918 For the input of IRIs with right-to-left characters, please see 1919 Section 4.3. 1921 8.3. URI/IRI Transfer between Applications 1923 Many applications (for example, mail user agents) try to detect URIs 1924 appearing in plain text. For this, they use some heuristics based on 1925 URI syntax. They then allow the user to click on such URIs and 1926 retrieve the corresponding resource in an appropriate (usually 1927 scheme-dependent) application. 1929 Such applications would need to be upgraded, in order to use the IRI 1930 syntax as a base for heuristics. In particular, a non-ASCII 1931 character should not be taken as the indication of the end of an IRI. 1932 Such applications also would need to make sure that they correctly 1933 convert the detected IRI from the character encoding of the document 1934 or application where the IRI appears, to the character encoding used 1935 by the system-wide IRI invocation mechanism, or to a URI (according 1936 to Section 3.6) if the system-wide invocation mechanism only accepts 1937 URIs. 1939 The clipboard is another frequently used way to transfer URIs and 1940 IRIs from one application to another. On most platforms, the 1941 clipboard is able to store and transfer text in many languages and 1942 scripts. Correctly used, the clipboard transfers characters, not 1943 octets, which will do the right thing with IRIs. 1945 8.4. URI/IRI Generation 1947 Systems that offer resources through the Internet, where those 1948 resources have logical names, sometimes automatically generate URIs 1949 for the resources they offer. For example, some HTTP servers can 1950 generate a directory listing for a file directory and then respond to 1951 the generated URIs with the files. 1953 Many legacy character encodings are in use in various file systems. 1954 Many currently deployed systems do not transform the local character 1955 representation of the underlying system before generating URIs. 1957 For maximum interoperability, systems that generate resource 1958 identifiers should make the appropriate transformations. For 1959 example, if a file system contains a file named "résum&# 1960 xE9;.html", a server should expose this as "r%C3%A9sum%C3%A9.html" in 1961 a URI, which allows use of "résumé.html" in an IRI, even if 1962 locally the file name is kept in a character encoding other than 1963 UTF-8. 1965 This recommendation particularly applies to HTTP servers. For FTP 1966 servers, similar considerations apply; see [RFC2640]. 1968 8.5. URI/IRI Selection 1970 In some cases, resource owners and publishers have control over the 1971 IRIs used to identify their resources. This control is mostly 1972 executed by controlling the resource names, such as file names, 1973 directly. 1975 In these cases, it is recommended to avoid choosing IRIs that are 1976 easily confused. For example, for US-ASCII, the lower-case ell ("l") 1977 is easily confused with the digit one ("1"), and the upper-case oh 1978 ("O") is easily confused with the digit zero ("0"). Publishers 1979 should avoid confusing users with "br0ken" or "1ame" identifiers. 1981 Outside the US-ASCII repertoire, there are many more opportunities 1982 for confusion; a complete set of guidelines is too lengthy to include 1983 here. As long as names are limited to characters from a single 1984 script, native writers of a given script or language will know best 1985 when ambiguities can appear, and how they can be avoided. What may 1986 look ambiguous to a stranger may be completely obvious to the average 1987 native user. On the other hand, in some cases, the UCS contains 1988 variants for compatibility reasons; for example, for typographic 1989 purposes. These should be avoided wherever possible. Although there 1990 may be exceptions, newly created resource names should generally be 1991 in NFKC [UTR15] (which means that they are also in NFC). 1993 As an example, the UCS contains the "fi" ligature at U+FB01 for 1994 compatibility reasons. Wherever possible, IRIs should use the two 1995 letters "f" and "i" rather than the "fi" ligature. An example where 1996 the latter may be used is in the query part of an IRI for an explicit 1997 search for a word written containing the "fi" ligature. 1999 In certain cases, there is a chance that characters from different 2000 scripts look the same. The best known example is the similarity of 2001 the Latin "A", the Greek "Alpha", and the Cyrillic "A". To avoid 2002 such cases, IRIs should only be created where all the characters in a 2003 single component are used together in a given language. This usually 2004 means that all of these characters will be from the same script, but 2005 there are languages that mix characters from different scripts (such 2006 as Japanese). This is similar to the heuristics used to distinguish 2007 between letters and numbers in the examples above. Also, for Latin, 2008 Greek, and Cyrillic, using lowercase letters results in fewer 2009 ambiguities than using uppercase letters would. 2011 8.6. Display of URIs/IRIs 2013 In situations where the rendering software is not expected to display 2014 non-ASCII parts of the IRI correctly using the available layout and 2015 font resources, these parts should be percent-encoded before being 2016 displayed. 2018 For display of Bidi IRIs, please see Section 4.1. 2020 8.7. Interpretation of URIs and IRIs 2022 Software that interprets IRIs as the names of local resources should 2023 accept IRIs in multiple forms and convert and match them with the 2024 appropriate local resource names. 2026 First, multiple representations include both IRIs in the native 2027 character encoding of the protocol and also their URI counterparts. 2029 Second, it may include URIs constructed based on character encodings 2030 other than UTF-8. These URIs may be produced by user agents that do 2031 not conform to this specification and that use legacy character 2032 encodings to convert non-ASCII characters to URIs. Whether this is 2033 necessary, and what character encodings to cover, depends on a number 2034 of factors, such as the legacy character encodings used locally and 2035 the distribution of various versions of user agents. For example, 2036 software for Japanese may accept URIs in Shift_JIS and/or EUC-JP in 2037 addition to UTF-8. 2039 Third, it may include additional mappings to be more user-friendly 2040 and robust against transmission errors. These would be similar to 2041 how some servers currently treat URIs as case insensitive or perform 2042 additional matching to account for spelling errors. For characters 2043 beyond the US-ASCII repertoire, this may, for example, include 2044 ignoring the accents on received IRIs or resource names. Please note 2045 that such mappings, including case mappings, are language dependent. 2047 It can be difficult to identify a resource unambiguously if too many 2048 mappings are taken into consideration. However, percent-encoded and 2049 not percent-encoded parts of IRIs can always be clearly 2050 distinguished. Also, the regularity of UTF-8 (see [Duerst97]) makes 2051 the potential for collisions lower than it may seem at first. 2053 8.8. Upgrading Strategy 2055 Where this recommendation places further constraints on software for 2056 which many instances are already deployed, it is important to 2057 introduce upgrades carefully and to be aware of the various 2058 interdependencies. 2060 If IRIs cannot be interpreted correctly, they should not be created, 2061 generated, or transported. This suggests that upgrading URI 2062 interpreting software to accept IRIs should have highest priority. 2064 On the other hand, a single IRI is interpreted only by a single or 2065 very few interpreters that are known in advance, although it may be 2066 entered and transported very widely. 2068 Therefore, IRIs benefit most from a broad upgrade of software to be 2069 able to enter and transport IRIs. However, before an individual IRI 2070 is published, care should be taken to upgrade the corresponding 2071 interpreting software in order to cover the forms expected to be 2072 received by various versions of entry and transport software. 2074 The upgrade of generating software to generate IRIs instead of using 2075 a local character encoding should happen only after the service is 2076 upgraded to accept IRIs. Similarly, IRIs should only be generated 2077 when the service accepts IRIs and the intervening infrastructure and 2078 protocol is known to transport them safely. 2080 Software converting from URIs to IRIs for display should be upgraded 2081 only after upgraded entry software has been widely deployed to the 2082 population that will see the displayed result. 2084 Where there is a free choice of character encodings, it is often 2085 possible to reduce the effort and dependencies for upgrading to IRIs 2086 by using UTF-8 rather than another encoding. For example, when a new 2087 file-based Web server is set up, using UTF-8 as the character 2088 encoding for file names will make the transition to IRIs easier. 2089 Likewise, when a new Web form is set up using UTF-8 as the character 2090 encoding of the form page, the returned query URIs will use UTF-8 as 2091 the character encoding (unless the user, for whatever reason, changes 2092 the character encoding) and will therefore be compatible with IRIs. 2094 These recommendations, when taken together, will allow for the 2095 extension from URIs to IRIs in order to handle characters other than 2096 US-ASCII while minimizing interoperability problems. For 2097 considerations regarding the upgrade of URI scheme definitions, see 2098 Section 6.4. 2100 9. IANA Considerations 2102 RFC Editor and IANA note: Please Replace RFC XXXX with the number of 2103 this document when it issues as an RFC. 2105 IANA maintains a registry of "URI schemes". A "URI scheme" also 2106 serves an "IRI scheme". 2108 To clarify that the URI scheme registration process also applies to 2109 IRIs, change the description of the "URI schemes" registry header to 2110 say "[RFC4395] defines an IANA-maintained registry of URI Schemes. 2112 These registries include the Permanent and Provisional URI Schemes. 2113 RFC XXXX updates this registry to designate that schemes may also 2114 indicate their usability as IRI schemes. 2116 Update "per RFC 4395" to "per RFC 4395 and RFC XXXX". 2118 10. Security Considerations 2120 The security considerations discussed in [RFC3986] also apply to 2121 IRIs. In addition, the following issues require particular care for 2122 IRIs. 2124 Incorrect encoding or decoding can lead to security problems. For 2125 example, some UTF-8 decoders do not check against overlong byte 2126 sequences. See [UTR36] Section 3 for details. 2128 There are serious difficulties with relying on a human to verify that 2129 a an IRI (whether presented visually or aurally) is the same as 2130 another IRI or is the one intended. These problems exist with ASCII- 2131 only URIs (bl00mberg.com vs. bloomberg.com) but are strongly 2132 exacerbated when using the much larger character repertoire of 2133 Unicode. For details, see Section 2 of [UTR36]. Using 2134 administrative and technical means to reduce the availability of such 2135 exploits is possible, but they are difficult to eliminate altogether. 2136 User agents SHOULD NOT rely on visual or perceptual comparison or 2137 verification of IRIs as a means of validating or assuring safety, 2138 correctness or appropriateness of an IRI. Other means of presenting 2139 users with the validity, safety, or appropriateness of visited sites 2140 are being developed in the browser community as an alternative means 2141 of avoiding these difficulties. 2143 Besides the large character repertoire of Unicode, reasons for 2144 confusion include different forms of normalization and different 2145 normalization expectations, use of percent-encoding with various 2146 legacy encodings, and bidirectionality issues. See also [UTR36]. 2148 Confusion can occur in various IRI components, such as the domain 2149 name part or the path part, or between IRI components. For 2150 considerations specific to the domain name part, see [RFC5890]. For 2151 considerations specific to particular protocols or schemes, see the 2152 security sections of the relevant specifications and registration 2153 templates. Administrators of sites that allow independent users to 2154 create resources in the same sub area have to be careful. Details 2155 are discussed in Section 8.5. 2157 Confusion can occur with bidirectional IRIs, if the restrictions in 2158 Section 4.2 are not followed. The same visual representation may be 2159 interpreted as different logical representations, and vice versa. It 2160 is also very important that a correct Unicode bidirectional 2161 implementation be used. 2163 The characters additionally allowed in Legacy Extended IRIs introduce 2164 additional security issues. For details, see Section 7.3. 2166 11. Acknowledgements 2168 This document was derived from [RFC3987]; the acknowledgments from 2169 that specification still apply. 2171 We would like to thank Ian Hickson, Michael Sperberg-McQueen, and Dan 2172 Connolly for their work on HyperText References, and Norman Walsh, 2173 Richard Tobin, Henry S. Thomson, John Cowan, Paul Grosso, and the XML 2174 Core Working Group of the W3C for their work on LEIRIs. 2176 In addition, this document was influenced by contributions from (in 2177 no particular order) Chris Lilley, Bjoern Hoehrmann, Felix Sasaki, 2178 Jeremy Carroll, Frank Ellermann, Michael Everson, Cary Karp, 2179 Matitiahu Allouche, Richard Ishida, Addison Phillips, Jonathan 2180 Rosenne, Najib Tounsi, Debbie Garside, Mark Davis, Sarmad Hussain, 2181 Ted Hardie, Konrad Lanz, Thomas Roessler, Lisa Dusseault, Julian 2182 Reschke, Giovanni Campagna, Anne van Kesteren, Mark Nottingham, Erik 2183 van der Poel, Marcin Hanclik, Marcos Caceres, Roy Fielding, Greg 2184 Wilkins, Pieter Hintjens, Daniel R. Tobias, Marko Martin, Maciej 2185 Stanchowiak, Wil Tan, Yui Naruse, Michael A. Puls II, Dave Thaler, 2186 Tom Petch, John Klensin, Shawn Steele, Peter Saint-Andre, Geoffrey 2187 Sneddon, Chris Weber, Alex Melnikov, Slim Amamou, SM, Tim Berners- 2188 Lee, Yaron Goland, Sam Ruby, Adam Barth, Abdulrahman I. ALGhadir, 2189 Aharon Lanin, Thomas Milo, Murray Sargent, Marc Blanchet, and Mykyta 2190 Yevstifeyev. 2192 12. Main Changes Since RFC 3987 2194 This section describes the main changes since [RFC3987]. 2196 12.1. Major restructuring of IRI processing model 2198 Major restructuring of IRI processing model to make scheme-specific 2199 translation necessary to handle IDNA requirements and for consistency 2200 with web implementations. 2202 Starting with IRI, you want one of: 2204 a IRI components (IRI parsed into UTF8 pieces) 2206 b URI components (URI parsed into ASCII pieces, encoded correctly) 2208 c whole URI (for passing on to some other system that wants whole 2209 URIs) 2211 12.1.1. OLD WAY 2213 1. Pct-encoding on the whole thing to a URI. (c1) If you want a 2214 (maybe broken) whole URI, you might stop here. 2216 2. Parsing the URI into URI components. (b1) If you want (maybe 2217 broken) URI components, stop here. 2219 3. Decode the components (undoing the pct-encoding). (a) if you want 2220 IRI components, stop here. 2222 4. reencode: Either using a different encoding some components (for 2223 domain names, and query components in web pages, which depends on 2224 the component, scheme and context), and otherwise using pct- 2225 encoding. (b2) if you want (good) URI components, stop here. 2227 5. reassemble the reencoded components. (c2) if you want a (*good*) 2228 whole URI stop here. 2230 12.1.2. NEW WAY 2232 1. Parse the IRI into IRI components using the generic syntax. (a) 2233 if you want IRI components, stop here. 2235 2. Encode each components, using pct-encoding, IDN encoding, or 2236 special query part encoding depending on the component scheme or 2237 context. (b) If you want URI components, stop here. 2239 3. reassemble the a whole URI from URI components. (c) if you want a 2240 whole URI stop here. 2242 12.1.3. Extension of Syntax 2244 Added the tag range (U+E0000-E0FFF) to the iprivate production. Some 2245 IRIs generated with the new syntax may fail to pass very strict 2246 checks relying on the old syntax. But characters in this range 2247 should be extremely infrequent anyway. 2249 12.1.4. More to be added 2251 TODO: There are more main changes that need to be documented in this 2252 section. 2254 12.2. Change Log 2256 Note to RFC Editor: Please completely remove this section before 2257 publication. 2259 12.2.1. Changes after draft-ietf-iri-3987bis-01 2261 Changes from draft-ietf-iri-3987bis-01 onwards are available as 2262 changesets in the IETF tools subversion repository at http:// 2263 trac.tools.ietf.org/wg/iri/trac/log/draft-ietf-iri-3987bis/ 2264 draft-ietf-iri-3987bis.xml. 2266 12.2.2. Changes from draft-duerst-iri-bis-07 to 2267 draft-ietf-iri-3987bis-00 2269 Changed draft name, date, last paragraph of abstract, and titles in 2270 change log, and added this section in moving from 2271 draft-duerst-iri-bis-07 (personal submission) to 2272 draft-ietf-iri-3987bis-00 (WG document). 2274 12.2.3. Changes from -06 to -07 of draft-duerst-iri-bis 2276 Major restructuring of the processing model, see Section 12.1. 2278 12.3. Changes from -00 to -01 2280 o Removed 'mailto:' before mail addresses of authors. 2282 o Added "" as right side of 'href-strip' rule. Fixed 2283 '|' to '/' for alternatives. 2285 12.4. Changes from -05 to -06 of draft-duerst-iri-bis-00 2287 o Add HyperText Reference, change abstract, acks and references for 2288 it 2290 o Add Masinter back as another editor. 2292 o Masinter integrates HRef material from HTML5 spec. 2294 o Rewrite introduction sections to modernize. 2296 12.5. Changes from -04 to -05 of draft-duerst-iri-bis 2298 o Updated references. 2300 o Changed IPR text to pre5378Trust200902. 2302 12.6. Changes from -03 to -04 of draft-duerst-iri-bis 2304 o Added explicit abbreviation for LEIRIs. 2306 o Mentioned LEIRI references. 2308 o Completed text in LEIRI section about tag characters and about 2309 specials. 2311 12.7. Changes from -02 to -03 of draft-duerst-iri-bis 2313 o Updated some references. 2315 o Updated Michel Suginard's coordinates. 2317 12.8. Changes from -01 to -02 of draft-duerst-iri-bis 2319 o Added tag range to iprivate (issue private-include-tags-115). 2321 o Added Specials (U+FFF0-FFFD) to Legacy Extended IRIs. 2323 12.9. Changes from -00 to -01 of draft-duerst-iri-bis 2325 o Changed from "IRIs with Spaces/Controls" to "Legacy Extended IRI" 2326 based on input from the W3C XML Core WG. Moved the relevant 2327 subsections to the back and promoted them to a section. 2329 o Added some text re. Legacy Extended IRIs to the security section. 2331 o Added a IANA Consideration Section. 2333 o Added this Change Log Section. 2335 o Added a section about "IRIs with Spaces/Controls" (converting from 2336 a Note in RFC 3987). 2338 12.10. Changes from RFC 3987 to -00 of draft-duerst-iri-bis 2340 Fixed errata (see 2341 http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=3987). 2343 13. References 2345 13.1. Normative References 2347 [ASCII] American National Standards Institute, "Coded Character 2348 Set -- 7-bit American Standard Code for Information 2349 Interchange", ANSI X3.4, 1986. 2351 [ISO10646] 2352 International Organization for Standardization, "ISO/IEC 2353 10646:2003: Information Technology - Universal Multiple- 2354 Octet Coded Character Set (UCS)", ISO Standard 10646, 2355 December 2003. 2357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2358 Requirement Levels", BCP 14, RFC 2119, March 1997. 2360 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 2361 "Internationalizing Domain Names in Applications (IDNA)", 2362 RFC 3490, March 2003. 2364 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 2365 Profile for Internationalized Domain Names (IDN)", 2366 RFC 3491, March 2003. 2368 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2369 10646", STD 63, RFC 3629, November 2003. 2371 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2372 Resource Identifier (URI): Generic Syntax", STD 66, 2373 RFC 3986, January 2005. 2375 [RFC5890] Klensin, J., "Internationalized Domain Names for 2376 Applications (IDNA): Definitions and Document Framework", 2377 RFC 5890, August 2010. 2379 [RFC5891] Klensin, J., "Internationalized Domain Names in 2380 Applications (IDNA): Protocol", RFC 5891, August 2010. 2382 [STD68] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2383 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2385 [UNI9] Davis, M., "The Bidirectional Algorithm", Unicode Standard 2386 Annex #9, March 2004, 2387 . 2389 [UNIV6] The Unicode Consortium, "The Unicode Standard, Version 2390 6.0.0 (Mountain View, CA, The Unicode Consortium, 2011, 2391 ISBN 978-1-936213-01-6)", October 2010. 2393 [UTR15] Davis, M. and M. Duerst, "Unicode Normalization Forms", 2394 Unicode Standard Annex #15, March 2008, 2395 . 2398 13.2. Informative References 2400 [BidiEx] "Examples of bidirectional IRIs", 2401 . 2403 [CharMod] Duerst, M., Yergeau, F., Ishida, R., Wolf, M., and T. 2404 Texin, "Character Model for the World Wide Web: Resource 2405 Identifiers", World Wide Web Consortium Candidate 2406 Recommendation, November 2004, 2407 . 2409 [Duerst97] 2410 Duerst, M., "The Properties and Promises of UTF-8", Proc. 2411 11th International Unicode Conference, San Jose , 2412 September 1997, . 2415 [Gettys] Gettys, J., "URI Model Consequences", 2416 . 2418 [HTML4] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 2419 Specification", World Wide Web Consortium Recommendation, 2420 December 1999, 2421 . 2423 [HTML5] Hickson, I. and D. Hyatt, "A vocabulary and associated 2424 APIs for HTML and XHTML", World Wide Web 2425 Consortium Working Draft, April 2009, 2426 . 2428 [LEIRI] Thompson, H., Tobin, R., and N. Walsh, "Legacy extended 2429 IRIs for XML resource identification", World Wide Web 2430 Consortium Note, November 2008, 2431 . 2433 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 2434 Resource Locators (URL)", RFC 1738, December 1994. 2436 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2437 Extensions (MIME) Part One: Format of Internet Message 2438 Bodies", RFC 2045, November 1996. 2440 [RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., 2441 Atkinson, R., Crispin, M., and P. Svanberg, "The Report of 2442 the IAB Character Set Workshop held 29 February - 1 March, 2443 1996", RFC 2130, April 1997. 2445 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 2447 [RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. 2449 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 2450 Languages", BCP 18, RFC 2277, January 1998. 2452 [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto 2453 URL scheme", RFC 2368, July 1998. 2455 [RFC2384] Gellens, R., "POP URL Scheme", RFC 2384, August 1998. 2457 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2458 Resource Identifiers (URI): Generic Syntax", RFC 2396, 2459 August 1998. 2461 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 2462 August 1998. 2464 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2465 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2466 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2468 [RFC2640] Curtin, B., "Internationalization of the File Transfer 2469 Protocol", RFC 2640, July 1999. 2471 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 2472 Identifiers (IRIs)", RFC 3987, January 2005. 2474 [RFC4395bis] 2475 Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 2476 Registration Procedures for New URI/IRI Schemes", 2477 draft-hansen-iri-4395bis-irireg-00 (work in progress), 2478 September 2010. 2480 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 2481 Encodings for Internationalized Domain Names", RFC 6055, 2482 February 2011. 2484 [UNIXML] Duerst, M. and A. Freytag, "Unicode in XML and other 2485 Markup Languages", Unicode Technical Report #20, World 2486 Wide Web Consortium Note, June 2003, 2487 . 2489 [UTR36] Davis, M. and M. Suignard, "Unicode Security 2490 Considerations", Unicode Technical Report #36, 2491 August 2010, . 2493 [XLink] DeRose, S., Maler, E., and D. Orchard, "XML Linking 2494 Language (XLink) Version 1.0", World Wide Web 2495 Consortium Recommendation, June 2001, 2496 . 2498 [XML1] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 2499 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Forth 2500 Edition)", World Wide Web Consortium Recommendation, 2501 August 2006, . 2503 [XMLNamespace] 2504 Bray, T., Hollander, D., Layman, A., and R. Tobin, 2505 "Namespaces in XML (Second Edition)", World Wide Web 2506 Consortium Recommendation, August 2006, 2507 . 2509 [XMLSchema] 2510 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", 2511 World Wide Web Consortium Recommendation, May 2001, 2512 . 2514 [XPointer] 2515 Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer 2516 Framework", World Wide Web Consortium Recommendation, 2517 March 2003, 2518 . 2520 Authors' Addresses 2522 Martin Duerst 2523 Aoyama Gakuin University 2524 5-10-1 Fuchinobe 2525 Sagamihara, Kanagawa 229-8558 2526 Japan 2528 Phone: +81 42 759 6329 2529 Fax: +81 42 759 6495 2530 Email: duerst@it.aoyama.ac.jp 2531 URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/ 2532 Michel Suignard 2533 Unicode Consortium 2534 P.O. Box 391476 2535 Mountain View, CA 94039-1476 2536 U.S.A. 2538 Phone: +1-650-693-3921 2539 Email: michel@unicode.org 2540 URI: http://www.suignard.com 2542 Larry Masinter 2543 Adobe 2544 345 Park Ave 2545 San Jose, CA 95110 2546 U.S.A. 2548 Phone: +1-408-536-3024 2549 Email: masinter@adobe.com 2550 URI: http://larry.masinter.net