Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7613 &yet
Obsoletes: 4013 A. Melnikov
Category: Standards Track Isode Ltd
ISSN: 2070-1721 August 2015
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7613 &yet
Obsoletes: 4013 A. Melnikov
Category: Standards Track Isode Ltd
ISSN: 2070-1721 August 2015
Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
表示用户名和密码的国际化字符串的准备、实施和比较
Abstract
摘要
This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The preparation, enforcement, and comparison of internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC 3454, and this document obsoletes RFC 4013.
本文档描述了处理表示用户名和密码的Unicode字符串的更新方法。之前的方法称为SASLprep（RFC 4013），基于stringprep（RFC 3454）。本文档中指定的方法为处理国际化用户名和密码提供了一种更可持续的方法。国际化字符串（PRECIS）框架、RFC 7564、废弃RFC 3454的编制、实施和比较，以及本文件废弃RFC 4013。
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/rfc7613.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7613.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Usernames .......................................................6
3.1. Definition .................................................6
3.2. UsernameCaseMapped Profile .................................7
3.2.1. Preparation .........................................7
3.2.2. Enforcement .........................................7
3.2.3. Comparison ..........................................8
3.3. UsernameCasePreserved Profile ..............................8
3.3.1. Preparation .........................................8
3.3.2. Enforcement .........................................8
3.3.3. Comparison ..........................................9
3.4. Case Mapping vs. Case Preservation .........................9
3.5. Application-Layer Constructs ..............................10
3.6. Examples ..................................................11
4. Passwords ......................................................13
4.1. Definition ................................................13
4.2. OpaqueString Profile ......................................14
4.2.1. Preparation ........................................14
4.2.2. Enforcement ........................................14
4.2.3. Comparison .........................................15
4.3. Examples ..................................................15
5. Use in Application Protocols ...................................16
6. Migration ......................................................16
6.1. Usernames .................................................17
6.2. Passwords .................................................18
7. IANA Considerations ............................................19
7.1. UsernameCaseMapped Profile ................................19
7.2. UsernameCasePreserved Profile .............................20
7.3. OpaqueString Profile ......................................20
7.4. Stringprep Profile ........................................21
8. Security Considerations ........................................21
8.1. Password/Passphrase Strength ..............................21
8.2. Identifier Comparison .....................................21
8.3. Reuse of PRECIS ...........................................21
8.4. Reuse of Unicode ..........................................22
9. References .....................................................22
9.1. Normative References ......................................22
9.2. Informative References ....................................23
Appendix A. Differences from RFC 4013 .............................26
Acknowledgements ..................................................27
Authors' Addresses ................................................27
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Usernames .......................................................6
3.1. Definition .................................................6
3.2. UsernameCaseMapped Profile .................................7
3.2.1. Preparation .........................................7
3.2.2. Enforcement .........................................7
3.2.3. Comparison ..........................................8
3.3. UsernameCasePreserved Profile ..............................8
3.3.1. Preparation .........................................8
3.3.2. Enforcement .........................................8
3.3.3. Comparison ..........................................9
3.4. Case Mapping vs. Case Preservation .........................9
3.5. Application-Layer Constructs ..............................10
3.6. Examples ..................................................11
4. Passwords ......................................................13
4.1. Definition ................................................13
4.2. OpaqueString Profile ......................................14
4.2.1. Preparation ........................................14
4.2.2. Enforcement ........................................14
4.2.3. Comparison .........................................15
4.3. Examples ..................................................15
5. Use in Application Protocols ...................................16
6. Migration ......................................................16
6.1. Usernames .................................................17
6.2. Passwords .................................................18
7. IANA Considerations ............................................19
7.1. UsernameCaseMapped Profile ................................19
7.2. UsernameCasePreserved Profile .............................20
7.3. OpaqueString Profile ......................................20
7.4. Stringprep Profile ........................................21
8. Security Considerations ........................................21
8.1. Password/Passphrase Strength ..............................21
8.2. Identifier Comparison .....................................21
8.3. Reuse of PRECIS ...........................................21
8.4. Reuse of Unicode ..........................................22
9. References .....................................................22
9.1. Normative References ......................................22
9.2. Informative References ....................................23
Appendix A. Differences from RFC 4013 .............................26
Acknowledgements ..................................................27
Authors' Addresses ................................................27
Usernames and passwords are widely used for authentication and authorization on the Internet, either directly when provided in plaintext (as in the PLAIN Simple Authentication and Security Layer (SASL) mechanism [RFC4616] and the HTTP Basic scheme [HTTP-BASIC-AUTH]) or indirectly when provided as the input to a cryptographic algorithm such as a hash function (as in the Salted Challenge Response Authentication Mechanism (SCRAM) SASL mechanism [RFC5802] and the HTTP Digest scheme [HTTP-DIGEST-AUTH]).
用户名和密码被广泛用于互联网上的身份验证和授权，或者直接以明文形式提供（如普通简单身份验证和安全层（SASL）机制[RFC4616]和HTTP基本方案[HTTP-Basic-AUTH]）或者，当作为诸如散列函数之类的加密算法的输入提供时（如在Salted质询-响应认证机制（SCRAM）SASL机制[RFC5802]和HTTP摘要方案[HTTP-Digest-AUTH]中）间接地。
To increase the likelihood that the input and comparison of usernames and passwords will work in ways that make sense for typical users throughout the world, this document defines rules for preparing, enforcing, and comparing internationalized strings that represent usernames and passwords. Such strings consist of characters from the Unicode character set [Unicode], with special attention to characters outside the ASCII range [RFC20]. The rules for handling such strings are specified through profiles of the string classes defined in the preparation, enforcement, and comparison of internationalized strings (PRECIS) framework specification [RFC7564].
为了提高用户名和密码的输入和比较对全世界典型用户有意义的可能性，本文档定义了用于准备、执行和比较代表用户名和密码的国际化字符串的规则。此类字符串由Unicode字符集[Unicode]中的字符组成，特别注意ASCII范围[RFC20]之外的字符。处理此类字符串的规则是通过准备、实施和比较国际化字符串（PRECIS）框架规范[RFC7564]中定义的字符串类概要文件指定的。
Profiles of the PRECIS framework enable software to handle Unicode characters outside the ASCII range in an automated way, so that such characters are treated carefully and consistently in application protocols. In large measure, these profiles are designed to protect application developers from the potentially negative consequences of supporting the full range of Unicode characters. For instance, in almost all application protocols it would be dangerous to treat the Unicode character SUPERSCRIPT ONE (U+00B9) as equivalent to DIGIT ONE (U+0031), because that would result in false positives during comparison, authentication, and authorization (e.g., an attacker could easy spoof an account "user1@example.com").
PRECIS框架的配置文件使软件能够以自动化的方式处理ASCII范围之外的Unicode字符，以便在应用程序协议中谨慎一致地处理这些字符。在很大程度上，这些配置文件旨在保护应用程序开发人员免受支持所有Unicode字符的潜在负面影响。例如，在几乎所有的应用程序协议中，将Unicode字符上标1（U+00B9）视为等同于数字1（U+0031）是危险的，因为这将导致在比较、身份验证和授权过程中出现误报（例如，攻击者可能很容易伪造帐户）user1@example.com").
Whereas a naive use of Unicode would make such attacks trivially easy, the PRECIS profile defined here for usernames generally protects applications from inadvertently causing such problems. (Similar considerations apply to passwords, although here it is desirable to support a wider range of characters so as to maximize entropy for purposes of authentication.)
虽然简单地使用Unicode会使此类攻击变得非常容易，但此处为用户名定义的PRECIS配置文件通常会保护应用程序免受无意中造成此类问题的影响。（类似的注意事项也适用于密码，尽管此处需要支持更大范围的字符，以便最大限度地利用熵进行身份验证。）
The methods defined here might be applicable wherever usernames or passwords are used. However, the methods are not intended for use in preparing strings that are not usernames (e.g., Lightweight Directory Access Protocol (LDAP) distinguished names), nor in cases where identifiers or secrets are not strings (e.g., keys and certificates) or require specialized handling.
这里定义的方法可能适用于使用用户名或密码的任何地方。但是，这些方法不用于准备非用户名的字符串（例如，轻量级目录访问协议（LDAP）可分辨名称），也不用于标识符或机密不是字符串（例如，密钥和证书）或需要专门处理的情况。
This document obsoletes RFC 4013 (the SASLprep profile of stringprep [RFC3454]) but can be used by technologies other than SASL [RFC4422], such as HTTP authentication as specified in [HTTP-BASIC-AUTH] and [HTTP-DIGEST-AUTH].
本文档淘汰了RFC 4013（stringprep[RFC3454]的SASLprep配置文件），但可由SASL[RFC4422]以外的技术使用，如[HTTP-BASIC-AUTH]和[HTTP-DIGEST-AUTH]中规定的HTTP身份验证。
This document does not modify the handling of internationalized strings in usernames and passwords as prescribed by existing application protocols that use SASLprep. If the community that uses such an application protocol wishes to modernize its handling of internationalized strings to use PRECIS instead of stringprep, it needs to explicitly update the existing application protocol definition (one example is [XMPP-ADDR], which is intended to obsolete [RFC6122]). Non-coordinated updates to protocol implementations are discouraged because they can have a negative impact on interoperability and security.
本文档不会按照使用SASLprep的现有应用程序协议的规定修改用户名和密码中国际化字符串的处理。如果使用此类应用程序协议的社区希望现代化其对国际化字符串的处理，以使用PRECIS而不是stringprep，则需要显式更新现有的应用程序协议定义（一个示例是[XMPP-ADDR]，其目的是淘汰[RFC6122]）。不鼓励对协议实现进行不协调的更新，因为它们会对互操作性和安全性产生负面影响。
Many important terms used in this document are defined in [RFC5890], [RFC6365], [RFC7564], and [Unicode]. The term "non-ASCII space" refers to any Unicode code point having a Unicode general category of "Zs", with the exception of U+0020 (here called "ASCII space").
本文档中使用的许多重要术语在[RFC5890]、[RFC6365]、[RFC7564]和[Unicode]中定义。术语“非ASCII空间”是指具有Unicode通用类别“Zs”的任何Unicode码点，U+0020除外（此处称为“ASCII空间”）。
As used here, the term "password" is not literally limited to a word; i.e., a password could be a passphrase consisting of more than one word, perhaps separated by spaces, punctuation, or other non-alphanumeric characters.
正如这里所使用的，术语“密码”并不仅仅限于一个单词；i、 例如，密码可以是由多个单词组成的密码短语，可能由空格、标点符号或其他非字母数字字符分隔。
Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify that the authentication identity used in the context of such mechanisms is a "simple user name" (see Section 2 of [RFC4422] as well as [RFC4013]). Various application technologies also assume that the identity of a user or account takes the form of a username (e.g., authentication for the Hypertext Transfer Protocol as specified in [HTTP-BASIC-AUTH] and [HTTP-DIGEST-AUTH]), whether or not they use SASL. Note well that the exact form of a username in any particular SASL mechanism or application technology is a matter for implementation and deployment, and that a username does not necessarily map to any particular application identifier (such as the localpart of an email address).
一些SASL机制（例如CRAM-MD5、DIGEST-MD5和SCRAM）规定，在此类机制的上下文中使用的身份验证标识是“简单用户名”（参见[RFC4422]第2节以及[RFC4013]）。各种应用程序技术还假定用户或帐户的身份采用用户名的形式（例如，[HTTP-BASIC-AUTH]和[HTTP-DIGEST-AUTH]中指定的超文本传输协议的身份验证），无论它们是否使用SASL。请注意，在任何特定SASL机制或应用程序技术中，用户名的确切形式取决于实现和部署，并且用户名不一定映射到任何特定的应用程序标识符（例如电子邮件地址的localpart）。
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]中的说明进行解释。
This document specifies that a username is a string of Unicode code points [Unicode], encoded using UTF-8 [RFC3629], and structured as an ordered sequence of "userparts". A userpart is allowed to contain only code points that are in turn allowed by the PRECIS IdentifierClass defined in Section 4.2 of [RFC7564], and thus consists almost exclusively of letters and digits. A username can consist of a single userpart or a space-separated sequence of userparts.
本文档规定用户名是一个Unicode码点字符串[Unicode]，使用UTF-8[RFC3629]编码，并按“用户部分”的有序序列进行结构。用户部件只允许包含[RFC7564]第4.2节中定义的PRECIS IdentifierClass所允许的代码点，因此几乎完全由字母和数字组成。用户名可以由单个用户部分或以空格分隔的用户部分序列组成。
The syntax for a username is defined as follows, using the Augmented Backus-Naur Form (ABNF) [RFC5234].
用户名的语法定义如下，使用扩展的Backus Naur表单（ABNF）[RFC5234]。
username = userpart *(1*SP userpart)
userpart = 1*(idbyte)
;
; an "idbyte" is a byte used to represent a
; UTF-8 encoded Unicode code point that can be
; contained in a string that conforms to the
; PRECIS IdentifierClass
;
username = userpart *(1*SP userpart)
userpart = 1*(idbyte)
;
; an "idbyte" is a byte used to represent a
; UTF-8 encoded Unicode code point that can be
; contained in a string that conforms to the
; PRECIS IdentifierClass
;
All code points and blocks not explicitly allowed in the PRECIS IdentifierClass are disallowed; this includes private use characters, surrogate code points, and the other code points and blocks that were defined as "Prohibited Output" in [RFC4013]. In addition, common constructions such as "user@example.com" (e.g., the Network Access Identifier from [RFC7542]) are allowed as usernames under this specification, as they were under [RFC4013].
不允许PRECIS IdentifierClass中未明确允许的所有代码点和代码块；这包括专用字符、代理代码点以及[RFC4013]中定义为“禁止输出”的其他代码点和块。此外，常见的结构，如“user@example.com“（例如，[RFC7542]中的网络访问标识符）与[RFC4013]中的用户名一样，可以作为本规范中的用户名。
Implementation Note: The username construct defined in this document does not necessarily match what all deployed applications might refer to as a "username" or "userid" but instead provides a relatively safe subset of Unicode characters that can be used in existing SASL mechanisms and in application protocols that use SASL, and even in most application protocols that do not currently use SASL.
实施说明：本文档中定义的用户名结构不一定与所有部署的应用程序所称的“用户名”或“用户ID”匹配，而是提供了一个相对安全的Unicode字符子集，可在现有SASL机制和使用SASL的应用程序协议中使用，甚至在目前不使用SASL的大多数应用程序协议中。
A username MUST NOT be zero bytes in length. This rule is to be enforced after any normalization and mapping of code points.
用户名的长度不得为零字节。此规则将在代码点的任何规范化和映射之后强制执行。
In protocols that provide usernames as input to a cryptographic algorithm such as a hash function, the client will need to perform enforcement of the rules for the UsernameCaseMapped or UsernameCasePreserved profile before applying the algorithm.
在提供用户名作为加密算法（如哈希函数）输入的协议中，客户端需要在应用算法之前执行UsernameCaseMapped或UsernameCaseServered配置文件的规则。
This specification defines two profiles for usernames: one that performs case mapping and one that performs case preservation (see further discussion under Section 3.4).
本规范为用户名定义了两个配置文件：一个用于执行案例映射，另一个用于执行案例保存（请参阅第3.4节下的进一步讨论）。
The definition of the UsernameCaseMapped profile of the IdentifierClass is provided in the following sections, including detailed information about preparation, enforcement, and comparison (for details on the distinction between these actions, refer to [RFC7564]).
以下章节提供了IdentifierClass的UsernameCaseMapped配置文件的定义，包括有关准备、实施和比较的详细信息（有关这些操作之间区别的详细信息，请参阅[RFC7564]）。
An entity that prepares a string according to this profile MUST first map fullwidth and halfwidth characters to their decomposition mappings (see Unicode Standard Annex #11 [UAX11]). This is necessary because the PRECIS "HasCompat" category specified in Section 9.17 of [RFC7564] would otherwise forbid fullwidth and halfwidth characters. After applying this width-mapping rule, the entity then MUST ensure that the string consists only of Unicode code points that conform to the PRECIS IdentifierClass defined in Section 4.2 of [RFC7564]. In addition, the entity then MUST encode the string as UTF-8 [RFC3629].
根据此配置文件准备字符串的实体必须首先将全宽和半宽字符映射到其分解映射（请参见Unicode标准附录11[UAX11]）。这是必要的，因为[RFC7564]第9.17节中规定的PRECIS“HasCompat”类别将禁止全宽和半宽字符。应用此宽度映射规则后，实体必须确保字符串仅由符合[RFC7564]第4.2节中定义的PRECIS IdentifierClass的Unicode代码点组成。此外，实体必须将字符串编码为UTF-8[RFC3629]。
An entity that performs enforcement according to this profile MUST prepare a string as described in Section 3.2.1 and MUST also apply the rules specified below for the UsernameCaseMapped profile (these rules MUST be applied in the order shown):
根据此配置文件执行强制的实体必须按照第3.2.1节所述准备字符串，并且还必须为UsernameCaseMapped配置文件应用以下指定的规则（这些规则必须按照所示顺序应用）：
1. Width-Mapping Rule: Applied as part of preparation (see above).
1. 宽度映射规则：作为准备的一部分应用（见上文）。
2. Additional Mapping Rule: There is no additional mapping rule.
2. 其他映射规则：没有其他映射规则。
3. Case-Mapping Rule: Uppercase and titlecase characters MUST be mapped to their lowercase equivalents, preferably using Unicode Default Case Folding as defined in the Unicode Standard [Unicode] (at the time of this writing, the algorithm is specified in Chapter 3 of [Unicode7.0], but the chapter number might change in a future version of the Unicode Standard); see further discussion in Section 3.4.
3. 大小写映射规则：必须将大写和titlecase字符映射为其小写等效字符，最好使用Unicode标准[Unicode]中定义的Unicode默认大小写折叠（撰写本文时，算法在[Unicode7.0]的第3章中指定），但在未来版本的Unicode标准中，章节号可能会更改）；见第3.4节的进一步讨论。
4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be applied to all characters.
4. 规范化规则：Unicode规范化表单C（NFC）必须应用于所有字符。
5. Directionality Rule: Applications MUST apply the "Bidi Rule" defined in [RFC5893] to strings that contain right-to-left characters (i.e., each of the six conditions of the Bidi Rule must be satisfied).
5. 方向性规则：应用程序必须将[RFC5893]中定义的“Bidi规则”应用于包含从右到左字符的字符串（即，必须满足Bidi规则的六个条件中的每一个）。
An entity that performs comparison of two strings according to this profile MUST prepare each string as specified in Section 3.2.1 and then enforce the rules specified in Section 3.2.2. The two strings are to be considered equivalent if they are an exact octet-for-octet match (sometimes called "bit-string identity").
根据本概要文件对两个字符串进行比较的实体必须按照第3.2.1节的规定准备每个字符串，然后执行第3.2.2节规定的规则。如果这两个字符串是八位字节匹配的精确八位字节（有时称为“位字符串标识”），则认为它们是等效的。
The definition of the UsernameCasePreserved profile of the IdentifierClass is provided in the following sections, including detailed information about preparation, enforcement, and comparison (for details on the distinction between these actions, refer to [RFC7564]).
以下章节提供了IdentifierClass的UsernameCasePreserved配置文件的定义，包括有关准备、实施和比较的详细信息（有关这些操作之间的区别的详细信息，请参阅[RFC7564]）。
An entity that prepares a string according to this profile MUST first map fullwidth and halfwidth characters to their decomposition mappings (see Unicode Standard Annex #11 [UAX11]). This is necessary because the PRECIS "HasCompat" category specified in Section 9.17 of [RFC7564] would otherwise forbid fullwidth and halfwidth characters. After applying this width-mapping rule, the entity then MUST ensure that the string consists only of Unicode code points that conform to the PRECIS IdentifierClass defined in Section 4.2 of [RFC7564]. In addition, the entity then MUST encode the string as UTF-8 [RFC3629].
根据此配置文件准备字符串的实体必须首先将全宽和半宽字符映射到其分解映射（请参见Unicode标准附录11[UAX11]）。这是必要的，因为[RFC7564]第9.17节中规定的PRECIS“HasCompat”类别将禁止全宽和半宽字符。应用此宽度映射规则后，实体必须确保字符串仅由符合[RFC7564]第4.2节中定义的PRECIS IdentifierClass的Unicode代码点组成。此外，实体必须将字符串编码为UTF-8[RFC3629]。
An entity that performs enforcement according to this profile MUST prepare a string as described in Section 3.3.1 and MUST also apply the rules specified below for the UsernameCasePreserved profile (these rules MUST be applied in the order shown):
根据此配置文件执行强制的实体必须按照第3.3.1节所述准备字符串，并且还必须为UsernameCasePreserved配置文件应用以下指定的规则（这些规则必须按照显示的顺序应用）：
1. Width-Mapping Rule: Applied as part of preparation (see above).
1. 宽度映射规则：作为准备的一部分应用（见上文）。
2. Additional Mapping Rule: There is no additional mapping rule.
2. 其他映射规则：没有其他映射规则。
3. Case-Mapping Rule: Uppercase and titlecase characters MUST NOT be mapped to their lowercase equivalents; see further discussion in Section 3.4.
3. 大小写映射规则：大写和titlecase字符不能映射到其对应的小写字符；见第3.4节的进一步讨论。
4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be applied to all characters.
4. 规范化规则：Unicode规范化表单C（NFC）必须应用于所有字符。
5. Directionality Rule: Applications MUST apply the "Bidi Rule" defined in [RFC5893] to strings that contain right-to-left characters (i.e., each of the six conditions of the Bidi Rule must be satisfied).
5. 方向性规则：应用程序必须将[RFC5893]中定义的“Bidi规则”应用于包含从右到左字符的字符串（即，必须满足Bidi规则的六个条件中的每一个）。
An entity that performs comparison of two strings according to this profile MUST prepare each string as specified in Section 3.3.1 and then enforce the rules specified in Section 3.3.2. The two strings are to be considered equivalent if they are an exact octet-for-octet match (sometimes called "bit-string identity").
根据本概要文件对两个字符串进行比较的实体必须按照第3.3.1节的规定准备每个字符串，然后执行第3.3.2节的规定。如果这两个字符串是八位字节匹配的精确八位字节（有时称为“位字符串标识”），则认为它们是等效的。
In order to accommodate the widest range of username constructs in applications, this document defines two username profiles: UsernameCaseMapped and UsernameCasePreserved. These two profiles differ only in the Case-Mapping Rule and are otherwise identical.
为了适应应用程序中最广泛的用户名构造，本文档定义了两个用户名配置文件：UsernameCaseMapped和UsernameCasePreserved。这两个配置文件仅在案例映射规则上不同，在其他方面相同。
Case mapping is a matter for the application protocol, protocol implementation, or end deployment. In general, this document suggests that it is preferable to apply the UsernameCaseMapped profile and therefore perform case mapping, because not doing so can lead to false positives during authentication and authorization (as described in [RFC6943]) and can result in confusion among end users, given the prevalence of case mapping in many existing protocols and applications. However, there can be good reasons to apply the UsernameCasePreserved profile and thus not perform case mapping, such as backward compatibility with deployed infrastructure.
案例映射是应用程序协议、协议实现或最终部署的问题。一般来说，本文件建议最好应用UsernameCaseMapped概要文件，并因此执行案例映射，因为不这样做可能会导致身份验证和授权期间出现误报（如[RFC6943]所述），并可能导致最终用户之间的混淆，考虑到案例映射在许多现有协议和应用程序中的普遍性。但是，应用UsernameCasePreserved概要文件并因此不执行案例映射可能有很好的理由，例如与已部署的基础结构的向后兼容性。
In particular:
特别地：
o SASL mechanisms that follow the recommendations in this document MUST specify whether and when case mapping is to be applied to authentication identifiers. SASL mechanisms SHOULD delay any case mapping to the last possible moment, such as when doing a lookup by username, performing username comparisons, or generating a cryptographic salt from a username (if the last possible moment happens on the server, then decisions about case mapping can be a matter of deployment policy). In keeping with [RFC4422], SASL mechanisms are not to apply this or any other profile to authorization identifiers, only to authentication identifiers.
o 遵循本文档中建议的SASL机制必须指定是否以及何时将案例映射应用于身份验证标识符。SASL机制应该将任何案例映射延迟到最后一个可能的时刻，例如按用户名进行查找、执行用户名比较或从用户名生成加密salt时（如果最后一个可能的时刻发生在服务器上，那么关于案例映射的决定可能是部署策略的问题）。根据[RFC4422]，SASL机制不将此配置文件或任何其他配置文件应用于授权标识符，而仅应用于身份验证标识符。
o Application protocols that use SASL (such as IMAP [RFC3501] and the Extensible Messaging and Presence Protocol (XMPP) [RFC6120]) and that directly reuse this profile MUST specify whether or not case mapping is to be applied to authorization identifiers. Such "SASL application protocols" SHOULD delay any case-mapping of authorization identifiers to the last possible moment, which happens to necessarily be on the server side (this enables decisions about case mapping to be a matter of deployment policy). In keeping with [RFC4422], SASL application protocols are not to apply this or any other profile to authentication identifiers, only to authorization identifiers.
o 使用SASL的应用程序协议（如IMAP[RFC3501]和可扩展消息和状态协议（XMPP）[RFC6120]）以及直接重用此配置文件的应用程序协议必须指定是否将案例映射应用于授权标识符。这样的“SASL应用程序协议”应该将授权标识符的任何案例映射延迟到最后一个可能的时刻，而这恰好发生在服务器端（这使得关于案例映射的决策成为部署策略的问题）。与[RFC4422]保持一致，SASL应用程序协议不将此配置文件或任何其他配置文件应用于身份验证标识符，仅应用于授权标识符。
o Application protocols that do not use SASL (such as HTTP authentication with the HTTP Basic and Digest schemes as specified in [HTTP-BASIC-AUTH] and [HTTP-DIGEST-AUTH]) but that directly reuse this profile MUST specify whether and when case mapping is to be applied to authentication identifiers or authorization identifiers, or both. Such "non-SASL application protocols" SHOULD delay any case mapping to the last possible moment, such as when doing a lookup by username, performing username comparisons, or generating a cryptographic salt from a username (if the last possible moment happens on the server, then decisions about case mapping can be a matter of deployment policy).
o 不使用SASL的应用程序协议（如[HTTP-Basic-AUTH]和[HTTP-Digest-AUTH]中指定的HTTP Basic和Digest方案的HTTP身份验证），但直接重用此配置文件的应用程序协议必须指定是否以及何时将案例映射应用于身份验证标识符或授权标识符，或两者。此类“非SASL应用程序协议”应将任何案例映射延迟到最后一个可能的时刻，例如按用户名进行查找、执行用户名比较或从用户名生成加密salt时（如果最后一个可能的时刻发生在服务器上，那么关于案例映射的决定可能是部署策略的问题）。
If the specification for a SASL mechanism, SASL application protocol, or non-SASL application protocol uses the UsernameCaseMapped profile, it MUST clearly describe whether case mapping is to be applied at the level of the protocol itself, implementations thereof, or service deployments (each of these approaches can be legitimate, depending on the application in question).
如果SASL机制、SASL应用程序协议或非SASL应用程序协议的规范使用UsernameCaseMapped概要文件，则必须明确说明是否在协议本身、其实现或服务部署级别应用案例映射（这些方法中的每一种都可能是合法的，具体取决于所讨论的应用）。
Both the UsernameCaseMapped and UsernameCasePreserved profiles enable an application protocol, implementation, or deployment to create application-layer constructs such as a username that is a space-separated set of userparts like "Firstname Middlename Lastname". Although such a construct is not a profile of the PRECIS IdentifierClass (because U+0020 SPACE is not allowed in the IdentifierClass), it can be created at the application layer because U+0020 SPACE can be used as a separator between instances of the PRECIS IdentifierClass (e.g., userparts as defined in this specification).
UsernameCaseMapped和UsernameCasePreserved配置文件都支持应用程序协议、实现或部署来创建应用程序层结构，例如用户名，它是一组以空格分隔的用户名，如“Firstname Middlename Lastname”。尽管这种构造不是PRECIS IdentifierClass的配置文件（因为IdentifierClass中不允许使用U+0020空间），但它可以在应用层创建，因为U+0020空间可以用作PRECIS IdentifierClass实例之间的分隔符（例如，本规范中定义的用户部件）。
The following examples illustrate a small number of userparts (not usernames) that are consistent with the format defined above (note that the characters "<" and ">" are used here to delineate the actual userparts and are not part of the userpart strings).
以下示例说明了与上面定义的格式一致的少量用户部件（不是用户名）（请注意，此处使用“<”和“>”字符来描述实际用户部件，而不是用户部件字符串的一部分）。
+--------------------------+---------------------------------+
| # | Userpart | Notes |
+--------------------------+---------------------------------+
| 1 | <juliet@example.com> | The at-sign is allowed in the |
| | | PRECIS IdentifierClass |
+--------------------------+---------------------------------+
| 2 | <fussball> | |
+--------------------------+---------------------------------+
| 3 | <fußball> | The third character is LATIN |
| | | SMALL LETTER SHARP S (U+00DF) |
+--------------------------+---------------------------------+
| 4 | <π> | A userpart of GREEK SMALL |
| | | LETTER PI (U+03C0) |
+--------------------------+---------------------------------+
| 5 | <Σ> | A userpart of GREEK CAPITAL |
| | | LETTER SIGMA (U+03A3) |
+--------------------------+---------------------------------+
| 6 | <σ> | A userpart of GREEK SMALL |
| | | LETTER SIGMA (U+03C3) |
+--------------------------+---------------------------------+
| 7 | <ς> | A userpart of GREEK SMALL |
| | | LETTER FINAL SIGMA (U+03C2) |
+--------------------------+---------------------------------+
+--------------------------+---------------------------------+
| # | Userpart | Notes |
+--------------------------+---------------------------------+
| 1 | <juliet@example.com> | The at-sign is allowed in the |
| | | PRECIS IdentifierClass |
+--------------------------+---------------------------------+
| 2 | <fussball> | |
+--------------------------+---------------------------------+
| 3 | <fußball> | The third character is LATIN |
| | | SMALL LETTER SHARP S (U+00DF) |
+--------------------------+---------------------------------+
| 4 | <π> | A userpart of GREEK SMALL |
| | | LETTER PI (U+03C0) |
+--------------------------+---------------------------------+
| 5 | <Σ> | A userpart of GREEK CAPITAL |
| | | LETTER SIGMA (U+03A3) |
+--------------------------+---------------------------------+
| 6 | <σ> | A userpart of GREEK SMALL |
| | | LETTER SIGMA (U+03C3) |
+--------------------------+---------------------------------+
| 7 | <ς> | A userpart of GREEK SMALL |
| | | LETTER FINAL SIGMA (U+03C2) |
+--------------------------+---------------------------------+
Table 1: A Sample of Legal Userparts
表1：合法用户部件示例
Several points are worth noting. Regarding examples 2 and 3: although in German the character eszett (LATIN SMALL LETTER SHARP S (U+00DF)) can mostly be used interchangeably with the two characters "ss", the userparts in these examples are different and (if desired) a server would need to enforce a registration policy that disallows one of them if the other is registered. Regarding examples 5, 6, and 7: optional case-mapping of GREEK CAPITAL LETTER SIGMA (U+03A3) to lowercase (i.e., to GREEK SMALL LETTER SIGMA (U+03C3)) during comparison would result in matching the userparts in examples 5 and 6; however, because the PRECIS mapping rules do not account for the special status of GREEK SMALL LETTER FINAL SIGMA (U+03C2), the userparts in examples 5 and 7 or examples 6 and 7 would not be matched during comparison.
有几点值得注意。关于示例2和3：虽然在德语中，字符eszett（拉丁小写字母SHARP S（U+00DF））大部分可以与两个字符“ss”互换使用，但这些示例中的用户部分是不同的，并且（如果需要）服务器需要强制执行一个注册策略，如果其中一个已注册，则不允许其中一个。关于示例5、6和7：在比较期间，希腊大写字母SIGMA（U+03A3）到小写字母（即，到希腊小写字母SIGMA（U+03C3））的可选大小写映射将导致匹配示例5和6中的用户部分；然而，由于PRECIS映射规则没有考虑希腊小写字母FINAL SIGMA（U+03C2）的特殊状态，因此在比较过程中，示例5和7或示例6和7中的用户部分将不匹配。
The following examples illustrate strings that are not valid userparts (not usernames) because they violate the format defined above.
以下示例说明了无效的用户名（而非用户名）字符串，因为它们违反了上面定义的格式。
+--------------------------+---------------------------------+
| # | Non-Userpart String | Notes |
+--------------------------+---------------------------------+
| 8 | <foo bar> | Space (U+0020) is disallowed in |
| | | the userpart |
+--------------------------+---------------------------------+
| 9 | <> | Zero-length userpart |
+--------------------------+---------------------------------+
| 10| <henryⅣ> | The sixth character is ROMAN |
| | | NUMERAL FOUR (U+2163) |
+--------------------------+---------------------------------+
| 11| <♚> | A localpart of BLACK CHESS KING |
| | | (U+265A) |
+--------------------------+---------------------------------+
+--------------------------+---------------------------------+
| # | Non-Userpart String | Notes |
+--------------------------+---------------------------------+
| 8 | <foo bar> | Space (U+0020) is disallowed in |
| | | the userpart |
+--------------------------+---------------------------------+
| 9 | <> | Zero-length userpart |
+--------------------------+---------------------------------+
| 10| <henryⅣ> | The sixth character is ROMAN |
| | | NUMERAL FOUR (U+2163) |
+--------------------------+---------------------------------+
| 11| <♚> | A localpart of BLACK CHESS KING |
| | | (U+265A) |
+--------------------------+---------------------------------+
Table 2: A Sample of Strings That Violate the Userpart Rule
表2：违反Userpart规则的字符串示例
Here again, several points are worth noting. Regarding example 8: although this is not a valid userpart, it is a valid username because it is a space-separated sequence of userparts. Regarding example 10: the Unicode character ROMAN NUMERAL FOUR (U+2163) has a compatibility equivalent of the string formed of LATIN CAPITAL LETTER I (U+0049) and LATIN CAPITAL LETTER V (U+0056), but characters with compatibility equivalents are not allowed in the PRECIS IdentifierClass. Regarding example 11: symbol characters such as BLACK CHESS KING (U+265A) are not allowed in the PRECIS IdentifierClass.
在这里，有几点值得注意。关于示例8：尽管这不是一个有效的userpart，但它是一个有效的用户名，因为它是一个以空格分隔的userpart序列。关于示例10：Unicode字符罗马数字4（U+2163）具有与由拉丁大写字母I（U+0049）和拉丁大写字母V（U+0056）构成的字符串的兼容性等价物，但PRECIS IdentifierClass中不允许具有兼容性等价物的字符。关于示例11：PRECIS IdentifierClass中不允许使用黑棋王（U+265A）等符号字符。
This document specifies that a password is a string of Unicode code points [Unicode], encoded using UTF-8 [RFC3629], and conformant to the OpaqueString profile (specified below) of the PRECIS FreeformClass defined in Section 4.3 of [RFC7564].
本文件规定密码为Unicode码点字符串[Unicode]，使用UTF-8[RFC3629]编码，并符合[RFC7564]第4.3节中定义的PRECIS FreeformClass的OpaqueString配置文件（如下所述）。
The syntax for a password is defined as follows, using the Augmented Backus-Naur Form (ABNF) [RFC5234].
密码的语法定义如下，使用扩展的Backus Naur表单（ABNF）[RFC5234]。
password = 1*(freebyte)
;
; a "freebyte" is a byte used to represent a
; UTF-8 encoded Unicode code point that can be
; contained in a string that conforms to the
; PRECIS FreeformClass
;
password = 1*(freebyte)
;
; a "freebyte" is a byte used to represent a
; UTF-8 encoded Unicode code point that can be
; contained in a string that conforms to the
; PRECIS FreeformClass
;
All code points and blocks not explicitly allowed in the PRECIS FreeformClass are disallowed; this includes private use characters, surrogate code points, and the other code points and blocks defined as "Prohibited Output" in Section 2.3 of RFC 4013 (when corrected per [Err1812]).
不允许PRECIS FreeformClass中未明确允许的所有代码点和代码块；这包括专用字符、代理代码点以及RFC 4013第2.3节中定义为“禁止输出”的其他代码点和代码块（根据[Err1812]更正时）。
A password MUST NOT be zero bytes in length. This rule is to be enforced after any normalization and mapping of code points.
密码长度不得为零字节。此规则将在代码点的任何规范化和映射之后强制执行。
Note: Some existing systems allow an empty string in places where a password would be expected (e.g., command-line tools that might be called from an automated script, or servers that might need to be restarted without human intervention). From the perspective of this document (and RFC 4013 before it), these empty strings are not passwords but are workarounds for the practical difficulty of using passwords in certain scenarios. The prohibition of zero-length passwords is not a recommendation regarding password strength (because a password of only one byte is highly insecure) but is meant to prevent applications from mistakenly omitting a password entirely; such an outcome is possible when internationalized characters are accepted, because a non-empty sequence of characters can result in a zero-length password after canonicalization.
注意：一些现有系统允许在需要密码的地方使用空字符串（例如，可能从自动脚本调用的命令行工具，或者可能需要在无需人工干预的情况下重新启动的服务器）。从本文档（以及之前的RFC 4013）的角度来看，这些空字符串不是密码，而是在某些场景中使用密码的实际困难的解决方法。禁止零长度密码不是关于密码强度的建议（因为只有一个字节的密码是高度不安全的），而是为了防止应用程序错误地完全忽略密码；当接受国际化字符时，这样的结果是可能的，因为非空字符序列在规范化后可能导致零长度密码。
In protocols that provide passwords as input to a cryptographic algorithm such as a hash function, the client will need to perform enforcement of the rules for the OpaqueString profile before applying the algorithm, because the password is not available to the server in plaintext form.
在提供密码作为加密算法（如哈希函数）输入的协议中，客户端需要在应用算法之前执行OpaqueString配置文件的规则，因为服务器无法以明文形式使用密码。
The definition of the OpaqueString profile is provided in the following sections, including detailed information about preparation, enforcement, and comparison (for details on the distinction between these actions, refer to [RFC7564]).
以下章节提供了不透明字符串配置文件的定义，包括有关准备、实施和比较的详细信息（有关这些操作之间区别的详细信息，请参阅[RFC7564]）。
An entity that prepares a string according to this profile MUST ensure that the string consists only of Unicode code points that conform to the FreeformClass base string class defined in [RFC7564]. In addition, the entity MUST encode the string as UTF-8 [RFC3629].
根据此配置文件准备字符串的实体必须确保字符串仅包含符合[RFC7564]中定义的FreeformClass基字符串类的Unicode代码点。此外，实体必须将字符串编码为UTF-8[RFC3629]。
An entity that performs enforcement according to this profile MUST prepare a string as described in Section 4.2.1 and MUST also apply the rules specified below for the OpaqueString profile (these rules MUST be applied in the order shown):
根据本概要文件执行强制的实体必须按照第4.2.1节所述准备字符串，并且还必须为OpaqueString概要文件应用以下规定的规则（这些规则必须按照所示顺序应用）：
1. Width-Mapping Rule: Fullwidth and halfwidth characters MUST NOT be mapped to their decomposition mappings (see Unicode Standard Annex #11 [UAX11]).
1. 宽度映射规则：全宽和半宽字符不得映射到其分解映射（请参见Unicode标准附录#11[UAX11]）。
2. Additional Mapping Rule: 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 Unicode general category of "Zs" (with the exception of U+0020).
2. 附加映射规则：非ASCII空间的任何实例都必须映射到ASCII空间（U+0020）；非ASCII空间是具有Unicode通用类别“Zs”（U+0020除外）的任何Unicode代码点。
3. Case-Mapping Rule: Uppercase and titlecase characters MUST NOT be mapped to their lowercase equivalents.
3. 大小写映射规则：大写和titlecase字符不能映射到其对应的小写字符。
4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be applied to all characters.
4. 规范化规则：Unicode规范化表单C（NFC）必须应用于所有字符。
5. Directionality Rule: There is no directionality rule. The "Bidi Rule" (defined in [RFC5893]) and similar rules are unnecessary and inapplicable to passwords, because they can reduce the range of characters that are allowed in a string and therefore reduce the amount of entropy that is possible in a password. Such rules are intended to minimize the possibility that the same string
5. 方向性规则：没有方向性规则。“Bidi规则”（在[RFC5893]中定义）和类似规则是不必要的，不适用于密码，因为它们可以减少字符串中允许的字符范围，从而减少密码中可能出现的熵。此类规则旨在最大限度地减少相同字符串
will be displayed differently on a layout system set for right-to-left display and a layout system set for left-to-right display; however, passwords are typically not displayed at all and are rarely meant to be interoperable across different layout systems in the way that non-secret strings like domain names and usernames are. Furthermore, it is perfectly acceptable for opaque strings other than passwords to be presented differently in different layout systems, as long as the presentation is consistent in any given layout system.
将在设置为从右到左显示的布局系统和设置为从左到右显示的布局系统上以不同方式显示；但是，密码通常根本不显示，也很少像域名和用户名等非机密字符串那样在不同的布局系统之间进行互操作。此外，密码以外的不透明字符串在不同的布局系统中以不同的方式呈现是完全可以接受的，只要呈现在任何给定的布局系统中是一致的。
An entity that performs comparison of two strings according to this profile MUST prepare each string as specified in Section 4.2.1 and then enforce the rules specified in Section 4.2.2. The two strings are to be considered equivalent if they are an exact octet-for-octet match (sometimes called "bit-string identity").
根据本概要文件对两个字符串进行比较的实体必须按照第4.2.1节的规定准备每个字符串，然后执行第4.2.2节的规定。如果这两个字符串是八位字节匹配的精确八位字节（有时称为“位字符串标识”），则认为它们是等效的。
The following examples illustrate a small number of passwords that are consistent with the format defined above (note that the characters "<" and ">" are used here to delineate the actual passwords and are not part of the password strings).
以下示例说明了与上述格式一致的少量密码（请注意，此处使用“<”和“>”字符来描述实际密码，而不是密码字符串的一部分）。
+------------------------------------+------------------------------+
| # | Password | Notes |
+------------------------------------+------------------------------+
| 12| <correct horse battery staple> | ASCII space is allowed |
+------------------------------------+------------------------------+
| 13| <Correct Horse Battery Staple> | Differs by case 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> | Differs by case 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> |
+------------------------------------+------------------------------+
Table 3: A Sample of Legal Passwords
表3：合法密码示例
The following example illustrates a string that is not a valid password because it violates the format defined above.
以下示例演示了一个字符串，该字符串不是有效密码，因为它违反了上面定义的格式。
+------------------------------------+------------------------------+
| # | Password | Notes |
+------------------------------------+------------------------------+
| 17| <my cat is a 	by> | Controls are disallowed |
+------------------------------------+------------------------------+
+------------------------------------+------------------------------+
| # | Password | Notes |
+------------------------------------+------------------------------+
| 17| <my cat is a 	by> | Controls are disallowed |
+------------------------------------+------------------------------+
Table 4: A String That Violates the Password Rules
表4：违反密码规则的字符串
This specification defines only the PRECIS-based rules for the handling of strings conforming to the UsernameCaseMapped and UsernameCasePreserved profiles of the PRECIS IdentifierClass, and strings conforming to the OpaqueString profile of the PRECIS FreeformClass. It is the responsibility of an application protocol to specify the protocol slots in which such strings can appear, the entities that are expected to enforce the rules governing such strings, and at what points during protocol processing or interface handling the rules need to be enforced. See Section 6 of [RFC7564] for guidelines on using PRECIS profiles in applications.
本规范仅定义了基于PRECIS的规则，用于处理符合PRECIS IdentifierClass的UsernameCaseMapped和UsernameCasePreserved配置文件的字符串，以及符合PRECIS FreeformClass的OpaqueString配置文件的字符串。应用程序协议的责任是指定这些字符串可以出现的协议插槽、期望强制执行这些字符串的规则的实体，以及在协议处理或接口处理期间需要强制执行规则的点。有关在应用程序中使用PRECIS配置文件的指南，请参见[RFC7564]第6节。
Above and beyond the PRECIS-based rules specified here, application protocols can also define application-specific rules governing such strings (rules regarding minimum or maximum length, further restrictions on allowable characters or character ranges, safeguards to mitigate the effects of visually similar characters, etc.), application-layer constructs (see Section 3.5), and related matters.
除了此处指定的基于PRECIS的规则之外，应用协议还可以定义管理此类字符串的特定于应用程序的规则（关于最小或最大长度的规则、对允许字符或字符范围的进一步限制、减轻视觉相似字符影响的保护措施等），应用层构造（见第3.5节）和相关事项。
Some PRECIS profile definitions encourage entities that enforce the rules to be liberal in what they accept. However, for usernames and passwords such a policy can be problematic, because it can lead to false positives. An in-depth discussion can be found in [RFC6943].
一些PRECIS概要文件定义鼓励执行规则的实体在其接受的内容上自由。但是，对于用户名和密码，这样的策略可能会有问题，因为它会导致误报。深入讨论见[RFC6943]。
The rules defined in this specification differ slightly from those defined by the SASLprep specification [RFC4013]. The following sections describe these differences, along with their implications for migration, in more detail.
本规范中定义的规则与SASLprep规范[RFC4013]中定义的规则略有不同。以下各节将更详细地描述这些差异及其对迁移的影响。
Deployments that currently use SASLprep for handling usernames might need to scrub existing data when they migrate to the rules defined in this specification. In particular:
当前使用SASLprep处理用户名的部署在迁移到此规范中定义的规则时可能需要清除现有数据。特别地：
o SASLprep specified the use of Unicode Normalization Form KC (NFKC), whereas the UsernameCaseMapped and UsernameCasePreserved profiles employ Unicode Normalization Form C (NFC). In practice, this change is unlikely to cause significant problems, because NFKC provides methods for mapping Unicode code points with compatibility equivalents to those equivalents, whereas the PRECIS IdentifierClass entirely disallows Unicode code points with compatibility equivalents (i.e., during comparison, NFKC is more "aggressive" about finding matches than NFC). A few examples might suffice to indicate the nature of the problem:
o SASLprep指定使用Unicode规范化表单KC（NFKC），而UsernameCaseMapped和UsernameCasePreserved配置文件使用Unicode规范化表单C（NFC）。在实践中，此更改不太可能导致重大问题，因为NFKC提供了将具有兼容性等价物的Unicode代码点映射到这些等价物的方法，而PRECIS IdentifierClass完全不允许具有兼容性等价物的Unicode代码点（即，在比较过程中，NFKC更“激进”）关于查找匹配项（而非NFC）。几个例子可能足以说明问题的性质：
1. LATIN SMALL LETTER LONG S (U+017F) is compatibility equivalent to LATIN SMALL LETTER S (U+0073).
1. 拉丁文小写字母长S（U+017F）的兼容性等同于拉丁文小写字母S（U+0073）。
2. ROMAN NUMERAL FOUR (U+2163) is compatibility equivalent to LATIN CAPITAL LETTER I (U+0049) and LATIN CAPITAL LETTER V (U+0056).
2. 罗马数字四（U+2163）与拉丁文大写字母I（U+0049）和拉丁文大写字母V（U+0056）兼容。
3. LATIN SMALL LIGATURE FI (U+FB01) is compatibility equivalent to LATIN SMALL LETTER F (U+0066) and LATIN SMALL LETTER I (U+0069).
3. 拉丁小连字FI（U+FB01）与拉丁小字母F（U+0066）和拉丁小字母I（U+0069）兼容。
Under SASLprep, the use of NFKC also handled the mapping of fullwidth and halfwidth code points to their decomposition mappings.
在SASLprep下，NFKC的使用还处理了全宽和半宽代码点到其分解映射的映射。
For migration purposes, operators might want to search their database of usernames for names containing Unicode code points with compatibility equivalents and, where there is no conflict, map those code points to their equivalents. Naturally, it is possible that during this process the operator will discover conflicting usernames (e.g., HENRYIV with the last two characters being LATIN CAPITAL LETTER I (U+0049) and LATIN CAPITAL LETTER V (U+0056) vs. "HENRYIV" with the last character being ROMAN NUMERAL FOUR (U+2163), which is compatibility equivalent to U+0049 and U+0056); in these cases, the operator will need to determine how to proceed -- for instance, by disabling the account whose name contains a Unicode code point with a compatibility equivalent. Such cases are probably rare, but it is important for operators to be aware of them.
出于迁移目的，运营商可能希望在其用户名数据库中搜索包含具有兼容性等价物的Unicode代码点的名称，并且在没有冲突的情况下，将这些代码点映射到其等价物。当然，在此过程中，操作员可能会发现冲突的用户名（例如，最后两个字符为拉丁大写字母I（U+0049）的HENRYIV和最后一个字符为罗马数字4（U+2163）的拉丁大写字母V（U+0056）与“HENRYIV”（U+0056），这相当于U+0049和U+0056的兼容性）；在这些情况下，操作员将需要确定如何继续操作——例如，通过禁用名称包含具有等效兼容性的Unicode代码点的帐户。这种情况可能很少见，但运营商必须意识到这一点。
o SASLprep mapped the "characters commonly mapped to nothing" from Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS IdentifierClass entirely disallows most of these characters, which correspond to the code points from the PRECIS "M" category defined under Section 9.13 of [RFC7564] (with the exception of MONGOLIAN TODO SOFT HYPHEN (U+1806), which was "commonly mapped to nothing" in Unicode 3.2 but at the time of this writing does not have a derived property of Default_Ignorable_Code_Point in Unicode 7.0). For migration purposes, the operator might want to remove from usernames any code points contained in the PRECIS "M" category (e.g., SOFT HYPHEN (U+00AD)). Because these code points would have been "mapped to nothing" in stringprep, in practice a user would not notice the difference if, upon migration to PRECIS, the code points are removed.
o SASLprep将[RFC3454]附录B.1中的“通常映射为零的字符”映射为零，而PRECIS IdentifierClass完全不允许这些字符中的大多数，它们对应于[RFC7564]第9.13节中定义的PRECIS“M”类别中的代码点（蒙古语TODO软连字符（U+1806）除外），它在Unicode 3.2中“通常映射为空”，但在撰写本文时，在Unicode 7.0中没有Default_Ignorable_Code_Point的派生属性）。出于迁移目的，操作员可能希望从用户名中删除PRECIS“M”类别中包含的任何代码点（例如，软连字符（U+00AD））。因为这些代码点在stringprep中“映射为空”，实际上，如果在迁移到PRECIS时删除了代码点，用户不会注意到差异。
o SASLprep allowed uppercase and titlecase characters, whereas the UsernameCaseMapped profile maps uppercase and titlecase characters to their lowercase equivalents (by contrast, the UsernameCasePreserved profile matches SASLprep in this regard). For migration purposes, the operator can use either the UsernameCaseMapped profile (thus losing the case information) or the UsernameCasePreserved profile (thus ignoring case difference when comparing usernames).
o SASLprep允许大写和标题字符，而UsernameCaseMapped配置文件将大写和标题字符映射为其对应的小写字符（相比之下，usernamecaseperved配置文件在这方面与SASLprep匹配）。出于迁移目的，操作员可以使用UsernameCaseMapped配置文件（从而丢失案例信息）或usernamecaseperved配置文件（从而在比较用户名时忽略案例差异）。
Depending on local service policy, migration from RFC 4013 to this specification might not involve any scrubbing of data (because passwords might not be stored in the clear anyway); however, service providers need to be aware of possible issues that might arise during migration. In particular:
根据本地服务策略，从RFC 4013迁移到此规范可能不涉及任何数据清理（因为密码可能不会存储在clear中）；但是，服务提供商需要了解迁移过程中可能出现的问题。特别地：
o SASLprep specified the use of Unicode Normalization Form KC (NFKC), whereas the OpaqueString profile employs Unicode Normalization Form C (NFC). Because NFKC is more aggressive about finding matches than NFC, in practice this change is unlikely to cause significant problems and indeed has the security benefit of probably resulting in fewer false positives when comparing passwords. A few examples might suffice to indicate the nature of the problem:
o SASLprep指定使用Unicode规范化表单KC（NFKC），而OpaqueString配置文件使用Unicode规范化表单C（NFC）。由于NFKC在查找匹配项方面比NFC更具攻击性，因此在实践中，这种更改不太可能导致重大问题，并且确实具有安全性优势，在比较密码时可能会导致更少的误报。几个例子可能足以说明问题的性质：
1. LATIN SMALL LETTER LONG S (U+017F) is compatibility equivalent to LATIN SMALL LETTER S (U+0073).
1. 拉丁文小写字母长S（U+017F）的兼容性等同于拉丁文小写字母S（U+0073）。
2. ROMAN NUMERAL FOUR (U+2163) is compatibility equivalent to LATIN CAPITAL LETTER I (U+0049) and LATIN CAPITAL LETTER V (U+0056).
2. 罗马数字四（U+2163）与拉丁文大写字母I（U+0049）和拉丁文大写字母V（U+0056）兼容。
3. LATIN SMALL LIGATURE FI (U+FB01) is compatibility equivalent to LATIN SMALL LETTER F (U+0066) and LATIN SMALL LETTER I (U+0069).
3. 拉丁小连字FI（U+FB01）与拉丁小字母F（U+0066）和拉丁小字母I（U+0069）兼容。
Under SASLprep, the use of NFKC also handled the mapping of fullwidth and halfwidth code points to their decomposition mappings. Although it is expected that code points with compatibility equivalents are rare in existing passwords, some passwords that matched when SASLprep was used might no longer work when the rules in this specification are applied.
在SASLprep下，NFKC的使用还处理了全宽和半宽代码点到其分解映射的映射。虽然在现有密码中，具有兼容性等价物的代码点是很少见的，但当应用本规范中的规则时，使用SASLprep时匹配的某些密码可能不再有效。
o SASLprep mapped the "characters commonly mapped to nothing" from Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS FreeformClass entirely disallows such characters, which correspond to the code points from the PRECIS "M" category defined under Section 9.13 of [RFC7564] (with the exception of MONGOLIAN TODO SOFT HYPHEN (U+1806), which was commonly mapped to nothing in Unicode 3.2 but at the time of this writing is allowed by Unicode 7.0). In practice, this change will probably have no effect on comparison, but user-oriented software might reject such code points instead of ignoring them during password preparation.
o SASLprep将[RFC3454]附录B.1中的“通常映射为零的字符”映射为零，而PRECIS FreeformClass完全不允许此类字符，它们对应于[RFC7564]第9.13节定义的PRECIS“M”类别中的代码点（蒙古语TODO软连字符（U+1806）除外），在Unicode 3.2中通常映射为nothing，但在撰写本文时，Unicode 7.0允许使用它）。实际上，此更改可能不会对比较产生影响，但面向用户的软件可能会拒绝这些代码点，而不是在密码准备过程中忽略它们。
IANA has made the updates described below.
IANA已进行了如下所述的更新。
IANA has added the following entry to the "PRECIS Profiles" registry.
IANA已将以下条目添加到“PRECIS配置文件”注册表中。
Name: UsernameCaseMapped.
名称：UsernameCaseMapped。
Base Class: IdentifierClass.
基类：IdentifierClass。
Applicability: Usernames in security and application protocols.
适用性：安全和应用程序协议中的用户名。
Replaces: The SASLprep profile of stringprep.
替换：stringprep的SASLprep配置文件。
Width-Mapping Rule: Map fullwidth and halfwidth characters to their decomposition mappings.
宽度映射规则：将全宽和半宽字符映射到其分解映射。
Additional Mapping Rule: None.
其他映射规则：无。
Case-Mapping Rule: Map uppercase and titlecase characters to lowercase.
大小写映射规则：将大小写字符映射为小写。
Normalization Rule: NFC.
规范化规则：NFC。
Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies.
方向性规则：RFC 5893中定义的“比迪规则”适用。
Enforcement: To be defined by security or application protocols that use this profile.
强制：由使用此配置文件的安全协议或应用程序协议定义。
Specification: RFC 7613 (this document), Section 3.2.
规范：RFC 7613（本文件），第3.2节。
IANA has added the following entry to the "PRECIS Profiles" registry.
IANA已将以下条目添加到“PRECIS配置文件”注册表中。
Name: UsernameCasePreserved.
名称：UsernameCasePreserved。
Base Class: IdentifierClass.
基类：IdentifierClass。
Applicability: Usernames in security and application protocols.
适用性：安全和应用程序协议中的用户名。
Replaces: The SASLprep profile of stringprep.
替换：stringprep的SASLprep配置文件。
Width-Mapping Rule: Map fullwidth and halfwidth characters to their decomposition mappings.
宽度映射规则：将全宽和半宽字符映射到其分解映射。
Additional Mapping Rule: None.
其他映射规则：无。
Case-Mapping Rule: None.
案例映射规则：无。
Normalization Rule: NFC.
规范化规则：NFC。
Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies.
方向性规则：RFC 5893中定义的“比迪规则”适用。
Enforcement: To be defined by security or application protocols that use this profile.
强制：由使用此配置文件的安全协议或应用程序协议定义。
Specification: RFC 7613 (this document), Section 3.3.
规范：RFC 7613（本文件），第3.3节。
IANA has added the following entry to the "PRECIS Profiles" registry.
IANA已将以下条目添加到“PRECIS配置文件”注册表中。
Name: OpaqueString.
名称：OpaqueString。
Base Class: FreeformClass.
基类：FreeformClass。
Applicability: Passwords and other opaque strings in security and application protocols.
适用性：安全和应用程序协议中的密码和其他不透明字符串。
Replaces: The SASLprep profile of stringprep.
替换：stringprep的SASLprep配置文件。
Width-Mapping Rule: None.
宽度映射规则：无。
Additional Mapping Rule: Map non-ASCII space characters to ASCII space.
其他映射规则：将非ASCII空格字符映射到ASCII空格。
Case-Mapping Rule: None.
案例映射规则：无。
Normalization Rule: NFC.
规范化规则：NFC。
Directionality Rule: None.
方向性规则：无。
Enforcement: To be defined by security or application protocols that use this profile.
强制：由使用此配置文件的安全协议或应用程序协议定义。
Specification: RFC 7613 (this document), Section 4.2.
规范：RFC 7613（本文件），第4.2节。
The stringprep specification [RFC3454] did not provide for entries in the "Stringprep Profiles" registry to have any state except "Current" or "Not Current". Because this document obsoletes RFC 4013, which registered the SASLprep profile of stringprep, IANA has marked that profile as "Not Current" and cited this document as an additional reference.
stringprep规范[RFC3454]未规定“stringprep配置文件”注册表中的条目具有除“当前”或“非当前”之外的任何状态。由于本文件淘汰了RFC 4013，RFC 4013注册了stringprep的SASLprep配置文件，IANA已将该配置文件标记为“非最新”，并引用本文件作为附加参考。
The ability to include a wide range of characters in passwords and passphrases can increase the potential for creating a strong password with high entropy. However, in practice, the ability to include such characters ought to be weighed against the possible need to reproduce them on various devices using various input methods.
在密码和密码短语中包含大量字符的能力可以增加创建高熵强密码的可能性。然而，在实践中，包括这些字符的能力应该与使用各种输入方法在各种设备上重现这些字符的可能需要进行权衡。
The process of comparing identifiers (such as SASL simple user names, authentication identifiers, and authorization identifiers) can lead to either false negatives or false positives, both of which have security implications. A more detailed discussion can be found in [RFC6943].
比较标识符（如SASL简单用户名、身份验证标识符和授权标识符）的过程可能导致误报或误报，这两种情况都有安全隐患。更详细的讨论见[RFC6943]。
The security considerations described in [RFC7564] apply to the IdentifierClass and FreeformClass base string classes used in this document for usernames and passwords, respectively.
[RFC7564]中描述的安全注意事项分别适用于本文档中用于用户名和密码的IdentifierClass和FreeformClass基字符串类。
The security considerations described in [UTS39] apply to the use of Unicode characters in usernames and passwords.
[UTS39]中描述的安全注意事项适用于用户名和密码中Unicode字符的使用。
[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>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<http://www.rfc-editor.org/info/rfc5890>.
[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>.
[UAX11] Unicode Standard Annex #11, "East Asian Width", edited by Ken Lunde. An integral part of The Unicode Standard, <http://unicode.org/reports/tr11/>.
[UAX11]Unicode标准附件#11，“东亚宽度”，Ken Lunde编辑。Unicode标准不可分割的一部分<http://unicode.org/reports/tr11/>.
[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", (Mountain View, CA: The Unicode Consortium, 2014 ISBN 978-1-936213-09-2), <http://www.unicode.org/versions/Unicode7.0.0/>.
[Unicode 7.0]Unicode联盟，“Unicode标准，7.0.0版”（加利福尼亚州山景城：Unicode联盟，2014年ISBN 978-1-936213-09-2）<http://www.unicode.org/versions/Unicode7.0.0/>.
[Err1812] RFC Errata, Erratum ID 1812, RFC 4013, <http://www.rfc-editor.org>.
[Err1812]RFC勘误表，勘误表ID 1812，RFC 4013<http://www.rfc-editor.org>.
[HTTP-BASIC-AUTH] Reschke, J., "The 'Basic' HTTP Authentication Scheme", Work in Progress, draft-ietf-httpauth-basicauth-update-07, February 2015.
[HTTP-BASIC-AUTH]Reschke，J.，“基本”HTTP认证方案，正在进行的工作，草稿-ietf-httpauth-basicauth-update-072015年2月。
[HTTP-DIGEST-AUTH] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", Work in Progress, draft-ietf-httpauth-digest-19, April 2015.
[HTTP-DIGEST-AUTH]Shekh Yusef，R.，Ed.，Ahrens，D.，和S.Bremer，“HTTP摘要访问认证”，正在进行的工作，草稿-ietf-httpauth-DIGEST-192015年4月。
[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>.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, DOI 10.17487/RFC3454, December 2002, <http://www.rfc-editor.org/info/rfc3454>.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化字符串的准备（“stringprep”）”，RFC 3454，DOI 10.17487/RFC3454，2002年12月<http://www.rfc-editor.org/info/rfc3454>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <http://www.rfc-editor.org/info/rfc3501>.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 3501，DOI 10.17487/RFC3501，2003年3月<http://www.rfc-editor.org/info/rfc3501>.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, DOI 10.17487/RFC4013, February 2005, <http://www.rfc-editor.org/info/rfc4013>.
[RFC4013]Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC 4013，DOI 10.17487/RFC4013，2005年2月<http://www.rfc-editor.org/info/rfc4013>.
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <http://www.rfc-editor.org/info/rfc4422>.
[RFC4422]Melnikov，A.，Ed.，和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，DOI 10.17487/RFC4422，2006年6月<http://www.rfc-editor.org/info/rfc4422>.
[RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, DOI 10.17487/RFC4616, August 2006, <http://www.rfc-editor.org/info/rfc4616>.
[RFC4616]Zeilenga，K.，Ed.“简单认证和安全层（SASL）机制”，RFC 4616，DOI 10.17487/RFC4616，2006年8月<http://www.rfc-editor.org/info/rfc4616>.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, DOI 10.17487/RFC5802, July 2010, <http://www.rfc-editor.org/info/rfc5802>.
[RFC5802]Newman，C.，Menon Sen，A.，Melnikov，A.，和N.Williams，“盐渍挑战响应认证机制（SCRAM）SASL和GSS-API机制”，RFC 5802，DOI 10.17487/RFC5802，2010年7月<http://www.rfc-editor.org/info/rfc5802>.
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <http://www.rfc-editor.org/info/rfc5891>.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 5891，DOI 10.17487/RFC5891，2010年8月<http://www.rfc-editor.org/info/rfc5891>.
[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>.
[RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, <http://www.rfc-editor.org/info/rfc5894>.
[RFC5894]Klensin，J.，“应用程序的国际化域名（IDNA）：背景、解释和理由”，RFC 5894，DOI 10.17487/RFC5894，2010年8月<http://www.rfc-editor.org/info/rfc5894>.
[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>.
[RFC6122] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", RFC 6122, DOI 10.17487/RFC6122, March 2011, <http://www.rfc-editor.org/info/rfc6122>.
[RFC6122]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：地址格式”，RFC 6122，DOI 10.17487/RFC6122，2011年3月<http://www.rfc-editor.org/info/rfc6122>.
[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013, <http://www.rfc-editor.org/info/rfc6943>.
[RFC6943]Thaler，D.，Ed.，“出于安全目的的标识符比较问题”，RFC 6943，DOI 10.17487/RFC6943，2013年5月<http://www.rfc-editor.org/info/rfc6943>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, <http://www.rfc-editor.org/info/rfc7542>.
[RFC7542]DeKok，A.，“网络访问标识符”，RFC 7542，DOI 10.17487/RFC7542，2015年5月<http://www.rfc-editor.org/info/rfc7542>.
[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/>.
[XMPP-ADDR] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", Work in Progress, draft-ietf-xmpp-6122bis-24, June 2015.
[XMPP-ADDR]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：地址格式”，正在进行的工作，草稿-ietf-XMPP-6122bis-242015年6月。
This document builds upon the PRECIS framework defined in [RFC7564], which differs fundamentally from the stringprep technology [RFC3454] used in SASLprep [RFC4013]. The primary difference is that stringprep profiles allowed all characters except those characters that were explicitly disallowed, whereas PRECIS profiles disallow all characters except those characters that are explicitly allowed (this "inclusion model" was originally used for internationalized domain names in [RFC5891]; see [RFC5894] for further discussion). It is important to keep this distinction in mind when comparing the technology defined in this document to SASLprep [RFC4013].
本文档以[RFC7564]中定义的PRECIS框架为基础，该框架与SASLprep[RFC4013]中使用的stringprep技术[RFC3454]有根本不同。主要区别在于stringprep配置文件允许除明确禁止的字符外的所有字符，而PRECIS配置文件不允许除明确允许的字符外的所有字符（此“包含模型”最初用于[RFC5891]中的国际化域名；请参见[RFC5894]供进一步讨论）。在将本文档中定义的技术与SASLprep[RFC4013]进行比较时，务必记住这一区别。
The following substantive modifications were made from RFC 4013.
对RFC 4013进行了以下实质性修改。
o A single SASLprep algorithm was replaced by three separate algorithms: one for usernames with case mapping, one for usernames with case preservation, and one for passwords.
o 一个单独的SASLprep算法被三个单独的算法所取代：一个用于具有大小写映射的用户名，一个用于具有大小写保留的用户名，以及一个用于密码。
o The new preparation algorithms use PRECIS instead of a stringprep profile. The new algorithms work independently of Unicode versions.
o 新的准备算法使用PRECIS而不是stringprep配置文件。新算法独立于Unicode版本工作。
o As recommended in the PRECIS framework, changed the Unicode normalization form from NFKC to NFC.
o 按照PRECIS框架中的建议，将Unicode规范化表单从NFKC更改为NFC。
o Some Unicode code points that were mapped to nothing in RFC 4013 are simply disallowed by PRECIS.
o 一些在RFC4013中映射为nothing的Unicode代码点被PRECIS禁止。
Acknowledgements
致谢
This document borrows some text from [RFC4013] and [RFC6120].
本文件借用了[RFC4013]和[RFC6120]中的一些文本。
The following individuals provided helpful feedback on this document: Marc Blanchet, Ben Campbell, Alan DeKok, Joe Hildebrand, Jeffrey Hutzelman, Simon Josefsson, Jonathan Lennox, James Manger, Matt Miller, Chris Newman, Yutaka OIWA, Pete Resnick, Andrew Sullivan, Nico Williams, and Yoshiro YONEYA. Nico Williams in particular deserves special recognition for providing text that was used in Section 3.4. Thanks also to Takahiro NEMOTO and Yoshiro YONEYA for implementation feedback.
以下个人对本文件提供了有用的反馈：马克·布兰切特、本·坎贝尔、艾伦·德科克、乔·希尔德布兰德、杰弗里·哈泽尔曼、西蒙·约瑟夫森、乔纳森·伦诺克斯、詹姆斯·马格尔、马特·米勒、克里斯·纽曼、尤塔卡·奥瓦、皮特·雷斯尼克、安德鲁·沙利文、尼科·威廉姆斯和Yoshiro YONEYA。Nico Williams提供了第3.4节中使用的文本，尤其值得特别认可。还要感谢NEMOTO Takahiro和Yoseya Yoshiro提供的实施反馈。
Robert Sparks and Derek Atkins reviewed the document on behalf of the General Area Review Team and the Security Directorate, respectively.
罗伯特·斯帕克斯（Robert Sparks）和德里克·阿特金斯（Derek Atkins）分别代表总区域审查小组和安全理事会审查了该文件。
Benoit Claise and Stephen Farrell provided helpful input during IESG review.
Benoit Claise和Stephen Farrell在IESG审查期间提供了有用的意见。
Thanks to Matt Miller as document shepherd, Marc Blanchet and Yoshiro YONEYA as working group chairs, and Pete Resnick and Barry Leiba as area directors.
感谢马特·米勒担任文件管理员，马克·布兰切特和Yoshiro YONEYA担任工作组主席，皮特·雷斯尼克和巴里·莱巴担任区域主任。
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier draft versions of this document.
Peter Saint Andre希望感谢Cisco Systems，Inc.在编写本文件早期草稿期间聘用了他。
Authors' Addresses
作者地址
Peter Saint-Andre &yet
彼得·圣安德烈&还没有
Email: peter@andyet.com
URI: https://andyet.com/
Email: peter@andyet.com
URI: https://andyet.com/
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX United Kingdom
英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号Alexey Melnikov Isode有限公司TW12 2BX
Email: Alexey.Melnikov@isode.com
Email: Alexey.Melnikov@isode.com