

Re: Character Variant Deployment at VeriSign


(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
generate variants.

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
can handle).

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.

-James Seng