[council] #9 of Response to ccNSO/GAC Issues report

[Avri Doria]

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
>
>
>
>
>
>
>
>
>
>
>