ICANN ICANN Email List Archives

[gnso-idn-wg]


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

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

  • To: Steve Crocker <steve@xxxxxxxxxxxx>
  • Subject: Re: [gnso-idn-wg] Unified rules within a DNS subtree
  • From: subbiah <subbiah@xxxxxxxxx>
  • Date: Fri, 09 Mar 2007 08:54:50 -0800


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




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

Privacy Policy | Terms of Service | Cookies Policy