Re: [gnso-idn-wg] Unified rules within a DNS subtree

[subbiah <subbiah@xxxxxxxxx>]

Dear Steve,

As I am one, with Werner, who started on the path of "single script" on 
the con call, let me clarify once again. As I clarified quickly, by 
single script I mean "limited scripts". ie. a handful or less of scripts 
allowed under a given IDN gTLD .The latitude to be defined by the 
requesting applicant, input from the relevant linguistic community and 
overall ICANN policy to limit the extent of script-mixing to a "handful" 
of scripts in any single gTLD. (whether or not the current repertoire of 
Unicode approaches or eventually exceeds a 100 etc as Cary pointed out)

As to your policy discussion below  to contractually enforce such 
requirements as it may apply to a "limited script-mixing" that I prefer 
(as in above) and how it may apply  to both existing and new gTLDs I 
don't think I have any disagreemeent. What you suggest viz a viz both 
existing and new gTLDs appear in the main quite reasonable to me.

Cheers

Subbiah

Steve Crocker wrote:

> Sophia, and others:
>
> At the risk of stirring up unnecessary controversy, let me press on 
> the specific point I have in mind to see whether we have the same model.
>
> In my mind, I make a large distinction between existing TLDs and new 
> TLDs.  Existing TLDs are governed by an existing set rules.  In 
> particular, the existing TLD administrators, particularly the existing 
> gTLD administrators, have little control over the lower levels.  I 
> operate shinkuro.com, and if I choose to create a third level name 
> which is a mixture of many scripts, I'm free to do so.
>
> On the other hand, it seems to me we have the option of having a 
> different set of rules to govern new TLDs, if we think there's a good 
> reason for there to be different rules.  It was with this assumption 
> that I replied to Cary that it might be possible to use contractual 
> and other means, not just a unified zone, to enforce a rule about the 
> use of scripts in lower levels.  Thus, the picture I have in mind is 
> all levels would be enforceable for new TLDs, if that's the direction 
> that's adopted.
>
> I'm not saying whether this is a good or bad idea.  I was merely 
> putting forth an alternative means of accomplishing the enforcement of 
> a rule like "single script" as a reply to Cary's note that it would be 
> necessary to implement all levels within a single zone.  As I said, 
> this wouldn't apply to any existing TLD.  Similarly, Cary's comment 
> about having all levels within a single zone would only be possible 
> for a new TLD.
>
>
> Thanks,
>
> Steve
>
> Steve Crocker
> steve@xxxxxxxxxxxx <mailto:steve@xxxxxxxxxxxx>
>
> Try Shinkuro's collaboration technology.  Visit  www.shinkuro.com.  I 
> am steve!shinkuro.com.
>
>
> On Mar 7, 2007, at 12:53 PM, Sophia B wrote:
>
> >  
> >
> >             I was responding Cary's comment that they
> >             only way to have a rule like "single script" work for an
> >             entire
> >             subtree is to have the entire subtree maintained within a
> >             single
> >             registry, and I was suggesting contractual enforcement,
> >             culture, etc.
> >             could also be used.
> >
> >  
> > Yes, I am fully for this Steve,( as I suported it in the call by 
> > saying it was a good
> > compromise, when Subbiah made the original recommendation), ie. 
> > generally
> > maybe necessary and that the applicant on a case-by-case will be 
> > generously
> > awarded what they need, without going to hunderds of scripts. (at the 
> > enforceable
> > levels - 1st, 2nd and in some cases the 3rd etc).  And that it should 
> > just simply 
> > be made into a passive guidleines recommendation but a requirement to 
> > the
> > applicant in strong enforeacble contracts. (which Werner suggested). 
> > At  the
> > unenforceable levels, it should be a strong best practice recomendation
> > mentioned in the contract. The genreal idea is to prevent in the future,
> > hundreds of scripts and all manner of mixing them under single TLDs and
> > limit it to only a small handful of mixing based on local community 
> > needs as
> > requested by applicant.
> >
> >  
> > On 07/03/07, *Steve Crocker* <steve@xxxxxxxxxxxx 
> > <mailto:steve@xxxxxxxxxxxx>> wrote:
> >
> >     Bruce,
> >
> >     I was also including in my thinking the possibility of having even
> >     stronger contractual controls for all subordinate levels in newly
> >     created TLDs if that turns out to be desirable.  I'm not necessarily
> >     advocating this approach.  I was responding Cary's comment that they
> >     only way to have a rule like "single script" work for an entire
> >     subtree is to have the entire subtree maintained within a single
> >     registry, and I was suggesting contractual enforcement, culture, etc.
> >     could also be used.
> >
> >     Steve
> >
> >     Steve Crocker
> >     steve@xxxxxxxxxxxx <mailto:steve@xxxxxxxxxxxx>
> >
> >     Try Shinkuro's collaboration technology.  Visit www.shinkuro.com
> >     <http://www.shinkuro.com>.  I
> >     am steve!shinkuro.com.
> >
> >
> >     On Mar 7, 2007, at 1:26 AM, Bruce Tonkin wrote:
> >
> >     > Hello Steve,
> >     >
> >     >>
> >     >> Responding to your point on the call, I think it's feasible
> >     >> to have a
> >     >> uniform set of rules, e.g. single script adherence, imposed on an
> >     >> entire hierarchy even if the hierarchy is administered by multiple
> >     >> zone administrators, but it means using contracts and strong
> >     >> community enforcement instead of only mechanical checking.
> >     >>
> >     >
> >     >
> >     > It is really a balance between contractual enforcement and best
> >     > practice.
> >     >
> >     > For gTLDs:
> >     >
> >     > - top level - ICANN contractual term with registry operator
> >     >
> >     > - second level  - ICANN contractual term with registry operator
> >     >
> >     > - third and lower level - best practice/education
> >     >
> >     > (note that some TLDs like .name do support third level directly
> >     at the
> >     > registry, and hence compliance could be managed at that level)
> >     >
> >     >
> >     > For ccTLDs:
> >     >
> >     > - top level - ICANN contractual term with registry operator
> >     >
> >     > - second level - best practice/education
> >     >
> >     > - third and lower level -  - best practice/education
> >     >
> >     >
> >     > To some degree application software can also highlight issues - e.g
> >     > display a warning when mixed scripts are detected etc.
> >     >
> >     >
> >     > Regards,
> >     > Bruce Tonkin
> >     >
> >     >



--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.413 / Virus Database: 268.18.8/714 - Release Date: 3/8/2007