idnits 2.17.1 draft-klensin-idnabis-protocol-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 743. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 754. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 767. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3490, but the abstract doesn't seem to mention this, which it should. 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 (February 6, 2008) is 5923 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: 'ASCII' is defined on line 676, but no explicit reference was found in the text == Unused Reference: 'Unicode' is defined on line 712, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-alvestrand-idna-bidi-03 == Outdated reference: A later version (-07) exists of draft-klensin-idnabis-issues-06 -- Possible downref: Normative reference to a draft: ref. 'IDNA200X-Rationale' == Outdated reference: A later version (-05) exists of draft-faltstrom-idnabis-tables-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode-UAX15' -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 4952 (Obsoleted by RFC 6530) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin, Ed. 3 Internet-Draft February 6, 2008 4 Obsoletes: 3490 (if approved) 5 Intended status: Standards Track 6 Expires: August 9, 2008 8 Internationalizing Domain Names in Applications (IDNA): Protocol 9 draft-klensin-idnabis-protocol-04.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 August 9, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document supplies the protocol definition for a revised and 43 updated specification for internationalized domain names (IDNs). The 44 rationale for these changes, the relationship to the older 45 specification, and important terminology are provided in other 46 documents. This document specifies the protocol mechanism, called 47 Internationalizing Domain Names in Applications (IDNA), for 48 registering and looking up IDNs in a way that does not require 49 changes to the DNS itself. IDNA is only meant for processing domain 50 names, not free text. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Discussion Forum . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Requirements and Applicability . . . . . . . . . . . . . . . . 5 58 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2.1. DNS Resource Records . . . . . . . . . . . . . . . . . 5 61 3.2.2. Non-domain-name Data Types Stored in the DNS . . . . . 6 62 4. Registration Protocol . . . . . . . . . . . . . . . . . . . . 6 63 4.1. Proposed label . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. Conversion to Unicode and Normalization . . . . . . . . . 6 65 4.3. Permitted Character and Label Validation . . . . . . . . . 7 66 4.3.1. Rejection of Characters that are not Permitted . . . . 7 67 4.3.2. Label Validation . . . . . . . . . . . . . . . . . . . 7 68 4.3.3. Registration Validation Summary . . . . . . . . . . . 8 69 4.4. Registry Restrictions . . . . . . . . . . . . . . . . . . 8 70 4.5. Punycode Conversion . . . . . . . . . . . . . . . . . . . 8 71 4.6. Insertion in the Zone . . . . . . . . . . . . . . . . . . 8 72 5. Domain Name Resolution (Lookup) Protocol . . . . . . . . . . . 8 73 5.1. Label String Input . . . . . . . . . . . . . . . . . . . . 9 74 5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 9 75 5.3. Character Changes in Preprocessing or the User 76 Interface . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5.4. Validation and Character List Testing . . . . . . . . . . 10 78 5.5. Punycode Conversion . . . . . . . . . . . . . . . . . . . 11 79 5.6. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 11 80 6. Name server Considerations . . . . . . . . . . . . . . . . . . 11 81 6.1. Processing Non-ASCII Strings . . . . . . . . . . . . . . . 11 82 6.2. DNSSEC Authentication of IDN Domain Names . . . . . . . . 12 83 6.3. Root Server Considerations . . . . . . . . . . . . . . . . 12 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 9.1. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 13 88 9.2. Versions -01 and -02 . . . . . . . . . . . . . . . . . . . 13 89 9.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 14 90 9.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 14 91 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 95 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 Intellectual Property and Copyright Statements . . . . . . . . . . 18 100 1. Introduction 102 This document supplies the protocol definition for a revised and 103 updated specification for internationalized domain names. The 104 rationale for these changes and relationship to the older 105 specification and some new terminology is provided in other 106 documents, notably [IDNA200X-Rationale]. 108 IDNA works by allowing applications to use certain ASCII string 109 labels (beginning with a special prefix) to represent non-ASCII name 110 labels. Lower-layer protocols need not be aware of this; therefore 111 IDNA does not depend on changes to any infrastructure. In 112 particular, IDNA does not depend on any changes to DNS servers, 113 resolvers, or protocol elements, because the ASCII name service 114 provided by the existing DNS is entirely sufficient for IDNA. 116 IDNA is applied only to DNS labels. Standards for combining labels 117 into fully-qualified domain names and parsing labels out of those 118 names are covered in the base DNS standards [RFC1035]. An 119 application may, of course, apply locally-appropriate conventions to 120 the presentation forms of domain names as discussed in 121 [IDNA200X-Rationale]. 123 While they share terminology, reference data, and some operations, 124 this document describes two separate protocols, one for IDN 125 registration (Section 4) and one for IDN lookup (Section 5). 127 A good deal of the background material that appeared in RFC 3490 has 128 been removed from this update. That material is either of historical 129 interest only or has been covered from a more recent perspective in 130 RFC 4690 [RFC4690] and [IDNA200X-Rationale]. 132 [[anchor2: Note in Draft: This document still needs more specifics 133 about how to perform some of the tests in the Registration and Lookup 134 protocols described below. Those details will be supplied in a later 135 revision, but the intent should be clear from the existing text.]] 137 1.1. Discussion Forum 139 [[anchor4: RFC Editor: please remove this section.]] 141 This work is being discussed on the mailing list 142 idna-update@alvestrand.no 144 2. Terminology 146 General terminology applicable to IDNA, but with meanings familiar to 147 those who have worked with Unicode or other character set standards 148 and the DNS, appears in [IDNA200X-Rationale]. Terminology that is an 149 integral, normative, part of the IDNA definition, including the 150 definitions of "ACE", appears in that document as well. Familiarity 151 with the terminology materials in that document is assumed for 152 reading this one. 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in BCP 14, RFC 2119 157 [RFC2119]. 159 3. Requirements and Applicability 161 3.1. Requirements 163 IDNA conformance means adherence to the following requirements: 165 1. Whenever a domain name is put into an IDN-unaware domain name 166 slot (see Section 2 and [IDNA200X-Rationale]), it MUST contain 167 only ASCII characters (i.e., must be either an A-label or an LDH- 168 label), or must a label associated with a DNS application that is 169 not subject to either IDNA or the historical recommendations for 170 "hostname"-style names [RFC1034]. 172 2. Comparison of labels MUST be done on the A-label form, using an 173 ASCII case-insensitive comparison as with all comparisons of DNS 174 labels. 176 3.2. Applicability 178 IDNA is applicable to all domain names in all domain name slots 179 except where it is explicitly excluded. It is not applicable to 180 domain name slots which do not use the LDH syntax rules. 182 This implies that IDNA is applicable to many protocols that predate 183 IDNA. Note that IDNs occupying domain name slots in those protocols 184 MUST be in A-label form. 186 3.2.1. DNS Resource Records 188 IDNA applies only to domain names in the NAME and RDATA fields of DNS 189 resource records whose CLASS is IN. 191 There are currently no other exclusions on the applicability of IDNA 192 to DNS resource records. Applicability depends entirely on the 193 CLASS, and not on the TYPE. This will remain true, even as new types 194 are defined, unless there is a compelling reason for a new type that 195 requires type-specific rules. It is worth noting that the special 196 naming conventions applicable to SRV records are precisely such type- 197 specific rules and that the SRV requirement for a leading underscore 198 ("_") in some labels is incompatible with IDNA coding. 200 3.2.2. Non-domain-name Data Types Stored in the DNS 202 Although IDNA enables the representation of non-ASCII characters in 203 domain names, that does not imply that IDNA enables the 204 representation of non-ASCII characters in other data types that are 205 stored in domain names, specifically in the RDATA field for types 206 that have structured RDATA format. For example, an email address 207 local part is stored in a domain name in the RNAME field as part of 208 the RDATA of an SOA record (hostmaster@example.com would be 209 represented as hostmaster.example.com). IDNA specifically does not 210 update the existing email standards, which allow only ASCII 211 characters in local parts. Other work is under development to define 212 internationalization for email addresses [RFC4952], but changes to 213 the email address part of the SOA RDATA would require action in other 214 standards. Such standards could also specify IDNA interpretation of 215 labels that follow the local part such as by permitting them to be 216 A-labels or even U-labels. 218 4. Registration Protocol 220 This section defines the procedure for registering an IDN. The 221 procedure is implementation independent; any sequence of steps that 222 produces exactly the same result for all labels is considered a valid 223 implementation. 225 4.1. Proposed label 227 The registrant submits a request for an IDN. The user typically 228 produces the request string by the keyboard entry of a character 229 sequence. 231 4.2. Conversion to Unicode and Normalization 233 Some system routine, or a localized front-end to the IDNA process, 234 ensures that the proposed label is a Unicode string. That string 235 MUST be in Unicode Normalization Form C (NFC [Unicode-UAX15]). 237 As a local implementation choice, the implementation MAY choose to 238 map some forbidden characters to permitted characters (for instance 239 mapping uppercase characters to lowercase ones), displaying the 240 result to the user, and allowing processing to continue. However, it 241 is strongly recommended that, to avoid any possible ambiguity, 242 entities responsible for zone files ("registries") accept 243 registrations only for A-labels or U-labels actually produced from 244 A-labels, not forms expected to be converted by some other process. 246 4.3. Permitted Character and Label Validation 248 4.3.1. Rejection of Characters that are not Permitted 250 The Unicode string is examined to prohibit characters that IDNA does 251 not permit in input. Those characters are identified in the 252 "DISALLOWED" and "UNASSIGNED" lists that are discussed in 253 [IDNA200X-Rationale]. The normative rules for producing that list 254 and the initial version of it are specified in [IDNA200X-Tables]. 255 Characters that are either DISALLOWED or UNASSIGNED MUST NOT be part 256 of labels being processed for registration in the DNS. 258 4.3.2. Label Validation 260 The proposed label is then examined, performing tests that require 261 examination of more than one character. 263 4.3.2.1. Leading Combining Marks 265 The first character of the string is examined to verify that it is 266 not a combining mark. If it is a combining mark, the string MUST NOT 267 be registered. 269 4.3.2.2. Contextual Rules 271 Each code point is checked for its identification as characters for 272 registration (the list of characters appears as the combination of 273 CONTEXTJ and CONTEXTO in [IDNA200X-Tables]). If that indication 274 appears, the table of contextual rules is checked for a rule for that 275 character. If no rule is found, the proposed label is rejected and 276 MUST NOT be installed in a zone file. If one is found, it is applied 277 (typically as a test on the entire label or on adjacent characters). 278 If the application of the rule does not conclude that the character 279 is valid in context, the proposed label MUST BE rejected. (See the 280 IANA Considerations: IDNA Context Registry section of 281 [IDNA200X-Rationale].) 283 4.3.2.3. Labels Containing Characters Written Right to Left 285 Additional special tests for right-to-left strings are applied (See 286 [IDNA200X-BIDI]. Strings that contain right to left characters that 287 do not conform to the rule identified there MUST NOT be inserted in 288 zone files. 290 4.3.3. Registration Validation Summary 292 Strings that have been produced by the steps above, and whose 293 contents pass the above tests, are U-labels. 295 To summarize, tests are made here for invalid characters, invalid 296 combinations of characters, and for labels that are invalid even if 297 the characters they contain are valid individually. For example, 298 labels containing invisible ("zero-width") characters may be 299 permitted in context with characters whose presentation forms are 300 significantly changed by the presence or absence of the zero-width 301 characters, while other labels in which zero-width characters appear 302 may be rejected. 304 4.4. Registry Restrictions 306 Registries at all levels of the DNS, not just the top level, are 307 expected to establish policies about the labels that may be 308 registered, and for the processes associated with that action. While 309 exact policies are not specified as part of IDNA200X and it is 310 expected that different registries may specify different policies, 311 there SHOULD be policies. These per-registry policies and 312 restrictions are an essential element of the IDNA registration 313 protocol even for registries (and corresponding zone files) deep in 314 the DNS hierarchy. As discussed in [IDNA200X-Rationale], such 315 restrictions have always existed in the DNS. 317 The string produced by the above steps is checked and processed as 318 appropriate to local registry restrictions. Application of those 319 registry restrictions may result in the rejection of some labels or 320 the application of special restrictions to others. 322 4.5. Punycode Conversion 324 The resulting U-label is converted to an A-label (i.e., the encoding 325 of that label according to the Punycode algorithm [RFC3492] with the 326 prefix included, i.e., the "xn--..." form). 328 4.6. Insertion in the Zone 330 The A-label is registered in the DNS by insertion into a zone. 332 5. Domain Name Resolution (Lookup) Protocol 334 Resolution is conceptually different from registration and different 335 tests are applied on the client. Although some validity checks are 336 necessary to avoid serious problems with the protocol (see 337 Section 5.4 ff.), the resolution-side tests are more permissive and 338 rely heavily on the assumption that names that are present in the DNS 339 are valid. Among other things, this distinction, applied carefully, 340 facilitates expansion of the permitted character lists to include new 341 scripts and accommodate new versions of Unicode without introducing 342 ambiguity into domain name processing. 344 5.1. Label String Input 346 The user supplies a string in the local character set, typically by 347 typing it or clicking on, or copying and pasting, a resource 348 identifier, e.g., a URI [RFC3986] or IRI [RFC3987] from which the 349 domain name is extracted. Or some process not directly involving the 350 user may read the string from a file or obtain it in some other way. 351 Processing in this step and the next two are local matters, to be 352 accomplished prior to actual invocation of IDNA, but at least this 353 one and the next one must be accomplished in some way. 355 5.2. Conversion to Unicode 357 The local character set, character coding conventions, and, as 358 necessary, display and presentation conventions, are converted to 359 Unicode (without surrogates), paralleling the process described above 360 in Section 4.2. 362 5.3. Character Changes in Preprocessing or the User Interface 364 The Unicode string MAY then be processed, in a way specific to the 365 local environment, to make the result of the IDNA processing match 366 user expectations. For instance, at this step, it would be 367 reasonable to convert all upper case characters to lower case, if 368 this makes sense in the user's environment. 370 Other examples of processing for localization that might be applied, 371 if appropriate, at this point (but even further outside the scope of 372 this specification) include interpreting the KANA MIDDLE DOT as 373 separating domain name components from each other, mapping different 374 "width" forms of the same character into the one form permitted in 375 labels, or giving special treatment to characters whose presentation 376 forms are dependent only on placement in the label. 378 Recommendations for preprocessing for global contexts (i.e., when 379 local considerations do not apply or cannot be used) and for maximum 380 interoperability with labels that might have been specified under 381 liberal readings of IDNA2003 are given in [IDNA200X-Rationale]. 383 Because these transformations are local, it is important that domain 384 names that might be passed between systems (e.g., in IRIs) be 385 U-labels or A-labels and not forms that might be accepted locally as 386 a consequence of this step. This step is not standardized as part of 387 IDNA, and is not further specified here. 389 5.4. Validation and Character List Testing 391 In parallel with the registration procedure, the Unicode string is 392 checked to verify that all characters that appear in it are valid for 393 IDNA resolution input. As discussed in [IDNA200X-Rationale], the 394 resolution check is more liberal than that of the registration one. 395 Putative labels with any of the following characteristics MUST BE 396 rejected prior to DNS lookup: 398 o Labels containing code points that are unassigned in the version 399 of Unicode being used by the application, i.e., in the 400 "Unassigned" Unicode category or the UNASSIGNED category of 401 [IDNA200X-Tables]. 403 o Labels that are not in NFC form. 405 o Labels containing prohibited code points, i.e., those that are 406 assigned to the "DISALLOWED" category in the permitted character 407 table [IDNA200X-Tables]. 409 o Labels containing code points that are shown in the permitted 410 character table as requiring a contextual rule and that are 411 flagged as requiring exceptional special processing on lookup 412 ("CONTEXTJ" in the Tables) MUST conform to the rule, which MUST be 413 present. 415 o Labels containing other code points that are shown in the 416 permitted character table as requiring a contextual rule 417 ("CONTEXTO" in the tables), but for which no such rule appears in 418 the table of rules. With the exception in the rule immediately 419 above, applications resolving DNS names or carrying out equivalent 420 operations are not required to test contextual rules, only to 421 verify that a rule exists. 423 o Labels whose first character is a combining mark. [[anchor15: Note 424 in Draft: this definition may need to be further tightened.]] 426 In addition, the application SHOULD apply the following test. The 427 test may be omitted in special circumstances, such as when the 428 resolver application knows that the conditions are enforced 429 elsewhere, because an attempt to resolve such strings will almost 430 certainly lead to a DNS lookup failure. However, applying the test 431 is likely to give much better information about the reason for a 432 lookup failure -- information that may be usefully passed to the user 433 when that is feasible -- then DNS resolution failure alone. 435 o Verification that the string is compliant with the requirements 436 for right to left characters, specified in [IDNA200X-BIDI]. 438 For all other strings, the resolver MUST rely on the presence or 439 absence of labels in the DNS to determine the validity of those 440 labels and the validity of the characters they contain. If they are 441 registered, they are presumed to be valid; if they are not, their 442 possible validity is not relevant. A resolver that declines to look 443 up a string that conforms to the above rules is not in conformance 444 with this protocol. 446 5.5. Punycode Conversion 448 The validated string, a U-label, is converted to an A-label using the 449 punycode algorithm. 451 5.6. DNS Name Resolution 453 The A-label is looked up in the DNS, using normal DNS procedures. 455 6. Name server Considerations 457 6.1. Processing Non-ASCII Strings 459 Existing DNS servers do not know the IDNA rules for handling non- 460 ASCII forms of IDNs, and therefore need to be shielded from them. 461 All existing channels through which names can enter a DNS server 462 database (for example, master files (as described in RFC 1034) and 463 DNS update messages [RFC2136]) are IDN-unaware because they predate 464 IDNA. Other sections of this document provide the needed shielding 465 by ensuring that internationalized domain names entering DNS server 466 databases through such channels have already been converted to their 467 equivalent ASCII A-label forms. 469 Because of the design of the algorithms in Section 4 and Section 5 (a 470 domain name containing only ASCII codepoints can not be converted to 471 an A-label), there can not be more than one label for each domain 472 name. 474 The current definition of the DNS protocol [RFC2181] explicitly 475 allows domain labels to contain octets beyond the ASCII range 476 (0000..007F), and this document does not change that. Note, however, 477 that there is no defined interpretation of octets 0080..00FF as 478 characters. If labels containing these octets are returned to 479 applications, unpredictable behavior could result. The A-label form, 480 which cannot contain those characters, is the only standard 481 representation for internationalized labels in the current DNS 482 protocol. 484 6.2. DNSSEC Authentication of IDN Domain Names 486 DNS Security [RFC2535] is a method for supplying cryptographic 487 verification information along with DNS messages. Public Key 488 Cryptography is used in conjunction with digital signatures to 489 provide a means for a requester of domain information to authenticate 490 the source of the data. This ensures that it can be traced back to a 491 trusted source, either directly or via a chain of trust linking the 492 source of the information to the top of the DNS hierarchy. 494 IDNA specifies that all internationalized domain names served by DNS 495 servers that cannot be represented directly in ASCII must use the 496 A-label form. Conversion to A-labels must be performed prior to a 497 zone being signed by the private key for that zone. Because of this 498 ordering, it is important to recognize that DNSSEC authenticates a 499 domain name containing A-labels or conventional LDH-labels, not 500 U-labels. In the presence of DNSSEC, no form of a zone file or query 501 response that contains a U-label may be signed or validated against. 503 One consequence of this for sites deploying IDNA in the presence of 504 DNSSEC is that any special purpose proxies or forwarders used to 505 transform user input into IDNs must be earlier in the resolution flow 506 than DNSSEC authenticating nameservers for DNSSEC to work. 508 6.3. Root Server Considerations 510 IDNs are likely to be somewhat longer than current domain names, so 511 the bandwidth needed by the root servers is likely to go up by a 512 small amount. Also, queries and responses for IDNs will probably be 513 somewhat longer than typical queries today, so more queries and 514 responses may be forced to go to TCP instead of UDP. 516 7. Security Considerations 518 The general security principles and issues for IDNA appear in 519 [IDNA200X-Rationale]. The comments below are specific to this pair 520 of protocols, but should be read in the context of that material and 521 the definitions and specifications, identified there, on which this 522 one depends. 524 This memo describes procedures for registering and looking up labels 525 that are not valid according to the base DNS specifications (STD13 526 [RFC1034] [RFC1035] and Host Requirements [RFC1123]) because they 527 contain non-ASCII characters. Those procedures depends on the use of 528 a special ACE encoded form, with the encoding specified in [RFC3492], 529 that contains only characters permitted in host names by those 530 specifications. No security issues such as string length increases 531 or new allowed values are introduced by the encoding process or the 532 use of these encoded values, apart from those introduced by the ACE 533 encoding itself. 535 Domain names (or portions of them) are sometimes compared against a 536 set of privileged or anti-privileged domains. In such situations it 537 is especially important that the comparisons be done properly, as 538 specified in requirement 2 of Section 3.1. For labels already in 539 ASCII form (i.e., are LDH-labels or A-labels), the proper comparison 540 reduces to the same case-insensitive ASCII comparison that has always 541 been used for ASCII labels. 543 The introduction of IDNA means that any existing labels that start 544 with the ACE prefix would be construed as U-labels, at least until 545 they failed one of the relevant tests, whether or not that was the 546 intent of the zone administrator or registrant. There is no evidence 547 that this has caused any practical problems since RFC 3490 was 548 adopted, but the risk still exists in principle. 550 8. IANA Considerations 552 IANA actions for this version of IDNA are specified in 553 [IDNA200X-Rationale]. 555 9. Change Log 557 [[anchor22: RFC Editor: Please remove this section.]] 559 9.1. Version -00 561 Version -00 of this draft was produced in November 2007 by moving 562 text from draft-klensin-idnabis-issues and by copy considerable text 563 from RFC 3490. The result was then extensively edited. 565 9.2. Versions -01 and -02 567 These versions reflected a number of editorial changes, some of them 568 significant, and alignment of terminology with 569 draft-faltstrom-idnabis-tables. 571 9.3. Version -03 573 o Abstract rewritten to bring its length within RFC Editor 574 guidelines. 576 o Corrections and revisions in response to extensive comments by 577 Mark Davis and others. 579 o Small modifications to several operations, including moving the 580 Normalization steps to a different place in the sequence. 582 o Many editorial changes. 584 9.4. Version -04 586 o Revised terminology and removed the MAYBE category as a 587 consequence of design discussions on 30 January 2003 and followup 588 conversations. Also restructed the various operations to treat 589 CONTEXTUAL RULE REQUIRED as a validation step (paralleling bidi), 590 rather than a category. Those changes required changes elsewhere 591 in the document for consistency. 593 o Changed the requirements for normalization, making this a 594 requirement on the calling application rather than an action of 595 this protocol. This is consistent with the general "mappings 596 belong somewhere else" principle. 598 o Updated references. 600 o More editorial work, some independent of the changes, described 601 immediately above. 603 10. Contributors 605 While the listed editor held the pen, this document represents the 606 joint work and conclusions of an ad hoc design team consisting of the 607 editor and, in alphabetic order, Harald Alvestrand, Tina Dam, Patrik 608 Faltstrom, and Cary Karp. This document draws significantly on the 609 original version of IDNA [RFC3490] both conceptually and for specific 610 text. This second-generation version would not have been possible 611 without the work that went into that first version and its authors, 612 Patrik Faltstrom, Paul Hoffman, and Adam Costello. While Faltstrom 613 was actively involved in the creation of this version, Hoffman and 614 Costello were not and should not be held responsible for any errors 615 or omissions. 617 11. Acknowledgements 619 This revision to IDNA would have been impossible without the 620 accumulated experience since RFC 3490 was published and resulting 621 comments and complaints of many people in the IETF, ICANN, and other 622 communities, too many people to list here. Nor would it have been 623 possible without RFC 3490 itself and the efforts of the Working Group 624 that defined it. Those people whose contributions are acknowledged 625 in RFC 3490, [RFC4690], and [IDNA200X-Rationale] were particularly 626 important. 628 12. References 630 12.1. Normative References 632 [IDNA200X-BIDI] 633 Alvestrand, H. and C. Karp, "An updated IDNA criterion for 634 right-to-left scripts", January 2008, . 638 [IDNA200X-Rationale] 639 Klensin, J., Ed., "Internationalizing Domain Names for 640 Applications (IDNA): Issues, Explanation, and Rationale", 641 February 2008, . 644 [IDNA200X-Tables] 645 Faltstrom, P., "The Unicode Codepoints and IDN", 646 February 2008, . 649 A version of this document, is available in HTML format at 650 http://stupid.domain.name/idnabis/ 651 draft-faltstrom-idnabis-tables-04.html 653 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 654 STD 13, RFC 1034, November 1987. 656 [RFC1035] Mockapetris, P., "Domain names - implementation and 657 specification", STD 13, RFC 1035, November 1987. 659 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 660 and Support", STD 3, RFC 1123, October 1989. 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", BCP 14, RFC 2119, March 1997. 665 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 666 for Internationalized Domain Names in Applications 667 (IDNA)", RFC 3492, March 2003. 669 [Unicode-UAX15] 670 The Unicode Consortium, "Unicode Standard Annex #15: 671 Unicode Normalization Forms", 2006, 672 . 674 12.2. Informative References 676 [ASCII] American National Standards Institute (formerly United 677 States of America Standards Institute), "USA Code for 678 Information Interchange", ANSI X3.4-1968, 1968. 680 ANSI X3.4-1968 has been replaced by newer versions with 681 slight modifications, but the 1968 version remains 682 definitive for the Internet. 684 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 685 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 686 RFC 2136, April 1997. 688 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 689 Specification", RFC 2181, July 1997. 691 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 692 RFC 2535, March 1999. 694 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 695 "Internationalizing Domain Names in Applications (IDNA)", 696 RFC 3490, March 2003. 698 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 699 Resource Identifier (URI): Generic Syntax", STD 66, 700 RFC 3986, January 2005. 702 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 703 Identifiers (IRIs)", RFC 3987, January 2005. 705 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 706 Recommendations for Internationalized Domain Names 707 (IDNs)", RFC 4690, September 2006. 709 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 710 Internationalized Email", RFC 4952, July 2007. 712 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 713 5.0", 2007. 715 Boston, MA, USA: Addison-Wesley. ISBN 0-321-48091-0 717 Author's Address 719 John C Klensin (editor) 720 1770 Massachusetts Ave, Ste 322 721 Cambridge, MA 02140 722 USA 724 Phone: +1 617 245 1457 725 Fax: 726 Email: john+ietf@jck.com 727 URI: 729 Full Copyright Statement 731 Copyright (C) The IETF Trust (2008). 733 This document is subject to the rights, licenses and restrictions 734 contained in BCP 78, and except as set forth therein, the authors 735 retain all their rights. 737 This document and the information contained herein are provided on an 738 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 739 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 740 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 741 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 742 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 743 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 745 Intellectual Property 747 The IETF takes no position regarding the validity or scope of any 748 Intellectual Property Rights or other rights that might be claimed to 749 pertain to the implementation or use of the technology described in 750 this document or the extent to which any license under such rights 751 might or might not be available; nor does it represent that it has 752 made any independent effort to identify any such rights. Information 753 on the procedures with respect to rights in RFC documents can be 754 found in BCP 78 and BCP 79. 756 Copies of IPR disclosures made to the IETF Secretariat and any 757 assurances of licenses to be made available, or the result of an 758 attempt made to obtain a general license or permission for the use of 759 such proprietary rights by implementers or users of this 760 specification can be obtained from the IETF on-line IPR repository at 761 http://www.ietf.org/ipr. 763 The IETF invites any interested party to bring to its attention any 764 copyrights, patents or patent applications, or other proprietary 765 rights that may cover technology that may be required to implement 766 this standard. Please address the information to the IETF at 767 ietf-ipr@ietf.org. 769 Acknowledgment 771 Funding for the RFC Editor function is provided by the IETF 772 Administrative Support Activity (IASA).