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

["Edmon Chung" <edmon@xxxxxxxxxxx>]

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@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx] 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@xxxxxxx>
> Date: Tue, February 12, 2008 7:03 pm
> To: Edmon Chung <edmon@xxxxxxxxxxx>
> Cc: "'Council GNSO'" <council@xxxxxxxxxxxxxx>
>
>
> 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>