Internet Engineering Task Force (IETF) H. Alvestrand, Ed.
Request for Comments: 5893 Google
Category: Standards Track C. Karp
ISSN: 2070-1721 Swedish Museum of Natural History
August 2010
Internet Engineering Task Force (IETF) H. Alvestrand, Ed.
Request for Comments: 5893 Google
Category: Standards Track C. Karp
ISSN: 2070-1721 Swedish Museum of Natural History
August 2010
Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)
应用程序国际化域名（IDNA）的从右到左脚本
Abstract
摘要
The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges. This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion.
在国际化域名（IDN）中使用从右到左的脚本带来了一些挑战。本备忘录根据一些脚本遇到的问题和2003年IDNA Bidi标准中的一些缺陷，为应用程序国际化域名（IDNA）标签提供了新的Bidi规则。
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/rfc5893.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5893.
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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Purpose and Applicability . . . . . . . . . . . . . . . . 2
1.2. Background and History . . . . . . . . . . . . . . . . . . 3
1.3. Structure of the Rest of This Document . . . . . . . . . . 3
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Bidi Rule . . . . . . . . . . . . . . . . . . . . . . . . 6
3. The Requirement Set for the Bidi Rule . . . . . . . . . . . . 6
4. Examples of Issues Found with RFC 3454 . . . . . . . . . . . . 9
4.1. Dhivehi . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Yiddish . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Strings with Numbers . . . . . . . . . . . . . . . . . . . 12
5. Troublesome Situations and Guidelines . . . . . . . . . . . . 12
6. Other Issues in Need of Resolution . . . . . . . . . . . . . . 13
7. Compatibility Considerations . . . . . . . . . . . . . . . . . 14
7.1. Backwards Compatibility Considerations . . . . . . . . . . 14
7.2. Forward Compatibility Considerations . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Purpose and Applicability . . . . . . . . . . . . . . . . 2
1.2. Background and History . . . . . . . . . . . . . . . . . . 3
1.3. Structure of the Rest of This Document . . . . . . . . . . 3
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Bidi Rule . . . . . . . . . . . . . . . . . . . . . . . . 6
3. The Requirement Set for the Bidi Rule . . . . . . . . . . . . 6
4. Examples of Issues Found with RFC 3454 . . . . . . . . . . . . 9
4.1. Dhivehi . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Yiddish . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Strings with Numbers . . . . . . . . . . . . . . . . . . . 12
5. Troublesome Situations and Guidelines . . . . . . . . . . . . 12
6. Other Issues in Need of Resolution . . . . . . . . . . . . . . 13
7. Compatibility Considerations . . . . . . . . . . . . . . . . . 14
7.1. Backwards Compatibility Considerations . . . . . . . . . . 14
7.2. Forward Compatibility Considerations . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
The purpose of this document is to establish a rule that can be applied to Internationalized Domain Name (IDN) labels in Unicode form (U-labels) containing characters from scripts that are written from right to left. It is part of the revised IDNA protocol [RFC5891].
本文档旨在建立一条规则，该规则可应用于Unicode格式的国际化域名（IDN）标签（U-labels），其中包含从右向左写入的脚本中的字符。它是修订后的IDNA协议[RFC5891]的一部分。
When labels satisfy the rule, and when certain other conditions are satisfied, there is only a minimal chance of these labels being displayed in a confusing way by the Unicode bidirectional display algorithm.
当标签满足规则，并且满足某些其他条件时，Unicode双向显示算法以令人困惑的方式显示这些标签的可能性很小。
The other normative documents in the IDNA2008 document set establish criteria for valid labels, including listing the permitted characters. This document establishes additional validity criteria for labels in scripts normally written from right to left.
IDNA2008文件集中的其他规范性文件建立了有效标签的标准，包括列出允许的字符。本文档为通常从右向左编写的脚本中的标签建立了额外的有效性标准。
This specification is not intended to place any requirements on domain names that do not contain characters from such scripts.
本规范无意对不包含此类脚本字符的域名提出任何要求。
The "Stringprep" specification [RFC3454], part of IDNA2003, made the following statement in its Section 6 on the Bidi algorithm:
IDNA2003的一部分“Stringprep”规范[RFC3454]在其第6节中对Bidi算法作了以下声明：
3) If a string contains any RandALCat character, a RandALCat character MUST be the first character of the string, and a RandALCat character MUST be the last character of the string.
3) 如果字符串包含任何RandALCat字符，RandALCat字符必须是字符串的第一个字符，RandALCat字符必须是字符串的最后一个字符。
(A RandALCat character is a character with unambiguously right-to-left directionality.)
（RandALCat角色是具有明确的从右到左方向性的角色。）
The reasoning behind this prohibition was to ensure that every component of a displayed domain name has an unambiguously preferred direction. However, this made certain words in languages written with right-to-left scripts invalid as IDN labels, and in at least one case (Dhivehi) meant that all the words of an entire language were forbidden as IDN labels.
这项禁令背后的理由是确保显示的域名的每个组件都有明确的首选方向。然而，这使得使用从右向左脚本编写的语言中的某些单词作为IDN标签无效，并且至少在一种情况下（Dhivehi）意味着整个语言的所有单词都被禁止作为IDN标签。
This is illustrated below with examples taken from the Dhivehi and Yiddish languages, as written with the Thaana and Hebrew scripts, respectively.
下面用分别用塔纳语和希伯来语书写的迪维希语和意第绪语的例子说明了这一点。
RFC 3454 did not explicitly state the requirement to be fulfilled. Therefore, it is impossible to determine whether a simple relaxation of the rule would continue to fulfill the requirement.
RFC 3454没有明确说明需要满足的要求。因此，不可能确定简单地放宽规则是否能继续满足要求。
While this document specifies rules quite different from RFC 3454, most reasonable labels that were allowed under RFC 3454 will also be allowed under this specification (the most important example of non-permitted labels being labels that mix Arabic and European digits (AN and EN) inside an RTL label, and labels that use AN in an LTR label -- see Section 1.4 for terminology), so the operational impact of using the new rule in the updated IDNA specification is limited.
虽然本文件规定了与RFC 3454完全不同的规则，但根据RFC 3454允许的最合理标签也将在本规范下被允许（不允许标签的最重要示例是混合阿拉伯和欧洲数字（AN和EN）的标签）在RTL标签内部，以及在LTR标签中使用的标签（术语见第1.4节），因此在更新的IDNA规范中使用新规则的操作影响是有限的。
Section 2 defines a rule, the "Bidi rule", which can be used on a domain name label to check how safe it is to use in a domain name of possibly mixed directionality. The primary initial use of this rule is as part of the IDNA2008 protocol [RFC5891].
第2节定义了一条规则，即“Bidi规则”，可用于域名标签，以检查在可能具有混合方向性的域名中使用的安全性。此规则的最初主要用途是作为IDNA2008协议[RFC5891]的一部分。
Section 3 sets out the requirements for defining the Bidi rule.
第3节规定了定义Bidi规则的要求。
Section 4 gives detailed examples that serve as justification for the new rule.
第4节给出了详细的例子，作为新规则的理由。
Section 5 to Section 8 describe various situations that can occur when dealing with domain names with characters of different directionality.
第5节至第8节描述了处理具有不同方向性字符的域名时可能出现的各种情况。
Only Section 1.4 and Section 2 are normative.
只有第1.4节和第2节是规范性的。
The terminology used to describe IDNA concepts is defined in the Definitions document [RFC5890].
定义文档[RFC5890]中定义了用于描述IDNA概念的术语。
The terminology used for the Bidi properties of Unicode characters is taken from the Unicode Standard [Unicode52].
Unicode字符的Bidi属性所使用的术语取自Unicode标准[Unicode52]。
The Unicode Standard specifies a Bidi property for each character. That property controls the character's behavior in the Unicode bidirectional algorithm [Unicode-UAX9]. For reference, here are the values that the Unicode Bidi property can have:
Unicode标准为每个字符指定Bidi属性。该属性控制Unicode双向算法[Unicode-UAX9]中角色的行为。以下是Unicode Bidi属性可以具有的值供参考：
o L - Left to right - most letters in LTR scripts
o L-从左到右-LTR脚本中的大多数字母
o R - Right to left - most letters in non-Arabic RTL scripts
o R-从右到左-非阿拉伯语RTL脚本中的大多数字母
o AL - Arabic letters - most letters in the Arabic script
o AL-阿拉伯语字母-大多数字母为阿拉伯语
o EN - European Number (0-9, and Extended Arabic-Indic numbers)
o 欧洲数字（0-9和扩展的阿拉伯-印度数字）
o ES - European Number Separator (+ and -)
o ES-欧洲数字分隔符（+和-）
o ET - European Number Terminator (currency symbols, the hash sign, the percent sign and so on)
o ET-欧洲数字终止符（货币符号、哈希符号、百分比符号等）
o AN - Arabic Number; this encompasses the Arabic-Indic numbers, but not the Extended Arabic-Indic numbers
o 阿拉伯数字；这包括阿拉伯-印度数字，但不包括扩展阿拉伯-印度数字
o CS - Common Number Separator (. , / : et al)
o CS-常用数字分隔符（，/：等）
o NSM - Nonspacing Mark - most combining accents
o NSM-非空格标记-大多数组合重音
o BN - Boundary Neutral - control characters (ZWNJ, ZWJ, and others)
o BN-边界中性-控制字符（ZWNJ、ZWJ和其他）
o B - Paragraph Separator
o B段分隔符
o S - Segment Separator
o S段分隔符
o WS - Whitespace, including the SPACE character
o WS-空白，包括空格字符
o ON - Other Neutrals, including @, &, parentheses, MIDDLE DOT
o ON-其他中性词，包括@、&、括号、中间点
o LRE, LRO, RLE, RLO, PDF - these are "directional control characters" and are not used in IDNA labels.
o LRE、LRO、RLE、RLO、PDF-这些是“方向控制字符”，不用于IDNA标签。
In this memo, we use "network order" to describe the sequence of characters as transmitted on the wire or stored in a file; the terms "first", "next", "previous", "beginning", "end", "before", and "after" are used to refer to the relationship of characters and labels in network order.
在本备忘录中，我们使用“网络顺序”来描述在电线上传输或存储在文件中的字符序列；术语“第一”、“下一”、“上一”、“开始”、“结束”、“之前”和“之后”用于表示字符和标签在网络顺序中的关系。
We use "display order" to talk about the sequence of characters as imaged on a display medium; the terms "left" and "right" are used to refer to the relationship of characters and labels in display order.
我们使用“显示顺序”来谈论在显示介质上成像的字符序列；术语“左”和“右”用于表示字符和标签在显示顺序中的关系。
Most of the time, the examples use the abbreviations for the Unicode Bidi classes to denote the directionality of the characters; the example string CS L consists of one character of class CS and one character of class L. In some examples, the convention that uppercase characters are of class R or AL, and lowercase characters are of class L is used -- thus, the example string ABC.abc would consist of three right-to-left characters and three left-to-right characters.
大多数情况下，示例使用Unicode Bidi类的缩写来表示字符的方向性；示例字符串CS L由一个CS类字符和一个L类字符组成。在一些示例中，使用大写字符为R类或AL类，小写字符为L类的约定——因此，示例字符串ABC.ABC将由三个从右到左的字符和三个从左到右的字符组成。
The directionality of such examples is determined by context -- for instance, in the sentence "ABC.abc is displayed as CBA.abc", the first example string is in network order, the second example string is in display order.
这些示例的方向性由上下文决定——例如，在“ABC.ABC显示为CBA.ABC”的句子中，第一个示例字符串按网络顺序排列，第二个示例字符串按显示顺序排列。
The term "paragraph" is used in the sense of the Unicode Bidi specification [Unicode-UAX9]. It means "a block of text that has an overall direction, either left to right or right to left", approximately; see the "Unicode Bidirectional Algorithm" [Unicode-UAX9] for details.
术语“段落”在Unicode Bidi规范[Unicode-UAX9]的意义上使用。它的意思是“一块文字，大致上有一个整体方向，从左到右或从右到左”；有关详细信息，请参阅“Unicode双向算法”[Unicode-UAX9]。
"RTL" and "LTR" are abbreviations for "right to left" and "left to right", respectively.
“RTL”和“LTR”分别是“从右到左”和“从左到右”的缩写。
An RTL label is a label that contains at least one character of type R, AL, or AN.
RTL标签是至少包含一个R、AL或An类型字符的标签。
An LTR label is any label that is not an RTL label.
LTR标签是不是RTL标签的任何标签。
A "Bidi domain name" is a domain name that contains at least one RTL label. (Note: This definition includes domain names containing only dots and right-to-left characters. Providing a separate category of "RTL domain names" would not make this specification simpler, so it has not been done.)
“Bidi域名”是至少包含一个RTL标签的域名。（注意：此定义包括仅包含点和从右到左字符的域名。提供单独的“RTL域名”类别不会使此规范更简单，因此未进行此定义。）
The following rule, consisting of six conditions, applies to labels in Bidi domain names. The requirements that this rule satisfies are described in Section 3. All of the conditions must be satisfied for the rule to be satisfied.
以下规则包括六个条件，适用于Bidi域名中的标签。第3节描述了本规则满足的要求。必须满足所有条件才能满足规则。
1. The first character must be a character with Bidi property L, R, or AL. If it has the R or AL property, it is an RTL label; if it has the L property, it is an LTR label.
1. 第一个字符必须是具有Bidi属性L、R或AL的字符。如果它具有R或AL属性，则它是RTL标签；如果它具有L属性，则它是LTR标签。
2. In an RTL label, only characters with the Bidi properties R, AL, AN, EN, ES, CS, ET, ON, BN, or NSM are allowed.
2. 在RTL标签中，仅允许具有Bidi属性R、AL、an、EN、ES、CS、ET、ON、BN或NSM的字符。
3. In an RTL label, the end of the label must be a character with Bidi property R, AL, EN, or AN, followed by zero or more characters with Bidi property NSM.
3. 在RTL标签中，标签的结尾必须是具有Bidi属性R、AL、EN或an的字符，后跟零个或多个具有Bidi属性NSM的字符。
4. In an RTL label, if an EN is present, no AN may be present, and vice versa.
4. 在RTL标签中，如果存在EN，则可能不存在an，反之亦然。
5. In an LTR label, only characters with the Bidi properties L, EN, ES, CS, ET, ON, BN, or NSM are allowed.
5. 在LTR标签中，仅允许具有Bidi属性L、EN、ES、CS、ET、ON、BN或NSM的字符。
6. In an LTR label, the end of the label must be a character with Bidi property L or EN, followed by zero or more characters with Bidi property NSM.
6. 在LTR标签中，标签的结尾必须是具有Bidi属性L或EN的字符，后跟零个或多个具有Bidi属性NSM的字符。
The following guarantees can be made based on the above:
基于上述情况，可作出以下保证：
o In a domain name consisting of only labels that satisfy the rule, the requirements of Section 3 are satisfied. Note that even LTR labels and pure ASCII labels have to be tested.
o 在仅包含符合规则的标签的域名中，满足第3节的要求。请注意，即使是LTR标签和纯ASCII标签也必须进行测试。
o In a domain name consisting of only LDH labels (as defined in the Definitions document [RFC5890]) and labels that satisfy the rule, the requirements of Section 3 are satisfied as long as a label that starts with an ASCII digit does not come after a right-to-left label.
o 在仅由LDH标签（定义文件[RFC5890]中定义）和符合规则的标签组成的域名中，只要以ASCII数字开头的标签不在从右到左标签之后，则满足第3节的要求。
No guarantee is given for other combinations.
其他组合不提供任何保证。
This document, unlike RFC 3454 [RFC3454], provides an explicit justification for the Bidi rule, and states a set of requirements for which it is possible to test whether or not the modified rule fulfills the requirement.
与RFC 3454[RFC3454]不同，本文件为Bidi规则提供了明确的理由，并说明了一组可以测试修改后的规则是否满足要求的要求。
All the text in this document assumes that text containing the labels under consideration will be displayed using the Unicode bidirectional algorithm [Unicode-UAX9].
本文档中的所有文本都假定包含所考虑标签的文本将使用Unicode双向算法[Unicode-UAX9]显示。
The requirements proposed are these:
建议的要求如下：
o Label Uniqueness: No two labels, when presented in display order in the same paragraph, should have the same sequence of characters without also having the same sequence of characters in network order, both when the paragraph has LTR direction and when the paragraph has RTL direction. (This is the criterion that is explicit in RFC 3454). (Note that a label displayed in an RTL paragraph may display the same as a different label displayed in an LTR paragraph and still satisfy this criterion.)
o 标签唯一性：当在同一段落中以显示顺序显示时，当段落具有LTR方向和段落具有RTL方向时，任何两个标签都不应具有相同的字符序列而不具有相同的网络顺序字符序列。（这是RFC 3454中明确的标准）。（请注意，RTL段落中显示的标签可能与LTR段落中显示的不同标签显示相同，但仍满足此标准。）
o Character Grouping: When displaying a string of labels, using the Unicode Bidi algorithm to reorder the characters for display, the characters of each label should remain grouped between the characters delimiting the labels, both when the string is embedded in a paragraph with LTR direction and when it is embedded in a paragraph with RTL direction.
o 字符分组：显示标签字符串时，使用Unicode Bidi算法重新排列要显示的字符，每个标签的字符应在分隔标签的字符之间保持分组，当字符串嵌入具有LTR方向的段落时，以及当它嵌入具有RTL方向的段落时。
Several stronger statements were considered and rejected, because they seem to be impossible to fulfill within the constraints of the Unicode bidirectional algorithm. These include:
考虑并拒绝了几个更强的语句，因为它们似乎不可能在Unicode双向算法的约束下实现。这些措施包括：
o The appearance of a label should be unaffected by its embedding context. This proved impossible even for ASCII labels; the label "123-A" will have a different display order in an RTL context than in an LTR context. (This particular example is, however, disallowed anyway.)
o 标签的外观应不受其嵌入上下文的影响。这被证明是不可能的，即使是ASCII标签；标签“123-A”在RTL上下文中的显示顺序与在LTR上下文中的显示顺序不同。（但无论如何，这一特定示例是不允许的。）
o The sequence of labels should be consistent with network order. This proved impossible -- a domain name consisting of the labels (in network order) L1.R2.R3.L4 will be displayed as L1.R3.R2.L4 in an LTR context. (In an RTL context, it will be displayed as L4.R3.R2.L1).
o 标签的顺序应与网络顺序一致。事实证明这是不可能的——由标签（按网络顺序）L1.R2.R3.L4组成的域名将在LTR上下文中显示为L1.R3.R2.L4。（在RTL上下文中，它将显示为L4.R3.R2.L1）。
o No two domain names should be displayed the same, even under differing directionality. This was shown to be unsound, since the domain name (in network order) ABC.abc will have display order CBA.abc in an LTR context and abc.CBA in an RTL context, while the domain name (network) abc.ABC will have display order abc.CBA in an LTR context and CBA.abc in an RTL context.
o 任何两个域名都不应显示相同，即使方向不同。这被证明是不合理的，因为域名（网络顺序）ABC.ABC在LTR上下文中具有显示顺序CBA.ABC，在RTL上下文中具有显示顺序ABC.CBA，而域名（网络）ABC.ABC在LTR上下文中具有显示顺序ABC.CBA，在RTL上下文中具有显示顺序CBA.ABC。
One possible requirement was thought to be problematic, but turned out to be satisfied by a string that obeys the proposed rules:
一个可能的要求被认为是有问题的，但结果是一个字符串符合提议的规则：
o The Character Grouping requirement should be satisfied when directional controls (LRE, RLE, RLO, LRO, PDF) are used in the same paragraph (outside of the labels). Because these controls affect presentation order in non-obvious ways, by affecting the "sor" and "eor" properties of the Unicode Bidi algorithm, the conditions above require extra testing in order to figure out whether or not they influence the display of the domain name. Testing found that for the strings allowed under the rule presented in this document, directional controls do not influence the display of the domain name.
o 当在同一段落（标签外）中使用方向控制（LRE、RLE、RLO、LRO、PDF）时，应满足字符分组要求。由于这些控件通过影响Unicode Bidi算法的“sor”和“eor”属性以不明显的方式影响表示顺序，因此上述条件需要额外测试，以确定它们是否影响域名的显示。测试发现，对于本文档中提供的规则所允许的字符串，方向控制不会影响域名的显示。
This is still not stated as a requirement, since it did not seem as important as the stated requirements, but it is useful to know that Bidi domain names where the labels satisfy the rule have this property.
这仍然不是一项要求，因为它似乎没有规定的要求那么重要，但知道标签满足规则的Bidi域名具有此属性是有用的。
In the following descriptions, first-level bullets are used to indicate rules or normative statements; second-level bullets are commentary.
在以下描述中，第一级项目符号用于表示规则或规范性陈述；二级项目符号是注释。
The Character Grouping requirement can be more formally stated as:
字符分组要求可以更正式地表述为：
o Let "Delimiterchars" be a set of characters with the Unicode Bidi properties CS, WS, ON. (These are commonly used to delimit labels -- both the FULL STOP and the space are included. They are not allowed in domain labels.)
o 让“Delimiterchars”是一组具有Unicode Bidi属性CS、WS、ON的字符。（它们通常用于分隔标签——包括句号和空格。域标签中不允许使用它们。）
* ET, though it commonly occurs next to domain names in practice, is problematic: the context R CS L EN ET (for instance A.a1%) makes the label L EN not satisfy the character grouping requirement.
* ET虽然在实践中通常出现在域名旁边，但存在问题：上下文R CS L EN ET（例如A.a1%）使标签L EN不满足字符分组要求。
* ES commonly occurs in labels as HYPHEN-MINUS, but could also be used as a delimiter (for instance, the plus sign). It is left out here.
* ES通常以连字符形式出现在标签中，但也可以用作分隔符（例如，加号）。就放在这里了。
o Let "unproblematic label" be a label that either satisfies the requirements or does not contain any character with the Bidi properties R, AL, or AN and does not begin with a character with the Bidi property EN. (Informally, "it does not start with a number".)
o “无问题标签”是指满足要求或不包含任何具有Bidi属性R、AL或AN的字符，且不以具有Bidi属性EN的字符开头的标签。（非正式地说，“它不是以数字开头的”。）
A label X satisfies the Character Grouping requirement when, for any Delimiter Character D1 and D2, and for any label S1 and S2 that is an unproblematic label or an empty string, the following holds true:
当对于任何分隔符字符D1和D2，以及对于任何无问题标签或空字符串的标签S1和S2，以下条件成立时，标签X满足字符分组要求：
If the string formed by concatenating S1, D1, X, D2, and S2 is reordered according to the Bidi algorithm, then all the characters of X in the reordered string are between D1 and D2, and no other characters are between D1 and D2, both if the overall paragraph direction is LTR and if the overall paragraph direction is RTL.
如果根据Bidi算法对通过连接S1、D1、X、D2和S2形成的字符串进行重新排序，则重新排序的字符串中X的所有字符都在D1和D2之间，并且在整个段落方向为LTR和整个段落方向为RTL的情况下，D1和D2之间没有其他字符。
Note that the definition is self-referential, since S1 and S2 are constrained to be "legal" by this definition. This makes testing changes to proposed rules a little complex, but does not create problems for testing whether or not a given proposed rule satisfies the criterion.
请注意，该定义是自参考的，因为S1和S2被该定义限制为“合法”。这使得对建议规则的测试更改有点复杂，但不会在测试给定的建议规则是否满足标准时产生问题。
The "zero-length" case represents the case where a domain name is next to something that isn't a domain name, separated by a delimiter character.
“零长度”大小写表示域名与非域名相邻，并用分隔符分隔的情况。
Note about the position of BN: The Unicode bidirectional algorithm specifies that a BN has an effect on the adjoining characters in network order, not in display order, and are therefore treated as if removed during Bidi processing ([Unicode-UAX9], Section 3.3.2, rule X9 and Section 5.3). Therefore, the question of "what position does a BN have after reordering" is not meaningful. It has been ignored while developing the rules here.
关于BN位置的注意事项：Unicode双向算法规定BN对相邻字符具有网络顺序的影响，而不是显示顺序的影响，因此在Bidi处理过程中被视为被删除（[Unicode-UAX9]，第3.3.2节，规则X9和第5.3节）。因此，“重组后英国国民的地位如何”的问题没有意义。在这里制定规则时，它被忽略了。
The Label Uniqueness requirement can be formally stated as:
标签唯一性要求可以正式表述为：
If two non-identical labels X and Y, embedded as for the test above, displayed in paragraphs with the same directionality, are reordered by the Bidi algorithm into the same sequence of code points, the labels X and Y cannot both be legal.
如果按照上述测试嵌入的两个不相同的标签X和Y以相同的方向性显示在段落中，通过Bidi算法将其重新排序为相同的代码点序列，则标签X和Y不能同时合法。
Dhivehi, the official language of the Maldives, is written with the Thaana script. This script displays some of the characteristics of the Arabic script, including its directional properties, and the indication of vowels by the diacritical marking of consonantal base characters. This marking is obligatory, and both two consecutive vowels and syllable-final consonants are indicated with unvoiced combining marks. Every Dhivehi word therefore ends with a combining mark.
Dhivehi是马尔代夫的官方语言，用塔阿纳语书写。该脚本显示了阿拉伯脚本的一些特征，包括其方向特性，以及通过辅音基本字符的变音标记来指示元音。这种标记是强制性的，两个连续的元音和音节末辅音都用清音组合标记表示。因此，每个Dhivehi单词都以一个组合标记结尾。
The word for "computer", which is romanized as "konpeetaru", is written with the following sequence of Unicode code points:
“计算机”一词被罗马化为“konpeetaru”，用以下Unicode代码点序列书写：
U+0786 THAANA LETTER KAAFU (AL)
U+0786塔纳字母KAAFU（AL）
U+07AE THAANA OBOFILI (NSM)
U+07AE Thana OBOFILI（NSM）
U+0782 THAANA LETTER NOONU (AL)
U+0782塔纳字母NOONU（AL）
U+07B0 THAANA SUKUN (NSM)
U+07B0 Thana SUKUN（NSM）
U+0795 THAANA LETTER PAVIYANI (AL)
U+0795塔纳字母帕维亚尼（AL）
U+07A9 THAANA LETTER EEBEEFILI (AL)
U+07A9塔纳字母EEBEEFILI（AL）
U+0793 THAANA LETTER TAVIYANI (AL)
U+0793塔阿纳字母塔维亚尼（AL）
U+07A6 THAANA ABAFILI (NSM)
U+07A6塔纳·阿巴菲利（NSM）
U+0783 THAANA LETTER RAA (AL)
U+0783塔纳字母RAA（AL）
U+07AA THAANA UBUFILI (NSM)
U+07AA Thana UBUFILI（NSM）
The directionality class of U+07AA in the Unicode database [Unicode52] is NSM (Nonspacing Mark), which is not R or AL; a conformant implementation of the IDNA2003 algorithm will say that "this is not in RandALCat" and refuse to encode the string.
Unicode数据库[Unicode52]中U+07AA的方向性类是NSM（非空格标记），它不是R或AL；IDNA2003算法的一致性实现将声明“这不在RandALCat中”，并拒绝对字符串进行编码。
Yiddish is one of several languages written with the Hebrew script (others include Hebrew and Ladino). This is basically a consonantal alphabet (also termed an "abjad"), but Yiddish is written using an extended form that is fully vocalic. The vowels are indicated in several ways, one of which is by repurposing letters that are consonants in Hebrew. Other letters are used both as vowels and consonants, with combining marks, called "points", used to differentiate between them. Finally, some base characters can indicate several different vowels, which are also disambiguated by combining marks. Pointed characters can appear in word-final position and may therefore also be needed at the end of labels. This is not an invariable attribute of a Yiddish string and there is thus greater latitude here than there is with Dhivehi.
意第绪语是用希伯来语书写的几种语言之一（其他包括希伯来语和拉迪诺语）。这基本上是一个辅音字母表（也被称为“abjad”），但意第绪语是使用扩展形式编写的，完全是有声的。元音有几种表示方式，其中一种是重新使用希伯来语中的辅音字母。其他字母同时用作元音和辅音，并带有组合标记，称为“点”，用于区分元音和辅音。最后，一些基本字符可以表示几个不同的元音，这些元音也可以通过组合标记来消除歧义。尖字符可以出现在word最终位置，因此也可能需要出现在标签的末尾。这不是意第绪语字符串的不变属性，因此这里的纬度比Dhivehi更大。
The organization now known as the "YIVO Institute for Jewish Research" developed orthographic rules for modern Standard Yiddish during the 1930s on the basis of work conducted in several venues since earlier in that century. These are given in, "The Standardized
该组织现在被称为“伊沃犹太研究所”，在20世纪30年代，根据该世纪初以来在多个地点开展的工作，为现代标准意第绪语制定了拼写规则。这些在“标准化”中给出
Yiddish Orthography: Rules of Yiddish Spelling" [SYO], and are taken as normatively descriptive of modern Standard Yiddish in any context where that notion is deemed relevant. They have been applied exclusively in all formal Yiddish dictionaries published since their establishment, and are similarly dominant in academic and bibliographic regards.
意第绪语正字法：意第绪语拼写规则“[SYO]，在任何与该概念相关的上下文中被视为对现代标准意第绪语的规范性描述。自成立以来，这些规则仅适用于所有正式的意第绪语词典，在学术和书目方面同样占主导地位。
It therefore appears appropriate for this repertoire also to be supported fully by IDNA. This presents no difficulty with characters in initial and medial positions, but pointed characters are regularly used in final position as well. All of the characters in the SYO repertoire appear in both marked and unmarked form with one exception: the HEBREW LETTER PE (U+05E4). The SYO only permits this with a HEBREW POINT DAGESH (U+05BC), providing the Yiddish equivalent to the Latin letter "p", or a HEBREW POINT RAFE (U+05BF), equivalent to the Latin letter "f". There is, however, a separate unpointed allograph, the HEBREW LETTER FINAL PE (U+05E3), for the latter character when it appears in final position. The constraint on the use of the SYO repertoire resulting from the proscription of combining marks at the end of RTL strings thus reduces to nothing more, or less, than the equivalent of saying that a string of Latin characters cannot end with the letter "p". It must also be noted that the HEBREW LETTER PE with the HEBREW POINT DAGESH is characteristic of almost all traditional Yiddish orthographies that predate (or remain in use in parallel to) the SYO, being the first pointed character to appear in any of them.
因此，IDNA也完全支持该剧目似乎是合适的。这对处于起始和中间位置的字符没有困难，但在最后位置也经常使用尖头字符。SYO剧目中的所有角色都以有标记和无标记的形式出现，只有一个例外：希伯来语字母PE（U+05E4）。SYO仅允许使用希伯来语点DAGESH（U+05BC），提供等同于拉丁字母“p”的意第绪语，或等同于拉丁字母“f”的希伯来语点RAFE（U+05BF）。然而，当后一个字符出现在最后一个位置时，有一个单独的无印异体字，希伯来文字母FINAL PE（U+05E3）。因此，由于禁止在RTL字符串末尾使用组合标记，因此对SYO指令集的使用产生了限制，这等于说拉丁字符字符串不能以字母“p”结尾。还必须注意的是，带希伯来点DAGESH的希伯来字母PE是几乎所有传统意第绪语正字法的特征，这些正字法早于SYO（或与SYO平行使用），是其中出现的第一个尖字符。
A more general instantiation of the basic problem can be seen in the representation of the YIVO acronym. This acronym is written with the Hebrew letters YOD YOD HIRIQ VAV VAV ALEF QAMATS, where HIRIQ and QAMATS are combining points. The Unicode code points are:
在YIVO首字母缩略词的表示中可以看到基本问题的更一般的实例。这个首字母缩略词是用希伯来字母YOD YOD HIRIQ VAV VAV ALEF QAMATS写成的，其中HIRIQ和QAMATS是结合点。Unicode代码点是：
U+05D9 HEBREW LETTER YOD (R)
U+05D9希伯来文字母YOD（R）
U+05B4 HEBREW POINT HIRIQ (NSM)
U+05B4希伯莱角希里克（NSM）
U+05D5 HEBREW LETTER VAV (R)
U+05D5希伯来文字母VAV（R）
U+05D0 HEBREW LETTER ALEF (R)
U+05D0希伯来文字母ALEF（R）
U+05B8 HEBREW POINT QAMATS (NSM)
U+05B8希伯莱角卡马茨（NSM）
The directionality class of U+05B8 HEBREW POINT QAMATS in the Unicode database is NSM, which again causes the IDNA2003 algorithm to reject the string.
Unicode数据库中U+05B8希伯来点QAMATS的方向性类是NSM，这再次导致IDNA2003算法拒绝该字符串。
It may also be noted that all of the combined characters mentioned above exist in precomposed form at separate positions in the Unicode chart. However, by invoking Stringprep, the IDNA2003 algorithm also rejects those code points, for reasons not discussed here.
还可以注意到，上述所有组合字符都以预组合形式存在于Unicode图表中的不同位置。然而，通过调用Stringprep，IDNA2003算法也会拒绝这些代码点，原因在这里没有讨论。
By requiring that the first or last character of a string be a member of category R or AL, the Stringprep specification [RFC3454] prohibited a string containing right-to-left characters from ending with a number.
通过要求字符串的第一个或最后一个字符是类别R或AL的成员，Stringprep规范[RFC3454]禁止包含从右到左字符的字符串以数字结尾。
Consider the strings ALEF 5 (HEBREW LETTER ALEF + DIGIT FIVE) and 5 ALEF. Displayed in an LTR context, the first one will be displayed from left to right as 5 ALEF (with the 5 being considered right to left because of the leading ALEF), while 5 ALEF will be displayed in exactly the same order (5 taking the direction from context). Clearly, only one of those should be permitted as a registered label, but barring them both seems unnecessary.
考虑字符串AlEF 5（希伯来文字母ALEF+数字五）和5 ALEF。在LTR上下文中显示，第一个将从左到右显示为5 ALEF（由于前导的ALEF，5被视为从右到左），而5 ALEF将以完全相同的顺序显示（5按上下文的方向显示）。显然，其中只有一个应该被允许作为注册标签，但禁止两者似乎是不必要的。
There are situations in which labels that satisfy the rule above will be displayed in a surprising fashion. The most important of these is the case where a label ending in a character with Bidi property AL, AN, or R occurs before a label beginning with a character of Bidi property EN. In that case, the number will appear to move into the label containing the right-to-left character, violating the Character Grouping requirement.
在某些情况下，满足上述规则的标签将以令人惊讶的方式显示。其中最重要的一种情况是，以Bidi属性AL、AN或R结尾的标签出现在以Bidi属性EN开头的标签之前。在这种情况下，数字似乎会移动到包含从右向左字符的标签中，这违反了字符分组要求。
If the label that occurs after the right-to-left label itself satisfies the Bidi criterion, the requirements will be satisfied in all cases (this is the reason why the criterion talks about strings containing L in some cases). However, the IDNABIS WG concluded that this could not be required for several reasons:
如果出现在从右向左标签之后的标签本身满足Bidi标准，则在所有情况下都将满足要求（这就是为什么该标准在某些情况下讨论包含L的字符串的原因）。然而，IDNABIS工作组得出结论认为，由于以下几个原因，不需要这样做：
o There is a large current deployment of ASCII domain names starting with digits. These cannot possibly be invalidated.
o 目前有大量以数字开头的ASCII域名部署。这些不可能是无效的。
o Domain names are often constructed piecemeal, for instance, by combining a string with the content of a search list. This may occur after IDNA processing, and thus in part of the code that is not IDNA-aware, making detection of the undesirable combination impossible.
o 域名通常是零碎构建的，例如，通过将字符串与搜索列表的内容相结合。这可能发生在IDNA处理之后，并且因此在代码中不知道IDNA的部分中，使得不希望的组合的检测不可能。
o Even if a label is registered under a "safe" label, there may be a DNAME [RFC2672] with an "unsafe" label that points to the "safe" label, thus creating seemingly valid names that would not satisfy the criterion.
o 即使标签注册在“安全”标签下，也可能有一个带有指向“安全”标签的“不安全”标签的DNAME[RFC2672]，从而创建了看起来不符合标准的有效名称。
o Wildcards create the odd situation where a label is "valid" (can be looked up successfully) without the zone owner knowing that this label exists. So an owner of a zone whose name starts with a digit and contains a wildcard has no way of controlling whether or not names with RTL labels in them are looked up in his zone.
o 通配符会造成一种奇怪的情况，即标签“有效”（可以成功查找），而区域所有者不知道该标签存在。因此，名称以数字开头并包含通配符的区域的所有者无法控制是否在其区域中查找带有RTL标签的名称。
Rather than trying to suggest rules that disallow all such undesirable situations, this document merely warns about the possibility, and leaves it to application developers to take whatever measures they deem appropriate to avoid problematic situations.
本文档没有试图提出禁止所有此类不良情况的规则，只是警告了这种可能性，并让应用程序开发人员采取他们认为适当的措施来避免出现问题的情况。
This document concerns itself only with the rules that are needed when dealing with domain names with characters that have differing Bidi properties, and considers characters only in terms of their Bidi properties. All other issues with scripts that are written from right to left must be considered in other contexts.
本文档仅涉及在处理具有不同Bidi属性的字符的域名时所需的规则，并仅根据其Bidi属性考虑字符。必须在其他上下文中考虑从右向左编写的脚本的所有其他问题。
One such issue is the need to keep numbers separate. Several scripts are used with multiple sets of numbers -- most commonly they use Latin numbers and a script-specific set of numbers, but in the case of Arabic, there are two sets of "Arabic-Indic" digits involved.
其中一个问题是需要将数字分开。一些脚本与多组数字一起使用——最常见的是使用拉丁数字和一组特定于脚本的数字，但在阿拉伯语中，涉及两组“阿拉伯-印度”数字。
The algorithm in this document disallows occurrences of AN-class characters ("Arabic-Indic digits", U+0660 to U+0669) together with EN-class characters (which includes "European" digits, U+0030 to U+0039 and "extended Arabic-Indic digits", U+06F0 to U+06F9), but does not help in preventing the mixing of, for instance, Bengali digits (U+09E6 to U+09EF) and Gujarati digits (U+0AE6 to U+0AEF), both of which have Bidi class L. A registry or script community that wishes to create rules restricting the mixing of digits in a label will be able to specify these restrictions at the registry level. Some rules are also specified at the protocol level.
本文件中的算法不允许出现类别字符（“阿拉伯-印度数字”，U+0660至U+0669）和EN类别字符（包括“欧洲”数字，U+0030至U+0039和“扩展阿拉伯-印度数字”，U+06F0至U+06F9），但无助于防止混合，例如孟加拉数字（U+09E6到U+09EF）和古吉拉特邦数字（U+0AE6到U+0AEF），两者都具有Bidi类L。希望创建限制标签中数字混合的规则的注册表或脚本社区将能够在注册表级别指定这些限制。某些规则也在协议级别指定。
Another set of issues concerns the proper display of IDNs with a mixture of LTR and RTL labels, or only RTL labels.
另一组问题涉及使用LTR和RTL标签或仅使用RTL标签正确显示IDN。
It is unrealistic to expect that applications will display domain names using embedded formatting codes between their labels (for one thing, no reliable algorithms for identifying domain names in running text exist); thus, the display order will be determined by the Bidi algorithm. Thus, a sequence (in network order) of R1.R2.ltr will be
期望应用程序在标签之间使用嵌入式格式代码显示域名是不现实的（一方面，没有可靠的算法在运行文本中识别域名）；因此，显示顺序将由Bidi算法确定。因此，R1.R2.ltr的序列（按网络顺序）将被删除
displayed in the order 2R.1R.ltr in an LTR context, which might surprise someone expecting to see labels displayed in hierarchical order. People used to working with text that mixes LTR and RTL strings might not be so surprised by this. Again, this memo does not attempt to suggest a solution to this problem.
在ltr上下文中以2R.1R.ltr的顺序显示，这可能会让希望看到标签以层次顺序显示的人感到惊讶。习惯于处理混合LTR和RTL字符串的文本的人可能不会对此感到惊讶。同样，这份备忘录并没有试图提出解决这个问题的办法。
As with any change to an existing standard, it is important to consider what happens with existing implementations when the change is introduced. Some troublesome cases include:
与现有标准的任何更改一样，重要的是考虑引入变更时现有实现中发生的情况。一些棘手的情况包括：
o An old program used to input the newly allowed label. If the old program checks the input against RFC 3454, some labels will not be allowed, and domain names containing those labels will remain inaccessible.
o 用于输入新允许的标签的旧程序。如果旧程序根据RFC 3454检查输入，则不允许使用某些标签，并且包含这些标签的域名将仍然无法访问。
o An old program is asked to display the newly allowed label, and checks it against RFC 3454 before displaying. The program will perform some kind of fallback, most likely displaying the label in A-label form.
o 要求旧程序显示新允许的标签，并在显示前对照RFC 3454进行检查。程序将执行某种回退，很可能以A-label形式显示标签。
o An old program tries to display the newly allowed label. If the old program has code for displaying the last character of a label that is different from the code used to display the characters in the middle of the label, the display may be inconsistent and cause confusion.
o 旧程序尝试显示新允许的标签。如果旧程序有用于显示标签的最后一个字符的代码，该标签与用于在标签中间显示字符的代码不同，则显示可能不一致并引起混乱。
One particular example of the last case is if a program chooses to examine the last character (in network order) of a string in order to determine its directionality, rather than its first. If it finds an NSM character and tries to display the string as if it was a left-to-right string, the resulting display may be interesting, but not useful.
最后一种情况的一个特殊示例是，如果程序选择检查字符串的最后一个字符（按网络顺序），以确定其方向性，而不是第一个字符。如果它找到一个NSM字符，并尝试将该字符串显示为从左到右的字符串，则结果显示可能会很有趣，但没有用处。
The editors believe that these cases will have a less harmful impact in practice than continuing to deny the use of words from the languages for which these strings are necessary as IDN labels.
编辑们相信，与继续拒绝使用这些字符串作为IDN标签所必需的语言中的单词相比，这些案例在实践中产生的有害影响更小。
This specification does not forbid using leading European digits in ASCII-only labels, since this would conflict with a large installed base of such labels, and would increase the scope of the specification from RTL labels to all labels. The harm resulting from this limitation of scope is described in Section 5. Registries and private zone managers can check for this particular condition before they allow registration of any RTL label. Generally, it is best to
本规范不禁止在仅ASCII标签中使用前导欧洲数字，因为这将与此类标签的大量安装基础相冲突，并将规范的范围从RTL标签扩大到所有标签。第5节描述了这种范围限制造成的危害。注册中心和专用区域管理器可以在允许注册任何RTL标签之前检查此特定条件。一般来说，最好
disallow registration of any right-to-left strings in a zone where the label at the level above begins with a digit.
不允许在上面级别的标签以数字开头的区域中注册任何从右到左的字符串。
This text is intentionally specified strictly in terms of the Unicode Bidi properties. The determination that the condition is sufficient to fulfill the criteria depends on the Unicode Bidi algorithm; it is unlikely that drastic changes will be made to this algorithm.
本文本严格按照Unicode Bidi属性指定。确定条件是否足以满足标准取决于Unicode Bidi算法；不太可能对该算法进行重大更改。
However, the determination of validity for any string depends on the Unicode Bidi property values, which are not declared immutable by the Unicode Consortium. Furthermore, the behavior of the algorithm for any given character is likely to be linguistically and culturally sensitive, so while it should occur rarely, it is possible that later versions of the Unicode Standard may change the Bidi properties assigned to certain Unicode characters.
但是，任何字符串的有效性的确定取决于Unicode Bidi属性值，Unicode联盟并没有声明这些属性值是不可变的。此外，任何给定字符的算法行为在语言和文化上都可能是敏感的，因此，虽然这种情况很少发生，但Unicode标准的更高版本可能会更改指定给某些Unicode字符的Bidi属性。
This memo does not propose a solution for this problem.
本备忘录并未针对该问题提出解决方案。
The display behavior of mixed-direction text can be extremely surprising to users who are not used to it; for instance, cut and paste of a piece of text can cause the text to display differently at the destination, if the destination is in another directionality context, and adding a character in one place of a text can cause characters some distance from the point of insertion to change their display position. This is, however, not a phenomenon unique to the display of domain names.
混合方向文本的显示行为会让不习惯它的用户非常惊讶；例如，如果目标位于另一个方向性上下文中，则剪切和粘贴一段文本可能会导致文本在目标处以不同方式显示，并且在文本的一个位置添加字符可能会导致字符与插入点保持一定距离以改变其显示位置。然而，这并不是域名显示所特有的现象。
The new IDNA protocol, and particularly these new Bidi rules, will allow some strings to be used in IDNA contexts that are not allowed today. It is possible that differences in the interpretation of labels between implementations of IDNA2003 and IDNA2008 could pose a security risk, but it is difficult to envision any specific instantiation of this.
新的IDNA协议，特别是这些新的Bidi规则，将允许在IDNA上下文中使用一些现在不允许的字符串。IDNA2003和IDNA2008的实现之间标签解释的差异可能会带来安全风险，但很难设想任何具体的实例。
Any rational attempt to compute, for instance, a hash over an identifier processed by IDNA would use network order for its computation, and thus be unaffected by the new rules proposed here.
例如，任何理性的尝试都会使用网络顺序来计算IDNA处理的标识符上的哈希，因此不会受到这里提出的新规则的影响。
While it is not believed to pose a problem, if display routines had been written with specific knowledge of the RFC 3454 IDNA prohibitions, it is possible that the potential problems noted under "Backwards Compatibility Considerations" could cause new kinds of confusion.
虽然不认为会造成问题，但如果在编写显示例程时特别了解RFC 3454 IDNA禁令，则“向后兼容性注意事项”中指出的潜在问题可能会引起新的混淆。
While the listed editors held the pen, this document represents the joint work and conclusions of an ad hoc design team. In addition to the editors, this consisted of, in alphabetic order, Tina Dam, Patrik Faltstrom, and John Klensin. Many further specific contributions and helpful comments were received from the people listed below, and others who have contributed to the development and use of the IDNA protocols.
虽然列出的编辑们手握笔，但本文件代表了一个特设设计团队的共同工作和结论。除了编辑之外，按字母顺序排列的还有Tina Dam、Patrik Faltstrom和John Klesin。下面列出的人以及其他为IDNA协议的制定和使用做出贡献的人提供了许多进一步的具体贡献和有用的意见。
The particular formulation of the Bidi rule in Section 2 was suggested by Matitiahu Allouche.
第2节中比迪规则的具体表述是由马蒂蒂亚胡·阿洛切提出的。
The team wishes, in particular, to thank Roozbeh Pournader for calling its attention to the issue with the Thaana script, Paul Hoffman for pointing out the need to be explicit about backwards compatibility considerations, Ken Whistler for suggesting the basis of the formalized "Character Grouping" requirement, Mark Davis for commentary, Erik van der Poel for careful review, comments, and verification of the rulesets, Marcos Sanz, Andrew Sullivan, and Pete Resnick for reviews, and Vint Cerf for chairing the working group and contributing massively to getting the documents finished.
团队希望特别感谢Roozbeh Pournader提请其注意Thana脚本的问题，Paul Hoffman指出了明确向后兼容性考虑的必要性，Ken Whistler提出了形式化“字符分组”要求的基础，Mark Davis提供了评论，Erik van der Poel负责仔细审查、评论和验证规则集，Marcos Sanz、Andrew Sullivan和Pete Resnick负责审查，Vint Cerf负责主持工作组并为完成文件做出了巨大贡献。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[Unicode-UAX9] The Unicode Consortium, "Unicode Standard Annex #9: Unicode Bidirectional Algorithm", September 2009, <http://www.unicode.org/reports/tr9/>.
[Unicode-UAX9]Unicode联盟，“Unicode标准附录#9:Unicode双向算法”，2009年9月<http://www.unicode.org/reports/tr9/>.
[Unicode52] The Unicode Consortium. The Unicode Standard, Version 5.2.0, defined by: "The Unicode Standard, Version 5.2.0", (Mountain View, CA: The Unicode Consortium, 2009. ISBN 978-1-936213-00-9). <http://www.unicode.org/versions/Unicode5.2.0/>.
[Unicode 52]Unicode联盟。Unicode标准，版本5.2.0，定义为：“Unicode标准，版本5.2.0”（加利福尼亚州山景城：Unicode联盟，2009年。ISBN 978-1-936213-00-9）<http://www.unicode.org/versions/Unicode5.2.0/>.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[RFC2672]克劳福德，M.，“非终端DNS名称重定向”，RFC 26721999年8月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化弦的准备（“stringprep”）”，RFC 3454，2002年12月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 58912010年8月。
[SYO] "The Standardized Yiddish Orthography: Rules of Yiddish Spelling, 6th ed., New York, ISBN 0-914512-25-0", 1999.
[SYO]“标准化的意第绪语正字法：意第绪语拼写规则，第6版，纽约，ISBN 0-914512-25-0”，1999年。
Authors' Addresses
作者地址
Harald Tveit Alvestrand (editor) Google Beddingen 10 Trondheim, 7014 Norway
Harald Tveit Alvestrand（编辑）谷歌贝丁根10特隆赫姆，7014挪威
EMail: harald@alvestrand.no
EMail: harald@alvestrand.no
Cary Karp Swedish Museum of Natural History Frescativ. 40 Stockholm, 10405 Sweden
卡里·卡普瑞典自然历史博物馆壁画。40斯德哥尔摩，10405瑞典
Phone: +46 8 5195 4055
Fax:
EMail: ck@nic.museum
Phone: +46 8 5195 4055
Fax:
EMail: ck@nic.museum