[council] Re: Regarding issues report on IDNs

[Cary Karp]

Forwarded on John's behalf. Please quote him (not me) as its author in
any response, which should also be cc'd to both John and Patrik.


-------- Original Message --------
Subject: Re: [council] Re: Regarding issues report on IDNs
Date: Sun, 05 Feb 2006 19:39:39 -0500
From: John C Klensin <klensin at jck.com>
To: Marilyn Cade <marilynscade at hotmail.com>
CC: Cary Karp <ck at nic.museum>, Sophia B <sophiabekele at gmail.com>,
   Patrik Fältstrom <paf at cisco.com>,        Tina Dam <dam at icann.org>,
GNSO Council <council at gnso.icann.org>

--On Saturday, February 04, 2006 3:19 PM +0000 Marilyn Cade
<marilynscade at hotmail.com> wrote:

> I am much appreciative of this kind of exchange which can
> advance the understanding of many of the non technical
> councilors, and our constituency members.
>
> Sophie, I think you have identified a concern I personally
> have abt DNAMES as I understand them, but I must study
> further. Does a DNAMES approach advance an extension of
> present Latin character gTLDs into non Latin character, but do
> not expand the underlying infrastructure competition.  Or do
> more?

That is correct.  And, whether one is talking about a DNAME
approach or a "new domain" one, the questions of which names
should be allocated and on what basis remains.  For example, the
decision to go in the DNAME direction does not, in itself, imply
that .COM should be any synonyms, much less 400-600 of them --
the case is more obvious for a small number of synonyms for each
of the ccTLDs (or each of those that doesn't use Roman-based
characters to express at least one of the names of its country,
or...) than it is for gTLDs.  Note that "more obvious" does not
imply "better": I have no personal position on that, partially
because I do not believe that either DNAMES or new domains that
are somehow linked to existing TLDs on some sort of entitlement
basis are the right solution to the problem as seen by users.

> For instance,  when we created the policy guidance for sTLDs,
> and unrestricted/open TLDS, my view was that to fully
> understand and take into account the implications of whether
> policy for non Latin character strings policy was needed to
> determine issues such as:

I am not certain I can parse the above accurately, and
consequently am not sure what the following four points (or at
least the first three) mean.

>  1) extend operation of non Latin versions to that registry
> operator 2) prohibit that string in non Latin character 3)
> assume new policy that would ask these questions.  4) Address
> non-Latin chacteri gTLDs as is presently being studied.

Please remember that one recommendation of the Katoh-lead IDN
policy committee was that IDN TLDs be considered only in the
context of new TLD applications (sponsored, generic, or
otherwise) and independent of any existing domain (i.e., no
proposals for them on the basis of linkage to an existing TLD or
its registry).   In principle, nothing would have prevented an
applicant in the recent sponsored gTLD round from including in
the application a request for a IDNA-based non-ASCII name.
Personally, it is not clear to me why such an application, had
it arrived, should have been treated any differently than any
other.  There might have been an issue with synonyms,
translations, or transliterations of other names, but those
problems could, in principle, occur and require consideration in
the ASCII-only space.  So, for me, we should have separate
issues of policy or principle with IDN TLDs only if an
application or request is made on the basis on "rights" or
"entitlements" to such names based on an existing domain that is
named in ASCII characters only.

Again, with the understanding that I'm not personally enamored
of either approach, the notion of entitlements to new TLD that
are somehow linked to existing domains causes me to consider
DNAMEs an attractive option: not that everyone should be
necessarily entitled to any name they might like, since that
probably leads to madness and some DNS operational problems as
well as some tough policy issues, but precisely because it does
not imply "linkage" among TLDs, which is a far more complex
problem both operationally and from a policy standpoint.

One further comment from Cary's followup to Sophia's note...

>> This creates BIG problems, a political one I must say, as for
>> eg. US would have an equivalent in Chinese, Arabic, and
>> others managed by Neustar.  I am not sure if the Chinese or
>> Arabs will like that. On the other hand - Iran and Syria will
>> have a Hebrew TLD  - I am note sure the Israelis would like
>> that.
>
> As long as we are immersing ourselves in policy details of the 
> internationalization of the domain namespace, we would be well 
> advised to think more than twice before making any statements that 
> assume the legitimacy of the notion of language ownership. Which
> national government owns the English language? Which owns the Latin
>  alphabet? Which owns Cyrillic? Are the Chinese language and script
> any easier? Arabic?

Let me add to Cary's comment a cautionary note about reality.
That third strategy --of doing nothing in the root zone but
simply providing translations or transliterations of TLD names
in applications software-- is something that any competent
programmer who can assemble a browser from a toolkit or who can
implement an appropriate extension to a browser that supports
such extensions can implement (and similarly for any other
Internet application that calls on the DNS).  There are tens of
thousands, perhaps hundreds of thousands, of such programmers in
the world, and they are distributed across the world.  If a such
programmer in China were to decide that, for her users to have a
good experience, .US and .COM should be able to be referenced by
using Chinese names, there is nothing that the GNSO, ICANN,
IETF, ITU, or the Great Pumpkin could do to stop or prevent it.
Even the control of the Chinese government would be _extremely_
limited, since those Chinese names would be visible only to
users of that particular application with that particular
extension, and not "on the wire" or to either DNS servers or the
sites or hosts being reached.

So, for the GNSO to attempt to ban _that_ solution is precisely
a "flat earth" issue.   There are many reasons to actually like
that solution, and many reasons to dislike it.  But, especially
if you conclude that you dislike it, you had best start thinking
seriously about which of the DNAME or separate TLD solutions you
like best and start promoting it.  Unlike another one of Cary's
comments, I'm not convinced that pushing back on IDNs in the
root would lead to fragmentation, although it is certainly a
risk.  But, if ICANN were to tell people who want to be able to
reference nationally-linked TLDs in their own languages and
scripts that they just are not going to get that, I think either
that third approach or fragmentation and alternate roots are a
near-certainty... probably both, involving different parts of
the world.

regards,
    john