Internet Engineering Task Force (IETF) P. Saint-Andre Request for Comments: 8266 Jabber.org Obsoletes: 7700 October 2017 Category: Standards Track ISSN: 2070-1721
互联网工程任务组（IETF）P.Saint Andre征求意见：8266 Jabber.org淘汰：7700 2017年10月类别：标准跟踪ISSN:2070-1721
Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames
表示昵称的国际化字符串的准备、实施和比较
Abstract
摘要
This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames", "display names", or "petnames") for people, devices, accounts, websites, and other entities. This document obsoletes RFC 7700.
本文档描述了处理Unicode字符串的方法，这些字符串表示人员、设备、帐户、网站和其他实体的可记忆的、人性化的名称（称为“昵称”、“显示名”或“宠物名”）。本文件淘汰了RFC 7700。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8266.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8266.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Nickname Profile . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Preparation . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Enforcement . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Comparison . . . . . . . . . . . . . . . . . . . . . . . 6
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Use in Application Protocols . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Authentication and Authorization . . . . . . . . . . . . 9
6.2. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 10
6.3. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 10
6.4. Visually Similar Characters . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Changes from RFC 7700 . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Nickname Profile . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Preparation . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Enforcement . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Comparison . . . . . . . . . . . . . . . . . . . . . . . 6
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Use in Application Protocols . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Authentication and Authorization . . . . . . . . . . . . 9
6.2. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 10
6.3. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 10
6.4. Visually Similar Characters . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Changes from RFC 7700 . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
A number of technologies and applications provide the ability for a person to choose a memorable, human-friendly name in a communications context or to set such a name for another entity such as a device, account, contact, or website. Such names are variously called "nicknames" (e.g., in chat room applications), "display names" (e.g., in Internet mail), or "petnames" (see [PETNAME-SYSTEMS]); for consistency, these are all called "nicknames" in this document.
许多技术和应用程序使一个人能够在通信环境中选择一个令人难忘的、人性化的名字，或者为另一个实体（如设备、帐户、联系人或网站）设置这样的名字。这些名称被称为“昵称”（例如，在聊天室应用程序中）、“显示名称”（例如，在互联网邮件中）或“宠物名称”（参见[PETNAME-SYSTEMS]）；为了保持一致性，在本文档中这些都称为“昵称”。
Nicknames are commonly supported in technologies for textual chat rooms, such as:
文本聊天室技术通常支持昵称，例如：
o Internet Relay Chat (IRC) [RFC2811]
o 互联网中继聊天（IRC）[RFC2811]
o The Message Session Relay Protocol (MSRP) [RFC4975] [RFC7701]
o 消息会话中继协议（MSRP）[RFC4975][RFC7701]
o Centralized Conferencing (XCON) [RFC5239] [XCON-SYSTEM]
o 集中会议（XCON）[RFC5239][XCON-SYSTEM]
o The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] [XEP-0045]
o 可扩展消息和状态协议（XMPP）[RFC6120][XEP-0045]
Recent chat room technologies also allow internationalized nicknames because they support code points from outside the ASCII range [RFC20], typically by means of the Unicode coded character set [Unicode]. Although such nicknames tend to be used primarily for display purposes, they are sometimes used for programmatic purposes as well (e.g., kicking users out of a chat room or avoiding nickname conflicts).
最近的聊天室技术也允许使用国际化昵称，因为它们支持ASCII范围[RFC20]之外的代码点，通常是通过Unicode编码字符集[Unicode]实现的。尽管这些昵称通常主要用于显示目的，但有时也用于编程目的（例如，将用户踢出聊天室或避免昵称冲突）。
A similar usage enables a person to set their own preferred display name or to set a preferred display name for another user (e.g., the "display-name" construct in the Internet message format [RFC5322] and the <nick/> element in XMPP [XEP-0172]).
类似的用法允许用户设置自己的首选显示名称或为另一用户设置首选显示名称（例如，互联网消息格式[RFC5322]中的“显示名称”结构和XMPP[XEP-0172]中的<nick/>元素）。
Memorable, human-friendly names are also used in contexts other than personal messaging, such as names for devices (e.g., in a network visualization application), websites (e.g., for bookmarks in a web browser), accounts (e.g., in a web interface for a list of payees in a bank account), people (e.g., in a contact list application), and the like.
除了个人消息传递之外，还可在上下文中使用令人难忘的、人性化的名称，例如设备名称（例如，在网络可视化应用程序中）、网站名称（例如，在网络浏览器中的书签）、账户名称（例如，在银行账户中的收款人列表的网络界面中）、人员名称（例如，在联系人列表应用程序中）等等。
The rules specified in this document can be applied in all of the foregoing contexts.
本文件中规定的规则可适用于上述所有情况。
It is important to understand that a nickname is a personally memorable name or handle for something that has a more stable, underlying identity, such as a URI or a file path. To ensure secure operation of applications that use nicknames, authentication and authorization decisions MUST be made on the basis of the thing's identity, not its nickname.
重要的是要理解昵称是一个个人难忘的名称或句柄，它具有更稳定的底层标识，例如URI或文件路径。为了确保使用昵称的应用程序的安全运行，身份验证和授权决策必须基于对象的身份，而不是其昵称。
To increase the likelihood that memorable, human-friendly names will work in ways that make sense for typical users throughout the world, this document defines rules for handling nicknames in terms of the preparation, enforcement, and comparison of internationalized strings (PRECIS) framework specification [RFC8264].
为了提高令人难忘的、人性化的名称对世界各地的典型用户有意义的可能性，本文档定义了处理昵称的规则，包括国际化字符串（PRECIS）框架规范的准备、实施和比较[RFC8264]。
Many important terms used in this document are defined in [RFC8264], [RFC6365], and [Unicode].
[RFC8264]、[RFC6365]和[Unicode]中定义了本文档中使用的许多重要术语。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The following rules apply within the Nickname profile of the PRECIS FreeformClass defined in the PRECIS framework specification [RFC8264].
以下规则适用于PRECIS框架规范[RFC8264]中定义的PRECIS FreeformClass的昵称配置文件。
1. Width Mapping Rule: There is no width mapping rule (such a rule is not necessary because width mapping is performed as part of normalization using Normalization Form KC (NFKC) as specified below).
1. 宽度映射规则：没有宽度映射规则（不需要这样的规则，因为宽度映射是使用规范化表单KC（NFKC）作为规范化的一部分执行的，如下所述）。
2. Additional Mapping Rule: The additional mapping rule consists of the following sub-rules.
2. 附加映射规则：附加映射规则由以下子规则组成。
a. Map any instances of non-ASCII space to SPACE (U+0020); a non-ASCII space is any Unicode code point having a general category of "Zs", naturally with the exception of SPACE (U+0020). (The inclusion of only ASCII space prevents confusion with various non-ASCII space code points, many of which are difficult to reproduce across different input methods.)
a. 将非ASCII空间的任何实例映射到空间（U+0020）；非ASCII空间是具有一般类别“Zs”的任何Unicode代码点，当然，空格（U+0020）除外。（仅包含ASCII空间可防止与各种非ASCII空间代码点混淆，其中许多代码点很难跨不同的输入方法复制。）
b. Remove any instances of the ASCII space character at the beginning or end of a nickname (e.g., "stpeter " is mapped to "stpeter").
b. 删除昵称开头或结尾的ASCII空格字符的任何实例（例如，“stpeter”映射到“stpeter”）。
c. Map interior sequences of more than one ASCII space character to a single ASCII space character (e.g., "St Peter" is mapped to "St Peter").
c. 将多个ASCII空格字符的内部序列映射到单个ASCII空格字符（例如，“St Peter”映射到“St Peter”）。
3. Case Mapping Rule: Apply the Unicode toLowerCase() operation, as defined in the Unicode Standard [Unicode]. In applications that prohibit conflicting nicknames, this rule helps to reduce the possibility of confusion by ensuring that nicknames differing only by case (e.g., "stpeter" vs. "StPeter") would not be presented to a human user at the same time. (As explained below, this is typically appropriate only for comparison, not for enforcement.)
3. 大小写映射规则：按照Unicode标准[Unicode]中的定义，应用Unicode toLowerCase（）操作。在禁止冲突昵称的应用程序中，此规则有助于减少混淆的可能性，方法是确保仅因大小写不同的昵称（例如，“stpeter”与“stpeter”）不会同时呈现给人类用户。（如下所述，这通常仅适用于比较，不适用于强制执行。）
4. Normalization Rule: Apply Unicode Normalization Form KC. Because NFKC is more "aggressive" in finding matches than other normalization forms (in the terminology of Unicode, it performs both canonical and compatibility decomposition before recomposing code points), this rule helps to reduce the possibility of confusion by increasing the number of code points that would
4. 规范化规则：应用Unicode规范化表单KC。由于NFKC在查找匹配项方面比其他规范化形式更“积极”（在Unicode术语中，它在重新组合代码点之前执行规范分解和兼容性分解），因此此规则通过增加可能导致混淆的代码点数量来帮助减少混淆的可能性
match; for example, the character "Ⅳ" (ROMAN NUMERAL FOUR, U+2163) would match the combination of "I" (LATIN CAPITAL LETTER I, U+0049) and "V" (LATIN CAPITAL LETTER V, U+0056).
火柴例如，字符“Ⅳ”（罗马数字4，U+2163）将匹配“I”（拉丁文大写字母I，U+0049）和“V”（拉丁文大写字母V，U+0056）的组合。
5. Directionality Rule: There is no directionality rule. The "Bidi Rule" (defined in [RFC5893]) and similar rules are unnecessary and inapplicable to nicknames, because it is perfectly acceptable for a given nickname to be presented differently in different layout systems (e.g., a user interface that is configured to handle primarily a right-to-left script versus an interface that is configured to handle primarily a left-to-right script), as long as the presentation is consistent in any given layout system.
5. 方向性规则：没有方向性规则。“Bidi规则”（在[RFC5893]中定义）和类似规则是不必要的，也不适用于昵称，因为给定的昵称在不同的布局系统中以不同的方式呈现是完全可以接受的（例如，配置为主要处理从右到左脚本的用户界面，而不是配置为主要处理从左到右脚本的界面），只要呈现在任何给定布局系统中是一致的。
Implementation experience has shown that applying the rules for the Nickname profile is not an idempotent procedure for all code points. Therefore, an implementation SHOULD apply the rules repeatedly until the output string is stable; if the output string does not stabilize after reapplying the rules three (3) additional times after the first application, the implementation SHOULD terminate application of the rules and reject the input string as invalid.
实现经验表明，应用昵称配置文件的规则并不是所有代码点的幂等过程。因此，实现应该重复应用规则，直到输出字符串稳定为止；如果输出字符串在第一次应用后再次应用规则三（3）次后不稳定，则实现应终止规则的应用，并将输入字符串视为无效而拒绝。
An entity that prepares an input string for subsequent enforcement according to this profile MUST ensure that the string consists only of Unicode code points that conform to the FreeformClass string class defined in [RFC8264].
根据此配置文件准备输入字符串以供后续执行的实体必须确保该字符串仅包含符合[RFC8264]中定义的FreeformClass字符串类的Unicode代码点。
An entity that performs enforcement according to this profile MUST prepare an input string as described in Section 2.2 and MUST also apply the following rules specified in Section 2.1 in the order shown:
根据本概要文件执行强制的实体必须按照第2.2节所述准备输入字符串，还必须按照所示顺序应用第2.1节规定的以下规则：
1. Additional Mapping Rule 2. Normalization Rule
1. 附加映射规则2。规范化规则
Note: An entity SHOULD apply the Case Mapping Rule only during comparison.
注意：实体应仅在比较期间应用案例映射规则。
After all of the foregoing rules have been enforced, the entity MUST ensure that the nickname is not zero bytes in length (this is done after enforcing the rules to prevent applications from mistakenly omitting a nickname entirely, because when internationalized strings are accepted a non-empty sequence of characters can result in a zero-length nickname after canonicalization).
在执行了上述所有规则之后，实体必须确保昵称的长度不是零字节（这是在强制执行规则以防止应用程序错误地完全忽略昵称后完成的，因为当接受国际化字符串时，非空字符序列可能会在规范化后导致长度为零的昵称）。
The result of the foregoing operations is an output string that conforms to the Nickname profile. Until an implementation produces such an output string, it MUST NOT treat the string as conforming (in particular, it MUST NOT assume that an input string is conforming before the enforcement operation has been completed).
上述操作的结果是符合昵称配置文件的输出字符串。在实现生成这样的输出字符串之前，它不得将该字符串视为符合要求的字符串（特别是，它不得假设在执行操作完成之前输入字符串是符合要求的）。
An entity that performs comparison of two strings according to this profile MUST prepare each input string as specified in Section 2.2 and MUST apply the following rules specified in Section 2.1 in the order shown:
根据此配置文件执行两个字符串比较的实体必须按照第2.2节的规定准备每个输入字符串，并且必须按照所示顺序应用第2.1节规定的以下规则：
1. Additional Mapping Rule 2. Case Mapping Rule 3. Normalization Rule
1. 附加映射规则2。案例映射规则3。规范化规则
The two strings are to be considered equivalent if and only if they are an exact octet-for-octet match (sometimes called "bit-string identity").
当且仅当两个字符串是八位字节匹配的精确八位字节（有时称为“位字符串标识”）时，这两个字符串才被认为是等效的。
Until an implementation determines whether two strings are to be considered equivalent, it MUST NOT treat them as equivalent (in particular, it MUST NOT assume that two input strings are equivalent before the comparison operation has been completed).
在实现确定两个字符串是否等效之前，它不能将它们视为等效的（特别是，在比较操作完成之前，它不能假定两个输入字符串是等效的）。
The following examples illustrate a small number of nicknames that are consistent with the format defined above, along with the output string resulting from application of the PRECIS rules for comparison purposes (note that the characters "<" and ">" are used to delineate the actual nickname and are not part of the nickname strings).
以下示例说明了与上述格式一致的少量昵称，以及应用PRECIS规则进行比较产生的输出字符串（请注意，“<”和“>”字符用于描述实际昵称，不属于昵称字符串的一部分）。
+---------------------------+-------------------------------------+
| # | Nickname | Output for Comparison |
+---------------------------+-------------------------------------+
| 1 | <Foo> | <foo> |
+---------------------------+-------------------------------------+
| 2 | <foo> | <foo> |
+---------------------------+-------------------------------------+
| 3 | <Foo Bar> | <foo bar> |
+---------------------------+-------------------------------------+
| 4 | <foo bar> | <foo bar> |
+---------------------------+-------------------------------------+
| 5 | <Σ> | σ (GREEK SMALL LETTER SIGMA, |
| | | U+03C3) |
+---------------------------+-------------------------------------+
| 6 | <σ> | σ (GREEK SMALL LETTER SIGMA, |
| | | U+03C3) |
+---------------------------+-------------------------------------+
| 7 | <ς> | ς (GREEK SMALL LETTER FINAL SIGMA, |
| | | U+03C2) |
+---------------------------+-------------------------------------+
| 8 | <ϔ> | ϋ (GREEK SMALL LETTER UPSILON |
| | | WITH DIALYTIKA, U+03CB) |
+---------------------------+-------------------------------------+
| 9 | <∞> | ∞ (INFINITY, U+221E) |
+---------------------------+-------------------------------------+
| 10 | <Richard Ⅳ> | <richard iv> |
+---------------------------+-------------------------------------+
+---------------------------+-------------------------------------+
| # | Nickname | Output for Comparison |
+---------------------------+-------------------------------------+
| 1 | <Foo> | <foo> |
+---------------------------+-------------------------------------+
| 2 | <foo> | <foo> |
+---------------------------+-------------------------------------+
| 3 | <Foo Bar> | <foo bar> |
+---------------------------+-------------------------------------+
| 4 | <foo bar> | <foo bar> |
+---------------------------+-------------------------------------+
| 5 | <Σ> | σ (GREEK SMALL LETTER SIGMA, |
| | | U+03C3) |
+---------------------------+-------------------------------------+
| 6 | <σ> | σ (GREEK SMALL LETTER SIGMA, |
| | | U+03C3) |
+---------------------------+-------------------------------------+
| 7 | <ς> | ς (GREEK SMALL LETTER FINAL SIGMA, |
| | | U+03C2) |
+---------------------------+-------------------------------------+
| 8 | <ϔ> | ϋ (GREEK SMALL LETTER UPSILON |
| | | WITH DIALYTIKA, U+03CB) |
+---------------------------+-------------------------------------+
| 9 | <∞> | ∞ (INFINITY, U+221E) |
+---------------------------+-------------------------------------+
| 10 | <Richard Ⅳ> | <richard iv> |
+---------------------------+-------------------------------------+
Table 1: A Sample of Legal Nicknames
表1：法定昵称示例
Regarding examples 5, 6, and 7: applying the Unicode toLowerCase() operation to the character "Σ" (GREEK CAPITAL LETTER SIGMA, U+03A3) results in the character "σ" (GREEK SMALL LETTER SIGMA, U+03C3); however, the toLowerCase() operation does not modify the character "ς" (GREEK SMALL LETTER FINAL SIGMA, U+03C2). Therefore, the comparison operation defined in Section 2.4 would result in matching of the nicknames in examples 5 and 6 but not the nicknames in examples 5 and 7 or 6 and 7.
关于示例5、6和7：将Unicode toLowerCase（）操作应用于字符“σ”（希腊大写字母SIGMA，U+03A3）会导致字符“σ”（希腊小写字母SIGMA，U+03C3）；但是，toLowerCase（）操作不会修改字符“ς”（希腊小写字母FINAL SIGMA，U+03C2）。因此，第2.4节中定义的比较操作将导致示例5和6中的昵称匹配，但不会导致示例5和7或6和7中的昵称匹配。
Regarding example 8: this is an instance where applying the rules for the Nickname profile is not an idempotent procedure (see Section 2.1). In particular:
关于示例8：这是一个应用昵称配置文件规则不是幂等过程的实例（参见第2.1节）。特别地：
1. Applying toLowerCase() to the character "ϔ" (GREEK UPSILON WITH DIARESIS AND HOOK SYMBOL, U+03D4) results in no changes, and applying NFKC to that character results in the character "Ϋ" (GREEK CAPITAL LETTER UPSILON WITH DIALYTIKA, U+03AB).
1. 将toLowerCase（）应用于字符“ϔ”（希腊大写字母UPSILON，带有DIARESIS和HOOK符号，U+03D4）不会导致任何更改，而将NFKC应用于该字符会导致字符“Ϋ”（希腊大写字母UPSILON，带有DIALYTIKA，U+03AB）。
2. Applying toLowerCase() to "Ϋ" (GREEK CAPITAL LETTER UPSILON WITH DIALYTIKA, U+03AB) results in the character "ϋ" (GREEK SMALL LETTER UPSILON WITH DIALYTIKA, U+03CB), and applying NFKC to that character results in no changes.
2. 将toLowerCase（）应用于“Ϋ”（希腊文大写字母UPSILON加上DIALYTIKA，U+03AB）会导致字符“ϋ”（希腊文小写字母UPSILON加上DIALYTIKA，U+03CB），而将NFKC应用于该字符不会导致任何更改。
Regarding example 9: symbol characters such as "∞" (INFINITY, U+221E) are allowed by the PRECIS FreeformClass and thus can be used in nicknames.
关于示例9：符号字符，例如“∞" （无穷大，U+221E）是PRECIS FreeformClass允许的，因此可以在昵称中使用。
Regarding example 10: applying the Unicode toLowerCase() operation to the character "Ⅳ" (ROMAN NUMERAL FOUR, U+2163) results in the character "ⅳ" (SMALL ROMAN NUMERAL FOUR, U+2173), and applying NFKC to the character "ⅳ" (SMALL ROMAN NUMERAL FOUR, U+2173) results in the characters "i" (LATIN SMALL LETTER I, U+0069) and "v" (LATIN SMALL LETTER V, U+0076).
关于示例10：对字符“Ⅳ”（罗马数字4，U+2163）应用Unicode toLowerCase（）操作将导致字符“Ⅳ”ⅳ" （小罗马数字四，U+2173），并将NFKC应用于字符“ⅳ“（小罗马数字四，U+2173）产生字符“i”（拉丁文小写字母i，U+0069）和“v”（拉丁文小写字母v，U+0076）。
This specification defines only the PRECIS-based rules for handling of nickname strings. It is the responsibility of an application protocol (e.g., MSRP, XCON, or XMPP) or application definition to specify the protocol slots in which nickname strings can appear, the entities that are expected to enforce the rules governing nickname strings, and the point during protocol processing or interface handling when the rules need to be enforced. See Section 6 of [RFC8264] for guidelines about using PRECIS profiles in applications.
本规范仅定义用于处理昵称字符串的基于PRECIS的规则。应用程序协议（例如，MSRP、XCON或XMPP）或应用程序定义负责指定昵称字符串可以出现的协议插槽，以及期望强制执行昵称字符串规则的实体，以及协议处理或接口处理期间需要强制执行规则的点。有关在应用程序中使用PRECIS配置文件的指南，请参见[RFC8264]第6节。
Above and beyond the PRECIS-based rules specified here, application protocols can also define application-specific rules governing nickname strings (rules regarding the minimum or maximum length of nicknames, further restrictions on allowable code points or character ranges, safeguards to mitigate the effects of visually similar characters, etc.).
除了此处指定的基于PRECIS的规则之外，应用程序协议还可以定义管理昵称字符串的特定于应用程序的规则（关于昵称最小或最大长度的规则、对允许的代码点或字符范围的进一步限制、减轻视觉相似字符影响的保护措施等）。
Naturally, application protocols can also specify rules governing the actual use of nicknames in applications (reserved nicknames, authorization requirements for using nicknames, whether certain nicknames can be prohibited, handling of duplicates, the relationship between nicknames and underlying identifiers such as SIP URIs or Jabber IDs, etc.).
当然，应用程序协议还可以指定管理应用程序中昵称的实际使用的规则（保留昵称、使用昵称的授权要求、是否可以禁止某些昵称、重复的处理、昵称和基础标识符（如SIP URI或Jabber ID）之间的关系等）。
Entities that enforce the rules specified in this document are encouraged to be liberal in what they accept by following this procedure:
鼓励执行本文件规定规则的实体通过以下程序自由接受：
1. Where possible, map characters (e.g., through width mapping, additional mapping, case mapping, or normalization) and accept the mapped string.
1. 在可能的情况下，映射字符（例如，通过宽度映射、附加映射、大小写映射或规范化）并接受映射字符串。
2. If mapping is not possible (e.g., because a character is disallowed in the FreeformClass), reject the string.
2. 如果无法进行映射（例如，因为FreeformClass中不允许使用字符），请拒绝该字符串。
IANA has added the following entry to the "PRECIS Profiles" registry:
IANA已将以下条目添加到“PRECIS配置文件”注册表中：
Name: Nickname.
姓名：昵称。
Base Class: FreeformClass.
基类：FreeformClass。
Applicability: Nicknames or display names in messaging and text conferencing technologies; petnames for devices, accounts, and people; and other uses of nicknames, display names, or petnames.
适用性：消息和文本会议技术中的昵称或显示名称；设备、帐户和人员的名称；以及昵称、显示名或宠物名的其他用法。
Replaces: None.
替换：无。
Width Mapping Rule: None (handled via NFKC).
宽度映射规则：无（通过NFKC处理）。
Additional Mapping Rule: Map non-ASCII space characters to SPACE (U+0020), strip leading and trailing space characters, and map interior sequences of multiple space characters to a single instance of SPACE (U+0020).
其他映射规则：将非ASCII空格字符映射到空格（U+0020）、带前导和尾随空格字符，并将多个空格字符的内部序列映射到单个空格实例（U+0020）。
Case Mapping Rule: Map uppercase and titlecase code points to lowercase using the Unicode toLowerCase() operation.
大小写映射规则：使用Unicode toLowerCase（）操作将大写和titlecase代码点映射为小写。
Normalization Rule: NFKC.
规范化规则：NFKC。
Directionality Rule: None.
方向性规则：无。
Enforcement: To be specified by applications.
强制执行：由应用程序指定。
Specification: RFC 8266.
规格：RFC 8266。
It is important to understand that a nickname is a personally memorable name or handle for something that has a more stable, underlying identity, such as a URI or a file path. To ensure secure operation of applications that use nicknames, authentication and authorization decisions MUST be made on the basis of the thing's identity, not its nickname.
重要的是要理解昵称是一个个人难忘的名称或句柄，它具有更稳定的底层标识，例如URI或文件路径。为了确保使用昵称的应用程序的安全运行，身份验证和授权决策必须基于对象的身份，而不是其昵称。
The security considerations described in [RFC8264] apply to the FreeformClass string class used in this document for nicknames.
[RFC8264]中描述的安全注意事项适用于本文档中用于昵称的FreeformClass字符串类。
The security considerations described in [UTS39] apply to the use of Unicode code points in nicknames.
[UTS39]中描述的安全注意事项适用于昵称中Unicode代码点的使用。
[RFC8264] describes some of the security considerations related to visually similar characters, also called "confusable characters" or "confusables", and provides some examples of such characters.
[RFC8264]描述了与视觉相似字符（也称为“可混淆字符”或“可混淆字符”）相关的一些安全注意事项，并提供了此类字符的一些示例。
Although the mapping rules defined in Section 2 of this document are designed, in part, to reduce the possibility of confusion about nicknames, this document does not provide more-detailed recommendations regarding the handling of visually similar characters, such as those provided in [UTS39].
尽管本文件第2节中定义的映射规则的设计部分是为了减少昵称混淆的可能性，但本文件并未提供关于视觉相似字符处理的更详细建议，如[UTS39]中提供的建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, <https://www.rfc-editor.org/info/rfc5893>.
[RFC5893]Alvestrand，H.，Ed.和C.Karp，“应用程序国际化域名（IDNA）的从右到左脚本”，RFC 5893，DOI 10.17487/RFC5893，2010年8月<https://www.rfc-editor.org/info/rfc5893>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, <https://www.rfc-editor.org/info/rfc6365>.
[RFC6365]Hoffman，P.和J.Klensin，“IETF国际化中使用的术语”，BCP 166，RFC 6365，DOI 10.17487/RFC6365，2011年9月<https://www.rfc-editor.org/info/rfc6365>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 8264, DOI 10.17487/RFC8264, October 2017, <https://www.rfc-editor.org/info/rfc8264>.
[RFC8264]Saint Andre，P.和M.Blanchet，“PRECIS框架：应用协议中国际化字符串的准备、实施和比较”，RFC 8264，DOI 10.17487/RFC8264，2017年10月<https://www.rfc-editor.org/info/rfc8264>.
[Unicode] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[Unicode]Unicode联盟，“Unicode标准”<http://www.unicode.org/versions/latest/>.
[UTS39] Unicode Technical Standard #39, "Unicode Security Mechanisms", edited by Mark Davis and Michel Suignard, <http://unicode.org/reports/tr39/>.
[UTS39]Unicode技术标准#39，“Unicode安全机制”，由Mark Davis和Michel Suignard编辑<http://unicode.org/reports/tr39/>.
[Err4570] RFC Errata, Erratum ID 4570, RFC 7700, <https://www.rfc-editor.org/errata/eid4570>.
[Err4570]RFC勘误表，勘误表ID 4570，RFC 7700<https://www.rfc-editor.org/errata/eid4570>.
[PETNAME-SYSTEMS] Stiegler, M., "An Introduction to Petname Systems", updated June 2010, February 2005, <http://www.skyhunter.com/marcs/petnames/ IntroPetNames.html>.
[PETNAME-SYSTEMS]Stiegler，M.，“PETNAME系统简介”，2010年6月更新，2005年2月<http://www.skyhunter.com/marcs/petnames/ IntroPetNames.html>。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，STD 80，RFC 20，DOI 10.17487/RFC0020，1969年10月<https://www.rfc-editor.org/info/rfc20>.
[RFC2811] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, DOI 10.17487/RFC2811, April 2000, <https://www.rfc-editor.org/info/rfc2811>.
[RFC2811]Kalt，C.，“互联网中继聊天：频道管理”，RFC 2811，DOI 10.17487/RFC2811，2000年4月<https://www.rfc-editor.org/info/rfc2811>.
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, <https://www.rfc-editor.org/info/rfc4975>.
[RFC4975]Campbell，B.，Ed.，Mahy，R.，Ed.，和C.Jennings，Ed.，“消息会话中继协议（MSRP）”，RFC 4975，DOI 10.17487/RFC4975，2007年9月<https://www.rfc-editor.org/info/rfc4975>.
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, DOI 10.17487/RFC5239, June 2008, <https://www.rfc-editor.org/info/rfc5239>.
[RFC5239]Barnes，M.，Boulton，C.，和O.Levin，“集中会议的框架”，RFC 5239，DOI 10.17487/RFC5239，2008年6月<https://www.rfc-editor.org/info/rfc5239>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<https://www.rfc-editor.org/info/rfc5322>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC 6120，DOI 10.17487/RFC6120，2011年3月<https://www.rfc-editor.org/info/rfc6120>.
[RFC7700] Saint-Andre, P., "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames", RFC 7700, DOI 10.17487/RFC7700, December 2015, <https://www.rfc-editor.org/info/rfc7700>.
[RFC7700]Saint Andre，P.，“代表昵称的国际化字符串的准备、实施和比较”，RFC 7700，DOI 10.17487/RFC7700，2015年12月<https://www.rfc-editor.org/info/rfc7700>.
[RFC7701] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-party Chat Using the Message Session Relay Protocol (MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015, <https://www.rfc-editor.org/info/rfc7701>.
[RFC7701]Niemi，A.，Garcia Martin，M.，和G.Sandbakken，“使用消息会话中继协议（MSRP）的多方聊天”，RFC 7701，DOI 10.17487/RFC7701，2015年12月<https://www.rfc-editor.org/info/rfc7701>.
[XCON-SYSTEM] Barnes, M., Boulton, C., and S. Loreto, "Chatrooms within a Centralized Conferencing (XCON) System", Work in Progress, draft-boulton-xcon-session-chat-08, July 2012.
[XCON-SYSTEM]Barnes，M.，Boulton，C.，和S.Loreto，“集中会议（XCON）系统内的聊天室”，正在进行的工作，草稿-Boulton-XCON-session-chat-082012年7月。
[XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, September 2017, <https://xmpp.org/extensions/xep-0045.html>.
[XEP-0045]圣安德烈，P.，“多用户聊天”，XSF XEP 00452017年9月<https://xmpp.org/extensions/xep-0045.html>.
[XEP-0172] Saint-Andre, P. and V. Mercier, "User Nickname", XSF XEP 0172, March 2012, <https://xmpp.org/extensions/xep-0172.html>.
[XEP-0172]Saint Andre，P.和V.Mercier，“用户昵称”，XSF XEP 0172，2012年3月<https://xmpp.org/extensions/xep-0172.html>.
The following changes were made from [RFC7700].
对[RFC7700]进行了以下更改。
o Addressed [Err4570] by removing the directionality rule from Sections 2.3 and 2.4.
o 通过从第2.3节和第2.4节中删除方向性规则来解决[Err4570]。
o In accordance with working group discussions and updates to [RFC8264], removed the use of the Unicode toCaseFold() operation in favor of the Unicode toLowerCase() operation.
o 根据工作组的讨论和对[RFC8264]的更新，取消了Unicode toCaseFold（）操作的使用，转而使用Unicode toLowerCase（）操作。
o Clarified several editorial matters.
o 澄清了一些编辑事项。
o Updated references.
o 更新参考资料。
Acknowledgements
致谢
Thanks to William Fisher for his implementation feedback, especially regarding idempotence.
感谢William Fisher的实现反馈，特别是关于幂等性的反馈。
Thanks to Sam Whited for his feedback and for submitting [Err4570].
感谢Sam Whited的反馈和提交[Err4570]。
See [RFC7700] for acknowledgements related to the specification that this document supersedes.
参见[RFC7700]了解与本文件所取代规范相关的确认。
Author's Address
作者地址
Peter Saint-Andre Jabber.org P.O. Box 787 Parker, CO 80134 United States of America
Peter Saint Andre Jabber.org美国科罗拉多州帕克787号邮政信箱80134
Phone: +1 720 256 6756
Email: stpeter@jabber.org
URI: https://www.jabber.org/
Phone: +1 720 256 6756
Email: stpeter@jabber.org
URI: https://www.jabber.org/