draft-klensin-idn-tld-00.txt

bind-3.2.

INTERNET-DRAFT                             John C Klensin
21 October 2002
Expires April 2003

			 National and Local Characters in DNS TLD Names
					  draft-klensin-idn-tld-00.txt

Status of this Memo

	This document is an Internet-Draft and is in full conformance
	with all provisions of Section 10 of RFC2026 except that the
	right to produce derivative works is not granted.

	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 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.
	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.


Abstract

   In the context of work on internationalizing the Domain Name System
   (DNS), there have been extensive discussions about "multilingual" or
   "internationalized" top level domain names (TLDs), especially for
   countries whose predominant language is not written in a Roman-based
   script.  This document reviews some of the motivations for such
   domains and the constraints that the DNS imposes.  It then suggests
   an alternative, local translation, that may solve a superset of the
   problem while avoiding protocol changes, serious deployment delays,
   and other difficulties.

Table of Contents

1 Introduction
1.1 Background on the "Multilingual Name" Problem
1.2 Domain Name System Constraints
1.3 Internationalization and Localization
2. Client-side solutions
2.1 IDNA and the client
2.2 Local translation tables for TLD names
3. Advantages and disadvantages of local translation
3.1 Every TLD in the local language and character set

3.2 Unification of country code domains
3.3 User understanding of local and global reference
3.4 Limits on TLD propagation
4. Security Considerations
5. References
6. Acknowledgements
7. Author's Address


1. Introduction

1.1 Background on the "Multilingual Name" Problem

People who share a language prefer to communicate in it, using whatever
characters are normally used to write that language, rather than in some
"foreign" one.  There have been standards for using mutually-agreed
characters and languages in electronic mail message bodies and selected
headers since the introduction of MIME in 1992 [MIME] and the Web has
permitted multilingual text since its inception.  However, since domain
names are exposed to users in email addresses and URLs, and
corresponding arrangements in other protocols, demand rapidly arose to
permit domain names in applications that used characters other than
those of the very restrictive, ASCII-subset, "LDH" conventions [LDH].
The effort to do this rapidly became known as "multilingual domain
names", although that is a misnomer, since the DNS deals only with
characters and identifier strings, and not, except by accident, what
people usually think of as "names".  And there has been little actual
interest in what would actually be a "multilingual name" -- i.e., a name
that contains components from more than one language -- but only the use
of strings conforming to different languages in the context of the DNS.

1.1.1 Approaches to the requirement

If the requirement is seen, not as "modifying the DNS", but as
"providing users with access to the DNS from a variety of languages and
character sets", three sets of proposals have emerged in the IETF and
elsewhere.  They are:

   (1) Perform processing in client software that recodes a user-visible
   string into an ASCII-compatible form that can safely be passed
   through the DNS protocols and stored in the DNS.  This is the
   approach used, for example, in the IETF's "IDNA" protocol [IDNA].

   (2) Modify the DNS to be more hospitable to non-ASCII names and
   strings.  There have been a variety of proposals to do this in almost
   as many ways, some of which have been implemented on a proprietary
   basis by various vendors.  None of them have gained acceptance in the
   IETF community, primarily because they would take a long time to
   deploy and would leave many problems unsolved.

   (3) Move the problem out of the DNS entirely, relying instead on a
   "directory" or "presentation" layer to handle internationalization.
   The rationale for this approach is discussed in [DNSROLE].

This document proposes a fourth approach, applicable to the top level
domains (TLDs) only (see section 1.2.1 for a discussion of the special
issues that make TLDs problematic).  That approach could be used as an
alternate or supplement to the strategies summarized above.


1.1.2 Writing the name of one's country in its own characters

An early focus of the "multilingual domain name" efforts was expressed
in statements such as "users in my country, in which ASCII is rarely
used, should be able to write an entire domain name in their own
character set.  In particular, since all top-level domain names, at
present, follow the LDH rules, the somewhat more restrictive naming
rules discussed in [STD3], and the coding conventions specified in
[RFC1591], all fully-qualified DNS names were effectively required to
contain at least one ASCII label (the TLD name), and that was considered
inappropriate.  One should, instead, be able to write the name of the
ccTLD for China in Chinese, the name of the ccTLD for Saudi Arabia in
Arabic, and so on.

1.1.3 Countries with multiple languages and countries with multiple
     names

>From a user interface standpoint, writing ccTLD names in local
characters is a problem.  As discussed in section 1.2.2, the DNS itself
does not easily permit a domain to be referred to by more than one name
(or spelling or translation of a name).  Countries with more than one
official language would require that the country name be represented in
each of those languages.  And, just as it is important that a user in
China be able to represent the name of the Chinese ccTLD in Chinese
characters, she should be able to access a Chinese-language site in
France using Chinese characters, requiring that she be able to write the
name of the French ccTLD in those characters rather than in a form based
on a Roman character set.


1.2 Domain Name System Constraints

1.2.1 Administrative hierarchy

The domain name system is designed around the idea of an "administrative
hierarchy", with the entity responsible for a given node of the
hierarchy responsible for policies applicable to its subhierarchies (Cf.
[STD13]).  The model works quite well for the domain and subdomains of a
particular enterprise, where the hierarchy can be organized to match the
organizational structure, there are established ways to set policies and
there is, at least presumably, shared assumptions about overall goals
and objectives among all registrants in the domain.  It is more
problematic when a domain is shared by unrelated entities which lack
common policy assumptions.  It is difficult to reach agreement on rules
that should apply to all of them.  That situation always prevails for
the labels registered in a TLD (second-level names) except in those TLDs
for which the second level is structural (e.g., the .CO, .AC, .GOV
conventions in many ccTLD) in which case, it exists for the labels
within that structural level.

TLDs may, but need not, have consistent registration policies for those
second (or third) level names.  Countries (or ccTLD administrators) have
often adopted rules about what entities may register in those ccTLDs,
and the forms the names may take.  RFC 1591 outlined registration norms
for most of the gTLDs, even though those norms have been largely ignored
in recent years. And some recent "sponsored" domains are based on quite
specific rules about appropriate registrations.  Homogeneous

registration rules for the root are, by contrast, impossible: almost by
definition, the subdomains registered in it are diverse and no single
policy applying to all root subdomains (TLDs) is feasible.

1.2.2 Aliases

In an environment different from the DNS, a rational way to permit
assigning local-language names to a country code (or other) domain would
be to set up an alias for the name, or to use some sort of "see instead"
reference.  But the DNS does not have quite the right facilities for
either.  Instead, it supports a "CNAME" record, whose label can refer
onto to a particular label and not to a subtree.  For example, if A.B.C
is a fully-qualified name, then a CNAME reference from X to A would make
X.B.C appear to have the same values as A.B.C.  However, a CNAME
reference from Y to C would not make A.B.Y referenceable (or even
defined) at all.  A second record type, DNAME [RFC2672], can provide an
alias for a portion of the tree.  But it is problematic technically, and
its use is strongly discouraged except for transition uses from one
domain to another.


1.3 Internationalization and Localization

It has often been observed that while many people talk about
"internationalization" (a term we typically use for making something
globally accessible while incorporating a broad-range "universal"
character set and conventions appropriate to all languages), they often really
mean, and want, "localization" (making things work well in a particular
locality, or well, but potentially differently, for a broad range of
localities).  Anything that actually involves the DNS must be global and
hence internationalized since the DNS cannot meaningfully support
different responses based, e.g., on the location of the user making a
query.   While the DNS cannot support localization internally, many of
the features discussed earlier in this section are much more easily
thought about in local terms --whether localized to a geographical area,
users of a language, or using some other criteria -- than in global ones.

2. Client-side solutions

Traditionally, the IETF has avoided becoming involved in standardization
for actions that take place strictly on individual hosts on the network,
assuming that it should confine itself to behavior that is observable