Network Working GroupIndependent Submission J. LevineInternet-DraftRequest for Comments: 6927 Taughannock NetworksIntended status:Category: Informational P. HoffmanExpires: July 25, 2013ISSN: 2070-1721 VPN ConsortiumJanuary 21,May 2013 Variants in Second-Level Names Registered inTop LevelTop-Level Domainsdraft-levine-tld-variant-06Abstract Internationalized Domain Names for Applications (IDNA) provides a method to map a subset of names written in Unicode into the DNS. Because of Unicode decisions, appearance, language and writing system conventions, and historical reasons, it often has been asserted that there is more than one way to write what competent readers and writers think of as the same host name;thethese different ways of writing are often called "variants". (The authors note that there are many conflicting definitions for the term "variant" in the IDNA community.) This document surveys the approaches thattop leveltop-level domains have taken to the registration and provisioning of domain names that have variants. This document is not a product of the IETF, does not propose any method to make variants work "correctly", and is not an introduction to internationalization or IDNA. Status of This Memo ThisInternet-Draftdocument issubmitted in full conformance withnot an Internet Standards Track specification; it is published for informational purposes. This is a contribution to theprovisionsRFC Series, independently ofBCP 78any other RFC stream. The RFC Editor has chosen to publish this document at its discretion andBCP 79. Internet-Draftsmakes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor areworking documentsnot a candidate for any level oftheInternetEngineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The listStandard; see Section 2 of RFC 5741. Information about the currentInternet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximumstatus ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 25, 2013.http://www.rfc-editor.org/info/rfc6927. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3....................................................3 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 4.....................................................4 3. Base Documents. . . . . . . . . . . . . . . . . . . . . . . 5..................................................5 4. Domain Practices of gTLDs. . . . . . . . . . . . . . . . . . 5.......................................6 4.1. AERO. . . . . . . . . . . . . . . . . . . . . . . . . . 5.......................................................6 4.2. ASIA. . . . . . . . . . . . . . . . . . . . . . . . . . 6.......................................................6 4.3. BIZ. . . . . . . . . . . . . . . . . . . . . . . . . . . 6........................................................6 4.4. CAT. . . . . . . . . . . . . . . . . . . . . . . . . . . 6........................................................6 4.5. COM. . . . . . . . . . . . . . . . . . . . . . . . . . . 6........................................................7 4.6. COOP. . . . . . . . . . . . . . . . . . . . . . . . . . 7.......................................................7 4.7. INFO. . . . . . . . . . . . . . . . . . . . . . . . . . 7.......................................................7 4.8. JOBS. . . . . . . . . . . . . . . . . . . . . . . . . . 7.......................................................7 4.9. MOBI. . . . . . . . . . . . . . . . . . . . . . . . . . 7.......................................................7 4.10. MUSEUM. . . . . . . . . . . . . . . . . . . . . . . . . 7....................................................8 4.11. NAME. . . . . . . . . . . . . . . . . . . . . . . . . . 8......................................................8 4.12. NET. . . . . . . . . . . . . . . . . . . . . . . . . . . 8.......................................................8 4.13. ORG. . . . . . . . . . . . . . . . . . . . . . . . . . . 8.......................................................8 4.14. POST. . . . . . . . . . . . . . . . . . . . . . . . . . 8......................................................9 4.15. PRO. . . . . . . . . . . . . . . . . . . . . . . . . . . 8.......................................................9 4.16. TEL. . . . . . . . . . . . . . . . . . . . . . . . . . . 8.......................................................9 4.17. TRAVEL. . . . . . . . . . . . . . . . . . . . . . . . . 9...................................................10 4.18. XXX. . . . . . . . . . . . . . . . . . . . . . . . . . . 9......................................................10 5. Domain Practices of ccTLDs. . . . . . . . . . . . . . . . . 9.....................................10 5.1. BG. . . . . . . . . . . . . . . . . . . . . . . . . . . 10........................................................10 5.2. BR. . . . . . . . . . . . . . . . . . . . . . . . . . . 10........................................................10 5.3. CL. . . . . . . . . . . . . . . . . . . . . . . . . . . 10........................................................10 5.4. CN. . . . . . . . . . . . . . . . . . . . . . . . . . . 10........................................................10 5.5. ES. . . . . . . . . . . . . . . . . . . . . . . . . . . 10........................................................11 5.6. EU. . . . . . . . . . . . . . . . . . . . . . . . . . . 10........................................................11 5.7. GR. . . . . . . . . . . . . . . . . . . . . . . . . . . 11........................................................11 5.8. IL. . . . . . . . . . . . . . . . . . . . . . . . . . . 11........................................................11 5.9. IR. . . . . . . . . . . . . . . . . . . . . . . . . . . 11........................................................11 5.10. JP. . . . . . . . . . . . . . . . . . . . . . . . . . . 11.......................................................11 5.11. KR. . . . . . . . . . . . . . . . . . . . . . . . . . . 11.......................................................12 5.12. MY. . . . . . . . . . . . . . . . . . . . . . . . . . . 11.......................................................12 5.13. NZ. . . . . . . . . . . . . . . . . . . . . . . . . . . 11.......................................................12 5.14. PL. . . . . . . . . . . . . . . . . . . . . . . . . . . 12.......................................................12 5.15. RS. . . . . . . . . . . . . . . . . . . . . . . . . . . 12.......................................................12 5.16. RU. . . . . . . . . . . . . . . . . . . . . . . . . . . 12.......................................................12 5.17. SA. . . . . . . . . . . . . . . . . . . . . . . . . . . 12.......................................................12 5.18. SE. . . . . . . . . . . . . . . . . . . . . . . . . . . 12.......................................................13 5.19. TW. . . . . . . . . . . . . . . . . . . . . . . . . . . 12.......................................................13 5.20. UA. . . . . . . . . . . . . . . . . . . . . . . . . . . 12.......................................................13 5.21. VE. . . . . . . . . . . . . . . . . . . . . . . . . . . 13.......................................................13 5.22. XN--90A3AC. . . . . . . . . . . . . . . . . . . . . . . 13...............................................13 5.23. XN--MGBERP4A5D4AR. . . . . . . . . . . . . . . . . . . . 13........................................13 6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 13...............................................13 7.IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8.Security Considerations. . . . . . . . . . . . . . . . . . . 13 9.........................................14 8. Informative References. . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18.........................................14 1. Introduction Internationalized Domain Names for Applications (IDNA) [RFC5890] allows host names in the DNS [RFC1035] to contain characters from the Unicode repertoire. Some Unicode characters are considered to be "variants" of one another. Because of the 20th century reform of Chinese writing, there is often more than one representation of what Chinese speakers think of as the same character. Some languages written in Latin characters with accents and diacritical marks, known as decorated characters, allow the decorations to be omitted in some situations; for example, French sometimes omits accents on capital letters, depending on country and culture. Due to the difficulty of representing decorated characters in ASCII systems, many users have informally used undecorated characters in DNS host names, even when they are not linguistically equivalent to the decorated versions. There is no single agreed-on definition of "variant". InIDN Variant TLDs [VARIANTTLDS],2012, ICANNsayssaid that variants "occur when a single conceptual character can be identified with two or more different Unicode Code Points with graphic representations that may be visuallysimilar". Insimilar" (this definition was previously available at http://www.icann.org/en/resources/idn/variant-tlds). ICANN's IDN Variant Issues Project report[VIPREPORT], it[VIPREPORT] saysin part "Therethat "[t]here is today no fully accepted definition for what may constitute a variant relationship between top-level labels". RFC 3743 [RFC3743] (an Informational RFC, not the product of theIETF), sayIETF) says that the idea of variants is "wherein one conceptual character can be identified with several different Code Points in character sets for computer use". The proper handing of variant names has been a topic of extensive debate and research, with little consensus reached on how to handlethem,them or even what characters are variants of each other. Many people would like variant names to behave "the same", for a diverse range of meanings of"same.""same". In somecasescases, it is a textual similarity, such as variants having corresponding DNSrecords,records; insomesome, it is functional similarity, such as variant names resolving to the same webserver,server; while inothersothers, it is user experience similarity, such as names resolving to web siteswhichthat, while notidenticalidentical, are perceived by human users as equivalent. This document provides a snapshot of variant handling in thetoptop- level domains (TLDs) contracted by ICANN, so-called gTLDs (generic TLDs) and sTLDs (sponsored TLDs), as of late 2012. We chose those domains because ICANN requires each TLD to describe its IDN and variant practices, and the TLD zone files are available for inspection, to verify what actually goes into the zones. This document also contains a small sampling of so-called ccTLDs (country code TLDs, the TLDs that consist of two ASCII letters) for which we could find information. Since "variant" can mean vastly different things to different people, there is also no agreement about when two zones are supposed to "behave the same". Also, the gTLDs and sTLDs might have different views of what variants are and are not required to report to ICANN about their policies. 2. Terminology We use some terminology that has become generally agreed to when discussing variant names, although we openly admit that such agreement is notcomplete,complete and the terminology continues to change. Bundle: The IDN practices documents (see below) can identify sets of code points that are considered variants of each other using Language Variant Tables, defined in [RFC3743]. A set of names in which the characters in each position are variants is known as abundle, orbundle or, moretechnicallytechnically, as an "IDL Package". The variant rules vary among languages, and for the same language can vary among TLDs. Many languages do not define variantcharacters,characters and hence do not have bundles. Allocated: A name is allocated if sponsorship of that label in some zone has been granted. This is similar to what many people refer to as "registered". Active: A name is active if it appears as an owner name in a zone. Most allocated names are active, but some are not. Blocked: Some names cannot be registered at all. For example, some registries allow one name in a bundle to beregistered,registered and block the rest. Withheld: Some names can only be allocated under certain conditions. For example, some registries permit only the registrant of one name in a bundle to register or activate other names in the same bundle. Parallel NS: Multiple names in a bundle are provisioned in the TLD with identical NS records, so they all are handled by the same name servers. DNAME aliasing: The DNAME [RFC6672] DNS record creates a shadow tree of DNS records, roughly as though there were a CNAME in the shadow tree pointing to each name in the target tree. DNAMEs have been used both to provide resolution for several names in abundle,bundle and to provide resolution for every name under a TLD. 3. Base Documents ICANN has published a variety of documents on variant management. The most important are the "Guidelines for the Implementation of Internationalized Domain Names" issued in Version 1.0 [G1] and Version 3.0 [G3]. ICANN says that TLDs are supposed to register an IDN practices document with IANA for each language and/or script in which the TLD accepts IDN registrations, to be entered in the IANA Repository of IDN Practices [IANAIDN]. The practices document lists the Unicode characters allowed in names in the language or script, which characters are considered equivalent, and which of an equivalent group is preferred. Some TLDs have been more diligent than others at keeping the registry up to date. Also, some TLDs have tables for a few languages and scripts, while others (notably .COM, .NET, and .NAME) have a large set of tables, including some for languages and scripts that are no longer spoken or used, such as Runic and Ogham. The authors also note that many of the tables in the IANA registry are clearly out of date, containing URLs of policy pages that no longer exist and contact information for people who have left the registry. Some of the ICANN agreements with each TLD [ICANNAGREE] describe the TLD's IDN practices, but most don't. 4. Domain Practices of gTLDs This list coversthemost of the current set of gTLDs. In most cases, the authors have also checked the zone files for the gTLD to verify or augment the policy description. 4.1. AERO The .AERO TLD has noIDNs,IDNs and no rules or practices for them. 4.2. ASIA The .ASIA domain accepts registrations in many Asian languages. They have IANA tables for Japanese, Korean, and Chinese. The IANA tables refer to their CJK IDN policies [ASIACJK], which say that applied-for and preferred IDN variants are "active and included in thezone."zone". No IDN publication mechanism is described in the documentation, but since the zone file contains no DNAMEs, they must be using parallel NS for variants. 4.3. BIZ ICANN gave the registry (Neustar) non-specific permission to register IDNs in a letter in 2004 [TWOMEY04A]. The IDN rules were apparently discussed withICANN,ICANN but not defined; see Appendix 9 of the registry agreement [ICANNBIZ9]. They have about a dozen IANA tables. No IDN publication mechanism is described, but frominspectioninspection, it appears that variants are blocked. 4.4. CAT The IDN rules are described in AppendixSS, Part VII.2 [ICANNCATS] of the ICANN agreement. "Registry will take a very cautious approach in its IDN offerings. IDNs will be bundled with the equivalent ASCIIdomains."domains". The only language is Catalan. No IDN publication mechanism is described. Appendix S includes "The list of non-ASCII-characters for Catalan language and their ASCII equivalent for the purposes of the definedservice"service", which implicitly describes bundles. The bundles consist of names with accented and unaccented vowels, U+00E7 ("c with cedilla") and a plain c, and the Catalan "ela geminada" written as two l's separated by a U+00B7 ("middle dot") and the three characters "l-l". When a registrant registers an IDN, the registry also includes the ASCII version. From inspection of the zone file, the ASCII version is provisioned with NS, and the IDN is a DNAME alias of the ASCII version. 4.5. COM ICANN and Verisign have extensive correspondence about IDNs and variants, including letters to ICANN from Ben Turner [TURNER03] andEdRussell Lewis [LEWIS03]. The IANA registry has tables for several dozen languages, including archaic languages such as hieroglyphics and Aramaic. Verisign publishes documents describingScriptsscripts andLanguageslanguages [VRSNLANG],Character Variantscharacter variants [VRSNCHAR],Registration Rulesregistration rules [VRSNRULES], and additional registration logic [VRSNADDL]. In Chinese, variants are blocked (see [VRSNADDL]). In otherlanguageslanguages, there is no bundling or blocking. 4.6. COOP The .COOP TLD has noIDNs,IDNs and no rules or practices for them. 4.7. INFO The IANA registry has a table for German. The German table notes that "the Eszet ... character used in the German script will be mapped to a doubles's' string (i.e.ss)."'ss')". The domain also offers names in Greek, Russian, Arabic, Korean, and other languages. The list and IDN tables areontheon the registry's web site [INFOTABLES]. Afilias says (not in a published policy) that it does not allow Korean characters with differentwidths,widths and that there are no variants in .INFO.The registry agreementAppendix 9 of the registry agreement [ICANNINFO9] refers to a 2003 letter from Paul Twomey [TWOMEY03] that refers to blocking variants. 4.8. JOBS The .JOBS TLD has noIDNs,IDNs and no rules or practices for them. 4.9. MOBI The zone file has about 22,000 IDNs. Afilias says (not in a published policy) that .MOBI supports Simplified Chinese only and that the language table for this is the same as that used by .CN. Variant characters are blocked from registration. The domain has no tables at IANA.The registry agreementAppendix S[ICANNMOBIS]of the registry agreement [ICANNMOBIS], says that IDNs are provisioned according to [G1]. 4.10. MUSEUM The zone file has many IDNs, but spot checks find that many are lame or dead. A 2004 letter from Paul Twomey [TWOMEY04] refers to [G1]. The registry has a detailed policy page [MUSEUMPOLICY]. IDNs are accepted in Latin and Hebrew scripts, with plans for Arabic, Chinese, Japanese, Korean, Cyrillic, and Greek. They do no bundling or blocking, but names that may be confusable due to visual similarity are notallowed,allowed. These are apparently determined by manual inspection, which is practical due to the very small size of the domain. 4.11. NAME TheNAME.NAME TLD is managed the same as .COM. 4.12. NET TheNET.NET TLD is managed the same as .COM. 4.13. ORG A 2003 letter from Paul Twomey [TWOMEY03A] refers to [G1]. The registry has a list of IDN languages [PIRIDN], several written in Latin script, plus Chinese and Korean. A Questions page [PIRFAQ] states that Chinese names have been accepted since January2010,2010 and Cyrillic names in seven languages since February 2011. The practices forsomesome, but notallall, of the Latin languagesallare registered with IANA. A Chinese language policy form on thePIRPublic Interest Registry (PIR) web site says that theZH- CNZH-CN and ZH-TW IDNs use the corresponding ccTLD tables from IANA, and check boxes say that Variant Registration Polices and Variant Management Policies areapplicable,applicable but don't say what those policies are. Private correspondence [CHANDIWALA12] describes not-yet-public rules for variants in Chinese and Cyrillic in .ORG that restrict the number of variants that a registration can have. The Korean language policy form says that it uses the KRNIC table for Korean fromIANA,IANA and that there are no variants. 4.14. POST The .POST TLD appears to have no registrations at all yet. 4.15. PRO The .PRO TLD has noIDNs,IDNs and no rules or practices for them. 4.16. TEL The zone has many IDNs. It is probably operating according to a 2004 letter from Paul Twomey [TWOMEY04A] toNeustarNeustar, which did not mention specific TLDs. Its policy page [TELPOLICY] has links to IDN practices for 17 languages, all but one of which are registered with IANA. None of the Latin scripts do bundling or blocking. The Japanese practices say that variants are blocked. The Chinese practices document says: Therefore, in addition to the blocking mechanism, bundling is also implemented for the Chinese language IDNs. When registering a Chinese language IDN (primary domain name) up to two additional variant domain names will be automatically registered. The first variant will consist entirely of simplified Chinese characters that correspond to those comprising the primary domain name. The second variant will consist exclusively of traditional Chinese characters that correspond to those comprising the primary domain name. The primary domain name together with the requested variants constitutes a bundle on which all operations are atomic. For example, if the registrant adds a name server to the primary domain name, all names in the bundle will be associated with that new name server. The zone has no DNAME records, so the second paragraph strongly suggests parallel NS. The .TEL TLD, intended as an online directory, does not allow registrants to enter arbitraryRR'sResource Records (RRs) in the zone. Nearly all names have NS records pointing to Telnic's own name servers. The A records all point to Telnic's own web server that shows directory information. NAPTR records providethetelephonenumbernumbers of registrantsfor whom they have one.if available. Users can only directly provision MX records.Except thatCurrently, there are 16 domains, none of which are IDNs, that point to random other name servers and mostly appear to be parked. 4.17. TRAVEL The .TRAVEL TLD has noIDNs,IDNs and no rules or practices for them. 4.18. XXX The .XXX TLD has noIDNs,IDNs and no rules or practices for them. 5. Domain Practices of ccTLDs Some ccTLDs publish their IDN policies. This section is a non- exhaustive sampling of some of those policies. Note that few ccTLDs make their zone files available, so the authors could not validate the policies by looking in the zone files. 5.1. BG The .BG TLD (for Bulgaria) publishes a policy page [BGPOLICY]. It has published an IDN table for the Bulgarian and Russian languages in [IANAIDN]. The policy does not mention variants. 5.2. BR The .BR TLD (for Brazil) publishes a policy page [BRPOLICY]. It has published an IDN table for the Portuguese language in [IANAIDN]. Although the IDN table does not describe variants, the policy page says that bundles consist of names that are the same disregarding accents on vowels, cedillas on letter "c", and inserted or deleted hyphens. Only the registrant of a name in a bundle can register other names from the same bundle. 5.3. CL The .CL TLD (for Chile) publishes a policy page [CLPOLICY]. It has published an IDN table for the Latin script in [IANAIDN]. The policy says that variants are not considered for registration. 5.4. CN The .CN TLD (for China) publishes its policy as [RFC4713]. It has published an IDN table for the Chineselaguagelanguage in [IANAIDN]. The policy says that variants are "added into the zone file", presumably as NS records. 5.5. ES The .ES TLD (for Spain) publishes an IDN Area page [ESIDN]. It allows ten accented vowels, U+00E7 ("c with cedilla"), U+00F1 ("n with tilde"), and the Catalan "ela geminada" written as two l's separated by a U+00B7 ("middle dot"). There are no published IDN tables, and there appears to be no variant policy. 5.6. EU The .EU TLD (for Europe) publishes a policy page [EUPOLICY]. It has published IDN tables for three scripts in [IANAIDN]. There appears to be no variant policy. 5.7. GR The .GR TLD (for Greece) publishes a policy page [GRPOLICY] and an FAQ [GRFAQ]. The policy says that all variants of a nameuderunder .GR are assigned to the domain owner, with the zone pointing the NS records of all the variants to the name server of the "main form" of the registered name. The FAQ says that domain names in Greek characters are inserted in the zone using their non-punctuated form inPunycode,Punycode and that the punctuated form is associated with thenon-punctuatednon- punctuated with a DNAME record. It does not publish IDN tables in [IANAIDN]. 5.8. IL The .IL TLD (for Israel) publishes a policy page [ILPOLICY]. It has published an IDN table for the Hebrew language in [IANAIDN]. There is no variant policy. 5.9. IR The .IR TLD (for Iran) publishes a policy page [IRPOLICY]. It has published an IDN table for the Persian language in [IANAIDN]. The IDN table says that it will block registration of variants. However, the policy document says that no IDNs can be registered in .IR. 5.10. JP The .JP TLD (for Japan) publishes a policy page [JPPOLICY]. It has published an IDN table for the Japanese language in [IANAIDN]. Each code point in that table defines no variants, which means there are no variants in registration orresolution..resolution. 5.11. KR The .KR TLD (for South Korea) appears to only publish its policy as an IDN table for the Korean language in [IANAIDN]. The policy in that table does not discuss variants. 5.12. MY The .MY TLD (for Malaysia) appears to only publish its policy as an IDN table for the Jawi language in [IANAIDN]; however, IANA lists that as a table forthe"Malaymicrolanguage".(macrolanguage)". The policy in that table does not discuss variants. 5.13. NZ The .NZ TLD (for New Zealand) publishes a policy page [NZPOLICY]. It has published IDN tables for the Latin script in [IANAIDN]. The policy does not discuss variants. 5.14. PL The .PL TLD (for Poland) publishes a policy page [PLPOLICY]. It has published IDN tables for numerous European languages in [IANAIDN]. The policy says that it will block registration of "look-alike" variants. 5.15. RS The .RS TLD (for Serbia) publishes a policy page [RSPOLICY]. It has published IDN tables for the Serbianand Russian languages,language, and the Latin script, in [IANAIDN]. The policy does not discuss variants. 5.16. RU The .RU TLD (for Russia) appears to only publish its policy as an IDN table for the Russian language in [IANAIDN]. The policy in that table does not discuss variants. 5.17. SA The .SA TLD (for Saudi Arabia) publishes a policy page [SAPOLICY]. It has published an IDN table for the Arabic language in [IANAIDN]. The policy permits the registration of variants, but it is not clear whether others can register names with variants if the owner of a name has not registered them. 5.18. SE The .SE TLD (for Sweden) publishes a policy page [SEPOLICY]. It has published IDN tables for the Swedish and Yiddish languages, and the Latin script, in [IANAIDN]. The policy does not discuss variants. 5.19. TW The .TW TLD (for Taiwan) appears to only publish its policy as an IDN table for the Chinese language in [IANAIDN]. The policy in that table does not discuss variants. 5.20. UA The .UA TLD (for Ukraine) publishes a policy page [UAPOLICY]. It has published an IDN table for the Cyrillic script in [IANAIDN]. The policy does not discuss variants. 5.21. VE The .VE TLD (for Venezuela) appears to only publish its policy as an IDN table for the Spanish language in [IANAIDN]. The policy in that table does not discuss variants. 5.22. XN--90A3AC The .XN--90A3AC TLD (for Serbia) (U+0441 U+0440 U+0431) publishes a policy page [RSIDNPOLICY]. It has published IDN tables for the Cyrillic script in [IANAIDN]. The policy does not discuss variants. 5.23. XN--MGBERP4A5D4AR The .XN--MGBERP4A5D4AR TLD (for Saudi Arabia) (U+0627 U+0644 U+0633 U+0639 U+0648 U+062F U+064A U+0629) appears to only publish its policy as an IDN table for the Arabic script in [IANAIDN]. The policy permits the registration of variants, but it is not clear whether others can register names with variants if the owner of a name has not registered them. 6. Acknowledgements Many people contributed to this document, particularly Nacho Amadoz, Marc Blanchet, Michelle Coon, Jordi Iparraguirre, FredericoA CA. C. Neves, Vaggelis Segredakis, Doron Shikmoni, Andrew Sullivan, Dennis Tan, and Joseph Yee. 7.IANA Considerations This document discusses some of what is in an IANA registry, but otherwise has no IANA considerations, so this section should be removed before publication as an RFC. 8.Security Considerations There are many potential security considerations for various methods of dealing with IDN variants. However, this document is only a catalog of current variantpolicies,policies and does notofaddress whetheror notthey are good or bad ideas from a security standpoint. The documents cited in the Terminology sectionearlierhave a littlediscusiondiscussion of security considerations for IDN variants.9.8. Informative References [ASIACJK]DotAsiaDot.Asia Organisation, ".ASIA CJK (Chinese Japanese Korean) IDN Policies", May 2011,<http://dot.asia/policies/ DotAsia-CJK-IDN-Policies-COMPLETE--2011-05-04.pdf>.<http://dot.asia/policies/DotAsia-CJK-IDN-Policies- COMPLETE--2011-05-04.pdf>. [BGPOLICY]Register.bg,Register.BG, "TermsAndand ConditionsForfor Domain Name RegistrationAndand SupportIn The .Bgin the .BG ZoneAnd Theand the Sub- Zones", August 2011,<https://www.register.bg/user/static/ rules/en/index.html>.<https://www.register.bg/user/ static/rules/en/index.html>. [BRPOLICY] Registro.br,"Domains in"Dominios .br", September 2011,<http:// registro.br/dominio/regras.html>.<http://registro.br/dominio/regras.html>. [CHANDIWALA12] Chandiwala, S., "Letter from Sadik Chandiwala to John Levine", December 2012. [CLPOLICY] NIC Chile, "Syntax RulesForfor Domain NamesUnderunder .CL", August 2005, <http://www.nic.cl/CL-IDN-policy.html>. [ESIDN] Red.es, "IDN area",, <http://www.nic.es/section/ index.action?sec=1127&request_locale=en>.<http://www.dominios.es/dominios/ en/todo-lo-que-necesitas-saber/valores-anadidos/area- idn>. [EUPOLICY] EURid, ".eu Domain Name Registration Terms and Conditions",December 2009, <http://link.eurid.eu/trm- con>.<http://link.eurid.eu/trm-con>. [G1] ICANN, "Guidelines for the Implementation of Internationalized Domain Names, Version 1.0",, <http:// www.icann.org/en/resources/idn/idn-guidelines- 20jun03-en.htm>.<http://www.icann.org/en/resources/idn/idn- guidelines-20jun03-en.htm>. [G3] ICANN, "Guidelines for the Implementation of Internationalized Domain Names, Version 3.0",, <http:// www.icann.org/en/resources/idn/idn-guidelines- 02sep11-en.htm>.<http://www.icann.org/en/resources/idn/idn- guidelines-02sep11-en.htm>. [GRFAQ] Foundation forReaserchResearch and Technology - Hellas, "Frequently Asked Questions regarding [.gr] Domain Name registrations",2012, <https://grweb.ics.forth.gr/ faq.jsp?lang=en>.<https://grweb.ics.forth.gr/faq.jsp?lang=en>. [GRPOLICY] Foundation forReaserchResearch and Technology - Hellas, "Regulation on Management and Assignment of [.gr] Domain Names",2012,2011, <https://grweb.ics.forth.gr/tomcat_docs/ AP592_012_2011_.pdf>. [IANAIDN] IANA, "Repository of IDN Practices",, <http:// www.iana.org/domains/idn-tables>.<http://www.iana.org/domains/idn-tables>. [ICANNAGREE] ICANN, "ICANN Registryagreements", , <http:// www.icann.org/en/about/agreements/registries>.Agreements", <http://www.icann.org/en/about/agreements/registries>. [ICANNBIZ9] ICANN, "Appendix 9 of ICANN .BIZ Registryagreement", DecAgreement", December 2006,<http://www.icann.org/en/about/agreements/registries /biz/appendix-09-08dec06-en.htm>.<http://www.icann.org/en/about/ agreements/registries/biz/appendix-09-08dec06-en.htm>. [ICANNCATS] ICANN, "Appendix S of ICANN .CAT Registryagreement", MarAgreement", March 2006,<http://www.icann.org/en/about/agreements/registries /cat/cat-appendixs-22mar06-en.htm>.<http://www.icann.org/en/about/agreements/ registries/cat/cat-appendixs-22mar06-en.htm>. [ICANNINFO9] ICANN, "Appendix 9 of ICANN .INFO Registryagreement", DecAgreement", December 2006,<http://www.icann.org/en/tlds/agreements/info/ appendix-09-08dec06.htm>.<http://www.icann.org/en/tlds/ agreements/info/appendix-09-08dec06.htm>. [ICANNMOBIS] ICANN, "Appendix S of ICANN .MOBI Registryagreement", NovAgreement", November 2005,<http://www.icann.org/en/about/agreements/registries /mobi/mobi-appendixs-23nov05-en.htm>.<http://www.icann.org/en/about/ agreements/registries/mobi/mobi- appendixs-23nov05-en.htm>. [ILPOLICY] Israel Internet Association (ISOC-IL), "Rules for the Allocation of Domain Names Under the Israel Country Code Top Level Domain ("IL ")", August 2010,<http:// www.isoc.org.il/domains/il-domain-rules.html>.<http://www.isoc.org.il/domains/il-domain-rules.html>. [INFOTABLES] Afilias, "Internationalized Domain Names",2006,<http:// info.info/information/internationalized-domain-names>. [IRPOLICY] IPM/IRNIC, "Internationalized Domain Names inIR", August 2010,.IR", <http://www.nic.ir/Internationalized_Domain_Names>. [JPPOLICY] JPRS, "Technology bylaws regarding generic domain name registration JP",July 2012,<http://jprs.jp/doc/rule/ saisoku-1-wideusejp.html>. [LEWIS03] Lewis,E.,R., "Letter fromEdRussell Lewis to Paul Twomey",OctOctober 2003,<http://www.icann.org/en/news/correspondence/lewis- to-twomey-13oct03-en.htm>.<http://www.icann.org/en/news/ correspondence/lewis-to-twomey-13oct03-en.htm>. [MUSEUMPOLICY]Musedoma,MuseDoma, "Internationalized Domain Names (IDN) in .museum - Policies and terms of use",JanJanuary 2009,<http:// about.museum/idn/idnpolicy.html>.<http://about.museum/idn/idnpolicy.html>. [NZPOLICY] .nz Registry Services, "Internationalised Domain Names (IDN)",July 2010,<http://nzrs.net.nz/dns/idn>. [PIRFAQ] Public Interest Registry, "Internationalized Domain Name (IDN) Questions",2010, <http://www.pir.org/why/global/ idn>.<http://www.pir.org/why/global/idn>. [PIRIDN] Public Interest Registry, "Go Global",Jan 2009, <http:// www.pir.org/why/global>.<http://www.pir.org/why/global>. [PLPOLICY] NASK (PL-TLD), "Registering Internationalized Domain Names under .PL", July2012, <http://www.dns.pl/IDN/idn- registration-policy.txt>.2007, <http://www.dns.pl/IDN/idn-registration-policy.txt>. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean", RFC 3743, April 2004. [RFC4713] Lee, X., Mao, W., Chen, E., Hsu, N., and J. Klensin, "Registration and Administration Recommendations for Chinese Domain Names", RFC 4713, October 2006. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, June 2012. [RSIDNPOLICY] RNIDS, "Internationalized DomainNames(IDN)Names (IDN) in xn--90a3ac ccTLD", October 2011, <http://www.rnids.rs/data/DOKUMENTI/ idn-srb-policy-termsofuse-v1.4-eng.pdf>. [RSPOLICY] RNIDS, "General Terms And Conditions For Registration of .rs Domain Names", June 2009, <http://www.rnids.rs/data/ DOKUMENTI/Opsti%20akti/list0029_en.pdf>. [SAPOLICY] Saudi Network Information Center,"Permitted Characters and Symbols", December 2010, <http://nic.sa/docs/ Saudi_Domain_Name_Registration_Regulation_V3.0_EN.pdf>."Saudi Domain Name Registration Regulation", March 2011, <http://nic.sa/docs/Saudi_Domain_Name_Registration_ Regulation_V3.0_EN.pdf>. [SEPOLICY] .SE (The Internet Infrastructure Foundation),"Registration instructions", 2012, <https://www.iis.se/ english/register/idn/>."Domain names (IDN)", <https://www.iis.se/english/register/idn/>. [TELPOLICY] Telnic, ".TEL Policies",Jan 2007, <http://www.telnic.org/ policies.html>.<http://www.telnic.org/policies.html>. [TURNER03] Turner, B., "Letter from Ben Turner to Paul Twomey",NovNovember 2003,<http://www.icann.org/en/news/correspondence/turner- to-twomey-17nov03-en.htm>. [TWOMEY03A]<http://www.icann.org/en/news/ correspondence/turner-to-twomey-17nov03-en.htm>. [TWOMEY03] Twomey, P., "Letter from Paul Twomey toEdward Viltz", OctRam Mohan", August 2003,<http://www.icann.org/en/news/correspondence/twomey- to-viltz-21oct03-en.htm>. [TWOMEY03]<http://www.icann.org/en/news/ correspondence/twomey-to-mohan-19aug03-en.htm>. [TWOMEY03A] Twomey, P., "Letter from Paul Twomey toRam Mohan", AugEdward Viltz", October 2003,<http://www.icann.org/en/news/correspondence/twomey- to-mohan-19aug03-en.htm>. [TWOMEY04A]<http://www.icann.org/en/news/ correspondence/twomey-to-viltz-21oct03-en.htm>. [TWOMEY04] Twomey, P., "Letter from Paul Twomey toRichard Tindal", JulyCary Karp", January 2004,<http://www.icann.org/en/correspondence/twomey- to-tindal-29jul04.pdf>. [TWOMEY04]<http://www.icann.org/en/news/ correspondence/twomey-to-karp-20jan04-en.htm>. [TWOMEY04A] Twomey, P., "Letter from Paul Twomey toCary Karp", JanRichard Tindal", July 2004,<http://www.icann.org/en/news/correspondence/twomey- to-karp-20jan04-en.htm>.<http://www.icann.org/en/ correspondence/twomey-to-tindal-29jul04.pdf>. [UAPOLICY] UA ccTLD, "Registration Schedule of IDN-domains",October 2010,<http://www.hostmaster.ua/idn/>.[VARIANTTLDS] ICANN, "IDN Variant TLDs", , <http://www.icann.org/en/ resources/idn/variant-tlds>.[VIPREPORT] ICANN, "A Study of Issues Related to the Management of IDN Variant TLDs (Integrated Issues Report)",, <http:// www.icann.org/en/topics/idn/idn-vip-integrated-issues- final-clean-20feb12-en.pdf>.<http://www.icann.org/en/topics/idn/idn-vip- integrated-issues-final-clean-20feb12-en.pdf>. [VRSNADDL] Verisign, "Additional Logic",, <http:// www.verisigninc.com/en_US/products-and-services/domain- name-services/domain-information-center/idn-code-points/ additional-logic/index.xhtml>.<http://www.verisigninc.com/en_US/products-and- services/domain-name-services/domain-information- center/idn-code-points/additional-logic/index.xhtml>. [VRSNCHAR] Verisign, "Character Variants",, <http:// www.verisigninc.com/en_US/products-and-services/domain- name-services/domain-information-center/idn-resources/ character-variants/index.xhtml>.<http://www.verisigninc.com/en_US/products-and- services/domain-name-services/domain-information- center/idn-resources/character-variants/index.xhtml>. [VRSNLANG] Verisign, "Scripts and Languages",, <http:// www.verisigninc.com/en_US/products-and-services/domain- name-services/domain-information-center/idn-resources/ scripts-languages/index.xhtml>.<http://www.verisigninc.com/en_US/products-and- services/domain-name-services/domain-information- center/idn-resources/scripts-languages/index.xhtml>. [VRSNRULES] Verisign, "Registration Rules",, <http:// www.verisigninc.com/en_US/products-and-services/domain- name-services/domain-information-center/idn-code-points/ registration-rules/index.xhtml>.<http://www.verisigninc.com/en_US/products-and- services/domain-name-services/domain-information- center/idn-code-points/registration- rules/index.xhtml>. Authors' Addresses John Levine Taughannock NetworksEmail:EMail: standards@taugh.com Paul Hoffman VPN ConsortiumEmail: paul.hoffman@vpnc.org>EMail: paul.hoffman@vpnc.org