1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
|
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.
Lee, et al. Informational [Page 1]
^L
RFC 4713 Recommendations for Chinese Domain Names October 2006
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.
Lee, et al. Informational [Page 2]
^L
RFC 4713 Recommendations for Chinese Domain Names October 2006
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.
Lee, et al. Informational [Page 3]
^L
RFC 4713 Recommendations for Chinese Domain Names October 2006
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.
Lee, et al. Informational [Page 4]
^L
RFC 4713 Recommendations for Chinese Domain Names October 2006
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.
Lee, et al. Informational [Page 5]
^L
RFC 4713 Recommendations for Chinese Domain Names October 2006
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.
Lee, et al. Informational [Page 6]
^L
RFC 4713 Recommendations for Chinese Domain Names October 2006
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.
Lee, et al. Informational [Page 7]
^L
RFC 4713 Recommendations for Chinese Domain Names October 2006
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
Lee, et al. Informational [Page 8]
^L
RFC 4713 Recommendations for Chinese Domain Names October 2006
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).
Lee, et al. Informational [Page 9]
^L
|