ICANN ICANN Email List Archives

[gnso-idng]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: Process forward [RE: [gnso-idng] restarting discussions on IDN gTLD]

  • To: Edmon Chung <edmon@xxxxxxxxxxxxx>
  • Subject: Re: Process forward [RE: [gnso-idng] restarting discussions on IDN gTLD]
  • From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Date: Sat, 21 Nov 2009 19:14:42 -0500

Edmond,

I'm glad you spoke to Bertrand, he and I spoke about tracks and their characteristics several times in Seoul.
There already exists the ccTLD IDN FT set of some 40 eventual 
non-Latin strings to be added to the root.
These have the property that:
(a) the delegations are to existing delegees, with little substantial modification of the conditions attached to the present delegation, (b) the strings to be delegated are derived from the existing delegations strings (.cn -> chung guo), (c) one (or two in the cases of {cn,tw,sg,hk}) non-latin strings are allocated to each requestor, (d) the non-latin script must be used in an official capacity by the associated territorial jurisdiction
I think that covers it, corrections welcome.

To this I propose the following:

A very similar set, with the largest difference off of the ccTLD IDN FT requirement being (d), and as official scripts are an elective choice of territorial jurisdictions, equity suggests that the script is the choice of the registry.
I take Edmon's point about the absurdity of picking "a script" for 
Asia, but India alone has 11 scripts, and each registry is free to 
prioritize.
Because size may be useful, if each registry is allowed two scripts, 
the size of the ccTLD IDN FT set would be equivalent to, rather than 
twice the size of, this gTLD IDN FT.
There also already exists, by subtraction, the ccTLD IDN PDP set of 
some unknown, but bounded number of non-Latin, and (decorated) Latin 
strings to be added to the root.
I propose the equivalent on the g-side, which I think is something we 
agreed on some time ago. It can be organized as a series of rounds of 
allocation of non-Latin scripts, and decorated Latin script.
Thus far, all new delegations share the contractual relationship with 
ICANN as the existing delegations.
I'm indifferent as to whether an operator serves "the same" zonefile, 
regardless of choice of mechanism, DNAME or NS. When I think about how 
Indians "see" the US, and how non-Indians "see" the US, it is clear 
that we "see" very different things. Some of the political delegation 
structure is common, but not a lot else.

My guess is that museum, cat and coop excite no adverse interest by the authors of the criticisms that are directed at gTLDs in general, in fact, they may not even know about us. They may not object to museum in Chinese, or cat(alan) in Arabic, or coop in Hindi, though they may object to com/net/org in anything.
It is worth discussing, and if we find out that the critics of VGRS 
getting an IDN are opposed to Musedoma getting an IDN, we have 
important data that they're simply opposed to ICANN's gTLD mission.
Then there are the applications by businesses or institutions not 
currently a party to a registry contract.
It seems to me that most of the issues they present are dealt with 
acceptably in GFAv3, though again, we don't yet know if the authors of 
the criticisms that are directed at gTLDs in general can be satisfied 
by community-based or best-practices policied applications, that is, 
if they'd object to cat by any other name.
At the risk of seeming, even being, self-serving (well, CORE serving), 
if we could agree to some highly constrained applications, the kind 
that Amadeu and I prefer, community-based, serving a non-Latin script 
community ignored by the ccTLDs, either because it is a national 
minority ranked below the associated territorial government's first 
choice, or because it is a regional minority, with no national 
minority status, then we could discover if criticisms that are 
directed at gTLDs in general can be satisfied, or if they are brought 
in bad faith.
Examples that come to mind of script with no ccTLD interested in 
serving them are Yiddish (Hebrew Script), Rom (Cyrillic and 
(decorated) Latin Script), and Tibetan (Indic).
Cary and I are ready to do a Yiddish application, using the same rules 
as PuntCat used. We could do the work to get a Tibetan application 
ready, though it may be already done by others we don't yet know. 
Cat's rules got it a total of 4 DRP issues over a volume of 40,000 
registrations, and it seems to have triggered an unprecedented 
explosion in Catalan writing (check Google's pages-in-language tool).
If we (that the "we" on this list) can't get cat's Yiddish kitten past 
the process censors, then it isn't likely that anything will get past.
And that's really worth knowing, and I'm open to other proposals that 
attempt do discover if the criticisms that are directed at gTLDs are 
conditional, or unconditional.
Conference Calls +1.

Eric



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy