Re: [idn] Two Internet Drafts of possible interest

["Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>]

John C Klensin <klensin@jck.com> wrote:

> http://www.ietf.org/internet-drafts/draft-klensin-idn-tld-02.txt

Section 3.1:

> A user in Korea who can access the national ccTLD in the Korean
> language and character set has every reason to expect that both
> generic top level domains and domains associated with other countries
> would be similarly accessible, especially if the second-level domains
> bear Korean names.

If there are Korean labels registered under a France TLD, then users
would certainly benefit from being able to access those domains using a
Korean translation of ".fr".  I see no benefit in ensuring that French
or Chinese labels are accessible under the Korean translation of ".fr".
If a solution happens to make domains accessible under counter-intuitive
TLDs (via some sort of local or global aliasing), that's fine, but it
doesn't need to be a goal.

> That level of local optimization is not realistic -- some would
> argue not possible -- with the DNS since it would ultimately require
> that every top level domain be replicated for each of the world's
> languages.  That replication process would involve not just the top
> level domain itself: in principle, all of its subtrees would need to
> be completely replicated as well.

I don't see the benefit of replicating the subtrees.  If Korean and
Chinese translations of ".fr" exist, and if I have a server that I
want to be accessible via Korean and Chinese domain names, why would I
want to mix the Korean second-level label with the Chinese top-level
label, or vice-versa?  I only need two names, not four.  A solution that
automatically recognizes the mismatched names is okay, but a solution in
which the mismatched names don't exist is also okay.

The combinatorics might not be quite as bad as you expect, because new
TLDs might be introduced per script rather than per language.  Notice
that ".es" for Spain is not intuitive in English, but it's not too bad,
because English speakers are able to recognize and type the letters "e"
and "s", even if they don't understand the derivation of the spelling.
There are only 54 scripts in Unicode 4.0.

Currently, each TLD manager is encouraged to be cautious about admitting
new characters into the TLD registry, allowing new characters only
when the TLD manager has the expertise to set reasonable policies for
names using those characters.  In a similar spirit, we don't need to
encourage each TLD manager to create all 53 transcriptions of their
TLD immediately; they should roll them out gradually as they acquire
the necessary expertise.  Each new TLD would have its own policies
about what may be registered under it.  For example, .kr might allow
names using all Latin, Han, and Hangul characters; while the Hangul
transcription of .kr might allow only Hangul, Han, and ASCII; the Han
transcription of .kr might allow only Han, Hangul, Kana, and ASCII; and
the Cyrillic transcription of .kr might allow only Cyrillic and ASCII.
The non-ASCII TLDs might require at least one non-ASCII character in
the second-level label, so that registrants under the ASCII TLD don't
need to worry about squatters registering the same label under every
transcribed TLD.

Someone running a server (like a web server or mail server) with an
English name, a Korean name, a Chinese name, a Japanese name, and a
Russian name may need to maintain several zone files, but each name will
appear in only one zone file, not all of them.  If the TLDs were all
aliases of each other, then all the names could appear in one zone file;
having separate TLDs causes the zone data to be split among multiple
files, but not replicated.  (For backward compatibility, you might want
some labels to appear under both the ASCII TLD and the more intuitive
TLD, but that's a factor of 2, not N.)

I think the separate-TLD approach is feasible.  On the other hand, if
the aliased-TLD approach is preferred for whatever reason, then I would
encourage people to fix whatever problems might exist with DNAME, so
that the aliases are global rather than local.

> At least for 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 in any event, so the marginal knowledge or effort needed
> to put TLD names into standard form and transmit them that way would
> be very small.

As IDNA and Unicode become more widespread, the need to reveal the
Punycode will diminish, but the need to reveal the ASCII TLDs will not
diminish unless the TLD aliases are either frozen or put into the DNS
(presumably via DNAME).

AMC