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