RFC 7700: Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames 中文翻译

URL : https://datatracker.ietf.org/doc/html/rfc7700
标题 : RFC 7700
翻译类型 : 自动生成

Internet Engineering Task Force (IETF)                    P. Saint-Andre
Request for Comments: 7700                                          &yet
Category: Standards Track                                  December 2015
ISSN: 2070-1721

Internet Engineering Task Force (IETF)                    P. Saint-Andre
Request for Comments: 7700                                          &yet
Category: Standards Track                                  December 2015
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.

本文档描述了处理Unicode字符串的方法，这些字符串表示人员、设备、帐户、网站和其他实体的可记忆的、人性化的名称（称为“昵称”、“显示名”或“宠物名”）。

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/rfc7700.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7700.

版权公告

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. Overview ...................................................2
      1.2. Terminology ................................................3
   2. Nickname Profile ................................................3
      2.1. Rules ......................................................3
      2.2. Preparation ................................................5
      2.3. Enforcement ................................................5
      2.4. Comparison .................................................5
   3. Examples ........................................................5
   4. Use in Application Protocols ....................................6
   5. IANA Considerations .............................................7
   6. Security Considerations .........................................8
      6.1. Reuse of PRECIS ............................................8
      6.2. Reuse of Unicode ...........................................8
      6.3. Visually Similar Characters ................................8
   7. References ......................................................8
      7.1. Normative References .......................................8
      7.2. Informative References .....................................9
   Acknowledgements ..................................................11
   Author's Address ..................................................11

   1. Introduction ....................................................2
      1.1. Overview ...................................................2
      1.2. Terminology ................................................3
   2. Nickname Profile ................................................3
      2.1. Rules ......................................................3
      2.2. Preparation ................................................5
      2.3. Enforcement ................................................5
      2.4. Comparison .................................................5
   3. Examples ........................................................5
   4. Use in Application Protocols ....................................6
   5. IANA Considerations .............................................7
   6. Security Considerations .........................................8
      6.1. Reuse of PRECIS ............................................8
      6.2. Reuse of Unicode ...........................................8
      6.3. Visually Similar Characters ................................8
   7. References ......................................................8
      7.1. Normative References .......................................8
      7.2. Informative References .....................................9
   Acknowledgements ..................................................11
   Author's Address ..................................................11

1. Introduction

1. 介绍

1.1. Overview

1.1. 概述

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, e.g., Internet Relay Chat [RFC2811] and multi-party chat technologies based on the Extensible Messaging and Presence Protocol (XMPP) [RFC6120] [XEP-0045], the Message Session Relay Protocol (MSRP) [RFC4975] [RFC7701], and Centralized Conferencing (XCON) [RFC5239] [XCON-SYSTEM]. Recent chat room technologies also allow internationalized nicknames because they support characters from outside the ASCII range [RFC20], typically by means of the Unicode 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 or avoiding nickname conflicts).

文本聊天室技术通常支持昵称，例如互联网中继聊天[RFC2811]和基于可扩展消息和状态协议（XMPP）[RFC6120][XEP-0045]、消息会话中继协议（MSRP）[RFC4975][RFC7701]和集中会议（XCON）[RFC5239][XCON-SYSTEM]的多方聊天技术. 最近的聊天室技术也允许使用国际化昵称，因为它们支持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 [XEP-0172] in XMPP).

类似的用法允许用户设置自己的首选显示名称或为另一用户设置首选显示名称（例如，XMPP中互联网消息格式[RFC5322]和[XEP-0172]中的“显示名称”结构）。

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.

本文件中规定的规则可适用于上述所有情况。

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 preparing, enforcing, and comparing internationalized nicknames.

为了增加令人难忘的、人性化的名字对全世界典型用户有意义的可能性，本文档定义了准备、实施和比较国际化昵称的规则。

1.2. Terminology

1.2. 术语

Many important terms used in this document are defined in [RFC7564], [RFC6365], and [Unicode].

[RFC7564]、[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 [RFC2119].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。

2. Nickname Profile

2. 昵称配置文件

2.1. Rules

2.1. 规则

The following rules apply within the Nickname profile of the PRECIS FreeformClass.

以下规则适用于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. 附加映射规则：附加映射规则由以下子规则组成。

1. Any instances of non-ASCII space MUST be mapped to ASCII space (U+0020); a non-ASCII space is any Unicode code point having a general category of "Zs", naturally with the exception of U+0020.

1. 非ASCII空间的任何实例必须映射到ASCII空间（U+0020）；非ASCII空间是具有一般类别“Zs”的任何Unicode代码点，当然U+0020除外。

2. Any instances of the ASCII space character at the beginning or end of a nickname MUST be removed (e.g., "stpeter " is mapped to "stpeter").

2. 必须删除昵称开头或结尾的ASCII空格字符的任何实例（例如，“stpeter”映射为“stpeter”）。

3. Interior sequences of more than one ASCII space character MUST be mapped to a single ASCII space character (e.g., "St Peter" is mapped to "St Peter").

3. 多个ASCII空格字符的内部序列必须映射到单个ASCII空格字符（例如，“St Peter”映射到“St Peter”）。

3. Case Mapping Rule: Unicode Default Case Folding MUST be applied, as defined in the Unicode Standard [Unicode] (at the time of this writing, the algorithm is specified in Chapter 3 of [Unicode7.0]). 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.

3. 大小写映射规则：必须应用Unicode默认大小写折叠，如Unicode标准[Unicode]中所定义（撰写本文时，算法在[Unicode7.0]第3章中指定）。在禁止冲突昵称的应用程序中，此规则有助于减少混淆的可能性，方法是确保仅因大小写不同的昵称（例如，“stpeter”与“stpeter”）不会同时呈现给人类用户。

4. Normalization Rule: The string MUST be normalized using Unicode NFKC. 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 characters that would match (e.g., U+2163 ROMAN NUMERAL FOUR would match the combination of U+0049 LATIN CAPITAL LETTER I and U+0056 LATIN CAPITAL LETTER V).

4. 规范化规则：必须使用Unicode NFKC规范化字符串。由于NFKC在查找匹配项方面比其他规范化形式更“积极”（在Unicode术语中，它在重新组合代码点之前执行规范分解和兼容性分解），因此此规则通过增加匹配的字符数来帮助减少混淆的可能性（例如，U+2163罗马数字4将匹配U+0049拉丁大写字母I和U+0056拉丁大写字母V的组合）。

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]中定义）和类似规则是不必要的，也不适用于昵称，因为给定的昵称在不同的布局系统中以不同的方式呈现是完全可以接受的（例如，配置为主要处理从右到左脚本的用户界面，而不是配置为主要处理从左到右脚本的界面），只要呈现在任何给定布局系统中是一致的。

2.2. Preparation

2.2. 准备

An entity that prepares a 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 [RFC7564]. In addition, the entity MUST ensure that the string is encoded as UTF-8 [RFC3629].

根据此配置文件准备字符串以供后续执行的实体必须确保该字符串仅包含符合[RFC7564]中定义的FreeformClass字符串类的Unicode代码点。此外，实体必须确保字符串编码为UTF-8[RFC3629]。

2.3. Enforcement

2.3. 执行

An entity that performs enforcement according to this profile MUST prepare a 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 3. Directionality Rule

1. 附加映射规则2。规范化规则3。方向性规则

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 characters are accepted, a non-empty sequence of characters can result in a zero-length nickname after canonicalization).

在执行了上述所有规则之后，实体必须确保昵称的长度不是零字节（这是在强制执行规则以防止应用程序错误地完全忽略昵称后完成的，因为当接受国际化字符时，非空字符序列可能会在规范化后导致长度为零的昵称）。

2.4. Comparison

2.4. 比较

An entity that performs comparison of two strings according to this profile MUST prepare each 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 4. Directionality Rule

1. 附加映射规则2。案例映射规则3。规范化规则4。方向性规则

The two strings are to be considered equivalent if they are an exact octet-for-octet match (sometimes called "bit-string identity").

如果这两个字符串是八位字节匹配的精确八位字节（有时称为“位字符串标识”），则认为它们是等效的。

3. Examples

3. 例子

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 (note that the characters < and > are used to delineate the actual nickname and are not part of the nickname strings).

以下示例说明了与上述格式一致的少量昵称，以及应用PRECIS规则产生的输出字符串（注意，<和>字符用于描述实际昵称，不属于昵称字符串的一部分）。

Table 1: A Sample of Legal Nicknames

表1：法定昵称示例

   +---------------------------+-----------------------------------+
   | # | Nickname              | Output for Comparison             |
   +---------------------------+-----------------------------------+
   | 1 | <Foo>                 | <foo>                             |
   +---------------------------+-----------------------------------+
   | 2 | <foo>                 | <foo>                             |
   +---------------------------+-----------------------------------+
   | 3 | <Foo Bar>             | <foo bar>                         |
   +---------------------------+-----------------------------------+
   | 4 | <foo bar>             | <foo bar>                         |
   +---------------------------+-----------------------------------+
   | 5 | <&#x3A3;>             | GREEK SMALL LETTER SIGMA (U+03C3) |
   +---------------------------+-----------------------------------+
   | 6 | <&#x3C3;>             | GREEK SMALL LETTER SIGMA (U+03C3) |
   +---------------------------+-----------------------------------+
   | 7 | <&#x3C2;>             | GREEK SMALL LETTER SIGMA (U+03C3) |
   +---------------------------+-----------------------------------+
   | 8 | <&#x265A;>            | BLACK CHESS KING (U+265A)         |
   +---------------------------+-----------------------------------+
   | 9 | <Richard &#x2163;>    | <richard iv>                      |
   +---------------------------+-----------------------------------+

   +---------------------------+-----------------------------------+
   | # | Nickname              | Output for Comparison             |
   +---------------------------+-----------------------------------+
   | 1 | <Foo>                 | <foo>                             |
   +---------------------------+-----------------------------------+
   | 2 | <foo>                 | <foo>                             |
   +---------------------------+-----------------------------------+
   | 3 | <Foo Bar>             | <foo bar>                         |
   +---------------------------+-----------------------------------+
   | 4 | <foo bar>             | <foo bar>                         |
   +---------------------------+-----------------------------------+
   | 5 | <&#x3A3;>             | GREEK SMALL LETTER SIGMA (U+03C3) |
   +---------------------------+-----------------------------------+
   | 6 | <&#x3C3;>             | GREEK SMALL LETTER SIGMA (U+03C3) |
   +---------------------------+-----------------------------------+
   | 7 | <&#x3C2;>             | GREEK SMALL LETTER SIGMA (U+03C3) |
   +---------------------------+-----------------------------------+
   | 8 | <&#x265A;>            | BLACK CHESS KING (U+265A)         |
   +---------------------------+-----------------------------------+
   | 9 | <Richard &#x2163;>    | <richard iv>                      |
   +---------------------------+-----------------------------------+

Regarding examples 5, 6, and 7: applying Unicode Default Case Folding to GREEK CAPITAL LETTER SIGMA (U+03A3) results in GREEK SMALL LETTER SIGMA (U+03C3), and the same is true of 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, 6, and 7. Regarding example 8: symbol characters such as BLACK CHESS KING (U+265A) are allowed by the PRECIS FreeformClass and thus can be used in nicknames. Regarding example 9: applying Unicode Default Case Folding to ROMAN NUMERAL FOUR (U+2163) results in SMALL ROMAN NUMERAL FOUR (U+2173), and applying NFKC to SMALL ROMAN NUMERAL FOUR (U+2173) results in LATIN SMALL LETTER I (U+0069) LATIN SMALL LETTER V (U+0086).

关于示例5、6和7：将Unicode默认大小写折叠应用于希腊文大写字母SIGMA（U+03A3）会产生希腊文小写字母SIGMA（U+03C3），希腊文小写字母FINAL SIGMA（U+03C2）也是如此；因此，第2.4节中定义的比较操作将导致示例5、6和7中昵称的匹配。关于示例8：PRECIS FreeformClass允许使用黑棋王（U+265A）等符号字符，因此可以在昵称中使用。关于示例9：将Unicode默认大小写折叠应用于罗马数字四（U+2163）会产生小罗马数字四（U+2173），将NFKC应用于小罗马数字四（U+2173）会产生拉丁小写字母I（U+0069）和拉丁小写字母V（U+0086）。

4. Use in Application Protocols

4. 在应用程序协议中使用

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 when in protocol processing or interface handling the rules need to be enforced. See Section 6 of [RFC7564] for guidelines about using PRECIS profiles in applications.

本规范仅定义用于处理昵称字符串的基于PRECIS的规则。应用程序协议（例如，MSRP、XCON或XMPP）或应用程序定义负责指定昵称字符串可出现的协议插槽、预期将强制执行管理昵称字符串的规则的实体，以及在协议处理或接口处理时需要强制执行规则。有关在应用程序中使用PRECIS配置文件的指南，请参见[RFC7564]第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 characters 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中不允许使用字符），请拒绝该字符串。

5. IANA Considerations

5. IANA考虑

The IANA shall add the following entry to the PRECIS Profiles Registry:

IANA应将以下条目添加到PRECIS配置文件注册表中：

Name: Nickname

姓名：昵称

Base Class: FreeformClass

基类：FreeformClass

Applicability: Nicknames in messaging and text conferencing technologies; petnames for devices, accounts, and people; and other uses of nicknames or petnames.

适用性：短信和文本会议技术中的昵称；设备、帐户和人员的名称；以及昵称或昵称的其他用法。

Replaces: None

替换：无

Width Mapping Rule: None (handled via NFKC)

宽度映射规则：无（通过NFKC处理）

Additional Mapping Rule: Map non-ASCII space characters to ASCII space, strip leading and trailing space characters, map interior sequences of multiple space characters to a single ASCII space.

其他映射规则：将非ASCII空格字符映射到ASCII空格，带前导和尾随空格字符，将多个空格字符的内部序列映射到单个ASCII空格。

Case Mapping Rule: Map uppercase and titlecase characters to lowercase using Unicode Default Case Folding.

大小写映射规则：使用Unicode默认大小写折叠将大小写字符映射为小写。

Normalization Rule: NFKC

规范化规则：NFKC

Directionality Rule: None

方向性规则：无

Enforcement: To be specified by applications.

强制执行：由应用程序指定。

Specification: RFC 7700 (this document)

规范：RFC 7700（本文件）

6. Security Considerations

6. 安全考虑

6.1. Reuse of PRECIS

6.1. PRECIS的再利用

The security considerations described in [RFC7564] apply to the FreeformClass string class used in this document for nicknames.

[RFC7564]中描述的安全注意事项适用于本文档中用于昵称的FreeformClass字符串类。

6.2. Reuse of Unicode

6.2. Unicode的重用

The security considerations described in [UTS39] apply to the use of Unicode characters in nicknames.

[UTS39]中描述的安全注意事项适用于昵称中Unicode字符的使用。

6.3. Visually Similar Characters

6.3. 视觉上相似的字符

[RFC7564] describes some of the security considerations related to visually similar characters, also called "confusable characters" or "confusables".

[RFC7564]描述了与视觉上相似的字符（也称为“可混淆字符”或“可混淆字符”）相关的一些安全注意事项。

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]中提供的建议。

7. References

7. 工具书类

7.1. Normative References

7.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.

[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.

[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, <http://www.rfc-editor.org/info/rfc5893>.

[RFC5893]Alvestrand，H.，Ed.和C.Karp，“应用程序国际化域名（IDNA）的从右到左脚本”，RFC 5893，DOI 10.17487/RFC5893，2010年8月<http://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, <http://www.rfc-editor.org/info/rfc6365>.

[RFC6365]Hoffman，P.和J.Klensin，“IETF国际化中使用的术语”，BCP 166，RFC 6365，DOI 10.17487/RFC6365，2011年9月<http://www.rfc-editor.org/info/rfc6365>.

[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>.

[Unicode] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.

[Unicode]Unicode联盟，“Unicode标准”<http://www.unicode.org/versions/latest/>.

[Unicode7.0] The Unicode Consortium, "The Unicode Standard, Version 7.0.0", 2014, <http://www.unicode.org/versions/Unicode7.0.0/>.

[Unicode 7.0]Unicode联盟，“Unicode标准，7.0.0版”，2014年<http://www.unicode.org/versions/Unicode7.0.0/>.

[UTS39] The Unicode Consortium, "Unicode Technical Standard #39: Unicode Security Mechanisms", November 2013, <http://unicode.org/reports/tr39/>.

[UTS39]Unicode联盟，“Unicode技术标准#39：Unicode安全机制”，2013年11月<http://unicode.org/reports/tr39/>.

7.2. Informative References

7.2. 资料性引用

[PETNAME-SYSTEMS] Stiegler, M., "An Introduction to Petname Systems", updated June 2012, February 2005, <http://www.skyhunter.com/marcs/petnames/ IntroPetNames.html>.

[PETNAME-SYSTEMS]Stiegler，M.，“PETNAME系统简介”，2012年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, <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>.

[RFC2811] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, DOI 10.17487/RFC2811, April 2000, <http://www.rfc-editor.org/info/rfc2811>.

[RFC2811]Kalt，C.，“互联网中继聊天：频道管理”，RFC 2811，DOI 10.17487/RFC2811，2000年4月<http://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, <http://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月<http://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, <http://www.rfc-editor.org/info/rfc5239>.

[RFC5239]Barnes，M.，Boulton，C.，和O.Levin，“集中会议的框架”，RFC 5239，DOI 10.17487/RFC5239，2008年6月<http://www.rfc-editor.org/info/rfc5239>.

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.

[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<http://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, <http://www.rfc-editor.org/info/rfc6120>.

[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC 6120，DOI 10.17487/RFC6120，2011年3月<http://www.rfc-editor.org/info/rfc6120>.

[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, <http://www.rfc-editor.org/info/rfc7701>.

[RFC7701]Niemi，A.，Garcia Martin，M.，和G.Sandbakken，“使用消息会话中继协议（MSRP）的多方聊天”，RFC 7701，DOI 10.17487/RFC7701，2015年12月<http://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, February 2012, <http://xmpp.org/extensions/xep-0045.html>.

[XEP-0045]圣安德烈，P.，“多用户聊天”，XSF XEP 00452012年2月<http://xmpp.org/extensions/xep-0045.html>.

[XEP-0172] Saint-Andre, P. and V. Mercier, "User Nickname", XSF XEP 0172, March 2012, <http://xmpp.org/extensions/xep-0172.html>.

[XEP-0172]Saint Andre，P.和V.Mercier，“用户昵称”，XSF XEP 0172，2012年3月<http://xmpp.org/extensions/xep-0172.html>.

Acknowledgements

致谢

Thanks to Kim Alvefur, Mary Barnes, Ben Campbell, Dave Cridland, Miguel Garcia, Salvatore Loreto, Enrico Marocco, Matt Miller, and Yoshiro YONEYA for their reviews and comments.

感谢Kim Alvefur、Mary Barnes、Ben Campbell、Dave Cridland、Miguel Garcia、Salvatore Loreto、Enrico Marocco、Matt Miller和Yoshiro YONEYA的评论和评论。

Paul Kyzivat and Melinda Shore reviewed the document for the General Area Review Team and Operations Directorate, respectively.

Paul Kyzivat和Melinda Shore分别为一般区域审查小组和运营董事会审查了该文件。

During IESG review, Ben Campbell and Kathleen Moriarty provided comments that led to further improvements.

在IESG审查期间，Ben Campbell和Kathleen Moriarty提供了意见，这些意见导致了进一步的改进。

Thanks to Matt Miller as Document Shepherd, Pete Resnick and Andrew Sullivan as IANA Designated Experts, Marc Blanchet and Alexey Melnikov as working group Chairs, and Barry Leiba as Area Director.

多亏马特·米勒（Matt Miller）担任文件管理员，皮特·雷斯尼克（Pete Resnick）和安德鲁·沙利文（Andrew Sullivan）担任IANA指定专家，马克·布兰切特（Marc Blanchet）和亚历克赛·梅尔尼科夫（Alexey Melnikov）担任工作组主席，巴里·莱巴（Barry Leiba）担任区域主任。

The author wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier draft versions of this document.

作者希望感谢Cisco Systems，Inc.在编写本文件早期草稿期间雇用了他。

Author's Address

作者地址

Peter Saint-Andre &yet

彼得·圣安德烈&还没有

   Email: peter@andyet.com
   URI:   https://andyet.com/

   Email: peter@andyet.com
   URI:   https://andyet.com/