ICANN ICANN Email List Archives

[gnso-idng]


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

RE: [gnso-idng] Picking up where we left off ...

  • To: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>, "gnso-idng@xxxxxxxxx" <gnso-idng@xxxxxxxxx>
  • Subject: RE: [gnso-idng] Picking up where we left off ...
  • From: Adrian Kinderis <adrian@xxxxxxxxxxxxxxxxxx>
  • Date: Wed, 3 Feb 2010 09:47:04 +1100

For what it is worth, I refute the claim that any existing operator 'get' 
anything at all. They should apply just like anyone else.

Adrian Kinderis

-----Original Message-----
From: owner-gnso-idng@xxxxxxxxx [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of 
Eric Brunner-Williams
Sent: Wednesday, 3 February 2010 5:20 AM
To: gnso-idng@xxxxxxxxx
Subject: Re: [gnso-idng] Picking up where we left off ...


All,

It has been a week since I wrote "Picking up where we left off ...", 
and six weeks and five days since Stéphane's note, the last after 
Edmon cancelled the call scheduled the previous day , so the gnso-idng 
activity is ... not progressing.

As you all should know, requests by Egypt, the Russian Federation, the 
United Arab Emirates, and Saudi Arabia have completed evaluation.

The respective strings are:

.sa xn--mgberp4a5d4ar (variants: xn--mgberp4a5d4a87g, 
xn--mgbqly7c0a67fbc, and xn--mgbqly7cvafr) for "al saudiah",

.eg xn--wgbh1c, the familiar "misr",

.ae xn--mgbaam7a8h, the familar "imarat",

.ru xn--p1ai, the familiar "rf".

Returning to the GNSOC rhetoric that roughly equal in time and sense 
means more than nothing ...

One possibility is each of {VGRS, AF, NS, CORE} get an IDN of their 
choices.

Another is that {VGRS, AF, NS, CORE} get an arabic or a cyrillic IDN.

Another is that {VGRS, AF, NS, CORE} get an IDN sizeof(.sa or .eg or 
.ae), which is to say "small", or an IDN sizeof(.ru), which is to say 
bigger.

Another is that {VGRS, AF, NS, CORE} get an IDN chit that they can't 
(or shouldn't) cash in yet, which they may either conceal until the 
entire ccTLD IDN FT activity discloses all ccTLD IDNs under the FT, or 
they must disclose in stages, e.g., the {SA, EG, AE, RU} set being one 
stage.

These were some of my "what does `roughly equal' (my paraphrase) and 
the ccTLD IDN FT mean" thoughts.

Of course, CORE's initial preference is a Hebrew Script IDN TLD for 
Yiddish, for the same reasons we did a Latin Script ASCII TLD for 
Catalan, to preserve an endangered language.

There are alternate interpretations of the GNSO statements of position 
on IDNs. Avri has pointed out an equity claim for parties not 
currently contracted. Someone could offer a best use claim for the 
currently contracted parties with the largest market share. Someone 
else could offer a competition policy claim for the currently 
contracted parties with the smallest market share, and so on.

CORE's position is that we're fine with the ccTLDs going first. We 
think steady IDN expansion, nor initial market share, is the better 
goal. We also know our view is not widely shared by the other 
contracted parties.

What I've learned during the course of this list is that the 
Overarching Issues, at least the trademarks issue, isn't such a big 
deal for IDN strings are it is for ASCII strings, and with the 
exception of the homographic problem, the rest of the Overarching 
Issues are not as present.

That could be a good thing, if the current DAGv3+ process was able to 
distinguish between IDN applications and ASCII applications, but for 
the present there is no differentiation, and so the relative absence 
of objection to IDN gTLDs is data without significance.

Eric






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

Privacy Policy | Terms of Service | Cookies Policy