Network Working Group K. Konishi
Request for Comments: 3743 K. Huang
Category: Informational H. Qian
Y. Ko
April 2004
Network Working Group K. Konishi
Request for Comments: 3743 K. Huang
Category: Informational H. Qian
Y. Ko
April 2004
Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean
联合工程团队（JET）中文、日文和韩文国际化域名（IDN）注册和管理指南
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 (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
IESG Note
IESG注释
The IESG congratulates the Joint Engineering Team (JET) on developing mechanisms to enforce their desired policy. The Language Variant Table mechanisms described here allow JET to enforce language-based character variant preferences, and they set an example for those who might want to use variant tables for their own policy enforcement.
IESG祝贺联合工程团队（JET）制定了执行其预期政策的机制。这里描述的语言变体表机制允许JET强制执行基于语言的字符变体首选项，它们为那些可能希望使用变体表强制执行自己策略的人树立了榜样。
The IESG encourages those following this example to take JET's diligence as an example, as well as its technical work. To follow their example, registration authorities may need to articulate policy, develop appropriate procedures and mechanisms for enforcement, and document the relationship between the two. JET's LVT mechanism should be adaptable to different policies, and can be considered during that development process.
IESG鼓励那些遵循此示例的人以JET的勤奋以及其技术工作为例。为了仿效他们的榜样，登记当局可能需要阐明政策，制定适当的程序和执行机制，并记录两者之间的关系。JET的LVT机制应该适应不同的政策，并且可以在开发过程中加以考虑。
The IETF does not, of course, dictate policy or require the use of any particular mechanisms for the implementation of these policies, as these are matters of sovereignty and contract.
当然，IETF不规定政策或要求使用任何特定机制来实施这些政策，因为这些是主权和合同问题。
Abstract
摘要
Achieving internationalized access to domain names raises many complex issues. These are associated not only with basic protocol design, such as how names are represented on the network, compared, and converted to appropriate forms, but also with issues and options for deployment, transition, registration, and administration.
实现域名的国际化访问提出了许多复杂的问题。这些问题不仅与基本协议设计相关，例如名称在网络上的表示、比较和转换为适当形式的方式，还与部署、转换、注册和管理的问题和选项相关。
The IETF Standards for Internationalized Domain Names, known as "IDNA", focuses on access to domain names in a range of scripts that is broader in scope than the original ASCII. The development process made it clear that use of characters with similar appearances and/or interpretations created potential for confusion, as well as difficulties in deployment and transition. The conclusion was that, while those issues were important, they could best be addressed administratively rather than through restrictions embedded in the protocols. This document defines a set of guidelines for applying restrictions of that type for Chinese, Japanese and Korean (CJK) scripts and the zones that use them and, perhaps, the beginning of a framework for thinking about other zones, languages, and scripts.
IETF的国际化域名标准（称为“IDNA”）侧重于在一系列脚本中访问域名，这些脚本的范围比原始ASCII更广。发展过程清楚地表明，使用具有相似外观和/或解释的角色可能会造成混淆，以及部署和过渡方面的困难。结论是，虽然这些问题很重要，但最好通过行政手段而不是通过议定书中的限制来解决。本文档定义了一套指南，用于对中文、日文和韩文（CJK）脚本和使用它们的区域应用此类限制，并且可能是思考其他区域、语言和脚本的框架的开始。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions, Context, and Notation . . . . . . . . . . . . . . 5
2.1. Definitions and Context. . . . . . . . . . . . . . . . . 5
2.2. Notation for Ideographs and Other Non-ASCII CJK
Characters . . . . . . . . . . . . . . . . . . . . . . . 9
3. Scope of the Administrative Guidelines . . . . . . . . . . . . 9
3.1. Principles Underlying These Guidelines . . . . . . . . . 10
3.2. Registration of IDL. . . . . . . . . . . . . . . . . . . 13
3.2.1. Using the Language Variant Table . . . . . . . . 13
3.2.2. IDL Package. . . . . . . . . . . . . . . . . . . 14
3.2.3. Procedure for Registering IDLs . . . . . . . . . 14
3.3. Deletion and Transfer of IDL and IDL Package . . . . . . 19
3.4. Activation and Deactivation of IDL Variants . . . . . . 19
3.4.1. Activation Algorithm . . . . . . . . . . . . . . 19
3.4.2. Deactivation Algorithm . . . . . . . . . . . . . 20
3.5. Managing Changes in Language Associations. . . . . . . . 21
3.6. Managing Changes to Language Variant Tables. . . . . . . 21
4. Examples of Guideline Use in Zones . . . . . . . . . . . . . . 21
5. Syntax Description for the Language Variant Table. . . . . . . 25
5.1. ABNF Syntax. . . . . . . . . . . . . . . . . . . . . . . 25
5.2. Comments and Explanation of Syntax . . . . . . . . . . . 25
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 27
7. Index to Terminology . . . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . 30
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Authors' Addresses . . . . . . . . . . . . . . . . . . . 31
10.2. Editors' Addresses . . . . . . . . . . . . . . . . . . . 32
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions, Context, and Notation . . . . . . . . . . . . . . 5
2.1. Definitions and Context. . . . . . . . . . . . . . . . . 5
2.2. Notation for Ideographs and Other Non-ASCII CJK
Characters . . . . . . . . . . . . . . . . . . . . . . . 9
3. Scope of the Administrative Guidelines . . . . . . . . . . . . 9
3.1. Principles Underlying These Guidelines . . . . . . . . . 10
3.2. Registration of IDL. . . . . . . . . . . . . . . . . . . 13
3.2.1. Using the Language Variant Table . . . . . . . . 13
3.2.2. IDL Package. . . . . . . . . . . . . . . . . . . 14
3.2.3. Procedure for Registering IDLs . . . . . . . . . 14
3.3. Deletion and Transfer of IDL and IDL Package . . . . . . 19
3.4. Activation and Deactivation of IDL Variants . . . . . . 19
3.4.1. Activation Algorithm . . . . . . . . . . . . . . 19
3.4.2. Deactivation Algorithm . . . . . . . . . . . . . 20
3.5. Managing Changes in Language Associations. . . . . . . . 21
3.6. Managing Changes to Language Variant Tables. . . . . . . 21
4. Examples of Guideline Use in Zones . . . . . . . . . . . . . . 21
5. Syntax Description for the Language Variant Table. . . . . . . 25
5.1. ABNF Syntax. . . . . . . . . . . . . . . . . . . . . . . 25
5.2. Comments and Explanation of Syntax . . . . . . . . . . . 25
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 27
7. Index to Terminology . . . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . 30
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Authors' Addresses . . . . . . . . . . . . . . . . . . . 31
10.2. Editors' Addresses . . . . . . . . . . . . . . . . . . . 32
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33
Domain names form the fundamental naming architecture of the Internet. Countless Internet protocols and applications rely on them, not just for stability and continuity, but also to avoid ambiguity. They were designed to be identifiers without any language context. However, as domain names have become visible to end users through Web URLs and e-mail addresses, the strings in domain-name labels are being increasingly interpreted as names, words, or phrases. It is likely that users will do the same with languages of differing character sets, such as Chinese, Japanese and Korean (CJK), in which many words or concepts are represented using short sequences of characters.
域名构成了互联网的基本命名架构。无数的互联网协议和应用程序依赖于它们，这不仅是为了稳定性和连续性，也是为了避免歧义。它们被设计成没有任何语言背景的标识符。然而，随着最终用户通过Web URL和电子邮件地址看到域名，域名标签中的字符串越来越多地被解释为名称、单词或短语。用户可能会对不同字符集的语言（如中文、日文和韩文（CJK））采取同样的做法，在这些语言中，许多单词或概念都是使用短字符序列表示的。
The introduction of what are called Internationalized Domain Names (IDN) amplifies both the difficulty of putting names into identifiers and the confusion that exists between scripts and languages. Character symbols that appear (or actually are) identical, or that have similar or identical semantics but that are assigned the different code points, further increase the potential for confusion. DNS internationalization also affects a number of Internet protocols and applications and creates additional layers of complexity in terms of technical administration and services. Given the added complications of using a much broader range of characters than the original small ASCII subset, precautions are necessary in the deployment of IDNs in order to minimize confusion and fraud.
所谓的国际化域名（IDN）的引入既增加了将名称放入标识符的难度，也增加了脚本和语言之间存在的混淆。看起来（或实际上）相同的字符符号，或具有相似或相同语义但分配了不同代码点的字符符号，进一步增加了混淆的可能性。DNS国际化还影响许多互联网协议和应用程序，并在技术管理和服务方面造成额外的复杂性。由于使用比原来的小ASCII子集更广泛的字符范围会增加复杂性，因此在部署IDN时必须采取预防措施，以最大限度地减少混淆和欺诈。
The IETF IDN Working Group [IDN-WG] addressed the problem of handling the encoding and decoding of Unicode strings into and out of Domain Name System (DNS) labels with the goal that its solution would not put the operational DNS at any risk. Its work resulted in one primary protocol and three supporting ones, respectively:
IETF IDN工作组[IDN-WG]解决了处理Unicode字符串进出域名系统（DNS）标签的编码和解码问题，其目标是其解决方案不会使操作DNS面临任何风险。其工作分别产生了一个主要协议和三个支持协议：
1. Internationalizing Host Names in Applications [IDNA] 2. Preparation of Internationalized Strings [STRINGPREP] 3. A Stringprep Profile for Internationalized Domain Names [NAMEPREP] 4. Punycode [PUNYCODE]
1. 国际化应用程序中的主机名[IDNA]2。准备国际化字符串[STRINGPREP]3。国际化域名的Stringprep配置文件[NAMEPREP]4。Punycode[Punycode]
IDNA, which calls on the others, normalizes and transforms strings that are intended to be used as IDNs. In combination, the four provide the minimum functions required for internationalization, such as performing case mappings, eliminating character differences that would cause severe problems, and specifying matching (equality). They also convert between the resulting Unicode code points and an ASCII-based form that is more suitable for storing in actual DNS labels. In this way, the IDNA transformations improve a user's chances of getting to the correct IDN.
IDNA调用其他函数，对用作IDN的字符串进行规范化和转换。这四种方法结合起来提供了国际化所需的最低功能，例如执行大小写映射、消除可能导致严重问题的字符差异以及指定匹配（相等）。它们还可以在生成的Unicode代码点和更适合存储在实际DNS标签中的基于ASCII的形式之间进行转换。这样，IDNA转换提高了用户获得正确IDN的机会。
Addressing the issues around differing character sets, a primary consideration and administrative challenge involves region-specific definitions, interpretations, and the semantics of strings to be used in IDNs. A Unicode string may have a specific meaning as a name, word, or phrase in a particular language but that meaning could vary depending on the country, region, culture, or other context in which the string is used. It might also have different interpretations in different languages that share some or all of the same characters. Therefore, individual zones and zone administrators may find it necessary to impose restrictions and procedures to reduce the likelihood of confusion, and instabilities of reference, within their own environments.
解决不同字符集的问题，主要考虑和管理挑战涉及IDN中使用的特定于区域的定义、解释和字符串语义。Unicode字符串可能具有特定的含义，如特定语言中的名称、单词或短语，但该含义可能因使用该字符串的国家、地区、文化或其他上下文而异。它也可能在不同的语言中有不同的解释，这些语言共享一些或所有相同的字符。因此，各个区域和区域管理员可能会发现有必要实施限制和程序，以减少在其自身环境中出现混淆和参考不稳定性的可能性。
Over the centuries, the evolution of CJK characters, and the differences in their use in different languages and even in different regions where the same language is spoken, has given rise to the idea of "variants", wherein one conceptual character can be identified with several different Code Points in character sets for computer use. This document provides a framework for handling such variants while minimizing the possibility of serious user confusion in the obtaining or using of domain names. However, the concept of variants is complex and may require many different layers of solutions. This guideline offers only one of those solution components. It is not sufficient by itself to solve the whole problem, even with zone-specific tables as described below.
几个世纪以来，CJK字符的演变，以及它们在不同语言中甚至在使用同一语言的不同地区的使用差异，产生了“变体”的概念，其中一个概念性字符可以通过字符集中的几个不同代码点来识别，以供计算机使用。本文档提供了一个处理此类变体的框架，同时最大限度地减少了用户在获取或使用域名时严重混淆的可能性。然而，变体的概念很复杂，可能需要许多不同层次的解决方案。本指南仅提供其中一个解决方案组件。单靠它本身还不足以解决整个问题，即使使用下面描述的特定于区域的表也是如此。
Additionally, because of local language or writing-system differences, it is impossible to create universally accepted definitions for which potential variants are the same and which are not the same. It is even more difficult to define a technical algorithm to generate variants that are linguistically accurate. That is, that the variant forms produced make as much sense in the language as the originally specified forms. It is also possible that variants generated may have no meaning in the associated language or languages. The intention is not to generate meaningful "words" but to generate similar variants to be reserved. So even though the method described in this document may not always be linguistically accurate, nor does it need to be, it increases the chances of getting the right variants while accepting the inherent limitations of the DNS and the complexities of human language.
此外，由于当地语言或书写系统的差异，不可能为潜在变体相同和不同的变体创建普遍接受的定义。更难定义一种技术算法来生成语言准确的变体。也就是说，产生的变体形式在语言中与最初指定的形式一样有意义。生成的变体也可能在相关语言中没有意义。其目的不是生成有意义的“单词”，而是生成要保留的类似变体。因此，尽管本文档中描述的方法在语言上可能并不总是准确的，也不一定是准确的，但它增加了获得正确变体的机会，同时接受DNS固有的局限性和人类语言的复杂性。
This document outlines a model for such conventions for zones in which labels that contain CJK characters are to be registered and a system for implementing that model. It provides a mechanism that allows each zone to define its own local rules for permitted characters and sequences and the handling of IDNs and their variants.
本文档概述了将在其中注册包含CJK字符的标签的区域的此类约定的模型以及用于实现该模型的系统。它提供了一种机制，允许每个区域为允许的字符和序列以及IDN及其变体的处理定义自己的本地规则。
The document is an effort of the Joint Engineering Team (JET), a group composed of members of CNNIC, TWNIC, KRNIC, and JPNIC as well as other individual experts. It offers guidelines for zone administrators, including but not limited to registry operators and registrars and information for all domain names holders on the administration of domain names that contain characters drawn from Chinese, Japanese, and Korean scripts. Other language groups are encouraged to develop their own guidelines as needed, based on these guidelines if that is helpful.
该文件是联合工程团队（JET）的成果，该团队由CNNIC、TWNIC、KRNIC和JPNIC的成员以及其他个人专家组成。它为区域管理员（包括但不限于注册运营商和注册商）提供了指南，并为所有域名持有人提供了关于管理包含中文、日文和韩文字符的域名的信息。鼓励其他语言团体根据需要制定自己的指导方针，如果这些指导方针有用的话。
This document uses a number of special terms. In this section, definitions and explanations are grouped topically. Some readers may prefer to skip over this material, returning, perhaps via the index to terminology in section 7, when needed.
本文件使用了一些特殊术语。在本节中，定义和解释按主题分组。有些读者可能更愿意跳过本资料，在需要时，可以通过第7节中的术语索引返回。
IDN: The term "IDN" has a number of different uses: (a) as an abbreviation for "Internationalized Domain Name"; (b) as a fully qualified domain name that contains at least one label that contains characters not appearing in ASCII, specifically not in the subset of ASCII recommended for domain names (the so-called "hostname" or "LDH" subset, see RFC1035 [STD13]); (c) as a label of a domain name that contains at least one character beyond ASCII; (d) as a Unicode string to be processed by Nameprep; (e) as a string that is an output from Nameprep; (f) as a string that is the result of processing through both Nameprep and conversion into Punycode; (g) as the abbreviation of an IDN (more properly, IDL) Package, in the terminology of this document; (h) as the abbreviation of the IETF IDN Working Group; (g) as the abbreviation of the ICANN IDN Committee; and (h) as standing for other IDN activities in other companies/organizations.
IDN：术语“IDN”有许多不同的用途：（a）作为“国际化域名”的缩写；（b） 作为一个完全限定的域名，至少包含一个标签，其中包含ASCII中未出现的字符，特别是未出现在为域名推荐的ASCII子集（所谓的“主机名”或“LDH”子集，请参见RFC1035[STD13]）；（c） 作为域名的标签，至少包含ASCII以外的一个字符；（d） 作为要由Nameprep处理的Unicode字符串；（e） 作为Nameprep输出的字符串；（f） 作为通过Nameprep和转换为Punycode处理的结果的字符串；（g） 作为IDN（更准确地说，IDL）包的缩写，在本文件术语中；（h） 作为IETF IDN工作组的缩写；（g） 作为ICANN IDN委员会的缩写；（h）代表其他公司/组织的其他IDN活动。
Because of the potential confusion, this document uses the term "IDN" as an abbreviation for Internationalized Domain Name and, specifically, in the second sense described in (b) above. It uses "IDL," defined immediately below, to refer to Internationalized Domain Labels.
由于潜在的混淆，本文件使用术语“IDN”作为国际化域名的缩写，具体而言，是上文（b）中所述的第二种含义。它使用下面定义的“IDL”来表示国际化的域标签。
IDL: This document provides a guideline to be applied on a per-zone basis, one label at a time. Therefore, the term "Internationalized Domain Label" or "IDL" will be used instead of the more general term "IDN" or its equivalents. The processing specifications of this
IDL：本文件提供了一个指南，以每个区域为基础，每次使用一个标签。因此，将使用术语“国际化域标签”或“IDL”，而不是更一般的术语“IDN”或其等价物。本产品的加工规格
document may be applied, in some zones, to ASCII characters also, if those characters are specified as valid in a Language Variant Table (see below). Hence, in some zones, an IDL may contain or consist entirely of "LDH" characters.
在某些区域，如果ASCII字符在语言变量表中被指定为有效字符，则文档也可以应用于ASCII字符（见下文）。因此，在某些区域中，IDL可能包含或完全由“LDH”字符组成。
FQDN: A fully qualified domain name, one that explicitly contains all labels, including a Top-Level Domain (TLD) name. In this context, a TLD name is one whose label appears in a nameserver record in the root zone. The term "Domain Name Label" refers to any label of a FQDN.
FQDN：完全限定的域名，显式包含所有标签，包括顶级域名（TLD）。在此上下文中，TLD名称是其标签出现在根区域的名称服务器记录中的名称。术语“域名标签”指FQDN的任何标签。
Registration: In this document, the term "registration" refers to the process by which a potential domain name holder requests that a label be placed in the DNS either as an individual name within a domain or as a subdomain delegation from another domain name holder. In the case of a successful registration, the label or delegation records are placed in the relevant zone file, or, more specifically, they are "activated" or made "active" and additional IDLs may be reserved as part of an "IDL Package" (see below). The guidelines presented here are recommended for all zones, at any hierarchy level, in which CJK characters are to appear and not just domains at the first or second level.
注册：在本文件中，术语“注册”是指潜在域名持有人请求将标签作为域内的个人名称或另一域名持有人的子域授权放置在DNS中的过程。在成功注册的情况下，标签或授权记录被放置在相关区域文件中，或者更具体地说，它们被“激活”或被设置为“激活”，并且额外的IDL可以作为“IDL包”的一部分保留（见下文）。此处提供的指南建议用于所有区域，在任何层次结构级别，其中将显示CJK字符，而不仅仅是第一级或第二级的域。
RFC3066: A system, widely used in the Internet, for coding and representing names of languages [RFC3066]. It is based on an International Organization for Standardization (ISO) standard for coding language names [ISO639], but expands it to provide additional precision.
RFC3066：互联网上广泛使用的一种系统，用于编码和表示语言名称[RFC3066]。它基于国际标准化组织（ISO）的语言名称编码标准[ISO639]，但对其进行了扩展以提供额外的精度。
ISO/IEC 10646: The international standard universal multiple-octet coded character set ("UCS") [IS10646]. The Code Point definitions of this standard are identical to those of corresponding versions of the Unicode standard (see below). Consequently, the characters and their coding are often referred to as "Unicode characters."
ISO/IEC 10646：国际标准通用多八位编码字符集（“UCS”）[IS10646]。本标准的代码点定义与Unicode标准相应版本的代码点定义相同（见下文）。因此，字符及其编码通常被称为“Unicode字符”
Unicode Character: The term "Unicode character" is used here in reference to characters chosen from the Unicode Standard Version 3.2 [UNICODE] (and hence from ISO/IEC 10646). In this document, the
Unicode字符：这里使用术语“Unicode字符”指的是从Unicode标准版本3.2[Unicode]（以及ISO/IEC 10646）中选择的字符。在本文件中
characters are identified by their positions, or "Code Points." The notation U+12AB, for example, indicates the character at the position 12AB (hexadecimal) in the Unicode 3.2 table. For characters in positions above FFFF, i.e., requiring more than sixteen bits to represent, a five to eight-character string is used, such as U+112AB for the character in position 12AB of plane 1.
字符由其位置或“代码点”标识。例如，符号U+12AB表示Unicode 3.2表中12AB（十六进制）位置的字符。对于FFFF以上位置的字符，即需要超过16位来表示的字符，使用5到8个字符串，例如平面1的12AB位置的字符使用U+112AB。
Unicode String: "Unicode string" refers to a string of Unicode characters. The Unicode string is identified by the sequence of the Unicode characters regardless of the encoding scheme.
Unicode字符串：“Unicode字符串”是指Unicode字符的字符串。Unicode字符串由Unicode字符序列标识，而与编码方案无关。
CJK Characters: CJK characters are characters commonly used in the Chinese, Japanese, or Korean languages, including but not limited to those defined in the Unicode Standard as ASCII (U+0020 to U+007F), Han ideographs (U+3400 to U+9FAF and U+20000 to U+2A6DF), Bopomofo (U+3100 to U+312F and U+31A0 to U+31BF), Kana (U+3040 to U+30FF), Jamo (U+1100 to 11FF and U+3130 to U+318F), Hangul (U+AC00 to U+D7AF and U+3130 to U+318F), and the respective compatibility forms. The particular characters that are permitted in a given zone are specified in the Language Variant Table(s) for that zone.
CJK字符：CJK字符是中文、日文或韩文中常用的字符，包括但不限于Unicode标准中定义的ASCII（U+0020至U+007F）、汉字（U+3400至U+9FAF和U+20000至U+2A6DF）、Bopomofo（U+3100至U+312F和U+31A0至U+31BF）、假名（U+3040至U+30FF）、Jamo（U+1100至11FF和U+3130至U+318F）、韩语（U+AC00至U+D7AF和U+3130至U+318F）以及相应的兼容格式。给定区域中允许的特定字符在该区域的语言变体表中指定。
Label String: A generic term referring to a string of characters that is a candidate for registration in the DNS or such a string, once registered. A label string may or may not be valid according to the rules of this specification and may even be invalid for IDNA use. The term "label", by itself, refers to a string that has been validated and may be formatted to appear in a DNS zone file.
标签字符串：一个通用术语，指在DNS中注册的候选字符串或此类字符串，一旦注册。根据本规范的规则，标签字符串可能有效，也可能无效，甚至可能对IDNA使用无效。术语“标签”本身指的是已验证的字符串，可以格式化为显示在DNS区域文件中。
Language Variant Table: The key mechanisms of this specification utilize a three-column table, called a Language Variant Table, for each language permitted to be registered in the zone. Those columns are known, respectively, as "Valid Code Point", "Preferred Variant", and "Character Variant", which are defined separately below. The Language Variant Tables are critical to the success of the guideline described in this document. However, the principles to be used to generate the tables are not within the scope of this document and should be worked out by each registry separately (perhaps by adopting or adapting the work of some other registry). In this document, "Table" and "Variant Table" are used as short forms for Language Variant Table.
语言变体表：本规范的关键机制为允许在区域中注册的每种语言使用一个称为语言变体表的三列表。这些列分别称为“有效代码点”、“首选变量”和“字符变量”，它们在下面分别定义。语言变体表对于本文件中所述指南的成功至关重要。然而，用于生成表格的原则不在本文件的范围内，应由每个登记处单独制定（也许通过采纳或调整其他登记处的工作）。在本文件中，“表格”和“变体表格”用作语言变体表格的缩写形式。
Valid Code Point: In a Language Variant Table, the list of Code Points that is permitted for that language. Any other Code Points, or any string containing them, will be rejected by this specification. The Valid Code Point list appears as the first column of the Language Variant Table.
有效代码点：在语言变体表中，该语言允许的代码点列表。本规范将拒绝任何其他代码点或包含它们的任何字符串。有效代码点列表显示为语言变量表的第一列。
Preferred Variant: In a Language Variant Table, a list of Code Points corresponding to each Valid Code Point and providing possible substitutions for it. These substitutions are "preferred" in the sense that the variant labels generated using them are normally registered in the zone file, or "activated." The Preferred Code Points appear in column 2 of the Language Variant Table. "Preferred Code Point" is used interchangeably with this term.
首选变体：在语言变体表中，与每个有效代码点对应的代码点列表，并为其提供可能的替换。这些替换是“首选”的，因为使用它们生成的变体标签通常在区域文件中注册或“激活”。首选代码点显示在语言变体表的第2列中。“首选代码点”可与本术语互换使用。
Character Variant: In a Language Variant Table, a second list of Code Points corresponding to each Valid Code Point and providing possible substitutions for it. Unlike the Preferred Variants, substitutions based on Character Variants are normally reserved but not actually registered (or "activated"). Character Variants appear in column 3 of the Language Variant Table. The term "Code Point Variants" is used interchangeably with this term.
字符变体：在语言变体表中，对应于每个有效代码点的第二个代码点列表，并为其提供可能的替换。与首选变体不同，基于字符变体的替换通常是保留的，但实际上没有注册（或“激活”）。字符变体出现在语言变体表的第3列中。术语“代码点变体”可与该术语互换使用。
Preferred Variant Label: A label generated by use of Preferred Variants (or Preferred Code Points).
首选变体标签：使用首选变体（或首选代码点）生成的标签。
Character Variant Label: A label generated by use of Character Variants.
字符变体标签：使用字符变体生成的标签。
Zone Variant: A Preferred or Character Variant Label that is actually to be entered (registered) into the DNS. That is, into the zone file for the relevant zone. Zone Variants are also referred to as Zone Variant Labels or Active (or Activated) Labels.
区域变体：实际要输入（注册）到DNS中的首选或字符变体标签。也就是说，输入相关分区的分区文件。分区变量也称为分区变量标签或活动（或激活）标签。
IDL Package: A collection of IDLs as determined by these Guidelines. All labels in the package are "reserved", meaning they cannot be registered by anyone other than the holder of the Package. These reserved IDLs may be "activated", meaning they are actually entered into a zone file as a "Zone Variant". The IDL Package also contains identification of the language(s) associated with the registration process. The IDL and its variant labels form a single, atomic unit.
IDL包：由这些指南确定的IDL集合。包装中的所有标签都是“保留”的，这意味着除了包装持有者之外，任何人都不能注册这些标签。这些保留IDL可能被“激活”，这意味着它们实际上作为“区域变量”输入到区域文件中。IDL包还包含与注册过程相关的语言标识。IDL及其变体标签构成一个单一的原子单元。
2.2. Notation for Ideographs and Other Non-ASCII CJK Characters.
2.2. 表意文字和其他非ASCII CJK字符的符号。
For purposes of clarity, particularly in regard to examples, Han ideographs appear in several places in this document. However, they do not appear in the ASCII version of this document. For the convenience of readers of the ASCII version, and some readers not familiar with recognizing and distinguishing Chinese characters, most uses of these characters will be associated with both their Unicode Code Points and an "asterisk tag" with its corresponding Chinese Romanization [ISO7098], with the tone mark represented by a number from 1 to 4. Those tags have no meaning outside this document; they are a quick visual and reading reference to help facilitate the combinations and transformations of characters in the guideline and table excerpts.
为清晰起见，尤其是在示例方面，本文件中的几个地方出现了汉字。但是，它们不会出现在本文档的ASCII版本中。为了方便ASCII版本的读者，以及一些不熟悉识别和区分汉字的读者，这些汉字的大多数用法都将与其Unicode代码点和带有相应中文罗马化的“星号标记”相关联[ISO7098]，带有由1到4之间的数字表示的音调标记。这些标签在本文件之外没有任何意义；它们是一个快速的视觉和阅读参考，有助于促进指南和表格摘录中字符的组合和转换。
Zone administrators are responsible for the administration of the domain name labels under their control. A zone administrator might be responsible for a large zone, such as a top-level domain (TLD), whether generic or country code, or a smaller one, such as a typical second- or third-level domain. A large zone is often more complex than its smaller counterpart. However, actual technical administrative tasks, such as addition, deletion, delegation, and transfer of zones between domain name holders, are similar for all zones.
区域管理员负责管理其控制下的域名标签。区域管理员可能负责大型区域，例如顶级域（TLD），无论是通用代码还是国家代码，也可能负责较小的区域，例如典型的二级或三级域。大区域往往比小区域更复杂。然而，实际的技术管理任务，如添加、删除、委派和域名持有者之间的区域转移，对于所有区域都是类似的。
This document provides guidelines for the ways CJK characters should be handled within a zone, for how language issues should be considered and incorporated, and for how Domain Name Labels containing CJK characters should be administered (including registration, deletion, and transfer of labels).
本文档提供了在区域内处理CJK字符的方法、如何考虑和合并语言问题以及如何管理包含CJK字符的域名标签（包括标签的注册、删除和转移）的指南。
Other IDN policies, such as the creation of new top-level domains (TLDs), the cost structure for registrations, and how the processes described here get allocated between registrar and registry if the zone makes that distinction, also are outside the scope of this document.
其他IDN政策，如创建新的顶级域（TLD）、注册的成本结构，以及如果区域做出区分，此处描述的流程如何在注册商和注册商之间分配，也不在本文档的范围内。
Technical implementation issues are not discussed here either. For example, deciding which guidelines should be implemented as registry actions and which should be registrar actions is left to zone administrators, with the possibility that it will differ from zone to zone.
这里也不讨论技术实现问题。例如，决定哪些指南应作为注册表操作实施，哪些指南应作为注册器操作实施，则留给区域管理员来决定，这可能会因区域而异。
In many places, in the event of a dispute over rights to a name (or, more accurately, DNS label string), this document assumes "first-come, first-served" (FCFS) as a resolution policy even though FCFS is not listed below as one of the principles for this document. If policies are already in place governing priorities and "rights", one can use the guidelines here by replacing uses of FCFS in this document with policies specific to the zone. Some of the guidelines here may not be applicable to other policies for determining rights to labels. Still other alternatives, such as use of UDRP [UDRP] or mutual exclusion, might have little impact on other aspects of these guidelines.
在许多地方，如果对名称（或更准确地说，DNS标签字符串）的权利发生争议，本文档假定“先到先得”（FCFS）为解决策略，即使FCFS未列为本文档的原则之一。如果已经制定了管理优先权和“权利”的政策，则可以使用此处的指南，将本文件中FCF的使用替换为特定于该区域的政策。此处的一些指南可能不适用于确定标签权利的其他政策。还有其他替代方案，如使用UDRP[UDRP]或互斥，可能对这些指南的其他方面影响不大。
(a) Although some Unicode strings may be pure identifiers made up of an assortment of characters from many languages and scripts, IDLs are likely to be "words" or "names" or "phrases" that have specific meaning in a language. While a zone administration might or might not require "meaning" as a registration criterion, meaning could prove to be a useful tool for avoiding user confusion.
(a) 尽管某些Unicode字符串可能是由多种语言和脚本中的各种字符组成的纯标识符，但IDL可能是在某种语言中具有特定含义的“单词”或“名称”或“短语”。虽然区域管理可能需要也可能不需要“意义”作为注册标准，但意义可能被证明是避免用户混淆的有用工具。
Each IDL to be registered should be associated administratively with one or more languages.
每个要注册的IDL都应该在管理上与一种或多种语言相关联。
Language associations should either be predetermined by the zone administrator and applied to the entire zone or be chosen by the registrants on a per-IDL basis. The latter may be necessary for some zones, but it will make administration more difficult and will increase the likelihood of conflicts in variant forms.
语言协会应由区域管理员预先确定并应用于整个区域，或由注册人根据每个IDL选择。对于某些区域，后者可能是必要的，但这将使管理更加困难，并增加各种形式冲突的可能性。
A given zone might have multiple languages associated with it or it may have no language specified at all. Omitting specification of a language may provide additional opportunities for user confusion and is therefore NOT recommended.
给定区域可能有多个与之关联的语言，或者可能根本没有指定语言。省略语言规范可能会给用户带来更多混淆的机会，因此不建议这样做。
(b) Each language uses only a subset of Unicode characters. Therefore, if an IDL is associated with a language, it is not permitted to contain any Unicode character that is not within the valid subset for that language.
(b) 每种语言只使用Unicode字符的子集。因此，如果IDL与某种语言关联，则不允许包含任何不在该语言有效子集内的Unicode字符。
Each IDL to be registered must be verified against the valid subset of Unicode for the language(s) associated with the IDL.
必须根据与IDL关联的语言的有效Unicode子集验证要注册的每个IDL。
That subset is specified by the list of characters appearing in the first column of the language and zone-specific tables as described later in this document.
该子集由出现在语言和区域特定表的第一列中的字符列表指定，如本文档后面所述。
If the IDL fails this test for any of its associated languages, the IDL is not valid for registration.
如果IDL未通过任何相关语言的此测试，则IDL注册无效。
Note that this verification is not necessarily linguistically accurate, because some languages have special rules. For example, some languages impose restrictions on the order in which particular combinations of characters may appear. Characters that are valid for the language, and hence permitted by this specification, might still not form valid words or even strings in the language.
注意，这种验证在语言上不一定准确，因为有些语言有特殊的规则。例如，某些语言对特定字符组合的显示顺序施加限制。对于该语言有效的字符（因此本规范允许）可能仍然无法在该语言中形成有效的单词甚至字符串。
(c) When an IDL is associated with a language, it may have Character Variants that depend on that language associated with it in addition to any Preferred Variants. These variants are potential sources of confusion with the Code Points in the original label string. Consequently, the labels generated from them should be unavailable to registrants of other names, words, or phrases.
(c) 当IDL与一种语言关联时，除了任何首选变体之外，它还可能具有依赖于与之关联的该语言的字符变体。这些变体可能会与原始标签字符串中的代码点混淆。因此，其他姓名、单词或短语的注册人不应使用由其生成的标签。
During registration, all labels generated from the Character Variants for the associated language(s) of the IDL should be reserved.
在注册期间，应保留从IDL关联语言的字符变体生成的所有标签。
IDL reservations of the type described here normally do not appear in the distributed DNS zone file. In other words, these reserved IDLs may not resolve. Domain name holders could request that these reserved IDLs be placed in the zone file and made active and resolvable.
此处所述类型的IDL保留通常不会出现在分布式DNS区域文件中。换句话说，这些保留的IDL可能无法解析。域名持有者可以请求将这些保留IDL放入区域文件中，并使其处于活动状态和可解析状态。
Zones will need to establish local policies about how they are to be made active. Specifically, many zones, especially at the top level, have prohibited or restricted the use of "CNAME"s DNS aliases, especially CNAMEs that point to nameserver delegation records (NS records). And long-term use of long-term aliases for domain hierarchies, rather than single names ("DNAME records") are considered problematic because of the recursion they can introduce into DNS lookups.
区域将需要制定关于如何使其活跃的地方政策。具体而言，许多区域，特别是顶级区域，已禁止或限制使用“CNAME”的DNS别名，特别是指向名称服务器委派记录（NS记录）的CNAME。长期使用域层次结构的长期别名，而不是单一名称（“DNAME记录”）被认为是有问题的，因为它们可以引入DNS查找中的递归。
(d) When an IDL is a "name", "word", or "phrase", it will have Character Variants depending on the associated language. Furthermore, one or more of those Character Variants will be used more often than others for linguistic, political, or other reasons.
(d) 当IDL是“名称”、“单词”或“短语”时，它将根据相关语言具有字符变体。此外，出于语言、政治或其他原因，这些字符变体中的一个或多个将比其他字符变体更频繁地使用。
These more commonly used variants are distinguished from ordinary Character Variants and are known as Preferred Variant(s) for the particular language.
这些更常用的变体与普通字符变体不同，被称为特定语言的首选变体。
To increase the likelihood of correct and predictable resolution of the IDN by end users, all labels generated from the Preferred Variants for the associated language(s) should be resolvable.
为了增加最终用户正确和可预测的IDN解析的可能性，从相关语言的首选变体生成的所有标签都应该是可解析的。
In other words, the Preferred Variant Labels should appear in the distributed DNS zone file.
换句话说，首选变量标签应该出现在分布式DNS区域文件中。
(e) IDLs associated with one or more languages may have a large number of Character Variant Labels or Preferred Variant Labels. Some of these labels may include combinations of characters that are meaningless or invalid linguistically. It may therefore be appropriate for a zone to adopt procedures that include only linguistically acceptable labels in the IDL Package.
(e) 与一种或多种语言关联的IDL可能有大量字符变体标签或首选变体标签。其中一些标签可能包含在语言上无意义或无效的字符组合。因此，对于一个区域来说，采用仅在IDL包中包含语言上可接受的标签的程序可能是合适的。
A zone administrator may impose additional rules and other processing activities to limit the number of Character Variant Labels or Preferred Variant Labels that are actually reserved or registered.
区域管理员可以实施附加规则和其他处理活动，以限制实际保留或注册的字符变体标签或首选变体标签的数量。
These additional rules and other processing activities are based on policies and/or procedures imposed on a per-zone basis and therefore are not within the scope of this document. Such policies or procedures might be used, for example, to restrict the number of Preferred Variant Labels actually reserved or to prevent certain words from being registered at all.
这些附加规则和其他处理活动基于每个区域实施的政策和/或程序，因此不在本文件的范围内。例如，可以使用此类策略或程序来限制实际保留的首选变体标签的数量，或者根本不允许注册某些单词。
(f) There are some Character Variant Labels and Preferred Variant Labels that are associated with each IDL. These labels are considered "equivalent" to each another. To avoid confusion, they all should be assigned to a single domain name holder.
(f) 有一些字符变体标签和首选变体标签与每个IDL关联。这些标签被视为彼此“等效”。为了避免混淆，它们都应该分配给一个域名持有者。
The IDL and its variant labels should be grouped together into a single atomic unit, known in this document as an "IDL Package".
IDL及其变体标签应组合成一个单一的原子单元，在本文档中称为“IDL包”。
The IDL Package is created upon registration and is atomic: Transfer and deletion of an IDL is performed on the IDL Package as a whole. That is, an IDL within the IDL Package may not be transferred or deleted individually; any re-registration, transfers, or other actions that impact the IDL should also affect the other variants.
IDL包在注册时创建，并且是原子的：IDL的传输和删除作为一个整体在IDL包上执行。也就是说，IDL包中的IDL不能单独传输或删除；影响IDL的任何重新注册、传输或其他操作也应影响其他变体。
The name-conflict resolution policy associated with this zone could result in a conflict with the principle of IDL Package atomicity. In such a case, the policy must be defined to make the precedence clear.
与此区域关联的名称冲突解决策略可能导致与IDL包原子性原则冲突。在这种情况下，必须定义策略以明确优先级。
To conform to the principles described in 3.1, this document introduces two concepts: the Language Variant Table and the IDL Package. These are described in the next two subsections, followed by a description of the algorithm that is used to interpret the table and generate variant labels.
为了符合3.1中描述的原则，本文引入了两个概念：语言变量表和IDL包。在接下来的两个小节中对这些进行了描述，然后介绍了用于解释表和生成变量标签的算法。
For each zone that uses a given language, each language should have its own Language Variant Table. The table consists of a header section that identifies references and version information, followed by a section with one row for each Code Point that is valid for the language and three columns.
对于使用给定语言的每个区域，每种语言都应该有自己的语言变体表。该表由一个标识引用和版本信息的标题部分组成，后面是一个部分，每个代码点对应一行（对该语言有效）和三列。
(1) The first column contains the subset of Unicode characters that is valid to be registered ("Valid Code Point"). This is used to verify the IDL to be registered (see 3.1b). As in the registration procedure described later, this column is used as an index to examine characters that appear in a proposed IDL to be processed. The collection of Valid Code Points in the table for a particular language can be thought of as defining the script for that language, although the normal definition of a script would not include, for example, ASCII characters with CJK ones.
(1) 第一列包含可有效注册的Unicode字符子集（“有效代码点”）。这用于验证要注册的IDL（见3.1b）。与后面描述的注册过程一样，此列用作索引，用于检查要处理的建议IDL中出现的字符。表中特定语言的有效代码点集合可被视为定义该语言的脚本，尽管脚本的正常定义不包括ASCII字符和CJK字符等。
(2) The second column contains the Preferred Variant(s) of the corresponding Unicode character in column one ("Valid Code Point"). These variant characters are used to generate the Preferred Variant Labels for the IDL. Those labels should be resolvable (see 3.1d). Under normal circumstances, all of those Preferred Variant Labels will be activated in the relevant zone file so that they will resolve when the DNS is queried for them.
(2) 第二列包含第一列中相应Unicode字符的首选变体（“有效代码点”）。这些变体字符用于生成IDL的首选变体标签。这些标签应是可解析的（见3.1d）。在正常情况下，所有这些首选变量标签将在相关区域文件中激活，以便在查询DNS时解析它们。
(3) The third column contains the Character Variant(s) for the corresponding Valid Code Point. These are used to generate the Character Variant Labels of the IDL, which are then to be reserved (see 3.1c). Registration, or activation, of labels generated from Character Variants will normally be a registrant decision, subject to local policy.
(3) 第三列包含对应有效代码点的字符变量。这些用于生成IDL的字符变体标签，然后保留这些标签（见3.1c）。根据当地政策，注册或激活由角色变体生成的标签通常由注册人决定。
Each entry in a column consists of one or more Code Points, expressed as a numeric character number in the Unicode table and optionally followed by a parenthetical reference. The first column, or Valid Code Point, may have only one Code Point specified in a given row. The other columns may have more than one.
列中的每个条目都由一个或多个代码点组成，在Unicode表中表示为一个数字字符编号，并可选地后跟一个括号引用。第一列或有效代码点在给定行中只能指定一个代码点。其他列可能有多个。
Any row may be terminated with an optional comment, starting with "#".
任何行都可以以可选注释结尾，以“#”开头。
The formal syntax of the table and more-precise definitions of some of its organization appear in Section 5.
表的形式语法及其某些组织的更精确定义见第5节。
The Language Variant Table should be provided by a relevant group, organization, or body. However, the question of who is relevant or has the authority to create this table and the rules that define it is beyond the scope of this document.
语言变体表应由相关团体、组织或机构提供。但是，谁与此表相关或有权创建此表以及定义此表的规则的问题超出了本文件的范围。
The IDL Package is created on successful registration and consists of:
IDL包在成功注册时创建，包括：
(1) the IDL registered
(1) IDL已注册
(2) the language(s) associated with the IDL
(2) 与IDL关联的语言
(3) the version of the associated character variant table
(3) 关联字符变量表的版本
(4) the reserved IDLs
(4) 保留的IDL
(5) active IDLs, that is, "Zone Variant Labels" that are to appear in the DNS zone file
(5) 活动IDL，即将出现在DNS区域文件中的“区域变量标签”
An explanation follows each step.
每一步后面都有一个解释。
Step 1. IN <= IDL to be registered and
{L} <= Set of languages associated with IN
Step 1. IN <= IDL to be registered and
{L} <= Set of languages associated with IN
Start the process with the label string (prospective IDL) to be registered and the associated language(s) as input.
以要注册的标签字符串（预期IDL）和关联的语言作为输入启动流程。
Step 2. Generate the Nameprep-processed version of the IN, applying all mappings and canonicalization required by IDNA.
第二步。应用IDNA所需的所有映射和规范化，生成中的Nameprep处理版本。
The prospective IDL is processed by using Nameprep to apply the normalizations and exclusions globally required to use IDNA. If the Nameprep processing fails, then the IDL is invalid and the registration process must stop.
通过使用Nameprep处理预期IDL，以在全球范围内应用使用IDNA所需的规范化和排除。如果Nameprep处理失败，则IDL无效，注册过程必须停止。
Step 2.1. NP(IN) <= Nameprep processed IN Step 2.2. Check availability of NP(IN). If not available, route to conflict policy.
步骤2.1。NP（IN）<=步骤2.2中处理的Nameprep。检查NP（IN）的可用性。如果不可用，请转到冲突策略。
The Nameprep-processed IDL is then checked against the contents of the zone file and previously created IDL Packages. If it is already registered or reserved, then a conflict exists that must be resolved by applying whatever policy is applicable for the zone. For example, if FCFS is used, the registration process terminates unless the conflict resolution policy provides another alternative.
然后根据区域文件和先前创建的IDL包的内容检查Nameprep处理的IDL。如果已注册或保留，则存在冲突，必须通过应用适用于该区域的任何策略来解决。例如，如果使用FCFS，则注册过程将终止，除非冲突解决策略提供了其他替代方案。
Step 3. Process each language. For each language (AL) in {L}
第三步。处理每种语言。对于{L}中的每种语言（AL）
Step 3 goes through all languages associated with the proposed IDL and checks each character (after Nameprep has been applied) for validity in each of them. It then applies the Preferred Variants (column 2 values) and the Character Variants (column 3 values) to generate candidate labels.
步骤3检查与建议的IDL关联的所有语言，并检查每个字符（在应用Nameprep之后）在每个字符中的有效性。然后应用首选变量（第2列值）和字符变量（第3列值）生成候选标签。
Step 3.1. Check validity of NP(IN) in AL. If failed, stop processing.
步骤3.1。检查AL中NP（IN）的有效性。如果失败，则停止处理。
In step 3.1, IDL validation is done by checking that every Code Point in the Nameprep-processed IDL is a Code Point allowed by the "Valid Code Point" column of the Character Variant Table for the language. This is then repeated for any other languages (and hence, Language Variant Tables) specified in the registration. If one or more Code Points are not valid, the registration process terminates.
在步骤3.1中，通过检查Nameprep处理的IDL中的每个代码点是否为该语言的字符变体表的“有效代码点”列所允许的代码点来完成IDL验证。然后对注册中指定的任何其他语言（因此，语言变体表）重复此操作。如果一个或多个代码点无效，则注册过程终止。
Step 3.2. PV(IN,AL) <= Set of available Nameprep-processed Preferred
Variants of NP(IN) in AL
Step 3.2. PV(IN,AL) <= Set of available Nameprep-processed Preferred
Variants of NP(IN) in AL
Step 3.2 generates the list of Preferred Variant Labels of the IDL by doing a combination (see Step 3.2A below) of all possible variants listed in the "Preferred Variant(s)" column for each Code Point in the Nameprep-processed IDL. The generated Preferred Variant Labels must be processed through Nameprep. If the Nameprep processing fails for any Preferred Variant Label (this is unlikely to occur if the Preferred Variants are processed through Nameprep before being placed in the table), then that variant label will be removed from the list. The remaining Preferred Variant Labels in the list are then checked to see whether they are already registered or reserved. If any are registered or reserved, then the conflict resolution policy will apply. In general, this will not prevent the originally requested IDL from being registered unless the policy prevents such registration. For example, if FCFS is applied, then the conflicting variants will be removed from the list, but the originally requested
步骤3.2通过对Nameprep处理的IDL中每个代码点的“首选变量”列中列出的所有可能变量进行组合（参见下面的步骤3.2A），生成IDL首选变量标签列表。必须通过Nameprep处理生成的首选变量标签。如果任何首选变体标签的Nameprep处理失败（如果首选变体在放入表格之前通过Nameprep处理，则不太可能发生这种情况），则该变体标签将从列表中删除。然后检查列表中剩余的首选变体标签，查看它们是否已注册或保留。如果已注册或保留冲突解决策略，则将应用冲突解决策略。通常，这不会阻止注册最初请求的IDL，除非策略阻止此类注册。例如，如果应用了FCFS，则冲突变量将从列表中删除，但最初请求的
IDL and any remaining variants will be registered (see steps 5 and 8 below).
将注册IDL和任何其他变体（请参阅下面的步骤5和8）。
Step 3.2A Generating variant labels from Variant Code Points.
步骤3.2A从变体代码点生成变体标签。
Steps 3.2 and 3.3 require that the Preferred Variants and Character Variants be combined with the original IDL to form sets of variant labels. Conceptually, one starts with the original, Nameprep-processed, IDL and examines each of its characters in turn. If a character is encountered for which there is a corresponding Preferred Variant or Character Variant, a new variant label is produced with the Variant Code Point substituted for the original one. If variant labels already exist as the result of the processing of characters that appeared earlier in the original IDL, then the substitutions are made in them as well, resulting in additional generated variant labels. This operation is repeated separately for the Preferred Variants (in Step 3.2) and Character Variants (in Step 3.3). Of course, equivalent results could be achieved by processing the original IDL's characters in order, building the Preferred Variant Label set and Character Variant Label set in parallel.
步骤3.2和3.3要求首选变体和字符变体与原始IDL组合，以形成变体标签集。从概念上讲，我们从原始的Nameprep processed IDL开始，依次检查它的每个字符。如果遇到具有相应首选变体或字符变体的字符，将生成一个新的变体标签，并用变体代码点替换原始标签。如果在处理原始IDL中较早出现的字符时，变体标签已经存在，那么也会在其中进行替换，从而生成额外的变体标签。对于首选变体（步骤3.2）和字符变体（步骤3.3），分别重复此操作。当然，通过按顺序处理原始IDL的字符，并行构建首选变体标签集和字符变体标签集，可以获得相同的结果。
This process will sometimes generate a very large number of labels. For example, if only two of the characters in the original IDL are associated with Preferred Variants and if the first of those characters has three Preferred Variants and the second has two, one ends up with 12 variant labels to be placed in the IDL Package and, normally, in the zone file. Repeating the process for Character Variants, if any exist, would further increase the number of labels. And if more than one language is specified for the original IDL, then repetition of the process for additional languages (see step 4, below) might further increase the size of the set.
此过程有时会生成大量标签。例如，如果原始IDL中只有两个字符与首选变体相关联，并且其中第一个字符有三个首选变体，而第二个字符有两个，则其中一个字符最后会有12个变体标签，以放置在IDL包中，通常情况下，放置在区域文件中。对字符变体（如果存在）重复该过程将进一步增加标签的数量。如果为原始IDL指定了多个语言，那么对其他语言重复该过程（参见下面的步骤4）可能会进一步增加集合的大小。
For illustrative purposes, the "combination" process could be achieved by a recursive function similar to the following pseudocode:
出于说明目的，“组合”过程可通过类似于以下伪代码的递归函数实现：
Function Combination(Str)
F <= first codepoint of Str
SStr <= Substring of Str, without the first code point
NSC <= {}
Function Combination(Str)
F <= first codepoint of Str
SStr <= Substring of Str, without the first code point
NSC <= {}
If SStr is empty then for each V in (Variants of code point F) NSC = NSC set-union (the string with the code point V) End of Loop Else SubCom = Combination(SStr) For each V in (Variants of code point F) For each SC in SubCom NSC = NSC set-union (the string with the first code point V followed by the string SC) End of Loop End of Loop Endif
如果SStr为空，则对于每个V in（代码点F的变体）NSC=NSC集合并集（带代码点V的字符串）循环结束Else SubCom=组合（SStr）对于每个V in（代码点F的变体）SubCom中的每个SC NSC=NSC集合并集（带第一个代码点V的字符串后跟字符串SC）循环结束循环结束Endif
Return NSC
返回NSC
Step 3.3. CV(IN,AL) <= Set of available Nameprep-processed Character
Variants of NP(IN) in AL
Step 3.3. CV(IN,AL) <= Set of available Nameprep-processed Character
Variants of NP(IN) in AL
This step generates the list of Character Variant Labels by doing a combination (see Step 3.2A above) of all the possible variants listed in the "Character Variant(s)" column for each Code Point in the Nameprep-processed original IDL. As with the Preferred Variant Labels, the generated Character Variant Labels must be processed by, and acceptable to, Nameprep. If the Nameprep processing fails for a Character Variant Label, then that variant label will be removed from the list. The remaining Character Variant Labels are then checked to be sure they are not registered or reserved. If one or more are, then the conflict resolution policy is applied. As with Preferred Variant Labels, a conflict that is resolved in favor of the earlier registrant does not, in general, prevent the IDL from being registered, nor the remaining variants from being reserved in step 6 below.
此步骤通过对Nameprep处理的原始IDL中每个代码点的“字符变体”列中列出的所有可能变体进行组合（请参见上面的步骤3.2A），生成字符变体标签列表。与首选变体标签一样，生成的字符变体标签必须由Nameprep处理并为其接受。如果字符变体标签的Nameprep处理失败，则该变体标签将从列表中删除。然后检查其余的字符变体标签，以确保它们未注册或保留。如果存在一个或多个冲突，则应用冲突解决策略。与首选变体标签一样，解决有利于早期注册人的冲突通常不会阻止IDL注册，也不会阻止在下面的步骤6中保留其余变体。
Step 3.4. End of Loop
步骤3.4。循环结束
Step 4. Let PVall be the set-union of all PV(IN,AL)
第四步。设PVall为所有PV（IN，AL）的集合并集
Step 4 generates the Preferred Variants Label for all languages. In this step, and again in step 6 below, the zone administrator may impose additional rules and processing activities to restrict the number of Preferred (tentatively to be reserved and activated) and Character (tentatively to be reserved) Label Variants. These additional rules and processing activities are zone policy specific and therefore are not specified in this document.
步骤4为所有语言生成首选变体标签。在这一步中，以及在下面的第6步中，区域管理员可以实施附加规则和处理活动，以限制首选（暂定保留和激活）和字符（暂定保留）标签变体的数量。这些附加规则和处理活动是特定于区域策略的，因此未在本文档中指定。
Step 5. {ZV} <= PVall set-union NP(IN)
Step 5. {ZV} <= PVall set-union NP(IN)
Step 5 generates the initial Zone Variants. The set includes all Preferred Variants for all languages and the original Nameprep-processed IDL. Unless excluded by further processing, these Zone Variants will be activated. That is, placed into the DNS zone. Note that the "set-union" operation will eliminate any duplicates.
步骤5生成初始区域变量。该集合包括所有语言的所有首选变体以及原始Nameprep处理的IDL。除非通过进一步处理排除，否则这些区域变量将被激活。也就是说，放入DNS区域。请注意，“set union”操作将消除任何重复项。
Step 6. Let CVall be the set-union of all CV(IN,AL), set-minus {ZV}
第六步。设CVall是所有CV（IN，AL）的集合并集，集合减去{ZV}
Step 6 generates the Reserved Label Variants (the Character Variant Label set). These labels are normally reserved but not activated. The set includes all Character Variant Labels for all languages, but not the Zone Variants defined in the previous step. The set-union and set-minus operations eliminate any duplicates.
步骤6生成保留标签变体（字符变体标签集）。这些标签通常保留但未激活。该集合包括所有语言的所有字符变体标签，但不包括上一步中定义的区域变体。集合并集和集合减号操作可消除任何重复项。
Step 7. Create IDL Package for IN using IN, {L}, {ZV} and CVall
Step 7. Create IDL Package for IN using IN, {L}, {ZV} and CVall
In Step 7, the "IDL Package" is created using the original IDL, the associated language(s), the Zone Variant Labels, and the Reserved Variant Labels. If zone-specific additional processing or filtering is to be applied to eliminate linguistically inappropriate or other forms, it should be applied before the IDL Package is actually assembled.
在步骤7中，使用原始IDL、关联语言、区域变量标签和保留变量标签创建“IDL包”。如果要应用特定于区域的附加处理或过滤来消除语言上不合适的形式或其他形式，则应在实际组装IDL包之前应用。
Step 8. Put {ZV} into zone file
第八步。将{ZV}放入区域文件
The activated IDLs are converted via ToASCII with UseSTD13ASCIIRules [IDNA] before being placed into the zone file. This conversion results in the IDLs being in the actual IDNA ("Punycode") form used in zone files, while the IDLs have been carried in Unicode form up to this point. If ToASCII fails for any of the activated IDLs, that IDL must not be placed into the zone file. If the IDL is a subdomain name, it will be delegated.
激活的IDL在放入区域文件之前通过ToASCII和UseSTD13ASCIIRules[IDNA]进行转换。这种转换导致IDL采用区域文件中使用的实际IDNA（“Punycode”）形式，而到目前为止，IDL一直采用Unicode形式。如果任何激活的IDL的ToASCII失败，则不得将该IDL放入区域文件中。如果IDL是一个子域名，它将被委派。
In traditional domain administration, every Domain Name Label is independent of all other Domain Name Labels. Registration, deletion, and transfer of labels is done on a per-label basis. However, with the guidelines discussed here, each IDL is associated with specific languages, with all label variants, both active (zone) and reserved, together in an IDL Package. This quite deliberately prohibits labels that contain sufficient mixtures of characters from different scripts to make them impossible as words in any given language. If a zone chooses to not impose that restriction--that is, to permit labels to be constructed by picking characters from several different languages and scripts--then the guidelines described here would be inappropriate.
在传统的域管理中，每个域名标签都独立于所有其他域名标签。标签的注册、删除和转移按标签进行。然而，根据这里讨论的指导原则，每个IDL都与特定的语言相关联，所有标签变体（活动（区域）和保留）都在一个IDL包中。这相当有意地禁止标签包含来自不同脚本的足够多的字符混合，使它们不可能成为任何给定语言中的单词。如果一个区域选择不施加这种限制——也就是说，允许通过从几种不同的语言和脚本中选取字符来构造标签——那么这里描述的准则将是不合适的。
As stated earlier, the IDL package should be treated as a single atomic unit and all variants of the IDL should belong to a single domain-name holder. If the local policy related to the handling of disagreements requires a particular IDL to be transferred and deleted independently of the IDL Package, the conflict policy would take precedence. In such an event, the conflict policy should include a transfer or delete procedure that takes the nature of IDL Packages into consideration.
如前所述，IDL包应被视为单个原子单元，IDL的所有变体应属于单个域名持有者。如果与处理分歧相关的本地政策要求独立于IDL包传输和删除特定IDL，则冲突政策将优先。在这种情况下，冲突策略应包括一个传输或删除过程，该过程应考虑IDL包的性质。
When an IDL Package is deleted, all of the Zone and Reserved Label Variants again become available. The deletion of one IDL Package does not change any other IDL Packages.
删除IDL包后，所有分区和保留标签变体将再次可用。删除一个IDL包不会更改任何其他IDL包。
Because there are active (registered) IDLs and inactive (reserved but not registered) IDLs within an IDL package, processes are required to activate or deactivate IDL variants within an IDL Package.
由于IDL包中存在活动（已注册）IDL和非活动（保留但未注册）IDL，因此需要流程来激活或停用IDL包中的IDL变体。
Step 1. IN <= IDL to be activated and PA <= IDL Package
Step 1. IN <= IDL to be activated and PA <= IDL Package
Start with the IDL to be activated and the IDL Package of which it is a member.
从要激活的IDL及其所属的IDL包开始。
Step 2. NP(IN) <= Nameprep processed IN
Step 2. NP(IN) <= Nameprep processed IN
Process the IDL through Nameprep. This step should never cause a problem, or even a change, since all labels that become part of the IDL Package are processed through Nameprep in Step 3.2 or 3.3 of the Registration procedure (section 3.2.3).
通过Nameprep处理IDL。此步骤不应引起问题，甚至不应引起更改，因为成为IDL包一部分的所有标签都是通过注册程序（第3.2.3节）步骤3.2或3.3中的Nameprep处理的。
Step 3. If NP(IN) not in CVall then stop
第三步。如果NP（IN）不在CVall中，则停止
Verify that the Nameprep-processed version of the IDL appears as a still-unactivated label in the IDL Package, i.e., in the list of Reserved Label Variants, CVall. It might be a useful "sanity check" to also verify that it does not already appear in the zone file.
验证Nameprep处理过的IDL版本是否在IDL包中显示为仍然未激活的标签，即在保留标签变体列表CVall中。这可能是一个有用的“健全性检查”，还可以验证它是否已经出现在区域文件中。
Step 4. CVall <= CVall set-minus NP(IN) and {ZV} <= {ZV} set-union
NP(IN)
Step 4. CVall <= CVall set-minus NP(IN) and {ZV} <= {ZV} set-union
NP(IN)
Within the IDL Package, remove the Nameprep-processed version of the IDL from the list of Reserved Label Variants and add it to the list of active (zone) label variants.
在IDL包中，从保留标签变体列表中删除Nameprep处理过的IDL版本，并将其添加到活动（区域）标签变体列表中。
Step 5. Put {ZV} into the zone file
第五步。将{ZV}放入区域文件
Actually register (activate) the Zone Variant Labels.
实际注册（激活）区域变量标签。
Step 1. IN <= IDL to be deactivated and PA <= IDL Package
Step 1. IN <= IDL to be deactivated and PA <= IDL Package
As with activation, start with the IDL to be deactivated and the IDL Package of which it is a member.
与激活一样，从要停用的IDL及其所属的IDL包开始。
Step 2. NP(IN) <= Nameprep processed IN
Step 2. NP(IN) <= Nameprep processed IN
Get the Nameprep-processed version of the name (see discussion in the previous section).
获取名称的Nameprep处理版本（请参阅上一节中的讨论）。
Step 3. If NP(IN) not in {ZV} then stop
Step 3. If NP(IN) not in {ZV} then stop
Verify that the Nameprep-processed version of the IDL appears as an activated (zone) label variant in the IDL Package. It might be a useful "sanity check" at this point to also verify that it actually appears in the zone file.
验证Nameprep处理过的IDL版本在IDL包中是否显示为激活（区域）标签变体。在这一点上，它可能是一个有用的“健全性检查”，以验证它是否确实出现在区域文件中。
Step 4. CVall <= CVall set-union NP(IN) and {ZV} <= {ZV} set-minus
NP(IN)
Step 4. CVall <= CVall set-union NP(IN) and {ZV} <= {ZV} set-minus
NP(IN)
Within the IDL Package, remove the Nameprep-processed version of the IDL from the list of Active (Zone) Label Variants and add it to the list of Reserved (but inactive) Label Variants.
在IDL包中，从活动（区域）标签变体列表中删除Nameprep处理过的IDL版本，并将其添加到保留（但非活动）标签变体列表中。
Step 5. Put {ZV} into the zone file
第五步。将{ZV}放入区域文件
Since the IDL package is an atomic unit and the associated list of variants must not be changed after creation, this document does not include a mechanism for adding and deleting language associations within the IDL package. Instead, it recommends deleting the IDL package entirely, followed by a registration with the new set of languages. Zone administrators may find it desirable to devise procedures that prevent other parties from capturing the labels in the IDL Package during these operations.
由于IDL包是一个原子单元，创建后不得更改相关的变体列表，因此本文档不包括在IDL包中添加和删除语言关联的机制。相反，它建议完全删除IDL包，然后注册新的语言集。区域管理员可能会发现，需要设计一些程序，防止其他方在这些操作期间捕获IDL包中的标签。
Language Variant Tables are subject to changes over time, and these changes may or may not be backward compatible. It is possible that updated Language Variant Tables may produce a different set of Preferred Variants and Reserved Variants.
语言变量表会随着时间的推移而发生变化，这些变化可能向后兼容，也可能不向后兼容。更新后的语言变体表可能会产生一组不同的首选变体和保留变体。
In order to preserve the atomicity of the IDL Package, when the Language Variant Table is changed, IDL Packages created using the previous version of the Language Variant Table must not be updated or affected.
为了保持IDL包的原子性，当语言变量表发生更改时，不得更新或影响使用以前版本的语言变量表创建的IDL包。
To provide a meaningful example, some Language Variant Tables must be defined. Assume, then, for the purpose of giving examples, that the following four Language Variant Tables are defined:
为了提供一个有意义的示例，必须定义一些语言变量表。为了举例，假设定义了以下四种语言变体表：
Note: these tables are not a representation of the actual tables, and they do not contain sufficient entries to be used in any actual implementation. IANA maintains a voluntary registry of actual tables [IANA-LVTABLES] which may be consulted for complete examples.
注意：这些表不是实际表的表示，并且它们不包含足够的条目，无法在任何实际实现中使用。IANA维护一个实际表的自愿登记册[IANA-LVTABLES]，完整示例可参考该登记册。
a) Language Variant Table for zh-cn and zh-sg
a) zh cn和zh sg的语言变量表
Reference 1 CP936 (commonly known as GBK) Reference 2 zVariant, zTradVariant, zSimpVariant in Unihan.txt [UNIHAN] Reference 3 List of Simplified character Table (Simplified column) Reference 4 zSimpVariant in Unihan.txt [UNIHAN] Reference 5 variant that exists in GB2312, common simplified hanzi
参考文献1 CP936（俗称GBK）参考文献2 Unihan.txt中的zVariant、zTradVariant、zSimpVariant[Unihan]参考文献3简化字符表列表（简化列）参考文献4 Unihan.txt中的zSimpVariant[Unihan]参考文献5 GB2312中存在的变体，通用简化汉字
Version 1 20020701 # July 2002
版本1 20020701#2002年7月
56E2(1);56E2(5);5718(2) # sphere, ball, circle; mass, lump
5718(1);56E2(4);56E2(2),56E3(2) # sphere, ball, circle; mass, lump
60F3(1);60F3(5); # think, speculate, plan, consider
654E(1);6559(5);6559(2) # teach
56E2(1);56E2(5);5718(2) # sphere, ball, circle; mass, lump
5718(1);56E2(4);56E2(2),56E3(2) # sphere, ball, circle; mass, lump
60F3(1);60F3(5); # think, speculate, plan, consider
654E(1);6559(5);6559(2) # teach
6559(1);6559(5);654E(2) # teach, class
6DF8(1);6E05(5);6E05(2) # clear
6E05(1);6E05(5);6DF8(2) # clear, pure, clean; peaceful
771E(1);771F(5);771F(2) # real, actual, true, genuine
771F(1);771F(5);771E(2) # real, actual, true, genuine
8054(1);8054(3);806F(2) # connect, join; associate, ally
806F(1);8054(3);8054(2),8068(2) # connect, join; associate, ally
96C6(1);96C6(5); # assemble, collect together
6559(1);6559(5);654E(2) # teach, class
6DF8(1);6E05(5);6E05(2) # clear
6E05(1);6E05(5);6DF8(2) # clear, pure, clean; peaceful
771E(1);771F(5);771F(2) # real, actual, true, genuine
771F(1);771F(5);771E(2) # real, actual, true, genuine
8054(1);8054(3);806F(2) # connect, join; associate, ally
806F(1);8054(3);8054(2),8068(2) # connect, join; associate, ally
96C6(1);96C6(5); # assemble, collect together
b) Language Variant Table for zh-tw
b) zh tw的语言变量表
Reference 1 CP950 (commonly known as BIG5) Reference 2 zVariant, zTradVariant, zSimpVariant in Unihan.txt Reference 3 List of Simplified Character Table (Traditional column) Reference 4 zTradVariant in Unihan.txt
参考1 CP950（通常称为BIG5）参考2 Unihan.txt中的zVariant、zTradVariant、zSimpVariant参考3简化字符表列表（传统列）参考4 Unihan.txt中的zTradVariant
Version 1 20020701 # July 2002
版本1 20020701#2002年7月
5718(1);5718(4);56E2(2),56E3(2) # sphere, ball, circle; mass, lump
60F3(1);60F3(1); # think, speculate, plan, consider
6559(1);6559(1);654E(2) # teach, class
6E05(1);6E05(1);6DF8(2) # clear, pure, clean; peaceful
771F(1);771F(1);771E(2) # real, actual, true, genuine
806F(1);806F(3);8054(2),8068(2) # connect, join; associate, ally
96C6(1);96C6(1); # assemble, collect together
5718(1);5718(4);56E2(2),56E3(2) # sphere, ball, circle; mass, lump
60F3(1);60F3(1); # think, speculate, plan, consider
6559(1);6559(1);654E(2) # teach, class
6E05(1);6E05(1);6DF8(2) # clear, pure, clean; peaceful
771F(1);771F(1);771E(2) # real, actual, true, genuine
806F(1);806F(3);8054(2),8068(2) # connect, join; associate, ally
96C6(1);96C6(1); # assemble, collect together
c) Language Variant Table for ja
c) ja语言变量表
Reference 1 CP932 (commonly known as Shift-JIS) Reference 2 zVariant in Unihan.txt Reference 3 variant that exists in JIS X0208, commonly used Kanji
参考文献1 CP932（通常称为Shift JIS）参考文献2 Unihan.txt参考文献3变体中的zVariant存在于JIS X0208中，常用汉字
Version 1 20020701 # July 2002
版本1 20020701#2002年7月
5718(1);5718(3);56E3(2) # sphere, ball, circle; mass, lump
60F3(1);60F3(3); # think, speculate, plan, consider
654E(1);6559(3);6559(2) # teach
6559(1);6559(3);654E(2) # teach, class
6DF8(1);6E05(3);6E05(2) # clear
6E05(1);6E05(3);6DF8(2) # clear, pure, clean; peaceful
771E(1);771E(1);771F(2) # real, actual, true, genuine
771F(1);771F(1);771E(2) # real, actual, true, genuine
806F(1);806F(1);8068(2) # connect, join; associate, ally
96C6(1);96C6(3); # assemble, collect together
5718(1);5718(3);56E3(2) # sphere, ball, circle; mass, lump
60F3(1);60F3(3); # think, speculate, plan, consider
654E(1);6559(3);6559(2) # teach
6559(1);6559(3);654E(2) # teach, class
6DF8(1);6E05(3);6E05(2) # clear
6E05(1);6E05(3);6DF8(2) # clear, pure, clean; peaceful
771E(1);771E(1);771F(2) # real, actual, true, genuine
771F(1);771F(1);771E(2) # real, actual, true, genuine
806F(1);806F(1);8068(2) # connect, join; associate, ally
96C6(1);96C6(3); # assemble, collect together
d) Language Variant Table for ko
d) ko语言变体表
Reference 1 CP949 (commonly known as EUC-KR)
参考文献1 CP949（通常称为EUC-KR）
Reference 2 zVariant and K-source in Unihan.txt
Unihan.txt中的参考2 zVariant和K源
Version 1 20020701 # July 2002
版本1 20020701#2002年7月
5718(1);5718(1);56E3(2) # sphere, ball, circle; mass, lump
60F3(1);60F3(1); # think, speculate, plan, consider
654E(1);654E(1);6559(2) # teach
6DF8(1);6DF8(1);6E05(2) # clear
771E(1);771E(1);771F(2) # real, actual, true, genuine
806F(1);806F(1);8068(2) # connect, join; associate, ally
96C6(1);96C6(1); # assemble, collect together
5718(1);5718(1);56E3(2) # sphere, ball, circle; mass, lump
60F3(1);60F3(1); # think, speculate, plan, consider
654E(1);654E(1);6559(2) # teach
6DF8(1);6DF8(1);6E05(2) # clear
771E(1);771E(1);771F(2) # real, actual, true, genuine
806F(1);806F(1);8068(2) # connect, join; associate, ally
96C6(1);96C6(1); # assemble, collect together
Example 1: IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
{L} = {zh-cn, zh-sg, zh-tw}
Example 1: IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
{L} = {zh-cn, zh-sg, zh-tw}
NP(IN) = (U+6E05 U+771F U+6559)
PV(IN,zh-cn) = (U+6E05 U+771F U+6559)
PV(IN,zh-sg) = (U+6E05 U+771F U+6559)
PV(IN,zh-tw) = (U+6E05 U+771F U+6559)
NP(IN) = (U+6E05 U+771F U+6559)
PV(IN,zh-cn) = (U+6E05 U+771F U+6559)
PV(IN,zh-sg) = (U+6E05 U+771F U+6559)
PV(IN,zh-tw) = (U+6E05 U+771F U+6559)
{ZV} = {(U+6E05 U+771F U+6559)}
CVall = {(U+6E05 U+771E U+6559),
(U+6E05 U+771E U+654E),
(U+6E05 U+771F U+654E),
(U+6DF8 U+771E U+6559),
(U+6DF8 U+771E U+654E),
(U+6DF8 U+771F U+6559),
(U+6DF8 U+771F U+654E)}
{ZV} = {(U+6E05 U+771F U+6559)}
CVall = {(U+6E05 U+771E U+6559),
(U+6E05 U+771E U+654E),
(U+6E05 U+771F U+654E),
(U+6DF8 U+771E U+6559),
(U+6DF8 U+771E U+654E),
(U+6DF8 U+771F U+6559),
(U+6DF8 U+771F U+654E)}
Example 2: IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
{L} = {ja}
Example 2: IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
{L} = {ja}
NP(IN) = (U+6E05 U+771F U+6559)
PV(IN,ja) = (U+6E05 U+771F U+6559)
{ZV} = {(U+6E05 U+771F U+6559)}
NP(IN) = (U+6E05 U+771F U+6559)
PV(IN,ja) = (U+6E05 U+771F U+6559)
{ZV} = {(U+6E05 U+771F U+6559)}
CVall = {(U+6E05 U+771E U+6559),
(U+6E05 U+771E U+654E),
(U+6E05 U+771F U+654E),
(U+6DF8 U+771E U+6559),
(U+6DF8 U+771E U+654E),
(U+6DF8 U+771F U+6559),
(U+6DF8 U+771F U+654E)}
CVall = {(U+6E05 U+771E U+6559),
(U+6E05 U+771E U+654E),
(U+6E05 U+771F U+654E),
(U+6DF8 U+771E U+6559),
(U+6DF8 U+771E U+654E),
(U+6DF8 U+771F U+6559),
(U+6DF8 U+771F U+654E)}
Example 3: IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
{L} = {zh-cn, zh-sg, zh-tw, ja, ko}
Example 3: IDL = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
{L} = {zh-cn, zh-sg, zh-tw, ja, ko}
NP(IN) = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
NP(IN) = (U+6E05 U+771F U+6559) *qing2 zhen1 jiao4*
Invalid registration because U+6E05 is invalid in L = ko
注册无效，因为U+6E05在L=ko中无效
Example 4: IDL = (U+806F U+60F3 U+96C6 U+5718)
*lian2 xiang3 ji2 tuan2*
{L} = {zh-cn, zh-sg, zh-tw}
Example 4: IDL = (U+806F U+60F3 U+96C6 U+5718)
*lian2 xiang3 ji2 tuan2*
{L} = {zh-cn, zh-sg, zh-tw}
NP(IN) = (U+806F U+60F3 U+96C6 U+5718)
PV(IN,zh-cn) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-sg) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-tw) = (U+806F U+60F3 U+96C6 U+5718)
{ZV} = {(U+8054 U+60F3 U+96C6 U+56E2),
(U+806F U+60F3 U+96C6 U+5718)}
CVall = {(U+8054 U+60F3 U+96C6 U+56E3),
(U+8054 U+60F3 U+96C6 U+5718),
(U+806F U+60F3 U+96C6 U+56E2),
(U+806f U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+56E2),
(U+8068 U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+5718)
NP(IN) = (U+806F U+60F3 U+96C6 U+5718)
PV(IN,zh-cn) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-sg) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-tw) = (U+806F U+60F3 U+96C6 U+5718)
{ZV} = {(U+8054 U+60F3 U+96C6 U+56E2),
(U+806F U+60F3 U+96C6 U+5718)}
CVall = {(U+8054 U+60F3 U+96C6 U+56E3),
(U+8054 U+60F3 U+96C6 U+5718),
(U+806F U+60F3 U+96C6 U+56E2),
(U+806f U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+56E2),
(U+8068 U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+5718)
Example 5: IDL = (U+8054 U+60F3 U+96C6 U+56E2)
*lian2 xiang3 ji2 tuan2*
{L} = {zh-cn, zh-sg}
Example 5: IDL = (U+8054 U+60F3 U+96C6 U+56E2)
*lian2 xiang3 ji2 tuan2*
{L} = {zh-cn, zh-sg}
NP(IN) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-cn) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-sg) = (U+8054 U+60F3 U+96C6 U+56E2)
{ZV} = {(U+8054 U+60F3 U+96C6 U+56E2)}
CVall = {(U+8054 U+60F3 U+96C6 U+56E3),
(U+8054 U+60F3 U+96C6 U+5718),
(U+806F U+60F3 U+96C6 U+56E2),
(U+806f U+60F3 U+96C6 U+56E3),
(U+806F U+60F3 U+96C6 U+5718),
(U+8068 U+60F3 U+96C6 U+56E2),
(U+8068 U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+5718)}
NP(IN) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-cn) = (U+8054 U+60F3 U+96C6 U+56E2)
PV(IN,zh-sg) = (U+8054 U+60F3 U+96C6 U+56E2)
{ZV} = {(U+8054 U+60F3 U+96C6 U+56E2)}
CVall = {(U+8054 U+60F3 U+96C6 U+56E3),
(U+8054 U+60F3 U+96C6 U+5718),
(U+806F U+60F3 U+96C6 U+56E2),
(U+806f U+60F3 U+96C6 U+56E3),
(U+806F U+60F3 U+96C6 U+5718),
(U+8068 U+60F3 U+96C6 U+56E2),
(U+8068 U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+5718)}
Example 6: IDL = (U+8054 U+60F3 U+96C6 U+56E2)
*lian2 xiang3 ji2 tuan2*
{L} = {zh-cn, zh-sg, zh-tw}
Example 6: IDL = (U+8054 U+60F3 U+96C6 U+56E2)
*lian2 xiang3 ji2 tuan2*
{L} = {zh-cn, zh-sg, zh-tw}
NP(IN) = (U+8054 U+60F3 U+96C6 U+56E2)
Invalid registration because U+8054 is invalid in L = zh-tw
NP(IN) = (U+8054 U+60F3 U+96C6 U+56E2)
Invalid registration because U+8054 is invalid in L = zh-tw
Example 7: IDL = (U+806F U+60F3 U+96C6 U+5718)
*lian2 xiang3 ji2 tuan2*
{L} = {ja,ko}
Example 7: IDL = (U+806F U+60F3 U+96C6 U+5718)
*lian2 xiang3 ji2 tuan2*
{L} = {ja,ko}
NP(IN) = (U+806F U+60F3 U+96C6 U+5718)
PV(IN,ja) = (U+806F U+60F3 U+96C6 U+5718)
PV(IN,ko) = (U+806F U+60F3 U+96C6 U+5718)
{ZV} = {(U+806F U+60F3 U+96C6 U+5718)}
NP(IN) = (U+806F U+60F3 U+96C6 U+5718)
PV(IN,ja) = (U+806F U+60F3 U+96C6 U+5718)
PV(IN,ko) = (U+806F U+60F3 U+96C6 U+5718)
{ZV} = {(U+806F U+60F3 U+96C6 U+5718)}
CVall = {(U+806F U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+5718),
(U+8068 U+60F3 U+96C6 U+56E3)}
CVall = {(U+806F U+60F3 U+96C6 U+56E3),
(U+8068 U+60F3 U+96C6 U+5718),
(U+8068 U+60F3 U+96C6 U+56E3)}
The formal syntax for the Language Variant Table is as follows, using the IETF "ABNF" metalanguage [ABNF]. Some comments on this syntax appear immediately after it.
语言变量表的形式语法如下，使用IETF“ABNF”元语言[ABNF]。关于此语法的一些注释会立即出现在后面。
LanguageVariantTable = 1*ReferenceLine VersionLine 1*EntryLine
ReferenceLine = "Reference" SP RefNo SP RefDesciption [ Comment ] CRLF
RefNo = 1*DIGIT
RefDesciption = *[VCHAR]
VersionLine = "Version" SP VersionNo SP VersionDate [ Comment ] CRLF
VersionNo = 1*DIGIT
VersionDate = YYYYMMDD
EntryLine = VariantEntry/Comment CRLF
LanguageVariantTable = 1*ReferenceLine VersionLine 1*EntryLine
ReferenceLine = "Reference" SP RefNo SP RefDesciption [ Comment ] CRLF
RefNo = 1*DIGIT
RefDesciption = *[VCHAR]
VersionLine = "Version" SP VersionNo SP VersionDate [ Comment ] CRLF
VersionNo = 1*DIGIT
VersionDate = YYYYMMDD
EntryLine = VariantEntry/Comment CRLF
VariantEntry = ValidCodePoint ";"
PreferredVariant ";" CharacterVariant [ Comment ]
ValidCodePoint = CodePoint
RefList = RefNo 0*( "," RefNo )
PreferredVariant = CodePointSet 0*( "," CodePointSet )
CharacterVariant = CodePointSet 0*( "," CodePointSet )
CodePointSet = CodePoint 0*( SP CodePoint )
CodePoint = 4*8DIGIT [ "(" Reflist ")" ]
Comment = "#" *VCHAR
VariantEntry = ValidCodePoint ";"
PreferredVariant ";" CharacterVariant [ Comment ]
ValidCodePoint = CodePoint
RefList = RefNo 0*( "," RefNo )
PreferredVariant = CodePointSet 0*( "," CodePointSet )
CharacterVariant = CodePointSet 0*( "," CodePointSet )
CodePointSet = CodePoint 0*( SP CodePoint )
CodePoint = 4*8DIGIT [ "(" Reflist ")" ]
Comment = "#" *VCHAR
YYYYMMDD is an integer, in alphabetic form, representing a date, where YYYY is the 4-digit year, MM is the 2-digit month, and DD is the 2-digit day.
YYYYMMDD是一个整数，以字母形式表示日期，其中YYYY是4位数字的年份，MM是2位数字的月份，DD是2位数字的日期。
Any lines starting with, or portions of lines after, the hash symbol("#") are treated as comments. Comments have no significance in the processing of the tables; nor are there any syntax requirements between the hash symbol and the end of the line. Blank lines in the tables are ignored completely.
以散列符号（“#”）开头的任何行或其后的部分行都被视为注释。注释在表格处理中没有意义；哈希符号和行尾之间也没有任何语法要求。表格中的空行将被完全忽略。
Every language should have its own Language Variant Table provided by a relevant group, organization, or other body. That table will normally be based on some established standard or standards. The group that defines a Language Variant Table should document references to the appropriate standards at the beginning of the table, tagged with the word "Reference" followed by an integer (the reference number) followed by the description of the reference. For example:
每种语言都应该有自己的语言变体表，由相关团体、组织或其他机构提供。该表通常基于一些既定标准。定义语言变量表的小组应在表的开头记录对适当标准的引用，标记为“引用”一词，后跟整数（引用号），后跟引用说明。例如：
Reference 1 CP936 (commonly known as GBK) Reference 2 zVariant, zTradVariant, zSimpVariant in Unihan.txt Reference 3 List of Simplified Character Table (Simplified column) Reference 4 zSimpVariant in Unihan.txt Reference 5 Variant that exists in GB2312, common simplified Hanzi
参考文献1 CP936（俗称GBK）参考文献2 Unihan.txt中的zVariant、zTradVariant、zSimpVariant参考文献3简化字符表列表（简化列）参考文献4 Unihan.txt中的zSimpVariant参考文献5 GB2312中存在的变体，通用简化汉字
Each Language Variant Table must have a version number and its release date. This is tagged with the word "Version" followed by an integer then followed by the date in the format YYYYMMDD, where YYYY is the 4-digit year, MM is the 2-digit month, and DD is the 2-digit day of the publication date of the table.
每个语言变体表必须有版本号及其发布日期。该表标记为“版本”，后跟一个整数，然后是格式为YYYYMMDD的日期，其中YYYY是4位数的年份，MM是2位数的月份，DD是表的发布日期的2位数的日期。
Version 1 20020701 # July 2002 Version 1
版本1 20020701#2002年7月版本1
The table has three columns, separated by semicolons: "Valid Code Point"; "Preferred Variant(s)"; and "Character Variant(s)".
该表有三列，以分号分隔：“有效代码点”；“首选变体”；及"字符变体。
The "Valid Code Point" is the subset of Unicode characters that are valid to be registered.
“有效代码点”是可有效注册的Unicode字符的子集。
There can be more than one Preferred Variant; hence there could be multiple entries in the "Preferred Variant(s)" column. If the "Preferred Variant(s)" column is empty, then there is no corresponding Preferred Variant; in other words, the Preferred Variant is null, there is no corresponding preferred variant codepoint, and no processing to add labels for preferred variants occurs." Unless local policy dictates otherwise, the procedures above will result in only those labels that reflect the valid code point being activated (registered) into the zone file.
可以有多个首选变体；因此，“首选变量”列中可能有多个条目。如果“首选变量”列为空，则没有相应的首选变量；换句话说，首选变量为空，没有相应的首选变量代码点，并且没有为首选变量添加标签的处理。”除非当地政策另有规定，否则上述过程将导致仅将反映有效代码点的标签激活（注册）到区域文件中。
The "Character Variant(s)" column contains all Character Variants of the Code Point. Since the Code Point is always a variant of itself, to avoid redundancy, the Code Point is assumed to be part of the "Character Variant(s)" and need not be repeated in the "Character Variant(s)" column.
“字符变体”列包含代码点的所有字符变体。由于代码点始终是其自身的变体，为避免冗余，代码点被假定为“字符变体”的一部分，无需在“字符变体”列中重复。
If the variant in the "Preferred Variant(s)" or the "Character Variant(s)" column is composed of a sequence of Code Points, then sequence of Code Points is listed separated by a space.
如果“首选变量”或“字符变量”列中的变量由一系列代码点组成，则代码点序列以空格分隔。
If there are multiple variants in the "Preferred Variant(s)" or the "Character Variant(s)" column, then each variant is separated by a comma.
如果“首选变量”或“字符变量”列中有多个变量，则每个变量用逗号分隔。
Any Code Point listed in the "Preferred Variant(s)" column must be allowed by the rules for the relevant language to be registered. However, this is not a requirement for the entries in the "Character Variant(s)" column; it is possible that some of those entries may not be allowed to be registered.
“首选变体”列中列出的任何代码点必须得到相关语言注册规则的允许。但是，“字符变体”列中的条目不要求这样做；其中一些条目可能不允许注册。
Every Code Point in the table should have a corresponding reference number (associated with the references) specified to justify the entry. The reference number is placed in parentheses after the Code Point. If there is more than one reference, then the numbers are placed within a single set of parentheses and separated by commas.
表中的每个代码点都应指定相应的参考编号（与参考关联），以证明条目的合理性。参考号放在代码点后的括号中。如果有多个引用，则将数字放在一组括号内，并用逗号分隔。
As discussed in the Introduction, substantially-unrestricted use of international (non-ASCII) characters in domain name labels may cause user confusion and invite various types of attacks. In particular, in the case of CJK languages, an attacker has an opportunity to divert or confuse users as a result of different characters (or, more specifically, assigned code points) with identical or similar semantics. These Guidelines provide a partial remedy for those risks by supplying a framework for prohibiting inappropriate characters from being registered at all and for permitting "variant" characters to be grouped together and reserved, so that they can only be registered in the DNS by the same owner. However, the system it suggests is no better or worse than the per-zone and per-language tables whose format and use this document specifies. Specific tables, and any additional local processing, will reflect per-zone decisions about the balance between risk and flexibility of registrations. And, of course, errors in construction of those tables may significantly reduce the quality of protection provided.
正如引言中所讨论的，在域名标签中基本上不受限制地使用国际（非ASCII）字符可能会导致用户混淆，并引发各种类型的攻击。特别是在CJK语言的情况下，由于具有相同或类似语义的不同字符（或更具体地说，指定的代码点），攻击者有机会转移或混淆用户。这些指南提供了一个框架，用于禁止不适当的字符注册，并允许将“变体”字符分组并保留，以便它们只能由同一所有者在DNS中注册，从而为这些风险提供了部分补救措施。然而，它所建议的系统并不比本文档指定的格式和用途的每区域和每语言表更好或更差。具体表格和任何额外的本地处理将反映每个区域关于注册风险和灵活性之间平衡的决定。当然，这些表的构造错误可能会显著降低所提供保护的质量。
As a convenience to the reader, this section lists all of the special terminology used in this document, with a pointer to the section in which it is defined.
为方便读者阅读，本节列出了本文件中使用的所有特殊术语，并附有一个指向定义该术语的章节的指针。
Activated Label 2.1.17 Activation 2.1.4 Active Label 2.1.17 Character Variant 2.1.14 Character Variant Label 2.1.16 CJK Characters 2.1.9
激活标签2.1.17激活2.1.4激活标签2.1.17字符变体2.1.14字符变体标签2.1.16 CJK字符2.1.9
Code point 2.1.7 Code Point Variant 2.1.14 FQDN 2.1.3 Hostname 2.1.1 IDL 2.1.2 IDL Package 2.1.18 IDN 2.1.1 Internationalized Domain Label 2.1.2 ISO/IEC 10646 2.1.6 Label String 2.1.10 Language name codes 2.1.5 Language Variant Table 2.1.11 LDH Subset 2.1.1 Preferred Code Point 2.1.13 Preferred Variant 2.1.13 Preferred Variant Label 2.1.15 Registration 2.1.4 Reserved 2.1.18 RFC3066 2.1.5 Table 2.1.11 UCS 2.1.6 Unicode Character 2.1.7 Unicode String 2.1.8 Valid Code Point 2.1.12 Variant Table 2.1.11 Zone Variant 2.1.17
Code point 2.1.7 Code Point Variant 2.1.14 FQDN 2.1.3 Hostname 2.1.1 IDL 2.1.2 IDL Package 2.1.18 IDN 2.1.1 Internationalized Domain Label 2.1.2 ISO/IEC 10646 2.1.6 Label String 2.1.10 Language name codes 2.1.5 Language Variant Table 2.1.11 LDH Subset 2.1.1 Preferred Code Point 2.1.13 Preferred Variant 2.1.13 Preferred Variant Label 2.1.15 Registration 2.1.4 Reserved 2.1.18 RFC3066 2.1.5 Table 2.1.11 UCS 2.1.6 Unicode Character 2.1.7 Unicode String 2.1.8 Valid Code Point 2.1.12 Variant Table 2.1.11 Zone Variant 2.1.17translate error, please retry
The authors gratefully acknowledge the contributions of:
作者衷心感谢以下方面的贡献：
- V. CHEN, N. HSU, H. HOTTA, S. TASHIRO, Y. YONEYA, and other Joint Engineering Team members at the JET meeting in Bangkok, Thailand.
- V.CHEN、N.HSU、H.HOTTA、S.TASHIRO、Y.YONEYA和其他联合工程团队成员出席了在泰国曼谷举行的JET会议。
- Yves Arrouye, an observer at the JET meeting in Bangkok, for his contribution on the IDL Package.
- 伊夫·阿罗耶（Yves Arrouye），曼谷喷气式飞机会议观察员，感谢他对IDL计划的贡献。
- Those who commented on, and made suggestions about, earlier versions, including Harald ALVESTRAND, Erin CHEN, Patrik FALTSTROM, Paul HOFFMAN, Soobok LEE, LEE Xiaodong, MAO Wei, Erik NORDMARK, and L.M. TSENG.
- 那些对早期版本发表评论并提出建议的人，包括哈拉尔·阿尔维斯特朗、陈艾琳、帕特里克·法茨特罗姆、保罗·霍夫曼、李秀博、李晓东、毛伟、埃里克·诺德马克和曾立明。
[ABNF] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]Crocker，D.和P.Overell，编辑，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[STD13] Mockapetris, P., "Domain names concepts and facilities" STD 13, RFC 1034, November 1987. Mockapetris, P., "Domain names implementation and specification", STD 13, RFC 1035, November 1987.
[STD13]Mockapetris，P.，“域名概念和设施”STD 13，RFC 1034，1987年11月。Mockapetris，P.，“域名实现和规范”，STD 13，RFC 10351987年11月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages," BCP 47, RFC 3066, January 2001.
[RFC3066]Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[IDNA] Faltstrom, P., Hoffman, P. and A. M. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[IDNA]Faltstrom，P.，Hoffman，P.和A.M.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[PUNYCODE] Costello, A.M., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[PUNYCODE]Costello，A.M.，“PUNYCODE：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，2003年3月。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[STRINGPREP]Hoffman，P.和M.Blanchet，“国际化弦的准备（“STRINGPREP”）”，RFC 3454，2002年12月。
[NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[NAMEPREP]Hoffman，P.和M.Blanchet，“NAMEPREP：国际化域名（IDN）的Stringprep配置文件”，RFC 34912003年3月。
[IS10646] A product of ISO/IEC JTC1/SC2/WG2, Work Item JTC1.02.18 (ISO/IEC 10646). It is a multipart standard: Part 1, published as ISO/IEC 10646- 1:2000(E), covers the Architecture and Basic Multilingual Plane, and Part 2, published as ISO/IEC 10646-2:2001(E), covers the supplementary (additional) planes.
[IS10646]是ISO/IEC JTC1/SC2/WG2工作项JTC1.02.18（ISO/IEC 10646）的产品。它是一个多部分标准：第1部分（以ISO/IEC 10646-1:2000（E）的形式发布）涵盖了体系结构和基本多语言平面，第2部分（以ISO/IEC 10646-2:2001（E）的形式发布）涵盖了补充（附加）平面。
[UNIHAN] Unicode Han Database, Unicode Consortium ftp://ftp.unicode.org/Public/UNIDATA/Unihan.txt.
[UNIHAN]Unicode Han数据库，Unicode联盟ftp://ftp.unicode.org/Public/UNIDATA/Unihan.txt.
[UNICODE] The Unicode Consortium, "The Unicode Standard Version 3.0," ISBN 0-201-61633-5. Unicode Standard Annex #28 (http://www.unicode.org/unicode/reports/tr28/) defines Version 3.2 of the Unicode Standard, which is definitive for IDNA and this document.
[UNICODE]UNICODE联盟，“UNICODE标准版本3.0”，ISBN 0-201-61633-5。Unicode标准附件#28(http://www.unicode.org/unicode/reports/tr28/)定义Unicode标准的3.2版，这是IDNA和本文档的最终版本。
[ISO7098] ISO 7098;1991 Information and documentation Romanization of Chinese, ISO/TC46/SC2.
[ISO7098]ISO7098；1991信息和文件中文罗马化，ISO/TC46/SC2。
[IANA-LVTABLES] Internet Assigned Numbers Authority (IANA), IDN
Character Registry.
http://www.iana.org/assignments/idn/
[IANA-LVTABLES] Internet Assigned Numbers Authority (IANA), IDN
Character Registry.
http://www.iana.org/assignments/idn/
[IDN-WG] IETF Internationalized Domain Names Working Group, now concluded,idn@ops.ietf.org, James Seng, Marc Blanchet, co-chairs, http://www.i-d-n.net/.
[IDN-WG]IETF国际化域名工作组，现已结束，idn@ops.ietf.org，James Seng，Marc Blanchet，联合主席，http://www.i-d-n.net/.
[UDRP] ICANN, "Uniform Domain Name Dispute Resolution
Policy", October 1999,
http://www.icann.org/udrp/udrp-policy-24oct99.htm
[UDRP] ICANN, "Uniform Domain Name Dispute Resolution
Policy", October 1999,
http://www.icann.org/udrp/udrp-policy-24oct99.htm
[ISO639] "ISO 639:1988 (E/F) Code for the representation of names of languages", International Organization for Standardization, 1st edition, 1988-04-01.
[ISO639]“ISO 639:1988（E/F）语言名称表示代码”，国际标准化组织，第1版，1988-04-01。
The formal responsibility for this document and the ideas it contains lie with K. Koniski, K. Huang, H. Qian, and Y. Ko. These authors are listed on the first page as authors of record, and they are the appropriate the long-term contacts for questions and comments on this RFC. On the other hand, J. Seng, J. Klensin, and W. Rickard served as editors of the document, transcribing and translating the ideas of the four authors and the teams they represented into the current written form. They were the primary contacts during the editing process, but not in the long term.
本文件及其包含的思想由K.Koniski、K.Huang、H.Qian和Y.Ko承担正式责任。这些作者作为记录作者列在第一页上，他们是本RFC问题和评论的长期联系人。另一方面，J.Seng、J.Klensin和W.Rickard担任该文件的编辑，将四位作者及其代表的团队的想法转录并翻译成当前的书面形式。他们是编辑过程中的主要联系人，但不是长期联系人。
Kazunori KONISHI JPNIC Kokusai-Kougyou-Kanda Bldg 6F 2-3-4 Uchi-Kanda, Chiyoda-ku Tokyo 101-0047 Japan
日本东京千代田区内神田2-3-4楼Kokusai Kougyou Kanda大厦6楼
Phone: +81 49-278-7313
EMail: konishi@jp.apan.net
Phone: +81 49-278-7313
EMail: konishi@jp.apan.net
Kenny HUANG TWNIC 3F, 16, Kang Hwa Street, Taipei Taiwan
台湾台北市康华街16号黄建豪三楼
Phone: 886-2-2658-6510 EMail: huangk@alum.sinica.edu
电话：886-2-2658-6510电子邮件：huangk@alum.sinica.edu
QIAN Hualin CNNIC No.6 Branch-box of No.349 Mailbox, Beijing 100080 Peoples Republic of China
钱华林中国互联网络信息中心349号邮箱6号分机箱，中华人民共和国北京100080
EMail: Hlqian@cnnic.net.cn
EMail: Hlqian@cnnic.net.cn
KO YangWoo PeaceNet Yangchun P.O. Box 81 Seoul 158-600 Korea
高阳宇和平网阳春邮政信箱81首尔158-600韩国
EMail: yw@mrko.pe.kr
EMail: yw@mrko.pe.kr
James SENG 180 Lompang Road #22-07 Singapore 670180 Phone: +65 9638-7085
James SENG Lompang路180号#22-07新加坡670180电话：+65 9638-7085
EMail: jseng@pobox.org.sg
EMail: jseng@pobox.org.sg
John C KLENSIN 1770 Massachusetts Avenue, No. 322 Cambridge, MA 02140 U.S.A.
美国马萨诸塞州剑桥322号马萨诸塞大道1770号，邮编02140。
EMail: Klensin+ietf@jck.com
EMail: Klensin+ietf@jck.com
Wendy RICKARD The Rickard Group 16 Seminary Ave Hopewell, NJ 08525 USA
温迪·里卡德美国新泽西州霍普韦尔神学院16号里卡德集团，邮编：08525
EMail: rickard@rickardgroup.com
EMail: rickard@rickardgroup.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。