[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Character Variant Deployment at VeriSign
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.
(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).
If "I get x2 too" means that x2 appears in the DNS zone at no additional
charge, then I agree, a language tag would be useful.
Read the JET IDN Admin. Depending on what kind of variants, it may or it
may not end up in the zonefile. As for the question involving cost, that
is left out of the document *intentionally* because we dont think IETF
is the forum to discuss that.
But even if I don't get x2 (x2 does not appear in the DNS zone), even if
I don't want x2, I think it would still be a good idea for the registry
to prevent anyone else from getting x2, because some users would confuse
x1 and x2. The blocking is not just for my benefit, but also for
thats why the JET admin suggest using the language tag as a basis to
When you say "variants", do you mean only the names that the registrant
has control over, or also the names that the registry blocks? I see why
language tags are useful for generating the former, but not the latter.
I meant both. When the variants is reserved for the registrant, the
registrant will be the only one able to "register" or "deregister" it.
In the JET document, we call this "activation" and "deactivation".
(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
You don't necessarily have to store the blocked names. Checking whether
a new name is blocked might be equivalent to a pattern-match against the
set of already-registered names.
Sure you can :-) But if it feasible if you have, say 1M names in your
zone file? I think the checking would be pretty intensive.