2. the language (or script, if the registration is script-based, but
"language" is used for convenience below) for the proposed base
registration, and
3. the processing table associated with that language.
The output of the process is either failure (the base registration
cannot be registered at all), or a registration bundle that contains
one or more labels (always including the base registration). As
described earlier, the registration bundle should be stored with its
date of creation so that issues with overlapping elements between
bundles can later be resolved on a first-come, first-served basis.
There are two steps to processing the registration:
1. Check whether the proposed base registration exists in any
bundle. If it does, stop immediately with a failure.
2. Process the base registration with the mechanism described as
"CreateBundle" in Section 6.1, below.
Note that the process must be executed only once. The process must
not be performed on any output of the process, only on the proposed
base registration.
6.1. Description of the CreateBundle Mechanism
The CreateBundle mechanism determines whether a registration bundle
can be created and, if so, populates that bundle with valid labels.
During the processing, a "temporary bundle" contains partial labels,
that is, labels that are being built and are not complete labels.
The partial labels in the temporary bundle consist of strings.
The steps are:
1. Split the base registration into individual characters, called
"candidate characters". Compare every candidate character
against the base characters in the table. If any candidate
character does not exist in the set of base characters, the
system must stop and not register any names (that is, it must not
register either the base registration or any labels that would
have come from character variants).
2. Perform the steps in IDNA’s ToASCII sequence for the base
registration. If ToASCII fails for the base registration, the
system must stop and not register any label (that is, it must not
register either the base registration or labels that might have
been created from variants of characters contained in it). If
ToASCII succeeds, place the base registration into the
registration bundle.
3. For every candidate character in the base registration, do the
following:
o Create the set of characters that consists of the candidate
character and any variants.
o For each character in the set from the previous step,
duplicate the temporary bundle that resulted from the previous
candidate character, and add the new character to the end of
each partial label.
4. The temporary bundle now contains zero or more labels that
consist of Unicode characters. For every label in the temporary
bundle, do the following:
o Process the label with ToASCII to see if ToASCII succeeds. If
it does, add the label to the registration bundle. Otherwise,
do not process this label from the temporary bundle any
further; it will not go into the registration bundle.
The result of the processing outlined above is the registration
bundle with the base registration and possibly other labels.
6.2. The "no-variants" Case
It is clear that, for many scripts, registries will choose to create
tables without variants, either because variants are clearly not
necessary or because they are determined to cause more confusion and
overhead than is justified by the circumstances. For those
situations the table model of Section 5 becomes a trivial listing of
base characters and only the first two steps of CreateBundle
(verifying that all candidate character are in the base ("valid")
character list and verifying that the resulting characters will
succeed in the ToASCII operation) are applicable. Even the second of
those steps becomes pro forma if the advice in the next subsection is
followed.
6.3. CreateBundle and Nameprep Mapping
One of the functions of Nameprep, and IDNA more generally, is to map
a large number of Unicode characters (code points) into a smaller
number to avoid a different but overlapping set of confusion
problems. For example, when a non-ASCII script makes distinctions
between "upper case" and "lower case", nameprep maps the upper case
characters to the lower case ones in order to simulate the DNS
protocol’s rule that ASCII characters are interpreted in a case-
insensitive way. Unicode also contains many code points that are
typographic variants on each other (e.g., forms with different widths
and code points that designate font variations for mathematical
uses), the Unicode standard explicitly identifies them that way, and
Nameprep maps these onto base characters.
While having these mapping functions available during lookup may be
quite helpful to users who type equivalent forms, registrations are
probably best performed in terms of the IDNA base characters only,
i.e., those characters that nameprep will not change. This will have
two advantages.
o Registrants will never find themselves in the rather confusing
position of having submitted one string for registration and
finding a different string in the registry database (which could
otherwise occur even if the relevant language table does not
contain variants).
o Those who are interested in what characters are permitted by a
given registry will only need to examine the relevant tables,
rather than simulating the IDNA algorithm to determine the result
of processing particular characters.
7. IANA Considerations
Under ICANN (not IETF) direction and management, the IANA has created
a registry for language variant tables. The authoritative
documentation for that registry is in [IANA-language-registry].
Since the registry exists and is being managed under ICANN direction,
the material that follows is a review of the theory of this registry,
rather than new instructions for IANA.
As described above and suggested in the JET Guidelines, the
registration rules generally require only that:
o The application be submitted or endorsed by a TLD registry, to
ensure that someone cares about the particular table.
o The table be identified by the following:
* the name -- usually the top-level domain name -- of the
submitting or endorsing registry;
* one of: a language designation (consistent with [RFC3066] or
with some other system approved by the IANA), a script
designation, a combination of the two, or a sequence number
acceptable to IANA for this purpose;
* a version number; and
* a date.
o Characters listed in the table be identified by Unicode code
points, as discussed above.
o The table format may correspond to that identified in [RFC3743],
or in Section 5 above, or may be some variation on those themes
appropriate to the local processing model (with or without
variants).
This raises some issues that will need to be worked out as
experiences accumulate. For example, more standardization of table
formats would be desirable to allow processing by the same computer
tools for different registries and languages. But standardization
seems premature at this time due to differences in languages,
processing, and requirements and lack of experience with them.
Similarly, if a registry concludes that it should use a table that
contains characters from several scripts, it is not clear how such a
table should be designated. Identifying it with a language code
(either according to [RFC3066] or an independent code registered with
IANA) is likely to just introduce more confusion, especially given
other Internet uses of the language codes. It appears that some
other convention will be needed for those cases, and it should be
developed (if it has not already been established by the time this
document is published).
8. Internationalization Considerations
This document specifies a model mechanism for registering
Internationalized Domain Names (IDNs) that can be used to reduce
confusion among similar-appearing names. The proposal is designed to
facilitate internationalization while permitting a balance between
internationalization concerns and concerns about keeping the Internet
global and domain name system references unique in the perception of
the user as well as in practice.
9. Security Considerations
Registration of labels in the DNS that contain essentially
unrestricted sequences of arbitrary Unicode characters may introduce
opportunities for either attacks or simple confusion. Some of these
risks, such as confusion about which character (of several that look
alike) is actually intended, may be associated with the presentation
form of DNS names. Others may be linked to databases associated with
the DNS, e.g., with the difficulty of finding an entry in a "Whois
file" when it is not clear how to enter or to search for the
characters that make up a name. This document discusses a family of
restrictions on the names that can be registered. Restrictions of
the type described can be imposed by a DNS zone ("registry"). The
document also describes some possible tools for implementing such
restrictions.
While the increased number and types of characters made available by
Unicode considerably increases the scale of the potential problems,
the problems addressed by this document are not new. No plausible
set of restrictions will eliminate all problems and sources of
confusion: for example, it has often been pointed out that, even in
ASCII, the characters digit-one ("1") and lower case L ("l") can
easily be confused in some display fonts. But, to the degree to
which security may be aided by sensible risk reduction, these
techniques may be helpful.
10. Acknowledgements
Discussions in the process of developing the JET Guidelines were
vital in developing this document and all of the JET participants are
consequently acknowledged. Attempts to explain some of the issues
uncovered there to, and feedback from, Vint Cerf, Wendy Rickard, and
members of the ICANN IDN Committee were also helpful in the thinking
leading up to this document.
An effort by Paul Hoffman to create a generic specification for
registration restrictions of this type helped to inspire this
document, which takes a somewhat different, more language-oriented,
approach than his initial draft. While the initial version of that
draft indicated that multiple languages (or multiple language tables)
for a single zone were infeasible, more recent versions [Hoffman-reg]
shifted to inclusion of language-based approaches. The current
version of this document incorporates considerable text, and even
more ideas, from those drafts, with Paul Hoffman’s generous
permission.
Feedback was provided by several registry operators (of both country
code and generic TLDs), including Edmon Chung and Ram Mohan of
Afilias, and by ICANN and IANA staff, notably Tina Dam and Theresa
Swinehart. This feedback about issues encountered in registering
tables and designing IDN implementations resulted in the addition of
significant clarifying text to the current version of the document.
The opinions expressed here are the sole responsibility of the
author. Some of those whose ideas and comments are reflected in this
document may disagree with the conclusions the author has drawn from
them. The first draft version of this document was posted in June
2003.
11. Informative References
[Daniels] P.T. Daniels and W. Bright, The World’s Writing
Systems, Oxford: Oxford University Press: 1996.
[Drucker] Drucker, J., "The Alphabetic Labyrinth: The Letters in
History and Imagination", 1995.
[Hoffman-reg] Hoffman, P., "A Method for Registering
Internationalized Domain Names", Work in Progress,
October 2003.
[IESG-IDN] Internet Engineering Steering Group, IETF, "IESG
Statement on IDN", IESG Statement available from
http://www.ietf.org/IESG/STATEMENTS/IDNstatement.txt,
February 2003.
[ICANN-IDN] Internet Corporation for Assigned Names and Numbers
(ICANN), "Guidelines for the Implementation of
Internationalized Domain Names, Version 1.0", June
2003.
[ICANN-IDN2] Internet Corporation for Assigned Names and Numbers
(ICANN), "Guidelines for the Implementation of
Internationalized Domain Names, Version 2.0", September
2005.
[IANA-language-registry]
Internet Assigned Numbers Authority (IANA), "IDN
Language Table Registry", April 2004.
[LTRU-Registry]
Phillips, A., Ed. and M. Davis, Ed., "Tags for
Identifying Languages", Work in Progress, October 2005.
[RFC952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD
Internet host table specification", RFC 952, October
1985.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)", RFC
3491, March 2003.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of
Unicode for Internationalized Domain Names in
Applications (IDNA)", RFC 3492, March 2003.
[RFC3536] Hoffman, P., "Terminology Used in Internationalization
in the IETF", RFC 3536, May 2003.
[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.
[Unicode] The Unicode Consortium, "The Unicode Standard --
Version 3.0", January 2000.
[Unicode32] The Unicode Consortium, "Unicode Standard Annex #28:
Unicode 3.2", March 2002.
Author’s Address
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78 and at www.rfc-editor.org/copyright.html, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.