Home / Blogs

JET Guidelines for Internationalized Domain Names

It is difficult to explain RFC 3743 or commonly known as the Joint Engineering Team (JET) Guidelines without some lesson on Chinese, Japanese and Korean (CJK), particularly how it relates to Internationalized Domain Names (IDN). Luckily, an Internet-Draft [PDF] we wrote back in 2001 discusses the issues quite neatly in this context.

In brief, Chinese characters (Hanzi) or Han ideographs are evolved from pictographs (writing made up of pictures) across thousands of years. Unlike other writing systems, Han Ideographs are constantly evolving. In the 1950s, China underwent a major exercise to simplify the Chinese writing using an almost systematic process. The resulting simplified form or Simplified Chinese is now being used in China and Singapore while the original form or Traditional Chinese is still being used in Taiwan, Hong Kong, Malaysia and most oversea Chinese communities.

Because of the almost systematic simplification process, there is a somewhat 1-to-1 matching between Simplified Chinese and Traditional Chinese. It is easy to associate it to the like of uppercase/lowercase in English but at best, it is a bad analogy that grossly underestimates the depth of the problem.

If that is not complicated enough, Han Ideographs are also used to write Japanese (Kanji), Korean (Hanja) and old Vietnamese (Chu Han and Chu Nom), and each language has its own simplification history and rule. In addition, there are many Han Ideographs that look exactly the same (CJK Compatibility) or have similar looks (zVariants) but assigned different code points in Unicode.

Some readers may point out that the IETF standard for IDN, RFC 3490 (IDNA) includes RFC 3454 (stringprep) and RFC 3491 (nameprep) that specify a normalization process that “will allow users to enter internationalized domain names into applications and have the highest chance of getting the content of the strings correct.” But unfortunately, it does not handle any normalization for Han Ideographs as there isn’t any universal well-defined matching/folding rule for Han Ideographs across CJK. What works for one language will inevitably mess up another.

Hence, the next best solution is to ensure CJK IDNs are handled correctly in the registries or registrars; RFC 3743 is the result of a two-year effort by JET to define an administrative guidelines for CJK IDNs. While RFC 3743 was published only 2 weeks ago (April 15, 2004), it has been in circulation within the community for a long time and is highly regarded. In fact, ICANN IDN Guidelines is heavily influenced by the JET Guidelines and today, IANA maintains an IDN Characters Tables Registry for RFC 3743.

Without going into the gory technical details, RFC 3743 introduces two main concepts in CJK IDN administration:

The first is a set of valid characters code points that can be registered. There are nearly 70,000 Han Ideographs in Unicode 3.2 and over 96,000 in Unicode 4.0 and only a fraction (between 1200 to 9000 ideographs, varying between countries) is commonly used. Therefore, it is more sensible to restrict the CJK IDN registration to a subset of Han Ideographs than to allow any code point to be registered.

The second is administrating CJK IDNs as a “package”. Due to simplifications and variants, each Han Ideograph may have 1 or more variants. For example, a Traditional Chinese IDN would have a corresponding Simplified Chinese IDN and it would be confusing if the two IDNs are been registered to different parties.

Thus, to avoid potential conflict, when someone registers a CJK IDN, the other related variants (generated using the algorithm defined in the JET Guidelines) are also marked reserved. These variants are administrated as a single atomic “package” i.e., if one IDN is deleted, the whole package is deleted and when one IDN is transfered, the whole package is transferred.

For example, if Legend Group register their Traditional Chinese IDN, the Simplified Chinese IDN and all its possible permutations would be reserved (see figure below). All these IDNs are considered “equivalent” and administrative treated as a single atomic “package”.

Chinese Characters: Traditional, Simplified, and Variants

Incidentally, for those who can read Chinese, you will realize that some of the variants mentioned above are not commonly used or don’t make sense. The algorithm utilizes the dumb code point permutation. More intelligent algorithm could be designed using CJK lexemic and orthographic data but would be very expensive to implement. The goal of the algorithm is not to generate meaningful variants but ensuring the potential variants are reserved to minimize potential dispute.

Finally, I would like to point out that it is common for a Han Ideograph to have 2 or more, and in some rare cases, more than 10 variants. So for an IDN with 10 Han Ideographs, there could be 100 to 10,000 variants. The cost to register all these variants one-by-one to “protect” just one IDN and the possible domain dispute if not done properly is left as an exercise for the reader. The importance of the RFC 3743 or JET Guidelines would be obvious thereafter.

By James Seng, Vice President

Filed Under


Jothan Frakes  –  Aug 25, 2004 3:18 AM

I have worked with James on a variety of projects.  His contributions to the arena of IDN are immense, and my respect for him equal.

These are some very strong points made in the area of RFC 3743 / JET Guidelines.  These are absolutely important to the long term success and traction of this expansion of the namespace.

The number of Han Ideographs can multiply confusion in the IDN space, and undermine customer and user confidence—most notably that of registrants. 

Variant blocking is an absolute must for handling IDN registrations in a responsible manner.  RCF 3743 is hopefully taken and adopted in TLDs offering IDN registrations to the CJK communities.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Domain Names

Sponsored byVerisign


Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API

Brand Protection

Sponsored byCSC


Sponsored byDNIB.com

IPv4 Markets

Sponsored byIPv4.Global

New TLDs

Sponsored byRadix