Network Working Group X.LEE Internet-DraftLee Request for Comments: 4713 W. Mao Category: Informational CNNIC E.CHEN Intended status: Standards Track J. KLENSIN Expires: January 31, 2007Chen N.HSU W. MAO July 30,Hsu TWNIC J. Klensin October 2006 Registration and Administration Recommendations for Chinese Domain Namesdraft-xdlee-idn-cdnadmin-08.txtStatus ofthisThis MemoBy submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents ofThis document specifies an Internet standards track protocol for the InternetEngineering Task Force (IETF), its areas,community, andits working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents validrequests discussion and suggestions fora maximumimprovements. Please refer to the current edition ofsix monthsthe "Internet Official Protocol Standards" (STD 1) for the standardization state andmay be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The liststatus ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The listthis protocol. Distribution ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 31, 2007.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(CDN)(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. . . . . . . . . . . . . . . . . . . . . . . . . 3....................................................2 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 4.....................................................3 2.1. Chinese Characters. . . . . . . . . . . . . . . . . . . . 4.........................................3 2.2. Chinese Domain Name Label (CDNL). . . . . . . . . . . . . 4...........................3 2.3. Simplified Chinese Variant Table (SCVT). . . . . . . . . 4....................4 2.4. Traditional Chinese Variant Table (TCVT). . . . . . . . . 4...................4 2.5. Original Chinese Domain Name Label (OCDNL). . . . . . . . 4.................4 3. Procedure forregistrationRegistration of Chinese Domain Name Labels. . . 5........4 3.1. Terminology and Context. . . . . . . . . . . . . . . . . 5....................................4 3.2. Procedure intermsTerms of the RFC 3743model . . . . . . . . . 5Model ...................4 3.3. RFC 3743 Optional Registry Processing. . . . . . . . . . 5......................5 4. Security Considerations. . . . . . . . . . . . . . . . . . . 7.........................................5 5. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 8................................................6 6. References. . . . . . . . . . . . . . . . . . . . . . . . . . 9......................................................6 6.1. Normative References. . . . . . . . . . . . . . . . . . . 9.......................................6 6.2. Informative References. . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11.....................................7 1. Introduction With the standardization of Internationalized Domain Names for Application (IDNA, described in [RFC3490],[RFC3491][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"charactercharacters 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 Chinesedomain namesDomain 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 otherformforms (Traditional orSimplifiedSimplified, respectively) as well, and expect others to be able to access the website or otherresourceresources 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 RFC3743, [RFC3743]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 Mainland China users or defined inChinese relatedChinese-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 in Taiwan 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 forregistrationRegistration 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 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 intermsTerms of the RFC 3743modelModel 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;Thethe PV(IN, ZH-CN) is in SC form, and the PV(IN, ZH-TW) is in TC form. As a result, therewillwon't benotmore than threerecordrecords (i.e.,the onesfor 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 rulesfor which provision in madeprovided in RFC 3743 for optional processing, with the understanding that the rules may vary for different registries supportingChinese domain names.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 thereareis more than one preferredvariants,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 asRFC3743,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 Thanksforto theseperson'speople for their suggestions,promotionspromotions, and efforts on such tough work: WANG YanFeng, Ai-Chin LU, Shian-Shyong TSENG, QIAN HuaLin, and Li-Ming TSENG.Especially, thanksThe authors especially thank Joe ZHANG and XiaoMing WANG for their outstanding contributions on SCVT in [LVT-SC].And alsoAlso, 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 basicmaterials,materials or gave very crucial suggestions and principles to accomplish these two variant tables.And that, theThe authors also gratefully acknowledge the contributions of those who commented andmakemade 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,Konishi, K.,HUANG,Huang, K.,QIAN,Qian, H., and Y.KO,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 58813020Email: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 23411313Email:EMail: erin@twnic.net.tw URI: http://www.twnic.net.twJohn C KLENSIN 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 Email: john+ietf@jck.comNai-Wen HSU TWNIC, 4F-2, No. 9, Sec. 2, Roosevelt Rd. Taipei 100 Phone: +886 2 23411313Email:EMail: snw@twnic.net.tw URI: http://www.twnic.net.twMAO Wei CNNIC, No.4 South 4th Street, Zhongguancun Beijing 100080John C KLENSIN 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone:+86 10 58813055 Email: mao@cnnic.cn URI: http://www.cnnic.cn+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 BCP78,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.AcknowledgmentAcknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).