idnits 2.17.1 draft-klensin-idnabis-protocol-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 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 658. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 18, 2007) is 6002 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 558, but no explicit reference was found in the text == Unused Reference: 'RFC2181' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'Unicode' is defined on line 603, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IDNA200X-BIDI' -- Possible downref: Non-RFC (?) normative reference: ref. 'IDNA200X-issues' == Outdated reference: A later version (-05) exists of draft-faltstrom-idnabis-tables-03 -- 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 3 Internet-Draft November 18, 2007 4 Obsoletes: 3490 (if approved) 5 Intended status: Standards Track 6 Expires: May 21, 2008 8 Internationalizing Domain Names in Applications (IDNA): Protocol 9 draft-klensin-idnabis-protocol-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 May 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document supplies the protocol definition for a revised and 43 updated specification for internationalized domain names. The 44 rationale for these changes and relationship to the older 45 specification and some new terminology is provided in other 46 documents. This document specifies a standard method using 47 characters outside the ASCII repertoire in domain names. This 48 document defines internationalized domain names (IDNs) and a 49 mechanism called Internationalizing Domain Names in Applications 50 (IDNA) for handling them in a standard fashion. IDNs use characters 51 drawn from a large subset of the Unicode repertoire, but IDNA allows 52 the non-ASCII characters to be represented using only the ASCII 53 characters already allowed in so-called host names today. This 54 backward-compatible representation is required in existing protocols 55 like DNS, so that IDNs can be introduced with no changes to the 56 existing infrastructure. IDNA is only meant for processing domain 57 names, not free text. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Discussion Forum . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Requirements and Applicability . . . . . . . . . . . . . . . . 5 65 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2.1. DNS Resource Records . . . . . . . . . . . . . . . . . 5 68 3.2.2. Non-domain-name Data Types Stored in the DNS . . . . . 6 69 4. Registration Protocol . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Proposed label . . . . . . . . . . . . . . . . . . . . . . 6 71 4.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 6 72 4.3. Permitted Character Identification . . . . . . . . . . . . 6 73 4.4. Additional Character String Checking and Processing . . . 7 74 4.5. Registry Restrictions . . . . . . . . . . . . . . . . . . 8 75 4.6. Punycode Conversion . . . . . . . . . . . . . . . . . . . 8 76 4.7. Insertion in the Zone . . . . . . . . . . . . . . . . . . 8 77 5. Domain Name Resolution (Lookup) Protocol . . . . . . . . . . . 8 78 5.1. User input . . . . . . . . . . . . . . . . . . . . . . . . 8 79 5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 8 80 5.3. User Interface Character Changes . . . . . . . . . . . . . 9 81 5.4. Pre-Normalization Validation and Character List Testing . 9 82 5.5. Normalization . . . . . . . . . . . . . . . . . . . . . . 10 83 5.6. Post-Normalization Processing . . . . . . . . . . . . . . 10 84 5.7. Punycode Conversion . . . . . . . . . . . . . . . . . . . 10 85 5.8. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 10 86 6. Name server Considerations . . . . . . . . . . . . . . . . . . 10 87 6.1. Processing Non-ASCII Strings . . . . . . . . . . . . . . . 10 88 6.2. DNSSEC Authentication of IDN Domain Names . . . . . . . . 11 89 6.3. Root Server Considerations . . . . . . . . . . . . . . . . 11 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 92 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 96 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 98 Intellectual Property and Copyright Statements . . . . . . . . . . 16 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-issues]. 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-issues]. 123 A good deal of the background material that appeared in RFC 3490 has 124 been removed from this update. That material is either of historical 125 interest only or has been covered from a more recent perspective in 126 RFC 4690 [RFC4690] and [IDNA200X-issues]. 128 1.1. Discussion Forum 130 [[anchor3: RFC Editor: please remove this section.]] 132 This work is being discussed on the mailing list 133 idna-update@alvestrand.no 135 2. Terminology 137 General terminology applicable to IDNA, but with meanings familiar to 138 those who have worked with Unicode or other character set standards 139 and the DNS, appears in [IDNA200X-issues]. Terminology that is an 140 integral, normative, part of the IDNA definition, including the 141 definitions of "ACE", appears in that document as well. Familiarity 142 with the terminology materials in that document is assumed for 143 reading this one. 145 [[anchor4: May want to copy some definitions from "issues" back to 146 here to avoid or reduce normative dependencies. But, of course, that 147 would risk the two sets of definitions becoming inconsistent. 148 Tradeoff...]] 150 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 151 and "MAY" in this document are to be interpreted as described in BCP 152 14, RFC 2119 [RFC2119]. 154 3. Requirements and Applicability 156 3.1. Requirements 158 IDNA conformance means adherence to the following requirements: 160 1. Whenever a domain name is put into an IDN-unaware domain name 161 slot (see Section 2 and [IDNA200X-issues]), it MUST contain only 162 ASCII characters (i.e., must be either an A-label, an LDH-label, 163 or a label associated with a DNS application that is not subject 164 to IDNA. 166 2. Comparing two labels MUST be done on the A-label form, using an 167 ASCII case-insensitive comparison, as with all comparisons of DNS 168 labels. 170 3.2. Applicability 172 IDNA is applicable to all domain names in all domain name slots 173 except where it is explicitly excluded. It is not applicable to 174 domain name slots which do not use the LDH syntax rules. 176 This implies that IDNA is applicable to many protocols that predate 177 IDNA. Note that IDNs occupying domain name slots in those protocols 178 MUST be in A-label form. 180 3.2.1. DNS Resource Records 182 IDNA applies only to domain names in the NAME and RDATA fields of DNS 183 resource records whose CLASS is IN. 185 There are currently no other exclusions on the applicability of IDNA 186 to DNS resource records; it depends entirely on the CLASS, and not on 187 the TYPE. This will remain true, even as new types are defined, 188 unless there is a compelling reason for a new type that requires 189 type-specific rules. It is worth noting that the special naming 190 conventions applicable to SRV records are precisely such type- 191 specific rules. 193 3.2.2. Non-domain-name Data Types Stored in the DNS 195 Although IDNA enables the representation of non-ASCII characters in 196 domain names, that does not imply that IDNA enables the 197 representation of non-ASCII characters in other data types that are 198 stored in domain names, specifically in the RDATA field for types 199 that have structured RDATA format. For example, an email address 200 local part is stored in a domain name in the RNAME field as part of 201 the RDATA of an SOA record (hostmaster@example.com would be 202 represented as hostmaster.example.com). IDNA specifically does not 203 update the existing email standards, which allow only ASCII 204 characters in local parts. Other work is under development to define 205 internationalization for email addresses [RFC4952], but changes to 206 that part of the SOA RDATA would require action in other standards, 207 which could also specify IDNA interpretation of labels that follow 208 the local part such as by permitting them to be A-labels. 210 4. Registration Protocol 212 This section defines the procedure for registering an IDN. The 213 procedure is implementation independent; any sequence of steps that 214 produces exactly the same result for all labels is considered a valid 215 implementation. 217 4.1. Proposed label 219 The registrant submits a request for an IDN. The user typically 220 produces the request string by the keyboard entry of a character 221 sequence. 223 4.2. Conversion to Unicode 225 Some system routine, or a localized front-end to the IDNA process, 226 ensures that the proposed label is a Unicode string. As a local 227 implementation choice, the implementation may choose to map some 228 forbidden characters to permitted characters (for instance mapping 229 uppercase characters to lowercase ones), displaying the result to the 230 user, and allowing processing to continue. 232 4.3. Permitted Character Identification 234 The Unicode string is examined to prohibit characters that IDNA does 235 not permit in input. Those characters are identified in the "NEVER" 236 list that is discussed in [IDNA200X-issues] which characters 237 specified in [IDNA200X-Tables]. Characters that are specified as 238 "NEVER" in those documents, and characters or sequences that are 239 unassigned in Unicode, MUST NOT be part of labels being processed for 240 registration in the DNS. 242 4.4. Additional Character String Checking and Processing 244 All characters produced as output of the preceding step are then 245 verified for permissibility by IDNA. Conceptually, these tests are, 246 in order: 248 1. Each code point is verified to be assigned in the version of 249 Unicode in use (See [IDNA200X-issues]). If verification fails, 250 the proposed label containing the code point is not a U-label and 251 MUST NOT be processed further. 253 2. Each code point is checked for its presence as "ALWAYS" 254 (permitted) in the table of included characters for registration 255 or, if appropriate for the specific registry, as "MAYBE" 256 permitted (see [IDNA200X-Tables]). 258 3. Each code point is checked for its presence as "CONTEXTUAL RULE 259 REQUIRED" in the table of included characters for registration. 260 If that indication appears, the table of contextual rules is 261 checked for a rule for that character. If no rule is found, the 262 proposed label is rejected. If one is found, it is applied 263 (typically as a test on the entire label or adjacent characters). 264 If the application of the rule does not conclude that the 265 character is valid in context, the proposed label must be 266 rejected. (See the IANA Considerations: IDNA Context Registry 267 section of [IDNA200X-issues]). 269 4. Additional special tests for right-to-left strings are applied 270 (See [IDNA200X-BIDI]. 272 Strings that have been produced by the steps above, and whose 273 contents pass the above tests, are U-labels. 275 To summarize, tests are made here for invalid characters, invalid 276 combinations of characters, and for labels that are invalid even if 277 the individual characters they contain are all valid. For example, 278 labels containing invisible ("zero-width") characters may be 279 permitted in context with characters whose presentation forms are 280 significantly changed by the presence or absence of the zero-width 281 characters, while other labels in which zero-width characters appear 282 may be rejected. Additional transformations that do not occur as the 283 result of the steps above may be specified at this point by IDNA200x. 284 As the list of characters permitted to be registered expands, new 285 rules, similar to those suggested for zero-width characters, may 286 accompany them. 288 4.5. Registry Restrictions 290 Registries at all levels of the DNS, not just the top level, are 291 expected to establish policies about the labels that may be 292 registered, and for the processes associated with that action. As 293 discussed in [IDNA200X-issues]), such restrictions have always 294 existed in the DNS. 296 The string produced by the above steps is checked and processed as 297 appropriate to local registry restrictions. Application of those 298 registry restrictions may result in the rejection of some labels or 299 the application of special restrictions to others. 301 4.6. Punycode Conversion 303 The resulting U-label is converted to an A-label (i.e., the encoding 304 of that label according to the Punycode algorithm [RFC3492] with the 305 prefix included, i.e., the "xn--..." form). 307 4.7. Insertion in the Zone 309 The A-label is registered in the DNS by insertion into a zone. 311 5. Domain Name Resolution (Lookup) Protocol 313 Resolution is conceptually different from registration and different 314 tests are applied on the client. The resolution-side tests are more 315 permissive and rely heavily on the assumption that names that are 316 present in the DNS are valid. Among other things, this distinction 317 facilitates expansion of the permitted character lists to include new 318 scripts and accommodate new versions of Unicode. 320 5.1. User input 322 The user supplies a string in the local character set, typically by 323 typing it or clicking on, or copying and pasting, a resource 324 identifier, e.g., a URI [RFC3986] or IRI [RFC3987] from which the 325 domain name is extracted. Processing in this step and the next two 326 are local matters, to be accomplished prior to actual invocation of 327 IDNAbis, but at least this one and the next one must be accomplished 328 in some way. 330 5.2. Conversion to Unicode 332 The local character set, character coding conventions, and, as 333 necessary, display and presentation conventions, are converted to 334 Unicode (without surrogates), paralleling the process above 335 (Section 4.2). 337 5.3. User Interface Character Changes 339 The Unicode string MAY then be processed, in a way specific to the 340 local environment, to make the result of the IDNA processing match 341 user expectations. For instance, at this step, it would be 342 reasonable to case-fold all upper case characters to lower case, if 343 this makes sense in the user's environment. 345 Other examples of processing for localization that might be applied, 346 if appropriate, at this point (but even further outside the scope of 347 this specification) include interpreting the KANA MIDDLE DOT to 348 separate domain name components from each other, standardizing 349 different "width" forms of the same character, or giving special 350 treatment to characters whose presentation forms are dependent only 351 on placement in the label. 353 Because these transformations are local, it is important that domain 354 names that might be passed between systems (e.g., in IRIs) be 355 U-labels or A-labels and not forms that might be accepted locally as 356 a consequence of this step. This step is not standardized, and not 357 specified further here. 359 5.4. Pre-Normalization Validation and Character List Testing 361 In parallel with the registration procedure, the Unicode string is 362 checked to verify that all characters that appear in it are valid for 363 IDNA resolution input. As discussed in [IDNA200X-issues], the 364 resolution check is more liberal than that of the registration one. 365 Characters that fall into the "MAYBE" (see [IDNA200X-issues]) 366 categories in the inclusion tables do not lead to label rejection on 367 resolution. Putative labels containing code points with any of the 368 following characteristics MUST BE rejected prior to DNS lookup: 370 o Code points that are unassigned in the version of Unicode being 371 used by the application, i.e., in the "Unassigned" Unicode 372 category. 374 o Prohibited code points, i.e., those that are assigned to the 375 "NEVER" category in the permitted character table. 377 o Code points that are shown in the permitted character table as 378 requiring a contextual rule ("CONTEXTUAL RULE REQUIRED"), but for 379 which no such rule appears in the table of rules. 381 For all other strings, the resolver MUST rely on the presence or 382 absence of labels in the DNS to determine the validity of those 383 labels and the validity of the characters they contain. If they are 384 registered, they are presumed to be valid; if they are not, their 385 possible validity is not relevant. 387 5.5. Normalization 389 The validated Unicode string is normalized (using NFC); no case- 390 mapping is performed. 392 5.6. Post-Normalization Processing 394 Any necessary processing or filtering is applied to the normalized 395 output string produced by the above. In the cases that can be 396 anticipated, this step will be null. It is included in the model in 397 case, e.g., full-label checks are needed on lookup. 399 5.7. Punycode Conversion 401 The validated string, a U-label, is converted to an A-label. 403 5.8. DNS Name Resolution 405 The A-label is looked up in the DNS, using normal DNS procedures. 407 6. Name server Considerations 409 6.1. Processing Non-ASCII Strings 411 Existing DNS servers do not know the IDNA rules for handling non- 412 ASCII forms of IDNs, and therefore need to be shielded from them. 413 All existing channels through which names can enter a DNS server 414 database (for example, master files (as described in RFC 1034) and 415 DNS update messages [RFC2136]) are IDN-unaware because they predate 416 IDNA. Other sections of this document provide the needed shielding 417 by ensuring that internationalized domain names entering DNS server 418 databases through such channels have already been converted to their 419 equivalent ASCII A-label forms. 421 Because of the design of the algorithms in Section 4 and Section 5 (a 422 domain name containing only ASCII codepoints can not be converted to 423 an A-label), there can not be more than one label for each domain 424 name. 426 RFC2821 explicitly allows domain labels to contain octets beyond the 427 ASCII range (0..7F), and this document does not change that. Note, 428 however, that there is no defined interpretation of octets 80..FF as 429 characters. If labels containing these octets are returned to 430 applications, unpredictable behavior could result. The A-label form, 431 which cannot contain those characters, is the only standard 432 representation for internationalized labels in the current DNS 433 protocol. 435 6.2. DNSSEC Authentication of IDN Domain Names 437 DNS Security [RFC2535] is a method for supplying cryptographic 438 verification information along with DNS messages. Public Key 439 Cryptography is used in conjunction with digital signatures to 440 provide a means for a requester of domain information to authenticate 441 the source of the data. This ensures that it can be traced back to a 442 trusted source, either directly, or via a chain of trust linking the 443 source of the information to the top of the DNS hierarchy. 445 IDNA specifies that all internationalized domain names served by DNS 446 servers that cannot be represented directly in ASCII must use the 447 A-label form. Conversion to A-labels must be performed prior to a 448 zone being signed by the private key for that zone. Because of this 449 ordering, it is important to recognize that DNSSEC authenticates a 450 domain name containing A-labels or conventional LDH-labels, not 451 U-labels. In the presence of DNSSEC, no form of a zone file or query 452 response that contains a U-label may be signed or validated against. 454 One consequence of this for sites deploying IDNA in the presence of 455 DNSSEC is that any special purpose proxies or forwarders used to 456 transform user input into IDNs must be earlier in the resolution flow 457 than DNSSEC authenticating nameservers for DNSSEC to work. 459 6.3. Root Server Considerations 461 IDNs are likely to be somewhat longer than current domain names, so 462 the bandwidth needed by the root servers is likely to go up by a 463 small amount. Also, queries and responses for IDNs will probably be 464 somewhat longer than typical queries today, so more queries and 465 responses may be forced to go to TCP instead of UDP. 467 7. Security Considerations 469 The general security principles and issues for IDNA appear in 470 [IDNA200X-issues]. The comments below are specific to this protocol, 471 but should be read in the context of that material and the 472 specifications, identified there, on which this one depends. 474 This memo describes an algorithm which encodes characters that are 475 not valid according to the base DNS specifications (STD13 [RFC1034] 476 [RFC1035] and Host Requirements [RFC1123]) into octet values that are 477 valid. No security issues such as string length increases or new 478 allowed values are introduced by the encoding process or the use of 479 these encoded values, apart from those introduced by the ACE encoding 480 itself. 482 Domain names (or portions of them) are sometimes compared against a 483 set of privileged or anti-privileged domains. In such situations it 484 is especially important that the comparisons be done properly, as 485 specified in requirement 2 of Section 3.1. For labels already in 486 ASCII form, the proper comparison reduces to the same case- 487 insensitive ASCII comparison that has always been used for ASCII 488 labels. 490 The introduction of IDNA means that any existing labels that start 491 with the ACE prefix would be construed as U-labels, at least until 492 they failed one of the relevant tests, whether or not that was the 493 intent of the zone administrator or registrant. There is no evidence 494 that this has caused any practical problems since RFC 3490 was 495 adopted, but the risk still exists in principle. 497 8. IANA Considerations 499 IANA actions for this version of IDNA are specified in 500 [IDNA200X-issues]. 502 9. Contributors 504 While the listed editor held the pen, this document represents the 505 joint work and conclusions of an ad hoc design team consisting of the 506 editor and, in alphabetic order, Harald Alvestrand, Tina Dam, Patrik 507 Faltstrom, and Cary Karp. This document draws significantly on the 508 original version of IDNA [RFC3490] both conceptually and for specific 509 text. This second-generation version would not have been possible 510 without the work that went into that first version and its authors, 511 Patrik Faltstrom, Paul Hoffman, and Adam Costello. While Faltstrom 512 was actively involved in the creation of this version, Hoffman and 513 Costello were not and should not be held responsible for any errors 514 or omissions. 516 10. Acknowledgements 518 This revision to IDNA would have been impossible without the 519 accumulated experience since RFC 3490 was published and resulting 520 comments and complaints of many people in the IETF, ICANN, and other 521 communities, too many people to list here. Nor would it have been 522 possible without RFC 3490 itself and the efforts of the Working Group 523 that defined it. Those people whose contributions are acknowledged 524 in RFC 3490, [RFC4690], and [IDNA200X-issues] were particularly 525 important. 527 11. References 529 11.1. Normative References 531 [IDNA200X-BIDI] 532 Alvestrand, H. and C. Karp, "An IDNA problem in right-to- 533 left scripts", July 2007, . 536 [IDNA200X-issues] 537 Klensin, J., Ed., "Internationalizing Domain Names for 538 Applications (IDNA): Issues and Rationale", November 2007. 540 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 541 STD 13, RFC 1034, November 1987. 543 [RFC1035] Mockapetris, P., "Domain names - implementation and 544 specification", STD 13, RFC 1035, November 1987. 546 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 547 and Support", STD 3, RFC 1123, October 1989. 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, March 1997. 552 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 553 for Internationalized Domain Names in Applications 554 (IDNA)", RFC 3492, March 2003. 556 11.2. Informative References 558 [ASCII] American National Standards Institute (formerly United 559 States of America Standards Institute), "USA Code for 560 Information Interchange", ANSI X3.4-1968, 1968. 562 ANSI X3.4-1968 has been replaced by newer versions with 563 slight modifications, but the 1968 version remains 564 definitive for the Internet. 566 [IDNA200X-Tables] 567 Faltstrom, P., "The Unicode Codepoints and IDN", 568 November 2007, . 571 A version of this document, is available in HTML format at 572 http://stupid.domain.name/idnabis/ 573 draft-faltstrom-idnabis-tables-03.txt 575 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 576 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 577 RFC 2136, April 1997. 579 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 580 Specification", RFC 2181, July 1997. 582 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 583 RFC 2535, March 1999. 585 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 586 "Internationalizing Domain Names in Applications (IDNA)", 587 RFC 3490, March 2003. 589 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 590 Resource Identifier (URI): Generic Syntax", STD 66, 591 RFC 3986, January 2005. 593 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 594 Identifiers (IRIs)", RFC 3987, January 2005. 596 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 597 Recommendations for Internationalized Domain Names 598 (IDNs)", RFC 4690, September 2006. 600 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 601 Internationalized Email", RFC 4952, July 2007. 603 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 604 5.0", 2007. 606 Boston, MA, USA: Addison-Wesley. ISBN 0-321-48091-0 608 Author's Address 610 John C Klensin 611 1770 Massachusetts Ave, Ste 322 612 Cambridge, MA 02140 613 USA 615 Phone: +1 617 245 1457 616 Fax: 617 Email: john+ietf@jck.com 618 URI: 620 Full Copyright Statement 622 Copyright (C) The IETF Trust (2007). 624 This document is subject to the rights, licenses and restrictions 625 contained in BCP 78, and except as set forth therein, the authors 626 retain all their rights. 628 This document and the information contained herein are provided on an 629 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 630 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 631 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 632 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 633 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 634 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 636 Intellectual Property 638 The IETF takes no position regarding the validity or scope of any 639 Intellectual Property Rights or other rights that might be claimed to 640 pertain to the implementation or use of the technology described in 641 this document or the extent to which any license under such rights 642 might or might not be available; nor does it represent that it has 643 made any independent effort to identify any such rights. Information 644 on the procedures with respect to rights in RFC documents can be 645 found in BCP 78 and BCP 79. 647 Copies of IPR disclosures made to the IETF Secretariat and any 648 assurances of licenses to be made available, or the result of an 649 attempt made to obtain a general license or permission for the use of 650 such proprietary rights by implementers or users of this 651 specification can be obtained from the IETF on-line IPR repository at 652 http://www.ietf.org/ipr. 654 The IETF invites any interested party to bring to its attention any 655 copyrights, patents or patent applications, or other proprietary 656 rights that may cover technology that may be required to implement 657 this standard. Please address the information to the IETF at 658 ietf-ipr@ietf.org. 660 Acknowledgment 662 Funding for the RFC Editor function is provided by the IETF 663 Administrative Support Activity (IASA).