Internet Engineering Task Force (IETF) J. Klensin
Request for Comments: 5891 August 2010
Obsoletes: 3490, 3491
Updates: 3492
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Klensin
Request for Comments: 5891 August 2010
Obsoletes: 3490, 3491
Updates: 3492
Category: Standards Track
ISSN: 2070-1721
Internationalized Domain Names in Applications (IDNA): Protocol
应用程序中的国际化域名（IDNA）：协议
Abstract
摘要
This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text.
本文件是国际域名（IDN）的修订协议定义。其他文档中提供了更改的基本原理、与旧规范的关系以及重要术语。本文档指定了协议机制，称为应用程序中的国际化域名（IDNA），用于以不需要更改DNS本身的方式注册和查找IDN。IDNA仅用于处理域名，而不是自由文本。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5891.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5891.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements and Applicability . . . . . . . . . . . . . . . . 5
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. DNS Resource Records . . . . . . . . . . . . . . . . . 6
3.2.2. Non-Domain-Name Data Types Stored in the DNS . . . . . 6
4. Registration Protocol . . . . . . . . . . . . . . . . . . . . 6
4.1. Input to IDNA Registration . . . . . . . . . . . . . . . . 7
4.2. Permitted Character and Label Validation . . . . . . . . . 7
4.2.1. Input Format . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Rejection of Characters That Are Not Permitted . . . . 8
4.2.3. Label Validation . . . . . . . . . . . . . . . . . . . 8
4.2.4. Registration Validation Requirements . . . . . . . . . 9
4.3. Registry Restrictions . . . . . . . . . . . . . . . . . . 9
4.4. Punycode Conversion . . . . . . . . . . . . . . . . . . . 9
4.5. Insertion in the Zone . . . . . . . . . . . . . . . . . . 10
5. Domain Name Lookup Protocol . . . . . . . . . . . . . . . . . 10
5.1. Label String Input . . . . . . . . . . . . . . . . . . . . 10
5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 10
5.3. A-label Input . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Validation and Character List Testing . . . . . . . . . . 11
5.5. Punycode Conversion . . . . . . . . . . . . . . . . . . . 13
5.6. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Summary of Major Changes from IDNA2003 . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements and Applicability . . . . . . . . . . . . . . . . 5
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. DNS Resource Records . . . . . . . . . . . . . . . . . 6
3.2.2. Non-Domain-Name Data Types Stored in the DNS . . . . . 6
4. Registration Protocol . . . . . . . . . . . . . . . . . . . . 6
4.1. Input to IDNA Registration . . . . . . . . . . . . . . . . 7
4.2. Permitted Character and Label Validation . . . . . . . . . 7
4.2.1. Input Format . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Rejection of Characters That Are Not Permitted . . . . 8
4.2.3. Label Validation . . . . . . . . . . . . . . . . . . . 8
4.2.4. Registration Validation Requirements . . . . . . . . . 9
4.3. Registry Restrictions . . . . . . . . . . . . . . . . . . 9
4.4. Punycode Conversion . . . . . . . . . . . . . . . . . . . 9
4.5. Insertion in the Zone . . . . . . . . . . . . . . . . . . 10
5. Domain Name Lookup Protocol . . . . . . . . . . . . . . . . . 10
5.1. Label String Input . . . . . . . . . . . . . . . . . . . . 10
5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 10
5.3. A-label Input . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Validation and Character List Testing . . . . . . . . . . 11
5.5. Punycode Conversion . . . . . . . . . . . . . . . . . . . 13
5.6. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Summary of Major Changes from IDNA2003 . . . . . . . 17
This document supplies the protocol definition for Internationalized Domain Names in Applications (IDNA), with the version specified here known as IDNA2008. Essential definitions and terminology for understanding this document and a road map of the collection of documents that make up IDNA2008 appear in a separate Definitions document [RFC5890]. Appendix A discusses the relationship between this specification and the earlier version of IDNA (referred to here as "IDNA2003"). The rationale for these changes, along with considerable explanatory material and advice to zone administrators who support IDNs, is provided in another document, known informally in this series as the "Rationale document" [RFC5894].
本文档提供了应用程序中国际化域名（IDNA）的协议定义，此处指定的版本称为IDNA2008。理解本文件的基本定义和术语以及构成IDNA2008的文件集合路线图见单独的定义文件[RFC5890]。附录A讨论了本规范与IDNA早期版本（此处称为“IDNA2003”）之间的关系。这些变更的基本原理，以及对支持IDN的区域管理员的大量解释性材料和建议，在另一份文件中提供，在本系列中非正式地称为“基本原理文件”[RFC5894]。
IDNA works by allowing applications to use certain ASCII [ASCII] string labels (beginning with a special prefix) to represent non-ASCII name labels. Lower-layer protocols need not be aware of this; therefore, IDNA does not change any infrastructure. In particular, IDNA does not depend on any changes to DNS servers, resolvers, or DNS protocol elements, because the ASCII name service provided by the existing DNS can be used for IDNA.
IDNA允许应用程序使用某些ASCII[ASCII]字符串标签（以特殊前缀开头）来表示非ASCII名称标签。低层协议不需要意识到这一点；因此，IDNA不会改变任何基础设施。特别是，IDNA不依赖于对DNS服务器、解析程序或DNS协议元素的任何更改，因为现有DNS提供的ASCII名称服务可用于IDNA。
IDNA applies only to a specific subset of DNS labels. The base DNS standards [RFC1034] [RFC1035] and their various updates specify how to combine labels into fully-qualified domain names and parse labels out of those names.
IDNA仅适用于DNS标签的特定子集。基本DNS标准[RFC1034][RFC1035]及其各种更新规定了如何将标签组合成完全限定的域名，并从这些域名中解析标签。
This document describes two separate protocols, one for IDN registration (Section 4) and one for IDN lookup (Section 5). These two protocols share some terminology, reference data, and operations.
本文档描述了两个独立的协议，一个用于IDN注册（第4节），另一个用于IDN查找（第5节）。这两个协议共享一些术语、参考数据和操作。
As mentioned above, terminology used as part of the definition of IDNA appears in the Definitions document [RFC5890]. It is worth noting that some of this terminology overlaps with, and is consistent with, that used in Unicode or other character set standards and the DNS. Readers of this document are assumed to be familiar with the associated Definitions document and with the DNS-specific terminology in RFC 1034 [RFC1034].
如上所述，作为IDNA定义一部分的术语出现在定义文档[RFC5890]中。值得注意的是，其中一些术语与Unicode或其他字符集标准和DNS中使用的术语重叠，并且是一致的。假定本文档的读者熟悉相关定义文档以及RFC 1034[RFC1034]中的DNS特定术语。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
IDNA makes the following requirements:
IDNA提出以下要求：
1. Whenever a domain name is put into a domain name slot that is not IDNA-aware (see Section 2.3.2.6 of the Definitions document [RFC5890]), it MUST contain only ASCII characters (i.e., its labels must be either A-labels or NR-LDH labels), unless the DNS application is not subject to historical recommendations for "hostname"-style names (see RFC 1034 [RFC1034] and Section 3.2.1).
1. 每当将域名放入不支持IDNA的域名槽时（参见定义文档[RFC5890]第2.3.2.6节），它必须仅包含ASCII字符（即，其标签必须是a标签或NR-LDH标签），除非DNS应用程序不受“主机名”样式名称的历史建议的约束（参见RFC 1034[RFC1034]和第3.2.1节）。
2. Labels MUST be compared using equivalent forms: either both A-label forms or both U-label forms. Because A-labels and U-labels can be transformed into each other without loss of information, these comparisons are equivalent (however, in practice, comparison of U-labels requires first verifying that they actually are U-labels and not just Unicode strings). A pair of A-labels MUST be compared as case-insensitive ASCII (as with all comparisons of ASCII DNS labels). U-labels MUST be compared as-is, without case folding or other intermediate steps. While it is not necessary to validate labels in order to compare them, successful comparison does not imply validity. In many cases, not limited to comparison, validation may be important for other reasons and SHOULD be performed.
2. 标签必须使用等效形式进行比较：A标签形式或U标签形式。由于A标签和U标签可以在不丢失信息的情况下相互转换，因此这些比较是等效的（然而，在实践中，U标签的比较需要首先验证它们实际上是U标签，而不仅仅是Unicode字符串）。一对A标签必须作为不区分大小写的ASCII进行比较（与所有ASCII DNS标签的比较一样）。U型标签必须按原样进行比较，无需折叠包装箱或其他中间步骤。虽然没有必要验证标签以进行比较，但成功的比较并不意味着有效性。在许多情况下（不限于比较），验证可能因其他原因而很重要，因此应进行验证。
3. Labels being registered MUST conform to the requirements of Section 4. Labels being looked up and the lookup process MUST conform to the requirements of Section 5.
3. 正在注册的标签必须符合第4节的要求。正在查找的标签和查找过程必须符合第5节的要求。
IDNA applies to all domain names in all domain name slots in protocols except where it is explicitly excluded. It does not apply to domain name slots that do not use the LDH syntax rules as described in the Definitions document [RFC5890].
IDNA适用于协议中所有域名槽中的所有域名，明确排除的除外。它不适用于不使用定义文档[RFC5890]中所述LDH语法规则的域名插槽。
Because it uses the DNS, IDNA applies to many protocols that were specified before it was designed. IDNs occupying domain name slots in those older protocols MUST be in A-label form until and unless those protocols and their implementations are explicitly upgraded to be aware of IDNs and to accept the U-label form. IDNs actually appearing in DNS queries or responses MUST be A-labels.
由于它使用DNS，IDNA适用于许多在设计之前指定的协议。在那些旧协议中占用域名插槽的IDN必须采用A标签形式，直到并且除非这些协议及其实现被明确升级以了解IDN并接受U标签形式。DNS查询或响应中实际出现的IDN必须是A标签。
IDNA-aware protocols and implementations MAY accept U-labels, A-labels, or both as those particular protocols specify. IDNA is not defined for extended label types (see RFC 2671 [RFC2671], Section 3).
IDNA感知的协议和实现可以接受U标签、A标签，或者这些特定协议指定的两者。未为扩展标签类型定义IDNA（参见RFC 2671[RFC2671]，第3节）。
IDNA applies only to domain names in the NAME and RDATA fields of DNS resource records whose CLASS is IN. See the DNS specification [RFC1035] for precise definitions of these terms.
IDNA仅适用于类在中的DNS资源记录的名称和RDATA字段中的域名。有关这些术语的精确定义，请参见DNS规范[RFC1035]。
The application of IDNA to DNS resource records depends entirely on the CLASS of the record, and not on the TYPE except as noted below. This will remain true, even as new TYPEs are defined, unless a new TYPE defines TYPE-specific rules. Special naming conventions for SRV records (and "underscore labels" more generally) are incompatible with IDNA coding as discussed in the Definitions document [RFC5890], especially Section 2.3.2.3. Of course, underscore labels may be part of a domain that uses IDN labels at higher levels in the tree.
IDNA对DNS资源记录的应用完全取决于记录的类别，而不取决于类型，除非如下所述。即使定义了新类型，这仍然是正确的，除非新类型定义了特定于类型的规则。SRV记录的特殊命名约定（以及更一般的“下划线标签”）与定义文件[RFC5890]中讨论的IDNA编码不兼容，特别是第2.3.2.3节。当然，下划线标签可能是在树的更高级别使用IDN标签的域的一部分。
Although IDNA enables the representation of non-ASCII characters in domain names, that does not imply that IDNA enables the representation of non-ASCII characters in other data types that are stored in domain names, specifically in the RDATA field for types that have structured RDATA format. For example, an email address local part is stored in a domain name in the RNAME field as part of the RDATA of an SOA record (e.g., hostmaster@example.com would be represented as hostmaster.example.com). IDNA does not update the existing email standards, which allow only ASCII characters in local parts. Even though work is in progress to define internationalization for email addresses [RFC4952], changes to the email address part of the SOA RDATA would require action in, or updates to, other standards, specifically those that specify the format of the SOA RR.
尽管IDNA支持在域名中表示非ASCII字符，但这并不意味着IDNA支持在存储在域名中的其他数据类型中表示非ASCII字符，特别是在RDATA字段中表示具有结构化RDATA格式的类型。例如，电子邮件地址本地部分存储在RNAME字段中的域名中，作为SOA记录RDATA的一部分（例如。，hostmaster@example.com将表示为hostmaster.example.com）。IDNA不更新现有的电子邮件标准，该标准只允许本地部分使用ASCII字符。尽管定义电子邮件地址国际化[RFC4952]的工作正在进行中，但对SOA RDATA的电子邮件地址部分的更改需要在其他标准中采取行动或更新，特别是那些指定SOA RR格式的标准。
This section defines the model for registering an IDN. The model is implementation independent; any sequence of steps that produces exactly the same result for all labels is considered a valid implementation.
本节定义了注册IDN的模型。该模型是独立于实现的；为所有标签生成完全相同结果的任何步骤序列都被视为有效的实现。
Note that, while the registration (this section) and lookup protocols (Section 5) are very similar in most respects, they are not identical, and implementers should carefully follow the steps described in this specification.
请注意，尽管注册（本节）和查找协议（第5节）在大多数方面非常相似，但它们并不完全相同，实现者应仔细遵循本规范中描述的步骤。
Registration processes, especially processing by entities (often called "registrars") who deal with registrants before the request actually reaches the zone manager ("registry") are outside the scope of this definition and may differ significantly depending on local needs. By the time a string enters the IDNA registration process as described in this specification, it MUST be in Unicode and in Normalization Form C (NFC [Unicode-UAX15]). Entities responsible for zone files ("registries") MUST accept only the exact string for which registration is requested, free of any mappings or local adjustments. They MAY accept that input in any of three forms:
注册流程，特别是在请求实际到达区域管理人（“注册人”）之前与注册人打交道的实体（通常称为“注册人”）的处理，不在本定义的范围内，并且可能因当地需要而存在显著差异。当字符串进入本规范所述的IDNA注册过程时，它必须是Unicode格式和规范化格式C（NFC[Unicode-UAX15]）。负责区域文件（“注册表”）的实体必须只接受请求注册的确切字符串，不接受任何映射或本地调整。他们可以接受以下三种形式的输入：
1. As a pair of A-label and U-label.
1. 作为一对a标签和U标签。
2. As an A-label only.
2. 仅作为A标签。
3. As a U-label only.
3. 仅作为U型标签。
The first two of these forms are RECOMMENDED because the use of A-labels avoids any possibility of ambiguity. The first is normally preferred over the second because it permits further verification of user intent (see Section 4.2.1).
建议使用前两种形式，因为使用A标签可避免任何歧义的可能性。第一种方法通常优于第二种方法，因为它允许进一步验证用户意图（见第4.2.1节）。
If both the U-label and A-label forms are available, the registry MUST ensure that the A-label form is in lowercase, perform a conversion to a U-label, perform the steps and tests described below on that U-label, and then verify that the A-label produced by the step in Section 4.4 matches the one provided as input. In addition, the U-label that was provided as input and the one obtained by conversion of the A-label MUST match exactly. If, for some reason, these tests fail, the registration MUST be rejected.
如果U-label和A-label表格均可用，注册中心必须确保A-label表格为小写，执行到U-label的转换，对该U-label执行下述步骤和测试，然后验证第4.4节中步骤生成的A-label与作为输入提供的A-label匹配。此外，作为输入提供的U型标签和通过转换A型标签获得的U型标签必须完全匹配。如果由于某种原因，这些测试失败，则必须拒绝注册。
If only an A-label was provided and the conversion to a U-label is not performed, the registry MUST still verify that the A-label is superficially valid, i.e., that it does not violate any of the rules of Punycode encoding [RFC3492] such as the prohibition on trailing hyphen-minus, the requirement that all characters be ASCII, and so on. Strings that appear to be A-labels (e.g., they start with "xn--") and strings that are supplied to the registry in a context reserved for A-labels (such as a field in a form to be filled out), but that are not valid A-labels as described in this paragraph, MUST NOT be placed in DNS zones that support IDNA.
如果只提供了A标签，并且没有执行到U标签的转换，注册表仍然必须验证A标签表面上是否有效，即它没有违反Punycode编码[RFC3492]的任何规则，例如禁止尾随连字符减号、所有字符都必须是ASCII等。看起来是A标签的字符串（例如，它们以“xn--”开头）和在为A标签保留的上下文中提供给注册表的字符串（例如要填写的表单中的字段），但如本段所述，这些字符串不是有效的A标签，不得放在支持IDNA的DNS区域中。
If only an A-label is provided, the conversion to a U-label is not performed, but the superficial tests described in the previous paragraph are performed, registration procedures MAY, and usually will, bypass the tests and actions in the balance of Section 4.2 and in Sections 4.3 and 4.4.
如果仅提供A型标签，则不进行U型标签的转换，而是进行上一段中所述的表面试验，注册程序可能并且通常将绕过第4.2节以及第4.3节和第4.4节中的试验和措施。
The candidate Unicode string MUST NOT contain characters that appear in the "DISALLOWED" and "UNASSIGNED" lists specified in the Tables document [RFC5892].
候选Unicode字符串不得包含表文档[RFC5892]中指定的“不允许”和“未分配”列表中出现的字符。
The proposed label (in the form of a Unicode string, i.e., a string that at least superficially appears to be a U-label) is then examined using tests that require examination of more than one character. Character order is considered to be the on-the-wire order. That order may not be the same as the display order.
然后使用需要检查多个字符的测试来检查提议的标签（以Unicode字符串的形式，即至少表面上看起来是U标签的字符串）。字符顺序被认为是线上顺序。该顺序可能与显示顺序不同。
The Unicode string MUST NOT contain "--" (two consecutive hyphens) in the third and fourth character positions and MUST NOT start or end with a "-" (hyphen).
Unicode字符串的第三和第四个字符位置不得包含“-”（两个连续连字符），且不得以“-”（连字符）开头或结尾。
The Unicode string MUST NOT begin with a combining mark or combining character (see The Unicode Standard, Section 2.11 [Unicode] for an exact definition).
Unicode字符串不得以组合标记或组合字符开头（有关确切定义，请参阅Unicode标准第2.11节[Unicode]）。
The Unicode string MUST NOT contain any characters whose validity is context-dependent, unless the validity is positively confirmed by a contextual rule. To check this, each code point identified as CONTEXTJ or CONTEXTO in the Tables document [RFC5892] MUST have a non-null rule. If such a code point is missing a rule, the label is invalid. If the rule exists but the result of applying the rule is negative or inconclusive, the proposed label is invalid.
Unicode字符串不得包含任何有效性取决于上下文的字符，除非上下文规则明确确认了有效性。要检查这一点，表文档[RFC5892]中标识为CONTEXTJ或CONTEXTO的每个代码点必须具有非空规则。如果这样的代码点缺少规则，则标签无效。如果规则存在，但应用规则的结果为否定或不确定，则建议的标签无效。
If the proposed label contains any characters from scripts that are written from right to left, it MUST meet the Bidi criteria [RFC5893].
如果建议的标签包含从右到左书写的脚本中的任何字符，则必须符合Bidi标准[RFC5893]。
Strings that contain at least one non-ASCII character, have been produced by the steps above, whose contents pass all of the tests in Section 4.2.3, and are 63 or fewer characters long in ASCII-compatible encoding (ACE) form (see Section 4.4), are U-labels.
至少包含一个非ASCII字符的字符串由上述步骤生成，其内容通过了第4.2.3节中的所有测试，并且在ASCII兼容编码（ACE）形式（见第4.4节）中长度不超过63个字符，为U型标签。
To summarize, tests are made in Section 4.2 for invalid characters, invalid combinations of characters, for labels that are invalid even if the characters they contain are valid individually, and for labels that do not conform to the restrictions for strings containing right-to-left characters.
总之，第4.2节对无效字符、无效字符组合、无效标签（即使其包含的字符单独有效）以及不符合从右到左字符字符串限制的标签进行了测试。
In addition to the rules and tests above, there are many reasons why a registry could reject a label. Registries at all levels of the DNS, not just the top level, are expected to establish policies about label registrations. Policies are likely to be informed by the local languages and the scripts that are used to write them and may depend on many factors including what characters are in the label (for example, a label may be rejected based on other labels already registered). See the Rationale document [RFC5894], Section 3.2, for further discussion and recommendations about registry policies.
除了上面的规则和测试之外，注册表可以拒绝标签的原因还有很多。DNS的所有级别的注册中心，而不仅仅是顶级注册中心，都需要建立有关标签注册的策略。策略可能由本地语言和用于编写它们的脚本通知，并且可能取决于许多因素，包括标签中的字符（例如，可能会根据已注册的其他标签拒绝标签）。有关注册表策略的进一步讨论和建议，请参阅基本原理文件[RFC5894]，第3.2节。
The string produced by the steps in Section 4.2 is checked and processed as appropriate to local registry restrictions. Application of those registry restrictions may result in the rejection of some labels or the application of special restrictions to others.
根据本地注册表限制，检查并处理第4.2节中步骤生成的字符串。应用这些注册限制可能导致拒绝某些标签或对其他标签应用特殊限制。
The resulting U-label is converted to an A-label (defined in Section 2.3.2.1 of the Definitions document [RFC5890]). The A-label is the encoding of the U-label according to the Punycode algorithm [RFC3492] with the ACE prefix "xn--" added at the beginning of the string. The resulting string must, of course, conform to the length limits imposed by the DNS. This document does not update or alter the Punycode algorithm specified in RFC 3492 in any way. RFC 3492 does make a non-normative reference to the information about the value and construction of the ACE prefix that appears in RFC 3490 or Nameprep [RFC3491]. For consistency and reader convenience, IDNA2008 effectively updates that reference to point to this document. That change does not alter the prefix itself. The prefix, "xn--", is the same in both sets of documents.
产生的U型标签转换为A型标签（定义文件[RFC5890]第2.3.2.1节中定义）。A标签是根据Punycode算法[RFC3492]对U标签进行编码，并在字符串开头添加ACE前缀“xn--”。当然，生成的字符串必须符合DNS施加的长度限制。本文件不以任何方式更新或更改RFC 3492中规定的Punycode算法。RFC 3492对RFC 3490或Nameprep[RFC3491]中出现的ACE前缀的值和构造信息进行了非规范性引用。为了一致性和读者方便，IDNA2008有效地更新了指向本文档的引用。这种更改不会改变前缀本身。前缀“xn--”在两组文档中是相同的。
With the exception of the maximum string length test on Punycode output, the failure conditions identified in the Punycode encoding procedure cannot occur if the input is a U-label as determined by the steps in Sections 4.1 through 4.3 above.
除Punycode输出上的最大字符串长度测试外，如果输入是由上述第4.1节至第4.3节中的步骤确定的U型标签，则Punycode编码程序中确定的故障条件不会发生。
The label is registered in the DNS by inserting the A-label into a zone.
通过将A标签插入区域，在DNS中注册标签。
Lookup is different from registration and different tests are applied on the client. Although some validity checks are necessary to avoid serious problems with the protocol, the lookup-side tests are more permissive and rely on the assumption that names that are present in the DNS are valid. That assumption is, however, a weak one because the presence of wildcards in the DNS might cause a string that is not actually registered in the DNS to be successfully looked up.
查找与注册不同，并且在客户端上应用了不同的测试。虽然需要进行一些有效性检查以避免协议出现严重问题，但查找端测试更为宽松，并且依赖于DNS中存在的名称是有效的假设。然而，这种假设是很弱的，因为DNS中存在通配符可能会导致在DNS中实际未注册的字符串被成功查找。
The user supplies a string in the local character set, for example, by typing it, clicking on it, or copying and pasting it from a resource identifier, e.g., a Uniform Resource Identifier (URI) [RFC3986] or an Internationalized Resource Identifier (IRI) [RFC3987], from which the domain name is extracted. Alternately, some process not directly involving the user may read the string from a file or obtain it in some other way. Processing in this step and the one specified in Section 5.2 are local matters, to be accomplished prior to actual invocation of IDNA.
用户在本地字符集中提供字符串，例如，通过键入、单击或从资源标识符（例如，从中提取域名的统一资源标识符（URI）[RFC3986]或国际化资源标识符（IRI）[RFC3987]）复制和粘贴该字符串。或者，一些不直接涉及用户的进程可以从文件中读取字符串或以其他方式获取字符串。本步骤中的处理和第5.2节中规定的处理是本地事务，在实际调用IDNA之前完成。
The string is converted from the local character set into Unicode, if it is not already in Unicode. Depending on local needs, this conversion may involve mapping some characters into other characters as well as coding conversions. Those issues are discussed in the mapping-related sections (Sections 4.2, 4.4, 6, and 7.3) of the Rationale document [RFC5894] and in the separate Mapping document [IDNA2008-Mapping]. The result MUST be a Unicode string in NFC form.
如果字符串尚未使用Unicode，则会将其从本地字符集转换为Unicode。根据本地需要，此转换可能涉及将某些字符映射到其他字符以及编码转换。这些问题在基本原理文件[RFC5894]的制图相关章节（第4.2、4.4、6和7.3节）以及单独的制图文件[IDNA2008制图]中进行了讨论。结果必须是NFC格式的Unicode字符串。
If the input to this procedure appears to be an A-label (i.e., it starts in "xn--", interpreted case-insensitively), the lookup application MAY attempt to convert it to a U-label, first ensuring that the A-label is entirely in lowercase (converting it to lowercase
如果此过程的输入似乎是A标签（即，它以“xn--”开头，不区分大小写解释），则查找应用程序可能会尝试将其转换为U标签，首先确保A标签完全是小写的（将其转换为小写）
if necessary), and apply the tests of Section 5.4 and the conversion of Section 5.5 to that form. If the label is converted to Unicode (i.e., to U-label form) using the Punycode decoding algorithm, then the processing specified in those two sections MUST be performed, and the label MUST be rejected if the resulting label is not identical to the original. See Section 8.1 of the Rationale document [RFC5894] for additional discussion on this topic.
如有必要），并应用第5.4节的测试和第5.5节的转换。如果使用Punycode解码算法将标签转换为Unicode（即U标签形式），则必须执行这两部分中指定的处理，如果生成的标签与原始标签不相同，则必须拒绝标签。有关此主题的更多讨论，请参见基本原理文件[RFC5894]第8.1节。
Conversion from the A-label and testing that the result is a U-label SHOULD be performed if the domain name will later be presented to the user in native character form (this requires that the lookup application be IDNA-aware). If those steps are not performed, the lookup process SHOULD at least test to determine that the string is actually an A-label, examining it for the invalid formats specified in the Punycode decoding specification. Applications that are not IDNA-aware will obviously omit that testing; others MAY treat the string as opaque to avoid the additional processing at the expense of providing less protection and information to users.
如果域名稍后将以本机字符形式呈现给用户，则应从A标签转换并测试结果是否为U标签（这要求查找应用程序能够识别IDNA）。如果未执行这些步骤，则查找过程至少应测试以确定字符串实际上是A标签，并检查Punycode解码规范中指定的无效格式。不知道IDNA的应用程序显然会忽略该测试；其他人可能会将字符串视为不透明的，以避免额外的处理，而代价是为用户提供较少的保护和信息。
As with the registration procedure described in Section 4, the Unicode string is checked to verify that all characters that appear in it are valid as input to IDNA lookup processing. As discussed above and in the Rationale document [RFC5894], the lookup check is more liberal than the registration one. Labels that have not been fully evaluated for conformance to the applicable rules are referred to as "putative" labels as discussed in Section 2.3.2.1 of the Definitions document [RFC5890]. Putative U-labels with any of the following characteristics MUST be rejected prior to DNS lookup:
与第4节中描述的注册过程一样，将检查Unicode字符串，以验证其中出现的所有字符作为IDNA查找处理的输入是否有效。如上文和基本原理文件[RFC5894]所述，查找检查比注册检查更自由。如定义文件[RFC5890]第2.3.2.1节所述，未完全评估是否符合适用规则的标签称为“假定”标签。在DNS查找之前，必须拒绝具有以下任何特征的假定U型标签：
o Labels that are not in NFC [Unicode-UAX15].
o 非NFC[Unicode-UAX15]格式的标签。
o Labels containing "--" (two consecutive hyphens) in the third and fourth character positions.
o 在第三和第四个字符位置包含“-”（两个连续连字符）的标签。
o Labels whose first character is a combining mark (see The Unicode Standard, Section 2.11 [Unicode]).
o 第一个字符为组合标记的标签（参见Unicode标准，第2.11节[Unicode]）。
o Labels containing prohibited code points, i.e., those that are assigned to the "DISALLOWED" category of the Tables document [RFC5892].
o 包含禁止代码点的标签，即分配给表格文档“不允许”类别的标签[RFC5892]。
o Labels containing code points that are identified in the Tables document as "CONTEXTJ", i.e., requiring exceptional contextual rule processing on lookup, but that do not conform to those rules. Note that this implies that a rule must be defined, not null: a
o 包含代码点的标签，这些代码点在表格文档中标识为“CONTEXTJ”，即在查找时需要特殊的上下文规则处理，但不符合这些规则。注意，这意味着必须定义一个规则，而不是null:a
character that requires a contextual rule but for which the rule is null is treated in this step as having failed to conform to the rule.
需要上下文规则但规则为空的字符在此步骤中被视为不符合规则。
o Labels containing code points that are identified in the Tables document as "CONTEXTO", but for which no such rule appears in the table of rules. Applications resolving DNS names or carrying out equivalent operations are not required to test contextual rules for "CONTEXTO" characters, only to verify that a rule is defined (although they MAY make such tests to provide better protection or give better information to the user).
o 包含代码点的标签，这些代码点在表格文档中标识为“CONTEXTO”，但在规则表中没有此类规则。解析DNS名称或执行等效操作的应用程序无需测试“CONTEXTO”字符的上下文规则，只需验证规则是否已定义（尽管它们可能进行此类测试以提供更好的保护或向用户提供更好的信息）。
o Labels containing code points that are unassigned in the version of Unicode being used by the application, i.e., in the UNASSIGNED category of the Tables document.
o 包含代码点的标签，这些代码点在应用程序使用的Unicode版本中未分配，即在Tables文档的未分配类别中。
This requirement means that the application must use a list of unassigned characters that is matched to the version of Unicode that is being used for the other requirements in this section. It is not required that the application know which version of Unicode is being used; that information might be part of the operating environment in which the application is running.
此要求意味着应用程序必须使用与本节中其他要求所使用的Unicode版本相匹配的未分配字符列表。应用程序不需要知道使用的是哪个Unicode版本；这些信息可能是运行应用程序的操作环境的一部分。
In addition, the application SHOULD apply the following test.
此外，应用程序应进行以下测试。
o Verification that the string is compliant with the requirements for right-to-left characters specified in the Bidi document [RFC5893].
o 验证字符串是否符合Bidi文件[RFC5893]中规定的从右向左字符的要求。
This test may be omitted in special circumstances, such as when the lookup application knows that the conditions are enforced elsewhere, because an attempt to look up and resolve such strings will almost certainly lead to a DNS lookup failure except when wildcards are present in the zone. However, applying the test is likely to give much better information about the reason for a lookup failure -- information that may be usefully passed to the user when that is feasible -- than DNS resolution failure information alone.
在特殊情况下，例如当查找应用程序知道这些条件在其他地方强制执行时，可以忽略此测试，因为尝试查找和解析此类字符串几乎肯定会导致DNS查找失败，除非区域中存在通配符。然而，应用该测试可能会提供有关查找失败原因的更好信息——在可行时可以有效地传递给用户的信息——而不仅仅是DNS解析失败信息。
For all other strings, the lookup application MUST rely on the presence or absence of labels in the DNS to determine the validity of those labels and the validity of the characters they contain. If they are registered, they are presumed to be valid; if they are not, their possible validity is not relevant. While a lookup application may reasonably issue warnings about strings it believes may be problematic, applications that decline to process a string that conforms to the rules above (i.e., does not look it up in the DNS) are not in conformance with this protocol.
对于所有其他字符串，查找应用程序必须依赖DNS中是否存在标签来确定这些标签的有效性及其包含的字符的有效性。如果它们已注册，则被推定为有效；如果不是，则其可能的有效性不相关。虽然查找应用程序可能会合理地发出有关其认为可能有问题的字符串的警告，但拒绝处理符合上述规则（即，不在DNS中查找）的字符串的应用程序不符合此协议。
The string that has now been validated for lookup is converted to ACE form by applying the Punycode algorithm to the string and then adding the ACE prefix ("xn--").
通过对字符串应用Punycode算法，然后添加ACE前缀（“xn-->”），现在已验证用于查找的字符串将转换为ACE形式。
The A-label resulting from the conversion in Section 5.5 or supplied directly (see Section 5.3) is combined with other labels as needed to form a fully-qualified domain name that is then looked up in the DNS, using normal DNS resolver procedures. The lookup can obviously either succeed (returning information) or fail.
根据需要，将第5.5节中转换产生的或直接提供的A标签（见第5.3节）与其他标签组合，以形成完全限定的域名，然后使用正常的DNS解析程序在DNS中查找该域名。显然，查找可能成功（返回信息）或失败。
Security Considerations for this version of IDNA are described in the Definitions document [RFC5890], except for the special issues associated with right-to-left scripts and characters. The latter are discussed in the Bidi document [RFC5893].
定义文档[RFC5890]中描述了此版本IDNA的安全注意事项，但与从右向左脚本和字符相关的特殊问题除外。后者在Bidi文件[RFC5893]中进行了讨论。
In order to avoid intentional or accidental attacks from labels that might be confused with others, special problems in rendering, and so on, the IDNA model requires that registries exercise care and thoughtfulness about what labels they choose to permit. That issue is discussed in Section 4.3 of this document which, in turn, points to a somewhat more extensive discussion in the Rationale document [RFC5894].
为了避免来自标签的故意或意外攻击（可能与其他标签混淆）、呈现中的特殊问题等，IDNA模型要求注册中心对其选择允许的标签进行谨慎和深思熟虑。本文件第4.3节对该问题进行了讨论，这反过来又指向了基本原理文件[RFC5894]中更广泛的讨论。
IANA actions for this version of IDNA are specified in the Tables document [RFC5892] and discussed informally in the Rationale document [RFC5894]. The components of IDNA described in this document do not require any IANA actions.
此版本IDNA的IANA行动在表格文件[RFC5892]中有规定，并在基本原理文件[RFC5894]中进行了非正式讨论。本文档中描述的IDNA组件不需要任何IANA操作。
While the listed editor held the pen, the original versions of this document represent the joint work and conclusions of an ad hoc design team consisting of the editor and, in alphabetic order, Harald Alvestrand, Tina Dam, Patrik Faltstrom, and Cary Karp. This document draws significantly on the original version of IDNA [RFC3490] both conceptually and for specific text. This second-generation version would not have been possible without the work that went into that first version and especially the contributions of its authors Patrik Faltstrom, Paul Hoffman, and Adam Costello. While Faltstrom was
虽然列出的编辑拿着笔，但本文件的原始版本代表了由编辑和Harald Alvestrand、Tina Dam、Patrik Faltstrom和Cary Karp按字母顺序组成的特设设计团队的共同工作和结论。本文件在概念上和具体文本上均大量借鉴了IDNA[RFC3490]的原始版本。如果没有第一个版本的工作，特别是其作者帕特里克·法茨特罗姆、保罗·霍夫曼和亚当·科斯特洛的贡献，第二代版本就不可能实现。而法尔茨特罗姆
actively involved in the creation of this version, Hoffman and Costello were not and should not be held responsible for any errors or omissions.
霍夫曼和科斯特洛积极参与了本版本的创作，他们不应对任何错误或遗漏负责。
This revision to IDNA would have been impossible without the accumulated experience since RFC 3490 was published and resulting comments and complaints of many people in the IETF, ICANN, and other communities (too many people to list here). Nor would it have been possible without RFC 3490 itself and the efforts of the Working Group that defined it. Those people whose contributions are acknowledged in RFC 3490, RFC 4690 [RFC4690], and the Rationale document [RFC5894] were particularly important.
如果没有RFC 3490出版以来积累的经验以及IETF、ICANN和其他社区许多人（这里列出的人太多）的评论和投诉，IDNA的此次修订是不可能的。如果没有RFC 3490本身和定义它的工作组的努力，也不可能做到这一点。那些贡献在RFC 3490、RFC 4690[RFC4690]和基本原理文件[RFC5894]中得到认可的人尤其重要。
Specific textual changes were incorporated into this document after suggestions from the other contributors, Stephane Bortzmeyer, Vint Cerf, Lisa Dusseault, Paul Hoffman, Kent Karlsson, James Mitchell, Erik van der Poel, Marcos Sanz, Andrew Sullivan, Wil Tan, Ken Whistler, Chris Wright, and other WG participants and reviewers including Martin Duerst, James Mitchell, Subramanian Moonesamy, Peter Saint-Andre, Margaret Wasserman, and Dan Winship who caught specific errors and recommended corrections. Special thanks are due to Paul Hoffman for permission to extract material to form the basis for Appendix A from a draft document that he prepared.
在其他撰稿人斯蒂芬·博茨梅尔、文特·瑟夫、丽莎·杜肖尔、保罗·霍夫曼、肯特·卡尔森、詹姆斯·米切尔、埃里克·范德波尔、马科斯·桑兹、安德鲁·沙利文、威尔特·坦、肯·惠斯勒、克里斯·赖特、约翰·斯泰德·斯泰德·斯泰德·斯泰德·斯泰德·斯泰德·斯泰德·斯泰德·斯泰德·斯泰德·斯泰斯泰斯泰斯，以及其他工作组参与者和评论员，包括Martin Duerst、James Mitchell、Subramanian Moonesay、Peter Saint Andre、Margaret Wasserman和Dan Winship，他们发现了具体错误并建议纠正。特别感谢Paul Hoffman允许从他准备的文件草案中提取材料，作为附录A的基础。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]Costello，A.，“Punycode：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，2003年3月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.
[RFC5892]Faltstrom，P.，Ed.“Unicode代码点和应用程序的国际化域名（IDNA）”，RFC 5892，2010年8月。
[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010.
[RFC5893]Alvestrand，H.，Ed.和C.Karp，“应用程序国际化域名（IDNA）的从右到左脚本”，RFC 5893，2010年8月。
[Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", September 2009, <http://www.unicode.org/reports/tr15/>.
[Unicode-UAX15]Unicode联盟，“Unicode标准附录#15：Unicode规范化表单”，2009年9月<http://www.unicode.org/reports/tr15/>.
[ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968. ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet.
[ASCII]美国国家标准协会（前美国标准协会），“美国信息交换代码”，ANSI X3.4-1968，1968年。ANSI X3.4-1968已被稍作修改的较新版本所取代，但1968年版本仍然是互联网的最终版本。
[IDNA2008-Mapping] Resnick, P. and P. Hoffman, "Mapping Characters in Internationalized Domain Names for Applications (IDNA)", Work in Progress, April 2010.
[IDNA2008映射]Resnick，P.和P.Hoffman，“应用程序国际化域名（IDNA）中的字符映射”，正在进行的工作，2010年4月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491]Hoffman，P.和M.Blanchet，“Nameprep：国际化域名（IDN）的Stringprep配置文件”，RFC 3491，2003年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006.
[RFC4690]Klensin，J.，Faltstrom，P.，Karp，C.，和IAB，“国际化域名（IDN）的审查和建议”，RFC 46902006年9月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952]Klensin，J.和Y.Ko，“国际化电子邮件的概述和框架”，RFC 49522007年7月。
[RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010.
[RFC5894]Klensin，J.“应用程序的国际化域名（IDNA）：背景、解释和基本原理”，RFC 58942010年8月。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 5.0", 2007. Boston, MA, USA: Addison-Wesley. ISBN 0-321-48091-0. This printed reference has now been updated online to reflect additional code points. For code points, the reference at the time this document was published is to Unicode 5.2.
[Unicode]Unicode联盟，“Unicode标准，5.0版”，2007年。美国马萨诸塞州波士顿：艾迪生·韦斯利。ISBN 0-321-48091-0。此打印参考现已在线更新，以反映其他代码点。对于代码点，本文档发布时的参考是Unicode 5.2。
1. Update base character set from Unicode 3.2 to Unicode version agnostic.
1. 将基本字符集从Unicode 3.2更新为Unicode版本不可知。
2. Separate the definitions for the "registration" and "lookup" activities.
2. 将“注册”和“查找”活动的定义分开。
3. Disallow symbol and punctuation characters except where special exceptions are necessary.
3. 不允许使用符号和标点符号，除非有特殊例外情况。
4. Remove the mapping and normalization steps from the protocol and have them, instead, done by the applications themselves, possibly in a local fashion, before invoking the protocol.
4. 从协议中删除映射和规范化步骤，并让它们在调用协议之前由应用程序自己完成（可能以本地方式）。
5. Change the way that the protocol specifies which characters are allowed in labels from "humans decide what the table of code points contains" to "decision about code points are based on Unicode properties plus a small exclusion list created by humans".
5. 将协议指定标签中允许哪些字符的方式从“人类决定代码点表包含什么”更改为“关于代码点的决定基于Unicode属性加上人类创建的小型排除列表”。
6. Introduce the new concept of characters that can be used only in specific contexts.
6. 介绍只能在特定上下文中使用的字符的新概念。
7. Allow typical words and names in languages such as Dhivehi and Yiddish to be expressed.
7. 允许使用Dhivehi和意第绪语等语言表达典型的单词和名称。
8. Make bidirectional domain names (delimited strings of labels, not just labels standing on their own) display in a less surprising fashion, whether they appear in obvious domain name contexts or as part of running text in paragraphs.
8. 使双向域名（标签的分隔字符串，而不仅仅是独立的标签）以不那么令人惊讶的方式显示，无论它们出现在明显的域名上下文中还是作为段落中运行文本的一部分。
9. Remove the dot separator from the mandatory part of the protocol.
9. 从协议的强制部分删除点分隔符。
10. Make some currently valid labels that are not actually IDNA labels invalid.
10. 使一些当前有效但实际上不是IDNA标签的标签无效。
Author's Address
作者地址
John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA
美国马萨诸塞州剑桥322号马萨诸塞大道1770号约翰·C·克伦辛邮编：02140
Phone: +1 617 245 1457
EMail: john+ietf@jck.com
Phone: +1 617 245 1457
EMail: john+ietf@jck.com