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

Character Variant Deployment at VeriSign


Paul has asked that I provide this mailing list some information concerning
what we are doing at VGRS in terms of character variant mapping.

This Saturday evening, May 17th, VGRS will be deploying into our systems an
ability to block future registrations where a variant of a registration
already exists within the IDN Testbed.  The objective of this release is to
minimize the exposure to registering domains where a variant has previously
been registered within the testbed.

-  For existing Chinese IDN registrations, VGRS will generate variants and
store them with a relationship to the registration that created them.  This
is the bundle. 
-  This will only apply to registrations that are entirely made up of
characters from the CJK Unified Ideograph Unicode code pages and ASCII
characters.  We are assuming that registrations that contain at least one
character outside of these sets of code points are not Chinese.
-  VGRS will be using a table that is available from TWNIC.
-  If there is a variant conflict within existing registrations, we will not
be deleting either of the offending registrations.  The TWNIC table will be
replaced in the future with one that provides a consensus position,
hopefully, in how to map Chinese characters, so conflicts today may not
exist in the future.  The TWNIC table is being used to minimize exposure.
-  For new registrations (post 5/17), if a variant exists, the registration
will not be permitted.
-  When a new registration does not exist and is successfully added to the
SRS, variants will be generated and posted to the variant table following
the same mapping rules that we are using for legacy registrations.
-  We do not consider the bundles created to be the final correct bundles
since we know that we will be replacing the table.

Later this summer, we intend to introduce a language tag so that a registrar
or registrant can provide the appropriate language association for a new
registration.  If an appropriate table exists for that language at that
time, we will apply those mapping rules to that registration.  Should no
mapping rules exist, we will mark the registration with the appropriate
language and commit it the SRS.

This is a brief picture of what we have planned.  

Paul, I hope this is about what you were looking for, but if not, I will be
glad to contribute more.


Pat Kane
IDN Product Manager