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@jck.com> To: Marilyn Cade <marilynscade@hotmail.com> CC: Cary Karp <ck@nic.museum>, Sophia B <sophiabekele@gmail.com>, Patrik Fältstrom <paf@cisco.com>, Tina Dam <dam@icann.org>, GNSO Council <council@gnso.icann.org> --On Saturday, February 04, 2006 3:19 PM +0000 Marilyn Cade <marilynscade@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