Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 6122 Cisco
Updates: 3920 March 2011
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 6122 Cisco
Updates: 3920 March 2011
Category: Standards Track
ISSN: 2070-1721
Extensible Messaging and Presence Protocol (XMPP): Address Format
可扩展消息和状态协议（XMPP）：地址格式
Abstract
摘要
This document defines the format for addresses used in the Extensible Messaging and Presence Protocol (XMPP), including support for non-ASCII characters. This document updates RFC 3920.
本文档定义了可扩展消息和状态协议（XMPP）中使用的地址格式，包括对非ASCII字符的支持。本文件更新了RFC 3920。
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/rfc6122.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6122.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Domainpart . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Localpart . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Resourcepart . . . . . . . . . . . . . . . . . . . . . . . 8
3. Internationalization Considerations . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4.1. Reuse of Stringprep . . . . . . . . . . . . . . . . . . . 9
4.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . . 9
4.3. Address Spoofing . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Address Forging . . . . . . . . . . . . . . . . . . . 10
4.3.2. Address Mimicking . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5.1. Nodeprep Profile of Stringprep . . . . . . . . . . . . . . 13
5.2. Resourceprep Profile of Stringprep . . . . . . . . . . . . 14
6. Conformance Requirements . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 19
A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 19
A.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 19
A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 19
A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 20
A.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 20
A.7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 21
B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 21
B.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 22
B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 22
B.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 22
B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 22
B.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 22
Appendix C. Differences from RFC 3920 . . . . . . . . . . . . . . 22
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Domainpart . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Localpart . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Resourcepart . . . . . . . . . . . . . . . . . . . . . . . 8
3. Internationalization Considerations . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4.1. Reuse of Stringprep . . . . . . . . . . . . . . . . . . . 9
4.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . . 9
4.3. Address Spoofing . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Address Forging . . . . . . . . . . . . . . . . . . . 10
4.3.2. Address Mimicking . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5.1. Nodeprep Profile of Stringprep . . . . . . . . . . . . . . 13
5.2. Resourceprep Profile of Stringprep . . . . . . . . . . . . 14
6. Conformance Requirements . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 19
A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 19
A.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 19
A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 19
A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 20
A.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 20
A.7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 21
B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 21
B.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 22
B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 22
B.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 22
B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 22
B.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 22
Appendix C. Differences from RFC 3920 . . . . . . . . . . . . . . 22
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 23
The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language [XML] for streaming XML data in close to real time between any two or more network-aware entities. The address format for XMPP entities was originally developed in the Jabber open-source community in 1999, first described by [XEP-0029] in 2002, and defined canonically by [RFC3920] in 2004.
可扩展消息和状态协议（XMPP）是可扩展标记语言[XML]的应用程序配置文件，用于在任何两个或多个网络感知实体之间近实时地流式传输XML数据。XMPP实体的地址格式最初于1999年在Jabber开源社区中开发，2002年由[XEP-0029]首次描述，2004年由[RFC3920]进行规范定义。
As specified in RFC 3920, the XMPP address format reuses the "stringprep" technology for preparation of non-ASCII characters [STRINGPREP], including the Nameprep profile for internationalized domain names as specified in [NAMEPREP] and [IDNA2003] along with two XMPP-specific profiles for the localpart and resourcepart.
如RFC 3920所述，XMPP地址格式重用“stringprep”技术来准备非ASCII字符[stringprep]，包括[Nameprep]和[IDNA2003]中指定的国际化域名的Nameprep配置文件，以及localpart和resourcepart的两个XMPP特定配置文件。
Since the publication of RFC 3920, IDNA2003 has been superseded by IDNA2008 (see [IDNA-PROTO] and related documents), which is not based on stringprep. Following the lead of the IDNA community, other technology communities that use stringprep have begun discussions about migrating away from stringprep toward more "modern" approaches. The XMPP community is participating in those discussions (mostly within the PRECIS Working Group) in order to find a replacement for the Nodeprep and Resourceprep profiles of stringprep defined in RFC 3920. Because all other aspects of revised documentation for XMPP have been incorporated into [XMPP], the XMPP Working Group decided to temporarily split the XMPP address format into a separate document so as not to significantly delay publication of improved documentation for XMPP. It is expected that this document will be obsoleted as soon as work on a new approach to preparation and comparison of internationalized addresses has been completed.
自RFC 3920发布以来，IDNA2003已被IDNA2008（见[IDNA-PROTO]和相关文件）取代，IDNA2008并非基于stringprep。在IDNA社区的领导下，其他使用stringprep的技术社区已经开始讨论从stringprep迁移到更“现代”的方法。XMPP社区正在参与这些讨论（主要在PRECIS工作组内），以便找到RFC 3920中定义的stringprep的Nodeprep和Resourceprep配置文件的替代品。由于XMPP修订文件的所有其他方面已纳入[XMPP]，XMPP工作组决定暂时将XMPP地址格式拆分为单独的文件，以避免显著延迟XMPP改进文件的发布。预计一旦制定和比较国际化地址的新方法的工作完成，本文件将被废弃。
Therefore, this specification provides corrected documentation of the XMPP address format using the internationalization technologies available in 2004 (when RFC 3920 was published). Although this document normatively references [IDNA2003] and [NAMEPREP], XMPP software implementations are encouraged to begin migrating to IDNA2008 (see [IDNA-PROTO] and related documents) because the specification that obsoletes this one will use IDNA2008 rather than IDNA2003.
因此，本规范使用2004年（RFC3920发布时）可用的国际化技术提供了XMPP地址格式的更正文档。尽管本文档规范性地引用了[IDNA2003]和[NAMEPREP]，但仍鼓励XMPP软件实现开始迁移到IDNA2008（请参阅[IDNA-PROTO]和相关文档），因为淘汰本文档的规范将使用IDNA2008而不是IDNA2003。
This document updates RFC 3920.
本文件更新了RFC 3920。
Many important terms used in this document are defined in [IDNA2003], [STRINGPREP], [UNICODE], and [XMPP].
本文档中使用的许多重要术语在[IDNA2003]、[STRINGPREP]、[UNICODE]和[XMPP]中定义。
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 RFC 2119 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[关键词]中的描述进行解释。
An XMPP entity is anything that is network-addressable and that can communicate using XMPP. For historical reasons, the native address of an XMPP entity is called a Jabber Identifier or JID. A valid JID is a string of [UNICODE] code points, encoded using [UTF-8], and structured as an ordered sequence of localpart, domainpart, and resourcepart (where the first two parts are demarcated by the '@' character used as a separator, and the last two parts are similarly demarcated by the '/' character).
XMPP实体是任何可以通过网络寻址并且可以使用XMPP进行通信的实体。出于历史原因，XMPP实体的本机地址称为Jabber标识符或JID。有效的JID是一个[UNICODE]代码点字符串，使用[UTF-8]编码，结构为localpart、domainpart和resourcepart的有序序列（其中前两部分由用作分隔符的“@”字符划分，后两部分由“/”字符类似地划分）。
The syntax for a JID is defined as follows using the Augmented Backus-Naur Form as specified in [ABNF].
JID的语法定义如下，使用[ABNF]中指定的扩展的Backus Naur形式。
jid = [ localpart "@" ] domainpart [ "/" resourcepart ]
localpart = 1*(nodepoint)
;
; a "nodepoint" is a UTF-8 encoded Unicode code
; point that satisfies the Nodeprep profile of
; stringprep
;
domainpart = IP-literal / IPv4address / ifqdn
;
; the "IPv4address" and "IP-literal" rules are
; defined in RFC 3986, and the first-match-wins
; (a.k.a. "greedy") algorithm described in RFC
; 3986 applies to the matching process
;
; note well that reuse of the IP-literal rule
; from RFC 3986 implies that IPv6 addresses are
; enclosed in square brackets (i.e., beginning
; with '[' and ending with ']'), which was not
; the case in RFC 3920
;
ifqdn = 1*(namepoint)
;
; a "namepoint" is a UTF-8 encoded Unicode
; code point that satisfies the Nameprep
; profile of stringprep
;
resourcepart = 1*(resourcepoint)
;
; a "resourcepoint" is a UTF-8 encoded Unicode
; code point that satisfies the Resourceprep
; profile of stringprep
;
jid = [ localpart "@" ] domainpart [ "/" resourcepart ]
localpart = 1*(nodepoint)
;
; a "nodepoint" is a UTF-8 encoded Unicode code
; point that satisfies the Nodeprep profile of
; stringprep
;
domainpart = IP-literal / IPv4address / ifqdn
;
; the "IPv4address" and "IP-literal" rules are
; defined in RFC 3986, and the first-match-wins
; (a.k.a. "greedy") algorithm described in RFC
; 3986 applies to the matching process
;
; note well that reuse of the IP-literal rule
; from RFC 3986 implies that IPv6 addresses are
; enclosed in square brackets (i.e., beginning
; with '[' and ending with ']'), which was not
; the case in RFC 3920
;
ifqdn = 1*(namepoint)
;
; a "namepoint" is a UTF-8 encoded Unicode
; code point that satisfies the Nameprep
; profile of stringprep
;
resourcepart = 1*(resourcepoint)
;
; a "resourcepoint" is a UTF-8 encoded Unicode
; code point that satisfies the Resourceprep
; profile of stringprep
;
All JIDs are based on the foregoing structure.
所有JID都基于上述结构。
Each allowable portion of a JID (localpart, domainpart, and resourcepart) MUST NOT be zero bytes in length and MUST NOT be more than 1023 bytes in length, resulting in a maximum total size (including the '@' and '/' separators) of 3071 bytes.
JID的每个允许部分（localpart、domainpart和resourcepart）的长度不得为零字节，长度不得超过1023字节，从而导致最大总大小（包括“@”和“/”分隔符）为3071字节。
For the purpose of communication over an XMPP network (e.g., in the 'to' or 'from' address of an XMPP stanza), an entity's address MUST be represented as a JID, not as a Uniform Resource Identifier [URI] or Internationalized Resource Identifier [IRI]. An XMPP IRI [XMPP-URI] is in essence a JID prepended with 'xmpp:'; however, the native addressing format used in XMPP is that of a mere JID without a URI scheme. [XMPP-URI] is provided only for identification and interaction outside the context of XMPP itself, for example when
为了通过XMPP网络进行通信（例如，在XMPP节的“收件人”或“发件人”地址中），实体的地址必须表示为JID，而不是统一资源标识符[URI]或国际化资源标识符[IRI]。XMPP IRI[XMPP-URI]本质上是一个以“XMPP:”开头的JID；然而，XMPP中使用的本机寻址格式只是没有URI方案的JID格式。[XMPP-URI]仅用于XMPP本身上下文之外的标识和交互，例如
linking to a JID from a web page. See [XMPP-URI] for a description of the process for securely extracting a JID from an XMPP URI or IRI.
从网页链接到JID。有关从XMPP URI或IRI安全提取JID的过程的描述，请参见[XMPP-URI]。
Implementation Note: When dividing a JID into its component parts, an implementation needs to match the separator characters '@' and '/' before applying any transformation algorithms, which might decompose certain Unicode code points to the separator characters (e.g., U+FE6B SMALL COMMERCIAL AT might decompose into U+0040 COMMERCIAL AT).
实现说明：将JID划分为其组成部分时，实现需要在应用任何转换算法之前匹配分隔符“@”和“/”，这可能会将某些Unicode代码点分解为分隔符（例如，U+FE6B小型商用AT可能会分解为U+0040商用AT）。
The domainpart of a JID is that portion after the '@' character (if any) and before the '/' character (if any); it is the primary identifier and is the only REQUIRED element of a JID (a mere domainpart is a valid JID). Typically a domainpart identifies the "home" server to which clients connect for XML routing and data management functionality. However, it is not necessary for an XMPP domainpart to identify an entity that provides core XMPP server functionality (e.g., a domainpart can identify an entity such as a multi-user chat service, a publish-subscribe service, or a user directory).
JID的domainpart是在“@”字符（如果有）之后和“/”字符（如果有）之前的部分；它是主要标识符，并且是JID的唯一必需元素（仅domainpart是有效的JID）。通常，domainpart标识客户端为XML路由和数据管理功能连接的“主”服务器。然而，XMPP域部件不需要识别提供核心XMPP服务器功能的实体（例如，域部件可以识别实体，例如多用户聊天服务、发布-订阅服务或用户目录）。
The domainpart for every XMPP service MUST be a fully qualified domain name (FQDN; see [DNS]), IPv4 address, IPv6 address, or unqualified hostname (i.e., a text label that is resolvable on a local network).
每个XMPP服务的domainpart必须是完全限定的域名（FQDN；请参阅[DNS]）、IPv4地址、IPv6地址或非限定的主机名（即，可在本地网络上解析的文本标签）。
Interoperability Note: Domainparts that are IP addresses might not be accepted by other services for the sake of server-to-server communication, and domainparts that are unqualified hostnames cannot be used on public networks because they are resolvable only on a local network.
互操作性说明：出于服务器对服务器通信的考虑，作为IP地址的DomainPart可能不被其他服务接受，并且作为非限定主机名的DomainPart不能在公共网络上使用，因为它们只能在本地网络上解析。
If the domainpart includes a final character considered to be a label separator (dot) by [IDNA2003] or [DNS], this character MUST be stripped from the domainpart before the JID of which it is a part is used for the purpose of routing an XML stanza, comparing against another JID, or constructing an [XMPP-URI]. In particular, the character MUST be stripped before any other canonicalization steps are taken, such as application of the [NAMEPREP] profile of [STRINGPREP] or completion of the ToASCII operation as described in [IDNA2003].
如果domainpart包含[IDNA2003]或[DNS]认为是标签分隔符（dot）的最后一个字符，则必须在将该字符作为其一部分的JID用于路由XML节、与另一个JID进行比较或构造[XMPP-URI]之前，从domainpart中删除该字符。特别是，在采取任何其他规范化步骤之前，必须去除字符，例如应用[STRINGPREP]的[NAMEPREP]配置文件或完成[IDNA2003]中所述的ToASCII操作。
A domainpart consisting of a fully qualified domain name MUST be an "internationalized domain name" as defined in [IDNA2003]; that is, it MUST be "a domain name in which every label is an internationalized label" and MUST follow the rules for construction of
由完全限定域名组成的domainpart必须是[IDNA2003]中定义的“国际化域名”；也就是说，它必须是“一个域名，其中每个标签都是一个国际化的标签”，并且必须遵循
internationalized domain names specified in [IDNA2003]. When preparing a text label (consisting of a sequence of UTF-8 encoded Unicode code points) for representation as an internationalized label in the process of constructing an XMPP domainpart or comparing two XMPP domainparts, an application MUST ensure that for each text label it is possible to apply without failing the ToASCII operation specified in [IDNA2003] with the UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other than letters, digits, and hyphens). If the ToASCII operation can be applied without failing, then the label is an internationalized label. (Note: The ToASCII operation includes application of the [NAMEPREP] profile of [STRINGPREP] and encoding using the algorithm specified in [PUNYCODE]; for details, see [IDNA2003].) Although XMPP applications do not communicate the output of the ToASCII operation (called an "ACE label") over the wire, it MUST be possible to apply that operation without failing to each internationalized label. If an XMPP application receives as input an ACE label, it SHOULD convert that ACE label to an internationalized label using the ToUnicode operation (see [IDNA2003]) before including the label in an XMPP domainpart that will be communicated over the wire on an XMPP network (however, instead of converting the label, there are legitimate reasons why an application might instead refuse the input altogether and return an error to the entity that provided the offending data).
[IDNA2003]中指定的国际化域名。在构造XMPP domainpart或比较两个XMPP domainpart的过程中，准备文本标签（由UTF-8编码的Unicode代码点序列组成）以表示为国际化标签时，应用程序必须确保，对于每个文本标签，在设置UseSTD3ASCIIRules标志（从而禁止字母、数字和连字符以外的ASCII码点）的情况下，可以在不失败[IDNA2003]中指定的ToASCII操作的情况下应用。如果ToASCII操作可以在不失败的情况下应用，则标签是国际化标签。（注：ToASCII操作包括应用[STRINGPREP]的[NAMEPREP]配置文件，并使用[PUNYCODE]中指定的算法进行编码；有关详细信息，请参阅[IDNA2003]）。尽管XMPP应用程序不通过线路传输ToASCII操作的输出（称为“ACE标签”），必须能够对每个国际化标签应用该操作而不会失败。如果XMPP应用程序接收到ACE标签作为输入，则应使用ToUnicode操作（参见[IDNA2003]）将该ACE标签转换为国际化标签，然后再将该标签包含在XMPP domainpart中，该XMPP domainpart将通过XMPP网络上的线路进行通信（但是，应用程序可能会完全拒绝输入并向提供违规数据的实体返回错误，而不是转换标签，这是有正当理由的）。
A domainpart MUST NOT be zero bytes in length and MUST NOT be more than 1023 bytes in length. This rule is to be enforced after any mapping or normalization resulting from application of the Nameprep profile of stringprep (e.g., in Nameprep some characters can be mapped to nothing, which might result in a string of zero length). Naturally, the length limits of [DNS] apply, and nothing in this document is to be interpreted as overriding those more fundamental limits.
domainpart的长度不得为零字节，且不得超过1023字节。在应用stringprep的Nameprep配置文件（例如，在Nameprep中，某些字符可以映射为nothing，这可能导致字符串长度为零）后，将强制执行此规则。自然地，[DNS]的长度限制适用，本文档中的任何内容都不能解释为覆盖了这些更基本的限制。
In the terms of IDNA2008 [IDNA-DEFS], the domainpart of a JID is a "domain name slot".
在IDNA2008[IDNA-DEFS]中，JID的域部分是一个“域名槽”。
The localpart of a JID is an optional identifier placed before the domainpart and separated from the latter by the '@' character. Typically a localpart uniquely identifies the entity requesting and using network access provided by a server (i.e., a local account), although it can also represent other kinds of entities (e.g., a chat room associated with a multi-user chat service). The entity represented by an XMPP localpart is addressed within the context of a specific domain (i.e., <localpart@domainpart>).
JID的localpart是一个可选标识符，位于domainpart之前，并用“@”字符与后者隔开。通常，localpart唯一地标识请求并使用服务器提供的网络访问的实体（即本地帐户），尽管它也可以表示其他类型的实体（例如，与多用户聊天服务关联的聊天室）。XMPP localpart表示的实体在特定域的上下文中寻址（即<localpart@domainpart>).
A localpart MUST be formatted such that the Nodeprep profile of [STRINGPREP] can be applied without failing (see Appendix A). Before comparing two localparts, an application MUST first ensure that the Nodeprep profile has been applied to each identifier (the profile need not be applied each time a comparison is made, as long as it has been applied before comparison).
必须对localpart进行格式化，以使[STRINGPREP]的Nodeprep配置文件能够在不失败的情况下应用（参见附录A）。在比较两个LocalPart之前，应用程序必须首先确保已将Nodeprep配置文件应用于每个标识符（不必在每次进行比较时应用该配置文件，只要该配置文件在比较之前已应用）。
A localpart MUST NOT be zero bytes in length and MUST NOT be more than 1023 bytes in length. This rule is to be enforced after any mapping or normalization resulting from application of the Nodeprep profile of stringprep (e.g., in Nodeprep some characters can be mapped to nothing, which might result in a string of zero length).
localpart的长度不得为零字节，且不得超过1023字节。在应用stringprep的Nodeprep配置文件（例如，在Nodeprep中，某些字符可以映射为nothing，这可能导致字符串长度为零）后，将强制执行此规则。
The resourcepart of a JID is an optional identifier placed after the domainpart and separated from the latter by the '/' character. A resourcepart can modify either a <localpart@domainpart> address or a mere <domainpart> address. Typically a resourcepart uniquely identifies a specific connection (e.g., a device or location) or object (e.g., an occupant in a multi-user chat room) belonging to the entity associated with an XMPP localpart at a domain (i.e., <localpart@domainpart/resourcepart>).
JID的resourcepart是一个可选标识符，位于domainpart之后，并用“/”字符与后者隔开。resourcepart可以修改<localpart@domainpart>地址或仅仅是<domainpart>地址。通常，resourcepart唯一标识属于域中与XMPP localpart关联的实体的特定连接（例如，设备或位置）或对象（例如，多用户聊天室中的占用者）（即<localpart@domainpart/资源部分>）。
A resourcepart MUST be formatted such that the Resourceprep profile of [STRINGPREP] can be applied without failing (see Appendix B). Before comparing two resourceparts, an application MUST first ensure that the Resourceprep profile has been applied to each identifier (the profile need not be applied each time a comparison is made, as long as it has been applied before comparison).
resourcepart的格式必须确保[STRINGPREP]的Resourceprep配置文件可以应用而不会失败（参见附录B）。在比较两个ResourcePart之前，应用程序必须首先确保Resourceprep配置文件已应用于每个标识符（无需在每次进行比较时应用该配置文件，只要该配置文件已在比较之前应用）。
A resourcepart MUST NOT be zero bytes in length and MUST NOT be more than 1023 bytes in length. This rule is to be enforced after any mapping or normalization resulting from application of the Resourceprep profile of stringprep (e.g., in Resourceprep some characters can be mapped to nothing, which might result in a string of zero length).
resourcepart的长度不得为零字节，且不得超过1023字节。在应用stringprep的Resourceprep配置文件（例如，在Resourceprep中，某些字符可以映射为nothing，这可能导致字符串长度为零）后，将强制执行此规则。
Informational Note: For historical reasons, the term "resource identifier" is often used in XMPP to refer to the optional portion of an XMPP address that follows the domainpart and the "/" separator character; to help prevent confusion between an XMPP "resource identifier" and the meanings of "resource" and "identifier" provided in Section 1.1 of [URI], this specification uses the term "resourcepart" instead of "resource identifier" (as in RFC 3920).
信息性说明：出于历史原因，XMPP中经常使用术语“资源标识符”来表示在domainpart和“/”分隔符之后的XMPP地址的可选部分；为了帮助防止XMPP“资源标识符”与[URI]第1.1节中提供的“资源”和“标识符”含义之间的混淆，本规范使用术语“resourcepart”而不是“资源标识符”（如RFC 3920所示）。
XMPP entities SHOULD consider resourceparts to be opaque strings and SHOULD NOT impute meaning to any given resourcepart. In particular:
XMPP实体应该考虑资源部分是不透明的字符串，并且不应该将含义归咎于任何给定的资源部分。特别地：
o Use of the '/' character as a separator between the domainpart and the resourcepart does not imply that XMPP addresses are hierarchical in the way that, say, HTTP addresses are hierarchical; thus for example an XMPP address of the form <localpart@domainpart/foo/bar> does not identify a resource "bar" that exists below a resource "foo" in a hierarchy of resources associated with the entity "localpart@domain".
o 使用“/”字符作为domainpart和resourcepart之间的分隔符并不意味着XMPP地址的层次结构与HTTP地址的层次结构相同；例如，表单的XMPP地址<localpart@domainpart/foo/bar>未标识与实体关联的资源层次结构中资源“foo”下方存在的资源“bar”localpart@domain".
o The '@' character is allowed in the resourcepart and is often used in the "nick" shown in XMPP chatrooms. For example, the JID <room@chat.example.com/user@host> describes an entity who is an occupant of the room <room@chat.example.com> with an (asserted) nick of <user@host>. However, chatroom services do not necessarily check such an asserted nick against the occupant's real JID.
o resourcepart中允许使用“@”字符，并且经常在XMPP聊天室中显示的“nick”中使用。例如，JID<room@chat.example.com/user@host>描述作为房间占用者的实体<room@chat.example.com>带着（断言的）一丝<user@host>. 然而，聊天室服务不一定会根据住户的真实JID检查这样一个声称的尼克。
XMPP servers MUST, and XMPP clients SHOULD, support [IDNA2003] for domainparts (including the [NAMEPREP] profile of [STRINGPREP]), the Nodeprep (Appendix A) profile of [STRINGPREP] for localparts, and the Resourceprep (Appendix B) profile of [STRINGPREP] for resourceparts; this enables XMPP addresses to include a wide variety of characters outside the US-ASCII range. Rules for enforcement of the XMPP address format are provided in [XMPP].
XMPP服务器必须并且XMPP客户端应该支持domainparts的[IDNA2003]（包括[STRINGPREP]的[NAMEPREP]配置文件）、localparts的[STRINGPREP]的Nodeprep（附录A）配置文件以及resourceparts的[STRINGPREP]的Resourceprep（附录B）配置文件；这使XMPP地址能够包含US-ASCII范围之外的多种字符。[XMPP]中提供了XMPP地址格式的实施规则。
The security considerations described in [STRINGPREP] apply to the Nodeprep (Appendix A) and Resourceprep (Appendix B) profiles defined in this document for XMPP localparts and resourceparts. The security considerations described in [STRINGPREP] and [NAMEPREP] apply to the Nameprep profile that is reused here for XMPP domainparts.
[STRINGPREP]中描述的安全注意事项适用于本文档中为XMPP localparts和resourceparts定义的Nodeprep（附录A）和Resourceprep（附录B）配置文件。[STRINGPREP]和[NAMEPREP]中描述的安全注意事项适用于此处为XMPP domainparts重用的NAMEPREP配置文件。
The security considerations described in [UNICODE-SEC] apply to the use of Unicode characters in XMPP addresses.
[UNICODE-SEC]中描述的安全注意事项适用于在XMPP地址中使用UNICODE字符。
There are two forms of address spoofing: forging and mimicking.
地址欺骗有两种形式：伪造和模仿。
In the context of XMPP technologies, address forging occurs when an entity is able to generate an XML stanza whose 'from' address does not correspond to the account credentials with which the entity authenticated onto the network (or an authorization identity provided during negotiation of SASL authentication [SASL] as described in [XMPP]). For example, address forging occurs if an entity that authenticated as "juliet@im.example.com" is able to send XML stanzas from "nurse@im.example.com" or "romeo@example.net".
在XMPP技术的上下文中，当一个实体能够生成一个XML节时，就会发生地址伪造，该XML节的“发件人”地址与该实体在网络上进行身份验证时使用的帐户凭据（或在SASL身份验证[SASL]协商期间提供的授权标识，如[XMPP]中所述）不一致。例如，如果验证为“”的实体发生地址伪造juliet@im.example.com“能够从发送XML节”nurse@im.example.com“或”romeo@example.net".
Address forging is difficult in XMPP systems, given the requirement for sending servers to stamp 'from' addresses and for receiving servers to verify sending domains via server-to-server authentication (see [XMPP]). However, address forging is possible if:
在XMPP系统中，地址伪造是很困难的，因为发送服务器需要标记“发件人”地址，接收服务器需要通过服务器到服务器的身份验证验证发送域（参见[XMPP]）。但是，如果：
o A poorly implemented server ignores the requirement for stamping the 'from' address. This would enable any entity that authenticated with the server to send stanzas from any localpart@domainpart as long as the domainpart matches the sending domain of the server.
o 实现不佳的服务器忽略了在“发件人”地址上加盖戳记的要求。这将使任何通过服务器身份验证的实体都能够从任何服务器发送节localpart@domainpart只要domainpart与服务器的发送域匹配。
o An actively malicious server generates stanzas on behalf of any registered account.
o 主动恶意服务器代表任何已注册帐户生成节。
Therefore, an entity outside the security perimeter of a particular server cannot reliably distinguish between JIDs of the form <localpart@domainpart> at that server and thus can authenticate only the domainpart of such JIDs with any level of assurance. This specification does not define methods for discovering or counteracting such poorly implemented or rogue servers. However, the end-to-end authentication or signing of XMPP stanzas could help to mitigate this risk, since it would require the rogue server to generate false credentials in addition to modifying 'from' addresses.
因此，特定服务器安全外围之外的实体无法可靠地区分表单的JID<localpart@domainpart>在该服务器上，因此只能以任何级别的保证对此类JID的域部分进行身份验证。本规范未定义用于发现或抵制此类实施不善或恶意服务器的方法。但是，XMPP节的端到端身份验证或签名可能有助于降低这一风险，因为除了修改“发件人”地址外，还需要恶意服务器生成虚假凭据。
Furthermore, it is possible for an attacker to forge JIDs at other domains by means of a DNS poisoning attack if DNS security extensions [DNSSEC] are not used.
此外，如果不使用DNS安全扩展[DNSSEC]，攻击者有可能通过DNS中毒攻击在其他域伪造JID。
Address mimicking occurs when an entity provides legitimate authentication credentials for and sends XML stanzas from an account whose JID appears to a human user to be the same as another JID. For example, in some XMPP clients the address "ju1iet@example.org" (spelled with the number one as the third character of the localpart) might appear to be the same as "juliet@example.org (spelled with the lower-case version of the letter "L"), especially on casual visual
当一个实体为一个帐户提供合法的身份验证凭据并从该帐户发送XML节时，地址模拟就会发生。在人类用户看来，该帐户的JID与另一个JID相同。例如，在某些XMPP客户端中，地址为“ju1iet@example.org“（用数字1作为localpart的第三个字符拼写）可能看起来与”juliet@example.org（用字母“L”的小写字母拼写），尤其是在随意的视觉上
inspection; this phenomenon is sometimes called "typejacking". A more sophisticated example of address mimicking might involve the use of characters from outside the familiar Latin extended-A block of Unicode code points, such as the characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 from the Cherokee block instead of the similar-looking US-ASCII characters "STPETER".
视察这种现象有时被称为“类型劫持”。一个更复杂的地址模拟示例可能涉及使用来自熟悉的拉丁扩展（Unicode代码点块）之外的字符，例如切诺基块中的字符U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2，而不是类似的US-ASCII字符“STPETER”。
In some examples of address mimicking, it is unlikely that the average user could tell the difference between the real JID and the fake JID. (Indeed, there is no programmatic way to distinguish with full certainty which is the fake JID and which is the real JID; in some communication contexts, the JID formed of Cherokee characters might be the real JID and the JID formed of US-ASCII characters might thus appear to be the fake JID.) Because JIDs can contain almost any properly encoded Unicode code point, it can be relatively easy to mimic some JIDs in XMPP systems. The possibility of address mimicking introduces security vulnerabilities of the kind that have also plagued the World Wide Web, specifically the phenomenon known as phishing.
在一些地址模拟的例子中，普通用户不太可能分辨出真假JID的区别。（事实上，没有一种编程方法可以完全确定地区分哪一个是假JID，哪一个是真JID；在某些通信上下文中，切诺基字符形成的JID可能是真JID，而US-ASCII字符形成的JID可能因此看起来是假JID。）因为JID几乎可以包含任何正确编码的Unicode代码点，所以在XMPP系统中模拟某些JID相对容易。地址模仿的可能性引入了同样困扰万维网的安全漏洞，特别是网络钓鱼现象。
These problems arise because Unicode and ISO/IEC 10646 repertoires have many characters that look similar (so-called "confusable characters" or "confusables"). In many cases, XMPP users might perform visual matching, such as when comparing the JIDs of communication partners. Because it is impossible to map similar-looking characters without a great deal of context (such as knowing the fonts used), stringprep and stringprep-based technologies such as Nameprep, Nodeprep, and Resourceprep do nothing to map similar-looking characters together, nor do they prohibit some characters because they look like others. As a result, XMPP localparts and resourceparts could contain confusable characters, producing JIDs that appear to mimic other JIDs and thus leading to security vulnerabilities such as the following:
出现这些问题是因为Unicode和ISO/IEC10646指令集有许多看起来相似的字符（所谓的“可混淆字符”或“可混淆字符”）。在许多情况下，XMPP用户可能会执行视觉匹配，例如在比较通信伙伴的JID时。因为在没有大量上下文的情况下（例如知道使用的字体），不可能映射相似外观的字符，因此stringprep和基于stringprep的技术（如Nameprep、Nodeprep和Resourceprep）无法将相似外观的字符映射在一起，也不能禁止某些字符，因为它们看起来像其他字符。因此，XMPP localparts和resourceparts可能包含易混淆的字符，从而产生模仿其他JID的JID，从而导致以下安全漏洞：
o A localpart can be employed as one part of an entity's address in XMPP. One common usage is as the username of an instant messaging user; another is as the name of a multi-user chat room; and many other kinds of entities could use localparts as part of their addresses. The security of such services could be compromised based on different interpretations of the internationalized localpart; for example, a user entering a single internationalized localpart could access another user's account information, or a user could gain access to a hidden or otherwise restricted chat room or service.
o localpart可以用作XMPP中实体地址的一部分。一种常见用法是作为即时消息用户的用户名；另一种是作为多用户聊天室的名称；许多其他类型的实体可以使用localparts作为其地址的一部分。基于对国际化本地部分的不同解释，此类服务的安全性可能会受到损害；例如，输入单个国际化localpart的用户可以访问另一个用户的帐户信息，或者用户可以访问隐藏的或受限的聊天室或服务。
o A resourcepart can be employed as one part of an entity's address in XMPP. One common usage is as the name for an instant messaging user's connected resource; another is as the nickname of a user in
o resourcepart可以用作XMPP中实体地址的一部分。一种常见用法是作为即时消息用户连接资源的名称；另一个是作为用户的昵称
a multi-user chat room; and many other kinds of entities could use resourceparts as part of their addresses. The security of such services could be compromised based on different interpretations of the internationalized resourcepart; for example, two or more confusable resources could be bound at the same time to the same account (resulting in inconsistent authorization decisions in an XMPP application that uses full JIDs), or a user could send a message to someone other than the intended recipient in a multi-user chat room.
多用户聊天室；许多其他类型的实体可以使用resourceparts作为其地址的一部分。基于对国际化资源部分的不同解释，此类服务的安全性可能会受到损害；例如，两个或多个易混淆的资源可以同时绑定到同一个帐户（导致使用完整JID的XMPP应用程序中的授权决策不一致），或者用户可以向多用户聊天室中的预期收件人以外的其他人发送消息。
Despite the fact that some specific suggestions about identification and handling of confusable characters appear in the Unicode Security Considerations [UNICODE-SEC], it is also true (as noted in [IDNA-DEFS]) that "there are no comprehensive technical solutions to the problems of confusable characters". Mimicked JIDs that involve characters from only one script, or from the script typically employed by a particular user or community of language users, are not easy to combat (e.g., the simple typejacking attack previously described, which relies on a surface similarity between the characters "1" and "l" in some presentations). However, mimicked addresses that involve characters from more than one script, or from a script not typically employed by a particular user or community of language users, can be mitigated somewhat through the application of appropriate registration policies at XMPP services and presentation policies in XMPP client software. Therefore, the following policies are encouraged:
尽管Unicode安全注意事项[Unicode-SEC]中出现了一些关于易混淆字符的识别和处理的具体建议，但（如[IDNA-DEFS]中所述）“对于易混淆字符的问题没有全面的技术解决方案”也是正确的。仅涉及一个脚本中的角色或特定用户或语言用户社区通常使用的脚本中的角色的模拟JID不容易对抗（例如，前面描述的简单的类型劫持攻击，它依赖于某些演示文稿中字符“1”和“l”之间的表面相似性）。但是，通过在XMPP服务中应用适当的注册策略和在XMPP客户端软件中应用表示策略，可以在一定程度上缓解涉及多个脚本中的字符或特定用户或语言用户社区通常不使用的脚本中的字符的模拟地址。因此，鼓励采取以下政策：
1. Because an XMPP service that allows registration of XMPP user accounts (localparts) plays a role similar to that of a registry for DNS domain names, such a service SHOULD establish a policy about the scripts or blocks of characters it will allow in localparts at the service. Such a policy is likely to be informed by the languages and scripts that are used to write registered account names; in particular, to reduce confusion, the service MAY forbid registration of XMPP localparts that contain characters from more than one script and to restrict registrations to characters drawn from a very small number of scripts (e.g., scripts that are well-understood by the administrators of the service). Such policies are also appropriate for XMPP services that allow temporary or permanent registration of XMPP resourceparts, e.g., during resource binding [XMPP] or upon joining an XMPP-based chat room [XEP-0045]. For related considerations in the context of domain name registration, refer to Section 4.3 of [IDNA-PROTO] and Section 3.2 of [IDNA-RATIONALE]. Note well that methods for enforcing such restrictions are out of scope for this document.
1. 由于允许注册XMPP用户帐户（localparts）的XMPP服务所起的作用类似于DNS域名注册中心的作用，因此此类服务应建立一个有关其将在服务的localparts中允许的脚本或字符块的策略。此类政策可能由用于书写注册账户名称的语言和脚本通知；特别是，为了减少混淆，服务可能会禁止注册包含多个脚本中的字符的XMPP LocalPart，并将注册限制为从极少数脚本（例如，服务管理员完全理解的脚本）中提取的字符。此类策略也适用于允许临时或永久注册XMPP ResourcePart的XMPP服务，例如，在资源绑定[XMPP]期间或加入基于XMPP的聊天室[XEP-0045]时。有关域名注册的相关注意事项，请参阅[IDNA-PROTO]第4.3节和[IDNA-PROTO]第3.2节。请注意，强制执行此类限制的方法超出了本文档的范围。
2. Because every human user of an XMPP client presumably has a preferred language (or, in some cases, a small set of preferred languages), an XMPP client SHOULD gather that information either explicitly from the user or implicitly via the operating system of the user's device. Furthermore, because most languages are typically represented by a single script (or a small set of scripts) and most scripts are typically contained in one or more blocks of characters, an XMPP client SHOULD warn the user when presenting a JID that mixes characters from more than one script or block, or that uses characters outside the normal range of the user's preferred language(s). This recommendation is not intended to discourage communication across different communities of language users; instead, it recognizes the existence of such communities and encourages due caution when presenting unfamiliar scripts or characters to human users.
2. 因为XMPP客户机的每个人类用户可能都有一种首选语言（或者，在某些情况下，一小部分首选语言），所以XMPP客户机应该显式地从用户那里收集信息，或者通过用户设备的操作系统隐式地收集信息。此外，由于大多数语言通常由单个脚本（或一小组脚本）表示，并且大多数脚本通常包含在一个或多个字符块中，因此当呈现混合了多个脚本或块中的字符的JID时，XMPP客户机应向用户发出警告，或者使用超出用户首选语言正常范围的字符。本建议的目的不是阻止不同语言使用者社区之间的交流；相反，它认识到这些社区的存在，并鼓励在向人类用户呈现不熟悉的脚本或字符时谨慎行事。
The following sections update the registrations provided in [RFC3920].
以下章节更新了[RFC3920]中提供的注册。
The Nodeprep profile of stringprep is defined under Nodeprep (Appendix A). The IANA has registered Nodeprep in the "Stringprep Profiles" registry.
stringprep的Nodeprep配置文件在Nodeprep（附录A）中定义。IANA已在“Stringprep配置文件”注册表中注册了Nodeprep。
Name of this profile:
此配置文件的名称：
Nodeprep
Nodeprep
RFC in which the profile is defined:
定义配置文件的RFC：
RFC 6122
RFC6122
Indicator whether or not this is the newest version of the profile:
指示此配置文件是否为最新版本：
This is the first version of Nodeprep
这是Nodeprep的第一个版本
The Resourceprep profile of stringprep is defined under Resourceprep (Appendix B). The IANA has registered Resourceprep in the "Stringprep Profiles" registry.
stringprep的Resourceprep配置文件在Resourceprep（附录B）下定义。IANA已在“Stringprep配置文件”注册表中注册Resourceprep。
Name of this profile:
此配置文件的名称：
Resourceprep
资源准备
RFC in which the profile is defined:
定义配置文件的RFC：
RFC 6122
RFC6122
Indicator whether or not this is the newest version of the profile:
指示此配置文件是否为最新版本：
This is the first version of Resourceprep
这是Resourceprep的第一个版本
This section describes a protocol feature set that summarizes the conformance requirements of this specification. This feature set is appropriate for use in software certification, interoperability testing, and implementation reports. For each feature, this section provides the following information:
本节描述了协议功能集，该功能集总结了本规范的一致性要求。此功能集适用于软件认证、互操作性测试和实施报告。对于每个功能，本节提供以下信息：
o A human-readable name
o 人名
o An informational description
o 信息性描述
o A reference to the particular section of this document that normatively defines the feature
o 对本文件中规范性定义特征的特定章节的参考
o Whether the feature applies to the Client role, the Server role, or both (where "N/A" signifies that the feature is not applicable to the specified role)
o 该功能是否适用于客户端角色、服务器角色或两者（其中“N/A”表示该功能不适用于指定角色）
o Whether the feature MUST or SHOULD be implemented, where the capitalized terms are to be understood as described in [KEYWORDS]
o 是否必须或应该实施该功能，其中大写术语应按照[关键字]中所述理解
The feature set specified here attempts to adhere to the concepts and formats proposed by Larry Masinter within the IETF's NEWTRK Working Group in 2005, as captured in [INTEROP]. Although this feature set is more detailed than called for by [REPORTS], it provides a suitable basis for the generation of implementation reports to be submitted in support of advancing this specification from Proposed Standard to Draft Standard in accordance with [PROCESS].
此处指定的功能集试图遵循Larry Masinter于2005年在IETF的NEWTRK工作组中提出的概念和格式，如[INTEROP]中所述。尽管该功能集比[报告]要求的更详细，但它为生成提交的实施报告提供了合适的基础，以支持根据[过程]将本规范从拟定标准推进到标准草案。
Feature: address-domain-length Description: Ensure that the domainpart of an XMPP address is at least one byte in length and at most 1023 bytes in length, and conforms to the underlying length limits of the DNS. Section: Section 2.2 Roles: Both MUST.
功能：地址域长度描述：确保XMPP地址的domainpart长度至少为一个字节，最多为1023个字节，并符合DNS的基本长度限制。第2.2节角色：两者都必须。
Feature: address-domain-prep Description: Ensure that the domainpart of an XMPP address conforms to the Nameprep profile of stringprep. Section: Section 2.2 Roles: Client SHOULD, Server MUST.
功能：地址域准备说明：确保XMPP地址的domainpart符合stringprep的Nameprep配置文件。第2.2节角色：客户端应该，服务器必须。
Feature: address-localpart-length Description: Ensure that the localpart of an XMPP address is at least one byte in length and at most 1023 bytes in length. Section: Section 2.3 Roles: Both MUST.
功能：地址localpart长度描述：确保XMPP地址的localpart长度至少为一个字节，最多为1023个字节。第2.3节角色：两者都必须。
Feature: address-localpart-prep Description: Ensure that the localpart of an XMPP address conforms to the Nodeprep profile of stringprep. Section: Section 2.3 Roles: Client SHOULD, Server MUST.
功能：address localpart prep描述：确保XMPP地址的localpart符合stringprep的Nodeprep配置文件。第2.3节角色：客户端应该，服务器必须。
Feature: address-resource-length Description: Ensure that the resourcepart of an XMPP address is at least one byte in length and at most 1023 bytes in length. Section: Section 2.4 Roles: Both MUST.
功能：地址资源长度描述：确保XMPP地址的resourcepart长度至少为一个字节，最多为1023个字节。第2.4节角色：两者都必须。
Feature: address-resource-prep Description: Ensure that the resourcepart of an XMPP address conforms to the Resourceprep profile of stringprep. Section: Section 2.4 Roles: Client SHOULD, Server MUST.
功能：地址资源准备说明：确保XMPP地址的resourcepart符合stringprep的Resourceprep配置文件。第2.4节角色：客户端应该，服务器必须。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[IDNA2003] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[IDNA2003]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
See Section 1 for an explanation of why the normative reference to an obsoleted specification is needed.
参见第1节，了解为什么需要对已过时规范进行规范性引用。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[NAMEPREP]Hoffman，P.和M.Blanchet，“NAMEPREP：国际化域名（IDN）的Stringprep配置文件”，RFC 34912003年3月。
See Section 1 for an explanation of why the normative reference to an obsoleted specification is needed.
参见第1节，了解为什么需要对已过时规范进行规范性引用。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[STRINGPREP]Hoffman，P.和M.Blanchet，“国际化弦的准备（“STRINGPREP”）”，RFC 3454，2002年12月。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 3.2.0", 2000. The Unicode Standard, Version 3.2.0 is defined by The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/) and by the Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/).
[UNICODE]UNICODE联盟，“UNICODE标准，3.2.0版”，2000年。Unicode标准3.2.0版由Unicode标准3.0版（雷丁，马萨诸塞州，Addison-Wesley，2000.ISBN 0-201-61633-5）定义，并由Unicode标准附录27:Unicode 3.1修订(http://www.unicode.org/reports/tr27/)根据Unicode标准附录#28:Unicode 3.2(http://www.unicode.org/reports/tr28/).
[UNICODE-SEC] The Unicode Consortium, "Unicode Technical Report #36: Unicode Security Considerations", 2008, <http://www.unicode.org/reports/tr36/>.
[UNICODE-SEC]UNICODE联盟，“UNICODE技术报告#36：UNICODE安全注意事项”，2008年<http://www.unicode.org/reports/tr36/>.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[XMPP]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC61202011年3月。
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[DNSSEC]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[IDNA-DEFS] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[IDNA-DEFS]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[IDNA-PROTO] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[IDNA-PROTO]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 58912010年8月。
[IDNA-RATIONALE] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010.
[IDNA-基本原理]Klensin，J.“应用程序的国际化域名（IDNA）：背景、解释和基本原理”，RFC 58942010年8月。
[INTEROP] Masinter, L., "Formalizing IETF Interoperability Reporting", Work in Progress, October 2005.
[INTEROP]Masinter，L.，“IETF互操作性报告的形式化”，正在进行的工作，2005年10月。
[IRI] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[IRI]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[PROCESS] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[过程]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[PUNYCODE] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[PUNYCODE]Costello，A.，“PUNYCODE：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，2003年3月。
[REPORTS] Dusseault, L. and R. Sparks, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", BCP 9, RFC 5657, September 2009.
[报告]Dusseault，L.和R.Sparks，“推进标准草案的互操作和实施报告指南”，BCP 9，RFC 5657，2009年9月。
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC3920]Saint Andre，P.，Ed.“可扩展消息和状态协议（XMPP）：核心”，RFC 3920，2004年10月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月。
[SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL]Melnikov，A.，Ed.和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[XEP-0029] Kaes, C., "Definition of Jabber Identifiers (JIDs)", XSF XEP 0029, October 2003.
[XEP-0029]Kaes，C.“Jabber标识符（JID）的定义”，XSF XEP 00292003年10月。
[XEP-0030] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-Andre, "Service Discovery", XSF XEP 0030, June 2008.
[XEP-0030]Hildebrand，J.，Millard，P.，Eatmon，R.，和P.Saint Andre，“服务发现”，XSF XEP 0030，2008年6月。
[XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, July 2008.
[XEP-0045]圣安德烈，P.，“多用户聊天”，XSF XEP 00452008年7月。
[XEP-0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish-Subscribe", XSF XEP 0060, July 2010.
[XEP-0060]Millard，P.，Saint Andre，P.，和R.Meijer，“发布-订阅”，XSF XEP 0060，2010年7月。
[XEP-0165] Saint-Andre, P., "Best Practices to Discourage JID Mimicking", XSF XEP 0045, December 2007.
[XEP-0165]圣安德烈，P.，“阻止JID模仿的最佳实践”，XSF XEP 0045，2007年12月。
[XML] Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium Recommendation REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816>.
[XML]Paoli，J.，Maler，E.，Sperberg McQueen，C.，Yergeau，F.，和T.Bray，“可扩展标记语言（XML）1.0（第四版）”，万维网联盟建议REC-XML-20060816，2006年8月<http://www.w3.org/TR/2006/REC-xml-20060816>.
[XMPP-URI] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008.
[XMPP-URI]Saint Andre，P.，“可扩展消息传递和存在协议（XMPP）的国际化资源标识符（IRI）和统一资源标识符（URI）”，RFC 5122，2008年2月。
This appendix defines the "Nodeprep" profile of stringprep. As such, it specifies processing rules that will enable users to enter internationalized localparts in the Extensible Messaging and Presence Protocol (XMPP) and have the highest chance of getting the content of the strings correct. (An XMPP localpart is the optional portion of an XMPP address that precedes an XMPP domainpart and the '@' separator; it is often but not exclusively associated with an instant messaging username.) These processing rules are intended only for XMPP localparts and are not intended for arbitrary text or any other aspect of an XMPP address.
本附录定义了stringprep的“Nodeprep”配置文件。因此，它指定了处理规则，使用户能够在可扩展消息和状态协议（XMPP）中输入国际化的LocalPart，并有最大的机会获得正确的字符串内容。（XMPP localpart是XMPP地址的可选部分，位于XMPP domainpart和“@”分隔符之前；它通常但不完全与即时消息用户名关联。）这些处理规则仅适用于XMPP localpart，不适用于任意文本或XMPP地址的任何其他方面。
This profile defines the following, as required by [STRINGPREP]:
根据[STRINGPREP]的要求，此配置文件定义了以下内容：
o The intended applicability of the profile: internationalized localparts within XMPP
o 概要文件的预期适用性：XMPP中的国际化localparts
o The character repertoire that is the input and output to stringprep: Unicode 3.2, specified in A.2
o 作为stringprep:Unicode 3.2的输入和输出的字符集，在A.2中指定
o The mappings used: specified in A.3
o 使用的映射：在A.3中指定
o The Unicode normalization used: specified in A.4
o 使用的Unicode规范化：在A.4中指定
o The characters that are prohibited as output: specified in A.5
o 禁止作为输出的字符：在A.5中指定
o Bidirectional character handling: specified in A.6
o 双向字符处理：在A.6中规定
This profile uses Unicode 3.2 with the list of unassigned code points in Table A.1, both as defined in Appendix A of [STRINGPREP].
此配置文件使用Unicode 3.2和表A.1中的未分配代码点列表，两者均在[STRINGPREP]的附录A中定义。
This profile specifies mapping using the following tables from [STRINGPREP]:
此配置文件使用[STRINGPREP]中的下表指定映射：
Table B.1 Table B.2
表B.1表B.2
This profile specifies the use of Unicode Normalization Form KC, as described in [STRINGPREP].
此配置文件指定使用Unicode规范化表单KC，如[STRINGPREP]中所述。
This profile specifies the prohibition of using the following tables from [STRINGPREP].
此配置文件指定禁止使用[STRINGPREP]中的下表。
Table C.1.1 Table C.1.2 Table C.2.1 Table C.2.2 Table C.3 Table C.4 Table C.5 Table C.6 Table C.7 Table C.8 Table C.9
表C.1.1表C.1.2表C.2.1表C.2.2表C.3表C.4表C.5表C.6表C.7表C.8表C.9
In addition, the following additional Unicode characters are also prohibited:
此外，还禁止使用以下额外的Unicode字符：
U+0022 (QUOTATION MARK), i.e., "
U+0026 (AMPERSAND), i.e., &
U+0027 (APOSTROPHE), i.e., '
U+002F (SOLIDUS), i.e., /
U+003A (COLON), i.e., :
U+003C (LESS-THAN SIGN), i.e., <
U+003E (GREATER-THAN SIGN), i.e., >
U+0040 (COMMERCIAL AT), i.e., @
U+0022 (QUOTATION MARK), i.e., "
U+0026 (AMPERSAND), i.e., &
U+0027 (APOSTROPHE), i.e., '
U+002F (SOLIDUS), i.e., /
U+003A (COLON), i.e., :
U+003C (LESS-THAN SIGN), i.e., <
U+003E (GREATER-THAN SIGN), i.e., >
U+0040 (COMMERCIAL AT), i.e., @
This profile specifies checking bidirectional strings, as described in Section 6 of [STRINGPREP].
此配置文件指定检查双向字符串，如[STRINGPREP]第6节所述。
Because the additional characters prohibited by Nodeprep are prohibited after normalization, an implementation MUST NOT enable a human user to input any Unicode code point whose decomposition includes those characters; such code points include but are not necessarily limited to the following (refer to [UNICODE] for complete information):
由于Nodeprep禁止的附加字符在规范化后被禁止，因此实现不能允许人类用户输入任何分解包含这些字符的Unicode代码点；此类代码点包括但不一定限于以下内容（有关完整信息，请参阅[UNICODE]：
o U+2100 (ACCOUNT OF) o U+2101 (ADDRESSED TO THE SUBJECT) o U+2105 (CARE OF) o U+2106 (CADA UNA) o U+226E (NOT LESS-THAN) o U+226F (NOT GREATER-THAN) o U+2A74 (DOUBLE COLON EQUAL) o U+FE13 (PRESENTATION FORM FOR VERTICAL COLON) o U+FE60 (SMALL AMPERSAND) o U+FE64 (SMALL LESS-THAN SIGN) o U+FE65 (SMALL GREATER-THAN SIGN) o U+FE6B (SMALL COMMERCIAL AT) o U+FF02 (FULLWIDTH QUOTATION MARK) o U+FF06 (FULLWIDTH AMPERSAND) o U+FF07 (FULLWIDTH APOSTROPHE) o U+FF0F (FULLWIDTH SOLIDUS) o U+FF1A (FULLWIDTH COLON) o U+FF1C (FULLWIDTH LESS-THAN SIGN) o U+FF1E (FULLWIDTH GREATER-THAN SIGN) o U+FF20 (FULLWIDTH COMMERCIAL AT)
o U+2100（账户）o U+2101（致受试者）o U+2105（照管）o U+2106（CADA UNA）o U+226E（不小于）o U+226F（不大于）o U+2A74（双冒号相等）o U+FE13（垂直冒号表示形式）o U+FE60（小符号）o U+FE64（小符号小于号）o U+FE65（小符号大于号）o U+FE6B（小商业AT）o U+FF02（全宽引号）o U+FF06（全宽符号）o U+FF07（全宽撇号）o U+FF0F（全宽实线）o U+FF1A（全宽冒号）o U+FF1C（全宽小于号）o U+FF1E（全宽大于号）o U+FF20（全宽商业AT）
This appendix defines the "Resourceprep" profile of stringprep. As such, it specifies processing rules that will enable users to enter internationalized resourceparts in the Extensible Messaging and Presence Protocol (XMPP) and have the highest chance of getting the content of the strings correct. (An XMPP resourcepart is the optional portion of an XMPP address that follows an XMPP domainpart and the '/' separator.) These processing rules are intended only for XMPP resourceparts and are not intended for arbitrary text or any other aspect of an XMPP address.
本附录定义了stringprep的“Resourceprep”配置文件。因此，它指定了处理规则，使用户能够在可扩展消息和状态协议（XMPP）中输入国际化的ResourcePart，并有最大的机会获得正确的字符串内容。（XMPP resourcepart是XMPP地址的可选部分，位于XMPP domainpart和“/”分隔符之后。）这些处理规则仅适用于XMPP resourcepart，不适用于任意文本或XMPP地址的任何其他方面。
This profile defines the following, as required by [STRINGPREP]:
根据[STRINGPREP]的要求，此配置文件定义了以下内容：
o The intended applicability of the profile: internationalized resourceparts within XMPP
o 概要文件的预期适用性：XMPP中的国际化resourceparts
o The character repertoire that is the input and output to stringprep: Unicode 3.2, specified in B.2
o 作为stringprep:Unicode 3.2的输入和输出的字符集，在B.2中指定
o The mappings used: specified in B.3
o 使用的映射：在B.3中指定
o The Unicode normalization used: specified in B.4
o 使用的Unicode规范化：在B.4中指定
o The characters that are prohibited as output: specified in B.5
o 禁止输出的字符：在B.5中规定
o Bidirectional character handling: specified in B.6
o 双向字符处理：在B.6中规定
This profile uses Unicode 3.2 with the list of unassigned code points in Table A.1, both as defined in Appendix A of [STRINGPREP].
此配置文件使用Unicode 3.2和表A.1中的未分配代码点列表，两者均在[STRINGPREP]的附录A中定义。
This profile specifies mapping using the following tables from [STRINGPREP]:
此配置文件使用[STRINGPREP]中的下表指定映射：
Table B.1
表B.1
This profile specifies the use of Unicode Normalization Form KC, as described in [STRINGPREP].
此配置文件指定使用Unicode规范化表单KC，如[STRINGPREP]中所述。
This profile specifies the prohibition of using the following tables from [STRINGPREP].
此配置文件指定禁止使用[STRINGPREP]中的下表。
Table C.1.2 Table C.2.1 Table C.2.2 Table C.3 Table C.4 Table C.5 Table C.6 Table C.7 Table C.8 Table C.9
表C.1.2表C.2.1表C.2.2表C.3表C.4表C.5表C.6表C.7表C.8表C.9
This profile specifies checking bidirectional strings, as described in Section 6 of [STRINGPREP].
此配置文件指定检查双向字符串，如[STRINGPREP]第6节所述。
Based on consensus derived from implementation and deployment experience as well as formal interoperability testing, the following substantive modifications were made from RFC 3920.
基于从实施和部署经验以及正式互操作性测试中得出的共识，RFC 3920进行了以下实质性修改。
o Corrected the ABNF syntax to ensure consistency with [URI] and [IRI], including consistency with RFC 3986 and [RFC5952] with regard to IPv6 addresses (e.g., enclosing the IPv6 address in square brackets '[' and ']' -- see also Section 4.9.3.19 of [XMPP]).
o 更正了ABNF语法，以确保与[URI]和[IRI]的一致性，包括与RFC 3986和[RFC5952]在IPv6地址方面的一致性（例如，将IPv6地址括在方括号“[”和“]”中，另请参见[XMPP]第4.9.3.19节）。
o Corrected the ABNF syntax to prevent zero-length localparts, domainparts, and resourceparts (and also noted that the underlying length limits from the DNS apply to domainparts).
o 更正了ABNF语法以防止长度为零的localparts、domainparts和resourceparts（还注意到DNS的基本长度限制适用于domainparts）。
o To avoid confusion with the term "node" as used in [XEP-0030] and [XEP-0060], changed the term "node identifier" to "localpart" (but retained the name "Nodeprep" for backward compatibility).
o 为了避免与[XEP-0030]和[XEP-0060]中使用的术语“节点”混淆，将术语“节点标识符”更改为“localpart”（但为了向后兼容，保留了名称“Nodeprep”）。
o To avoid confusion with the terms "resource" and "identifier" as used in [URI], changed the term "resource identifier" to "resourcepart".
o 为了避免与[URI]中使用的术语“资源”和“标识符”混淆，将术语“资源标识符”更改为“resourcepart”。
o Corrected the Nameprep processing rules to require use of the UseSTD3ASCIIRules flag.
o 已更正Nameprep处理规则，以要求使用UseSTD3ASCIIRules标志。
Thanks to Ben Campbell, Waqas Hussain, Jehan Pages, and Florian Zeitz for their feedback. Thanks also to Richard Barnes and Elwyn Davies for their reviews on behalf of the Security Directorate and the General Area Review Team, respectively.
感谢Ben Campbell、Waqas Hussain、Jehan Pages和Florian Zeitz的反馈。还感谢Richard Barnes和Elwyn Davies分别代表安全理事会和一般区域审查小组进行审查。
The Working Group chairs were Ben Campbell and Joe Hildebrand. The responsible Area Director was Gonzalo Camarillo.
工作组主席是本·坎贝尔和乔·希尔德布兰德。负责区域的主管是冈萨洛·卡马里洛。
Some text in this document was borrowed or adapted from [IDNA-DEFS], [IDNA-PROTO], [IDNA-RATIONALE], and [XEP-0165].
本文件中的一些文本借用或改编自[IDNA-DEFS]、[IDNA-PROTO]、[IDNA-REQUALITY]和[XEP-0165]。
Author's Address
作者地址
Peter Saint-Andre Cisco 1899 Wyknoop Street, Suite 600 Denver, CO 80202 USA
美国科罗拉多州丹佛市怀诺普街1899号600室彼得·圣安德烈思科公司80202
Phone: +1-303-308-3282
EMail: psaintan@cisco.com
Phone: +1-303-308-3282
EMail: psaintan@cisco.com