idnits 2.17.00 (12 Aug 2021) /tmp/idnits6663/draft-ietf-idnabis-rationale-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2223. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 12, 2008) is 4998 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5226' is defined on line 2077, but no explicit reference was found in the text == Unused Reference: 'RulesInit' is defined on line 2081, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'IDNA2008-Bidi' -- Possible downref: Non-RFC (?) normative reference: ref. 'IDNA2008-Protocol' == Outdated reference: draft-ietf-idnabis-tables has been published as RFC 5892 ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3491 (Obsoleted by RFC 5891) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-ietf-idnabis-protocol has been published as RFC 5891 -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode-UAX15' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode51' -- Obsolete informational reference (is this intentional?): RFC 810 (Obsoleted by RFC 952) -- Obsolete informational reference (is this intentional?): RFC 2673 (Obsoleted by RFC 6891) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft September 12, 2008 4 Intended status: Standards Track 5 Expires: March 16, 2009 7 Internationalized Domain Names for Applications (IDNA): Definitions, 8 Background and Rationale 9 draft-ietf-idnabis-rationale-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 16, 2009. 36 Abstract 38 Several years have passed since the original protocol for 39 Internationalized Domain Names (IDNs) was completed and deployed. 40 During that time, a number of issues have arisen, including the need 41 to update the system to deal with newer versions of Unicode. Some of 42 these issues require tuning of the existing protocols and the tables 43 on which they depend. This document provides an overview of a 44 revised system and provides explanatory material for its components. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 1.1. Context and Overview . . . . . . . . . . . . . . . . . . . 4 50 1.2. Discussion Forum . . . . . . . . . . . . . . . . . . . . . 4 51 1.3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.4. Applicability and Function of IDNA . . . . . . . . . . . . 5 53 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 54 1.5.1. Documents and Standards . . . . . . . . . . . . . . . 6 55 1.5.2. Terminology about Characters and Character Sets . . . 6 56 1.5.3. DNS-related Terminology . . . . . . . . . . . . . . . 7 57 1.5.4. Terminology Specific to IDNA . . . . . . . . . . . . . 7 58 1.5.5. Punycode is an Algorithm, not a Name . . . . . . . . . 11 59 1.5.6. Other Terminology Issues . . . . . . . . . . . . . . . 11 60 1.6. Comprehensibility of IDNA Mechanisms and Processing . . . 12 61 2. The Revised IDNA Model . . . . . . . . . . . . . . . . . . . . 13 62 3. Processing in IDNA2008 . . . . . . . . . . . . . . . . . . . . 14 63 4. IDNA2008 Document List . . . . . . . . . . . . . . . . . . . . 14 64 5. Permitted Characters: An Inclusion List . . . . . . . . . . . 15 65 5.1. A Tiered Model of Permitted Characters and Labels . . . . 15 66 5.1.1. PROTOCOL-VALID . . . . . . . . . . . . . . . . . . . . 15 67 5.1.2. DISALLOWED . . . . . . . . . . . . . . . . . . . . . . 17 68 5.1.3. UNASSIGNED . . . . . . . . . . . . . . . . . . . . . . 18 69 5.2. Registration Policy . . . . . . . . . . . . . . . . . . . 18 70 5.3. Layered Restrictions: Tables, Context, Registration, 71 Applications . . . . . . . . . . . . . . . . . . . . . . . 19 72 6. Issues that Constrain Possible Solutions . . . . . . . . . . . 19 73 6.1. Display and Network Order . . . . . . . . . . . . . . . . 19 74 6.2. Entry and Display in Applications . . . . . . . . . . . . 20 75 6.3. Linguistic Expectations: Ligatures, Digraphs, and 76 Alternate Character Forms . . . . . . . . . . . . . . . . 21 77 6.4. Case Mapping and Related Issues . . . . . . . . . . . . . 24 78 6.5. Right to Left Text . . . . . . . . . . . . . . . . . . . . 25 79 7. IDNs and the Robustness Principle . . . . . . . . . . . . . . 25 80 8. Front-end and User Interface Processing . . . . . . . . . . . 26 81 9. Relationship to IDNA2003 and Earlier Versions of Unicode . . . 28 82 9.1. Summary of Major Changes from IDNA2003 . . . . . . . . . . 29 83 9.2. Migration and Version Synchronization . . . . . . . . . . 29 84 9.2.1. Design Criteria . . . . . . . . . . . . . . . . . . . 29 85 9.2.2. More Flexibility in User Agents . . . . . . . . . . . 33 86 9.2.3. The Question of Prefix Changes . . . . . . . . . . . . 34 87 9.2.4. Stringprep Changes and Compatibility . . . . . . . . . 36 88 9.2.5. The Symbol Question . . . . . . . . . . . . . . . . . 37 89 9.2.6. Migration Between Unicode Versions: Unassigned 90 Code Points . . . . . . . . . . . . . . . . . . . . . 38 91 9.2.7. Other Compatibility Issues . . . . . . . . . . . . . . 39 92 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 93 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 40 94 12. Internationalization Considerations . . . . . . . . . . . . . 40 95 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 96 13.1. IDNA Character Registry . . . . . . . . . . . . . . . . . 41 97 13.2. IDNA Context Registry . . . . . . . . . . . . . . . . . . 41 98 13.3. IANA Repository of IDN Practices of TLDs . . . . . . . . . 41 99 14. Security Considerations . . . . . . . . . . . . . . . . . . . 42 100 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 43 101 15.1. Changes between Version -00 and Version -01 of 102 draft-ietf-idnabis-rationale . . . . . . . . . . . . . . . 43 103 15.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 44 104 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 105 16.1. Normative References . . . . . . . . . . . . . . . . . . . 44 106 16.2. Informative References . . . . . . . . . . . . . . . . . . 46 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 108 Intellectual Property and Copyright Statements . . . . . . . . . . 48 110 1. Introduction 112 1.1. Context and Overview 114 Several years have passed since the original protocol for 115 Internationalized Domain Names (IDNs) was completed and deployed. 116 During that time, a number of issues have arisen, including a subset 117 of those described in a recent IAB report [RFC4690] and the need to 118 update the system to deal with newer versions of Unicode. Those 119 standards are known as Internationalized Domain Names in Applications 120 (IDNA), taken from the name of the highest level standard within that 121 group (see Section 1.5). Some tuning of the existing protocols and 122 the tables on which they depend is now required. Where it is 123 important to understanding of the revised protocols, this document 124 further explains the issues that have been encountered. It also 125 provides an overview of the new IDNA model and explanatory material 126 for it. Additional explanatory material for the specific components 127 of the proposals will appear with the associated documents. 129 1.2. Discussion Forum 131 [[anchor4: RFC Editor: please remove this section.]] 133 This work is being discussed in the IETF "idnabis" Working Group and 134 on the mailing list idna-update@alvestrand.no 136 1.3. Objectives 138 The intent of the IDNA revision effort, and hence of this document 139 and the associated ones, is to increase the usability and 140 effectiveness of internationalized domain names (IDNs) while 141 preserving or strengthening the integrity of references that use 142 them. The original "hostname" character definitions (see, e.g., 143 [RFC0810]) struck a balance between the creation of useful mnemonics 144 and the introduction of parsing problems or general confusion in the 145 contexts in which domain names are used. Our objective is to 146 preserve that balance while expanding the character repertoire to 147 include extended versions of Roman-derived scripts and scripts that 148 are not Roman in origin. No work of this sort will be able to 149 completely eliminate sources of visual or textual confusion: such 150 confusion is possible even under the original rules where only ASCII 151 characters were permitted. However, one can hope, through the 152 application of different techniques at different points (see 153 Section 5.3), to keep problems to an acceptable minimum. One 154 consequence of this general objective is that the desire of some user 155 or marketing community to use a particular string --whether the 156 reason is to try to write sentences of particular languages in the 157 DNS, to express a facsimile of the symbol for a brand, or for some 158 other purpose-- is not a primary goal within the context of 159 applications in the domain name space. 161 1.4. Applicability and Function of IDNA 163 The IDNA standard does not require any applications to conform to it, 164 nor does it retroactively change those applications. An application 165 can elect to use IDNA in order to support IDN while maintaining 166 interoperability with existing infrastructure. If an application 167 wants to use non-ASCII characters in domain names, IDNA is the only 168 currently-defined option. Adding IDNA support to an existing 169 application entails changes to the application only, and leaves room 170 for flexibility in front-end processing and more specifically in the 171 user interface (see Section 8). 173 A great deal of the discussion of IDN solutions has focused on 174 transition issues and how IDNs will work in a world where not all of 175 the components have been updated. Proposals that were not chosen by 176 the original IDN Working Group would depend on user applications, 177 resolvers, and DNS servers being updated in order for a user to apply 178 an internationalized domain name in any form or coding acceptable 179 under that method. While processing must be performed prior to or 180 after access to the DNS, no changes are needed to the DNS protocol or 181 any DNS servers or the resolvers on user's computers. 183 The IDNA specification solves the problem of extending the repertoire 184 of characters that can be used in domain names to include a large 185 subset of the Unicode repertoire. 187 IDNA does not extend the service offered by DNS to the applications. 188 Instead, the applications (and, by implication, the users) continue 189 to see an exact-match lookup service. Either there is a single 190 exactly-matching name or there is no match. This model has served 191 the existing applications well, but it requires, with or without 192 internationalized domain names, that users know the exact spelling of 193 the domain names that are to be typed into applications such as web 194 browsers and mail user agents. The introduction of the larger 195 repertoire of characters potentially makes the set of misspellings 196 larger, especially given that in some cases the same appearance, for 197 example on a business card, might visually match several Unicode code 198 points or several sequences of code points. 200 IDNA allows the graceful introduction of IDNs not only by avoiding 201 upgrades to existing infrastructure (such as DNS servers and mail 202 transport agents), but also by allowing some rudimentary use of IDNs 203 in applications by using the ASCII representation of the non-ASCII 204 name labels. While such names are user-unfriendly to read and type, 205 and hence not optimal for user input, they can be used as a last 206 resort to allow rudimentary IDN usage. For example, they might be 207 the best choice for display if it were known that relevant fonts were 208 not available on the user's computer. In order to allow user- 209 friendly input and output of the IDNs and acceptance of some 210 characters as equivalent to those to be processed according to the 211 protocol, the applications need to be modified to conform to this 212 specification. 214 IDNA uses the Unicode character repertoire, for continuity with the 215 original version of IDNA. 217 1.5. Terminology 219 1.5.1. Documents and Standards 221 This document uses the term "IDNA2003" to refer to the set of 222 standards that make up and support the version of IDNA published in 223 2003, i.e., those commonly known as the IDNA base specification 224 [RFC3490], Nameprep [RFC3491], Punycode [RFC3492], and Stringprep 225 [RFC3454]. In this document, those names are used to refer, 226 conceptually, to the individual documents, with the base IDNA 227 specification called just "IDNA". 229 The term "IDNA2008" is used to refer to a new version of IDNA as 230 described in this document and in the documents described in 231 Section 4. References to "these specifications" are to the entire 232 set. 234 1.5.2. Terminology about Characters and Character Sets 236 A code point is an integer value associated with a character in a 237 coded character set. 239 Unicode [Unicode51] is a coded character set containing almost 240 100,000 characters as of the current version. A single Unicode code 241 point is denoted by "U+" followed by four to six hexadecimal digits, 242 while a range of Unicode code points is denoted by two four to six 243 digit hexadecimal numbers separated by "..", with no prefixes. 245 ASCII means US-ASCII [ASCII], a coded character set containing 128 246 characters associated with code points in the range 0000..007F. 247 Unicode may be thought of as an extension of ASCII; it includes all 248 the ASCII characters and associates them with equivalent code points. 250 "Letters" are, informally, generalizations from the ASCII and common- 251 sense understanding of that term, i.e., characters that are used to 252 write text that are not digits, symbols, or punctuation. Formally, 253 they are characters with a Unicode General Category value starting in 254 "L" (see Section 4.5 of [Unicode51]). 256 1.5.3. DNS-related Terminology 258 When discussing the DNS, this document generally assumes the 259 terminology used in the DNS specifications [RFC1034] [RFC1035]. The 260 terms "lookup" is used to describe the combination of operations 261 performed by this protocol and those actually performed by a DNS 262 resolver. The process of placing an entry into the DNS is referred 263 to as "registration", similar to common contemporary usage in other 264 contexts. Consequently, any DNS zone administration is described as 265 a "registry", regardless of the actual administrative arrangements or 266 level in the DNS tree. A note about that relationship is included in 267 the text below where it seems particularly significant. 269 The term "LDH code points" is defined in this document to mean the 270 code points associated with ASCII letters, digits, and the hyphen- 271 minus; that is, U+002D, 0030..0039, 0041..005A, and 0061..007A. "LDH" 272 is an abbreviation for "letters, digits, hyphen". 274 The base DNS specifications [RFC1034] [RFC1035] discuss "domain 275 names" and "host names", but many people and sections of these 276 specifications use the terms interchangeably. Lack of clarity about 277 that terminology has contributed to confusion about intent in some 278 cases. This document generally uses the term "domain name". When it 279 refers to, e.g., host name syntax restrictions, it explicitly cites 280 the relevant defining documents. The remaining definitions in this 281 subsection are essentially a review. 283 A label is an individual component of a domain name. Labels are 284 usually shown separated by dots; for example, the domain name 285 "www.example.com" is composed of three labels: "www", "example", and 286 "com". (The zero-length root label described in RFC 1123 [RFC1123], 287 which can be explicit as in "www.example.com." or implicit as in 288 "www.example.com", is not considered in this specification.) IDNA 289 extends the set of usable characters in labels that are treated as 290 text (as distinct from the binary string labels discussed in RFC 1035 291 and RFC 2181 [RFC2181] and the bitstring ones described in RFC 2673 292 [RFC2673]). For the rest of this document and in the related ones, 293 the term "label" is shorthand for "text label", and "every label" 294 means "every text label". 296 1.5.4. Terminology Specific to IDNA 298 This section defines some terminology to reduce dependence on terms 299 and definitions that have been problematic in the past. 301 1.5.4.1. Terms for IDN Label Codings 303 1.5.4.1.1. IDNA-valid strings, A-label, and U-label 305 To improve clarity, this document introduces three new terms in this 306 subsection. In the next, it defines a historical one to be slightly 307 more precise for IDNA contexts. 309 o A string is "IDNA-valid" if it meets all of the requirements of 310 these specifications for an IDNA label. IDNA-valid strings may 311 appear in either of two forms, defined immediately below. It is 312 expected that specific reference will be made to the form 313 appropriate to any context in which the distinction is important. 315 o An "A-label" is the ASCII-Compatible Encoding (ACE, see 316 Section 1.5.4.5) form of an IDNA-valid string. It must be a 317 complete label: IDNA is defined for labels, not for parts of them 318 and not for complete domain names. This means, by definition, 319 that every A-label will begin with the IDNA ACE prefix, "xn--", 320 followed by a string that is a valid output of the Punycode 321 algorithm and hence a maximum of 59 ASCII characters in length. 322 The prefix and string together must conform to all requirements 323 for a label that can be stored in the DNS including conformance to 324 the rules for the preferred form described in RFC 1034, RFC 1035, 325 and RFC 1123. 327 o A "U-label" is an IDNA-valid string of Unicode characters, 328 including at least one non-ASCII character, expressed in a 329 standard Unicode Encoding Form -- normally UTF-8 in an Internet 330 transmission context -- and subject to the constraint below. 331 Conversions between U-labels and A-labels are performed according 332 to the "Punycode" specification [RFC3492], adding or removing the 333 ACE prefix (see Section 1.5.4.5) as needed. 335 To be valid, U-labels and A-labels must obey an important symmetry 336 constraint. While that constraint may be tested in any of several 337 ways, an A-label must be capable of being produced by conversion from 338 a U-label and a U-label must be capable of being produced by 339 conversion from an A-label. Among other things, this implies that 340 both U-labels and A-labels must be strings in Unicode NFC 341 [Unicode-UAX15] normalized form. These strings MUST contain only 342 characters specified elsewhere in this document and its companion 343 documents, and only in the contexts indicated as appropriate. 345 Any rules or conventions that apply to DNS labels in general, such as 346 rules about lengths of strings, apply to whichever of the U-label or 347 A-label would be more restrictive. For the U-label, constraints 348 imposed by existing protocols and their presentation forms make the 349 length restriction apply to the length in octets of the UTF-8 form of 350 those labels (which will always be greater than or equal to the 351 length in code points). The exception to this, of course, is that 352 the restriction to ASCII characters does not apply to the U-label. 354 A different way to look at these terms, which may be more clear to 355 some readers, is that U-labels, A-labels, and LDH-labels (see the 356 next subsection) are disjoint categories that, together, make up the 357 forms of legitimate strings for use in domain names that describe 358 hosts. Of the three, only A-labels and LDH-labels can actually 359 appear in DNS zone files or queries; U-labels can appear, along with 360 the other two, in presentation and user interface forms and in 361 selected protocols other than those of the DNS itself. Strings that 362 do not conform to the rules for one of these three categories and, in 363 particular, strings that contain "--" in the third and fourth 364 character position but are: 366 o not A-labels or 368 o cannot be processed as U-labels or A-labels as described in these 369 specifications, 371 are invalid in IDNA-conformant applications as labels in domain names 372 that identify Internet hosts or similar resources. This restriction 373 on strings containing "--" is required for three reasons: 375 o to prevent confusion with pre-IDNA coding forms; 377 o to permit future extensions that would require changing the 378 prefix, no matter how unlikely those might be (see Section 9.2.3); 379 and 381 o to reduce the opportunities for attacks via the encoding system. 383 1.5.4.2. LDH-label and Internationalized Label 385 In the hope of further clarifying discussions about IDNs, these 386 specifications use the term "LDH-label" strictly to refer to an all- 387 ASCII label that obeys the preferred syntax (often known as 388 "hostname" (from RFC 952 [RFC0952]) or "LDH") conventions and that is 389 not an IDN. It should be stressed that an A-label obeys the 390 "hostname" rules and is sometimes described as "LDH-conformant" or in 391 similar language but that it is not an LDH-label as used in this 392 document. 394 1.5.4.3. Internationalized Domain Name 396 An "internationalized domain name" (IDN) is a domain name that may 397 contain any mixture of LDH-labels, A-labels, or U-labels. This 398 implies that every conventional domain name is an IDN (which implies 399 that it is possible for a domain name to be an IDN without it 400 containing any non-ASCII characters). Just as has been the case with 401 ASCII names, some DNS zone administrators may impose restrictions, 402 beyond those imposed by DNS or IDNA, on the characters or strings 403 that may be registered as labels in their zones. Because of the 404 diversity of characters that can be used in a U-label and the 405 confusion they might cause, such restrictions are mandatory for IDN 406 registries and zones even though the particular restrictions are not 407 part of these specifications. Because these restrictions, commonly 408 known as "registry restrictions", only affect what can be registered 409 and not lookup processing, they have no effect on the syntax or 410 semantics of DNS protocol messages; a query for a name that matches 411 no records will yield the same response regardless of the reason why 412 it is not in the zone. Clients issuing queries or interpreting 413 responses cannot be assumed to have any knowledge of zone-specific 414 restrictions or conventions. See Section 5.2. 416 "Internationalized label" is used when a term is needed to refer to a 417 single label of an IDN, i.e., one that might be any of an LDH-label, 418 A-label, or U-label. There are some standardized DNS label formats, 419 such as those for service location (SRV) records [RFC2782] that do 420 not fall into any of the three categories and hence are not 421 internationalized labels. 423 1.5.4.4. Equivalence 425 In IDNA, equivalence of labels is defined in terms of the A-labels. 426 If the A-labels are equal in a case-independent comparison, then the 427 labels are considered equivalent, no matter how they are represented. 428 Traditional LDH labels already have a notion of equivalence: within 429 that list of characters, upper case and lower case are considered 430 equivalent. The IDNA notion of equivalence is an extension of that 431 older notion. Equivalent labels in IDNA are treated as alternate 432 forms of the same label, just as "foo" and "Foo" are treated as 433 alternate forms of the same label. 435 1.5.4.5. ACE Prefix 437 The "ACE prefix" is defined in this document to be a string of ASCII 438 characters "xn--" that appears at the beginning of every A-label. 439 "ACE" stands for "ASCII-Compatible Encoding". 441 1.5.4.6. Domain Name Slot 443 A "domain name slot" is defined in this document to be a protocol 444 element or a function argument or a return value (and so on) 445 explicitly designated for carrying a domain name. Examples of domain 446 name slots include: the QNAME field of a DNS query; the name argument 447 of the gethostbyname() or getaddrinfo() standard C library functions; 448 the part of an email address following the at-sign (@) in the 449 parameter to the SMTP MAIL or RCPT commands or the "From:" field of 450 an email message header; and the host portion of the URI in the src 451 attribute of an HTML tag. General text that just happens to 452 contain a domain name is not a domain name slot. For example, a 453 domain name appearing in the plain text body of an email message is 454 not occupying a domain name slot. 456 An "IDN-aware domain name slot" is defined in this document to be a 457 domain name slot explicitly designated for carrying an 458 internationalized domain name as defined in this document. The 459 designation may be static (for example, in the specification of the 460 protocol or interface) or dynamic (for example, as a result of 461 negotiation in an interactive session). 463 An "IDN-unaware domain name slot" is defined in this document to be 464 any domain name slot that is not an IDN-aware domain name slot. 465 Obviously, this includes any domain name slot whose specification 466 predates IDNA. 468 1.5.5. Punycode is an Algorithm, not a Name 470 There has been some confusion about whether a "Punycode string" does 471 or does not include the ACE prefix and about whether it is required 472 that such strings could have been the output of the ToASCII operation 473 (see RFC 3490, Section 4 [RFC3490]). This specification discourages 474 the use of the term "Punycode" to describe anything but the encoding 475 method and algorithm of [RFC3492]. The terms defined above are 476 preferred as much more clear than terms such as "Punycode string". 478 1.5.6. Other Terminology Issues 480 The document departs from historical DNS terminology and usage in one 481 important respect. Over the years, the community has talked very 482 casually about "names" in the DNS, beginning with calling it "the 483 domain name system". That terminology is fine in the very precise 484 sense that the identifiers of the DNS do provide names for objects 485 and addresses. But, in the context of IDNs, the term has introduced 486 some confusion, confusion that has increased further as people have 487 begun to speak of DNS labels in terms of the words or phrases of 488 various natural languages. 490 Historically, many, perhaps most, of the "names" in the DNS have been 491 mnemonics to identify some particular concept, object, or 492 organization. They are typically derived from, or rooted in, some 493 language because most people think in language-based ways. But, 494 because they are mnemonics, they need not obey the orthographic 495 conventions of any language: it is not a requirement that it be 496 possible for them to be "words". 498 This distinction is important because the reasonable goal of an IDN 499 effort is not to be able to write the great Klingon (or language of 500 one's choice) novel in DNS labels but to be able to form a usefully 501 broad range of mnemonics in ways that are as natural as possible in a 502 very broad range of scripts. 504 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 505 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 506 document are to be interpreted as described in RFC 2119 [RFC2119]. 508 1.6. Comprehensibility of IDNA Mechanisms and Processing 510 One of the major goals of this work is to improve the general 511 understanding of how IDNA works and what characters are permitted and 512 what happens to them. Comprehensibility and predictability to users 513 and registrants are themselves important motivations and design goals 514 for this effort. The effort includes some new terminology and a 515 revised and extended model, both covered in this section, and some 516 more specific protocol, processing, and table modifications. Details 517 of the latter appear in other documents (see Section 4). 519 Several issues are inherent in the application of IDNs and, indeed, 520 almost any other system that tries to handle international characters 521 and concepts. They range from the apparently trivial --e.g., one 522 cannot display a character for which one does not have a font 523 available locally-- to the more complex and subtle. Many people have 524 observed that internationalization is just a tool to enable effective 525 localization while permitting some global uniformity. Issues of 526 display, of exactly how various strings and characters are entered, 527 and so on are inherently issues about localization and user interface 528 design. 530 A protocol such as IDNA can only assume that such operations as data 531 entry and reconciliation of differences in character forms are 532 possible. It may make some recommendations about how display might 533 work when characters and fonts are not available, but they can only 534 be general recommendations and, because display functions are rarely 535 controlled by the types of applications that would call upon IDNA, 536 will rarely be very effective. 538 However, shifting responsibility for character mapping and other 539 adjustments from the protocol (where it was located in IDNA2003) to 540 the user interface or processing before invoking IDNA raises issues 541 about both what that processing should do and about compatibility for 542 references prepared in an IDNA2003 context. Those issues are 543 discussed in Section 8. 545 Operations for converting between local character sets and normalized 546 Unicode are part of this general set of user interface issues. The 547 conversion is obviously not required at all in a Unicode-native 548 system that maintains all strings in Normalization Form C (NFC). It 549 may, however, involve some complexity in a system that is not 550 Unicode-native, especially if the elements of the local character set 551 do not map exactly and unambiguously into Unicode characters or do so 552 in a way that is not completely stable over time. Perhaps more 553 important, if a label being converted to a local character set 554 contains Unicode characters that have no correspondence in that 555 character set, the application may have to apply special, locally- 556 appropriate, methods to avoid or reduce loss of information. 558 Depending on the system involved, the major difficulty may not lie in 559 the mapping but in accurately identifying the incoming character set 560 and then applying the correct conversion routine. If a local 561 operating system uses one of the ISO 8859 character sets or an 562 extensive national or industrial system such as GB18030 [GB18030] or 563 BIG5 [BIG5], one must correctly identify the character set in use 564 before converting to Unicode even though those character coding 565 systems are substantially or completely Unicode-compatible (i.e., all 566 of the code points in them have an exact and unique mapping to 567 Unicode code points). It may be even more difficult when the 568 character coding system in local use is based on conceptually 569 different assumptions than those used by Unicode about, e.g., about 570 font encodings used for publications in some Indic scripts. Those 571 differences may not easily yield unambiguous conversions or 572 interpretations even if each coding system is internally consistent 573 and adequate to represent the local language and script. 575 2. The Revised IDNA Model 577 IDNA is a client-side protocol, i.e., almost all of the processing is 578 performed by the client. The strings that appear in, and are 579 resolved by, the DNS conform to the traditional rules for the naming 580 of hosts, and consist of ASCII letters, digits, and hyphens. This 581 approach permits IDNA to be deployed without modifications to the DNS 582 itself. That, in turn, avoids both having to upgrade the entire 583 Internet to support IDNs and needing to incur the unknown risks to 584 deployed systems of DNS structural or design changes especially if 585 those changes need to be deployed all at the same time. 587 [[anchor17: This paragraph is somewhat redundant with material 588 above.It will be dropped in -03 if there are not strong arguments for 589 keeping it here.]] 591 3. Processing in IDNA2008 593 These specifications separate Domain Name Registration and Lookup in 594 the protocol specification. Doing so reflects current practice in 595 which per-registry restrictions and special processing are applied at 596 registration time but not during lookup. Even more important in the 597 longer term, it facilitates incremental addition of permitted 598 character groups to avoid freezing on one particular version of 599 Unicode. 601 The actual registration and lookup protocols for IDNA2008 are 602 specified in [IDNA2008-Protocol]. 604 4. IDNA2008 Document List 606 [[anchor19: This section will need to be extensively revised or 607 removed before publication.]] 609 The following documents are being produced as part of the IDNA2008 610 effort. 612 o A revised version of this document, containing an overview, 613 rationale, and conformance conditions. 615 o A separate document, drawn from material in early versions of this 616 one, that explicitly updates and replaces RFC 3490 but which has 617 most rationale material from that document moved to this one 618 [IDNA2008-Protocol]. 620 o A document describing the "Bidi problem" with Stringprep and 621 proposing a solution [IDNA2008-Bidi]. 623 o A specification of the categories and rules that identify the code 624 points allowed in a U-label, based on Unicode 5.0 code 625 assignments. See Section 5 and [IDNA2008-Tables]. 627 o One or more documents containing guidance and suggestions for 628 registries (in this context, those responsible for establishing 629 policies for any zone file in the DNS, not only those at the top 630 or second level). The documents in this category may not be IETF 631 products and may be prepared and completed asynchronously with 632 those described above. 634 5. Permitted Characters: An Inclusion List 636 This section provides an overview of the model used to establish the 637 algorithm and character lists of [IDNA2008-Tables] and describes the 638 names and applicability of the categories used there. Note that the 639 inclusion of a character in the first category group does not imply 640 that it can be used indiscriminately; some characters are associated 641 with contextual rules that must be applied as well. 643 The information given in this section is provided to make the rules, 644 tables, and protocol easier to understand. It is not normative. The 645 normative generating rules appear in [IDNA2008-Tables] and the rules 646 that actually determine what labels can be registered or looked up 647 are in [IDNA2008-Protocol]. 649 5.1. A Tiered Model of Permitted Characters and Labels 651 Moving to an inclusion model requires respecifying the list of 652 characters that are permitted in IDNs. In IDNA2003, the role and 653 utility of characters are independent of context and fixed forever 654 (or until the standard is replaced). Making completely context- 655 independent rules globally has proven impractical because some 656 characters, especially those that are called "Join_Controls" in 657 Unicode, are needed to make reasonable use of some scripts but have 658 no visible effect(s) in others. Of necessity, IDNA2003 prohibited 659 those types of characters entirely. But the restrictions were much 660 too severe to permit an adequate range of mnemonics for terminology 661 based on some languages. The requirement to support those characters 662 but limit their use to very specific contexts was reinforced by the 663 observation that handling of particular characters across the 664 languages that use a script, or the use of similar or identical- 665 looking characters in different scripts, is less well understood than 666 many people believed it was several years ago. 668 Independently of the characters chosen (see next subsection), the 669 theory is to divide the characters that appear in Unicode into three 670 categories: 672 5.1.1. PROTOCOL-VALID 674 Characters identified as "PROTOCOL-VALID" (often abbreviated 675 "PVALID") are, in general, permitted by IDNA for all uses in IDNs. 676 Their use may be restricted by rules about the context in which they 677 appear or by other rules that apply to the entire label in which they 678 are to be embedded. For example, any label that contains a character 679 in this category that has a "right-to-left" property must be used in 680 context with the "Bidi" rules (see [IDNA2008-Bidi]). 682 The term "PROTOCOL-VALID" is used to stress the fact that the 683 presence of a character in this category does not imply that a given 684 registry need accept registrations containing any of the characters 685 in the category. Registries are still expected to apply judgment 686 about labels they will accept and to maintain rules consistent with 687 those judgments (see [IDNA2008-Protocol] and Section 5.3). 689 Characters that are placed in the "PROTOCOL-VALID" category are never 690 removed from it unless the code points themselves are removed from 691 Unicode (such removal would be inconsistent with the Unicode 692 stability principles (see [Unicode51], Appendix F) and hence should 693 never occur). 695 [[anchor21: Placeholder: Does this topic or comment need additional 696 discussion or explanation?]] 698 5.1.1.1. Contextual Rules 700 Some characters may be unsuitable for general use in IDNs but 701 necessary for the plausible support of some scripts. The two most 702 commonly-cited examples are the zero-width joiner and non-joiner 703 characters (ZWJ, U+200D and ZWNJ, U+200C), but provisions for 704 unambiguous labels may require that other characters be restricted to 705 particular contexts. For example, the ASCII hyphen is not permitted 706 to start or end a label, whether that label contains non-ASCII 707 characters or not. 709 These characters must not appear in IDNs without additional 710 restrictions, typically because they have no visible consequences in 711 most scripts but affect format or presentation in a few others or 712 because they are combining characters that are safe for use only in 713 conjunction with particular characters or scripts. In order to 714 permit them to be used at all, they are specially identified as 715 "CONTEXTUAL RULE REQUIRED" and, when adequately understood, 716 associated with a rule. In addition, the rule will define whether it 717 is to be applied on lookup as well as registration. A distinction is 718 made between characters that indicate or prohibit joining (known as 719 "CONTEXT-JOINER" or "CONTEXTJ") and other characters requiring 720 contextual treatment ("CONTEXT-OTHER" or "CONTEXTO"). Only the 721 former are fully tested at lookup time. 723 5.1.1.2. Rules and Their Application 725 The actual rules may be present or absent. If present, they may have 726 values of "True" (character may be used in any position in any 727 label), "False" (character may not be used in any label), or may be a 728 set of procedural rules that specify the context in which the 729 character is permitted. 731 Examples of descriptions of typical rules, stated informally and in 732 English, include "Must follow a character from Script XYZ", "MUST 733 occur only if the entire label is in Script ABC", "MUST occur only if 734 the previous and subsequent characters have the DFG property". 736 Because it is easier to identify these characters than to know that 737 they are actually needed in IDNs or how to establish exactly the 738 right rules for each one, a rule may have a null value in a given 739 version of the tables. Characters associated with null rules MUST 740 NOT appear in putative labels for either registration or lookup. Of 741 course, a later version of the tables might contain a non-null rule. 743 The description of the syntax of the rules, and the rules themselves, 744 appears in [IDNA2008-Tables]. 746 5.1.2. DISALLOWED 748 Some characters are sufficiently problematic for use in IDNs that 749 they should be excluded for both registration and lookup (i.e., IDNA- 750 conforming applications performing name lookup should verify that 751 these characters are absent; if they are present, the label strings 752 should be rejected rather than converted to A-labels and looked up. 754 Of course, this category would include code points that had been 755 removed entirely from Unicode should such removals ever occur. 757 Characters that are placed in the "DISALLOWED" category are expected 758 to never be removed from it or reclassified. If a character is 759 classified as "DISALLOWED" in error and the error is sufficiently 760 problematic, the only recourse would be either to introduce a new 761 code point into Unicode and classify it as "PROTOCOL-VALID" or for 762 the IETF to accept the considerable costs of an incompatible change 763 and replace the relevant RFC with one containing appropriate 764 exceptions. 766 [[anchor23: Note in Draft: the permanence of DISALLOWED was still 767 under discussion in the WG when this draft was posted. The text 768 above reflects the editor's opinion about the emerging consensus but 769 is subject to change as the discussion continues.]] 770 There is provision for exception cases but, in general, characters 771 are placed into "DISALLOWED" if they fall into one or more of the 772 following groups: 774 o The character is a compatibility equivalent for another character. 775 In slightly more precise Unicode terms, application of 776 normalization method NFKC to the character yields some other 777 character. 779 o The character is an upper-case form or some other form that is 780 mapped to another character by Unicode casefolding. 782 o The character is a symbol or punctuation form or, more generally, 783 something that is not a letter, digit, or a mark that is used to 784 form a letter or digit. 786 5.1.3. UNASSIGNED 788 For convenience in processing and table-building, code points that do 789 not have assigned values in a given version of Unicode are treated as 790 belonging to a special UNASSIGNED category. Such code points MUST 791 NOT appear in labels to be registered or looked up. The category 792 differs from DISALLOWED in that code points are moved out of it by 793 the simple expedient of being assigned in a later version of Unicode 794 (at which point, they are classified into one of the other categories 795 as appropriate). 797 5.2. Registration Policy 799 While these recommendations cannot and should not define registry 800 policies, registries SHOULD develop and apply additional restrictions 801 to reduce confusion and other problems. For example, it is generally 802 believed that labels containing characters from more than one script 803 are a bad practice although there may be some important exceptions to 804 that principle. Some registries may choose to restrict registrations 805 to characters drawn from a very small number of scripts. For many 806 scripts, the use of variant techniques such as those as described in 807 [RFC3743] and [RFC4290], and illustrated for Chinese by the tables 808 described in RFC 4713 [RFC4713] may be helpful in reducing problems 809 that might be perceived by users. It is worth stressing that these 810 principles of policy development and application apply at all levels 811 of the DNS, not only, e.g., TLD registrations and that even a 812 trivial, "anything permitted that is valid under the protocol" policy 813 is helpful in that it helps users and application developers know 814 what to expect.. 816 5.3. Layered Restrictions: Tables, Context, Registration, Applications 818 The essence of the character rules in IDNA2008 is based on the 819 realization that there is no magic bullet for any of the issues 820 associated with a multiscript DNS. Instead, the specifications 821 define a variety of approaches that, together, constitute multiple 822 lines of defense against ambiguity in identifiers and loss of 823 referential integrity. The actual character tables are the first 824 mechanism, protocol rules about how those characters are applied or 825 restricted in context are the second, and those two in combination 826 constitute the limits of what can be done by a protocol alone. As 827 discussed in the previous section (Section 5.2), registries are 828 expected to restrict what they permit to be registered, devising and 829 using rules that are designed to optimize the balance between 830 confusion and risk on the one hand and maximum expressiveness in 831 mnemonics on the other. 833 In addition, there is an important role for user agents in warning 834 against label forms that appear unreasonable given their knowledge of 835 local contexts and conventions. Of course, no approach based on 836 naming or identifiers alone can protect against all threats. 838 6. Issues that Constrain Possible Solutions 840 6.1. Display and Network Order 842 The correct treatment of domain names requires a clear distinction 843 between Network Order (the order in which the code points are sent in 844 protocols) and Display Order (the order in which the code points are 845 displayed on a screen or paper). The order of labels in a domain 846 name that contains characters that are normally written right to left 847 is discussed in [IDNA2008-Bidi]. In particular, there are questions 848 about the order in which labels are displayed if left to right and 849 right to left labels are adjacent to each other, especially if there 850 are also multiple consecutive appearances of one of the types. The 851 decision about the display order is ultimately under the control of 852 user agents --including web browsers, mail clients, and the like-- 853 which may be highly localized. Even when formats are specified by 854 protocols, the full composition of an Internationalized Resource 855 Identifier (IRI) [RFC3987] or Internationalized Email address 856 contains elements other than the domain name. For example, IRIs 857 contain protocol identifiers and field delimiter syntax such as 858 "http://" or "mailto:" while email addresses contain the "@" to 859 separate local parts from domain names. User agents are not required 860 to use those protocol-based forms directly but often do so. While 861 display, parsing, and processing within a label is specified by the 862 IDNA protocol and the associated documents, the relationship between 863 fully-qualified domain names and internationalized labels is 864 unchanged from the base DNS specifications. Comments here about such 865 full domain names are explanatory or examples of what might be done 866 and must not be considered normative. 868 Questions remain about protocol constraints implying that the overall 869 direction of these strings will always be left to right (or right to 870 left) for an IRI or email address, or if they even should conform to 871 such rules. These questions also have several possible answers. 872 Should a domain name abc.def, in which both labels are represented in 873 scripts that are written right to left, be displayed as fed.cba or 874 cba.fed? An IRI for clear text web access would, in network order, 875 begin with "http://" and the characters will appear as 876 "http://abc.def" -- but what does this suggest about the display 877 order? When entering a URI to many browsers, it may be possible to 878 provide only the domain name and leave the "http://" to be filled in 879 by default, assuming no tail (an approach that does not work for 880 other protocols). The natural display order for the typed domain 881 name on a right to left system is fed.cba. Does this change if a 882 protocol identifier, tail, and the corresponding delimiters are 883 specified? 885 While logic, precedent, and reality suggest that these are questions 886 for user interface design, not IETF protocol specifications, 887 experience in the 1980s and 1990s with mixing systems in which domain 888 name labels were read in network order (left to right) and those in 889 which those labels were read right to left would predict a great deal 890 of confusion, and heuristics that sometimes fail, if each 891 implementation of each application makes its own decisions on these 892 issues. 894 It should be obvious that any revision of IDNA, including the current 895 one, must be clear about the network (transmission on the wire) order 896 of characters in labels and for the labels in complete (fully- 897 qualified) domain names. In order to prevent user confusion and, in 898 particular, to reduce the chances for inconsistent transcription of 899 domain names from printed form, it is likely that some strong 900 suggestions should be made about display order as well. 902 6.2. Entry and Display in Applications 904 Applications can accept domain names using any character set or sets 905 desired by the application developer or specified by the operating 906 system, and can display domain names in any charset. That is, the 907 IDNA protocol does not affect the interface between users and 908 applications. 910 An IDNA-aware application can accept and display internationalized 911 domain names in two formats: the internationalized character set(s) 912 supported by the application (i.e., an appropriate local 913 representation of a U-label), and as an A-label. Applications MAY 914 allow the display of A-labels, but are encouraged to not do so except 915 as an interface for special purposes, possibly for debugging, or to 916 cope with display limitations. In general, they SHOULD allow, but 917 not encourage, user input of that label form. A-labels are opaque 918 and ugly, and, where possible, should thus only be exposed to users 919 and in contexts in which they are absolutely needed. Because IDN 920 labels can be rendered either as A-labels or U-labels, the 921 application may reasonably have an option for the user to select the 922 preferred method of display; if it does, rendering the U-label should 923 normally be the default. 925 Domain names are often stored and transported in many places. For 926 example, they are part of documents such as mail messages and web 927 pages. They are transported in many parts of many protocols, such as 928 both the control commands and the RFC 2822 body parts of SMTP, and 929 the headers and the body content in HTTP. It is important to 930 remember that domain names appear both in domain name slots and in 931 the content that is passed over protocols. 933 In protocols and document formats that define how to handle 934 specification or negotiation of charsets, labels can be encoded in 935 any charset allowed by the protocol or document format. If a 936 protocol or document format only allows one charset, the labels MUST 937 be given in that charset. Of course, not all charsets can properly 938 represent all labels. If a U-label cannot be displayed in its 939 entirety, the only choice (without loss of information) may be to 940 display the A-label. 942 In any place where a protocol or document format allows transmission 943 of the characters in internationalized labels, labels SHOULD be 944 transmitted using whatever character encoding and escape mechanism 945 the protocol or document format uses at that place. This provision 946 is intended to prevent situations in which, e.g., UTF-8 domain names 947 appear embedded in text that is otherwise in some other character 948 coding. 950 All protocols that use domain name slots already have the capacity 951 for handling domain names in the ASCII charset. Thus, A-labels can 952 inherently be handled by those protocols. 954 6.3. Linguistic Expectations: Ligatures, Digraphs, and Alternate 955 Character Forms 957 Users often have expectations about character matching or equivalence 958 that are based on their languages and the orthography of those 959 languages. These expectations may not be consistent with forms or 960 actions that can be naturally accommodated in a character coding 961 system, especially if multiple languages are written using the same 962 script but using different conventions. A Norwegian user might 963 expect a label with the ae-ligature to be treated as the same label 964 as one using the Swedish spelling with a-umlaut even though applying 965 that mapping to English would be astonishing to users. A user in 966 German might expect a label with an o-umlaut and a label that had 967 "oe" substituted, but was otherwise the same, treated as equivalent 968 even though that substitution would be a clear error in Swedish. A 969 Chinese user might expect automatic matching of Simplified and 970 Traditional Chinese characters, but applying that matching for Korean 971 or Japanese text would create considerable confusion. For that 972 matter, an English user might expect "theater" and "theatre" to 973 match. 975 Related issues arise because there are a number of languages written 976 with alphabetic scripts in which single phonemes are written using 977 two characters, termed a "digraph", for example, the "ph" in 978 "pharmacy" and "telephone". (Note that characters paired in this 979 manner can also appear consecutively without forming a digraph, as in 980 "tophat".) Certain digraphs are normally indicated typographically 981 by setting the two characters closer together than they would be if 982 used consecutively to represent different phonemes. Some digraphs 983 are fully joined as ligatures (strictly designating setting totally 984 without intervening white space, although the term is sometimes 985 applied to close set pairs). An example of this may be seen when the 986 word "encyclopaedia" is set with a U+00E6 LATIN SMALL LIGATURE AE 987 (and some would not consider that word correctly spelled unless the 988 ligature form was used or the "a" was dropped entirely). When these 989 ligature and digraph forms have the same interpretation across all 990 languages that use a given script, application of Unicode 991 normalization generally resolves the differences and causes them to 992 match. When they have different interpretations, any requirements 993 for matching must utilize other methods or users must be educated to 994 understand that matching will not occur. 996 Difficulties arise from the fact that a given ligature may be a 997 completely optional typographic convenience for representing a 998 digraph in one language (as in the above example with some spelling 999 conventions), while in another language it is a single character that 1000 may not always be correctly representable by a two-letter sequence 1001 (as in the above example with different spelling conventions). This 1002 can be illustrated by many words in the Norwegian language, where the 1003 "ae" ligature is the 27th letter of a 29-letter extended Latin 1004 alphabet. It is equivalent to the 28th letter of the Swedish 1005 alphabet (also containing 29 letters), U+00E4 LATIN SMALL LETTER A 1006 WITH DIAERESIS, for which an "ae" cannot be substituted according to 1007 current orthographic standards. 1009 That character (U+00E4) is also part of the German alphabet where, 1010 unlike in the Nordic languages, the two-character sequence "ae" is 1011 usually treated as a fully acceptable alternate orthography for the 1012 "umlauted a" character. The inverse is however not true, and those 1013 two characters cannot necessarily be combined into an "umlauted a". 1014 This also applies to another German character, the "umlauted o" 1015 (U+00F6 LATIN SMALL LETTER O WITH DIAERESIS) which, for example, 1016 cannot be used for writing the name of the author "Goethe". It is 1017 also a letter in the Swedish alphabet where, like the "umlauted a", 1018 it cannot be correctly represented as "oe" and in the Norwegian 1019 alphabet, where it is represented, not as "umlauted o", but as 1020 "slashed o", U+00F8. 1022 Some of the ligatures that have explicit code points in Unicode were 1023 given special handling in IDNA2003 and now pose additional problems 1024 as people argue that they should have been treated differently to 1025 preserve important information. For example, the German character 1026 Eszett (Sharp S, U+00DF) is retained as itself by NFKC but case- 1027 folded by Stringprep to "ss", but the closely-related, but less 1028 frequently seen, character "Long S T" (U+FB05) is a compatibility 1029 character that is mapped out by NFKC. Unless exceptions are made, 1030 both will be treated as DISALLOWED by IDNA2008. But there is 1031 significant interest in an exception, especially for Eszett. 1032 Depending on what the exception was, making it would either raise 1033 some backward compatibility problems with IDNA2003 or create an 1034 unusual special case that would highlight differences in preferred 1035 orthography between German as written in Germany and German as 1036 written in some other countries, notably Switzerland. Additional 1037 discussion of issues with Eszett appear in Section 9.2.7. 1039 Additional cases with alphabets written right to left are described 1040 in Section 6.5. 1042 Whether ligatures and digraphs are to be treated as a sequence of 1043 characters or as a single standalone one constitute a problem that 1044 cannot be resolved solely by operating on scripts. They are, 1045 however, a key concern in the IDN context. Their satisfactory 1046 resolution will require support in policies set by registries, which 1047 therefore need to be particularly mindful not just of this specific 1048 issue, but of all other related matters that cannot be dealt with on 1049 an exclusively algorithmic basis. 1051 Just as with the examples of different-looking characters that may be 1052 assumed to be the same, it is in general impossible to deal with 1053 these situations in a system such as IDNA -- or with Unicode 1054 normalization generally -- since determining what to do requires 1055 information about the language being used, context, or both. 1056 Consequently, these specifications make no attempt to treat these 1057 combined characters in any special way. However, their existence 1058 provides a prime example of a situation in which a registry that is 1059 aware of the language context in which labels are to be registered, 1060 and where that language sometimes (or always) treats the two- 1061 character sequences as equivalent to the combined form, should give 1062 serious consideration to applying a "variant" model [RFC3743] 1063 [RFC4290] to reduce the opportunities for user confusion and fraud 1064 that would result from the related strings being registered to 1065 different parties. 1067 6.4. Case Mapping and Related Issues 1069 Traditionally in the DNS, ASCII letters have been stored with their 1070 case preserved. Matching during the query process has been case- 1071 independent, but none of the information that might be represented by 1072 choices of case has been lost. That model has been accidentally 1073 helpful because, as people have created DNS labels by catenating 1074 words (or parts of words) to form labels, case has often been used to 1075 distinguish among components and make the labels more memorable. 1077 The solution of keeping the characters separate but doing matching 1078 independent of case is not feasible with an IDNA-like model because 1079 the matching would then have to be done on the server rather than 1080 have characters mapped on the client. That situation was recognized 1081 in IDNA2003 and nothing in IDNA2008 fundamentally changes it or could 1082 do so. In IDNA2003, all upper-case characters are mapped to lower- 1083 case ones and, in general, all code points that represent alternate 1084 forms of the same character are mapped to that character (including 1085 mapping Greek final form sigma to the medial form). IDNA2008 1086 permits, at the risk of some incompatibility, slightly more 1087 flexibility in this area. That additional flexibility still does not 1088 solve the problem with final form sigma and other characters that 1089 Unicode treats as completely separate characters that match only 1090 under casemapping if at all. Many people now believe these should be 1091 handled as separate characters so information about them can be 1092 preserved in the transformations to A-labels and back. However 1093 making a change to permit that behavior would create a situation in 1094 which the same string, valid in both protocols, would be interpreted 1095 differently by IDNA2003 and IDNA2008. In principle, that would 1096 violate one of the conditions discussed in Section 9.2.3.1 and hence 1097 require a prefix change. Of course, if a prefix change were made (at 1098 the costs discussed in Section 9.2.3.3) there would be several 1099 options, including, if desired, assigning the characer to the 1100 CONTEXTUAL RULE REQUIRED category and requiring that it only be used 1101 in carefully-selected contexts. 1103 6.5. Right to Left Text 1105 In order to be sure that the directionality of right to left text is 1106 unambiguous, IDNA2003 required that any label in which right to left 1107 characters appear both starts and ends with them, may not include any 1108 characters with strong left to right properties (which excludes other 1109 alphabetic characters but permits European digits), and rejects any 1110 other string that contains a right to left character. This is one of 1111 the few places where the IDNA algorithms (both old and new) are 1112 required to look at an entire label, not just at individual 1113 characters. The algorithmic model used in IDNA2003 rejects the label 1114 when the final character in a right to left string requires a 1115 combining mark in order to be correctly represented. 1117 This problem manifests itself in languages written with consonantal 1118 alphabets to which diacritical vocalic systems are applied, and in 1119 languages with orthographies derived from them where the combining 1120 marks may have different functionality. In both cases the combining 1121 marks can be essential components of the orthography. Examples of 1122 this are Yiddish, written with an extended Hebrew script, and Dhivehi 1123 (the official language of Maldives) which is written in the Thaana 1124 script (which is, in turn, derived from the Arabic script). The new 1125 rules for right to left scripts are described in [IDNA2008-Bidi]. 1127 7. IDNs and the Robustness Principle 1129 The model of IDNs described in this document can be seen as a 1130 particular instance of the "Robustness Principle" that has been so 1131 important to other aspects of Internet protocol design. This 1132 principle is often stated as "Be conservative about what you send and 1133 liberal in what you accept" (See, e.g., RFC 1123, Section 1.2.2 1134 [RFC1123]). For IDNs to work well, not only must the protocol be 1135 carefully designed and implemented, but zone administrators 1136 (registries) must have and require sensible policies about what is 1137 registered -- conservative policies -- and implement and enforce 1138 them. 1140 Conversely, lookup applications can (and SHOULD or maybe MUST) reject 1141 labels that clearly violate global (protocol) rules (no one has ever 1142 seriously claimed that being liberal in what is accepted requires 1143 being stupid). However, once one gets past such global rules and 1144 deals with anything sensitive to script or locale, it is necessary to 1145 assume that garbage has not been placed into the DNS, i.e., one must 1146 be liberal about what one is willing to look up in the DNS rather 1147 than guessing about whether it should have been permitted to be 1148 registered. 1150 As mentioned elsewhere, if a string cannot be successfully found in 1151 the DNS after the lookup processing described here, it makes no 1152 difference whether it simply wasn't registered or was prohibited by 1153 some rule. 1155 If lookup applications, as a user interface (UI) or other local 1156 matter, decide to warn about some strings that are valid under the 1157 global rules but that they perceive as dangerous, that is their 1158 prerogative and we can only hope that the market (and maybe 1159 regulators) will reinforce the good choices and discourage the poor 1160 ones. In this context, a lookup application that decides a string 1161 that is valid under the protocol is dangerous and refuses to look it 1162 up is in violation of the protocols; one that is willing to look 1163 something up, but warns against it, is exercising a local choice. 1165 8. Front-end and User Interface Processing 1167 Domain names may be identified and processed in many contexts. They 1168 may be typed in by users either by themselves or as part of URIs or 1169 IRIs. They may occur in running text or be processed by one system 1170 after being provided in another. Systems may wish to try to 1171 normalize URLs so as to determine (or guess) whether a reference is 1172 valid or two references point to the same object without actually 1173 looking the objects up and comparing them (that is necessary, not 1174 just a choice, for URI types that are not intended to be resolved). 1175 Some of these goals may be more easily and reliably satisfied than 1176 others. While there are strong arguments for any domain name that is 1177 placed "on the wire" -- transmitted between systems -- to be in the 1178 minimum-ambiguity forms of A-labels, U-labels, or LDH-labels, it is 1179 inevitable that programs that process domain names will encounter 1180 variant forms. 1182 One source of such forms will be labels created under IDNA2003 1183 because that protocol allowed labels that were transformed before 1184 they were turned from native-character into ACE ("xn--...") format. 1185 One consequence of the transformations was that, when the ToUnicode 1186 and ToASCII operations of IDNA2003 were applied, 1187 ToUnicode(ToASCII(original-label)) often did not produce the 1188 original-label. IDNA2008 explicitly defines A-labels and U-labels as 1189 different forms of the same abstract label, forms that are stable 1190 when conversions are performed between them, without mappings. A 1191 different way of explaining this is that there are, today, domain 1192 names in files on the Internet that use characters that cannot be 1193 represented directly in, or recovered from, (A-label) domain names 1194 but for which interpretations are provided by IDNA2003. There are 1195 two major categories of such characters, those that are removed by 1196 NFKC normalization and those upper-case characters that are mapped to 1197 lower-case (there are also a few characters that are given special- 1198 case mapping treatment in Stringprep). 1200 Other issues in domain name identification and processing arise 1201 because IDNA2003 specified that several other characters be treated 1202 as equivalent to the ASCII period (dot, full stop) character used as 1203 a label separator. If a string that might be a domain name appears 1204 in an arbitrary context (such as running text), it is difficult, even 1205 with only ASCII characters, to know whether an actual domain name (or 1206 a protocol parameter like a URI) is present and where it starts and 1207 ends. When using Unicode, this gets even more difficult if treatment 1208 of certain special characters (like the dot that separates labels in 1209 a domain name) depends on context (e.g., prior knowledge of whether 1210 the string represents a domain name or not). That knowledge is not 1211 available if the primary heuristic for identifying the presence of 1212 domain names in strings depends on the presence of dots separating 1213 groups of characters with no intervening spaces. 1214 [[anchor27: Above text is a substitute for an earlier (pre -01) 1215 version and is hoped to be more clear. Comments and improvements 1216 welcome.]] 1218 As discussed elsewhere in this document, the IDNA2008 model removes 1219 all of these mappings and interpretations, including the equivalence 1220 of different forms of dots, from the protocol, discouraging such 1221 mappings and leaving them, when necessary, to local processing. This 1222 should not be taken to imply that local processing is optional or can 1223 be avoided entirely. Instead, unless the program context is such 1224 that it is known that any IDNs that appear will be either U-labels or 1225 A-labels, or that other forms can safely be rejected, some local 1226 processing of apparent domain name strings will be required, both to 1227 maintain compatibility with IDNA2003 and to prevent user 1228 astonishment. Such local processing, while not specified in this 1229 document or the associated ones, will generally take one of two 1230 forms: 1232 o Generic Preprocessing. 1233 When the context in which the program or system that processes 1234 domain names operates is global, a reasonable balance must be 1235 found that is sensitive to the broad range of local needs and 1236 assumptions while, at the same time, not sacrificing the needs of 1237 one language, script, or user population to those of another. 1239 For this case, the best practice will usually be to apply NFKC and 1240 case-mapping (or, perhaps better yet, Stringprep itself), plus 1241 dot-mapping where appropriate, to the domain name string prior to 1242 applying IDNA. That practice will not only yield a reasonable 1243 compromise of user experience with protocol requirements but will 1244 be almost completely compatible with the various forms permitted 1245 by IDNA2003. 1247 o Highly Localized Preprocessing. 1248 Unlike the case above, there will be some situations in which 1249 software will be highly localized for a particular environment and 1250 carefully adapted to the expectations of users in that 1251 environment. The many discussions about using the Internet to 1252 preserve and support local cultures suggest that these cases may 1253 be more common in the future than they have been so far. 1255 In these cases, we should avoid trying to tell implementers what 1256 they should do, if only because they are quite likely (and for 1257 good reason) to ignore us. We would assume that they would map 1258 characters that the intuitions of their users would suggest be 1259 mapped and would hope that they would do that mapping as early as 1260 possible, storing A-label or U-label forms in files and 1261 transporting only those forms between systems. One can imagine 1262 switches about whether some sorts of mappings occur, warnings 1263 before applying them or, in a slightly more extreme version of the 1264 approach taken in Internet Explorer version 7 (IE7), systems that 1265 utterly refuse to handle "strange" characters at all if they 1266 appear in U-label form. None of those local decisions are a 1267 threat to interoperability as long as (i) only U-labels and 1268 A-labels are used in interchange with systems outside the local 1269 environment, (ii) no character that would be valid in a U-label as 1270 itself is mapped to something else, (iii) any local mappings are 1271 applied as a preprocessing step (or, for conversions from U-labels 1272 or A-labels to presentation forms, postprocessing), not as part of 1273 IDNA processing proper, and (iv) appropriate consideration is 1274 given to labels that might have entered the environment in 1275 conformance to IDNA2003. [[anchor28: Placeholder: there have been 1276 suggestions that this text be removed entirely. Comments (or 1277 improved text) welcome.]] 1279 In either case, it is vital that user interface designs and, where 1280 the interfaces are not sufficient, users, be aware that the only 1281 forms of domain names that this protocol anticipates will resolve 1282 globally or compare equal when crude methods (i.e., those not 1283 conforming to Section 1.5.4.4) are used are those in which all 1284 native-script labels are in U-label form. Forms that assume mapping 1285 will occur, especially forms that were not valid under IDNA2003, may 1286 or may not function in predictable ways across all implementations. 1288 9. Relationship to IDNA2003 and Earlier Versions of Unicode 1289 9.1. Summary of Major Changes from IDNA2003 1291 1. Update base character set from Unicode 3.2 to Unicode version- 1292 agnostic. 1294 2. Separate the definitions for the "registration" and "lookup" 1295 activities. 1297 3. Disallow symbol and punctuation characters except where special 1298 exceptions are necessary. 1300 4. Remove the mapping and normalization steps from the protocol and 1301 have them instead done by the applications themselves, possibly 1302 in a local fashion, before invoking the protocol. 1304 5. Change the way that the protocol specifies which characters are 1305 allowed in labels from "humans decide what the table of 1306 codepoints contains" to "decision about codepoints are based on 1307 Unicode properties plus a small exclusion list created by 1308 humans". 1310 6. Introduce the new concept of characters that can be used only in 1311 specific contexts. 1313 7. Allow typical words and names in languages such as Dhivehi and 1314 Yiddish to be expressed. 1316 8. Make bidirectional domain names (delimited strings of labels, 1317 not just labels standing on their own) display in a non- 1318 surprising fashion whether they appear in obvious domain name 1319 contexts or as part of running text in paragraphs. 1321 9. Remove the dot separator from the mandatory part of the 1322 protocol. 1324 10. Make some currently-valid labels that are not actually IDNA 1325 labels invalid. 1327 9.2. Migration and Version Synchronization 1329 9.2.1. Design Criteria 1331 As mentioned above and in RFC 4690, two key goals of this work are to 1332 enable applications to be agnostic about whether they are being run 1333 in environments supporting any Unicode version from 3.2 onward and to 1334 permit incrementally adding permitted scripts and other character 1335 collections without disruption or, subsequent to this version, 1336 "heavy" processes such as formation of an IETF WG. The mechanisms 1337 that support this are outlined above, but this section reviews them 1338 in a context that may be more helpful to those who need to understand 1339 the approach and make plans for it. 1341 9.2.1.1. General IDNA Validity Criteria 1343 The general criteria for a putative label, and the collection of 1344 characters that make it up, to be considered IDNA-valid are: 1346 o The characters are "letters", marks needed to form letters, 1347 numerals, or other code points used to write words in some 1348 language. Symbols, drawing characters, and various notational 1349 characters are permanently excluded -- some because they are 1350 actively dangerous in URI, IRI, or similar contexts and others 1351 because there is no evidence that they are important enough to 1352 Internet operations or internationalization to justify inclusion 1353 and the complexities that would come with it (additional 1354 discussion and rationale for the symbol decision appears in 1355 Section 9.2.5). 1357 o Other than in very exceptional cases, e.g., where they are needed 1358 to write substantially any word of a given language, punctuation 1359 characters are excluded as well. The fact that a word exists is 1360 not proof that it should be usable in a DNS label and DNS labels 1361 are not expected to be usable for multiple-word phrases (although 1362 they are certainly not prohibited if the conventions and 1363 orthography of a particular language cause that to be possible). 1364 Even for English, very common constructions -- contractions like 1365 "don't" or "it's", names that are written with apostrophes such as 1366 "O'Reilly" or characters for which apostrophes are common 1367 substitutes, and words whose usually-preferred spellings retain 1368 diacritical marks from earlier forms -- cannot be represented in 1369 DNS labels. 1371 o Characters that are unassigned (have no character assignment at 1372 all) in the version of Unicode being used by the registry or 1373 application are not permitted, even on lookup. There are at least 1374 two reasons for this. Tests involving the context of characters 1375 (e.g., some characters being permitted only adjacent to ones of 1376 specific types but otherwise invisible or very problematic for 1377 other reasons) and integrity tests on complete labels are needed. 1378 Unassigned code points cannot be permitted because one cannot 1379 determine whether particular code points will require contextual 1380 rules (and what those rules should be) before characters are 1381 assigned to them and the properties of those characters fully 1382 understood. Second, Unicode specifies that an unassigned code 1383 point normalizes and case folds to itself. If the code point is 1384 later assigned to a character, and particularly if the newly- 1385 assigned code point has a combining class that determines its 1386 placement relative to other combining characters, it could 1387 normalize to some other code point or sequence, creating confusion 1388 and/or violating other rules listed here. 1390 o Any character that is mapped to another character by Nameprep2003 1391 or by a current version of NFKC is prohibited as input to IDNA 1392 (for either registration or lookup). Implementers of user 1393 interfaces to applications are free to make those conversions when 1394 they consider them suitable for their operating system 1395 environments, context, or users. 1397 Tables used to identify the characters that are IDNA-valid are 1398 expected to be driven by the principles above (described in more 1399 precise form in [IDNA2008-Tables]). The principles are not just an 1400 interpretation of the tables. 1402 9.2.1.2. Labels in Registration 1404 Anyone entering a label into a DNS zone must properly validate that 1405 label -- i.e., be sure that the criteria for that label are met -- in 1406 order for applications to work as intended. This principle is not 1407 new: for example, zone administrators are expected to verify that 1408 names meet "hostname" [RFC0952] or special service location formats 1409 [RFC2782] where necessary for the expected applications. For zones 1410 that will contain IDNs, support for Unicode version-independence 1411 requires restrictions on all strings placed in the zone. In 1412 particular, for such zones: 1414 o Any label that appears to be an A-label, i.e., any label that 1415 starts in "xn--", MUST be IDNA-valid, i.e., that they MUST be 1416 valid A-labels, as discussed in Section 2 above. 1418 o The Unicode tables (i.e., tables of code points, character 1419 classes, and properties) and IDNA tables (i.e., tables of 1420 contextual rules such as those described above), MUST be 1421 consistent on the systems performing or validating labels to be 1422 registered. Note that this does not require that tables reflect 1423 the latest version of Unicode, only that all tables used on a 1424 given system are consistent with each other. 1426 [[anchor31: Note in draft: the above text was changed significantly 1427 between -00 and -01 to clearly restrict its scope to zones supporting 1428 IDNA and to eliminate comments about labels containing "--" in the 1429 third and forth positions but with different prefixes. There appears 1430 to be consensus that more extensive rules belong in a "best 1431 practices" document about appropriate DNS labels, but that document 1432 is not in-scope for the IDNABIS WG.]] 1433 Under this model, a registry (or entity communicating with a registry 1434 to accomplish name registrations) will need to update its tables -- 1435 both the Unicode-associated tables and the tables of permitted IDN 1436 characters -- to enable a new script or other set of new characters. 1437 It will not be affected by newer versions of Unicode, or newly- 1438 authorized characters, until and unless it wishes to make those 1439 registrations. The registration side is also responsible --under the 1440 protocol and to registrants and users-- for much more careful 1441 checking than is expected of applications systems that look names up, 1442 both checking as required by the protocol and checking required by 1443 whatever policies it develops for minimizing risks due to confusable 1444 characters and sequences and preserving language or script integrity. 1446 Systems looking up or resolving DNS labels, especially IDN DNS 1447 labels, MUST be able to assume that applicable registration rules 1448 were followed for names entered into the DNS. 1450 9.2.1.3. Labels in Lookup 1452 Anyone looking up a label in a DNS zone 1454 o MUST maintain a consistent set of tables, as discussed above. As 1455 with registration, the tables need not reflect the latest version 1456 of Unicode but they MUST be consistent. 1458 o MUST validate the characters in labels to be looked up only to the 1459 extent of determining that the U-label does not contain either 1460 code points prohibited by IDNA (categorized as "DISALLOWED") or 1461 code points that are unassigned in its version of Unicode. 1463 o MUST validate the label itself for conformance with a small number 1464 of whole-label rules, notably verifying that there are no leading 1465 combining marks, that the "bidi" conditions are met if right to 1466 left characters appear, that any required contextual rules are 1467 available and that, if such rules are associated with Joiner 1468 Controls, they are tested. 1470 o MUST NOT validate other contextual rules about characters, 1471 including mixed-script label prohibitions, although such rules MAY 1472 be used to influence presentation decisions in the user interface. 1474 By avoiding applying its own interpretation of which labels are valid 1475 as a means of rejecting lookup attempts, the lookup application 1476 becomes less sensitive to version incompatibilities with the 1477 particular zone registry associated with the domain name. 1479 An application or client that looks processes names according to this 1480 protocol and then resolves them in the DNS will be able to locate any 1481 name that is validly registered, as long as its version of the 1482 Unicode-associated tables is sufficiently up-to-date to interpret all 1483 of the characters in the label. It SHOULD distinguish, in its 1484 messages to users, between "label contains an unallocated code point" 1485 and other types of lookup failures. A failure on the basis of an old 1486 version of Unicode may lead the user to a desire to upgrade to a 1487 newer version, but will have no other ill effects (this is consistent 1488 with behavior in the transition to the DNS when some hosts could not 1489 yet handle some forms of names or record types). 1491 9.2.2. More Flexibility in User Agents 1493 These specifications do not perform mappings between one character or 1494 code point and others for any reason. Instead, they prohibits the 1495 characters that would be mapped to others by normalization, case 1496 folding, or other rules. As examples, while mathematical characters 1497 based on Latin ones are accepted as input to IDNA2003, they are 1498 prohibited in IDNA2008. Similarly, double-width characters and other 1499 variations are prohibited as IDNA input. 1501 Since the rules in [IDNA2008-Tables] provide that only strings that 1502 are stable under NFKC are valid, if it is convenient for an 1503 application to perform NFKC normalization before lookup, that 1504 operation is safe since this will never make the application unable 1505 to look up any valid string. 1507 In many cases these prohibitions should have no effect on what the 1508 user can type as input to the lookup process. It is perfectly 1509 reasonable for systems that support user interfaces to perform some 1510 character mapping that is appropriate to the local environment. This 1511 would normally be done prior to actual invocation of IDNA. At least 1512 conceptually, the mapping would be part of the Unicode conversions 1513 discussed above and in [IDNA2008-Protocol]. However, those changes 1514 will be local ones only -- local to environments in which users will 1515 clearly understand that the character forms are equivalent. For use 1516 in interchange among systems, it appears to be much more important 1517 that U-labels and A-labels can be mapped back and forth without loss 1518 of information. 1520 One specific, and very important, instance of this strategy arises 1521 with case-folding. In the ASCII-only DNS, names are looked up and 1522 matched in a case-independent way, but no actual case-folding occurs. 1523 Names can be placed in the DNS in either upper or lower case form (or 1524 any mixture of them) and that form is preserved, returned in queries, 1525 and so on. IDNA2003 simulated that behavior by performing case- 1526 mapping at registration time (resulting in only lower-case IDNs in 1527 the DNS) and when names were looked up. 1529 As suggested earlier in this section, it appears to be desirable to 1530 do as little character mapping as possible consistent with having 1531 Unicode work correctly (e.g., NFC mapping to resolve different 1532 codings for the same character is still necessary although the 1533 specifications require that it be performed prior to invoking the 1534 protocol) and to make the mapping between A-labels and U-labels 1535 idempotent. Case-mapping is not an exception to this principle. If 1536 only lower case characters can be registered in the DNS (i.e., be 1537 present in a U-label), then IDNA2008 should prohibit upper-case 1538 characters as input. Some other considerations reinforce this 1539 conclusion. For example, an essential element of the ASCII case- 1540 mapping functions is that uppercase(character) must be equal to 1541 uppercase(lowercase(character)). That requirement may not be 1542 satisfied with IDNs. The relationship between upper case and lower 1543 case may even be language-dependent, with different languages (or 1544 even the same language in different areas) expecting different 1545 mappings. Of course, the expectations of users who are accustomed to 1546 a case-insensitive DNS environment will probably be well-served if 1547 user agents perform case mapping prior to IDNA processing, but the 1548 IDNA procedures themselves should neither require such mapping nor 1549 expect them when they are not natural to the localized environment. 1551 9.2.3. The Question of Prefix Changes 1553 The conditions that would require a change in the IDNA "prefix" 1554 ("xn--" for the version of IDNA specified in [RFC3490]) have been a 1555 great concern to the community. A prefix change would clearly be 1556 necessary if the algorithms were modified in a manner that would 1557 create serious ambiguities during subsequent transition in 1558 registrations. This section summarizes our conclusions about the 1559 conditions under which changes in prefix would be necessary and the 1560 implications of such a change. 1562 9.2.3.1. Conditions Requiring a Prefix Change 1564 An IDN prefix change is needed if a given string would be looked up 1565 or otherwise interpreted differently depending on the version of the 1566 protocol or tables being used. Consequently, work to update IDNs 1567 would require a prefix change if, and only if, one of the following 1568 four conditions were met: 1570 1. The conversion of an A-label to Unicode (i.e., a U-label) yields 1571 one string under IDNA2003 (RFC3490) and a different string under 1572 IDNA2008. 1574 2. An input string that is valid under IDNA2003 and also valid under 1575 IDNA2008 yields two different A-labels with the different 1576 versions of IDNA. This condition is believed to be essentially 1577 equivalent to the one above. 1579 Note, however, that if the input string is valid under one 1580 version and not valid under the other, this condition does not 1581 apply. See the first item in Section 9.2.3.2, below. 1583 3. A fundamental change is made to the semantics of the string that 1584 is inserted in the DNS, e.g., if a decision were made to try to 1585 include language or specific script information in that string, 1586 rather than having it be just a string of characters. 1588 4. A sufficiently large number of characters is added to Unicode so 1589 that the Punycode mechanism for block offsets no longer has 1590 enough capacity to reference the higher-numbered planes and 1591 blocks. This condition is unlikely even in the long term and 1592 certain not to arise in the next few years. 1594 9.2.3.2. Conditions Not Requiring a Prefix Change 1596 In particular, as a result of the principles described above, none of 1597 the following changes require a new prefix: 1599 1. Prohibition of some characters as input to IDNA. This may make 1600 names that are now registered inaccessible, but does not require 1601 a prefix change. 1603 2. Adjustments in Stringprep tables or IDNA actions, including 1604 normalization definitions, that affect characters that were 1605 already invalid under IDNA2003. 1607 3. Changes in the style of definitions of Stringprep or Nameprep 1608 that do not alter the actions performed by them. 1610 Of course, because these specifications do not involve changes to 1611 Stringprep or Nameprep, the third condition above and part of the 1612 second are moot. 1614 9.2.3.3. Implications of Prefix Changes 1616 While it might be possible to make a prefix change, the costs of such 1617 a change are considerable. Even if they wanted to do so, all 1618 registries could not convert all IDNA2003 ("xn--") registrations to a 1619 new form at the same time and synchronize that change with 1620 applications supporting lookup. Unless all existing registrations 1621 were simply to be declared invalid, and perhaps even then, systems 1622 that needed to support both labels with old prefixes and labels with 1623 new ones would first process a putative label under the IDNA2008 1624 rules and try to look it up and then, if it were not found, would 1625 process the label under IDNA2003 rules and look it up again. That 1626 process could significantly slow down all processing that involved 1627 IDNs in the DNS especially since, in principle, a fully-qualified 1628 name could contain a mixture of labels that were registered with the 1629 old and new prefixes, a situation that would make the use of DNS 1630 caching very difficult. In addition, looking up the same input 1631 string as two separate A-labels would create some potential for 1632 confusion and attacks, since they could, in principle, map to 1633 different targets and then resolve to different DNS label nodes. 1635 Consequently, a prefix change is to be avoided if at all possible, 1636 even if it means accepting some IDNA2003 decisions about character 1637 distinctions as irreversible. 1639 9.2.4. Stringprep Changes and Compatibility 1641 Concerns have been expressed about problems for non-DNS uses of 1642 Stringprep being caused by changes to the specification intended to 1643 improve the handling of IDNs, most notably as this might affect 1644 identification and authentication protocols. Section 9.2.3, above, 1645 essentially also applies in this context. The proposed new inclusion 1646 tables [IDNA2008-Tables], the reduction in the number of characters 1647 permitted as input for registration or lookup (Section 5), and even 1648 the proposed changes in handling of right to left strings 1649 [IDNA2008-Bidi] either give interpretations to strings prohibited 1650 under IDNA2003 or prohibit strings that IDNA2003 permitted. Strings 1651 that are valid under both IDNA2003 and IDNA2008, and the 1652 corresponding versions of Stringprep, are not changed in 1653 interpretation. This protocol does not use either Nameprep or 1654 Stringprep as specified in IDNA2003. 1656 It is particularly important to keep IDNA processing separate from 1657 processing for various security protocols because some of the 1658 constraints that are necessary for smooth and comprehensible use of 1659 IDNs may be unwanted or undesirable in other contexts. For example, 1660 the criteria for good passwords or passphrases are very different 1661 from those for desirable IDNs. Similarly, internationalized SCSI 1662 identifiers and other protocol components are likely to have 1663 different requirements than IDNs. 1665 Perhaps even more important in practice, since most other known uses 1666 of Stringprep encode or process characters that are already in 1667 normalized form and expect the use of only those characters that can 1668 be used in writing words of languages, the changes proposed here and 1669 in [IDNA2008-Tables] are unlikely to have any effect at all, 1670 especially not on registries and registrations that follow rules 1671 already in existence when this work started. 1673 9.2.5. The Symbol Question 1675 One of the major differences between this specification and the 1676 original version of IDNA is that the original version permitted non- 1677 letter symbols of various sorts, including punctuation and line- 1678 drawing symbols, in the protocol. They were always discouraged in 1679 practice. In particular, both the "IESG Statement" about IDNA and 1680 all versions of the ICANN Guidelines specify that only language 1681 characters be used in labels. This specification disallows symbols 1682 entirely. There are several reasons for this, which include: 1684 o As discussed elsewhere, the original IDNA specification assumed 1685 that as many Unicode characters as possible should be permitted, 1686 directly or via mapping to other characters, in IDNs. This 1687 specification operates on an inclusion model, extrapolating from 1688 the LDH rules --which have served the Internet very well-- to a 1689 Unicode base rather than an ASCII base. 1691 o Most Unicode names for letters are, in most cases, fairly 1692 intuitive, unambiguous and recognizable to users of the relevant 1693 script. Symbol names are more problematic because there may be no 1694 general agreement on whether a particular glyph matches a symbol; 1695 there are no uniform conventions for naming; variations such as 1696 outline, solid, and shaded forms may or may not exist; and so on. 1697 As just one example, consider a "heart" symbol as it might appear 1698 in a logo that might be read as "I love...". While the user might 1699 read such a logo as "I love..." or "I heart...", considerable 1700 knowledge of the coding distinctions made in Unicode is needed to 1701 know that there more than one "heart" character (e.g., U+2665, 1702 U+2661, and U+2765) and how to describe it. These issues are of 1703 particular importance if strings are expected to be understood or 1704 transcribed by the listener after being read out loud. 1705 [[anchor33: The above paragraph remains controversial as to 1706 whether it is valid. The WG will need to make a decision if this 1707 section is not dropped entirely.]] 1709 o As a simplified example of this, assume one wanted to use a 1710 "heart" or "star" symbol in a label. This is problematic because 1711 the those names are ambiguous in the Unicode system of naming (the 1712 actual Unicode names require far more qualification). A user or 1713 would-be registrant has no way to know --absent careful study of 1714 the code tables-- whether it is ambiguous (e.g., where there are 1715 multiple "heart" characters) or not. Conversely, the user seeing 1716 the hypothetical label doesn't know whether to read it --try to 1717 transmit it to a colleague by voice-- as "heart", as "love", as 1718 "black heart", or as any of the other examples below. 1720 o The actual situation is even worse than this. There is no 1721 possible way for a normal, casual, user to tell the difference 1722 between the hearts of U+2665 and U+2765 and the stars of U+2606 1723 and U+2729 or the without somehow knowing to look for a 1724 distinction. We have a white heart (U+2661) and few black hearts 1725 and describing a label containing a heart symbol is hopelessly 1726 ambiguous. In cities where "Square" is a popular part of a 1727 location name, one might well want to use a square symbol in a 1728 label as well and there are far more squares of various flavors in 1729 Unicode than there are hearts or stars. 1731 o The consequence of these ambiguities of description and 1732 dependencies on distinctions that were, or were not, made in 1733 Unicode codings, is that symbols are a very poor basis for 1734 reliable communication. Consistent with this conclusion, the 1735 Unicode standard recommends that strings used in identifiers not 1736 contain symbols or punctuation [Unicode-UAX31]. Of course, these 1737 difficulties with symbols do not arise with actual pictographic 1738 languages and scripts which would be treated like any other 1739 language characters; the two should not be confused. 1741 [[anchor34: Note in Draft: Should the above section be significantly 1742 trimmed or eliminated?]] 1744 9.2.6. Migration Between Unicode Versions: Unassigned Code Points 1746 In IDNA2003, labels containing unassigned code points are looked up 1747 on the theory that, if they appear in labels and can be mapped and 1748 then resolved, the relevant standards must have changed and the 1749 registry has properly allocated only assigned values. 1751 In this specification, strings containing unassigned code points MUST 1752 NOT be either looked up or registered. There are several reasons for 1753 this, with the most important ones being: 1755 o It cannot be known with sufficient reliability in advance that a 1756 code point that was not previously assigned will not be assigned 1757 to a compatibility character. In IDNA2003, since there is no 1758 direct dependency on NFKC (Stringprep's tables are based on NFKC, 1759 but IDNA2003 depends only on Stringprep), allocation of a 1760 compatibility character might produce some odd situations, but it 1761 would not be a problem. In IDNA2008, where compatibility 1762 characters are generally assigned to DISALLOWED, permitting 1763 strings containing unassigned characters to be looked up would 1764 permit violating the principle that characters in DISALLOWED are 1765 not looked up. 1767 o More generally, the status of an unassigned character with regard 1768 to the DISALLOWED and PROTOCOL-VALID categories, and whether 1769 contextual rules are required with the latter, cannot be evaluated 1770 until a character is actually assigned and known. 1772 It is possible to argue that the issues above are not important and 1773 that, as a consequence, it is better to retain the principle of 1774 looking up labels even if they contain unassigned characters because 1775 all of the important scripts and characters have been coded as of 1776 Unicode 5.1 and hence unassigned code points will be assigned only to 1777 obscure characters or archaic scripts. Unfortunately, that does not 1778 appear to be a safe assumption for at least two reasons. First, much 1779 the same claim of completeness has been made for earlier versions of 1780 Unicode. The reality is that a script that is obscure to much of the 1781 world may still be very important to those who use it. Cultural and 1782 linguistic preservation principles make it inappropriate to declare 1783 the script of no importance in IDNs. Second, we already have 1784 counterexamples in, e.g., the relationships associated with new Han 1785 characters being added (whether in the BMP or in Unicode Plane 2). 1787 9.2.7. Other Compatibility Issues 1789 The existing (2003) IDNA model includes several odd artifacts of the 1790 context in which it was developed. Many, if not all, of these are 1791 potential avenues for exploits, especially if the registration 1792 process permits "source" names (names that have not been processed 1793 through IDNA and nameprep) to be registered. As one example, since 1794 the character Eszett, used in German, is mapped by IDNA2003 into the 1795 sequence "ss" rather than being retained as itself or prohibited, a 1796 string containing that character but that is otherwise in ASCII is 1797 not really an IDN (in the U-label sense defined above) at all. After 1798 Nameprep maps the Eszett out, the result is an ASCII string and so 1799 does not get an xn-- prefix, but the string that can be displayed to 1800 a user appears to be an IDN. The proposed IDNA2008 eliminates this 1801 artifact. A character is either permitted as itself or it is 1802 prohibited; special cases that make sense only in a particular 1803 linguistic or cultural context can be dealt with as localization 1804 matters where appropriate. 1806 10. Acknowledgments 1808 The editor and contributors would like to express their thanks to 1809 those who contributed significant early (pre-WG) review comments, 1810 sometimes accompanied by text, especially Mark Davis, Paul Hoffman, 1811 Simon Josefsson, and Sam Weiler. In addition, some specific ideas 1812 were incorporated from suggestions, text, or comments about sections 1813 that were unclear supplied by Frank Ellerman, Michael Everson, Asmus 1814 Freytag, Erik van der Poel, Michel Suignard, and Ken Whistler, 1815 although, as usual, they bear little or no responsibility for the 1816 conclusions the editor and contributors reached after receiving their 1817 suggestions. Thanks are also due to Vint Cerf, Debbie Garside, and 1818 Jefsey Morphin for conversations that led to considerable 1819 improvements in the content of this document. 1821 A meeting was held on 30 January 2008 to attempt to reconcile 1822 differences in perspective and terminology about this set of 1823 specifications between the design team and members of the Unicode 1824 Technical Consortium. The discussions at and subsequent to that 1825 meeting were very helpful in focusing the issues and in refining the 1826 specifications. The active participants at that meeting were (in 1827 alphabetic order as usual) Harald Alvestrand, Vint Cerf, Tina Dam, 1828 Mark Davis, Lisa Dusseault, Patrik Faltstrom (by telephone), Cary 1829 Karp, John Klensin, Warren Kumari, Lisa Moore, Erik van der Poel, 1830 Michel Suignard, and Ken Whistler. We express our thanks to Google 1831 for support of that meeting and to the participants for their 1832 contributions. 1834 Special thanks are due to Paul Hoffman for permission to extract 1835 material from his Internet-Draft to form the basis for Section 9.1. 1837 Useful comments and text on the WG versions of the draft were 1838 received from many participants in the IETF "IDNABIS" WG and a number 1839 of document changes resulted from mailing list discussions made by 1840 that group. Marcos Sanz provided specific analysis and suggestions 1841 that were exceptionally helpful in refining the text. 1843 11. Contributors 1845 While the listed editor held the pen, this core of this document and 1846 the initial WG version represents the joint work and conclusions of 1847 an ad hoc design team consisting of the editor and, in alphabetic 1848 order, Harald Alvestrand, Tina Dam, Patrik Faltstrom, and Cary Karp. 1849 In addition, there were many specific contributions and helpful 1850 comments from those listed in the Acknowledgments section and others 1851 who have contributed to the development and use of the IDNA 1852 protocols. 1854 12. Internationalization Considerations 1856 DNS labels and fully-qualified domain names provide mnemonics that 1857 assist in identifying and referring to resources on the Internet. 1858 IDNs expand the range of those mnemonics to include those based on 1859 languages and character sets other than Western European and Roman- 1860 derived ones. But domain "names" are not, in general, words in any 1861 language. The recommendations of the IETF policy on character sets 1862 and languages, BCP 18 [RFC2277] are applicable to situations in which 1863 language identification is used to provide language-specific 1864 contexts. The DNS is, by contrast, global and international and 1865 ultimately has nothing to do with languages. Adding languages (or 1866 similar context) to IDNs generally, or to DNS matching in particular, 1867 would imply context dependent matching in DNS, which would be a very 1868 significant change to the DNS protocol itself. It would also imply 1869 that users would need to identify the language associated with a 1870 particular label in order to look that label up, a decision that 1871 would be impossible in many or most cases. 1873 13. IANA Considerations 1875 This section gives an overview of registries required for IDNA. The 1876 actual definitions of the first two appear in [IDNA2008-Tables]. 1878 13.1. IDNA Character Registry 1880 The distinction among the three major categories "UNASSIGNED", 1881 "DISALLOWED", and "PROTOCOL-VALID" is made by special categories and 1882 rules that are integral elements of [IDNA2008-Tables]. Convenience 1883 in programming and validation requires a registry of characters and 1884 scripts and their categories, updated for each new version of Unicode 1885 and the characters it contains. The details of this registry are 1886 specified in [IDNA2008-Tables]. 1888 13.2. IDNA Context Registry 1890 For characters that are defined in the IDNA Character Registry list 1891 as PROTOCOL-VALID but requiring a contextual rule (i.e., the types of 1892 rule described in Section 5.1.1.1), IANA will create and maintain a 1893 list of approved contextual rules. The details for those rules 1894 appear in [IDNA2008-Tables]. 1896 13.3. IANA Repository of IDN Practices of TLDs 1898 This registry, historically described as the "IANA Language Character 1899 Set Registry" or "IANA Script Registry" (both somewhat misleading 1900 terms) is maintained by IANA at the request of ICANN. It is used to 1901 provide a central documentation repository of the IDN policies used 1902 by top level domain (TLD) registries who volunteer to contribute to 1903 it and is used in conjunction with ICANN Guidelines for IDN use. 1905 It is not an IETF-managed registry and, while the protocol changes 1906 specified here may call for some revisions to the tables, these 1907 specifications have no direct effect on that registry and no IANA 1908 action is required as a result. 1910 14. Security Considerations 1912 Security on the Internet partly relies on the DNS. Thus, any change 1913 to the characteristics of the DNS can change the security of much of 1914 the Internet. 1916 Domain names are used by users to identify and connect to Internet 1917 servers. The security of the Internet is compromised if a user 1918 entering a single internationalized name is connected to different 1919 servers based on different interpretations of the internationalized 1920 domain name. 1922 When systems use local character sets other than ASCII and Unicode, 1923 this specification leaves the problem of transcoding between the 1924 local character set and Unicode up to the application or local 1925 system. If different applications (or different versions of one 1926 application) implement different transcoding rules, they could 1927 interpret the same name differently and contact different servers. 1928 This problem is not solved by security protocols like TLS that do not 1929 take local character sets into account. 1931 To help prevent confusion between characters that are visually 1932 similar, it is suggested that implementations provide visual 1933 indications where a domain name contains multiple scripts. Such 1934 mechanisms can also be used to show when a name contains a mixture of 1935 simplified and traditional Chinese characters, or to distinguish zero 1936 and one from O and l. DNS zone administrators may impose 1937 restrictions (subject to the limitations identified elsewhere in this 1938 document) that try to minimize characters that have similar 1939 appearance or similar interpretations. It is worth noting that there 1940 are no comprehensive technical solutions to the problems of 1941 confusable characters. One can reduce the extent of the problems in 1942 various ways, but probably never eliminate it. Some specific 1943 suggestions about identification and handling of confusable 1944 characters appear in a Unicode Consortium publication 1945 [Unicode-UTR36]. 1947 The registration and lookup models described above and in 1948 [IDNA2008-Protocol] change the mechanisms available for lookup 1949 applications to determine the validity of labels they encounter. In 1950 some respects, the ability to test is strengthened. For example, 1951 putative labels that contain unassigned code points will now be 1952 rejected, while IDNA2003 permitted them (something that is now 1953 recognized as a considerable source of risk). On the other hand, the 1954 protocol specification no longer assumes that the application that 1955 looks up a name will be able to determine, and apply, information 1956 about the protocol version used in registration. In theory, that may 1957 increase risk since the application will be able to do less pre- 1958 lookup validation. In practice, the protection afforded by that test 1959 has been largely illusory for reasons explained in RFC 4690 and 1960 above. 1962 Any change to Stringprep or, more broadly, the IETF's model of the 1963 use of internationalized character strings in different protocols, 1964 creates some risk of inadvertent changes to those protocols, 1965 invalidating deployed applications or databases, and so on. Our 1966 current hypothesis is that the same considerations that would require 1967 changing the IDN prefix (see Section 9.2.3.2) are the ones that 1968 would, e.g., invalidate certificates or hashes that depend on 1969 Stringprep, but those cases require careful consideration and 1970 evaluation. More important, it is not necessary to change 1971 Stringprep2003 at all in order to make the IDNA changes contemplated 1972 here. It is far preferable to create a separate document, or 1973 separate profile components, for IDN work, leaving the question of 1974 upgrading to other protocols to experts on them and eliminating any 1975 possible synchronization dependency between IDNA changes and possible 1976 upgrades to security protocols or conventions. 1978 No mechanism involving names or identifiers alone can protect a wide 1979 variety of security threats and attacks that are largely independent 1980 of them including spoofed pages, DNS query trapping and diversion, 1981 and so on. 1983 15. Change Log 1985 [[anchor42: RFC Editor: Please remove this section.]] 1987 15.1. Changes between Version -00 and Version -01 of 1988 draft-ietf-idnabis-rationale 1990 o Clarified the U-label definition to note that U-labels must 1991 contain at least one non-ASCII character. Also clarified the 1992 relationship among label types. 1994 o Rewrote the discussion of Labels in Registration (Section 9.2.1.2) 1995 and related text in Section 1.5.4.1.1 to narrow its focus and 1996 remove more general restrictions. Added a temporary note in line 1997 to explain the situation. 1999 o Changed the "IDNA uses Unicode" statement to focus on 2000 compatibility with IDNA2003 and avoid more general or 2001 controversial assertions. 2003 o Added a discussion of examples to Section 9.2.1 2005 o Made a number of other small editorial changes and corrections 2006 suggested by Mark Davis. 2008 o Added several more discussion anchors and notes and expanded or 2009 updated some existing ones. 2011 15.2. Version -02 2013 o Trimmed change log, removing information about pre-WG drafts. 2015 o Adjusted discussion of Contextual Rules to match the new location 2016 of the tables and some conceptual material. 2018 o Rewrote the material on preprocessing somewhat. 2020 o Moved the material about relationships with IDNA2003 to be part of 2021 a single section on transitions. 2023 o Removed several placeholders and made editorial changes in 2024 accordance with decisions made at IETF 72 in Dublin and not 2025 disputed on the mailing list. 2027 16. References 2029 16.1. Normative References 2031 [ASCII] American National Standards Institute (formerly United 2032 States of America Standards Institute), "USA Code for 2033 Information Interchange", ANSI X3.4-1968, 1968. 2035 ANSI X3.4-1968 has been replaced by newer versions with 2036 slight modifications, but the 1968 version remains 2037 definitive for the Internet. 2039 [IDNA2008-Bidi] 2040 Alvestrand, H. and C. Karp, "An updated IDNA criterion for 2041 right to left scripts", July 2008, . 2044 [IDNA2008-Protocol] 2045 Klensin, J., "Internationalized Domain Names in 2046 Applications (IDNA): Protocol", July 2008, . 2049 [IDNA2008-Tables] 2050 Faltstrom, P., "The Unicode Code Points and IDNA", 2051 July 2008, . 2054 A version of this document is available in HTML format at 2055 http://stupid.domain.name/idnabis/ 2056 draft-ietf-idnabis-tables-02.html 2058 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2059 Requirement Levels", BCP 14, RFC 2119, March 1997. 2061 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 2062 Internationalized Strings ("stringprep")", RFC 3454, 2063 December 2002. 2065 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 2066 "Internationalizing Domain Names in Applications (IDNA)", 2067 RFC 3490, March 2003. 2069 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 2070 Profile for Internationalized Domain Names (IDN)", 2071 RFC 3491, March 2003. 2073 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 2074 for Internationalized Domain Names in Applications 2075 (IDNA)", RFC 3492, March 2003. 2077 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2078 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2079 May 2008. 2081 [RulesInit] 2082 Klensin, J., "Internationalizing Domain Names in 2083 Applications (IDNA): Protocol, Appendix A Contextual Rules 2084 Table", July 2008, . 2087 [Unicode-UAX15] 2088 The Unicode Consortium, "Unicode Standard Annex #15: 2089 Unicode Normalization Forms", March 2008, 2090 . 2092 [Unicode51] 2093 The Unicode Consortium, "The Unicode Standard, Version 2094 5.1.0", 2008. 2096 defined by: The Unicode Standard, Version 5.0, Boston, MA, 2097 Addison-Wesley, 2007, ISBN 0-321-48091-0, as amended by 2098 Unicode 5.1.0 2099 (http://www.unicode.org/versions/Unicode5.1.0/). 2101 16.2. Informative References 2103 [BIG5] Institute for Information Industry of Taiwan, "Computer 2104 Chinese Glyph and Character Code Mapping Table, Technical 2105 Report C-26", 1984. 2107 There are several forms and variations and a closely- 2108 related standard, CNS 11643. See the discussion in 2109 Chapter 3 of Lunde, K., CJKV Information Processing, 2110 O'Reilly & Associates, 1999 2112 [GB18030] "Chinese National Standard GB 18030-2000: Information 2113 Technology -- Chinese ideograms coded character set for 2114 information interchange -- Extension for the basic set.", 2115 2000. 2117 [RFC0810] Feinler, E., Harrenstien, K., Su, Z., and V. White, "DoD 2118 Internet host table specification", RFC 810, March 1982. 2120 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 2121 host table specification", RFC 952, October 1985. 2123 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2124 STD 13, RFC 1034, November 1987. 2126 [RFC1035] Mockapetris, P., "Domain names - implementation and 2127 specification", STD 13, RFC 1035, November 1987. 2129 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 2130 and Support", STD 3, RFC 1123, October 1989. 2132 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 2133 Specification", RFC 2181, July 1997. 2135 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 2136 Languages", BCP 18, RFC 2277, January 1998. 2138 [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", 2139 RFC 2673, August 1999. 2141 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2142 specifying the location of services (DNS SRV)", RFC 2782, 2143 February 2000. 2145 [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint 2146 Engineering Team (JET) Guidelines for Internationalized 2147 Domain Names (IDN) Registration and Administration for 2148 Chinese, Japanese, and Korean", RFC 3743, April 2004. 2150 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 2151 Identifiers (IRIs)", RFC 3987, January 2005. 2153 [RFC4290] Klensin, J., "Suggested Practices for Registration of 2154 Internationalized Domain Names (IDN)", RFC 4290, 2155 December 2005. 2157 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 2158 Recommendations for Internationalized Domain Names 2159 (IDNs)", RFC 4690, September 2006. 2161 [RFC4713] Lee, X., Mao, W., Chen, E., Hsu, N., and J. Klensin, 2162 "Registration and Administration Recommendations for 2163 Chinese Domain Names", RFC 4713, October 2006. 2165 [Unicode-UAX31] 2166 The Unicode Consortium, "Unicode Standard Annex #31: 2167 Unicode Identifier and Pattern Syntax", March 2008, 2168 . 2170 [Unicode-UTR36] 2171 The Unicode Consortium, "Unicode Technical Report #36: 2172 Unicode Security Considerations", July 2008, 2173 . 2175 Author's Address 2177 John C Klensin 2178 1770 Massachusetts Ave, Ste 322 2179 Cambridge, MA 02140 2180 USA 2182 Phone: +1 617 245 1457 2183 Email: john+ietf@jck.com 2185 Full Copyright Statement 2187 Copyright (C) The IETF Trust (2008). 2189 This document is subject to the rights, licenses and restrictions 2190 contained in BCP 78, and except as set forth therein, the authors 2191 retain all their rights. 2193 This document and the information contained herein are provided on an 2194 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2195 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2196 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2197 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2198 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2199 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2201 Intellectual Property 2203 The IETF takes no position regarding the validity or scope of any 2204 Intellectual Property Rights or other rights that might be claimed to 2205 pertain to the implementation or use of the technology described in 2206 this document or the extent to which any license under such rights 2207 might or might not be available; nor does it represent that it has 2208 made any independent effort to identify any such rights. Information 2209 on the procedures with respect to rights in RFC documents can be 2210 found in BCP 78 and BCP 79. 2212 Copies of IPR disclosures made to the IETF Secretariat and any 2213 assurances of licenses to be made available, or the result of an 2214 attempt made to obtain a general license or permission for the use of 2215 such proprietary rights by implementers or users of this 2216 specification can be obtained from the IETF on-line IPR repository at 2217 http://www.ietf.org/ipr. 2219 The IETF invites any interested party to bring to its attention any 2220 copyrights, patents or patent applications, or other proprietary 2221 rights that may cover technology that may be required to implement 2222 this standard. Please address the information to the IETF at 2223 ietf-ipr@ietf.org.