Edmon Chung Internet Draft Neteka Intended Category: Informational April 2003 ZONEPREP - Zone Preparations for IDN STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The reader is cautioned not to depend on the values that appear in examples to be current or complete, since their purpose is primarily educational. Distribution of this memo is unlimited. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Zoneprep intends to provide a framework for applying Charprep variants to zone file management. More specifically, Charprep profiles are used to generate a set of perceptually equivalent domains from a given primary domain, Zoneprep policy profiles are used to determine which among the generated set of Charprep variants to include into the DNS zone file. This document does NOT provide any specific Zoneprep policy profiles, instead it describes a framework for Zone Administrators (e.g. registries) to consider when implementing IDN. More importantly, to consider the policy on reserving and publishing variants from the given primary domain to the DNS zone files. This framework also leads into the discussion of provisioning protocol for IDN, more importantly for a server to announce its policies on reserved variants and zone variants, as well as for the client to further manage the IDN. This document will NOT describe extensively this issue, for further discussion please refer to [EPP- I], which incorporates this framework into EPP. Chung [Page 1] ZONEPREP April 2003 Table of Contents 1. Introduction....................................................2 1.1 Terminology....................................................3 1.2 Nomenclature...................................................3 2. Charprep & Zoneprep.............................................3 3. Reserved Variants (RV)..........................................4 3.1 Restricted Reserved Variants (rRV).............................4 3.2 Automatic Zone Variants (AutoZV)...............................5 3.3 Normal Reserved Variants (nRV).................................5 3.4 Suggested Reserved Variants (sRV)..............................5 4. Zone Variants (ZV)..............................................5 4.1 Same Delegation Name Servers as Primary Domain (Same NS).......6 4.2 Alias to Primary Domain Only (Alias Only)......................6 4.3 Normal Zone Variants (Normal ZV)...............................7 5. Zoneprep Policy Profiles........................................7 5.1 Zoneprep Policy Tables.........................................7 5.2 Publishing Zoneprep Profiles...................................8 5.3 Generating Zoneprep Variant (ZV) Sets..........................9 5.4 Managing Multiple Language Registrations.......................9 6. Provisioning Considerations....................................10 7. IANA Considerations............................................10 8. Security Considerations........................................11 1. Introduction While the issue with character equivalency has been raised as an important concern for the introduction and management of IDN, one key problem is that the possible set of variants is potentially huge. For example, 1 domain with 5 characters, each having 1 Charprep variant would already create a set of 2^5 = 32 domains (including the primary domain). And if one of the characters actually had 2 variants, then the set would balloon up to 48 domains. If character equivalency mandates that all of the Charprep variants be managed in DNS zone files, the scaling factor may cause Zone Administrators (e.g. registries) a lot of problem. To address this problem, Zoneprep policies should be used to select which variants to be published in the DNS zone files and which ones to simply reserve and be blocked from registration. Zoneprep will describe a framework for categorizing the different types of variants and how a Zone Administrator should treat the different categories. Specific Zoneprep policy profiles SHOULD however be determined by the individual zone administrators (e.g. registries). Chung [Page 2] ZONEPREP April 2003 1.1 Terminology The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2 Nomenclature As in the Unicode Standard [UNICODE], Unicode codepoints are denoted by "U+" followed by four to six hexadecimal digits. The following terms will carry specific definitions within this document: Zone Administrator û A domain operator or service that manages sub- domain delegations. This would include domain registries such as TLD registries as well as domain operators of SLDs to issue third level domains, etc. Registration û Entry of a domain into the zone file of an authoritative name server. Resolution û Matching or lookup of domain names within the name server. IDN û Internationalized Domain Names: domain names consisted of one or more characters out of the A-z 0-9 and "-" repertoire. 2. Charprep & Zoneprep Charprep forms the basis of Zoneprep. The Charprep variant set is further categorized into different types in the Zoneprep framework. There are three main types of domain names within a package or bundle of domain names as identified in Zoneprep: - Primary Domain - Reserved Variants (RV) - Zone Variants (ZV) The Primary Domain is the original domain name that was submitted for registration. The set of Reserved Variants (RV) is a set of Charprep variants derived from a particular Charprep profile. The set of Zone Variants (ZV) is a subset of the RV set, which will be published in the DNS zone file and available for resolution. All of the domain names considered MUST be properly Nameprep-ed and fully qualified domain names. While Charprep is based on scripts, Zoneprep is conceptually based on languages (Further discussion in Section 5). Chung [Page 3] ZONEPREP April 2003 While Charprep can be used as a basis for a consistent user experience in that a particular string of characters based on the script they are using will result in the same set of reserved variants, Zone Administrators can use Zoneprep policies to determine the resolvability of a particular variant. 3. Reserved Variants (RV) The RV set is precisely the set of Charprep variants generated based on the chosen Charprep mapping profile in the particular Zoneprep policy profile. Each RV (except for suggested reserved variants) is considered a registered domain and MUST be blocked from registration. More specifically, upon submission of registration for a domain name, one or more intended languages SHOULD be provided. With the language information, the Zone Administrator will choose to use the relevant Zoneprep policy profile, within which would be the specification for which Charprep profile to use. From the Primary Domain, the Zone Administrator can then generate the RV set based on the Charprep table. After generating the RV set, the Zoneprep policy profile then determines how each RV should be categorized into the four types of RVs: 1. Restricted Reserved Variants (rRV); 2. Automatic Zone Variants (AutoZV); 3. Normal Reserved Variants (nRV); and, 4. Suggested Reserved Variants (sRV). OR, a Zone Administrator may choose to define in the Zoneprep Policy Profile to have all RVs in a zone to be in the same type: rRV, AutoZV or nRV. Because sRVs are NOT registered domains, if a Zone Administrator chooses to define all RVs to be sRVs initially, a policy for the RVs once they are registered MUST still be provided. 3.1 Restricted Reserved Variants (rRV) Restricted RVs are RVs that cannot be activated as Zone Variants (ZV). Domains listed as rRVs are blocked from registration by another user but MUST not be published into the zone file, therefore rRVs are NOT resolvable domains. For a registered domain label to be categorized as an rRV, all of the characters comprising the string, that are subjected to variants (including primary characters), MUST be determined as an rRV candidate based on the corresponding Zoneprep policy profile. For example, if is listed as an rRV for a primary domain with , then suppose the primary domain is .example, then the RV: .example will be categorized as an rRV, while .example will NOT be. Chung [Page 4] ZONEPREP April 2003 3.2 Automatic Zone Variants (AutoZV) Automatic Zone Variants are RVs that MUST be published into the zone files. Upon registration of the Primary Domain, AutoZVs as well as the Primary Domain will by default be included in the DNS zone files. Domains listed as an AutoZV cannot be deactivated (which means that the domain should only be removed from the zone files if the primary domain is deleted. For a domain label to be categorized as an AutoZV, all of the characters comprising the string, that are subjected to variants (including primary characters), MUST be determined as an AutoZV candidate based on the corresponding Zoneprep policy profile. For example, if is listed as an AutoZV for a primary domain with , then suppose the primary domain is .example, then the RV: .example will be categorized as an AutoZV, while .example will NOT be. 3.3 Normal Reserved Variants (nRV) Normal RVs are RVs that can be activated as Zone Variants (ZV) after the initial registration. Domains listed as nRVs could be selected to be included into the DNS zone files. ZVs that are activated from nRVs could be deactivated at anytime. 3.4 Suggested Reserved Variants (sRV) Suggested RVs are RVs that are generated from the Charprep profile, but have NOT been registered yet. More specifically, sRVs continue to be available for registration by other users and are NOT blocked. Any RV that is not categorized as rRV, AutoZV or nRV will be an "sRV". Suggested RVs can be registered. Upon registration the RV will assume one of the abovementioned types of RVs. Also, once registered the RV will be included in a package or bundle of domain names corresponding to the primary domain and SHOULD NOT be independently unregistered. 4. Zone Variants (ZV) The ZV set is a subset of a given RV set that is published into the DNS zone files. Because they are published into the zone files, the Zone Administrator SHOULD consider each ZV as a unique domain in the DNS. By default, the Primary Domain MUST be included into the zone file. The ZV set will then be determined by 2 ways: Chung [Page 5] ZONEPREP April 2003 - Included as an Automatic Zone Variant (AutoZV) OR - An nRV being activated into a ZV Similar to the concept of the categorization of RVs, there are three possible types of ZVs as determined by a Zoneprep Policy Profile: 1. Same Delegation Name Servers; 2. Alias Only; and, 3. Normal Zone Variants. The type of ZV determines the behavior of the ZV domain in the zone file. More specifically, the types of resource records (RR) that may be associated with the ZV. 4.1 Same Delegation Name Servers as Primary Domain (Same NS) ZV domains that are determined to be "Same NS" MUST have the same set of sub-delegation Name Servers as the Primary Domain. Within the sub-delegated hostname servers however, there could be different sets of sub-domains as administered by the Zone Administrator of the sub- delegated domain. For a domain label to be categorized as "Same NS", all of the characters comprising the string, that are subjected to variants (including primary characters), MUST be determined to be a "Same NS" candidate based on the corresponding Zoneprep policy profile. OR, a Zone Administrator may choose to define in the Zoneprep Policy Profile to have all ZVs in a zone to be "Same NS". 4.2 Alias to Primary Domain Only (Alias Only) ZV domains that are defined as "Alias Only" should have no RR sets except for a CNAME (or DNAME) record gluing the ZV to the Primary Domain. For a domain label to be categorized as "Alias Only", all of the characters comprising the string, that are subjected to variants (including primary characters), MUST be determined as an "Alias Only" candidate based on the corresponding Zoneprep policy profile. OR, a Zone Administrator may choose to define in the Zoneprep Policy Profile to have all ZVs in a zone to be "Alias Only". Note that in order to create an Alias, the DNS server for the Zone must be able to handle dynamic CNAME. More specifically to allow the use of wildcards within a CNAME record: *.Alias-ZV.example CNAME *.PrimaryDomain.example Or, utilize a DNAME record for a similar effect (backwards compatibility to resolvers may however be compromised); Or, the Zone Administrator will have to be responsible for all sub-domains and Chung [Page 6] ZONEPREP April 2003 delegations. All of these is however beyond the scope of this document. 4.3 Normal Zone Variants (Normal ZV) Normal ZVs are managed the same way as any regular unique domain name. Any type of RR set may be assigned and administered by the Zone Administrator. Any ZV that is not categorized as "Same NS" or "Alias Only" will be a "Normal ZV". Because a ZV set is a subset of the RV set, the sum of "Same NS", "Alias Only" and "Normal ZV" must therefore be less than or equal to the total number of domains in the given RV set. 5. Zoneprep Policy Profiles Zoneprep Policy Profiles directly impact the resolvability of a domain name. That is, if a particular Charprep variant is restricted and must not be included in the zone file, that particular form will NOT be resolvable. In essence, Zoneprep Policy Profiles describe the operational policy of a Zone Administrator (e.g. registry) on how Charprep Profiles and Tables will be utilized and how variants will be managed within the DNS zone files and the registry database. Zoneprep Policy Profiles SHOULD be published by languages based on the ISO639 "Code for the representation of names of languages" standard. One Zoneprep Policy Profile may describe the policies for multiple languages. A Zoneprep Policy Profile MUST include: 1. A set of Zoneprep Policy Tables relevant to the language(s) of domain names covered by the particular Zoneprep Policy Profile 2. A report describing the languages of domain names accepted and rationale on the choice of Charprep tables as well as Zoneprep considerations (including general concepts for the categorization of domain names into nRV, rRV, AutoZV, sRV as well as "Normal ZV", "Same NS" and "Alias Only") 5.1 Zoneprep Policy Tables A Zoneprep Policy Table MUST identify which Charprep profile(s) it is referring to as well as what language(s) are included within the profile. The table MUST have the following 7 fields: Primary Char nRV AutoZV rRV SameNS Alias Remarks +------+--------+--------+--------+--------+--------+---------------+ |U+XXXX|U+XXXX..|U+XXXX..|U+XXXX..|U+XXXX..|U+XXXX..| OptÆl Remarks | : : : : : : : Chung [Page 7] ZONEPREP April 2003 The Primary Char column will be the key for the table and contain one Unicode codepoint only per entry. The total number of entries MUST not be more than the total number of entries in the corresponding Charprep profile(s). The next 5 columns: nRV, AutoZV, rRV, SameNS and Alias, consists of a set of one or more space delimited codepoints corresponding to the codepoint in the Primary Char column. The codepoint identified in the primary character column MAY also be inputted into the other columns. For multi-codepoint entries, the convention: U+XXXX+XXXX will be used. Entries to the columns for nRV, AutoZV and rRV are mutually exclusive. Codepoints included in AutoZV MUST NOT be included in rRV for the same row entry (same Primary Char), vice versa and thereon. Similarly, entries to the pair of columns for "SameNS" and "Alias" are mutually exclusive. Codepoints included in "SameNS" MUST NOT be included in "Alias" for the same row entry (same Primary Char) and vice versa. Furthermore, codepoints included in rRV MUST NOT be included in "Same NS" or "Alias Only" in the same row entry (same Primary Char) and vice versa. In summary, any codepoint that is included in rRV MUST NOT exist in the other columns for the same entry (Primary Char). Note that there are no columns allocated for sRV or Normal ZV because by default any codepoint not included in the other relevant columns will be determined as sRV and Normal ZV respectively. Optional remarks on rationale for the allocations could be provided. 5.2 Publishing Zoneprep Profiles A Zone Administrator, especially Top-Level Domain Registries, SHOULD publish Zoneprep profiles for all languages they allow registrations in, and make it publicly available for end users to understand the registration policies. As mentioned, Zoneprep Policy Profiles should be published based on languages identified in the ISO639 standard and correspond to Charprep profiles. Multiple languages could be considered in one Zoneprep Policy Profile. A text format for the Zoneprep Policy Table as follows should be published together with the profile: #Zoneprep Table for XXX #Version 1.0 #Charprep profile: latn #Languages: en el ru U+0061;U+0061;;U+03B1 U+0430;;;English Domain Chung [Page 8] ZONEPREP April 2003 U+03B1;U+03B1;U+0061;U+0430;U+0061;No Cyrillic for Greek as Primary U+0430;;U+0061;;;U+03B1;Alias onlt for Greek variant Note that multiple Charprep profiles and languages may be identified. 5.3 Generating Zoneprep Variant (ZV) Sets This section provides an example on how RVs and ZVs would be managed based on a given Zoneprep Policy Profile. Taking the example given in Section 5.2 corresponding to the Charprep Mapping Profile given as an example in Charprep [CHARPREP] section 6 (meant for Script:LATN). Given a request for registration IDN: Lang = el Primary Domain = <03B1><03B1>.example [.example] An RV set of 8 Charprep Variants will be generated: <03B1><0061>.example ( nRV & Normal ZV ) <03B1><0430>.example ( sRV & Normal ZV ) <0061><0061>.example ( AutoZV & SameNS ) <0061><03B1>.example ( nRV & Normal ZV ) <0061><0430>.example ( sRV & Normal ZV ) <0430><0061>.example ( sRV & Normal ZV ) <0430><03B1>.example ( sRV & Normal ZV ) <0430><0430>.example ( rRV & N/A ) Within this RV set, there will be one AutoZV: <0061><0061>.example and one Restricted RV: <0430><0430>.example. All domains containing the Cyrillic will be an sRV and the others would be Normal RVs and both may be activated as ZVs. Additionally, the AutoZV: <0061><0061>.example MUST have the same set of sub-delegation name servers as the primary domain: <03B1><03B1>.example. 5.4 Managing Multiple Language Registrations Zoneprep allows the management of multiple languages within a single domain label by either using multiple Zoneprep tables or by having a Zoneprep profile that addresses multiple languages. When multiple Charprep tables are used, the most conservative approach based on the combined equivalency variants will prevail (i.e. a superset of the variants generated by both Charprep tables will be used). When multiple Zoneprep tables are used, the most restrictive approach will be used. Restrictive-ness of Zoneprep policies are ranked as follows: For RV types (from most restrictive): 1. Restricted RV 2. Auto ZV 3. Normal RV Chung [Page 9] ZONEPREP April 2003 4. Suggested RV For ZV types (from most restrictive): 1. Alias Only 2. Same NS 3. Normal ZV More specifically, a permutation of the label for the multiple Zoneprep profiles will be compiled and the resulting parameters for RV and ZV types compared. 6. Provisioning Considerations In order to implement the Charprep and Zoneprep framework, Zone Administrators (e.g. registries) should consider incorporating the mechanisms into their provisioning protocols with subscribers (e.g. registrars or registrants directly). In terms of a provisioning framework for a top-level domain registry, it is possible to envision a model whereby the equivalence rules are enforced at the registrar level between the registrar and the registrant, while the registry will simply accept registrations and allow registrars to hold domains and to set delegation NS records as usual to effect the Zoneprep policies. However that is NOT RECOMMENDED because it may cause a lot of end-user (registrant) confusion if Zoneprep policies between registrars are not consistent. It is also very risky to assume that an out-of-band enforcement of the policies between the registry and registrar will be highly reliable. Therefore, the registry-registrar provisioning protocol should be able to handle the announcement of the RV and ZV policies upon registration of a domain name. As well as to allow the further provisioning of the variant domains (e.g. activating an RV into a ZV). Further discussion on incorporating Charprep and Zoneprep considerations for EPP (Extensible Provisioning Protocol) could be found in the document: EPP IDN Mapping [EPP-I]. Because Charprep and Zoneprep will likely have implications on the existing LDH (Letters, Digits & Hyphens) domain names currently registered within the zone (e.g. registry), the Zone Administrator should take into consideration the policies for handling the grandfathering of variants for the existing domain names. This document does NOT explicitly talk about the management of this process. 7. IANA Considerations There are no explicit IANA considerations required for Zoneprep. IANA may however choose to maintain a registry for Zoneprep Policy Profiles as described in Section 5 for TLD registries. Chung [Page 10] ZONEPREP April 2003 8. Security Considerations This document does not talk about DNS security issues, and it is believed that the proposal does not introduce additional security problems not already existent and/or anticipated by adding multilingual characters to DNS and/or using ACE (ASCII Compatible Encoding). Zoneprep and Charprep considerations should however help to improve the security and authenticity for the usage of IDNs by reducing the confusion of perceptually equivalent characters. Acknowledgements This document incorporates many of the discussions from the CJK community (from CNNIC, TWNIC, JPRS and KRNIC respectively) and by the JET (Joint Engineering Team) as well as at different forums including IETF and ICANN. More importantly discussions in the document: "Internationalized Domain Names Registration and Administration Guideline for Chinese, Japanese and Korean". Furthermore, many valuable comments and discussions with the following people were incorporated: Xiaodong (Sheldon) Lee Kenny Huang Paul Hoffman Mark Davis Vincent Chen References [TSCONV] XiaoDong LEE, et al., ôTraditional and Simplified Chinese Conversionö, November 2001 [JPCHAR] Yoshiro Yoneya & Yasuhiro Morishita, JPNIC, ôJapanese characters in multilingual domain name labelsö, March 2, 2001 [HANGULCHAR] Soobok Lee & GyeongSeog Gim, ôHangeul NAMEPREP recommendation version 1.0ö, June 2001 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities," STD 13, RFC 1034, USC/ISI, November 1987 [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification," STD 13, RFC 1035, USC/ISI, November 1987 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997 Chung [Page 11] ZONEPREP April 2003 [RFC2181] R. Elz, University of Melbourne & R. Bush, RGnet, Inc., ôClarifications to the DNS Specificationö, July 1997 [RFC3454] P. Hoffman, IMC & VPNC & M. Blanchet, Viagenie, öPreparation of Internationalized Strings ("stringprep")ö, December 2002 [RFC3490] P. Faltstrom, Cisco, P. Hoffman, IMC & VPNC & A. Costello UC Berkeley, ôInternationalizing Domain Names in Applications (IDNA)ö, March 2003 [RFC3491] P. Hoffman, IMC & VPNC & M. Blanchet, Viagenie, ôNameprep: A Stringprep Profile for Internationalized Domain Names (IDN)ö, March 2003 [RFC3492] A. Costello, Univ. of California, Berkeley, ôPunycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)ö, March 2003 IDN-Admin Editors: James SENG & John KLENSIN; Authors: K. KONISHI, K. HUANG, H. QIAN & Y. KO, ôInternationalized Domain Names Registration and Administration Guideline for Chinese, Japanese and Koreanö [IDNOP] E. Chung, ôIDN Operationsö, March 2003 [CHARPREP] E. Chung, ôCharacter Preparations for IDNö, March 2003 [EPP-I] E. Chung, ôEPP IDN Mappingö, March 2003 [IDNREG] E. Chung, ôIDN Registry Implementation Guidelinesö, March 2003 Authors: Edmon Chung Neteka Suite 100, 243 College St., Toronto, Ontario, Canada M5T 1R5 edmon@neteka.com Chung [Page 12]