idnits 2.17.1 draft-xdlee-idn-cdnadmin-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 376. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 30, 2006) is 6480 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'LVT-SC' -- Possible downref: Non-RFC (?) normative reference: ref. 'LVT-TC' ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3491 (Obsoleted by RFC 5891) ** Downref: Normative reference to an Informational RFC: RFC 3743 Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. LEE 3 Internet-Draft E. CHEN 4 Intended status: Standards Track J. KLENSIN 5 Expires: January 31, 2007 N. HSU 6 W. MAO 7 July 30, 2006 9 Registration and Administration Recommendations for Chinese Domain Names 10 draft-xdlee-idn-cdnadmin-08.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 31, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 Many Chinese characters in common use have variants, which makes most 44 of the Chinese Domain Names (CDN) have at least two different forms. 45 The equivalence between Simplified Chinese (SC) and Traditional 46 Chinese (TC) characters is very important for CDN registration. This 47 memo builds on the basic concepts, general guidelines, and framework 48 of RFC 3743 to specify proposed registration and administration 49 procedures for Chinese domain names. The document provides the 50 information needed for understanding and using the tables defined in 51 the IANA table registrations for Simplified and Traditional Chinese. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Chinese Characters . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Chinese Domain Name Label (CDNL) . . . . . . . . . . . . . 4 59 2.3. Simplified Chinese Variant Table (SCVT) . . . . . . . . . 4 60 2.4. Traditional Chinese Variant Table (TCVT) . . . . . . . . . 4 61 2.5. Original Chinese Domain Name Label (OCDNL) . . . . . . . . 4 62 3. Procedure for registration of Chinese Domain Name Labels . . . 5 63 3.1. Terminology and Context . . . . . . . . . . . . . . . . . 5 64 3.2. Procedure in terms of the RFC 3743 model . . . . . . . . . 5 65 3.3. RFC 3743 Optional Registry Processing . . . . . . . . . . 5 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 70 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 72 Intellectual Property and Copyright Statements . . . . . . . . . . 11 74 1. Introduction 76 With the standardization of Internationalized Domain Names for 77 Application (IDNA, described in [RFC3490], [RFC3491] and [RFC3492]), 78 internationalized domain names (IDNs), i.e., those that contain non- 79 ASCII characters, are included in the DNS, and users can access 80 Internet with their native languages, most of which are not English. 81 However, many languages have special requirements, which are not 82 addressed in the IDNA RFCs. One way to deal with some of the 83 remaining issues involves grouping characters that could be confused 84 together as "variants". The variant approach is discussed in RFC 85 4290 [RFC4290] and specifically for documents written in Chinese, 86 Japanese, or Korean (CJK documents), in the so-called "JET 87 Guidelines" RFC 3743 [RFC3743]. Readers of this document are assumed 88 to be familiar with the concepts and terminology of the latter. The 89 guidelines specified in this document provide a set of specific 90 tables and methods required to apply the JET Guidelines to Chinese 91 characters. For example, changes were made in the forms of a large 92 number of Chinese characters during the last century to simplify 93 writing and reading. These "Simplified" character have been adopted 94 in some Chinese-speaking communities, while others continue to use 95 the "Traditional" forms. On the global Internet, if IDNA were used 96 alone, there would be considerable potential for confusion if the two 97 forms were not considered together. Consequently, effective use of 98 Chinese domain names (CDNs) requires variant equivalence, as 99 described in RFC 3743, to handle character differences between 100 Simplified and Traditional Chinese forms. 102 Chinese variant equivalence itself is very complicated in principle 103 (please read [C2C] for further information). When it comes to the 104 usage of Chinese domain names, the basic requirement is to match the 105 user perception of Chinese characters between Simplified Chinese (SC) 106 and Traditional Chinese (TC) forms. When users register SC or TC 107 domain names, they will wish to obtain the other form (Traditional or 108 Simplified respectively) as well, and expect others to be able to 109 access the website or other resource in both forms. 111 This document specifies a solution for Chinese domain name 112 registration and administration that has been adopted and deployed by 113 CNNIC (the top-level domain registry for "CN") and TWNIC (the top- 114 level domain registry for "TW") to manage Simplified Chinese and 115 Traditional Chinese domain name equivalence. In the terminology of 116 RFC 3743, this solution is based on Internationalized Domain Labels 117 (IDLs). 119 2. Terminology 121 This document adopts the terminologies that are defined in RFC 3743. 122 It is not possible to understand this document without first 123 understanding the concepts and terminology or RFC 3743, including 124 terminology introduced in its examples. Additional terminology is 125 defined later in this document. 127 2.1. Chinese Characters 129 This document suggests permitting only a subset of Chinese characters 130 in Chinese Domain Names (CDNs) and hence in the DNS. When this 131 document discusses Chinese characters, it only refers to the subset 132 of the characters in the first column of the current IANA 133 registration tables for Chinese as discussed in Section 2.3 and 134 Section 2.4. Of course, characters excluded from these tables are 135 still valid Chinese characters. However, this document strongly 136 suggests that registries do not permit any registration of Chinese 137 characters that are not listed in the tables. The tables themselves 138 will be updated in the future if necessary. 140 2.2. Chinese Domain Name Label (CDNL) 142 If an IDN label includes at least one Chinese character, it is called 143 a Chinese Domain Name (CDN) Label. CDN labels may contain characters 144 from the traditional letter-digit-hyphen (LDH) set as well as Chinese 145 characters. 147 2.3. Simplified Chinese Variant Table (SCVT) 149 Based on RFC 3743, [RFC3743] a language table for Simplified Chinese 150 has been defined [LVT-SC]. It can be used for the registration of 151 Simplified Chinese domain names. The key feature of this table is 152 that the preferred variant is the SC character, which is used by 153 Mainland China users or defined in Chinese related standards. 155 2.4. Traditional Chinese Variant Table (TCVT) 157 Similarly, a language table has been defined for Traditional Chinese 158 [LVT-TC]. It is also based on the rules of RFC 3743. It can be used 159 for registration of Traditional Chinese domain names. The preferred 160 variant is the TC character, which is used in Taiwan or defined in 161 related standards. 163 2.5. Original Chinese Domain Name Label (OCDNL) 165 The Chinese Domain Name Label that users submit for registration. 167 3. Procedure for registration of Chinese Domain Name Labels 169 3.1. Terminology and Context 171 This document adopts the same procedure for Chinese Domain Name Label 172 (CDNL) registration as the one defined for more general IDN labels in 173 section 3.2.3 of RFC 3743 [RFC3743]. The terminology and notation 174 used below, and the steps that are mentioned, derive from that 175 document. In particular, "CV" is the character variant associated an 176 input character ("IN") and a language table. The language tables 177 used here are those for Chinese as spoken and written in the Chinese 178 Mainland (ZH-CN) and on Taiwan (ZH-TW). "PV" is the selected 179 Preferred Variant. 181 3.2. Procedure in terms of the RFC 3743 model 183 The first column of the Simplified Chinese Variant Table (SCVT) is 184 the same as the first column of the corresponding Traditional Chinese 185 Variant Table (TCVT) and so are the third columns of both tables. 186 Consequently, the CV(IN, ZH-CN) will be same as the CV(IN, ZH-TW) 187 after Step 3; The PV(IN, ZH-CN) is in SC form, and the PV(IN, ZH-TW) 188 is in TC form. As a result, there will be not more than three record 189 (i.e., the ones for the original label (OCDNL), the Simplified 190 Chinese (SC) form, and the Traditional Chinese (TC) form) to be added 191 into the zone file after applying this procedure. In other words, 192 the procedure does not generate labels that contain a mixture of 193 Simplified and Traditional Chinese as variants. 195 The set of languages associated with the input (IN) is both ZH-CN and 196 ZH-TW by default. The procedure for CDNL registration uses the 197 optional registry-defined rules for which provision in made in RFC 198 3743 for optional processing, with the understanding that the rules 199 may vary for different registries supporting Chinese domain names. 200 The motivation for such rules is described below. 202 The preferred variant(s) is/are TC in TCVT, and SC in SCVT. There 203 may be more than one preferred variant for a given valid character. 205 3.3. RFC 3743 Optional Registry Processing 207 In actuality, while IDNA, and hence RFC 3743, process characters one 208 at a time, the actual relationship between the valid code point and 209 the preferred variant is contextual: whether one character can be 210 substituted for another depends on the characters with which it is 211 associated in a label or, more generally, in a phrase. In 212 particular, some of the preferred variants make no sense in 213 combination with other characters; therefore, those combinations 214 should not be added into the Zone file (described as "ZV" or zone 215 variants in RFC 3743). If desired, it should be possible to define 216 and implement rules to reduce the preferred variant labels to only 217 plausible ones. This could be done, for example, with some 218 artificial intelligence tools, or with feedback from the registrant, 219 or with selection based on frequency of occurrence in other texts. 220 To illustrate one possibility, the OCDNL could be required to be TC- 221 only or SC-only, and if there are more than one preferred variants, 222 the OCDNL will be used as the PV, instead of PV produced by the 223 algorithm. 225 To reemphasize, the tables in [LVT-SC] and [LVT-TC] follow the table 226 format and terminologies defined in [RFC3743]. If one intends to 227 implement Chinese domain name registrations based on these two tables 228 or ones similar to them, a complete understanding of RFC 3743 is 229 needed for the proper use of those tables. 231 4. Security Considerations 233 This document is subject to the same security considerations as 234 RFC3743, which defines the table formats and operations. As with 235 that base document, part of its intent is to reduce the security 236 problems that might be caused by confusion among characters with 237 similar appearances or meanings. While it will not introduce any 238 additional security issues, additional registration restrictions such 239 as those outlined in Section 3 may further reduce potential problems. 241 5. Acknowledgements 243 Thanks for these person's suggestions, promotions and efforts on such 244 tough work: WANG YanFeng, Ai-Chin LU, Shian-Shyong TSENG, QIAN 245 HuaLin, and Li-Ming TSENG. 247 Especially, thanks Joe ZHANG and XiaoMing WANG for their outstanding 248 contributions on SCVT in [LVT-SC]. And also thanks Kenny HUANG, 249 Zheng-Wei LIN, Shi-Xiong TSENG, Lie-Neng WU, Cheng-Wu PAN, Lin-Mei 250 WEI, Qi-Qing HSU for their efforts and contributions on editing the 251 TCVT in [LVT-TC]. These experts provided basic materials, or gave 252 very crucial suggestions and principles to accomplish these two 253 variant tables. 255 And that, the authors gratefully acknowledge the contributions of 256 those who commented and make suggestions on this document, including 257 James SENG, and other JET members. 259 6. References 261 6.1. Normative References 263 [LVT-SC] QIAN, H. and X. LEE, ".CN Chinese Character Table", 264 IANA IDN Languages Tables, March 2005. 266 [LVT-TC] LU, A., ".TW Traditional Chinese Character Table", 267 IANA IDN Languages Tables, March 2005. 269 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 270 "Internationalizing Domain Names in Applications (IDNA)", 271 RFC 3490, March 2003. 273 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 274 Profile for Internationalized Domain Names (IDN)", 275 RFC 3491, March 2003. 277 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 278 for Internationalized Domain Names in Applications 279 (IDNA)", RFC 3492, March 2003. 281 [RFC3743] KONISHI, K., HUANG, K., QIAN, H., and Y. KO, "Joint 282 Engineering Team (JET) Guidelines for Internationalized 283 Domain Names (IDN) Registration and Administration for 284 Chinese, Japanese, and Korean", RFC 3743, April 2004. 286 6.2. Informative References 288 [C2C] Halpern, J. and J. Kerman, "Pitfalls and Complexities of 289 Chinese to Chinese Conversion", International Unicode 290 Conference (14th) in Boston, March 1999. 292 [RFC4290] Klensin, J., "Suggested Practices for Registration of 293 Internationalized Domain Names (IDN)", RFC 4290, 294 December 2005. 296 Authors' Addresses 298 LEE Xiaodong 299 CNNIC, No.4 South 4th Street, Zhongguancun 300 Beijing 100080 302 Phone: +86 10 58813020 303 Email: lee@cnnic.cn 304 URI: http://www.cnnic.cn 306 Erin CHEN 307 TWNIC, 4F-2, No. 9, Sec. 2, Roosevelt Rd. 308 Taipei 100 310 Phone: +886 2 23411313 311 Email: erin@twnic.net.tw 312 URI: http://www.twnic.net.tw 314 John C KLENSIN 315 1770 Massachusetts Ave, #322 316 Cambridge, MA 02140 317 USA 319 Phone: +1 617 491 5735 320 Email: john+ietf@jck.com 322 Nai-Wen HSU 323 TWNIC, 4F-2, No. 9, Sec. 2, Roosevelt Rd. 324 Taipei 100 326 Phone: +886 2 23411313 327 Email: snw@twnic.net.tw 328 URI: http://www.twnic.net.tw 330 MAO Wei 331 CNNIC, No.4 South 4th Street, Zhongguancun 332 Beijing 100080 334 Phone: +86 10 58813055 335 Email: mao@cnnic.cn 336 URI: http://www.cnnic.cn 338 Full Copyright Statement 340 Copyright (C) The Internet Society (2006). 342 This document is subject to the rights, licenses and restrictions 343 contained in BCP 78, and except as set forth therein, the authors 344 retain all their rights. 346 This document and the information contained herein are provided on an 347 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 348 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 349 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 350 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 351 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 352 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 354 Intellectual Property 356 The IETF takes no position regarding the validity or scope of any 357 Intellectual Property Rights or other rights that might be claimed to 358 pertain to the implementation or use of the technology described in 359 this document or the extent to which any license under such rights 360 might or might not be available; nor does it represent that it has 361 made any independent effort to identify any such rights. Information 362 on the procedures with respect to rights in RFC documents can be 363 found in BCP 78 and BCP 79. 365 Copies of IPR disclosures made to the IETF Secretariat and any 366 assurances of licenses to be made available, or the result of an 367 attempt made to obtain a general license or permission for the use of 368 such proprietary rights by implementers or users of this 369 specification can be obtained from the IETF on-line IPR repository at 370 http://www.ietf.org/ipr. 372 The IETF invites any interested party to bring to its attention any 373 copyrights, patents or patent applications, or other proprietary 374 rights that may cover technology that may be required to implement 375 this standard. Please address the information to the IETF at 376 ietf-ipr@ietf.org. 378 Acknowledgment 380 Funding for the RFC Editor function is provided by the IETF 381 Administrative Support Activity (IASA).