[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
________
mark.davis@xxxxxxxxx
IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193
(408) 256-3148
fax: (408) 256-0799

----- Original Message ----- 
From: "Adam M. Costello"
<idn-reg-policy.amc+0@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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
another
> person wants to register label x2 (tagged with language X), and
suppose
> that x1 and x2 would not be considered equivalent by people whose
native
> language is X, but would be considered equivalent by people whose
native
> language is Y.  If the registration-blocking mechanism pays
attention
> to the tags, it will allow both x1 and x2 to be registered, missing
an
> opportunity to prevent confusion among Y-speaking users, and missing
an
> 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
should
> be blocked in a given zone, it should use all the variant tables
that
> 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,
and
>
> (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
other
> purposes, though, like pricing and the domain management user
interface.
>
> 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
lang:eng
> > the french registry and the german registry may have different set
of
> > variants, while the swiss registry might want to use the superset
from
> > both for reserved variants.
>
> I think that's fine.  I have no problem with tagging an entire zone
as
> "French" or "German" or "French and German".  It's tags on
individual
> 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
one
> blocking rule to some names in the zone, and another blocking rule
to
> other names in the zone, I worry that the system will be both harder
to
> understand and less effective at preventing confusion and disputes.
>
> AMC
>