Internet Architecture Board (IAB) H. Flanagan, Ed.
Request for Comments: 7997 RFC Editor
Updates: 7322 December 2016
Category: Informational
ISSN: 2070-1721
Internet Architecture Board (IAB) H. Flanagan, Ed.
Request for Comments: 7997 RFC Editor
Updates: 7322 December 2016
Category: Informational
ISSN: 2070-1721
The Use of Non-ASCII Characters in RFCs
RFC中非ASCII字符的使用
Abstract
摘要
In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes the RFC Editor requirements and gives guidance regarding the use of non-ASCII characters in RFCs.
为了支持协议的国际化和更加多样化的互联网社区，RFC系列必须发展到允许在RFC中使用非ASCII字符。虽然英语仍然是本系列的必选语言，但未来RFC的编码将采用UTF-8，允许使用比英语更广泛的字符范围。本文档描述了RFC编辑器的要求，并提供了有关在RFC中使用非ASCII字符的指导。
This document updates RFC 7322. Please view this document in PDF form to see the full text.
本文件更新了RFC 7322。请以PDF格式查看此文档以查看全文。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第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/rfc7997.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7997.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Basic Requirements . . . . . . . . . . . . . . . . . . . . . 3
3. Rules for the Use of Non-ASCII Characters . . . . . . . . . . 4
3.1. General Usage throughout a Document . . . . . . . . . . . 4
3.2. Person Names . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Company Names . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Body of the Document . . . . . . . . . . . . . . . . . . 7
3.5. Tables . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Code Components . . . . . . . . . . . . . . . . . . . . . 11
3.7. Bibliographic Text . . . . . . . . . . . . . . . . . . . 11
3.8. Keywords and Citation Tags . . . . . . . . . . . . . . . 11
3.9. Address Information . . . . . . . . . . . . . . . . . . . 12
4. Normalization Forms . . . . . . . . . . . . . . . . . . . . . 12
5. XML Markup . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Internationalization Considerations . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Informative References . . . . . . . . . . . . . . . . . . . 13
IAB Members at the Time of Approval . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Basic Requirements . . . . . . . . . . . . . . . . . . . . . 3
3. Rules for the Use of Non-ASCII Characters . . . . . . . . . . 4
3.1. General Usage throughout a Document . . . . . . . . . . . 4
3.2. Person Names . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Company Names . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Body of the Document . . . . . . . . . . . . . . . . . . 7
3.5. Tables . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Code Components . . . . . . . . . . . . . . . . . . . . . 11
3.7. Bibliographic Text . . . . . . . . . . . . . . . . . . . 11
3.8. Keywords and Citation Tags . . . . . . . . . . . . . . . 11
3.9. Address Information . . . . . . . . . . . . . . . . . . . 12
4. Normalization Forms . . . . . . . . . . . . . . . . . . . . . 12
5. XML Markup . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Internationalization Considerations . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Informative References . . . . . . . . . . . . . . . . . . . 13
IAB Members at the Time of Approval . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
Please review the PDF version of this draft.
请查看此草稿的PDF版本。
For much of the history of the RFC Series, the character encoding used for RFCs has been ASCII [RFC20]. This was a sensible choice at the time: the language of the Series has always been English, a language that primarily uses ASCII-encoded characters (ignoring for a moment words borrowed from more richly decorated alphabets); and, ASCII is the "lowest common denominator" for character encoding, making cross-platform viewing trivial.
在RFC系列的大部分历史中，RFC使用的字符编码都是ASCII[RFC20]。这在当时是一个明智的选择：该系列的语言一直是英语，一种主要使用ASCII编码字符的语言（暂时忽略从装饰更丰富的字母表中借用的单词）；而且，ASCII是字符编码的“最低公分母”，使得跨平台查看变得微不足道。
There are limits to ASCII, however, that hinder its continued use as the exclusive character encoding for the Series. The increasing need for easily readable, internationalized content suggests it is time to allow non-ASCII characters in RFCs where necessary. To support this move away from ASCII, RFCs will switch to supporting UTF-8 as the default character encoding and will allow support for a broad range of Unicode characters [UnicodeCurrent]. Note that the RFC Editor may reject any code point that does not render adequately across all formats or in enough rendering engines using the v3 tooling.
但是，ASCII有一些限制，这妨碍了它继续用作序列的专用字符编码。对易读、国际化内容的日益增长的需求表明，在必要的情况下，是时候允许RFC中使用非ASCII字符了。为了支持这种从ASCII的转移，RFCs将切换到支持UTF-8作为默认字符编码，并允许支持广泛的Unicode字符[Unicode Decurrent]。请注意，RFC编辑器可能会拒绝使用v3工具在所有格式或足够的渲染引擎中进行充分渲染的任何代码点。
Given the continuing goal of maximum readability across platforms, the use of non-ASCII characters should be limited to only where necessary within the text. This document describes the rules under which non-ASCII characters may be used in an RFC. These rules will be applied as the necessary changes are made to submission checking and editorial tools.
考虑到跨平台最大可读性的持续目标，非ASCII字符的使用应仅限于文本中必要的地方。本文档描述了RFC中可能使用非ASCII字符的规则。这些规则将在提交检查和编辑工具进行必要更改时适用。
This document updates the RFC Style Guide [RFC7322].
本文档更新了RFC样式指南[RFC7322]。
The details included in this document are expected to change based on experience gained in implementing the new publication toolsets. Revised documents will be published capturing those changes as the toolsets are completed. Other implementers must not expect those changes to remain backwards compatible with the details included in this document.
本文档中包含的详细信息预计将根据在实施新发布工具集过程中获得的经验进行更改。修订后的文档将在工具集完成后发布，以捕获这些更改。其他实施者不得期望这些更改与本文档中包含的细节保持向后兼容。
Two fundamental requirements inform the guidance and examples provided in this document. They are:
本文件中提供的指南和示例包含两个基本要求。他们是：
o Searches against RFC indexes and database tables need to return expected results and support appropriate Unicode string matching behaviors;
o 对RFC索引和数据库表的搜索需要返回预期结果并支持适当的Unicode字符串匹配行为；
o RFCs must be able to be displayed correctly across a wide range of readers and browsers. People whose systems do not have the fonts needed to display a particular RFC need to be able to read the various publication formats and the XML correctly in order to understand and implement the information described in the document.
o RFC必须能够在广泛的阅读器和浏览器中正确显示。系统没有显示特定RFC所需字体的用户需要能够正确读取各种发布格式和XML，以便理解和实现文档中描述的信息。
This section describes the guidelines for the use of non-ASCII characters in an RFC. If the RFC Editor identifies areas where the use of non-ASCII characters negatively impacts the readability of the text, they will request alternate text.
本节介绍在RFC中使用非ASCII字符的指导原则。如果RFC编辑器确定使用非ASCII字符会对文本可读性产生负面影响的区域，它们将请求替换文本。
The RFC Editor may, in cases of entire words represented in non-ASCII characters, ask for a set of reviewers to verify the meaning, spelling, characters, and grammar of the text.
对于以非ASCII字符表示的整个单词，RFC编辑器可能会要求一组审阅者验证文本的含义、拼写、字符和语法。
Where the use of non-ASCII characters is purely part of an example and not otherwise required for correct protocol operation, escaping the non-ASCII character is not required. Note, however, that as the language of the RFC Series is English, the use of non-ASCII characters is based on the spelling of words commonly used in the English language following the guidance in the Merriam-Webster dictionary [MerrWeb].
如果非ASCII字符的使用只是示例的一部分，并且正确的协议操作不需要非ASCII字符，则不需要转义非ASCII字符。但是，请注意，由于RFC系列的语言为英语，因此非ASCII字符的使用基于英语中常用单词的拼写，并遵循Merriam-Webster字典[MerrWeb]中的指导。
The RFC Editor will use the primary spelling listed in that dictionary by default.
默认情况下，RFC编辑器将使用该词典中列出的主要拼写。
Example of non-ASCII characters that do not require escaping (example from Section 3.1.1.12 of RFC 4475 [RFC4475], with a hex dump replaced by the actual character glyphs):
不需要转义的非ASCII字符示例（RFC 4475[RFC4475]第3.1.1.12节中的示例，十六进制转储替换为实际字符图示符）：
This particular response contains unreserved and non-ASCII UTF-8 characters. This response is well formed. A parser must accept this message.
此特定响应包含无保留和非ASCII UTF-8字符。这一反应是有条理的。解析器必须接受此消息。
Message Details : unreason
消息详细信息：未读
SIP/2.0 200 = 2**3 * 5**2 (See PDF for non-ASCII character string)
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
Call-ID: unreason.1234ksdfak3j2erwedfsASdf
CSeq: 35 INVITE
From: sip:user@example.com;tag=11141343
To: sip:user@example.edu;tag=2229 Content-Length: 154
Content-Type: application/sdp
SIP/2.0 200 = 2**3 * 5**2 (See PDF for non-ASCII character string)
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
Call-ID: unreason.1234ksdfak3j2erwedfsASdf
CSeq: 35 INVITE
From: sip:user@example.com;tag=11141343
To: sip:user@example.edu;tag=2229 Content-Length: 154
Content-Type: application/sdp
Person names may appear in several places within an RFC (e.g., the header, Acknowledgements, and References). When a script outside the Unicode Latin blocks [UNICODE-CHART] is used for an individual name, an author-provided, ASCII-only identifier will appear immediately after the non-Latin characters, surrounded by parentheses. This will improve general readability of the text.
人名可能出现在RFC中的多个位置（例如标题、确认和引用）。当Unicode拉丁块[Unicode-CHART]之外的脚本用于单个名称时，作者提供的仅限ASCII的标识符将立即出现在非拉丁字符后面，并用括号括起来。这将提高文本的一般可读性。
Example header:
示例标题：
OLD:
旧的：
Internet Engineering Task Force (IETF) J. Tong Request for Comments: 7380 C. Bi, Ed. Category: Standards Track China Telecom ISSN: 2070-1721 R. Even Q. Wu, Ed. R. Huang Huawei November 2014
互联网工程特别工作组（IETF）汤杰征求意见：7380 C.Bi，Ed.类别：标准跟踪中国电信ISSN:2070-1721 R.Een Q.Wu，Ed.R.Huawei 2014年11月
PROPOSED/NEW:
拟议/新：
Internet Engineering Task Force (IETF) J. Tong Request for Comments: 7380 C. Bi, Ed. Category: Standards Track China Telecom ISSN: 2070-1721 (See PDF for non-ASCII character string) (R. Even) (See PDF for non-ASCII character string) (Q. Wu), Ed. R. Huang Huawei November 2014
互联网工程特别工作组（IETF）汤杰征求意见：7380 C.Bi，Ed.类别：标准跟踪中国电信ISSN:2070-1721（非ASCII字符串见PDF）（R.偶数）（非ASCII字符串见PDF）（Q.Wu），Ed.R.Huawei 2014年11月
Example Acknowledgements section:
确认部分示例：
OLD:
旧的：
The following people contributed significant text to early versions of this draft: Patrik Faltstrom, William Chan, and Fred Baker.
以下人士为该草案的早期版本提供了重要文本：帕特里克·法茨特罗姆（Patrik Faltstrom）、威廉·陈（William Chan）和弗雷德·贝克（Fred Baker）。
PROPOSED/NEW:
拟议/新：
The following people contributed significant text to early versions of this draft: Patrik (See PDF for non-ASCII character string) (Faltstrom), (See PDF for non-ASCII character string) (William Chan), and Fred Baker.
以下人员为该草案的早期版本提供了重要文本：Patrik（非ASCII字符串见PDF）（Faltstrom）（非ASCII字符串见PDF）（William Chan）和Fred Baker。
Example reference entry:
参考条目示例：
OLD:
旧的：
[RFC6630] Cao, Z., Deng, H., Wu, Q., and G. Zorn, Ed., "EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)", RFC 6630, June 2012.
[RFC6630]Cao，Z.，Deng，H.，Wu，Q.，和G.Zorn，Ed.，“认证预期键控（ERP/AAK）的EAP再认证协议扩展”，RFC 6630，2012年6月。
NEW
刚出现的
[RFC6630] Cao, Z., Deng, H., (See PDF for non-ASCII character string) (Wu, Q.), and G. Zorn, Ed., "EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)", RFC 6630, June 2012.
[RFC6630]Cao，Z.，Deng，H.（非ASCII字符串见PDF）（Wu，Q.）和G.Zorn，Ed.，“认证预期键控（ERP/AAK）的EAP再认证协议扩展”，RFC 6630，2012年6月。
Company names may appear in several places within an RFC. In all cases, valid Unicode is required. For names that include characters outside of the Unicode Latin and Latin Extended scripts, an author-provided, ASCII-only identifier is required to assist in searching and indexing of the document.
公司名称可能出现在RFC中的多个位置。在所有情况下，都需要有效的Unicode。对于包含Unicode拉丁语和拉丁语扩展脚本之外的字符的名称，需要作者提供的仅ASCII标识符来帮助搜索和索引文档。
When the mention of non-ASCII characters is required for correct protocol operation and understanding, the characters' Unicode code points must be used in the text. The addition of each character name is encouraged.
如果为了正确的协议操作和理解需要提及非ASCII字符，则必须在文本中使用字符的Unicode代码点。鼓励添加每个字符的名称。
o Non-ASCII characters will require identifying the Unicode code point.
o 非ASCII字符将需要标识Unicode代码点。
o Use of the actual UTF-8 character (e.g., (See PDF for non-ASCII character string)) is encouraged so that a reader can more easily see what the character is, if their device can render the text.
o 鼓励使用实际的UTF-8字符（例如（非ASCII字符串见PDF）），以便读者可以更容易地看到字符是什么，如果他们的设备可以呈现文本。
o The use of the Unicode character names like "INCREMENT" in addition to the use of Unicode code points is also encouraged. When used, Unicode character names should be in all capital letters.
o 除了使用Unicode代码点外，还鼓励使用Unicode字符名，如“INCREMENT”。使用时，Unicode字符名称应使用所有大写字母。
Examples:
示例：
OLD [RFC7564]:
旧的[RFC7564]：
However, the problem is made more serious by introducing the full range of Unicode code points into protocol strings. For example, the characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 from the Cherokee block look similar to the ASCII characters "STPETER" as they might appear when presented using a "creative" font family.
然而，通过在协议字符串中引入全范围的Unicode代码点，问题变得更加严重。例如，切诺基块中的字符U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2看起来类似于ASCII字符“STPETER”，因为它们在使用“创造性”字体系列呈现时可能会出现。
NEW/ALLOWED:
新的/允许的：
However, the problem is made more serious by introducing the full range of Unicode code points into protocol strings. For example, the characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 ((See PDF for non-ASCII character string)) from the Cherokee block look similar to the ASCII characters "STPETER" as they might appear when presented using a "creative" font family.
然而，通过在协议字符串中引入全范围的Unicode代码点，问题变得更加严重。例如，切诺基块中的字符U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2（（非ASCII字符串请参见PDF））看起来类似于ASCII字符“STPETER”，因为它们在使用“创造性”字体系列呈现时可能会出现。
ALSO ACCEPTABLE:
也可接受：
However, the problem is made more serious by introducing the full range of Unicode code points into protocol strings. For example, the characters "(See PDF for non-ASCII character string)" (U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2) from the Cherokee block look similar to the ASCII characters "STPETER" as they might appear when presented using a "creative" font family.
然而，通过在协议字符串中引入全范围的Unicode代码点，问题变得更加严重。例如，Cherokee块中的字符“（非ASCII字符串请参见PDF）”（U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2）看起来类似于ASCII字符“STPETER”，因为它们在使用“创造性”字体系列呈现时可能会出现。
Example of proper identification of Unicode characters in an RFC:
RFC中正确标识Unicode字符的示例：
Acceptable:
可接受的：
o Temperature changes in the Temperature Control Protocol are indicated by the U+2206 character.
o 温度控制协议中的温度变化由U+2206字符表示。
Preferred:
首选：
1. Temperature changes in the Temperature Control Protocol are indicated by the U+2206 character ("(See PDF for non-ASCII character string)").
1. 温度控制协议中的温度变化由U+2206字符（“非ASCII字符串请参见PDF”）表示。
2. Temperature changes in the Temperature Control Protocol are indicated by the U+2206 character (INCREMENT).
2. 温度控制协议中的温度变化由U+2206字符（增量）表示。
3. Temperature changes in the Temperature Control Protocol are indicated by the U+2206 character ("(See PDF for non-ASCII character string)", INCREMENT).
3. 温度控制协议中的温度变化由U+2206字符（“非ASCII字符串请参见PDF）”表示，增量）。
4. Temperature changes in the Temperature Control Protocol are indicated by the U+2206 character (INCREMENT, "(See PDF for non-ASCII character string)").
4. 温度控制协议中的温度变化由U+2206字符表示（增量“（非ASCII字符串请参见PDF）”）。
5. Temperature changes in the Temperature Control Protocol are indicated by the "Delta" character "(See PDF for non-ASCII character string)" (U+2206).
5. 温度控制协议中的温度变化用“增量”字符表示（非ASCII字符串见PDF）（U+2206）。
6. Temperature changes in the Temperature Control Protocol are indicated by the character "(See PDF for non-ASCII character string)" (INCREMENT, U+2206).
6. 温度控制协议中的温度变化由字符（非ASCII字符串见PDF）表示（增量，U+2206）。
Which option of (1), (2), (3), (4), (5), or (6) is preferred may depend on context and the specific character(s) in question. All are acceptable within an RFC. "US-ASCII Escaping of Unicode Character" [BCP137] describes the pros and cons of different options for identifying Unicode characters and may help authors decide how to represent the non-ASCII characters in their documents.
首选（1）、（2）、（3）、（4）、（5）或（6）中的哪一个选项可能取决于上下文和所讨论的特定字符。在RFC中，所有这些都是可接受的。“Unicode字符的US-ASCII转义”[BCP137]描述了识别Unicode字符的不同选项的优缺点，并可能帮助作者决定如何在文档中表示非ASCII字符。
Tables follow the same rules for identifiers and characters as in "Body of the Document" (Section 3.4). If it is sensible (i.e., more understandable for a reader) for a given document to have two tables, -- one including the identifiers and non-ASCII characters and a second with just the non-ASCII characters -- then that will be allowed at the discretion of the authors.
表格遵循与“文件正文”（第3.4节）中相同的标识符和字符规则。如果一个给定文档有两个表是明智的（即，读者更容易理解），一个表包含标识符和非ASCII字符，另一个表仅包含非ASCII字符，那么作者可以自行决定是否允许这样做。
Original text from "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords" [RFC7613].
“代表用户名和密码的国际化字符串的准备、执行和比较”[RFC7613]的原始文本。
Table 3: A sample of legal passwords
表3：合法密码示例
+------------------------------------+------------------------------+
| # | Password | Notes |
+------------------------------------+------------------------------+
| 12| <correct horse battery staple> | ASCII space is allowed |
+------------------------------------+------------------------------+
| 13| <Correct Horse Battery Staple> | Different from example 12 |
+------------------------------------+------------------------------+
| 14| <πßå> | Non-ASCII letters are OK |
| | | (e.g., GREEK SMALL LETTER |
| | | PI, U+03C0) |
+------------------------------------+------------------------------+
| 15| <Jack of ♦s> | Symbols are OK (e.g., BLACK |
| | | DIAMOND SUIT, U+2666) |
+------------------------------------+------------------------------+
| 16| <foo bar> | OGHAM SPACE MARK, U+1680, is |
| | | mapped to U+0020 and thus |
| | | the full string is mapped to |
| | | <foo bar> |
+------------------------------------+------------------------------+
+------------------------------------+------------------------------+
| # | Password | Notes |
+------------------------------------+------------------------------+
| 12| <correct horse battery staple> | ASCII space is allowed |
+------------------------------------+------------------------------+
| 13| <Correct Horse Battery Staple> | Different from example 12 |
+------------------------------------+------------------------------+
| 14| <πßå> | Non-ASCII letters are OK |
| | | (e.g., GREEK SMALL LETTER |
| | | PI, U+03C0) |
+------------------------------------+------------------------------+
| 15| <Jack of ♦s> | Symbols are OK (e.g., BLACK |
| | | DIAMOND SUIT, U+2666) |
+------------------------------------+------------------------------+
| 16| <foo bar> | OGHAM SPACE MARK, U+1680, is |
| | | mapped to U+0020 and thus |
| | | the full string is mapped to |
| | | <foo bar> |
+------------------------------------+------------------------------+
Preferred text:
首选文本：
Table 3: A sample of legal passwords
表3：合法密码示例
+------------------------------------+------------------------------+
| # | Password | Notes |
+------------------------------------+------------------------------+
| 12| <correct horse battery staple> | ASCII space is allowed |
+------------------------------------+------------------------------+
| 13| <Correct Horse Battery Staple> | Different from example 12 |
+------------------------------------+------------------------------+
| 14| <(See PDF for non-ASCII | Non-ASCII letters are OK |
| | character string)> | (e.g., GREEK SMALL LETTER |
| | | PI, U+03C0; LATIN SMALL |
| | | LETTER SHARP S, U+00DF; THAI |
| | | DIGIT SEVEN, U+0E57) |
+------------------------------------+------------------------------+
| 15| <Jack of (See PDF for non- | Symbols are OK (e.g., BLACK |
| | ASCII character string)s> | DIAMOND SUIT, U+2666) |
+------------------------------------+------------------------------+
| 16| <foo(See PDF for non-ASCII | OGHAM SPACE MARK, U+1680, is |
| | character string)bar> | mapped to U+0020 and thus |
| | | the full string is mapped to |
| | | <foo bar> |
+------------------------------------+------------------------------+
+------------------------------------+------------------------------+
| # | Password | Notes |
+------------------------------------+------------------------------+
| 12| <correct horse battery staple> | ASCII space is allowed |
+------------------------------------+------------------------------+
| 13| <Correct Horse Battery Staple> | Different from example 12 |
+------------------------------------+------------------------------+
| 14| <(See PDF for non-ASCII | Non-ASCII letters are OK |
| | character string)> | (e.g., GREEK SMALL LETTER |
| | | PI, U+03C0; LATIN SMALL |
| | | LETTER SHARP S, U+00DF; THAI |
| | | DIGIT SEVEN, U+0E57) |
+------------------------------------+------------------------------+
| 15| <Jack of (See PDF for non- | Symbols are OK (e.g., BLACK |
| | ASCII character string)s> | DIAMOND SUIT, U+2666) |
+------------------------------------+------------------------------+
| 16| <foo(See PDF for non-ASCII | OGHAM SPACE MARK, U+1680, is |
| | character string)bar> | mapped to U+0020 and thus |
| | | the full string is mapped to |
| | | <foo bar> |
+------------------------------------+------------------------------+
The RFC Editor encourages the use of the U+ notation except within a code component where one must follow the rules of the programming language in which the code is being written.
RFC编辑器鼓励使用U+符号，除非在代码组件中必须遵循编写代码所用编程语言的规则。
Code components are generally expected to use fixed-width fonts. Where such fonts are not available for a particular script, the best script-appropriate font will be used for that part of the code component.
代码组件通常使用固定宽度的字体。如果此类字体不适用于特定脚本，则代码组件的该部分将使用与脚本最佳匹配的字体。
The reference entry must be in English; whatever subfields are present must be available in ASCII-encoded characters. For references to RFCs and Internet-Drafts, the author's name will be formatted in the reference as per current RFC Style Guide recommendations. As long as good sense is used, the reference entry may also include non-ASCII characters at the author's discretion and as provided by the author. The RFC Editor may request that a third party, such as a language specialist or subject matter expert, review of any non-ASCII reference. This applies to both normative and informative references.
参考条目必须使用英语；存在的任何子字段都必须以ASCII编码字符提供。对于RFC和互联网草稿的引用，将按照当前RFC样式指南的建议在引用中格式化作者姓名。只要使用良好的判断力，参考条目也可以包括非ASCII字符，由作者自行决定，并由作者提供。RFC编辑可要求第三方（如语言专家或主题专家）审查任何非ASCII参考。这适用于规范性和信息性参考文件。
Example:
例子：
[GOST3410] "Information technology. Cryptographic data security. Signature and verification processes of [electronic] digital signature.", GOST R 34.10-2001, Gosudarstvennyi Standard of Russian Federation, Government Committee of Russia for Standards, 2001. (In Russian)
[GOST3410]“信息技术.加密数据安全.[电子]数字签名的签名和验证过程”，GOST R 34.10-2001，俄罗斯联邦GOSUDARTVENNYI标准，俄罗斯政府标准委员会，2001年。（俄语）
Allowable addition to the above citation: (See PDF for non-ASCII character strings)
上述引文的允许添加内容：（非ASCII字符串见PDF）
Alternatively: [GOST3410] "Information technology. Cryptographic data security. Signature and verification processes of [electronic] digital signature.", GOST R 34.10-2001, Gosudarstvennyi Standard of Russian Federation, (See PDF for non-ASCII character strings) (Government Committee of Russia for Standards), 2001. (In Russian)
或者：[GOST3410]“信息技术.加密数据安全.[电子]数字签名的签名和验证过程”，GOST R 34.10-2001，俄罗斯联邦GOSUDARTVENNYI标准，（非ASCII字符串见PDF）（俄罗斯政府标准委员会），2001年。（俄语）
Keywords (as tagged with the <keyword> element in XML) and citation tags (as defined in the anchor attributes of <reference> elements) must contain only ASCII characters.
关键字（用XML中的<keyword>元素标记）和引文标记（在<reference>元素的锚属性中定义）只能包含ASCII字符。
The purpose of providing address information, either postal or email, is to assist readers of an RFC in contacting the author or authors. Authors may include the official postal address as recognized by their company or local postal service without additional non-ASCII character escapes. If the email address includes non-ASCII characters and is a valid email address at the time of publication, non-ASCII character escapes are not required.
提供邮寄或电子邮件地址信息的目的是帮助RFC的读者联系作者。作者可以包括其公司或当地邮政服务机构认可的官方邮政地址，无需额外的非ASCII字符转义。如果电子邮件地址包含非ASCII字符，并且在发布时是有效的电子邮件地址，则不需要非ASCII字符转义。
Example:
例子：
Qin Wu (editor) Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
秦武（编辑）中国江苏省南京市雨花区华为软件大道101号210012
Additional contact information: (See PDF for non-ASCII character strings)
其他联系信息：（有关非ASCII字符串，请参见PDF）
------
------
Roni Even Huawei 14 David Hamelech Tel Aviv 64953 Israel
Roni甚至华为14 David Hamelech特拉维夫64953以色列
Additional contact information: (See PDF for non-ASCII character strings)
其他联系信息：（有关非ASCII字符串，请参见PDF）
Authors should not expect normalization forms [UNICODE-NORM]to be preserved. If a particular normalization form is expected, note that in the text of the RFC.
作者不应期望保留规范化表单[UNICODE-NORM]。如果需要特定的规范化形式，请注意RFC的文本中。
As described above, use of non-ASCII characters in areas such as email, company name, address, and name is allowed. In order to make it easier for code to identify the appropriate ASCII alternatives, authors must include an "ascii" attribute to their XML markup when an ASCII alternative is required. See [RFC7991] for more detail on how to tag ASCII alternatives.
如上所述，允许在电子邮件、公司名称、地址和名称等区域使用非ASCII字符。为了使代码更容易识别适当的ASCII替代方案，当需要ASCII替代方案时，作者必须在XML标记中包含“ASCII”属性。有关如何标记ASCII备选方案的更多详细信息，请参见[RFC7991]。
The ability to use non-ASCII characters in RFCs in a clear and consistent manner will improve the ability to describe internationalized protocols and will recognize the diversity of authors. However, the goal of readability will override the use of non-ASCII characters within the text.
以清晰一致的方式在RFC中使用非ASCII字符的能力将提高描述国际化协议的能力，并将认识到作者的多样性。然而，可读性的目标将覆盖文本中非ASCII字符的使用。
Valid Unicode that matches the expected text must be verified in order to preserve expected behavior and protocol information.
必须验证与预期文本匹配的有效Unicode，以保留预期行为和协议信息。
[BCP137] Klensin, J., "ASCII Escaping of Unicode Characters", BCP 137, RFC 5137, February 2008, <http://www.rfc-editor.org/info/bcp137>.
[BCP137]Klensin，J.，“Unicode字符的ASCII转义”，BCP 137，RFC 5137，2008年2月<http://www.rfc-editor.org/info/bcp137>.
[MerrWeb] Merriam-Webster, Inc., "Merriam-Webster's Collegiate Dictionary, 11th Edition", 2009.
[MerrWeb]梅里亚姆·韦伯斯特公司，“梅里亚姆·韦伯斯特大学词典，第11版”，2009年。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，STD 80，RFC 20，DOI 10.17487/RFC0020，1969年10月<http://www.rfc-editor.org/info/rfc20>.
[RFC4475] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, DOI 10.17487/RFC4475, May 2006, <http://www.rfc-editor.org/info/rfc4475>.
[RFC4475]Sparks，R.，Ed.，Hawrylyshen，A.，Johnston，A.，Rosenberg，J.，和H.Schulzrinne，“会话启动协议（SIP）酷刑测试消息”，RFC 4475，DOI 10.17487/RFC4475，2006年5月<http://www.rfc-editor.org/info/rfc4475>.
[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, DOI 10.17487/RFC7322, September 2014, <http://www.rfc-editor.org/info/rfc7322>.
[RFC7322]Flanagan，H.和S.Ginoza，“RFC风格指南”，RFC 7322，DOI 10.17487/RFC7322，2014年9月<http://www.rfc-editor.org/info/rfc7322>.
[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 7564, DOI 10.17487/RFC7564, May 2015, <http://www.rfc-editor.org/info/rfc7564>.
[RFC7564]Saint Andre，P.和M.Blanchet，“PRECIS框架：应用协议中国际化字符串的准备、实施和比较”，RFC 7564，DOI 10.17487/RFC7564，2015年5月<http://www.rfc-editor.org/info/rfc7564>.
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 7613, DOI 10.17487/RFC7613, August 2015, <http://www.rfc-editor.org/info/rfc7613>.
[RFC7613]Saint Andre，P.和A.Melnikov，“代表用户名和密码的国际化字符串的准备、实施和比较”，RFC 7613，DOI 10.17487/RFC7613，2015年8月<http://www.rfc-editor.org/info/rfc7613>.
[RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, December 2016, <http://www.rfc-editor.org/info/rfc7991>.
[RFC7991]Hoffman，P.“xml2rfc”版本3词汇表”，RFC 7991，DOI 10.17487/RFC7991，2016年12月<http://www.rfc-editor.org/info/rfc7991>.
[UNICODE-CHART] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/charts>.
[UNICODE-CHART]UNICODE联盟，“UNICODE标准”<http://www.unicode.org/charts>.
[UNICODE-NORM] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", 2016, <http://www.unicode.org/reports/tr15/>.
[UNICODE-NORM]UNICODE联盟，“UNICODE标准附录#15：UNICODE规范化格式”，2016年<http://www.unicode.org/reports/tr15/>.
[UnicodeCurrent] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[Unicode Decurrent]Unicode联盟，“Unicode标准”<http://www.unicode.org/versions/latest/>.
IAB Members at the Time of Approval
批准时的IAB成员
The IAB members at the time this memo was approved were (in alphabetical order):
本备忘录批准时，IAB成员为（按字母顺序排列）：
Jari Arkko Ralph Droms Ted Hardie Joe Hildebrand Russ Housley Lee Howard Erik Nordmark Robert Sparks Andrew Sullivan Dave Thaler Martin Thomson Brian Trammell Suzanne Woolf
贾里·阿克科·拉尔夫·德罗姆斯·泰德·哈迪·乔·希尔德布兰德·罗斯·霍斯利·李·霍华德·埃里克·诺德马克·罗伯特·斯帕克斯·安德鲁·沙利文·戴夫·泰勒·马丁·汤姆森·布莱恩·特拉梅尔·苏珊娜·伍尔夫
Acknowledgements
致谢
With many thanks to the members of the IAB i18n program. Also, many thanks to the RFC Format Design Team for their efforts in making this transition successful: Nevil Brownlee (ISE), Tony Hansen, Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, Alice Russo, Robert Sparks (Tools Team liaison), and Dave Thaler.
非常感谢IAB i18n计划的成员。此外，非常感谢RFC格式设计团队为成功实现这一过渡所做的努力：内维尔·布朗利（ISE）、托尼·汉森、乔·希尔德布兰德、保罗·霍夫曼、特德·莱蒙、朱利安·雷什克、亚当·罗奇、爱丽丝·鲁索、罗伯特·斯帕克斯（工具团队联络员）和戴夫·泰勒。
Author's Address
作者地址
Heather Flanagan (editor) RFC Editor
希瑟·弗拉纳根（编辑）RFC编辑
Email: rse@rfc-editor.org
URI: http://orcid.org/0000-0002-2647-2220
Email: rse@rfc-editor.org
URI: http://orcid.org/0000-0002-2647-2220