The problem is that Government Policy changes. We should stick to one per 3166-1 entry. Tim -------- Original Message -------- Subject: RE: [council] #9 of Response to ccNSO/GAC Issues report From: "Edmon Chung" <edmon@dotasia.org> Date: Tue, February 12, 2008 8:46 pm To: "'Tim Ruiz'" <tim@godaddy.com>, "'Avri Doria'" <avri@psg.com> Cc: "'Council GNSO'" <council@gnso.icann.org> Hi Tim, I am also concerned with the spawning of IDN ccTLDs, but I think it is prudent also to look at a reasonable approach for the cc side as well. I have already added in the part "AND governmental policy makes selecting a single string inappropriate", which I think provides adequate safe guard against the volume of TLDs. Also, this update actually does not change the general concept in the body of the document that already says: "These should be limited to one IDN ccTLD per ISO 3166-1country or territory, except in those cases where governmental policy makes selecting a single script impossible." Perhaps a slight tweak to make it a different sentence maybe better?: 9. There should be only one IDN ccTLD string per ISO 3166-1 entry per relevant script. Measures must be taken to limit confusion and collisions due to variants. Where one script is used for multiple languages and governmental policy makes selecting a single string in appropriate, one IDN ccTLD string per ISO 3166-1 entry per language may be considered. Edmon
-----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Tim Ruiz Sent: Wednesday, February 13, 2008 9:21 AM To: Avri Doria Cc: 'Council GNSO'; Edmon Chung Subject: RE: [council] #9 of Response to ccNSO/GAC Issues report
I don't agree with this change. This is the slippery slope I am concerned about. We started talking about one so-called IDN ccTLD per ISO 3166-1 entry, now we're opening it up to any number. So India could get 20 or so based on this new language? I am amazed that the registries have agreed to this.
Tim
-------- Original Message -------- Subject: Re: [council] #9 of Response to ccNSO/GAC Issues report From: Avri Doria <avri@psg.com> Date: Tue, February 12, 2008 7:03 pm To: Edmon Chung <edmon@dotasia.org> Cc: "'Council GNSO'" <council@gnso.icann.org>
Hi,
I agree that this is a good change. I was working on something similar myself and this this is better wording then what I was coming up with.
thanks
a.
On 13 Feb 2008, at 01:17, Edmon Chung wrote:
fter some discussion at the Registries Constituency today, would like to make the following suggested edits to #9.
The current wording:
9. There should be only one IDN ccTLD string per ISO 3166-1 entry per relevant script. Measures must be taken to limit confusion and collisions due to variants.
Suggested edit:
9. There should be only one IDN ccTLD string per ISO 3166-1 entry per relevant script, except in those cases where one script is used for multiple languages and governmental policy makes selecting a single string inappropriate. Measures must be taken to limit confusion and collisions due to variants.
The rationale for the edit is to provide for the situation is for example in India where one script is used for multiple languages and the representation of "india" in those different languages using the same script may be different.
We would have to make a change to the main body as well, mainly with regards to the response to: a) Should there similarly be only a single IDN ccTLD for a given script for each !%territory!& or can there be multiple IDN ccTLD strings? For example, should there be only one equivalent of .cn in Chinese script for China or .ru in Cyrillic for Russia? Proposed GNSO response: Yes, the GNSO believes that there should be only one string per ISO 3166-1 entry per relevant script.
Suggested change to the proposed response:
Yes, the GNSO believes that there should be only one string per ISO 3166-1 entry per relevant script., except in those cases where one script is used for multiple languages and governmental policy makes selecting a single string inappropriate. Measures must be taken to limit confusion and collisions due to variants.
Edmon