ICANN/GNSO GNSO Email List Archives

[council]


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

Re: [council] Bundling of IDN versions of TLDs

  • To: Adrian Kinderis <adrian@xxxxxxxxxxxxxxxxxx>
  • Subject: Re: [council] Bundling of IDN versions of TLDs
  • From: Ching Chiao <chiao@xxxxxxxxxxxxx>
  • Date: Wed, 18 May 2011 09:16:54 +0800
  • Cc: GNSO Council <council@xxxxxxxxxxxxxx>
  • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=rlnbzs5wS+IWRnIvHEYY2qs0pWQxGTvx2wDvCUu39IM=; b=Ij+Hgwz4SSP07IkttFIbOUrmYfBSPXpOUmGBrhOc4Lw9rwn6p/+r8pBFvX1I9nuANw MKlLdaj1HyrEz3HWpWpDVk+4lm6UQUo2nDUD6gRDr0B44dyXc9ptajg5z11AgX04CAN5 oASffB4ejP1ZG+bQON6tJa2kXLRbw1OUNEIC8=
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=cdP729GC10erTH8W04iewIL7wV7EsiciDcxznzWYx0Tm/5bD1j9jlb3alnG53r2BSP bO9z7OfOiQE/Cu31rYH/SF5l2gxvp2Tzjp0uHpAdRcagoFU6D1j3K/W3tN/xCeqoPnBb 1Ztx7lKw+1awfnWkAFoBYYufWrM1yO1k4ljRo=
  • In-reply-to: <8CEF048B9EC83748B1517DC64EA130FB569FE06F2A@off-win2003-01.ausregistrygroup.local>
  • List-id: council@xxxxxxxxxxxxxx
  • References: <8CEF048B9EC83748B1517DC64EA130FB569FE06F2A@off-win2003-01.ausregistrygroup.local>
  • Sender: owner-council@xxxxxxxxxxxxxx

(The following was also posted on RySG list earlier)

As most of you know that this issue has been addressed in the 2004 .asia
sTLD application http://www.icann.org/en/tlds/stld-apps-19mar04/asia.htm .
DotAsia will be happy to support this -- some may recalled that the similar
concept of *IDN gTLD fast track* to support existing TLD operators to apply
for associated IDN name. There's definitely other policy issues which it can
take another year or two to resolve.

However, this is a little bothering for some as this statement is from BC
rather than from NCSG or ALAC (which could make Adrian feel that this is
land grabbing). Also, the CJK language / ccTLD communities did not sign up
and this makes the statement less persuasive.

Just my two cents.

Ching



On Wed, May 18, 2011 at 6:18 AM, Adrian Kinderis
<adrian@xxxxxxxxxxxxxxxxxx>wrote:

> Have everyone seen this?
>
>
>
>
> http://www.icann.org/en/correspondence/andruff-et-al-to-dengate-thrush-beckstrom-11may11-en.pdf
>
>
>
> This is, in my opinion, ridiculous.
>
>
>
> This is an incredibly slippery slope to even bother with and we have
> covered this ground before.
>
>
>
> This is nothing more than a real estate grab by those that stand to benefit
> from it (and the usual suspects they have been able to rope in to “support”
> them).
>
>
>
> I thought the GNSO sorted out this issue a long time ago. Did VeriSign just
> decide how much it was going to cost to go for .com in every script all of a
> sudden?
>
>
>
> It is really simple. You cannot clearly define the meaning of *every* word
> in English as it directly relates to other scripts.
>
>
>
> So, if I went for .auto does that mean I get .auto in Arabic – what is the
> EXACT translation for that? Do you get everything close? How close does it
> have to be?
>
>
>
> What about the reverse? What if I go for .auto in Arabic (whatever that is)
> does that mean I get .car, .automobile, .auto, .autobus etc etc in ASCII?
>
>
>
> Finally, .music in ASCII) is not the same as .music (Arabic version). It is
> promoting competition. What amazes me is no one receives any bundled TLD’s
> when they register under .com right now. VeriSign allows for separate
> registrations in each script. If they are the same, why don’t they give each
> registrant every IDN variant?
>
>
>
> I would really like to make a stand on this as a Council. This rule has
> been included in EVERY version of the guidebook. Now we are nearing the
> finish line these folks would prefer to make a wholesale change to their
> benefit.
>
>
>
> What are the thoughts of the Council?
>
>
>
>
>
> *Adrian Kinderis*
>
>
>


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