Internet DRAFT - draft-chung-idnop-zoneprep
draft-chung-idnop-zoneprep
Edmon Chung
Internet Draft Neteka
<draft-chung-idnop-zoneprep-00.txt>
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 <U+0430> is listed as an rRV for a primary domain
with <U+03B1>, then suppose the primary domain is
<U+03B1><U+03B1>.example, then the RV: <U+0430><U+0430>.example will
be categorized as an rRV, while <U+0430><U+0061>.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 <U+0061> is listed as an AutoZV for a primary domain
with <U+03B1>, then suppose the primary domain is
<U+03B1><U+03B1>.example, then the RV: <U+0061><U+0061>.example will
be categorized as an AutoZV, while <U+0430><U+0061>.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 [<Alpha><Alpha>.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 <A> 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]
