[idn] Re: About draft-idn-klensin-tld-00.txt

[John C Klensin <klensin@jck.com>]

--On Thursday, 24 October, 2002 18:06 +0900
"=?windows-1252?Q?=22=3F=3F=3F=40=3F=3F=3F=22?="
<shlee@netpia.com> wrote:

> Hello,
> 
> This is SeungHo Lee from netpia.com, Korea.
> 
> I have just finished reading your new I-D about idn-tld
> and there are some parts I want to know more specifically
> about this draft and your thoughts.

First of all, this draft is definitely _not_ an IDN WG work item
or topic.  I'm not quite sure why the I-D administrator posted
it to the WG's list, although I think it is reasonable that WG
members be aware of it.   It is strictly a client-side
suggestion, with significantly fewer "on the wire" or server
implications than IDNA and so is probably not even an
appropriate subject for formal IETF work.  It is not an IRNSS
topic either, although it is generally concerned with
Internationalization and the i18n/l10n boundary.  So, if people
want to discuss it, please take it to the intloc list if you
think that would be useful or just send me private mail, to
which I will try to respond if it is technical in nature, rather
than argumentative.  Please do not copy the IDN list on any
response to this note unless the co-Chairs make some suggestion
to the contrary.

> I hope you could have some time to answer this questions. :)
> 
> 1.
> Could you give me one simple example of local table for local
> translation you mentioned? Because I'm not sure 'to what' the
> local launguage is translated and what does the "translation"
> exactly means.

This applies only to TLD names.  So the target for translation
would be a TLD name.  I would expect that a local translation
table for use in Korea by speakers of the Korean language would
contain Korean names or mnemonics for each of the TLDs (or each
of the TLDs that were considered to be of interest), mapping
onto the public identifiers (ISO3166-1 codes or other top-level
DNS labels) for those TLDs.  I would expect that, in particular,
it would contain the name for South Korea as it is normally
written and used in your country, mapping onto .KR.  Similarly,
I would expect a table for use in, say, Spain for use by
Spanish-speakers, to contain names or mnemonics based on the
Spanish language.  So, a Korean table would typically contain
the names of the Spanish and Korean TLDs, and the generic TLDs,
in Korean, while a table for Spain would contain mappings
(translations) from Spanish for each of those domains.  And so
forth, for every language or language variant whose users
thought it was worth the trouble.

> Does the translation mean "encoding" translation (to
> ASCII-compatible)? Is is right that if embodied as you
> suggested in this draft there is no need to add new root
> servers?

No.  The term "translation" is used literally and in its normal
sense.  The Korean user would see the TLD name (label) as a
Korean name, in Korean characters, but the application would put
only the Roman-character-based global names of those TLDs, coded
as usual in ASCII, on the wire or into DNS interfaces.

> 2.
> You wrote in 1.1
> -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".
> 
> Like [DNSROLE] I could see you don't think DNS is not for
> human, but for machine. Namely, DNS is basically an identifier
> for machine, not for human... Am I right?

Yes, I still believe that.  But it has little to do with this
document.  If the DNS is to be used as a naming environment, we
must figure out how to internationalize it.  In accepting
Stringprep, the WG (and the IETF) have essentially concluded
that a significant amount of that work is best done client-side,
rather than sending, e.g., Unicode characters to a DNS server
and having it do all comparisons and other mappings.  But that
decision, in turn, makes it appropriate to ask the question of
what things can be better done by localization, rather than by
uniform global solutions.     The only "machines, not humans"
element of this is that the strings provided by, or presented
to, the users are not the strings that go on the wire.  But IDNA
already takes us to that point, so it is nothing new.

> 3.
> But there are a few opinions that domain names should reflect
> real entities and if they can't, there should be
> addresses(identifiers) for human in the Internet... How do you
> think about these opinions?

It depends somewhat on what, exactly, is meant by "real
entities".  My personal belief is that human-accessible naming
should be provided through some service with directory
capabilities including non-exact lookup, e.g., that outlined in
draft-klensin-dns-search-04.txt.   But, if people are going to
insist on trying to make the DNS accomodate human-friendly,
internationalized, naming, then I believe that we must find ways
to do that which are consistent with the way the DNS works and
is operated in practice.   Creation of additional ccTLDs for
each name by which a country is called (officially or otherwise)
seems to me to be unwise and largely inconsistent with the
structure of the DNS.  So I wanted to point out that there is a
plausible alternative, one that provides local naming for TLDs
while avoiding the need for many additional TLDs with largely
overlapping content.

> 4.
> And If you think domain names are not for human, I guess IDN
> is also not for human because it is just another form of
> current domain names. (It'll have the same hierarchical
> structure..) Am I right?

If you are trying to start an argument, this is not the place.
Let me only say that I consider the use of the DNS for
user-friendly names, and, especially, for "searching by
name-guessing" to be inappropriate and that the monohierarchical
structure is only part of the problem.  I believe it is
inappropriate for LDH-style names and inappropriate for
internationalized ones -- slightly more so for the latter
because the large character repertoire creates additional
"opportunities" for mischief and confusion.   At the same time,
I recognize that people want to encode non-ASCII names into the
DNS, if only to make host and resource identifers more
conveniently remembered. I believe we should do that well,
correctly, and safely.   

> 5.
> I think currentyl there are two problems about DNS.
> One is the linguistic problem - IDN parts.
> And Another one is about domain names' not representing real
> world entities...
> 
> I think you think that the first problem is to be solved
> through IDN ... (IDNA + this draft??) And the second one is to
> be solved by DNS-SEARCH you suggested before... Am I right?

I am not sure that I would draw the distinction quite that way,
but that may be just a difference in the language we are using.
I do not believe that IDN is a complete solution to
internationalization, even internationalization constrained to
work within the DNS.  I believe that, to be practical and to
avoid large amounts of confusion, IDNA is only part of the
"solution".   Other parts might include some localization
suggestions like this one and, probably more important, per-zone
or per-registry restrictions on what can actually be stored in a
zone.  The latter might possibly include some homogeneity rules
for scripts that will be commonly used in that domain and/or use
of Mark's suggestions about detection and reporting of
mixed-script labels.

regards,
    john