[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Character Variant Deployment at VeriSign

I agree with Adam; this is what I was trying to say some time ago (but
didn't say as clearly (and haven't had time to follow up on)).

Of course, existing registrations need to be grandfathered, but the
policy for blocking needs to be global to the zone, not on the basis
of individual languages for individual names.

Märk Davis
IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193
(408) 256-3148
fax: (408) 256-0799

----- Original Message ----- 
From: "Adam M. Costello"
To: "IDN registration policy list" <idn-reg-policy@xxxxxxx>
Sent: Tuesday, May 20, 2003 23:06
Subject: Re: Character Variant Deployment at VeriSign

> AyeShil Jeon <asjeon@xxxxxxxxx> wrote:
> > I have no idea exactly what your point is.  Would you clarify it?
> Suppose a registry supports languages X and Y, and suppose that one
> person wants to register label x1 (tagged with language X), and
> person wants to register label x2 (tagged with language X), and
> that x1 and x2 would not be considered equivalent by people whose
> language is X, but would be considered equivalent by people whose
> language is Y.  If the registration-blocking mechanism pays
> to the tags, it will allow both x1 and x2 to be registered, missing
> opportunity to prevent confusion among Y-speaking users, and missing
> opportunity to prevent a dispute that may arise when the registrants
> discover that Y-speakers have started visiting their sites and are
> getting them confused.
> Therefore I suggest that when a registry is deciding which names
> be blocked in a given zone, it should use all the variant tables
> are relevant to that zone, paying no attention to any language tags
> belonging to individual names.
> Here's an example of how a registry might decide whether to admit
> a name.  Suppose the zone supports a set L of languages.  For each
> language in L, there is a function Valid(language;label) that checks
> whether the label is valid in that language, and another function
> TooClose(language;label1,label2) that checks whether two labels are
> confusingly similar in that language.
> I suggest that the registration of a new label be allowed if
> (1) Valid(language;label) is true for at least one language in L,
> (2) TooClose(language;label,existing_label) is never true for any
>     existing label, for any language in L.
> Notice that the language tags of the names never come into play for
> deciding what blocks what.  Language tags might still be used for
> purposes, though, like pricing and the domain management user
> It might be possible to combine the per-language tables into larger
> tables, but that's an implementation detail.
> Edmon Chung <edmon@xxxxxxxxxx> wrote:
> > For example, given a domain registration for a domain with
> > the french registry and the german registry may have different set
> > variants, while the swiss registry might want to use the superset
> > both for reserved variants.
> I think that's fine.  I have no problem with tagging an entire zone
> "French" or "German" or "French and German".  It's tags on
> names that I'm worried about.  I have no problem with a zone using
> its own custom rule for what blocks what, as long as that rule is
> applied uniformly to all names in the zone.  But if the zone applies
> blocking rule to some names in the zone, and another blocking rule
> other names in the zone, I worry that the system will be both harder
> understand and less effective at preventing confusion and disputes.