Re: Two Internet Drafts of possible interest

Dear John, Adam,
I will put myself in a different perspective to address the ML.ML situation.
- there are 54 different scriptings supported where all the TLD may 
probably be trimmed down to a 100 maximum (ideally 54) scripts.
- there is one particular existing scripting made of "numbers" from 0 to Z 
and minus, supporting a non conflicting convertion function from the other 
53 scripting codes (punycode). (As per the common understanding of the word 
I name it "international", "internationalized domain names" are ML domain 
names which can be internationalized in 0-Z and backed ito their initial 
codes, using punycode).
- there is a low work on aliasing because NSI did not understand yet that 
helping hosting companies to support aliasing was multiplying DN sales. But 
there will be an increasing need for aliasing and complex host access 
address management with IPv6, new mail services, etc. and when other 
Registries understand the golden mine aliasing maybe for them.
- the DNS is not only Bind. What is important in all this is the protocol. 
The DNS back office can change, to support new management concepts and 
services, keeping or not flat db.files. As different existing tools show it.
- IDNA is going to ask for an IDNA module to be added to the applications 
or to the resolver. This module can do more.
- multilingual real life will _demand_ everything monolingual people tend 
to consider as unlikely. This is not questionable.

There are three key concepts to use.
1. virtual zones.
These zones correspond to a real life zone that does not match 
(smaller/larger) any DNS made zone. An example of virtual zone are all the 
aliases of a same domain - which can be of different level.

2. ULD (user level domain).
This is the set of naming solution(s) implemented by a virtual zone manager 
to identify his virtual registry in the different DNS visions it may use. 
He will most probably use the 0-Z name registered by the user as a referent 
within the ULD. Such a referent will be aliased in the different registries 
used to support the ULD. These registries may possibly be of different 
levels (see below the example).

3. when you look for he name of a foreign affiliate company you create; you 
prefer to use a marketing counsel than a translation table. It is trhe same 
for a DN. Once you registered a name in its 0-Z version, it should be your 
Administrative Registration Referent. You should then be able to alias it 
the way you want in other languages and scriptings. This means that the 
virtual zone should go by scripting and that a name registration may lead 
to several registrations (by language) in the same scripting. I accept this 
is not mathematic. But cybernetic is to autonomous systems what mathematics 
is to abstract systems and physics to inert systems. Real life is more 
complex than a table or than a single transcoding formula.

Let take my name Jean-François.
The referent 0-Z name will be jean-francois. If I want it to be registered 
in French in China, I will interface the Chinese French virtual zone 
registration Manager and will ask for "jean-françois" to be registered in 
the "fr_cn" ULD  and he will start registering "jean-francois.cn" as a 
referent, then turn to IDNA.

My ULD is well identified for me, for the .cn ccTLD Manager and for the 
users. However the IDNA system did not defined it. The problem is therefore 
to define the way the "fr_cn" ULD will be supported with the existing DNS 
(I do not think the DNS need to be changed in any way).

- first complex solution by IETF : IDNA
IDNA does not support virtual zones as in a way sender and receiver can 
identify them; but it supports them through a very complex system of 
inter-virtual zone conflict minimization.

- second solution: ULDs are supported as virtual TLDs.
This means that IDNA is used and the users have a conversion table between 
their scripting of .com and the 0-Z com. The risk of conflict remains the 
same as above since there is no link between the TLD and the SLD scripting.

- third solution: ULDs are supported as separated TLDs.
This means that less than 30.000 TLDs are created. There is no objection to 
that, except it is heavy to introduce. In this case there is no more 
possible conflict because SLDs will be registered in using a scripting 
related to the TLD.

- fourth solution: ULDs are supported in respecting the DNS rules,
This means that lingual virtual zones will be supported as sub-zones. This 
means that fr_cn will be supported via something like "xs--fr.cn" and my 
domain name will be (0-Z) "jean-francois.cn" and (ML) 
xn--jean-franxxois.xn--fr.cn (xx being a way to indicate that punycode has 
been applied) that I could enter or read in French as "jean-françois.fr-cn" 
or any other .CN decided format.

In the third and fourth case there is a transliteration between the ULD on 
my terminal and in the DNS. This should be supported by a DNS 
pre-resolution of the ULD (so, in using the DNS twice). One first time to 
resolve the entered ULD through a punnycoded call, ex: .fr-cn into 
xs--fr.cn (or any other adopted formula) and then to resolve a the full 
punnycoded 0-Z entry.

I note that:
- this is what we do all the time with the telephone. While an American 
people will dial 800 AVIS, Chinese will call 800 28 47.
- we will probably need to use the same ML resolution system for the LHS, 
to be able to call an Arabic mail address from an ASCII terminal, from a 
menu or from icons. In that case the name server will be on the mail server.
- this calls for a serious ergonomic work on DNS information management, 
using probably real time data bases (making DynamicDNS trivial). PoweDNS or 
NSD can support that already. I do not know about Atlas, but I suppose it 
may? There are some solutions using Bind already able to come with that 
requirements.

Since, the change is not in the DNS but in calling a resolution service 
twice (IMHO both can be supported by the DNS - cf. RFC 883). This means 
that the change only affects the user's side (resolver or application): a 
user system will be ML enabled or not, a decision by the user not a network 
revolution.
jfc



On 23:37 01/05/04, Adam M. Costello said:

>John C Klensin <[email protected]> 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