Solutions for IDN character variants in traditional and simplified Chinese and related issues @ DomainAvenue.com | Domain Name Registration and Web Hosting on IBM/Hewlett-Packard (HP) Compaq Servers running Red Hat Linux 7.x w/Apache

Learn more: character variant solution - Read introduction

Different thought leaders in the technical community have suggested different approaches to address the character variant issue. Each possible approach has both positive and negative aspects. The technical community does agree that the character variant issue can never fully be addressed because languages are always in a state of change. Hence, new character variants between languages will continue to be introduced into languages.

While working to address the issue of character variants VeriSign has consulted and will continue to work with all interested stakeholders. These groups include China Network Information Center (.cn), Taiwan Network Information Center (.tw), Korea Network Information Center (.kr), Japan Registry Service (JPRS) (.jp), the Chinese Domain Name Consortium (CDNC), and the IDN Implementation Committee established by ICANN.

VeriSign plans on upgrading its IDN infrastructure to address character variants. The initial upgrade is designed to support character variants in simplified and traditional chinese scripts. They plan to deploy this upgrade in two phases:

Phase 1: Character variant blocking

In Phase 1, VeriSign will implement two new processes:

Legacy registrations

For existing IDN registrations, VeriSign will generate appropriate domain names containing character variants and prohibit them from being registered. If one of the generated domain names matches an existing IDN registration, it will continue to exist.

New registrations

For new IDN registrations, VeriSign will generate the appropriate domain names containing character variants and prohibit them from being registered. If one of the generated domain names matches an existing IDN registration or its blocked character variants, the new IDN registration will not be accepted.

The base IDN registration and its associated blocked character variants will act as a package. For example, if the base registration is deleted, the associated blocked character variants will be unblocked and become available for registration. This behavior will continue until additional functionality, such as activation of blocked character variants, is added.

By blocking the appropriate character variants, VeriSign hopes to limit the number of new IDN registrations that are adversely affected by character variants. In Phase 1, VeriSign will use mapping tables developed by TWNIC to generate the character variants. The TWNIC mapping table will be replaced with the CDNC mapping table when it is available. Phase 1 will be implemented entirely by VeriSign.

Example

The following is an example of character variants and how they will be handled. To simplify the example, a combination of shapes has been used to represent the Unicode points that represent traditional and simplified chinese characters.

Traditional Chinese Simplified Chinese

A Chinese character variant can fall into two classes: Class A: a variant where the string contains characters entirely in simplified chinese or traditional chinese. The VeriSign character variant solution will block Class A variants. Class B: a variant where the string contains characters that are both unique to simplified chinese and traditional chinese. The VeriSign character variant solution will not block Class B variants.

Suppose we have a traditional chinese IDN registration (also known as base registration) .com and is duely represented in simplified chinese as .com. This means all of the Unicode code points ( , , , ) are contained within the character set used for Traditional Chinese. However, and are unique to Traditional Chinese but can be mapped to the characters and , respectively, in Simplified Chinese. The following table shows the base registration and the character variants that were generated for the traditional Chinese registration above:

Base Registration     Registered

Class A variant     Blocked

Class B variant 1     Not blocked

Class B variant 2     Not blocked

Only the Class A variant(s) would be blocked. This is commonly referred to as the "mirror" of the original registration. In practice, there may be multiple mirrors. The process of blocking character variants will only be applied to IDN registrations that are composed entirely of the simplified or traditional chinese scripts.

Phase 2: Language tags

In Phase 2, VeriSign will implement language tags into the SRS core release 5.3. The language tag will be requested from the registrar for each new IDN registration. Phase 2 will impact registrations in the following manner:

Legacy Registrations

Existing IDN registrations were handled in Phase 1. No additional actions are planned in Phase 2. Language tags will not be required for legacy registrations.

New registrations

For new IDN registrations, VeriSign will follow the same process as in Phase 1 with one modification related to the process of generating the appropriate character variants. In Phase 2, the character variants will be generated using the mapping tables associated with the IDN's language tag.

The language tag will provide the language associated with the IDN registration. The language tag will determine which mapping table to apply, if any.

The language tag is a new field that will be deployed as a part of the RRP. It is not a required field. VeriSign will request a default language tag from each registrar. The default language tag will be associated with all IDN registrations, unless an overriding tag is received via RRP. If there is no language tag or default language tag associated with an IDN registration, no character variants will be generated for the IDN registration.

To be considered valid, language tags must come from the ISO 639-2 table, Codes for the representation of names of languages: alpha-3 codes. There will not be a table for each and every one of the languages identified in the ISO 639-2 table. At this time, VeriSign has implemented tables for simplified and traditional chinese.

For Phase 2, Registrars will be asked to provide a default language tag. In addition, registrars may choose to add a request for a language tag to their IDN purchase flow. If the registrar chooses to add the language tag to their purchase flow, they will need to modify their systems to add the language tag field to RRP. For some markets where character variants are not an issue or where the bulk of IDN registrations are in a particular language, registrars may choose not to modify their purchase flow to add language tags. This decision is entirely up to the registrar.

Example

The following is an example of the language tags and how they will be handled. The written Japanese language uses three scripts: Hiragana, Katakana and Kanji. Kanji are Chinese characters. A registrant registers .com, a Japanese IDN composed of only Kanji characters. How would VeriSign generate the appropriate character variants? The language tag will dictate the appropriate mapping tables to be used to generate the character variants. If the Japanese IDN registration is submitted with a Japanese language tag (ISO 639-3 tag: jpn), VeriSign will look for the Japanese mapping table. The Japanese mapping table does not contain any variants, therefore there would be no character variants generated or blocked.

Future functionality

To further enhance user experience and increase the IDN opportunity for registrars, VeriSign is considering additional functionality related to character variants such as activation of blocked character variants. VeriSign will announce enhancements as they become available.