kept synchronized. The oft-suggested proposal to adopt an "exactly
one extra domain for each country" rule would essentially require
some of the multiple-official-language countries to violate their own
constitutions. Conversely, having multiple domains for a given
country, based on the number of official languages and without any
expectation of synchronization, would give some countries an
additional allocation of TLDs that others would certainly consider
unfair.
Of course, having replicated domains might be popular with some
registries and registrars, since replication would almost inevitably
increase the total number of domains to be registered. Helping that
group of registries and registrars, while hurting Internet users by
adding administrative overhead and confusion, is not a goal of this
document.
3.3. User Understanding of Local and Global References
While the IDNA tables (actually Nameprep [RFC3491] and Stringprep
[RFC3454]) must be identical globally for IDNA to work reliably, the
tables for mapping between local names and TLD names could be locally
determined, and differ from one locale to another, as long as users
understood that international interchange of names required using the
standard forms. That understanding puts some additional burden of
learning on users, although part of it could be assisted by software
(see Section 4).
In any event, at least in the foreseeable future, it is likely that
DNS names being passed among users in different countries, or using
different languages, will be forced to be in punycode form to
guarantee compatibility, since those users would not, in general,
have the ability to read each other’s scripts or have appropriate
input facilities (keyboards, etc.) for then. So the marginal
knowledge or effort needed to put TLD names into standard form and
transmit them in that way would actually be fairly small.
3.4. Limits on Expansion of the Number of TLDs
The concept of using local translation does have one side effect that
some portions of the Internet community might consider undesirable.
The size and complexity of translation tables, and maintaining those
tables, will be, to a considerable extent, a function of the number
of top-level domains of interest, the frequency with which new
domains are added, and the number of domains added at a time. A
country or other locale that wished to maintain a complete set of
translations (i.e., so that every TLD had a representation in the
local language) would presumably find setting up a table for the
current collection of a few hundred domains to be a task that would
take some days. If the number of TLDs were relatively stable, with a
relatively small number being added at infrequent intervals, the
updates could probably be dealt with on an ad hoc basis. But, if
large numbers of domains were added frequently, or if the total
number of TLDs became very large, maintaining the table might require
dedicated staff if each new TLD is to be accommodated. Worse,
updating the tables stored on client machines might require update
and synchronization protocols and all of the complexities that tend
to go with them (see [RFC3696] for a discussion of some related
issues in applications).
In practice, there will be little requirement to translate every TLD
into a local language. There are already existing TLDs for which
there is no obvious translations in many languages (most notably,
".arpa") or where the translation will be far from obvious to typical
users (for example, ".int" and ".aero"). Of course, these could be
translated by function: ".arpa" to the local term for
"infrastructure", ".int" with "international" or "international
organization", ".aero" with "aeronautical" or "airlines", and so on;
but it is not clear whether doing so would have significant value.
For almost every language, there are dozens of ccTLDs for which there
are no translations of the country names into the local language that
would be known by anyone other than geographers. If new TLDs are
added, there might not be a strong need (or even capability) to have
language-specific equivalents for each.
3.5. Standardization of the Translations
An immediate question when proposals such as this one are considered
is whether the names for the various TLDs that do not match the
strings that are actually in the DNS should be standardized and, if
so, by what mechanism. Standardization would promote communication
within a country or among people sharing a language. However, it is
likely to be very difficult to reach appropriate international
agreements to which wide conformance could be expected. Exceptions
might arise within particular countries or language groups but, even
then, there might be advantages to users being able to specify
additional synonymous names that are easy for them to remember. As
with IDNA-based IDNs, users who wish to transmit information about
domain names to people whose exact capabilities and software are
unknown, and to do so with minimal risk of confusion, will probably
confine themselves to the names that actually appear in the DNS,
i.e., the "punycode" representations.
In any event, neither standardization nor uniform use of either the
system outlined here or of a specific collection of names is required
to make the system work for those who would find it useful.
Similarly, mechanisms for country-wide coordination, and examination
of the appropriateness or inappropriateness of such mechanisms, is
beyond the scope of this document.
3.6. Implications for Future New Domain Names
Applications that implement the proposal in this document are likely
to make the subsequent creation and acceptance of new IDNA-based TLDs
significantly more difficult. If this proposal becomes widely
adopted, local language names mapped as it suggests will be generally
expected by users of those languages to mean the same as a current
TLD. Creating a new, stand-alone IDNA-based TLD will then require
more deliberation and care to avoid conflicts and, when executed,
will require all the application software that maps the name to the
existing TLD to change the mapping tables.
For several reasons, this problem may not be as serious in practice
as it might first appear. For ccTLDs allocated according to the ISO
3166-1 list, there will presumably be no problem at all: not only are
the 3166-1 alpha-2 codes strictly in ASCII, but general trends, such
as those embodied in ICANN’s "GAC Recommendations" against using
country names or codes for any purpose not associated with those
specific countries, make conflicts with internationalized names
extremely unlikely. Because the DNS does not currently have a usable
aliasing function (see Section 1.3.2), it is likely that new IDNA-
based TLDs will be allocated only after there is considerable
opportunity for countries and other individual entities to identify
any problems they see with proposed new names.
3.7. Mapping for TLDs, Not Domain Names or Keywords
It should be clear to anyone who has read this far that the mapping
described in this document is limited to TLDs, not full domain names
or keywords. In particular, nothing here should be construed as
applying to anything other than TLDs, due at least in part to the
limitations described in Section 3.1. Further, this document is only
about the domain name system (DNS), not about any keyword system.
The interactions between particular keyword systems and the proposals
here are left as a (possibly very difficult) exercise for the reader
or implementer of such systems. However, for the subset of such
systems whose intent is to entirely hide DNS names or URIs from the
user, their output would presumably be the LDH names that actually
appeared in the DNS, i.e., in punycode form for IDNA names and
without any application processing of the type contemplated here.
4. Information Interchange, IDNs, Comparisons, and Translations
This specification is based on a pair of fairly explicit assumptions.
The first is that the greatest and most important impact and value of
any internationalization or localization technique is to permit users
who share a language or culture to communicate with others who also
share that language or culture. Communication among users from
different cultures, using different languages or different scripts is
inherently more difficult, and still more difficult if they cannot
easily identify languages and scripts in common. The reason for
those difficulties are age-old issues in language translation and
differences among languages and scripts, not problems associated with
the DNS or IDNs, however they are represented. That is the second
assumption: when communication across language or cultural groups is
required, the users who need to do it -- typically a much smaller
number than those communicating within the same language and culture
-- are going to need to rely on commonly-understood languages and
scripts and will need to exert somewhat more care and effort than
within their own groups.
As outlined in the sections above, the suggestions made in this
document could clearly be turned into major problems by misuse or
misunderstanding. For example, if two applications on the same host
used different translation tables, a situation could easily result
that would be very confusing to the user. However, in some cases,
this would be only slightly worse than some of the alternatives. For
example, if, on a given system, IDNs are expressed in native script,
but ASCII TLD names are used, cutting and pasting from one
application to another may not work as expected, unless both
applications and the underlying operating system are all Unicode-
based and use the same encoding model for Unicode. Some applications
writers have already discovered, even without significant use of
IDNs, that they need to support separate "copy string" and "copy link
location", and the corresponding "paste" operations. Any use of IDNs
or Internationalized Resource Identifiers (IRIs, see [RFC3987]) may
require similar operations, or extensions to those operations, to
force strings into internal ("punycode" or URI) form on the copy
operation and to translate them back on paste. Were that done, the
appropriate translations could be performed as part of the same
process. If this author’s hypothesis is correct -- that these
operations are likely to be required on many systems whether this
proposal is adopted or not -- then the additional translation
operations are likely to be invisible to the user.
In particular, precisely because the translated names proposed here
are part of a presentation form, rather than the internal form names,
they are inappropriate in a number of circumstances in which a
globally-unique, internal-form name is actually required. It would
be a poor, indeed dangerous, idea to use these names in security
contexts such as names in certificates, access lists, or other
contexts in which accurate comparisons are necessary.
A more general issue exists when DNS or IRI references are
transferred among users whose systems may be localized for different
languages or conventions. In general, a user in one part of the
world will not actually know how another user’s systems are set up,
precisely what software is being used, etc., nor should users be
expected or forced to learn that information. But, if the user
transmitting an internationalized reference doesn’t know that the
receiving system supports the same characters and fonts, and that the
receiving user is prepared to deal with them, the prudent user will
transmit the internal form of the reference in addition to, or even
instead of, the native-character form. And, of course, if the
reference is transmitted on paper, on a sign, in some coded character
set other than Unicode, or even as an image, rather than as a Unicode
string, the importance of supplementing it with the internal form
becomes even more important. The addition of a translation
requirement for TLD labels makes availability of internal forms in
interchange significantly more important, but does not actually
change the requirement to do so.
It may be helpful to note that, in a different networking model than
that used in the Internet, both this proposal and IDNA itself are
essentially "presentation layer" approaches rather than constructions
that can be expected to work well in interchange.
5. Internationalization Considerations
This entire specification addresses issues in internationalization
and especially the boundaries between internationalization and
localization and between network protocols and client/user interface
actions.
6. Security Considerations
IDNA provides a client-based mechanism for presenting Unicode names
in applications while passing only ASCII-based names on the wire. As
such, it constitutes a major step along the path of introducing a
client-based presentation layer into the Internet. Client-based
presentation layer transformations introduce risks from non-
conforming tables that can change meaning without external
protection. For example, if a mapping table normally maps A onto C,
and that table is altered by an attacker so that A maps onto D
instead, much mischief can be committed. On the other hand, these
are not the usual sort of network attacks: they may be thought of as
falling into the "users can always cause harm to themselves"
category. The local translation model outlined here does not
significantly increase the risks over those associated with IDNA, but
may provide some new avenues for exploiting them.
Both this approach and IDNA rely on having updated programs present
information to the user in a very different form than the one in
which it is transmitted on the wire. Unless the internal (wire) form
is always used in interchange, or at least made available when DNS
names are exchanged, there are possibilities for ambiguity and
confusion about references. As with IDNA itself, if only the "wire"
form is presented, the user will perceive that nothing of value has
been done, i.e., that no internationalization or localization has
occurred. So presentation of the "wire" form to eliminate the
potential ambiguities is unlikely to be considered an acceptable
solution, regardless of its security advantages.
If the translation tables associated with the technique suggested
here are obtained from a server, or translations are obtained from a
remote machine using some protocol, the mechanisms used should ensure
that the values received are authentic, i.e., that neither they, nor
the query for them, have been intercepted and tampered with in any
way.
7. Acknowledgements
This document was inspired by a number of conversations in ICANN,
IETF, MINC, and private contexts about the future evolution and
internationalization of top level domains. Unknown to the author,
but unsurprisingly (the general concept should be obvious to anyone
even slightly skilled in the relevant technologies), the concept has
been apparently developed independently in other groups but, as far
as this author knows, not written up for general comment.
Discussions within, and about, the ICANN IDN Committee were
particularly helpful, although several of the participants in that
committee may be surprised about where those discussions led. Email
correspondence with several people after the first version of this
document was posted, notably Richard Hill, Paul Hoffman, Lee
XiaoDong, and Soobok Lee, led to considerable clarification in the
subsequent versions. The author is particularly grateful to Paul
Hoffman for extensive comments and additional text for the third
version and to Patrik Faltstrom, Joel Halpern, Sam Hartman, and Russ
Housley for suggestions incorporated into the final one.
The first version of this document was posted on October 21, 2002.
8. Informative References
[ISO10646] International Organization for Standardization,
"Information Technology - Universal Multiple-octet coded
Character Set (UCS) - Part 1: Architecture and Basic
Multilingual Plane", ISO Standard 10646-1, May 1993.
[ISO3166] International Organization for Standardization, "Codes for
the representation of names of countries and their
subdivisions -- Part 1: Country codes", ISO Standard
3166-1:1977, 1997.
[MIME] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
Mail Extensions): Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1341, June
1992.
Updated and replaced by Freed, N. and N. Borenstein,
"Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies", RFC2045, November
1996. Also, Moore, K., "Representation of Non-ASCII Text
in Internet Message Headers", RFC 1342, June 1992.
Updated and replaced by Moore, K., "MIME (Multipurpose
Internet Mail Extensions) Part Three: Message Header
Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1480] Cooper, A. and J. Postel, "The US Domain", RFC 1480, June
1993.
[RFC1591] Postel, J., "Domain Name System Structure and Delegation",
RFC 1591, March 1994.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
2672, August 1999.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[RFC3467] Klensin, J., "Role of the Domain Name System (DNS)", RFC
3467, February 2003.
[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.
[RFC3696] Klensin, J., "Application Techniques for Checking and
Transformation of Names", RFC 3696, February 2004.
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents:
Procedures", BCP 92, RFC 3932, October 2004.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
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 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.