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

Re: Character Variant Deployment at VeriSign


this case you bought up isnt new. it was discussed in the JET and we believe the best way to deal with this is on a per language basis.

i.e. if x1=x2 under X but x1!=x2 under Y, depending if the person register in X or Y, he will get either x1 & x2 or just one of them.

there is no confusion because the registrant gets what he expected to get. (anyone remember "law of least astonishment"?)

(if I am a native in X, and i registered x1 under X, I *expect* to get x2 too. But if I am a native in Y, and i registered x1 under Y, I only *expect* to get x1 and x1 only).

thats why the JET admin suggest using the language tag as a basis to generate variants.

(of course, you can try to be aggressive, and reserved all possible variants but you probably end up with far too many variants then you can handle).

-James Seng

Adam M. Costello wrote:
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.