Katakana Middle Dot again (Was: tables-06b.txt: A.5, A.6, A.9)

John C Klensin klensin at jck.com
Sat Aug 8 14:07:50 CEST 2009



--On Friday, August 07, 2009 23:38 +0200 Elisabeth Blanconil
<eblanconil at gmail.com> wrote:

> Dear John,
> I do not understand some of your remarks.
> 
> 2009/8/7 John C Klensin <klensin at jck.com>:
>> 
>> 
>> --On Friday, August 07, 2009 22:13 +0200 Elisabeth Blanconil
>> Except that a "TLD table inheritance system" is impossible in
>> a DNS in which it is not, in the general case, possible to
>> tell which TLD a label is actually part of and in which a
>> given node can be effectively a subtree of multiple trees.
> 
> I am afraid "impossible" only means that some R&D is to be
> carried. Hence my allusion to RFC 3869.

No.  "Impossible" in this case means that, especially with
DNAMEs, doing resolution or matching with different rules based
on location in the tree is not possible without _very_
significant changes to the DNS, changes so significant that the
result would essentially be a new, replacement, DNS.   It is not
about minor tuning to IDNs or the equivalent.

>>> Was it not at a time a proposition by John Klensin?
>> Nope.
> 
> I refered to
> http://ietfreport.isoc.org/all-ids/draft-klensin-idn-tld-00.txt

Ah.  That proposal.  That proposal has nothing to do with this
discussion and is related to TLDs only.  It would not work lower
in the tree, even at the second level, and works for TLDs only
if IDN TLDs for countries (or country-like economics or other
entities) are prohibited entirely and, probably, that the number
of new TLDs of any type is significantly limited.  ICANN has
decided to go in the opposite direction.  I don't consider that
set of ICANN decisions wise, but, to paraphrase and update an
old American saying, my opinion and a few dollars will buy a cup
of coffee-flavored milk.

The summary of that proposal would be:

	(i) No IDN ccTLDs at all and probably no IDN TLDs.
	
	(ii) Each localized application (browser or otherwise)
	has its own table of TLDs of interest and local names,
	in the local language, and performs translations as
	needed.  Those translations are a function of the
	localized software and do not occur in (or anywhere
	near) the DNS.

	The net effect of the above is that, as far as the
	localized user is concerned, all relevant TLDs exist in
	the local language.  That user doesn't really care what
	some other country is called in that country's language,
	only about what it is called locally.  For example, for
	one of your users, it would be much more useful to be
	able to refer to the TLD for the country to your east as
	"Allemagne" than to be concerned about what either its
	residents call it or about what I (or someone else)
	might call it.
	
	(iii) People traveling outside their preferred localized
	environment either need to know and use the global form
	or to have a way to carry their localizations with them.

The third comment above of course has very general
applicability.  As soon as we start to do _any_ localizations,
those localizations have to be portable or users who move
outside the locality (geographically or from a
software-selection standpoint) are going to also need to know
the global forms (inconvenient and unnatural as they may be).
Much of the argument about mapping has been this issue in
disguise: if one forces everyone into a single global format and
terminology, one gets better global interoperability; if one
permits (or encourages) localization to make things easier for
casual users, then one has to be careful --and tolerate extra
measures-- in order to avoid losing global interoperability.

This model has no consequences at all for domains below the top
level.  At that level, if the domain administrator wants to make
things easier for a speaker of a given language, she can create
alternate entries, aliases, etc., for those speakers without
either having to make the root huge or engaging in international
politics.
	
> Sorry, if I did not understand the underlying idea. If there
> are tables to translate TLDs, it means that TLDs are
> identified.

That model requires a list of TLDs of interest (possibly a
different list for each localized application-instance).  That
list is not part of IDNA or the DNS.    And, in particular, it
doesn't have anything to do with how names further down in the
tree are interpreted.

>>> Ooops! This would have been a problem for "internationalized"
>>> money making gTLDs ICANN wants to sell.
>> 
>> No, actually, some of the "Rich people" who want those domains
>> would undoubtedly like the freedom to do whatever they like
>> even to use character coding systems other than Unicode.  So
>> you need a different conspiracy theory and/or source of
>> innuendo.
> 
> I am afraid you misuderstand the commercial point here.
> Coca-Cola does not want to fool around with ".coke". They want
> something stable and unique. TM protection is not in freedom,
> but in enforced rules. The same for .com.

We may need to agree to disagree but, while I believe that what
you are saying is quite sensible and that stability, uniqueness,
and decent rules are the key to predictable and usable behavior
(and, incidentally, the ability to localize), that is _not_ the
direction in which the marketplace is headed.

And the peculiarity of the "should control pass from ICANN
and/or the US Govt to someone else" debate, whether carried out
in the US Congress, in IGF, or elsewhere, is that it isn't about
stability and uniqueness versus a domain names market that
concentrates on a rather different set of issues, but about who
should control, manage, and maybe profit from that market.

> Freedom is great for IDN TLDs, not for global TLDs.

The nature of the DNS is that any TLD is inherently global.  The
focus of their registrations may differ as a matter of policy,
but accessibility --and consistency of the rules with which they
are accessed and names are interpreted-- are very much global
whether we like it or not.   If we don't like it, the only
options are to layer localizations on top of the DNS (and now on
top of IDNA) without changing the DNS or IDNA --and that is
exactly what the proposal to which you refer was about-- or to
junk the DNS and start over.

>...
>>   If you would like to
>> put IDNs into that category and accept the five or ten year
>> wait it would imply, I'm sure I can find people who would be
>> sympathetic to that idea.  But I'm not one of them and I
>> suspect that few participants in the WG are either.
> 
> IDNs were introduced on the Internet in 1998.

Sigh.  Even earlier than that, actually.   But, if you think
that is relevant, it is yet another reason why they are not a
research topic.
 
>...
>> I wish I had a better idea what you are talking about and
>> whether it was relevant to the WG.
> 
> I only mean that zone managers will have to deal with the
> final texts. And that we have to make sure no one can use
> these texts to insert hidden MUSTs, for example in the way to
> implement them or to contract their use.

And so?  You would change what about what we are doing?  I'm
also concerned about "make sure" because, ultimately, we have no
enforcement mechanism other than the consequences of misbehavior
causing loss of interoperability.

regards,
    john



More information about the Idna-update mailing list