Request for Comments: 4290 December 2005
Category: Informational
Suggested Practices for Registration of
Internationalized Domain Names (IDN)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
IESG Note
This RFC is not a candidate for any level of Internet Standard. The
IETF disclaims any knowledge of the fitness of this RFC for any
purpose and notes that the decision to publish is not based on IETF
review apart from IESG review for conflict with IETF work. The RFC
Editor has chosen to publish this document at its discretion. See
RFC 3932 for more information.
Abstract
This document explores the issues in the registration of
internationalized domain names (IDNs). The basic IDN definition
allows a very large number of possible characters in domain names,
and this richness may lead to serious user confusion about similar-
looking names. To avoid this confusion, the IDN registration process
must impose rules that disallow some otherwise-valid name
combinations. This document suggests a set of mechanisms that
registries might use to define and implement such rules for a broad
range of languages, including adaptation of methods developed for
Chinese, Japanese, and Korean domain names.
Table of Contents
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. The Nature and Status of these Recommendations .............4
1.3. Terminology ................................................5
1.3.1. Languages and Scripts .................................5
1.3.2. Characters, Variants, Registrations, and Other
Issues ................................................6
1.3.3. Confusion, Fraud, and Cybersquatting ..................9
1.4. A Review of the JET Guidelines .............................9
1.4.1. JET Model .............................................9
1.4.2. Reserved Names and Label Packages ....................10
1.5. Languages, Scripts, and Variants ..........................11
1.5.1. Languages versus Scripts .............................11
1.5.2. Variant Selection ....................................13
1.6. Variants are not a Universal Remedy .......................14
1.7. Reservations and Exclusions ...............................14
1.7.1. Sequence Exclusions for Valid Characters .............14
1.7.2. Character Pairing Issues .............................15
1.8. The Registration Bundle ...................................15
1.8.1. Definitions and Structure ............................15
1.8.2. Application of the Registration Bundle ...............16
2. Some Implications of This Approach .............................17
3. Possible Modifications of the JET Model ........................18
4. Conclusions and Recommendations About the General Approach .....18
5. A Model Table Format ...........................................19
6. A Model Label Registration Procedure: "CreateBundle" ...........20
6.1. Description of the CreateBundle Mechanism .................21
6.2. The "no-variants" Case ....................................22
6.3. CreateBundle and Nameprep Mapping .........................22
7. IANA Considerations ............................................23
8. Internationalization Considerations ............................24
9. Security Considerations ........................................24
10. Acknowledgements ..............................................25
11. Informative References ........................................26
1. Introduction
1.1. Background
The IDNA (Internationalized Domain Names in Applications)
specification [RFC3490] defines the basic model for encoding non-
ASCII strings in the DNS. Additional specifications [RFC3491]
[RFC3492] define the mechanisms and tables needed to support IDNA.
As work on these specifications neared completion, it became apparent
that it would be desirable for registries to impose additional
restrictions on the names that could actually be registered (e.g.,
see [IESG-IDN] and [ICANN-IDN]) to reduce potential confusion among
characters that were similar in some way. This document explores
these IDN (international domain name) registration issues and
suggests a set of mechanisms that IDN registries might use.
Registration restrictions are part of a long tradition. For example,
while the original DNS specifications [RFC1035] permitted any string
of octets in a DNS label, they also recommended the use of a much
more restricted subset. This subset was derived from the much older
"hostname" rules [RFC952] and defined by the "LDH" convention (for
the three permitted types of characters: letters, digits, and the
hyphen). Enforcement of this restricted subset in registrations was
the responsibility of the registry or domain administrator. The
definition of the subset was embedded in the DNS protocol itself,
although some applications protocols, notably those concerned with
electronic mail, did impose and enforce similar rules.
If there are no constraints on registration in a zone, people can
register characters that increase the risk of misunderstandings,
cybersquatting, and other forms of confusion. A similar situation
existed even before the introduction of IDNA, as exemplified by
domain names such as example.com and examp1e.com (note that the
latter domain contains the digit "1" instead of the letter "l").
For non-ASCII names (so-called "internationalized domain names" or
"IDNs"), the problem is more complicated. In the earlier situation
that led to the LDH (hostname) rules, all protocols, hosts, and DNS
zones used ASCII exclusively in practice, so the LDH restriction
could reasonably be applied uniformly across the Internet. Support
for IDNs introduces a very large character repertoire, different
geographical and political locations, and languages that require
different collections of characters. The optimal registration
restrictions are no longer a global matter; they may be different in
different areas and, hence, in different DNS zones.
For some human writing systems, there are characters and/or strings
that have equivalent or near-equivalent usages. If a name can be
registered with such a character or string, the registry might want
to automatically associate all of the names that have the same
meaning with the registered name. The registry might also decide
whether the names that are associated with, or generated by, one
registration should, as a group or individually, go into the zone or
should be blocked from registration by different parties.
To date, the best-developed system for handling registration
restrictions for IDNs is the JET Guidelines for Chinese, Japanese,
and Korean [RFC3743], the so-called "CJK" languages. The JET
Guidelines are limited to the CJK languages and, in particular, to
their common script base. Those languages are also the best-known
and most widely-used examples of writing systems constructed on
"ideographic" or "pictographic" principles. This document explores
the principles behind the JET guidelines. It then examines some of
the issues that might arise in adapting them to alphabetic languages,
i.e., to languages whose characters primarily represent sounds rather
than meanings.
This document describes five things:
1. The general background and considerations for non-ASCII scripts
in names.
2. Suggested practices for describing character variants.
3. A method for using a zone’s character variants to determine which
names should be associated with a registration.
4. A format for publishing a zone’s table of character variants;
Such tables are referred to below simply as "language tables" or
simply "tables".
5. A model algorithm for name registration given the presence of
language tables.
1.2. The Nature and Status of these Recommendations
The document makes recommendations for consideration by registries
and, where relevant, by those who coordinate them, and by those who
use their services. None of the recommendations are intended to be
normative. Instead, the intent of the document is to illustrate a
framework for developing variations to meet the needs of particular
registries and their processing of particular languages. Of course,
if registries make similar decisions and utilize similar tools, costs
and confusion may be reduced -- both between registries and for users
and registrars who have relationships with more than one domain.
Just as the JET Guidelines contain some suggestions that may not be
applicable to alphabetic scripts, some of the suggestions here,
especially the more specific ones, may be applicable to some scripts
and not others.
1.3. Terminology
1.3.1. Languages and Scripts
This document uses the term "language" in what may be, to many
readers, an odd way. Neither this specification, nor IDNA, nor the
DNS are directly concerned with natural language, but only with the
characters that make up a given label. In some respects, the term
"script", used in the character coding community for a collection of
characters, might be more appropriate. However, different subsets of
the same script may be used with different languages, and the same
language may be written using different characters (or even
completely different scripts) in different locations, so "script" is
not precisely correct either.
Long-standing confusion has also resulted from the fact that most
scripts are, informally at least, named after one of the languages
written in them. "Chinese" describes both a language and a
collection of characters that are also used in writing Japanese,
Korean, and, at least historically, some other languages. "Latin"
describes a language, the characters used to write that language,
and, often, characters used to write a number of contemporary
languages that are derived from or similar to those used to write the
Latin language. The script used to write the Arabic language is
called "Arabic", but it is also used (typically with some additions
or deletions) to write a number of other languages. Situations in
which a script has a clearly-defined name that is independent of the
name of a language are the exception, rather than the rule; examples
include Hangul, used to write Korean, Katakana and Hiragana, used to
write Japanese, and a few others. Some scholars have historically
used "Roman" or "Roman-derived" for the script in an attempt to
distinguish between a script and the Latin language.
The term "language" is therefore used in this document in the
informal sense of a written language and is defined, for this
purpose, by the characters used to write it, i.e., as a language-
specific subset of a script. In this context, a "language" is
defined by the combination of a code (see Section 1.4.1) and an
authority that has chosen to use that code and establish a
character-listing for it. Authorities are normally TLD (top-level
domain) registries; see Section 7 and [IANA-language-registry].
However, it is expected that TLD registries will find appropriate
experts and that advice from language and script experts selected by
international neutral bodies will also become part of the
registration system. In addition, as discussed below in Section 7,
registries may conclude that the best interests of registrants,
stakeholders, and the Internet community would be served by
constructing "language tables" that mix scripts and characters in
ways that conform to no known language. Conventions should be
developed for such registrations that do not misleadingly reflect
specific language codes.
1.3.2. Characters, Variants, Registrations, and Other Issues
1. Characters in this document are specified by their Unicode
codepoints in U+xxxx format, by their official names, or both.
2. The following terms are used in this document.
* String
A "string" is an sequence of one or more characters.
* Base Character
This document discusses characters that may have equivalent or
near-equivalent characters or strings. A "base character" is
a character that has zero or more equivalents. In the JET
Guidelines, base characters are referred to as "valid
characters". In a table with variants, as described in
Section 5, the base characters occupy the first column.
Normally (and always, if the recommendation of Section 6.3 is
adopted), the base characters will be the characters that
appear in registration requests from registrants; any other
character will invalidate the registration attempt.
* Native Script
Native script is the form in which the relevant string would
normally be represented. For example, it might use Lower
Slobbovian characters and the glyphs normally used to write
them. It would not be punycode as a presentation form.
* Variant Characters/Strings
The "variant(s)" are character(s) and/or string(s) that are
treated as equivalent to the base character. Note that these
might not be exactly equivalent characters; a particular
original character may be a base character with a mapping to a
particular variant character, but that variant character may
not have a mapping to the original base character. Indeed,
the variant character may not appear in the base character
list, and hence may not be valid for use in a registration.
Usually, characters or strings to be designated as variants
are considered either equivalent or sufficiently similar (by
some registry-specific definition) that confusion between them
and the base character might occur.
* Base Registration
The "base registration" is the single name that the registrant
requested from the registry. The JET Guidelines use the term
"label string" for this concept.
* Registered, Activated
A label (or "name") is described as "registered" if it is
actually entered into a domain (i.e., into a zone file) by the
registry, so that it can be accessed and resolved using
standard DNS tools. The JET Guidelines describe a
"registered" label as "activated". However, some domains use
a slightly different registration logic in which a name can be
registered with the registrar (if one is involved) and with
the registry, but not actually entered into the zone file
until an additional activation or delegation step occurs.
This document does not make that distinction, but is
compatible with it.
As specified in the IDNA Standard, the name actually placed in
the zone file is always the internal ("punycode") form. There
is no provision for actually entering any other form of an IDN
into the DNS. It remains controversial, with different
registrars and registries having adopted different policies,
as to whether the registration, as submitted by the
registrant, is in the form of:
o The native-script name, either in UTF-8 or in some coding
specified by the registrar, or
o the internal-form ("punycode") name, or
o both forms of the name together, so that the registrar and
registry can verify the intended translation.
If any of the approaches defined in this document is used, it
is almost certain to be necessary that the native-script form
of the requested string be available to the registry.
* Registration Bundle
A "registration bundle" is the set of all labels that come
from expanding the base characters for a single name into
their variants. The presence of a label in a registration
bundle does not imply that it is registered. In the JET
Guidelines, a registration bundle is called an "IDN Package".
* Reserved Label
A "reserved label" is a label in a registration bundle that is
not actually registered.
* Registry"
A "registry" is the administrative authority for a DNS zone.
The registry is the body that enforces, and typically makes,
policies that are used in a particular zone in the DNS.
* Coded Character Set
A "Coded Character Set" (CCS) is a list of characters and the
code positions assigned to them. ASCII and Unicode are CCSs.
* Language
A "language" is something spoken by humans, independent of how
it is written or coded. ISO Standard 639 and IETF BCP 47 (RFC
3066) [RFC3066] list and define codes for identifying
languages.
* Script
A "script" is a collection of characters (glyphs, independent
of coding) that are used together, typically to represent one
or more languages. Note that the script for one language may
heavily overlap the script for another. This does not imply
that they have identical scripts.
* Charset
"Charset" is an IETF-invented term to describe, more or less,
the combination of a script, a CCS that encodes that script,
and rules for serializing encoded bytes that are stored on a
computer or transmitted over the network.
The last four of these definitions are redundant with, but
deliberately somewhat less precise than, the definitions in
[RFC3536], which also provides sources. The two sets of definitions
are intended to be consistent.
1.3.3. Confusion, Fraud, and Cybersquatting
The term "confusion" is used very generically in this document to
cover the entire range from accidental user misperception of the
relationship between characters with some characteristic in common
(typically appearance, sound, or meaning) to cybersquatting and
(other) deliberately fraudulent attempts to exploit those
relationships based on the nature of the characters.
1.4. A Review of the JET Guidelines
1.4.1. JET Model
In the JET Guidelines model, a prospective registrant approaches the
registry for a zone (perhaps through an intermediate registrar) with
a candidate base registration -- a proposed name to be registered --
and a list of languages in which that name is to be interpreted. The
languages are defined according to the fairly high-resolution coding
of [RFC3066] or, if the registry considers it more appropriate, a
coding based on scripts such as those in [LTRU-Registry]. In this
way, Chinese as used on the mainland of the People’s Republic of
China ("zh-cn") can, at registry option, consist of a somewhat
different list of characters (code points) and be represented by a
separate table compared to Chinese as used in Taiwan ("zh-tw").
The design of the JET Guidelines took one important constraint as a
basis: IDNA was treated as a firm standard. A procedure that
modified some portion of the IDNA functions, or was a variant on
them, was considered a violation of those standards and should not be
encouraged (or, probably, even permitted).
Each registry is expected to construct (or obtain) a table for each
language it considers relevant and appropriate. These tables list,
for the particular zone, the characters permitted for that language.
If a character does not appear as a base character (called a "valid
code point" in the JET document) in that table, then a name
containing it cannot be registered. If multiple languages are listed
for the registration, then the character must appear in the tables
for each of those languages.
The tables may also contain columns that specify alternate or variant
forms of the valid character. If these variants appear, they are
used to synthesize labels that are alternatives to the original one.
These labels are all reserved and can be registered or "activated"
(placed into the DNS) only by the action or request of the original
registrant; some (the "preferred variant labels") are typically
registered automatically. The zone is expected to establish
appropriate policies for situations in which the variant forms of one
label conflict with already-reserved or already-registered labels.
Most of these concepts were introduced because of concerns about
specific issues with CJK characters, beginning from the requirement
that the use of Simplified Chinese by some registrants and
Traditional Chinese by others not be permitted to create confusion or
opportunities for fraud. While they may be applicable to registry
tables constructed for alphabetic scripts, the translation should be
done with care, since many analogies are not exact.
Some of the important issues are discussed in the sections that
follow, especially Section 3. The JET model may be considered as a
variation on, and inspiration for, the model and method presented by
the rest of this document, although the JET model has been completely
developed only for CJK characters. Other languages or scripts,
especially alphabetic ones, may require other variations.
1.4.2. Reserved Names and Label Packages
A basic assumption of the JET model is that, if the evolution of
specific characters or the properties of Unicode [Unicode]
[Unicode32] or IDNA cause two strings to appear similar enough to
cause confusion, then both should be registered by the same party or
one of them should become unregisterable. The definition of "appear
similar enough" will differ for different cultures and circumstance,
and hence DNS zones, but the principle is fairly general. In the JET
model, all of the variant strings are identified, some are registered
into the DNS automatically, and others are simply reserved and can be
registered, if at all, only by the original registrant. Other zones
might find other policies appropriate. For example, a zone might
conclude that having similar strings registered in the DNS was
undesirable. If so, the list of variant strings would be used only
to build a list of names that would be reserved and prohibited from
being registered.
1.5. Languages, Scripts, and Variants
1.5.1. Languages versus Scripts
Conversations about scripts -- collections of characters associated
with particular languages -- are common when discussing character
sets and codes. However, the boundaries between one script and
another are not well-defined. The Unicode Standard ([Unicode],
[Unicode32]), for example, does not define script boundaries at all,
even though it is structured in terms of usually-related blocks of
characters. The issue is complicated by the common origin of most
alphabetic scripts in use in the world today (see, for example,
[Drucker] or the more scholarly [Daniels]).
Because of that history, certain characters (or, more precisely,
symbols representing characters) appear in the scripts associated
with multiple languages, sometimes with very different sounds or
meanings. This differs from the CJK situation in which, if a
character appears in more than one of the relevant languages, it will