Registration and Administration Recommendations for Chinese Domain Names
Registering Chinese domain names that exist in both Simplified and Traditional character forms.
Lee, X., Mao, W., Chen, E., Hsu, N., and J. Klensin, "Registration and Administration Recommendations for Chinese Domain Names", RFC 4713, DOI 10.17487/RFC4713, October 2006, <https://www.rfc-editor.org/info/rfc4713>.
@misc{rfc4713,
series = {Request for Comments},
number = 4713,
howpublished = {RFC 4713},
publisher = {RFC Editor},
doi = {10.17487/RFC4713},
url = {https://www.rfc-editor.org/info/rfc4713},
author = {X. Lee and W. Mao and E. Chen and N. Hsu and J. Klensin},
title = {{Registration and Administration Recommendations for Chinese Domain Names}},
pagetotal = 9,
year = 2006,
month = oct,
} RFC text
Contents
Network Working Group X. Lee
Request for Comments: 4713 W. Mao
Category: Informational CNNIC
E. Chen
N. Hsu
TWNIC
J. Klensin
October 2006
Registration and Administration Recommendations for Chinese Domain Names
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
IESG Note
This RFC is not a candidate for any level of Internet Standard. The
IETF disclaims any knowledge of the fitness of this RFC for any
purpose and in particular notes that the decision to publish is not
based on IETF review for such things as security, congestion control,
or inappropriate interaction with deployed protocols. The RFC Editor
has chosen to publish this document at its discretion. Readers of
this document should exercise caution in evaluating its value for
implementation and deployment. See RFC 3932 for more information.
Abstract
Many Chinese characters in common use have variants, which makes most
of the Chinese Domain Names (CDNs) have at least two different forms.
The equivalence between Simplified Chinese (SC) and Traditional
Chinese (TC) characters is very important for CDN registration. This
memo builds on the basic concepts, general guidelines, and framework
of RFC 3743 to specify proposed registration and administration
procedures for Chinese domain names. The document provides the
information needed for understanding and using the tables defined in
the IANA table registrations for Simplified and Traditional Chinese.
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Chinese Characters .........................................3
2.2. Chinese Domain Name Label (CDNL) ...........................3
2.3. Simplified Chinese Variant Table (SCVT) ....................4
2.4. Traditional Chinese Variant Table (TCVT) ...................4
2.5. Original Chinese Domain Name Label (OCDNL) .................4
3. Procedure for Registration of Chinese Domain Name Labels ........4
3.1. Terminology and Context ....................................4
3.2. Procedure in Terms of the RFC 3743 Model ...................4
3.3. RFC 3743 Optional Registry Processing ......................5
4. Security Considerations .........................................5
5. Acknowledgements ................................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................7
1. Introduction
With the standardization of Internationalized Domain Names for
Application (IDNA, described in [RFC3490], [RFC3491], and [RFC3492]),
internationalized domain names (IDNs), i.e., those that contain non-
ASCII characters, are included in the DNS, and users can access the
Internet with their native languages, most of which are not English.
However, many languages have special requirements, which are not
addressed in the IDNA RFCs. One way to deal with some of the
remaining issues involves grouping characters that could be confused
together as "variants". The variant approach is discussed in RFC
4290 [RFC4290] and specifically for documents written in Chinese,
Japanese, or Korean (CJK documents), in the so-called "JET
Guidelines" RFC 3743 [RFC3743]. Readers of this document are assumed
to be familiar with the concepts and terminology of the latter. The
guidelines specified in this document provide a set of specific
tables and methods required to apply the JET Guidelines to Chinese
characters. For example, changes were made in the forms of a large
number of Chinese characters during the last century to simplify
writing and reading. These "Simplified" characters have been adopted
in some Chinese-speaking communities, while others continue to use
the "Traditional" forms. On the global Internet, if IDNA were used
alone, there would be considerable potential for confusion if the two
forms were not considered together. Consequently, effective use of
Chinese Domain Names (CDNs) requires variant equivalence, as
described in RFC 3743, to handle character differences between
Simplified and Traditional Chinese forms.
Chinese variant equivalence itself is very complicated in principle
(please read [C2C] for further information). When it comes to the
usage of Chinese domain names, the basic requirement is to match the
user perception of Chinese characters between Simplified Chinese (SC)
and Traditional Chinese (TC) forms. When users register SC or TC
domain names, they will wish to obtain the other forms (Traditional
or Simplified, respectively) as well, and expect others to be able to
access the website or other resources in both forms.
This document specifies a solution for Chinese domain name
registration and administration that has been adopted and deployed by
CNNIC (the top-level domain registry for "CN") and TWNIC (the top-
level domain registry for "TW") to manage Simplified Chinese and
Traditional Chinese domain name equivalence. In the terminology of
RFC 3743, this solution is based on Internationalized Domain Labels
(IDLs).
2. Terminology
This document adopts the terminologies that are defined in RFC 3743.
It is not possible to understand this document without first
understanding the concepts and terminology or RFC 3743, including
terminology introduced in its examples. Additional terminology is
defined later in this document.
2.1. Chinese Characters
This document suggests permitting only a subset of Chinese characters
in Chinese Domain Names (CDNs) and hence in the DNS. When this
document discusses Chinese characters, it only refers to the subset
of the characters in the first column of the current IANA
registration tables for Chinese as discussed in Section 2.3 and
Section 2.4. These are defined, in detail, in [LVT-SC] and [LVT-TC].
Of course, characters excluded from these tables are still valid
Chinese characters. However, this document strongly suggests that
registries do not permit any registration of Chinese characters that
are not listed in the tables. The tables themselves will be updated
in the future if necessary.
2.2. Chinese Domain Name Label (CDNL)
If an IDN label includes at least one Chinese character, it is called
a Chinese Domain Name (CDN) Label. CDN labels may contain characters
from the traditional letter-digit-hyphen (LDH) set as well as Chinese
characters.
2.3. Simplified Chinese Variant Table (SCVT)
Based on RFC 3743 [RFC3743], a language table for Simplified Chinese
has been defined [LVT-SC]. It can be used for the registration of
Simplified Chinese domain names. The key feature of this table is
that the preferred variant is the SC character, which is used by
Chinese mainland users or defined in Chinese-related standards.
2.4. Traditional Chinese Variant Table (TCVT)
Similarly, a language table has been defined for Traditional Chinese
[LVT-TC]. It is also based on the rules of RFC 3743. It can be used
for registration of Traditional Chinese domain names. The preferred
variant is the TC character, which is used by Taiwan users or defined
in related standards.
2.5. Original Chinese Domain Name Label (OCDNL)
The Chinese Domain Name Label that users submit for registration.
3. Procedure for Registration of Chinese Domain Name Labels
3.1. Terminology and Context
This document adopts the same procedure for Chinese Domain Name Label
(CDNL) registration as the one defined for more general IDN labels in
section 3.2.3 of RFC 3743 [RFC3743]. The terminology and notation
used below, and the steps that are mentioned, derive from that
document. In particular, "CV" is the character variant associated
with an input character ("IN") and a language table. The language
tables used here are those for Chinese as spoken and written in the
Chinese mainland (ZH-CN) and on Taiwan (ZH-TW). "PV" is the selected
Preferred Variant.
3.2. Procedure in Terms of the RFC 3743 Model
The first column of the Simplified Chinese Variant Table (SCVT) is
the same as the first column of the corresponding Traditional Chinese
Variant Table (TCVT) and so are the third columns of both tables.
Consequently, the CV(IN, ZH-CN) will be same as the CV(IN, ZH-TW)
after Step 3; the PV(IN, ZH-CN) is in SC form, and the PV(IN, ZH-TW)
is in TC form. As a result, there will not be more than three
records (i.e., for the original label (OCDNL), the Simplified Chinese
(SC) form, and the Traditional Chinese (TC) form) to be added into
the zone file after applying this procedure. In other words, the
procedure does not generate labels that contain a mixture of
Simplified and Traditional Chinese as variants.
The set of languages associated with the input (IN) is both ZH-CN and
ZH-TW by default. The procedure for CDNL registration uses the
optional registry-defined rules provided in RFC 3743 for optional
processing, with the understanding that the rules may vary for
different registries supporting CDNs. The motivation for such rules
is described below.
The preferred variant(s) is/are TC in TCVT, and SC in SCVT. There
may be more than one preferred variant for a given valid character.
3.3. RFC 3743 Optional Registry Processing
In actuality, while IDNA, and hence RFC 3743, process characters one
at a time, the actual relationship between the valid code point and
the preferred variant is contextual: whether one character can be
substituted for another depends on the characters with which it is
associated in a label or, more generally, in a phrase. In
particular, some of the preferred variants make no sense in
combination with other characters; therefore, those combinations
should not be added into the Zone file (described as "ZV" or zone
variants in RFC 3743). If desired, it should be possible to define
and implement rules to reduce the preferred variant labels to only
plausible ones. This could be done, for example, with some
artificial intelligence tools, or with feedback from the registrant,
or with selection based on frequency of occurrence in other texts.
To illustrate one possibility, the OCDNL could be required to be TC-
only or SC-only, and if there is more than one preferred variant, the
OCDNL will be used as the PV, instead of the PV produced by the
algorithm.
To reemphasize, the tables in [LVT-SC] and [LVT-TC] follow the table
format and terminologies defined in [RFC3743]. If one intends to
implement Chinese domain name registrations based on these two tables
or ones similar to them, a complete understanding of RFC 3743 is
needed for the proper use of those tables.
4. Security Considerations
This document is subject to the same security considerations as RFC
3743, which defines the table formats and operations. As with that
base document, part of its intent is to reduce the security problems
that might be caused by confusion among characters with similar
appearances or meanings. While it will not introduce any additional
security issues, additional registration restrictions such as those
outlined in Section 3 may further reduce potential problems.
5. Acknowledgements
Thanks to these people for their suggestions and for their efforts to
bring this tough work to conclusion and to promote the results: WANG
YanFeng, Ai-Chin LU, Shian-Shyong TSENG, QIAN HuaLin, and Li-Ming
TSENG.
The authors especially thank Joe ZHANG and XiaoMing WANG for their
outstanding contributions on SCVT in [LVT-SC]. Also, thanks to Kenny
HUANG, Zheng-Wei LIN, Shi-Xiong TSENG, Lie-Neng WU, Cheng-Wu PAN,
Lin-Mei WEI, and Qi-Qing HSU for their efforts and contributions on
editing the TCVT in [LVT-TC]. These experts provided basic materials
or gave very crucial suggestions and principles to accomplish these
two variant tables.
The authors also gratefully acknowledge the contributions of those
who commented and made suggestions on this document, including James
SENG, and other JET members.
6. References
6.1. Normative References
[LVT-SC] QIAN, H. and X. LEE, ".CN Chinese Character Table", IANA
IDN Languages Tables, March 2005.
[LVT-TC] LU, A., ".TW Traditional Chinese Character Table", IANA
IDN Languages Tables, March 2005.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)", RFC
3491, March 2003.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, March 2003.
[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
Engineering Team (JET) Guidelines for Internationalized
Domain Names (IDN) Registration and Administration for
Chinese, Japanese, and Korean", RFC 3743, April 2004.
6.2. Informative References
[C2C] Halpern, J. and J. Kerman, "Pitfalls and Complexities of
Chinese to Chinese Conversion", International Unicode
Conference (14th) in Boston, March 1999.
[RFC4290] Klensin, J., "Suggested Practices for Registration of
Internationalized Domain Names (IDN)", RFC 4290, December
2005.
Authors' Addresses
LEE Xiaodong
CNNIC, No.4 South 4th Street, Zhongguancun
Beijing 100080
Phone: +86 10 58813020
EMail: lee@cnnic.cn
URI: http://www.cnnic.cn
MAO Wei
CNNIC, No.4 South 4th Street, Zhongguancun
Beijing 100080
Phone: +86 10 58813055
EMail: mao@cnnic.cn
URI: http://www.cnnic.cn
Erin CHEN
TWNIC, 4F-2, No. 9, Sec. 2, Roosevelt Rd.
Taipei 100
Phone: +886 2 23411313
EMail: erin@twnic.net.tw
URI: http://www.twnic.net.tw
Nai-Wen HSU
TWNIC, 4F-2, No. 9, Sec. 2, Roosevelt Rd.
Taipei 100
Phone: +886 2 23411313
EMail: snw@twnic.net.tw
URI: http://www.twnic.net.tw
John C KLENSIN
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
EMail: john+ietf@jck.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78 and at www.rfc-editor.org/copyright.html, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
ISO Plain Language
On this page
§1Why the Same Name Has Two Forms
With the standardisation of Internationalized Domain Names for Applications, domain names containing non-ASCII characters are included in the DNS, and users can reach the Internet in their own languages. Many languages have special requirements that the IDNA documents do not address. One way to deal with some of the remaining issues involves grouping characters that could be confused together as variants, an approach discussed in RFC 4290 and, for documents written in Chinese, Japanese or Korean, in the Joint Engineering Team guidelines of RFC 3743.
Changes were made in the forms of a large number of Chinese characters during the last century to simplify writing and reading. These Simplified characters have been adopted in some Chinese-speaking communities, while others continue to use the Traditional forms. On the global Internet, if IDNA were used alone, there would be considerable potential for confusion if the two forms were not considered together. Effective use of Chinese domain names therefore requires variant equivalence, as described in RFC 3743, to handle the character differences between the Simplified and Traditional forms.
Chinese variant equivalence is very complicated in principle. When it comes to the use of Chinese domain names, the basic requirement is to match the user perception of Chinese characters between the Simplified and Traditional forms. When users register Simplified or Traditional domain names, they will wish to obtain the other forms as well, and expect others to be able to access the site or other resources in both forms.
This document specifies a solution for Chinese domain name registration and administration that has been adopted and deployed by CNNIC, the top-level domain registry for CN, and TWNIC, the top-level domain registry for TW, to manage Simplified and Traditional Chinese domain name equivalence. In the terminology of RFC 3743, the solution is based on Internationalized Domain Labels.
Chinese characters were simplified during the last century, and both forms are still in daily use. Without a rule for this, the same website could be registered twice under two spellings, and a link sent by one user would fail for another.
| Aspect | Simplified Chinese | Traditional Chinese |
|---|---|---|
| Table | The Simplified Chinese Variant Table | The Traditional Chinese Variant Table |
| Preferred variant | The Simplified character | The Traditional character |
| Used by | Users in Chinese mainland | Users in Taiwan |
| Language tag | ZH-CN | ZH-TW |
§2The Tables and the Names
The document adopts the terminology defined in RFC 3743, and cannot be understood without first understanding the concepts and terminology of that document, including the terminology introduced in its examples.
The document suggests permitting only a subset of Chinese characters in Chinese domain names and hence in the DNS. When it discusses Chinese characters it refers only to the subset in the first column of the current IANA registration tables for Chinese. Characters excluded from these tables are still valid Chinese characters, but the document strongly suggests that registries do not permit the registration of characters that are not listed in the tables. The tables themselves will be updated in the future if necessary.
A Chinese domain name label is an internationalized domain name label that includes at least one Chinese character. Such a label may also contain characters from the traditional letter-digit-hyphen set.
Two language tables have been defined, both based on the rules of RFC 3743. The Simplified Chinese Variant Table can be used for the registration of Simplified Chinese domain names, and its key feature is that the preferred variant is the Simplified character, the one used by users in Chinese mainland or defined in Chinese-related standards. The Traditional Chinese Variant Table is used for the registration of Traditional Chinese domain names, and its preferred variant is the Traditional character, the one used by users in Taiwan or defined in related standards. The original Chinese domain name label is the label that users submit for registration.
Two tables do the work: one says which character is preferred in Simplified Chinese, the other says the same for Traditional Chinese. Everything else is a label that contains at least one Chinese character, submitted by a user.
§3.2Applying the RFC 3743 Model
The document adopts the same procedure for Chinese domain name label registration as the one defined for more general internationalized domain name labels in Section 3.2.3 of RFC 3743. The terminology and notation derive from that document. The character variant associated with an input character and a language table is abbreviated CV, and the selected preferred variant is abbreviated PV. The language tables used are those for Chinese as spoken and written in Chinese mainland, ZH-CN, and on Taiwan, ZH-TW.
The first column of the Simplified Chinese Variant Table is the same as the first column of the corresponding Traditional Chinese Variant Table, and so are the third columns of both tables. The character variant is therefore the same for both language tables after the third step of the RFC 3743 model, while the preferred variant is in Simplified form in one table and Traditional form in the other. As a result there will not be more than three records to be added to the zone file after applying the procedure: one for the original label, one for the Simplified Chinese form and one for the Traditional Chinese form. The procedure does not generate labels that contain a mixture of Simplified and Traditional Chinese as variants.
The set of languages associated with the input is both ZH-CN and ZH-TW by default. The preferred variant is Traditional in the Traditional table and Simplified in the Simplified table, and there may be more than one preferred variant for a given valid character.
The procedure uses the optional registry-defined rules provided in RFC 3743 for optional processing, with the understanding that the rules may vary for different registries supporting Chinese domain names.
Applying the shared registration model to the two tables produces at most three names for one submission: what the user typed, the same name in Simplified characters, and the same name in Traditional characters. The two forms are never mixed together in one name.
- One submitted label At most three records, and never a mixture of Simplified and Traditional variants
- Original label (OCDNL)
- Simplified Chinese form
- Traditional Chinese form
§3.3Registry Rules for Plausible Combinations
While IDNA, and hence RFC 3743, processes characters one at a time, the actual relationship between a valid code point and the preferred variant is contextual: whether one character can be substituted for another depends on the characters with which it is associated in a label, or more generally in a phrase. Some preferred variants make no sense in combination with other characters, and those combinations should not be added into the zone file, which RFC 3743 describes as zone variants.
If desired, it should be possible to define and implement rules to reduce the preferred variant labels to only plausible ones. This could be done, for example, with some artificial intelligence tools, or with feedback from the registrant, or with selection based on the frequency of occurrence in other texts. To illustrate one possibility, the original Chinese domain name label could be required to be Traditional-only or Simplified-only, and if there is more than one preferred variant, the original label will be used as the preferred variant, instead of the preferred variant produced by the algorithm.
The tables in the IANA registrations follow the table format and terminologies defined in RFC 3743, so a complete understanding of RFC 3743 is needed for the proper use of those tables.
Converting characters one at a time can produce a name that makes no sense, because some characters only work in certain combinations. The registry can therefore apply extra rules of its own to keep only the combinations that are plausible.
- The problemSome preferred variants make no sense in combination with other characters, so those combinations should not be added to the zone file.
- Possible approachesWith artificial intelligence tools, with feedback from the registrant, or with selection based on the frequency of occurrence in other texts.
- One worked exampleThe submitted label could be required to be Traditional-only or Simplified-only, and used as the preferred variant instead of the one the algorithm produces.
- Registries may differThe optional processing rules provided in RFC 3743 may vary for different registries supporting Chinese domain names.
§4Security Considerations
This document is subject to the same security considerations as RFC 3743, which defines the table formats and operations. As with that base document, part of its intent is to reduce the security problems that might be caused by confusion among characters with similar appearances or meanings. While it will not introduce any additional security issues, additional registration restrictions such as those outlined in Section 3 may further reduce potential problems.
The whole point of the variant tables is to stop two characters that look alike from causing confusion, and the extra restrictions on registration reduce that risk a little further.