idnits 2.17.1 draft-levine-tld-variant-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 8, 2012) is 4179 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Levine 3 Internet-Draft Taughannock Networks 4 Intended status: Informational P. Hoffman 5 Expires: May 12, 2013 VPN Consortium 6 November 8, 2012 8 Variants in Second-Level Names Registered in Top Level Domains 9 draft-levine-tld-variant-04 11 Abstract 13 Internationalized Domain Names for Applications (IDNA) provides a 14 method to map a subset of names written in Unicode into the DNS. 15 Because of Unicode decisions, appearance, language and writing system 16 conventions, and historical reasons, it often has been asserted that 17 there is more than one way to write what competent readers and 18 writers think of as the same host name; the different ways of writing 19 are often called "variants". This document surveys the approaches 20 that top level domains have taken to the registration and 21 provisioning of domain names that have variants. This document is 22 not a product of the IETF, does not propose any method to make 23 variants work "correctly", and is not an introduction to 24 internationalization or IDNA. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 12, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Base Documents . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Domain Practices of gTLDs . . . . . . . . . . . . . . . . . . 6 64 4.1. AERO . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2. ASIA . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.3. BIZ . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.4. CAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.5. COM . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.6. COOP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.7. INFO . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.8. JOBS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.9. MOBI . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.10. MUSEUM . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.11. NAME . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.12. NET . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.13. ORG . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.14. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4.15. PRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 4.16. TEL . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.17. TRAVEL . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 4.18. XXX . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 5. Domain Practices of ccTLDs . . . . . . . . . . . . . . . . . . 10 83 5.1. BG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 5.2. BR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 5.3. CL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 5.4. CN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 5.5. ES . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 5.6. EU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 5.7. GR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 5.8. IL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 5.9. IR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 5.10. JP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 93 5.11. KR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 5.12. MY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 5.13. NZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 5.14. PL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 97 5.15. RS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 98 5.16. RU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 99 5.17. SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 100 5.18. SE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 101 5.19. TW . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 102 5.20. UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 103 5.21. VE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 104 5.22. XN--90A3AC . . . . . . . . . . . . . . . . . . . . . . . . 13 105 5.23. XN--MGBERP4A5D4AR . . . . . . . . . . . . . . . . . . . . 13 106 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 107 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 108 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 109 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 112 1. Introduction 114 Internationalized Domain Names for Applications (IDNA) [RFC5890] 115 allows host names in the DNS [RFC1035] to contain characters from the 116 Unicode repertoire. Some Unicode characters are considered to be 117 "variants" of one another. Because of the 20th century reform of 118 Chinese writing, there is often more than one representation of what 119 Chinese speakers think of as the same character. Some languages 120 written in Latin characters with accents and diacritical marks, known 121 as decorated characters, allow the decorations to be omitted in some 122 situations; for example, French sometimes omits accents on capital 123 letters, depending on country and culture. Due to the difficulty of 124 representing decorated characters in ASCII systems, many users have 125 informally used undecorated characters in DNS host names, even when 126 they are not linguistically equivalent to the decorated versions. 128 There is no single agreed-on definition of "variant". In IDN Variant 129 TLDs [VARIANTTLDS], ICANN says that variants "occur when a single 130 conceptual character can be identified with two or more different 131 Unicode Code Points with graphic representations that may be visually 132 similar". In ICANN's IDN Variant Issues Project report [VIPREPORT], 133 it says in part "There is today no fully accepted definition for what 134 may constitute a variant relationship between top-level labels". RFC 135 3743 [RFC3743] (an Informational RFC, not the product of the IETF), 136 say that the idea of variants is "wherein one conceptual character 137 can be identified with several different Code Points in character 138 sets for computer use". 140 The proper handing of variant names has been a topic of extensive 141 debate and research, with little consensus reached on how to handle 142 them, or even what characters are variants of each other. Many 143 people would like variant names to behave "the same", for a diverse 144 range of meanings of "same." In some cases it is a textual 145 similarity, such as variants having corresponding DNS records, in 146 some it is functional similarity, such as variant names resolving to 147 the same web server, while in others it is user experience 148 similarity, such as names resolving to web sites which while not 149 identical are perceived by human users as equivalent. 151 This document provides a snapshot of variant handling in the top 152 level domains contracted by ICANN, so-called gTLDs (generic TLDs) and 153 sTLDs (sponsored TLDs), as of late 2012. We chose those domains 154 because ICANN requires each TLD to describe its IDN and variant 155 practices, and the TLD zone files are available for inspection, to 156 verify what actually goes into the zones. This document also 157 contains a small sampling of so-called ccTLDs (country code TLDs, the 158 TLDs that consist of two ASCII letters) for which we could find 159 information. 161 Since "variant" can mean vastly different things to different people, 162 there is also no agreement about when when two zones are supposed to 163 "behave the same". Also, the gTLDs and sTLDs might have different 164 views of what variants are and are not required to report to ICANN 165 about their policies. 167 2. Terminology 169 We use some terminology that has become fairly well agreed when 170 discussing variant names. 172 Bundle: The IDN practices documents (see below) can identify sets of 173 code points that are considered variants of each other using 174 Language Variant Tables, defined in [RFC3743]. A set of names in 175 which the characters in each position are variants is known as a 176 bundle, or more technically as an "IDL Package". The variant 177 rules vary among languages, and for the same language can vary 178 among TLDs. Many languages do not define variant characters, and 179 hence do not have bundles. 181 Preferred variant: When a Language Variant Table defines sets of 182 variant characters, one character in each set is sometimes 183 designated as preferred. In a bundle, a variant that consists 184 entirely of preferred characters is a preferred variant. 185 Preferred variants are specific to both languages and countries. 186 For example, in some Chinese-speaking countries, the preferred 187 variant is simplified characters, while in others it is 188 traditional characters. 190 Allocated: A name is allocated if if sponsorship of that label in 191 some zone has been granted. This is similar to what many people 192 refer to as "registered". 194 Active: A name is active it appears as an owner name in a zone. 195 Most allocated names are active, but some are not. 197 Blocked: Some names cannot be registered at all. For example, some 198 registries allow one name in a bundle to be registered, and block 199 the rest. 201 Withheld: Some names can only be allocated under certain conditions. 202 For example, some registries permit only the registrant of one 203 name in a bundle to register or activate other names in the same 204 bundle. 206 Parallel NS: Multiple names in a bundle are provisioned in the TLD 207 with identical NS records, so they all are handled by the same 208 name servers. 210 DNAME aliasing: The DNAME [RFC6672] DNS record creates a shadow tree 211 of DNS records, roughly as though there were a CNAME in the shadow 212 tree pointing to each name in the target tree. DNAMEs have been 213 used both as second-level names, to provide resolution for several 214 names in a bundle, and as first-level names, to provide resolution 215 for every name under a TLD. 217 3. Base Documents 219 ICANN has published a variety of documents on variant management. 220 The most important are the "Guidelines for the Implementation of 221 Internationalized Domain Names" issued in Version 1.0 [G1] and 222 Version 3.0 [G3]. 224 ICANN says that TLDs are supposed to register an IDN practices 225 document with IANA for each language and/or script in which the TLD 226 accepts IDN registrations, to be entered in the IANA Repository of 227 IDN Practices [IANAIDN]. The practices document lists the Unicode 228 characters allowed in names in the language or script, which 229 characters are considered equivalent, and which of an equivalent 230 group is preferred. Some TLDs have been more diligent than others at 231 keeping the registry up to date. Also, some TLDs have tables for a 232 few languages and scripts, while others (notably .COM, .NET, and 233 .NAME) have a large set of tables, including some for languages and 234 scripts that are no longer spoken or used, such as Runic and Ogham. 235 The authors also note that many of the tables in the IANA registry 236 are clearly out of date, containing URLs of policy pages that no 237 longer exist and contact information for people who have left the 238 registry. 240 Some of the ICANN agreements with each TLD [ICANNAGREE] describe the 241 TLD's IDN practices, but most don't. 243 4. Domain Practices of gTLDs 245 This list covers the most of the current set of gTLDs. In most 246 cases, the authors have also checked the zone files for the gTLD to 247 verify or augment the policy description. 249 4.1. AERO 251 The .AERO TLD has no IDNs, and no rules or practices for them. 253 4.2. ASIA 255 The .ASIA domain accepts registrations in many Asian languages. They 256 have IANA tables for Japanese, Korean, and Chinese. The IANA tables 257 refer to their CJK IDN policies [ASIACJK], which say that applied-for 258 and preferred IDN variants are "active and included in the zone." No 259 IDN publication mechanism is described in the documentation, but 260 since the zone file contains no DNAMEs, they must be using parallel 261 NS for variants. 263 4.3. BIZ 265 ICANN gave the registry (Neustar) non-specific permission to register 266 IDNs in a letter in 2004 [TWOMEY04A]. The IDN rules were apparently 267 discussed with ICANN, but not defined; see Appendix 9 of the registry 268 agreement [ICANNBIZ9]. 270 They have about a dozen IANA tables. No IDN publication mechanism is 271 described, but from inspection it appears that variants are blocked. 273 4.4. CAT 275 The IDN rules are described in Appendix S Part VII.2 [ICANNCATS] of 276 the ICANN agreement. "Registry will take a very cautious approach in 277 its IDN offerings. IDNs will be bundled with the equivalent ASCII 278 domains." The only language is Catalan. No IDN publication 279 mechanism is described. 281 Appendix S includes "The list of non-ASCII-characters for Catalan 282 language and their ASCII equivalent for the purposes of the defined 283 service" which implicitly describes bundles. The bundles consist of 284 names with accented and unaccented vowels, U+00E7 ("c with cedilla") 285 and a plain c, and the Catalan "ela geminada" written as two l's 286 separated by a U+00B7 ("middle dot") and the three characters "l-l". 288 When a registrant registers an IDN, the registry also includes the 289 ASCII version. From inspection of the zone file, the ASCII version 290 is provisioned with NS, and the IDN is a DNAME alias of the ASCII 291 version. 293 4.5. COM 295 ICANN and Verisign have extensive correspondence about IDNs and 296 variants, including letters to ICANN from Ben Turner [TURNER03] and 297 Ed Lewis [LEWIS03]. 299 The IANA registry has tables for several dozen languages, including 300 archaic languages such as hieroglyphics and Aramaic. Verisign 301 publishes documents describing Scripts and Languages [VRSNLANG], 302 Character Variants [VRSNCHAR], Registration Rules [VRSNRULES], and 303 additional registration logic [VRSNADDL]. 305 In Chinese, variants are blocked (see [VRSNADDL]). In other 306 languages there is no bundling or blocking. 308 4.6. COOP 310 The .COOP TLD has no IDNs, and no rules or practices for them. 312 4.7. INFO 314 The IANA registry has tables for Danish, Hungarian, Lithuanian, 315 Latvian, and Swedish from 2005. The domain also has names in Greek, 316 Russian, Arabic, and other languages but no IANA tables. 318 The registry agreement Appendix 9 [ICANNINFO9] refers to a 2003 319 letter from Paul Twomey [TWOMEY03] that refers to blocking variants. 321 4.8. JOBS 323 The .JOBS TLD has no IDNs, and no rules or practices for them. 325 4.9. MOBI 327 The zone file has about 22,000 IDNs. The domain has no tables at 328 IANA. The registry agreement Appendix S [ICANNMOBIS] says that IDNs 329 are provisioned according to [G1]. 331 4.10. MUSEUM 333 The zone file has many IDNs, but spot checks find that many are lame 334 or dead. A 2004 letter from Paul Twomey [TWOMEY04] refers to [G1]. 336 The registry has a detailed policy page [MUSEUMPOLICY]. IDNs are 337 accepted in Latin and Hebrew scripts, with plans for Arabic, Chinese, 338 Japanese, Korean, Cyrillic, and Greek. They do no bundling or 339 blocking, but names that may be confusable due to visual similarity 340 are not allowed, apparently determined by manual inspection, which is 341 practical due to the very small size of the domain. 343 4.11. NAME 345 The NAME TLD is managed the same as .COM. 347 4.12. NET 349 The NET TLD is managed the same as .COM. 351 4.13. ORG 353 A 2003 letter from Paul Twomey [TWOMEY03A] refers to [G1]. The 354 registry has a list of IDN languages [PIRIDN], all written in Latin 355 script. The practices for some but not all are registered with IANA, 356 Since none of the languages do bundling, there is presumably no 357 blocking. 359 4.14. POST 361 The .POST TLD appears to have no registrations at all yet. 363 4.15. PRO 365 The .PRO TLD has no IDNs, and no rules or practices for them. 367 4.16. TEL 369 The zone has many IDNs. It is probably operating according to a 2004 370 letter from Paul Twomey [TWOMEY04A] to Neustar which did not mention 371 specific TLDs. Its policy page [TELPOLICY] has links to IDN 372 practices for 17 languages, all but one of which are registered with 373 IANA. None of the Latin scripts do bundling or blocking. The 374 Japanese practices say that variants are blocked. The Chinese 375 practices document says: 377 Therefore, in addition to the blocking mechanism, bundling is also 378 implemented for the Chinese language IDNs. When registering a 379 Chinese language IDN (primary domain name) up to two additional 380 variant domain names will be automatically registered. The first 381 variant will consist entirely of simplified Chinese characters 382 that correspond to those comprising the primary domain name. The 383 second variant will consist exclusively of traditional Chinese 384 characters that correspond to those comprising the primary domain 385 name. 387 The primary domain name together with the requested variants 388 constitutes a bundle on which all operations are atomic. For 389 example, if the registrant adds a name server to the primary 390 domain name, all names in the bundle will be associated with that 391 new name server. 393 The zone has no DNAME records, so the second paragraph strongly 394 suggests parallel NS. 396 The .TEL TLD, intended as an online directory, does not allow 397 registrants to enter arbitrary RR's in the zone. Nearly all names 398 have NS records pointing to Telnic's own name servers. The A records 399 all point to Telnic's own web server that shows directory 400 information. NAPTR records provide the telephone number of 401 registrants for whom they have one. Users can only directly 402 provision MX records. Except that there are 16 domains, none of 403 which are IDNs, that point to random other name servers and mostly 404 appear to be parked. 406 4.17. TRAVEL 408 The .TRAVEL TLD has no IDNs, and no rules or practices for them. 410 4.18. XXX 412 The .XXX TLD has no IDNs, and no rules or practices for them. 414 5. Domain Practices of ccTLDs 416 Some ccTLDs publish their IDN policies. This section is a non- 417 exhaustive sampling of some of those policies. Note that few ccTLDs 418 make their zone files available, so the authors could not validate 419 the policies by looking in the zone files. 421 5.1. BG 423 The .BG TLD (for Bugaria) publishes a policy page [BGPOLICY]. It has 424 published an IDN table for the Bulgarian and Russian languages in 425 [IANAIDN]. The policy does not mention variants. 427 5.2. BR 429 The .BR TLD (for Brazil) publishes a policy page [BRPOLICY]. It has 430 published an IDN table for the Portuguese language in [IANAIDN]. The 431 policy says that it will block registration of variants. 433 5.3. CL 435 The .CL TLD (for Chile) publishes a policy page [CLPOLICY]. It has 436 published an IDN table for the Latin script in [IANAIDN]. The policy 437 says that variants are not considered for registration. 439 5.4. CN 441 The .CN TLD (for China) publishes its policy as [RFC4713]. It has 442 published an IDN table for the Chinese laguage in [IANAIDN]. The 443 policy says that variants are "added into the zone file", presumably 444 as NS records. 446 5.5. ES 448 The .ES TLD (for Spain) publishes an IDN Area page [ESIDN]. It 449 allows ten accented vowels, U+00E7 ("c with cedilla"), U+00F1 ("n 450 with tilde"), and the Catalan "ela geminada" written as two l's 451 separated by a U+00B7 ("middle dot"). There are no published IDN 452 tables, and there appears to be no variant policy. 454 5.6. EU 456 The .EU TLD (for Europe) publishes a policy page [EUPOLICY]. It has 457 published IDN tables for three scripts in [IANAIDN]. There appears 458 to be no variant policy. 460 5.7. GR 462 The .GR TLD (for Greece) publishes a policy page [GRPOLICY]. The 463 policy says that all variants of name uder .GR are assigned to the 464 domain owner, with the zone pointing the NS records of all the 465 variants to the name server of the "main form" of the registered 466 name. It does not publish IDN tables in [IANAIDN]. 468 5.8. IL 470 The .IL TLD (for Israel) publishes a policy page [ILPOLICY]. It has 471 published an IDN table for the Hebrew language in [IANAIDN]. There 472 appears to be no variant policy. 474 5.9. IR 476 The .IR TLD (for Iran) publishes a policy page [IRPOLICY]. It has 477 published an IDN table for the Persian language in [IANAIDN]. The 478 IDN table says that it will block registration of variants. However, 479 the policy document says that no IDNs can be registered in .IR. 481 5.10. JP 483 The .JP TLD (for Japan) publishes a policy page [JPPOLICY]. It has 484 published an IDN table for the Japanese language in [IANAIDN]. Each 485 code point in that table defines no variants, which means there are 486 no variants in registration or resolution.. 488 5.11. KR 490 The .KR TLD (for Korea) appears to only publish its policy as an IDN 491 table for the Korean language in [IANAIDN]. The policy in that table 492 does not discuss variants. 494 5.12. MY 496 The .MY TLD (for Malaysia) appears to only publish its policy as an 497 IDN table for the Jawi language in [IANAIDN]; however, IANA lists 498 that as a table for the "Malay microlanguage". The policy in that 499 table does not discuss variants. 501 5.13. NZ 503 The .NZ TLD (for New Zealand) publishes a policy page [NZPOLICY]. It 504 has published IDN tables for the Latin script in [IANAIDN]. The 505 policy does not discuss variants. 507 5.14. PL 509 The .PL TLD (for Poland) publishes a policy page [PLPOLICY]. It has 510 published IDN tables for numerous European languages in [IANAIDN]. 511 The policy says that it will block registration of "look-alike" 512 variants. 514 5.15. RS 516 The .RS TLD (for Serbia) publishes a policy page [RSPOLICY]. It has 517 published IDN tables for the Serbian and Russian languages, and the 518 Latin script, in [IANAIDN]. The policy does not discuss variants. 520 5.16. RU 522 The .RU TLD (for Russia) appears to only publish its policy as an IDN 523 table for the Russian language in [IANAIDN]. The policy in that 524 table does not discuss variants. 526 5.17. SA 528 The .SA TLD (for Saudi Arabia) publishes a policy page [SAPOLICY]. 529 It has published an IDN table for the Arabic language in [IANAIDN]. 530 The policy permits the registration of variants, but it is not clear 531 whether others can register names with variants if the owner of a 532 name has not registered them. 534 5.18. SE 536 The .SE TLD (for Sweden) publishes a policy page [SEPOLICY]. It has 537 published IDN tables for the Swedish and Yiddish languages, and the 538 Latin script, in [IANAIDN]. The policy does not discuss variants. 540 5.19. TW 542 The .TW TLD (for Taiwan) appears to only publish its policy as an IDN 543 table for the Chinese language in [IANAIDN]. The policy in that 544 table does not discuss variants. 546 5.20. UA 548 The .UA TLD (for Ukraine) publishes a policy page [UAPOLICY]. It has 549 published an IDN table for the Cyrillic script in [IANAIDN]. The 550 policy does not discuss variants. 552 5.21. VE 554 The .VE TLD (for Venezuela) appears to only publish its policy as an 555 IDN table for the Spanish language in [IANAIDN]. The policy in that 556 table does not discuss variants. 558 5.22. XN--90A3AC 560 The .XN--90A3AC TLD (for Serbia) (U+0441 U+0440 U+0431) publishes a 561 policy page [RSIDNPOLICY]. It has published IDN tables for the 562 Cyrillic script in [IANAIDN]. The policy does not discuss variants. 564 5.23. XN--MGBERP4A5D4AR 566 The .XN--MGBERP4A5D4AR TLD (for Saudi Arabia) (U+0627 U+0644 U+0633 567 U+0639 U+0648 U+062F U+064A U+0629) appears to only publish its 568 policy as an IDN table for the Arabic script in [IANAIDN]. The 569 policy permits the registration of variants, but it is not clear 570 whether others can register names with variants if the owner of a 571 name has not registered them. 573 6. Acknowledgements 575 Many people contributed to this document, particularly Marc Blanchet, 576 Jordi Iparraguirre, Nacho Amadoz, Dennis Tan, Andrew Sullivan [[ and 577 more to be listed ##### ]]. 579 7. IANA Considerations 581 This document discusses some of what is in an IANA registry, but 582 otherwise has no IANA considerations, so this section should be 583 removed before publication as an RFC. 585 8. Security Considerations 587 There are many potential security considerations for various methods 588 of dealing with IDN variants. However, this document is only a 589 catalog of current variant policies, not of whether or not they are 590 good or bad ideas from a security standpoint. The documents in the 591 Terminology section earlier have a little discusion of security 592 considerations for IDN variants. 594 9. References 596 [ASIACJK] DotAsia Organisation, ".ASIA CJK (Chinese Japanese Korean) 597 IDN Policies", May 2011, . 600 [BGPOLICY] 601 Register.bg, "Terms And Conditions For Domain Name 602 Registration And Support In The .Bg Zone And The Sub- 603 Zones", August 2011, 604 . 606 [BRPOLICY] 607 Registro.br, "Domains in .br", September 2011, 608 . 610 [CLPOLICY] 611 NIC Chile, "Syntax Rules For Domain Names Under .CL", 612 August 2005, . 614 [ESIDN] Red.es, "IDN area", . 617 [EUPOLICY] 618 EURid, ".eu Domain Name Registration Terms and 619 Conditions", December 2009, 620 . 622 [G1] ICANN, "Guidelines for the Implementation of 623 Internationalized Domain Names, Version 1.0", . 627 [G3] ICANN, "Guidelines for the Implementation of 628 Internationalized Domain Names, Version 3.0", . 632 [GRPOLICY] 633 Foundation for Reaserch and Technology - Hellas, 634 "Registration of Domain Names [.gr] In Greek Characters", 635 2007, . 637 [IANAIDN] IANA, "Repository of IDN Practices", 638 . 640 [ICANNAGREE] 641 ICANN, "ICANN Registry agreements", 642 . 644 [ICANNBIZ9] 645 ICANN, "Appendix 9 of ICANN .BIZ Registry agreement", 646 Dec 2006, . 649 [ICANNCATS] 650 ICANN, "Appendix S of ICANN .CAT Registry agreement", 651 Mar 2006, . 654 [ICANNINFO9] 655 ICANN, "Appendix 9 of ICANN .INFO Registry agreement", 656 Dec 2006, . 659 [ICANNMOBIS] 660 ICANN, "Appendix S of ICANN .MOBI Registry agreement", 661 Nov 2005, . 664 [ILPOLICY] 665 Israel Internet Association, "Rules for the Allocation of 666 Domain Names Under the Israel Country Code Top Level 667 Domain ("IL ")", August 2010, 668 . 670 [IRPOLICY] 671 IPM/IRNIC, "Internationalized Domain Names in IR", 672 August 2010, 673 . 675 [JPPOLICY] 676 JPRS, "Technology bylaws regarding generic domain name 677 registration JP", July 2012, 678 . 680 [LEWIS03] Lewis, E., "Letter from Ed Lewis to Paul Twomey", 681 Oct 2003, . 684 [MUSEUMPOLICY] 685 Musedoma, "Internationalized Domain Names (IDN) in .museum 686 - Policies and terms of use", Jan 2009, 687 . 689 [NZPOLICY] 690 .nz Registry Services, "Internationalised Domain Names 691 (IDN)", July 2010, . 693 [PIRIDN] Public Interest Registry, "Expanding Multi-Lingual Options 694 in Domain Name Versatility", Jan 2009, 695 . 697 [PLPOLICY] 698 NASK (PL-TLD), "Registering Internationalized Domain Names 699 under .PL", July 2012, 700 . 702 [RFC1035] Mockapetris, P., "Domain names - implementation and 703 specification", STD 13, RFC 1035, November 1987. 705 [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint 706 Engineering Team (JET) Guidelines for Internationalized 707 Domain Names (IDN) Registration and Administration for 708 Chinese, Japanese, and Korean", RFC 3743, April 2004. 710 [RFC4713] Lee, X., Mao, W., Chen, E., Hsu, N., and J. Klensin, 711 "Registration and Administration Recommendations for 712 Chinese Domain Names", RFC 4713, October 2006. 714 [RFC5890] Klensin, J., "Internationalized Domain Names for 715 Applications (IDNA): Definitions and Document Framework", 716 RFC 5890, August 2010. 718 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 719 DNS", RFC 6672, June 2012. 721 [RSIDNPOLICY] 722 RNIDS, "Internationalized Domain Names(IDN) in xn--90a3ac 723 ccTLD", October 2011, . 726 [RSPOLICY] 727 RNIDS, "General Terms And Conditions For Registration of 728 .rs Domain Names", June 2009, . 731 [SAPOLICY] 732 Saudi Network Information Center, "Permitted Characters 733 and Symbols", December 2010, . 736 [SEPOLICY] 737 .SE (The Internet Infrastructure Foundation), 738 "Registration instructions", 2012, 739 . 741 [TELPOLICY] 742 Telnic, ".TEL Policies", Jan 2007, 743 . 745 [TURNER03] 746 Turner, B., "Letter from Ben Turner to Paul Twomey", 747 Nov 2003, . 750 [TWOMEY03] 751 Twomey, P., "Letter from Paul Twomey to Ram Mohan", 752 Aug 2003, . 755 [TWOMEY03A] 756 Twomey, P., "Letter from Paul Twomey to Edward Viltz", 757 Oct 2003, . 760 [TWOMEY04] 761 Twomey, P., "Letter from Paul Twomey to Cary Karp", 762 Jan 2004, . 765 [TWOMEY04A] 766 Twomey, P., "Letter from Paul Twomey to Richard Tindal", 767 July 2004, . 770 [UAPOLICY] 771 UA ccTLD, "Registration Schedule of IDN-domains", 772 October 2010, . 774 [VARIANTTLDS] 775 ICANN, "IDN Variant TLDs", 776 . 778 [VIPREPORT] 779 ICANN, "A Study of Issues Related to the Management of IDN 780 Variant TLDs (Integrated Issues Report)", . 784 [VRSNADDL] 785 Verisign, "Additional Logic", . 790 [VRSNCHAR] 791 Verisign, "Character Variants", . 796 [VRSNLANG] 797 Verisign, "Scripts and Languages", . 802 [VRSNRULES] 803 Verisign, "Registration Rules", . 808 Authors' Addresses 810 John Levine 811 Taughannock Networks 813 Email: standards@taugh.com 814 Paul Hoffman 815 VPN Consortium 817 Email: paul.hoffman@vpnc.org>