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