Network Working Group P. Saint-Andre, Ed.
Request for Comments: 3920 Jabber Software Foundation
Category: Standards Track October 2004
Network Working Group P. Saint-Andre, Ed.
Request for Comments: 3920 Jabber Software Foundation
Category: Standards Track October 2004
Extensible Messaging and Presence Protocol (XMPP): Core
可扩展消息和状态协议（XMPP）：核心
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.
本备忘录定义了可扩展消息和状态协议（XMPP）的核心功能，XMPP是一种流式传输可扩展标记语言（XML）元素的协议，用于在任意两个网络端点之间近实时地交换结构化信息。虽然XMPP为交换XML数据提供了一个通用的、可扩展的框架，但它主要用于构建满足RFC2779要求的即时消息和状态应用程序。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Generalized Architecture . . . . . . . . . . . . . . . . . . 3
3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 5
4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Use of SASL . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 37
8. Server Dialback . . . . . . . . . . . . . . . . . . . . . . 41
9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 48
10. Server Rules for Handling XML Stanzas . . . . . . . . . . . 58
11. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 60
12. Core Compliance Requirements . . . . . . . . . . . . . . . . 62
13. Internationalization Considerations . . . . . . . . . . . . 64
14. Security Considerations . . . . . . . . . . . . . . . . . . 64
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 69
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B. Resourceprep . . . . . . . . . . . . . . . . . . . . . . . . 76
C. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 78
D. Differences Between Core Jabber Protocols and XMPP . . . . . 87
Contributors. . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . 89
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 89
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 90
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Generalized Architecture . . . . . . . . . . . . . . . . . . 3
3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 5
4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Use of SASL . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 37
8. Server Dialback . . . . . . . . . . . . . . . . . . . . . . 41
9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 48
10. Server Rules for Handling XML Stanzas . . . . . . . . . . . 58
11. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 60
12. Core Compliance Requirements . . . . . . . . . . . . . . . . 62
13. Internationalization Considerations . . . . . . . . . . . . 64
14. Security Considerations . . . . . . . . . . . . . . . . . . 64
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 69
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B. Resourceprep . . . . . . . . . . . . . . . . . . . . . . . . 76
C. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 78
D. Differences Between Core Jabber Protocols and XMPP . . . . . 87
Contributors. . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . 89
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 89
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 90
The Extensible Messaging and Presence Protocol (XMPP) is an open Extensible Markup Language [XML] protocol for near-real-time messaging, presence, and request-response services. The basic syntax and semantics were developed originally within the Jabber open-source community, mainly in 1999. In 2002, the XMPP WG was chartered with developing an adaptation of the Jabber protocol that would be suitable as an IETF instant messaging (IM) and presence technology. As a result of work by the XMPP WG, the current memo defines the core features of XMPP 1.0; the extensions required to provide the instant messaging and presence functionality defined in RFC 2779 [IMP-REQS] are specified in the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence [XMPP-IM].
可扩展消息和状态协议（XMPP）是一种开放的可扩展标记语言[XML]协议，用于近实时消息、状态和请求-响应服务。基本语法和语义最初是在Jabber开源社区内开发的，主要是在1999年。2002年，XMPP工作组获得特许，负责开发适用于IETF即时消息（IM）和状态显示技术的Jabber协议的改编。作为XMPP工作组工作的结果，当前备忘录定义了XMPP 1.0的核心特性；提供RFC 2779[IMP-REQS]中定义的即时消息和状态功能所需的扩展在可扩展消息和状态协议（XMPP）：即时消息和状态[XMPP-IM]中指定。
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [TERMS].
本文件中大写的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[条款]的规定进行解释。
Although XMPP is not wedded to any specific network architecture, to date it usually has been implemented via a client-server architecture wherein a client utilizing XMPP accesses a server over a [TCP] connection, and servers also communicate with each other over TCP connections.
尽管XMPP不与任何特定的网络体系结构相结合，但迄今为止，它通常是通过客户机-服务器体系结构实现的，其中使用XMPP的客户机通过[TCP]连接访问服务器，并且服务器也通过TCP连接相互通信。
The following diagram provides a high-level overview of this architecture (where "-" represents communications that use XMPP and "=" represents communications that use any other protocol).
下图提供了此体系结构的高级概述（其中“-”表示使用XMPP的通信，“=”表示使用任何其他协议的通信）。
C1----S1---S2---C3
|
C2----+--G1===FN1===FC1
C1----S1---S2---C3
|
C2----+--G1===FN1===FC1
The symbols are as follows:
符号如下：
o C1, C2, C3 = XMPP clients
o C1、C2、C3=XMPP客户端
o S1, S2 = XMPP servers
o S1，S2=XMPP服务器
o G1 = A gateway that translates between XMPP and the protocol(s) used on a foreign (non-XMPP) messaging network
o G1=在XMPP和外部（非XMPP）消息网络上使用的协议之间转换的网关
o FN1 = A foreign messaging network
o FN1=外部消息传递网络
o FC1 = A client on a foreign messaging network
o FC1=外部消息网络上的客户端
A server acts as an intelligent abstraction layer for XMPP communications. Its primary responsibilities are:
服务器充当XMPP通信的智能抽象层。其主要职责是：
o to manage connections from or sessions for other entities, in the form of XML streams (Section 4) to and from authorized clients, servers, and other entities
o 以XML流（第4节）的形式管理其他实体与授权客户端、服务器和其他实体之间的连接或会话
o to route appropriately-addressed XML stanzas (Section 9) among such entities over XML streams
o 通过XML流在这些实体之间路由适当寻址的XML节（第9节）
Most XMPP-compliant servers also assume responsibility for the storage of data that is used by clients (e.g., contact lists for users of XMPP-based instant messaging and presence applications); in this case, the XML data is processed directly by the server itself on behalf of the client and is not routed to another entity.
大多数兼容XMPP的服务器还负责存储客户端使用的数据（例如，基于XMPP的即时消息和状态应用程序用户的联系人列表）；在这种情况下，XML数据由服务器本身代表客户机直接处理，而不是路由到另一个实体。
Most clients connect directly to a server over a [TCP] connection and use XMPP to take full advantage of the functionality provided by a server and any associated services. Multiple resources (e.g., devices or locations) MAY connect simultaneously to a server on behalf of each authorized client, with each resource differentiated by the resource identifier of an XMPP address (e.g., <node@domain/ home> vs. <node@domain/work>) as defined under Addressing Scheme (Section 3). The RECOMMENDED port for connections between a client and a server is 5222, as registered with the IANA (see Port Numbers (Section 15.9)).
大多数客户端通过[TCP]连接直接连接到服务器，并使用XMPP充分利用服务器和任何相关服务提供的功能。多个资源（例如，设备或位置）可以代表每个授权客户端同时连接到服务器，每个资源由XMPP地址的资源标识符区分（例如<node@domain/主页>vs<node@domain/工作>），如寻址方案（第3节）所定义。客户机和服务器之间连接的推荐端口为5222，已在IANA注册（请参阅端口号（第15.9节））。
A gateway is a special-purpose server-side service whose primary function is to translate XMPP into the protocol used by a foreign (non-XMPP) messaging system, as well as to translate the return data back into XMPP. Examples are gateways to email (see [SMTP]), Internet Relay Chat (see [IRC]), SIMPLE (see [SIMPLE]), Short Message Service (SMS), and legacy instant messaging services such as AIM, ICQ, MSN Messenger, and Yahoo! Instant Messenger. Communications between gateways and servers, and between gateways and the foreign messaging system, are not defined in this document.
网关是一种特殊用途的服务器端服务，其主要功能是将XMPP转换为外部（非XMPP）消息传递系统使用的协议，以及将返回数据转换回XMPP。例如，电子邮件网关（请参见[SMTP]）、Internet中继聊天（请参见[IRC]）、SIMPLE（请参见[SIMPLE]）、短消息服务（SMS）以及传统即时消息服务，如AIM、ICQ、MSN Messenger和Yahoo！即时通讯。本文档中未定义网关和服务器之间以及网关和外部消息传递系统之间的通信。
Because each server is identified by a network address and because server-to-server communications are a straightforward extension of the client-to-server protocol, in practice, the system consists of a network of servers that inter-communicate. Thus, for example, <juliet@example.com> is able to exchange messages, presence, and other information with <romeo@example.net>. This pattern is familiar from messaging protocols (such as [SMTP]) that make use of network addressing standards. Communications between any two servers are OPTIONAL. If enabled, such communications SHOULD occur over XML streams that are bound to [TCP] connections. The RECOMMENDED port for connections between servers is 5269, as registered with the IANA (see Port Numbers (Section 15.9)).
由于每个服务器都由网络地址标识，并且服务器到服务器的通信是客户机到服务器协议的直接扩展，因此在实践中，系统由相互通信的服务器网络组成。所以比如说,<juliet@example.com>能够与交换消息、状态和其他信息<romeo@example.net>. 这种模式在使用网络寻址标准的消息传递协议（如[SMTP]）中很常见。任意两台服务器之间的通信都是可选的。如果启用，这种通信应该通过绑定到[TCP]连接的XML流进行。服务器之间连接的推荐端口为5269，已在IANA注册（请参阅端口号（第15.9节））。
An entity is anything that can be considered a network endpoint (i.e., an ID on the network) and that can communicate using XMPP. All such entities are uniquely addressable in a form that is consistent with RFC 2396 [URI]. For historical reasons, the address of an XMPP entity is called a Jabber Identifier or JID. A valid JID contains a set of ordered elements formed of a domain identifier, node identifier, and resource identifier.
实体是可以被视为网络端点（即网络上的ID）并且可以使用XMPP进行通信的任何东西。所有这些实体都可以以与RFC 2396[URI]一致的形式唯一寻址。出于历史原因，XMPP实体的地址称为Jabber标识符或JID。有效的JID包含由域标识符、节点标识符和资源标识符组成的一组有序元素。
The syntax for a JID is defined below using the Augmented Backus-Naur Form as defined in [ABNF]. (The IPv4address and IPv6address rules are defined in Appendix B of [IPv6]; the allowable character sequences that conform to the node rule are defined by the Nodeprep profile of [STRINGPREP] as documented in Appendix A of this memo; the allowable character sequences that conform to the resource rule are defined by the Resourceprep profile of [STRINGPREP] as documented in Appendix B of this memo; and the sub-domain rule makes reference to the concept of an internationalized domain label as described in [IDNA].)
JID的语法定义如下，使用[ABNF]中定义的扩展的Backus Naur形式。（IPv4address和IPv6地址规则在[IPv6]的附录B中定义；符合节点规则的允许字符序列由本备忘录附录A中记录的[STRINGPREP]的Nodeprep配置文件定义；符合资源规则的允许字符序列由的Resourceprep配置文件定义。）[STRINGPREP]如本备忘录附录B所述；子域规则参考了[IDNA]中所述的国际化域标签的概念。）
jid = [ node "@" ] domain [ "/" resource ]
domain = fqdn / address-literal
fqdn = (sub-domain 1*("." sub-domain))
sub-domain = (internationalized domain label)
address-literal = IPv4address / IPv6address
jid = [ node "@" ] domain [ "/" resource ]
domain = fqdn / address-literal
fqdn = (sub-domain 1*("." sub-domain))
sub-domain = (internationalized domain label)
address-literal = IPv4address / IPv6address
All JIDs are based on the foregoing structure. The most common use of this structure is to identify an instant messaging user, the server to which the user connects, and the user's connected resource (e.g., a specific client) in the form of <user@host/resource>. However, node types other than clients are possible; for example, a specific chat room offered by a multi-user chat service could be addressed as <room@service> (where "room" is the name of the chat room and "service" is the hostname of the multi-user chat service) and a specific occupant of such a room could be addressed as <room@service/nick> (where "nick" is the occupant's room nickname). Many other JID types are possible (e.g., <domain/resource> could be a server-side script or service).
所有JID都基于上述结构。此结构最常见的用途是以以下形式标识即时消息用户、用户连接到的服务器以及用户连接的资源（例如，特定客户端）<user@host/资源>。但是，可以使用客户端以外的节点类型；例如，由多用户聊天服务提供的特定聊天室可以作为<room@service>（其中“room”是聊天室的名称，“service”是多用户聊天服务的主机名）并且该聊天室的特定占用者可以被称为<room@service/尼克>（其中“尼克”是住户的房间昵称）。许多其他JID类型也是可能的（例如，<domain/resource>可以是服务器端脚本或服务）。
Each allowable portion of a JID (node identifier, domain identifier, and resource identifier) MUST NOT be more than 1023 bytes in length, resulting in a maximum total size (including the '@' and '/' separators) of 3071 bytes.
JID（节点标识符、域标识符和资源标识符）的每个允许部分的长度不得超过1023字节，从而导致最大总大小（包括“@”和“/”分隔符）为3071字节。
The domain identifier is the primary identifier and is the only REQUIRED element of a JID (a mere domain identifier is a valid JID). It usually represents the network gateway or "primary" server to which other entities connect for XML routing and data management capabilities. However, the entity referenced by a domain identifier is not always a server, and may be a service that is addressed as a subdomain of a server that provides functionality above and beyond the capabilities of a server (e.g., a multi-user chat service, a user directory, or a gateway to a foreign messaging system).
域标识符是主要标识符，是JID的唯一必需元素（仅域标识符就是有效的JID）。它通常表示网络网关或“主”服务器，其他实体为XML路由和数据管理功能连接到该服务器。然而，由域标识符引用的实体并不总是服务器，并且可以是被寻址为服务器的子域的服务，该服务器提供的功能高于服务器的功能（例如，多用户聊天服务、用户目录或到外部消息传递系统的网关）。
The domain identifier for every server or service that will communicate over a network MAY be an IP address but SHOULD be a fully qualified domain name (see [DNS]). A domain identifier MUST be an "internationalized domain name" as defined in [IDNA], to which the Nameprep [NAMEPREP] profile of stringprep [STRINGPREP] can be applied without failing. Before comparing two domain identifiers, a server MUST (and a client SHOULD) first apply the Nameprep profile to the labels (as defined in [IDNA]) that make up each identifier.
将通过网络进行通信的每个服务器或服务的域标识符可以是IP地址，但应该是完全限定的域名（请参见[DNS]）。域标识符必须是[IDNA]中定义的“国际化域名”，stringprep[stringprep]的Nameprep[Nameprep]配置文件可以应用于该域名而不会失败。在比较两个域标识符之前，服务器（和客户端）必须首先将Nameprep配置文件应用于构成每个标识符的标签（如[IDNA]中定义的）。
The node identifier is an optional secondary identifier placed before the domain identifier and separated from the latter by the '@' character. It usually represents the entity requesting and using network access provided by the server or gateway (i.e., a client), 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 a node identifier is addressed within the context of a specific domain; within instant messaging and presence applications of XMPP, this address is called a "bare JID" and is of the form <node@domain>.
节点标识符是一个可选的辅助标识符，位于域标识符之前，并用“@”字符与域标识符隔开。它通常表示请求并使用服务器或网关（即，客户端）提供的网络访问的实体，尽管它也可以表示其他类型的实体（例如，与多用户聊天服务相关联的聊天室）。由节点标识符表示的实体在特定域的上下文中寻址；在XMPP的即时消息和状态应用程序中，此地址称为“裸JID”，其形式为<node@domain>.
A node identifier MUST be formatted such that the Nodeprep profile of [STRINGPREP] can be applied to it without failing. Before comparing two node identifiers, a server MUST (and a client SHOULD) first apply the Nodeprep profile to each identifier.
必须对节点标识符进行格式化，以使[STRINGPREP]的Nodeprep配置文件可以应用于它而不会失败。在比较两个节点标识符之前，服务器（和客户端）必须首先对每个标识符应用Nodeprep配置文件。
The resource identifier is an optional tertiary identifier placed after the domain identifier and separated from the latter by the '/' character. A resource identifier may modify either a <node@domain> or a mere <domain> address. It usually represents a specific session, connection (e.g., a device or location), or object (e.g., a participant in a multi-user chat room) belonging to the entity associated with a node identifier. A resource identifier is opaque
资源标识符是一个可选的第三级标识符，位于域标识符之后，并用“/”字符与域标识符隔开。资源标识符可以修改<node@domain>或者仅仅是一个<domain>地址。它通常表示属于与节点标识符相关联的实体的特定会话、连接（例如，设备或位置）或对象（例如，多用户聊天室中的参与者）。资源标识符是不透明的
to both servers and other clients, and is typically defined by a client implementation when it provides the information necessary to complete Resource Binding (Section 7) (although it may be generated by a server on behalf of a client), after which it is referred to as a "connected resource". An entity MAY maintain multiple connected resources simultaneously, with each connected resource differentiated by a distinct resource identifier.
对于服务器和其他客户端，通常由客户端实现定义，当它提供完成资源绑定所需的信息时（第7节）（尽管它可以由服务器代表客户端生成），之后它被称为“连接的资源”。一个实体可以同时维护多个连接的资源，每个连接的资源由不同的资源标识符区分。
A resource identifier MUST be formatted such that the Resourceprep profile of [STRINGPREP] can be applied without failing. Before comparing two resource identifiers, a server MUST (and a client SHOULD) first apply the Resourceprep profile to each identifier.
必须对资源标识符进行格式化，以便能够应用[STRINGPREP]的Resourceprep配置文件而不会失败。在比较两个资源标识符之前，服务器（和客户端）必须首先对每个标识符应用Resourceprep配置文件。
After SASL negotiation (Section 6) and, if appropriate, Resource Binding (Section 7), the receiving entity for a stream MUST determine the initiating entity's JID.
在SASL协商（第6节）和资源绑定（第7节）之后，流的接收实体必须确定发起实体的JID。
For server-to-server communications, the initiating entity's JID SHOULD be the authorization identity, derived from the authentication identity, as defined by the Simple Authentication and Security Layer (SASL) specification [SASL], if no authorization identity was specified during SASL negotiation (Section 6).
对于服务器到服务器的通信，如果在SASL协商期间未指定授权标识（第6节），则发起实体的JID应为根据简单认证和安全层（SASL）规范[SASL]定义的认证标识派生的授权标识。
For client-to-server communications, the "bare JID" (<node@domain>) SHOULD be the authorization identity, derived from the authentication identity, as defined in [SASL], if no authorization identity was specified during SASL negotiation (Section 6); the resource identifier portion of the "full JID" (<node@domain/resource>) SHOULD be the resource identifier negotiated by the client and server during Resource Binding (Section 7).
对于客户端到服务器的通信，“裸JID”(<node@domain>)如果在SASL协商（第6节）期间未指定授权标识，则应为授权标识，源自[SASL]中定义的认证标识；“完整JID”的资源标识符部分(<node@domain/resource>）应该是客户端和服务器在资源绑定期间协商的资源标识符（第7节）。
The receiving entity MUST ensure that the resulting JID (including node identifier, domain identifier, resource identifier, and separator characters) conforms to the rules and formats defined earlier in this section; to meet this restriction, the receiving entity may need to replace the JID sent by the initiating entity with the canonicalized JID as determined by the receiving entity.
接收实体必须确保生成的JID（包括节点标识符、域标识符、资源标识符和分隔符）符合本节前面定义的规则和格式；为了满足此限制，接收实体可能需要将发起实体发送的JID替换为接收实体确定的规范化JID。
Two fundamental concepts make possible the rapid, asynchronous exchange of relatively small payloads of structured information between presence-aware entities: XML streams and XML stanzas. These terms are defined as follows:
两个基本概念使得在感知状态的实体之间快速、异步地交换相对较小的结构化信息有效负载成为可能：XML流和XML节。这些术语的定义如下：
Definition of XML Stream: An XML stream is a container for the exchange of XML elements between any two entities over a network. The start of an XML stream is denoted unambiguously by an opening XML <stream> tag (with appropriate attributes and namespace declarations), while the end of the XML stream is denoted unambiguously by a closing XML </stream> tag. During the life of the stream, the entity that initiated it can send an unbounded number of XML elements over the stream, either elements used to negotiate the stream (e.g., to negotiate Use of TLS (Section 5) or use of SASL (Section 6)) or XML stanzas (as defined herein, <message/>, <presence/>, or <iq/> elements qualified by the default namespace). The "initial stream" is negotiated from the initiating entity (usually a client or server) to the receiving entity (usually a server), and can be seen as corresponding to the initiating entity's "session" with the receiving entity. The initial stream enables unidirectional communication from the initiating entity to the receiving entity; in order to enable information exchange from the receiving entity to the initiating entity, the receiving entity MUST negotiate a stream in the opposite direction (the "response stream").
XML流的定义：XML流是通过网络在任意两个实体之间交换XML元素的容器。XML流的开始由开始的XML<stream>标记（具有适当的属性和名称空间声明）明确表示，而XML流的结束由结束的XML<stream>标记明确表示。在流的生命周期内，发起它的实体可以通过流发送无限数量的XML元素，这些元素可以是用于协商流的元素（例如，协商TLS的使用（第5节）或SASL的使用（第6节））或XML节（如本文所定义，<message/>、<presence/>或<iq/>元素由默认名称空间限定。“初始流”从发起实体（通常是客户端或服务器）协商到接收实体（通常是服务器），并且可以被视为与发起实体的“会话”相对应与接收实体。初始流实现从发起实体到接收实体的单向通信；为了实现从接收实体到发起实体的信息交换，接收实体必须在相反方向协商流（“响应流”）。
Definition of XML Stanza: An XML stanza is a discrete semantic unit of structured information that is sent from one entity to another over an XML stream. An XML stanza exists at the direct child level of the root <stream/> element and is said to be well-balanced if it matches the production [43] content of [XML]. The start of any XML stanza is denoted unambiguously by the element start tag at depth=1 of the XML stream (e.g., <presence>), and the end of any XML stanza is denoted unambiguously by the corresponding close tag at depth=1 (e.g., </presence>). An XML stanza MAY contain child elements (with accompanying attributes, elements, and XML character data) as necessary in order to convey the desired information. The only XML stanzas defined herein are the <message/>, <presence/>, and <iq/> elements qualified by the default namespace for the stream, as described under XML Stanzas (Section 9); an XML element sent for the purpose of Transport Layer Security (TLS) negotiation (Section 5), Simple Authentication and Security Layer (SASL) negotiation (Section 6), or server dialback (Section 8) is not considered to be an XML stanza.
XML节的定义：XML节是结构化信息的离散语义单元，通过XML流从一个实体发送到另一个实体。XML节存在于根<stream/>元素的直接子级，如果它与[XML]的生产[43]内容相匹配，则称为平衡良好。任何XML节的开始由XML流的深度=1处的元素开始标记明确表示（例如，<presence>），任何XML节的结束由深度=1处的相应结束标记明确表示（例如，</presence>）。XML节可以根据需要包含子元素（附带属性、元素和XML字符数据），以便传递所需的信息。此处定义的唯一XML节是<message/>、<presence/>和<iq/>元素，这些元素由流的默认名称空间限定，如XML节（第9节）所述；为传输层安全（TLS）协商（第5节）、简单身份验证和安全层（SASL）协商（第6节）或服务器回拨（第8节）目的发送的XML元素不被视为XML节。
Consider the example of a client's session with a server. In order to connect to a server, a client MUST initiate an XML stream by sending an opening <stream> tag to the server, optionally preceded by a text declaration specifying the XML version and the character encoding supported (see Inclusion of Text Declaration (Section 11.4); see also Character Encoding (Section 11.5)). Subject to local policies and service provisioning, the server SHOULD then reply with
考虑客户端与服务器的会话的示例。为了连接到服务器，客户机必须通过向服务器发送一个开始的<stream>标记来启动XML流，之前可以选择一个文本声明，指定支持的XML版本和字符编码（请参阅包含文本声明（第11.4节）；另请参阅字符编码（第11.5节））。根据本地策略和服务配置，服务器应回复
a second XML stream back to the client, again optionally preceded by a text declaration. Once the client has completed SASL negotiation (Section 6), the client MAY send an unbounded number of XML stanzas over the stream to any recipient on the network. When the client desires to close the stream, it simply sends a closing </stream> tag to the server (alternatively, the stream may be closed by the server), after which both the client and server SHOULD terminate the underlying connection (usually a TCP connection) as well.
返回客户机的第二个XML流，也可以选择前面有一个文本声明。一旦客户机完成SASL协商（第6节），客户机可以通过流向网络上的任何收件人发送无限数量的XML节。当客户端希望关闭流时，它只需向服务器发送一个关闭标记（或者，服务器可能会关闭流），然后客户端和服务器都应该终止底层连接（通常是TCP连接）。
Those who are accustomed to thinking of XML in a document-centric manner may wish to view a client's session with a server as consisting of two open-ended XML documents: one from the client to the server and one from the server to the client. From this perspective, the root <stream/> element can be considered the document entity for each "document", and the two "documents" are built up through the accumulation of XML stanzas sent over the two XML streams. However, this perspective is a convenience only; XMPP does not deal in documents but in XML streams and XML stanzas.
习惯于以文档为中心的方式思考XML的人可能希望将客户机与服务器的会话视为由两个开放式XML文档组成：一个从客户机到服务器，另一个从服务器到客户机。从这个角度来看，根<stream/>元素可以被视为每个“文档”的文档实体，这两个“文档”是通过在两个XML流上发送的XML节的累积而建立起来的。然而，这种观点只是一种方便；XMPP不处理文档，而是处理XML流和XML节。
In essence, then, an XML stream acts as an envelope for all the XML stanzas sent during a session. We can represent this in a simplistic fashion as follows:
实际上，XML流充当会话期间发送的所有XML节的信封。我们可以简单地表示如下：
|--------------------|
| <stream> |
|--------------------|
| <presence> |
| <show/> |
| </presence> |
|--------------------|
| <message to='foo'> |
| <body/> |
| </message> |
|--------------------|
| <iq to='bar'> |
| <query/> |
| </iq> |
|--------------------|
| ... |
|--------------------|
| </stream> |
|--------------------|
|--------------------|
| <stream> |
|--------------------|
| <presence> |
| <show/> |
| </presence> |
|--------------------|
| <message to='foo'> |
| <body/> |
| </message> |
|--------------------|
| <iq to='bar'> |
| <query/> |
| </iq> |
|--------------------|
| ... |
|--------------------|
| </stream> |
|--------------------|
Although there is no necessary coupling of an XML stream to a [TCP] connection (e.g., two entities could connect to each other via another mechanism such as polling over [HTTP]), this specification defines a binding of XMPP to TCP only. In the context of client-to-server communications, a server MUST allow a client to share a single TCP connection for XML stanzas sent from client to server and from server to client. In the context of server-to-server communications, a server MUST use one TCP connection for XML stanzas sent from the server to the peer and another TCP connection (initiated by the peer) for stanzas from the peer to the server, for a total of two TCP connections.
尽管XML流与[TCP]连接之间没有必要的耦合（例如，两个实体可以通过另一种机制（如通过[HTTP]轮询）相互连接），但本规范仅定义了XMPP与TCP的绑定。在客户机到服务器通信的上下文中，服务器必须允许客户机共享从客户机到服务器以及从服务器到客户机发送的XML节的单个TCP连接。在服务器到服务器通信的上下文中，服务器必须使用一个TCP连接来表示从服务器发送到对等方的XML节，使用另一个TCP连接（由对等方发起）来表示从对等方发送到服务器的节，总共使用两个TCP连接。
When negotiating XML streams in XMPP 1.0, TLS SHOULD be used as defined under Use of TLS (Section 5) and SASL MUST be used as defined under Use of SASL (Section 6). The "initial stream" (i.e., the stream from the initiating entity to the receiving entity) and the "response stream" (i.e., the stream from the receiving entity to the initiating entity) MUST be secured separately, although security in both directions MAY be established via mechanisms that provide mutual authentication. An entity SHOULD NOT attempt to send XML Stanzas (Section 9) over the stream before the stream has been authenticated, but if it does, then the other entity MUST NOT accept such stanzas and SHOULD return a <not-authorized/> stream error and then terminate both the XML stream and the underlying TCP connection; note well that this applies to XML stanzas only (i.e., <message/>, <presence/>, and <iq/> elements scoped by the default namespace) and not to XML elements used for stream negotiation (e.g., elements used to negotiate Use of TLS (Section 5) or Use of SASL (Section 6)).
在XMPP 1.0中协商XML流时，TLS应该按照TLS的使用（第5节）中的定义使用，SASL必须按照SASL的使用（第6节）中的定义使用。“初始流”（即，从发起实体到接收实体的流）和“响应流”（即，从接收实体到发起实体的流）必须分开保护，尽管可以通过提供相互认证的机制来建立两个方向上的安全性。实体不应在流经过身份验证之前尝试通过流发送XML节（第9节），但如果尝试了，则另一实体不得接受此类节，并应返回<NOT authorized/>流错误，然后终止XML流和底层TCP连接；请注意，这仅适用于XML节（即，<message/>、<presence/>和<iq/>元素，其范围由默认名称空间限定），而不适用于用于流协商的XML元素（例如，用于协商TLS的使用（第5节）或SASL的使用（第6节））。
The attributes of the stream element are as follows:
stream元素的属性如下所示：
o to -- The 'to' attribute SHOULD be used only in the XML stream header from the initiating entity to the receiving entity, and MUST be set to a hostname serviced by the receiving entity. There SHOULD NOT be a 'to' attribute set in the XML stream header by which the receiving entity replies to the initiating entity; however, if a 'to' attribute is included, it SHOULD be silently ignored by the initiating entity.
o to--“to”属性只能在从发起实体到接收实体的XML流头中使用，并且必须设置为接收实体提供服务的主机名。XML流头中不应设置“to”属性，接收实体通过该属性回复发起实体；但是，如果包含“to”属性，则发起实体应默认忽略该属性。
o from -- The 'from' attribute SHOULD be used only in the XML stream header from the receiving entity to the initiating entity, and MUST be set to a hostname serviced by the receiving entity that is granting access to the initiating entity. There SHOULD NOT be a 'from' attribute on the XML stream header sent from the initiating entity to the receiving entity; however, if a 'from' attribute is included, it SHOULD be silently ignored by the receiving entity.
o from--“from”属性应仅在从接收实体到发起实体的XML流头中使用，并且必须设置为由向发起实体授予访问权的接收实体提供服务的主机名。从发起实体发送到接收实体的XML流头上不应有“from”属性；但是，如果包含“from”属性，则接收实体应默认忽略该属性。
o id -- The 'id' attribute SHOULD be used only in the XML stream header from the receiving entity to the initiating entity. This attribute is a unique identifier created by the receiving entity to function as a session key for the initiating entity's streams with the receiving entity, and MUST be unique within the receiving application (normally a server). Note well that the stream ID may be security-critical and therefore MUST be both unpredictable and nonrepeating (see [RANDOM] for recommendations regarding randomness for security purposes). There SHOULD NOT be an 'id' attribute on the XML stream header sent from the initiating entity to the receiving entity; however, if an 'id' attribute is included, it SHOULD be silently ignored by the receiving entity.
o id--“id”属性只能在从接收实体到发起实体的XML流头中使用。此属性是由接收实体创建的唯一标识符，用作发起实体与接收实体的流的会话密钥，并且在接收应用程序（通常是服务器）中必须是唯一的。请注意，流ID可能是安全关键的，因此必须是不可预测和不可重复的（请参阅[RANDOM]，以了解出于安全目的有关随机性的建议）。从发起实体发送到接收实体的XML流头上不应有“id”属性；但是，如果包含“id”属性，则接收实体应默认忽略该属性。
o xml:lang -- An 'xml:lang' attribute (as defined in Section 2.12 of [XML]) SHOULD be included by the initiating entity on the header for the initial stream to specify the default language of any human-readable XML character data it sends over that stream. If the attribute is included, the receiving entity SHOULD remember that value as the default for both the initial stream and the response stream; if the attribute is not included, the receiving entity SHOULD use a configurable default value for both streams, which it MUST communicate in the header for the response stream. For all stanzas sent over the initial stream, if the initiating entity does not include an 'xml:lang' attribute, the receiving entity SHOULD apply the default value; if the initiating entity does include an 'xml:lang' attribute, the receiving entity MUST NOT modify or delete it (see also xml:lang (Section 9.1.5)). The value of the 'xml:lang' attribute MUST be an NMTOKEN (as defined in Section 2.3 of [XML]) and MUST conform to the format defined in RFC 3066 [LANGTAGS].
o xml:lang——初始流的头上的发起实体应包含一个“xml:lang”属性（如[xml]第2.12节中定义的），以指定它通过该流发送的任何人类可读的xml字符数据的默认语言。如果包含该属性，则接收实体应记住该值作为初始流和响应流的默认值；如果未包含该属性，则接收实体应为两个流使用可配置的默认值，它必须在响应流的报头中进行通信。对于通过初始流发送的所有节，如果发起实体不包含“xml:lang”属性，则接收实体应应用默认值；如果发起实体包含“xml:lang”属性，则接收实体不得修改或删除该属性（另请参见xml:lang（第9.1.5节））。“xml:lang”属性的值必须是NMTOKEN（如[xml]第2.3节所定义），并且必须符合RFC 3066[LANGTAGS]中定义的格式。
o version -- The presence of the version attribute set to a value of at least "1.0" signals support for the stream-related protocols (including stream features) defined in this specification. Detailed rules regarding the generation and handling of this attribute are defined below.
o version——version属性设置为至少“1.0”的值表示支持本规范中定义的流相关协议（包括流特性）。有关此属性的生成和处理的详细规则定义如下。
We can summarize as follows:
我们可以总结如下：
| initiating to receiving | receiving to initiating
---------+---------------------------+-----------------------
to | hostname of receiver | silently ignored
from | silently ignored | hostname of receiver
id | silently ignored | session key
xml:lang | default language | default language
version | signals XMPP 1.0 support | signals XMPP 1.0 support
| initiating to receiving | receiving to initiating
---------+---------------------------+-----------------------
to | hostname of receiver | silently ignored
from | silently ignored | hostname of receiver
id | silently ignored | session key
xml:lang | default language | default language
version | signals XMPP 1.0 support | signals XMPP 1.0 support
The version of XMPP specified herein is "1.0"; in particular, this encapsulates the stream-related protocols (Use of TLS (Section 5), Use of SASL (Section 6), and Stream Errors (Section 4.7)), as well as the semantics of the three defined XML stanza types (<message/>, <presence/>, and <iq/>). The numbering scheme for XMPP versions is "<major>.<minor>". The major and minor numbers MUST be treated as separate integers and each number MAY be incremented higher than a single digit. Thus, "XMPP 2.4" would be a lower version than "XMPP 2.13", which in turn would be lower than "XMPP 12.3". Leading zeros (e.g., "XMPP 6.01") MUST be ignored by recipients and MUST NOT be sent.
此处指定的XMPP版本为“1.0”；特别是，这封装了与流相关的协议（TLS的使用（第5节）、SASL的使用（第6节）和流错误（第4.7节）），以及三种定义的XML节类型（<message/>、<presence/>和<iq/>）的语义。XMPP版本的编号方案为“<major><minor>”。主数字和次数字必须被视为独立的整数，每个数字的增量可以大于一个位数。因此，“XMPP2.4”的版本低于“XMPP2.13”，而“XMPP2.13”的版本又低于“XMPP12.3”。收件人必须忽略前导零（例如，“XMPP 6.01”），并且不得发送前导零。
The major version number should be incremented only if the stream and stanza formats or required actions have changed so dramatically that an older version entity would not be able to interoperate with a newer version entity if it simply ignored the elements and attributes it did not understand and took the actions specified in the older specification. The minor version number indicates new capabilities, and MUST be ignored by an entity with a smaller minor version number, but used for informational purposes by the entity with the larger minor version number. For example, a minor version number might indicate the ability to process a newly defined value of the 'type' attribute for message, presence, or IQ stanzas; the entity with the larger minor version number would simply note that its correspondent would not be able to understand that value of the 'type' attribute and therefore would not send it.
只有当流和节格式或所需操作发生了巨大变化，以至于旧版本实体无法与新版本实体进行互操作时（如果它忽略了它不理解的元素和属性，并采取了旧版本实体中指定的操作），主版本号才应增加规格次要版本号表示新功能，次要版本号较小的实体必须忽略该功能，但次要版本号较大的实体将其用于信息目的。例如，次要版本号可能表示处理消息、状态或IQ节的“type”属性的新定义值的能力；次要版本号较大的实体只会注意到其对应者无法理解“type”属性的值，因此不会发送它。
The following rules apply to the generation and handling of the 'version' attribute within stream headers by implementations:
以下规则适用于通过实现在流标头中生成和处理“version”属性：
1. The initiating entity MUST set the value of the 'version' attribute on the initial stream header to the highest version number it supports (e.g., if the highest version number it supports is that defined in this specification, it MUST set the value to "1.0").
1. 发起实体必须将初始流标头上的“版本”属性的值设置为其支持的最高版本号（例如，如果其支持的最高版本号是本规范中定义的版本号，则必须将该值设置为“1.0”）。
2. The receiving entity MUST set the value of the 'version' attribute on the response stream header to either the value supplied by the initiating entity or the highest version number supported by the receiving entity, whichever is lower. The receiving entity MUST perform a numeric comparison on the major and minor version numbers, not a string match on "<major>.<minor>".
2. 接收实体必须将响应流头上的“版本”属性的值设置为发起实体提供的值或接收实体支持的最高版本号，以较低者为准。接收实体必须对主版本号和次版本号执行数字比较，而不是“<major><minor>”上的字符串匹配。
3. If the version number included in the response stream header is at least one major version lower than the version number included in the initial stream header and newer version entities cannot interoperate with older version entities as described above, the initiating entity SHOULD generate an <unsupported-version/> stream error and terminate the XML stream and underlying TCP connection.
3. 如果响应流标头中包含的版本号至少比初始流标头中包含的版本号低一个主版本，且较新版本实体无法与较旧版本实体进行如上所述的互操作，发起实体应生成<unsupported version/>流错误，并终止XML流和底层TCP连接。
4. If either entity receives a stream header with no 'version' attribute, the entity MUST consider the version supported by the other entity to be "0.0" and SHOULD NOT include a 'version' attribute in the stream header it sends in reply.
4. 如果两个实体都接收到没有“版本”属性的流标头，则实体必须考虑由另一个实体支持的版本为“0”，并且不应该在其发送的流报头中包含“版本”属性。
The stream element MUST possess both a streams namespace declaration and a default namespace declaration (as "namespace declaration" is defined in the XML namespaces specification [XML-NAMES]). For detailed information regarding the streams namespace and default namespace, see Namespace Names and Prefixes (Section 11.2).
stream元素必须同时拥有streams名称空间声明和默认名称空间声明（因为“名称空间声明”在XML名称空间规范[XML-NAMES]中定义）。有关streams命名空间和默认命名空间的详细信息，请参阅命名空间名称和前缀（第11.2节）。
If the initiating entity includes the 'version' attribute set to a value of at least "1.0" in the initial stream header, the receiving entity MUST send a <features/> child element (prefixed by the streams namespace prefix) to the initiating entity in order to announce any stream-level features that can be negotiated (or capabilities that otherwise need to be advertised). Currently, this is used only to advertise Use of TLS (Section 5), Use of SASL (Section 6), and Resource Binding (Section 7) as defined herein, and for Session Establishment as defined in [XMPP-IM]; however, the stream features functionality could be used to advertise other negotiable features in the future. If an entity does not understand or support some features, it SHOULD silently ignore them. If one or more security features (e.g., TLS and SASL) need to be successfully negotiated before a non-security-related feature (e.g., Resource Binding) can be offered, the non-security-related feature SHOULD NOT be included in the stream features that are advertised before the relevant security features have been negotiated.
如果发起实体在初始流标头中包含设置为至少“1.0”的值的“版本”属性，则接收实体必须向发起实体发送<features/>子元素（前缀为streams命名空间前缀），以便宣布可协商的任何流级特征（或其他需要公布的功能）。目前，这仅用于公布本文定义的TLS（第5节）、SASL（第6节）和资源绑定（第7节）的使用，以及[XMPP-IM]中定义的会话建立；但是，流功能将来可用于宣传其他可协商功能。如果实体不理解或不支持某些功能，则应默默忽略它们。如果一个或多个安全功能（例如TLS和SASL）需要在非安全相关功能之前成功协商如果可以提供（例如，资源绑定），则在协商相关安全特性之前，不应将非安全相关特性包括在发布的流特性中。
The root stream element MAY contain an <error/> child element that is prefixed by the streams namespace prefix. The error child MUST be sent by a compliant entity (usually a server rather than a client) if it perceives that a stream-level error has occurred.
根流元素可能包含以streams命名空间前缀为前缀的<error/>子元素。如果兼容实体（通常是服务器而不是客户端）察觉到发生了流级错误，则必须发送错误子项。
The following rules apply to stream-level errors:
以下规则适用于流级错误：
o It is assumed that all stream-level errors are unrecoverable; therefore, if an error occurs at the level of the stream, the entity that detects the error MUST send a stream error to the other entity, send a closing </stream> tag, and terminate the underlying TCP connection.
o 假设所有流级错误都是不可恢复的；因此，如果在流级别发生错误，则检测到错误的实体必须向其他实体发送流错误，发送关闭标记，并终止底层TCP连接。
o If the error occurs while the stream is being set up, the receiving entity MUST still send the opening <stream> tag, include the <error/> element as a child of the stream element, send the closing </stream> tag, and terminate the underlying TCP connection. In this case, if the initiating entity provides an unknown host in the 'to' attribute (or provides no 'to' attribute at all), the server SHOULD provide the server's authoritative hostname in the 'from' attribute of the stream header sent before termination.
o 如果在设置流时发生错误，则接收实体仍必须发送开始的<stream>标记，将<error/>元素作为流元素的子元素，发送结束的<stream>标记，并终止底层TCP连接。在这种情况下，如果发起实体在“to”属性中提供未知主机（或根本不提供“to”属性），则服务器应在终止前发送的流标头的“from”属性中提供服务器的权威主机名。
The syntax for stream errors is as follows:
流错误的语法如下所示：
<stream:error>
<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-streams'
xml:lang='langcode'>
OPTIONAL descriptive text
</text>
[OPTIONAL application-specific condition element]
</stream:error>
<stream:error>
<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-streams'
xml:lang='langcode'>
OPTIONAL descriptive text
</text>
[OPTIONAL application-specific condition element]
</stream:error>
The <error/> element:
<error/>元素：
o MUST contain a child element corresponding to one of the defined stanza error conditions defined below; this element MUST be qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace
o 必须包含与以下定义的节错误条件之一对应的子元素；此元素必须由“urn:ietf:params:xml:ns:xmpp streams”命名空间限定
o MAY contain a <text/> child containing XML character data that describes the error in more detail; this element MUST be qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace and SHOULD possess an 'xml:lang' attribute specifying the natural language of the XML character data
o 可能包含一个子元素，该子元素包含更详细地描述错误的XML字符数据；此元素必须由“urn:ietf:params:xml:ns:xmpp streams”命名空间限定，并应具有指定xml字符数据的自然语言的“xml:lang”属性
o MAY contain a child element for an application-specific error condition; this element MUST be qualified by an application-defined namespace, and its structure is defined by that namespace
o 可能包含应用程序特定错误条件的子元素；此元素必须由应用程序定义的命名空间限定，其结构由该命名空间定义
The <text/> element is OPTIONAL. If included, it SHOULD be used only to provide descriptive or diagnostic information that supplements the meaning of a defined condition or application-specific condition. It SHOULD NOT be interpreted programmatically by an application. It SHOULD NOT be used as the error message presented to a user, but MAY be shown in addition to the error message associated with the included condition element (or elements).
<text/>元素是可选的。如果包括，则应仅用于提供补充定义条件或特定应用条件含义的描述性或诊断信息。应用程序不应以编程方式解释它。它不应用作向用户显示的错误消息，但可以在与包含的条件元素相关联的错误消息之外显示。
The following stream-level error conditions are defined:
定义了以下流级错误条件：
o <bad-format/> -- the entity has sent XML that cannot be processed; this error MAY be used instead of the more specific XML-related errors, such as <bad-namespace-prefix/>, <invalid-xml/>, <restricted-xml/>, <unsupported-encoding/>, and <xml-not-well-formed/>, although the more specific errors are preferred.
o <bad format/>--实体已发送无法处理的XML；可以使用此错误代替更具体的XML相关错误，例如<bad namespace prefix/>、<invalid XML/>、<restricted XML/>、<unsupported encoding/>和<XML not well format/>，尽管更具体的错误是首选错误。
o <bad-namespace-prefix/> -- the entity has sent a namespace prefix that is unsupported, or has sent no namespace prefix on an element that requires such a prefix (see XML Namespace Names and Prefixes (Section 11.2)).
o <bad namespace prefix/>——实体发送了不受支持的名称空间前缀，或者在需要此类前缀的元素上未发送名称空间前缀（请参阅XML名称空间名称和前缀（第11.2节））。
o <conflict/> -- the server is closing the active stream for this entity because a new stream has been initiated that conflicts with the existing stream.
o <conflict/>--服务器正在关闭此实体的活动流，因为已启动与现有流冲突的新流。
o <connection-timeout/> -- the entity has not generated any traffic over the stream for some period of time (configurable according to a local service policy).
o <connection timeout/>——实体在一段时间内没有在流上生成任何流量（可根据本地服务策略进行配置）。
o <host-gone/> -- the value of the 'to' attribute provided by the initiating entity in the stream header corresponds to a hostname that is no longer hosted by the server.
o <host gone/>——流头中发起实体提供的“to”属性的值对应于不再由服务器托管的主机名。
o <host-unknown/> -- the value of the 'to' attribute provided by the initiating entity in the stream header does not correspond to a hostname that is hosted by the server.
o <host unknown/>--流标头中发起实体提供的“to”属性的值与服务器承载的主机名不对应。
o <improper-addressing/> -- a stanza sent between two servers lacks a 'to' or 'from' attribute (or the attribute has no value).
o <不正确寻址>--在两台服务器之间发送的节缺少“to”或“from”属性（或者该属性没有值）。
o <internal-server-error/> -- the server has experienced a misconfiguration or an otherwise-undefined internal error that prevents it from servicing the stream.
o <internal server error/>--服务器遇到错误配置或未定义的内部错误，从而无法为流提供服务。
o <invalid-from/> -- the JID or hostname provided in a 'from' address does not match an authorized JID or validated domain negotiated between servers via SASL or dialback, or between a client and a server via authentication and resource binding.
o <invalid from/>--“from”地址中提供的JID或主机名与通过SASL或拨号在服务器之间协商的授权JID或验证域不匹配，或与通过身份验证和资源绑定在客户端和服务器之间协商的授权JID或验证域不匹配。
o <invalid-id/> -- the stream ID or dialback ID is invalid or does not match an ID previously provided.
o <invalid id/>--流id或回拨id无效或与以前提供的id不匹配。
o <invalid-namespace/> -- the streams namespace name is something other than "http://etherx.jabber.org/streams" or the dialback namespace name is something other than "jabber:server:dialback" (see XML Namespace Names and Prefixes (Section 11.2)).
o <invalid namespace/>--streams命名空间名称不是“http://etherx.jabber.org/streams或者拨回名称空间名称不是“jabber:server:dialback”（请参阅XML名称空间名称和前缀（第11.2节））。
o <invalid-xml/> -- the entity has sent invalid XML over the stream to a server that performs validation (see Validation (Section 11.3)).
o <invalid xml/>——实体已通过流将无效xml发送到执行验证的服务器（请参阅验证（第11.3节））。
o <not-authorized/> -- the entity has attempted to send data before the stream has been authenticated, or otherwise is not authorized to perform an action related to stream negotiation; the receiving entity MUST NOT process the offending stanza before sending the stream error.
o <not authorized/>——实体试图在流经过身份验证之前发送数据，或者未被授权执行与流协商相关的操作；在发送流错误之前，接收实体不得处理有问题的节。
o <policy-violation/> -- the entity has violated some local service policy; the server MAY choose to specify the policy in the <text/> element or an application-specific condition element.
o <policy violation/>——实体违反了某些本地服务策略；服务器可以选择在<text/>元素或特定于应用程序的条件元素中指定策略。
o <remote-connection-failed/> -- the server is unable to properly connect to a remote entity that is required for authentication or authorization.
o <remote connection failed/>--服务器无法正确连接到身份验证或授权所需的远程实体。
o <resource-constraint/> -- the server lacks the system resources necessary to service the stream.
o <resource constraint/>--服务器缺少为流提供服务所需的系统资源。
o <restricted-xml/> -- the entity has attempted to send restricted XML features such as a comment, processing instruction, DTD, entity reference, or unescaped character (see Restrictions (Section 11.1)).
o <restricted xml/>——实体试图发送受限xml功能，如注释、处理指令、DTD、实体引用或未转义字符（请参阅限制（第11.1节））。
o <see-other-host/> -- the server will not provide service to the initiating entity but is redirecting traffic to another host; the server SHOULD specify the alternate hostname or IP address (which MUST be a valid domain identifier) as the XML character data of the <see-other-host/> element.
o <查看其他主机/>--服务器不会向发起实体提供服务，但正在将流量重定向到另一台主机；服务器应指定备用主机名或IP地址（必须是有效的域标识符）作为<see other host/>元素的XML字符数据。
o <system-shutdown/> -- the server is being shut down and all active streams are being closed.
o <system shutdown/>服务器正在关闭，所有活动流正在关闭。
o <undefined-condition/> -- the error condition is not one of those defined by the other conditions in this list; this error condition SHOULD be used only in conjunction with an application-specific condition.
o <undefined condition/>——错误条件不是此列表中其他条件定义的条件之一；此错误条件只能与特定于应用程序的条件一起使用。
o <unsupported-encoding/> -- the initiating entity has encoded the stream in an encoding that is not supported by the server (see Character Encoding (Section 11.5)).
o <unsupported encoding/>——发起实体以服务器不支持的编码对流进行编码（请参阅字符编码（第11.5节））。
o <unsupported-stanza-type/> -- the initiating entity has sent a first-level child of the stream that is not supported by the server.
o <unsupported stanza type/>--发起实体已发送服务器不支持的流的第一级子级。
o <unsupported-version/> -- the value of the 'version' attribute provided by the initiating entity in the stream header specifies a version of XMPP that is not supported by the server; the server MAY specify the version(s) it supports in the <text/> element.
o <unsupported version/>——流头中发起实体提供的“version”属性的值指定服务器不支持的XMPP版本；服务器可以在<text/>元素中指定其支持的版本。
o <xml-not-well-formed/> -- the initiating entity has sent XML that is not well-formed as defined by [XML].
o <xml格式不正确/>——发起实体发送的xml格式不符合[xml]的定义。
As noted, an application MAY provide application-specific stream error information by including a properly-namespaced child in the error element. The application-specific element SHOULD supplement or further qualify a defined element. Thus the <error/> element will contain two or three child elements:
如前所述，应用程序可以通过在error元素中包含正确命名的子元素来提供特定于应用程序的流错误信息。特定于应用程序的元素应补充或进一步限定已定义的元素。因此，<error/>元素将包含两个或三个子元素：
<stream:error>
<xml-not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
Some special application diagnostic information!
</text>
<escape-your-data xmlns='application-ns'/>
</stream:error>
</stream:stream>
<stream:error>
<xml-not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
Some special application diagnostic information!
</text>
<escape-your-data xmlns='application-ns'/>
</stream:error>
</stream:stream>
This section contains two simplified examples of a stream-based "session" of a client on a server (where the "C" lines are sent from the client to the server, and the "S" lines are sent from the server to the client); these examples are included for the purpose of illustrating the concepts introduced thus far.
本节包含服务器上客户端基于流的“会话”的两个简化示例（其中“C”行从客户端发送到服务器，“S”行从服务器发送到客户端）；包括这些示例是为了说明迄今为止引入的概念。
A basic "session":
基本“会议”：
C: <?xml version='1.0'?>
<stream:stream
to='example.com'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='someid'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
... encryption, authentication, and resource binding ...
C: <message from='juliet@example.com'
to='romeo@example.net'
xml:lang='en'>
C: <body>Art thou not Romeo, and a Montague?</body>
C: </message>
S: <message from='romeo@example.net'
to='juliet@example.com'
xml:lang='en'>
S: <body>Neither, fair saint, if either thee dislike.</body>
S: </message>
C: </stream:stream>
S: </stream:stream>
C: <?xml version='1.0'?>
<stream:stream
to='example.com'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='someid'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
... encryption, authentication, and resource binding ...
C: <message from='juliet@example.com'
to='romeo@example.net'
xml:lang='en'>
C: <body>Art thou not Romeo, and a Montague?</body>
C: </message>
S: <message from='romeo@example.net'
to='juliet@example.com'
xml:lang='en'>
S: <body>Neither, fair saint, if either thee dislike.</body>
S: </message>
C: </stream:stream>
S: </stream:stream>
A "session" gone bad:
坏掉的“会话”：
C: <?xml version='1.0'?>
<stream:stream
to='example.com'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='someid'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
... encryption, authentication, and resource binding ...
C: <message xml:lang='en'>
<body>Bad XML, no closing body tag!
</message>
S: <stream:error>
<xml-not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
S: </stream:stream>
C: <?xml version='1.0'?>
<stream:stream
to='example.com'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='someid'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
... encryption, authentication, and resource binding ...
C: <message xml:lang='en'>
<body>Bad XML, no closing body tag!
</message>
S: <stream:error>
<xml-not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
S: </stream:stream>
XMPP includes a method for securing the stream from tampering and eavesdropping. This channel encryption method makes use of the Transport Layer Security (TLS) protocol [TLS], along with a "STARTTLS" extension that is modelled after similar extensions for the IMAP [IMAP], POP3 [POP3], and ACAP [ACAP] protocols as described in RFC 2595 [USINGTLS]. The namespace name for the STARTTLS extension is 'urn:ietf:params:xml:ns:xmpp-tls'.
XMPP包括一种保护流不被篡改和窃听的方法。这种信道加密方法使用传输层安全（TLS）协议[TLS]，以及“STARTTLS”扩展，该扩展是根据RFC 2595[USINGTLS]中所述的IMAP[IMAP]、POP3[POP3]和ACAP[ACAP]协议的类似扩展而建模的。STARTTLS扩展的命名空间名称为“urn:ietf:params:xml:ns:xmpp-tls”。
An administrator of a given domain MAY require the use of TLS for client-to-server communications, server-to-server communications, or both. Clients SHOULD use TLS to secure the streams prior to attempting the completion of SASL negotiation (Section 6), and servers SHOULD use TLS between two domains for the purpose of securing server-to-server communications.
给定域的管理员可能需要使用TLS进行客户端到服务器通信、服务器到服务器通信或两者兼而有之。在尝试完成SASL协商（第6节）之前，客户端应使用TLS保护流，服务器应在两个域之间使用TLS以保护服务器到服务器的通信。
The following rules apply:
以下规则适用：
1. An initiating entity that complies with this specification MUST include the 'version' attribute set to a value of "1.0" in the initial stream header.
1. 符合本规范的发起实体必须在初始流标头中包含设置为值“1.0”的“版本”属性。
2. If the TLS negotiation occurs between two servers, communications MUST NOT proceed until the Domain Name System (DNS) hostnames asserted by the servers have been resolved (see Server-to-Server Communications (Section 14.4)).
2. 如果两台服务器之间发生TLS协商，则在解析服务器断言的域名系统（DNS）主机名之前，不得进行通信（请参阅服务器到服务器通信（第14.4节））。
3. When a receiving entity that complies with this specification receives an initial stream header that includes the 'version' attribute set to a value of at least "1.0", after sending a stream header in reply (including the version flag), it MUST include a <starttls/> element (qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace) along with the list of other stream features it supports.
3. 当符合本规范的接收实体接收到初始流头时，在发送响应流头（包括版本标志）后，它必须包含<starttls/>元素（由“urn:ietf:params:xml:ns:xmpp tls”命名空间限定），该初始流头包括设置为至少“1.0”的“version”属性以及它支持的其他流功能的列表。
4. If the initiating entity chooses to use TLS, TLS negotiation MUST be completed before proceeding to SASL negotiation; this order of negotiation is required to help safeguard authentication information sent during SASL negotiation, as well as to make it possible to base the use of the SASL EXTERNAL mechanism on a certificate provided during prior TLS negotiation.
4. 如果发起实体选择使用TLS，则必须在进行SASL谈判之前完成TLS谈判；需要此协商顺序以帮助保护SASL协商期间发送的身份验证信息，并使SASL外部机制的使用基于先前TLS协商期间提供的证书。
5. During TLS negotiation, an entity MUST NOT send any white space characters (matching production [3] content of [XML]) within the root stream element as separators between elements (any white space characters shown in the TLS examples below are included for the sake of readability only); this prohibition helps to ensure proper security layer byte precision.
5. 在TLS协商期间，实体不得在根流元素内发送任何空白字符（匹配[XML]的生产[3]内容）作为元素之间的分隔符（以下TLS示例中显示的任何空白字符仅出于可读性考虑）；此禁止有助于确保适当的安全层字节精度。
6. The receiving entity MUST consider the TLS negotiation to have begun immediately after sending the closing ">" character of the <proceed/> element. The initiating entity MUST consider the TLS negotiation to have begun immediately after receiving the closing ">" character of the <proceed/> element from the receiving entity.
6. 接收实体必须考虑在发送<继续/>元素的关闭“>”字符后立即开始TLS协商。发起实体必须在接收到接收实体的“继续”/>元素的关闭“>”字符之后立即考虑TLS协商已经开始。
7. The initiating entity MUST validate the certificate presented by the receiving entity; see Certificate Validation (Section 14.2) regarding certificate validation procedures.
7. 发起实体必须验证接收实体提交的证书；有关证书验证程序，请参见证书验证（第14.2节）。
8. Certificates MUST be checked against the hostname as provided by the initiating entity (e.g., a user), not the hostname as resolved via the Domain Name System; e.g., if the user specifies a hostname of "example.com" but a DNS SRV [SRV] lookup returned
8. 必须根据发起实体（例如用户）提供的主机名检查证书，而不是通过域名系统解析的主机名；e、 例如，如果用户指定主机名为“example.com”，但返回DNS SRV[SRV]查找
"im.example.com", the certificate MUST be checked as "example.com". If a JID for any kind of XMPP entity (e.g., client or server) is represented in a certificate, it MUST be represented as a UTF8String within an otherName entity inside the subjectAltName, using the [ASN.1] Object Identifier "id-on-xmppAddr" specified in Section 5.1.1 of this document.
“im.example.com”，必须将证书检查为“example.com”。如果任何类型的XMPP实体（例如，客户端或服务器）的JID在证书中表示，则必须使用本文档第5.1.1节中指定的[ASN.1]对象标识符“xmppAddr上的id”，将其表示为subjectAltName内的otherName实体中的UTF8String。
9. If the TLS negotiation is successful, the receiving entity MUST discard any knowledge obtained in an insecure manner from the initiating entity before TLS takes effect.
9. 如果TLS协商成功，接收实体必须在TLS生效之前放弃以不安全方式从发起实体获得的任何知识。
10. If the TLS negotiation is successful, the initiating entity MUST discard any knowledge obtained in an insecure manner from the receiving entity before TLS takes effect.
10. 如果TLS协商成功，发起实体必须在TLS生效之前放弃以不安全方式从接收实体获得的任何知识。
11. If the TLS negotiation is successful, the receiving entity MUST NOT offer the STARTTLS extension to the initiating entity along with the other stream features that are offered when the stream is restarted.
11. 如果TLS协商成功，接收实体不得向发起实体提供STARTTLS扩展以及流重新启动时提供的其他流功能。
12. If the TLS negotiation is successful, the initiating entity MUST continue with SASL negotiation.
12. 如果TLS谈判成功，发起实体必须继续SASL谈判。
13. If the TLS negotiation results in failure, the receiving entity MUST terminate both the XML stream and the underlying TCP connection.
13. 如果TLS协商失败，则接收实体必须终止XML流和底层TCP连接。
14. See Mandatory-to-Implement Technologies (Section 14.7) regarding mechanisms that MUST be supported.
14. 关于必须支持的机制，请参见强制实施技术（第14.7节）。
The [ASN.1] Object Identifier "id-on-xmppAddr" described above is defined as follows:
上述[ASN.1]对象标识符“xmppAddr上的id”定义如下：
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms
id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms
id-on-xmppAddr OBJECT IDENTIFIER ::= { id-on 5 }
id-on-xmppAddr OBJECT IDENTIFIER ::= { id-on 5 }
XmppAddr ::= UTF8String
XmppAddr ::= UTF8String
This Object Identifier MAY also be represented in the dotted display format as "1.3.6.1.5.5.7.8.5".
该对象标识符也可以用虚线显示格式表示为“1.3.6.1.5.5.7.8.5”。
When an initiating entity secures a stream with a receiving entity using TLS, the steps involved are as follows:
当发起实体使用TLS与接收实体保护流时，涉及的步骤如下：
1. The initiating entity opens a TCP connection and initiates the stream by sending the opening XML stream header to the receiving entity, including the 'version' attribute set to a value of at least "1.0".
1. 发起实体打开TCP连接并通过向接收实体发送打开的XML流头来发起流，包括设置为至少“1.0”值的“版本”属性。
2. The receiving entity responds by opening a TCP connection and sending an XML stream header to the initiating entity, including the 'version' attribute set to a value of at least "1.0".
2. 接收实体通过打开TCP连接并向发起实体发送XML流头来响应，包括设置为至少“1.0”值的“版本”属性。
3. The receiving entity offers the STARTTLS extension to the initiating entity by including it with the list of other supported stream features (if TLS is required for interaction with the receiving entity, it SHOULD signal that fact by including a <required/> element as a child of the <starttls/> element).
3. 接收实体通过将STARTTLS扩展包含在其他受支持的流特性列表中，向发起实体提供STARTTLS扩展（如果与接收实体交互需要TLS，则应通过将<required/>元素包含为<STARTTLS/>元素的子元素来表示这一事实）。
4. The initiating entity issues the STARTTLS command (i.e., a <starttls/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the receiving entity that it wishes to begin a TLS negotiation to secure the stream.
4. 发起实体发出STARTTLS命令（即，由“urn:ietf:params:xml:ns:xmpp-tls”命名空间限定的<STARTTLS/>元素），以指示接收实体希望开始tls协商以保护流。
5. The receiving entity MUST reply with either a <proceed/> element or a <failure/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace. If the failure case occurs, the receiving entity MUST terminate both the XML stream and the underlying TCP connection. If the proceed case occurs, the entities MUST attempt to complete the TLS negotiation over the TCP connection and MUST NOT send any further XML data until the TLS negotiation is complete.
5. 接收实体必须使用由“urn:ietf:params:xml:ns:xmpp-tls”命名空间限定的<procedure/>元素或<failure/>元素进行回复。如果发生故障，接收实体必须终止XML流和底层TCP连接。如果发生继续情况，实体必须尝试通过TCP连接完成TLS协商，并且在TLS协商完成之前，不得发送任何进一步的XML数据。
6. The initiating entity and receiving entity attempt to complete a TLS negotiation in accordance with [TLS].
6. 发起实体和接收实体试图根据[TLS]完成TLS协商。
7. If the TLS negotiation is unsuccessful, the receiving entity MUST terminate the TCP connection. If the TLS negotiation is successful, the initiating entity MUST initiate a new stream by sending an opening XML stream header to the receiving entity (it is not necessary to send a closing </stream> tag first, since the receiving entity and initiating entity MUST consider the original stream to be closed upon successful TLS negotiation).
7. 如果TLS协商不成功，接收实体必须终止TCP连接。如果TLS协商成功，则发起实体必须通过向接收方实体发送开放XML流报头来启动新流（不必首先发送关闭<流>标签，因为接收实体和发起实体必须考虑在成功TLS协商时关闭原始流）。
8. Upon receiving the new stream header from the initiating entity, the receiving entity MUST respond by sending a new XML stream header to the initiating entity along with the available features (but not including the STARTTLS feature).
8. 从发起实体接收到新的流头后，接收实体必须通过向发起实体发送新的XML流头以及可用的功能（但不包括STARTTLS功能）来响应。
The following example shows the data flow for a client securing a stream using STARTTLS (note: the alternate steps shown below are provided to illustrate the protocol for failure cases; they are not exhaustive and would not necessarily be triggered by the data sent in the example).
下面的示例显示了使用STARTTLS保护流的客户端的数据流（注意：下面显示的替代步骤用于说明故障情况下的协议；这些步骤并不详尽，并且不一定由示例中发送的数据触发）。
Step 1: Client initiates stream to server:
步骤1：客户端向服务器发起流：
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 2: Server responds by sending a stream tag to client:
步骤2：服务器通过向客户端发送流标记进行响应：
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_123'
from='example.com'
version='1.0'>
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_123'
from='example.com'
version='1.0'>
Step 3: Server sends the STARTTLS extension to client along with authentication mechanisms and any other stream features:
步骤3：服务器向客户端发送STARTTLS扩展以及身份验证机制和任何其他流功能：
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
</stream:features>
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
</stream:features>
Step 4: Client sends the STARTTLS command to server:
步骤4：客户端向服务器发送STARTTLS命令：
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
Step 5: Server informs client that it is allowed to proceed:
步骤5：服务器通知客户端允许继续：
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
Step 5 (alt): Server informs client that TLS negotiation has failed and closes both stream and TCP connection:
步骤5（alt）：服务器通知客户端TLS协商失败，并关闭流和TCP连接：
<failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</stream:stream>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</stream:stream>
Step 6: Client and server attempt to complete TLS negotiation over the existing TCP connection.
步骤6：客户端和服务器尝试通过现有TCP连接完成TLS协商。
Step 7: If TLS negotiation is successful, client initiates a new stream to server:
步骤7：如果TLS协商成功，客户端将向服务器发起一个新流：
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP connection.
步骤7（alt）：如果TLS协商不成功，服务器将关闭TCP连接。
Step 8: Server responds by sending a stream header to client along with any available stream features:
步骤8：服务器通过向客户端发送流头以及任何可用的流功能进行响应：
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='c2s_234'
version='1.0'>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='c2s_234'
version='1.0'>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>
Step 9: Client continues with SASL negotiation (Section 6).
第9步：客户继续SASL谈判（第6节）。
The following example shows the data flow for two servers securing a stream using STARTTLS (note: the alternate steps shown below are provided to illustrate the protocol for failure cases; they are not exhaustive and would not necessarily be triggered by the data sent in the example).
以下示例显示了使用STARTTLS保护流的两台服务器的数据流（注意：下面所示的备选步骤用于说明故障情况下的协议；它们并不详尽，并且不一定由示例中发送的数据触发）。
Step 1: Server1 initiates stream to Server2:
步骤1:Server1向Server2发起流：
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 2: Server2 responds by sending a stream tag to Server1:
步骤2:Server2通过向Server1发送流标记进行响应：
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_123'
version='1.0'>
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_123'
version='1.0'>
Step 3: Server2 sends the STARTTLS extension to Server1 along with authentication mechanisms and any other stream features:
步骤3:Server2向Server1发送STARTTLS扩展以及身份验证机制和任何其他流功能：
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism>
</mechanisms>
</stream:features>
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism>
</mechanisms>
</stream:features>
Step 4: Server1 sends the STARTTLS command to Server2:
步骤4:Server1向Server2发送STARTTLS命令：
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
Step 5: Server2 informs Server1 that it is allowed to proceed:
步骤5:Server2通知Server1允许继续：
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed and closes stream:
步骤5（alt）：Server2通知Server1 TLS协商失败并关闭流：
<failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</stream:stream>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</stream:stream>
Step 6: Server1 and Server2 attempt to complete TLS negotiation via TCP.
步骤6:Server1和Server2尝试通过TCP完成TLS协商。
Step 7: If TLS negotiation is successful, Server1 initiates a new stream to Server2:
步骤7：如果TLS协商成功，Server1将向Server2发起一个新流：
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 7 (alt): If TLS negotiation is unsuccessful, Server2 closes TCP connection.
步骤7（alt）：如果TLS协商不成功，Server2将关闭TCP连接。
Step 8: Server2 responds by sending a stream header to Server1 along with any available stream features:
步骤8:Server2通过向Server1发送流头以及任何可用流功能来响应：
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_234'
version='1.0'>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_234'
version='1.0'>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>
Step 9: Server1 continues with SASL negotiation (Section 6).
步骤9:Server1继续SASL协商（第6节）。
XMPP includes a method for authenticating a stream by means of an XMPP-specific profile of the Simple Authentication and Security Layer (SASL) protocol [SASL]. SASL provides a generalized method for adding authentication support to connection-based protocols, and XMPP uses a generic XML namespace profile for SASL that conforms to the profiling requirements of [SASL].
XMPP包括通过简单认证和安全层（SASL）协议[SASL]的XMPP特定简档来认证流的方法。SASL提供了一种通用方法，用于向基于连接的协议添加身份验证支持，XMPP为SASL使用一个通用的XML名称空间配置文件，该配置文件符合[SASL]的配置要求。
The following rules apply:
以下规则适用：
1. If the SASL negotiation occurs between two servers, communications MUST NOT proceed until the Domain Name System (DNS) hostnames asserted by the servers have been resolved (see Server-to-Server Communications (Section 14.4)).
1. 如果两台服务器之间发生SASL协商，则在解析服务器断言的域名系统（DNS）主机名之前，不得进行通信（请参阅服务器到服务器通信（第14.4节））。
2. If the initiating entity is capable of SASL negotiation, it MUST include the 'version' attribute set to a value of at least "1.0" in the initial stream header.
2. 如果发起实体能够进行SASL协商，则它必须在初始流标头中包含设置为至少“1.0”值的“版本”属性。
3. If the receiving entity is capable of SASL negotiation, it MUST advertise one or more authentication mechanisms within a <mechanisms/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in reply to the opening stream tag received from the initiating entity (if the opening stream tag included the 'version' attribute set to a value of at least "1.0").
3. 如果接收实体能够进行SASL协商，则它必须在由“urn:ietf:params:xml:ns:xmpp-SASL”命名空间限定的<mechanism/>元素中公布一个或多个身份验证机制，以响应从发起实体接收的开始流标记（如果期初流标记包含设置为至少“1.0”的“版本”属性）。
4. During SASL negotiation, an entity MUST NOT send any white space characters (matching production [3] content of [XML]) within the root stream element as separators between elements (any white space characters shown in the SASL examples below are included for the sake of readability only); this prohibition helps to ensure proper security layer byte precision.
4. 在SASL协商期间，实体不得在根流元素内发送任何空白字符（匹配[XML]的生产[3]内容）作为元素之间的分隔符（以下SASL示例中显示的任何空白字符仅出于可读性考虑）；此禁止有助于确保适当的安全层字节精度。
5. Any XML character data contained within the XML elements used during SASL negotiation MUST be encoded using base64, where the encoding adheres to the definition in Section 3 of RFC 3548 [BASE64].
5. SASL协商期间使用的XML元素中包含的任何XML字符数据必须使用base64编码，其中编码符合RFC 3548[base64]第3节中的定义。
6. If provision of a "simple username" is supported by the selected SASL mechanism (e.g., this is supported by the DIGEST-MD5 and CRAM-MD5 mechanisms but not by the EXTERNAL and GSSAPI mechanisms), during authentication the initiating entity SHOULD provide as the simple username its sending domain (IP address or fully qualified domain name as contained in a domain identifier)
6. 如果所选SASL机制支持提供“简单用户名”（例如，DIGEST-MD5和CRAM-MD5机制支持，但外部和GSSAPI机制不支持），则在身份验证期间，发起实体应将其发送域作为简单用户名提供（IP地址或包含在域标识符中的完全限定域名）
in the case of server-to-server communications or its registered account name (user or node name as contained in an XMPP node identifier) in the case of client-to-server communications.
对于服务器到服务器的通信，或对于客户端到服务器的通信，其注册帐户名（XMPP节点标识符中包含的用户或节点名）。
7. If the initiating entity wishes to act on behalf of another entity and the selected SASL mechanism supports transmission of an authorization identity, the initiating entity MUST provide an authorization identity during SASL negotiation. If the initiating entity does not wish to act on behalf of another entity, it MUST NOT provide an authorization identity. As specified in [SASL], the initiating entity MUST NOT provide an authorization identity unless the authorization identity is different from the default authorization identity derived from the authentication identity as described in [SASL]. If provided, the value of the authorization identity MUST be of the form <domain> (i.e., a domain identifier only) for servers and of the form <node@domain> (i.e., node identifier and domain identifier) for clients.
7. 如果发起实体希望代表另一实体行事，且所选SASL机制支持授权标识的传输，则发起实体必须在SASL协商期间提供授权标识。如果发起实体不希望代表另一实体行事，则不得提供授权标识。如[SASL]中所述，发起实体不得提供授权标识，除非授权标识不同于[SASL]中所述从身份验证标识派生的默认授权标识。如果提供，授权标识的值必须为服务器的格式<域>（即，仅限域标识符）和格式<node@domain>（即节点标识符和域标识符）用于客户端。
8. Upon successful SASL negotiation that involves negotiation of a security layer, the receiving entity MUST discard any knowledge obtained from the initiating entity which was not obtained from the SASL negotiation itself.
8. 成功进行涉及安全层协商的SASL协商后，接收实体必须放弃从发起实体获得的、并非从SASL协商本身获得的任何知识。
9. Upon successful SASL negotiation that involves negotiation of a security layer, the initiating entity MUST discard any knowledge obtained from the receiving entity which was not obtained from the SASL negotiation itself.
9. 成功进行涉及安全层协商的SASL协商后，发起实体必须放弃从接收实体获得的、并非从SASL协商本身获得的任何知识。
10. See Mandatory-to-Implement Technologies (Section 14.7) regarding mechanisms that MUST be supported.
10. 关于必须支持的机制，请参见强制实施技术（第14.7节）。
When an initiating entity authenticates with a receiving entity using SASL, the steps involved are as follows:
当发起实体使用SASL与接收实体进行身份验证时，涉及的步骤如下：
1. The initiating entity requests SASL authentication by including the 'version' attribute in the opening XML stream header sent to the receiving entity, with the value set to "1.0".
1. 发起实体通过在发送给接收实体的开始XML流头中包含“version”属性请求SASL身份验证，该属性的值设置为“1.0”。
2. After sending an XML stream header in reply, the receiving entity advertises a list of available SASL authentication mechanisms; each of these is a <mechanism/> element included as a child within a <mechanisms/> container element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, which in turn is a child of a <features/> element in the streams namespace. If Use of TLS (Section 5) needs to be established before a particular
2. 在应答发送XML流报头之后，接收实体播发可用SASL认证机制的列表；其中每个元素都是一个<mechanism/>元素，作为子元素包含在由“urn:ietf:params:xml:ns:xmpp-sasl”命名空间限定的<mechanism/>容器元素中，而该命名空间又是streams命名空间中<features/>元素的子元素。如果需要在特定事件之前确定TLS的使用（第5节）
authentication mechanism may be used, the receiving entity MUST NOT provide that mechanism in the list of available SASL authentication mechanisms prior to TLS negotiation. If the initiating entity presents a valid certificate during prior TLS negotiation, the receiving entity SHOULD offer the SASL EXTERNAL mechanism to the initiating entity during SASL negotiation (refer to [SASL]), although the EXTERNAL mechanism MAY be offered under other circumstances as well.
可以使用身份验证机制，但在TLS协商之前，接收实体不得在可用SASL身份验证机制列表中提供该机制。如果发起实体在之前的TLS谈判期间出示了有效证书，接收实体应在SASL谈判期间向发起实体提供SASL外部机制（参考[SASL]），尽管在其他情况下也可能提供外部机制。
3. The initiating entity selects a mechanism by sending an <auth/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving entity and including an appropriate value for the 'mechanism' attribute. This element MAY contain XML character data (in SASL terminology, the "initial response") if the mechanism supports or requires it; if the initiating entity needs to send a zero-length initial response, it MUST transmit the response as a single equals sign ("="), which indicates that the response is present but contains no data.
3. 发起实体通过向接收实体发送由“urn:ietf:params:xml:ns:xmpp-sasl”命名空间限定的<auth/>元素并为“mechanism”属性包含适当的值来选择机制。如果机制支持或需要，该元素可能包含XML字符数据（在SASL术语中称为“初始响应”）；如果发起实体需要发送长度为零的初始响应，则它必须以单个等号（“=”）的形式发送响应，这表示响应存在，但不包含任何数据。
4. If necessary, the receiving entity challenges the initiating entity by sending a <challenge/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating entity; this element MAY contain XML character data (which MUST be computed in accordance with the definition of the SASL mechanism chosen by the initiating entity).
4. 如有必要，接收实体通过向发起实体发送由“urn:ietf:params:xml:ns:xmpp-sasl”命名空间限定的<challenge/>元素来向发起实体发起质询；此元素可能包含XML字符数据（必须根据发起实体选择的SASL机制的定义计算）。
5. The initiating entity responds to the challenge by sending a <response/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving entity; this element MAY contain XML character data (which MUST be computed in accordance with the definition of the SASL mechanism chosen by the initiating entity).
5. 发起实体通过向接收实体发送由“urn:ietf:params:xml:ns:xmpp-sasl”命名空间限定的<response/>元素来响应质询；此元素可能包含XML字符数据（必须根据发起实体选择的SASL机制的定义计算）。
6. If necessary, the receiving entity sends more challenges and the initiating entity sends more responses.
6. 如有必要，接收实体发送更多挑战，发起实体发送更多响应。
This series of challenge/response pairs continues until one of three things happens:
这一系列挑战/响应对将持续进行，直到发生以下三种情况之一：
1. The initiating entity aborts the handshake by sending an <abort/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving entity. Upon receiving an <abort/> element, the receiving entity SHOULD allow a configurable but reasonable number of retries (at least 2), after which it MUST terminate the TCP connection; this enables the initiating entity (e.g., an end-user client) to tolerate incorrectly-provided credentials (e.g., a mistyped password) without being forced to reconnect.
1. 发起实体通过向接收实体发送由“urn:ietf:params:xml:ns:xmpp-sasl”命名空间限定的<abort/>元素来中止握手。接收到<abort/>元素后，接收实体应允许可配置但合理的重试次数（至少2次），之后必须终止TCP连接；这使发起实体（例如，最终用户客户端）能够容忍错误提供的凭据（例如，输入错误的密码），而不必被迫重新连接。
2. The receiving entity reports failure of the handshake by sending a <failure/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating entity (the particular cause of failure SHOULD be communicated in an appropriate child element of the <failure/> element as defined under SASL Errors (Section 6.4)). If the failure case occurs, the receiving entity SHOULD allow a configurable but reasonable number of retries (at least 2), after which it MUST terminate the TCP connection; this enables the initiating entity (e.g., an end-user client) to tolerate incorrectly-provided credentials (e.g., a mistyped password) without being forced to reconnect.
2. 接收实体通过向发起实体发送由“urn:ietf:params:xml:ns:xmpp-sasl”命名空间限定的<failure/>元素来报告握手失败（失败的特定原因应在sasl Errors（第6.4节）中定义的<failure/>元素的适当子元素中传达）。如果发生故障，接收实体应允许可配置但合理的重试次数（至少2次），之后必须终止TCP连接；这使发起实体（例如，最终用户客户端）能够容忍错误提供的凭据（例如，输入错误的密码），而不必被迫重新连接。
3. The receiving entity reports success of the handshake by sending a <success/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating entity; this element MAY contain XML character data (in SASL terminology, "additional data with success") if required by the chosen SASL mechanism. Upon receiving the <success/> element, the initiating entity MUST initiate a new stream by sending an opening XML stream header to the receiving entity (it is not necessary to send a closing </stream> tag first, since the receiving entity and initiating entity MUST consider the original stream to be closed upon sending or receiving the <success/> element). Upon receiving the new stream header from the initiating entity, the receiving entity MUST respond by sending a new XML stream header to the initiating entity, along with any available features (but not including the STARTTLS and SASL features) or an empty <features/> element (to signify that no additional features are available); any such additional features not defined herein MUST be defined by the relevant extension to XMPP.
3. 接收实体通过向发起实体发送由“urn:ietf:params:xml:ns:xmpp-sasl”命名空间限定的<success/>元素来报告握手成功；如果所选SASL机制需要，此元素可能包含XML字符数据（在SASL术语中为“成功的附加数据”）。在接收到<success/>元素后，发起实体必须通过向接收实体发送打开的XML流头来发起新流（没有必要先发送关闭<流>标签，因为接收实体和发起实体在发送或接收<成功/>元素时必须考虑原始流被关闭）。。从发起实体接收到新的流标头后，接收实体必须通过向发起实体发送新的XML流标头以及任何可用的功能（但不包括STARTTLS和SASL功能）或空的<features/>元素（表示没有其他可用功能）来响应；此处未定义的任何此类附加功能必须由XMPP的相关扩展定义。
The profiling requirements of [SASL] require that the following information be supplied by a protocol definition:
[SASL]的分析要求通过协议定义提供以下信息：
service name: "xmpp"
服务名称：“xmpp”
initiation sequence: After the initiating entity provides an opening XML stream header and the receiving entity replies in kind, the receiving entity provides a list of acceptable authentication methods. The initiating entity chooses one method from the list and sends it to the receiving entity as the value of the 'mechanism' attribute possessed by an <auth/> element, optionally including an initial response to avoid a round trip.
发起顺序：在发起实体提供一个打开的XML流头并且接收实体以实物形式回复之后，接收实体提供一个可接受的身份验证方法列表。发起实体从列表中选择一种方法，并将其作为<auth/>元素拥有的“机制”属性的值发送给接收实体，可选地包括初始响应以避免往返。
exchange sequence: Challenges and responses are carried through the exchange of <challenge/> elements from receiving entity to initiating entity and <response/> elements from initiating entity to receiving entity. The receiving entity reports failure by sending a <failure/> element and success by sending a <success/> element; the initiating entity aborts the exchange by sending an <abort/> element. Upon successful negotiation, both sides consider the original XML stream to be closed and new stream headers are sent by both entities.
交换顺序：挑战和响应通过从接收实体到发起实体的<challenge/>元素交换和从发起实体到接收实体的<response/>元素交换进行。接收实体通过发送<failure/>元素报告失败，通过发送<success/>元素报告成功；发起实体通过发送<abort/>元素中止交换。在成功的协商之后，双方都认为原始XML流被关闭，并且两个实体都发送新的流头。
security layer negotiation: The security layer takes effect immediately after sending the closing ">" character of the <success/> element for the receiving entity, and immediately after receiving the closing ">" character of the <success/> element for the initiating entity. The order of layers is first [TCP], then [TLS], then [SASL], then XMPP.
安全层协商：安全层在发送接收实体的<success/>元素的结束“>”字符后立即生效，在接收发起实体的<success/>元素的结束“>”字符后立即生效。层的顺序首先是[TCP]，然后是[TLS]，然后是[SASL]，然后是XMPP。
use of the authorization identity: The authorization identity may be used by xmpp to denote the non-default <node@domain> of a client or the sending <domain> of a server.
授权标识的使用：xmpp可以使用授权标识来表示非默认值<node@domain>客户端或服务器的发送<domain>。
The following SASL-related error conditions are defined:
定义了以下与SASL相关的错误条件：
o <aborted/> -- The receiving entity acknowledges an <abort/> element sent by the initiating entity; sent in reply to the <abort/> element.
o <abort/>——接收实体确认发起实体发送的<abort/>元素；发送以回复<abort/>元素。
o <incorrect-encoding/> -- The data provided by the initiating entity could not be processed because the [BASE64] encoding is incorrect (e.g., because the encoding does not adhere to the definition in Section 3 of [BASE64]); sent in reply to a <response/> element or an <auth/> element with initial response data.
o <Error encoding/>——由于[BASE64]编码不正确（例如，因为编码不符合[BASE64]第3节中的定义），无法处理发起实体提供的数据；发送给带有初始响应数据的<response/>元素或<auth/>元素。
o <invalid-authzid/> -- The authzid provided by the initiating entity is invalid, either because it is incorrectly formatted or because the initiating entity does not have permissions to authorize that ID; sent in reply to a <response/> element or an <auth/> element with initial response data.
o <invalid authzid/>——发起实体提供的authzid无效，原因可能是格式不正确，或者发起实体没有授权该ID的权限；发送给带有初始响应数据的<response/>元素或<auth/>元素。
o <invalid-mechanism/> -- The initiating entity did not provide a mechanism or requested a mechanism that is not supported by the receiving entity; sent in reply to an <auth/> element.
o <invalid mechanism/>——发起实体未提供接收实体不支持的机制或请求的机制；作为对<auth/>元素的回复发送。
o <mechanism-too-weak/> -- The mechanism requested by the initiating entity is weaker than server policy permits for that initiating entity; sent in reply to a <response/> element or an <auth/> element with initial response data.
o <机制太弱/>——发起实体请求的机制弱于该发起实体的服务器策略许可；发送给带有初始响应数据的<response/>元素或<auth/>元素。
o <not-authorized/> -- The authentication failed because the initiating entity did not provide valid credentials (this includes but is not limited to the case of an unknown username); sent in reply to a <response/> element or an <auth/> element with initial response data.
o <not authorized/>--身份验证失败，因为发起实体未提供有效凭据（这包括但不限于未知用户名的情况）；发送给带有初始响应数据的<response/>元素或<auth/>元素。
o <temporary-auth-failure/> -- The authentication failed because of a temporary error condition within the receiving entity; sent in reply to an <auth/> element or <response/> element.
o <temporary auth failure/>——由于接收实体内的临时错误条件，身份验证失败；作为对<auth/>元素或<response/>元素的回复发送。
The following example shows the data flow for a client authenticating with a server using SASL, normally after successful TLS negotiation (note: the alternate steps shown below are provided to illustrate the protocol for failure cases; they are not exhaustive and would not necessarily be triggered by the data sent in the example).
以下示例显示了通常在成功的TLS协商之后，使用SASL与服务器进行身份验证的客户机的数据流（注意：下面显示的备选步骤用于说明失败情况下的协议；这些步骤并不详尽，也不一定由示例中发送的数据触发）。
Step 1: Client initiates stream to server:
步骤1：客户端向服务器发起流：
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 2: Server responds with a stream tag sent to client:
步骤2：服务器用发送到客户端的流标记进行响应：
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_234'
from='example.com'
version='1.0'>
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_234'
from='example.com'
version='1.0'>
Step 3: Server informs client of available authentication mechanisms:
步骤3：服务器通知客户端可用的身份验证机制：
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
</stream:features>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
</stream:features>
Step 4: Client selects an authentication mechanism:
步骤4：客户端选择身份验证机制：
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='DIGEST-MD5'/>
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='DIGEST-MD5'/>
Step 5: Server sends a [BASE64] encoded challenge to client:
步骤5：服务器向客户端发送[BASE64]编码的质询：
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi
LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg==
</challenge>
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi
LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg==
</challenge>
The decoded challenge is:
解码的挑战是：
realm="somerealm",nonce="OA6MG9tEQGm2hh",\
qop="auth",charset=utf-8,algorithm=md5-sess
realm="somerealm",nonce="OA6MG9tEQGm2hh",\
qop="auth",charset=utf-8,algorithm=md5-sess
Step 5 (alt): Server returns error to client:
步骤5（alt）：服务器向客户端返回错误：
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<incorrect-encoding/>
</failure>
</stream:stream>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<incorrect-encoding/>
</failure>
</stream:stream>
Step 6: Client sends a [BASE64] encoded response to the challenge:
步骤6：客户端向质询发送[BASE64]编码响应：
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i
T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw
MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i
LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo
YXJzZXQ9dXRmLTgK
</response>
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i
T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw
MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i
LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo
YXJzZXQ9dXRmLTgK
</response>
The decoded response is:
解码的响应是：
username="somenode",realm="somerealm",\
nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\
nc=00000001,qop=auth,digest-uri="xmpp/example.com",\
response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
username="somenode",realm="somerealm",\
nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\
nc=00000001,qop=auth,digest-uri="xmpp/example.com",\
response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
Step 7: Server sends another [BASE64] encoded challenge to client:
步骤7：服务器向客户端发送另一个[BASE64]编码的质询：
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
</challenge>
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
</challenge>
The decoded challenge is:
解码的挑战是：
rspauth=ea40f60335c427b5527b84dbabcdfffd
rspauth=ea40f60335c427b5527b84dbabcdfffd
Step 7 (alt): Server returns error to client:
步骤7（alt）：服务器向客户端返回错误：
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/>
</failure>
</stream:stream>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/>
</failure>
</stream:stream>
Step 8: Client responds to the challenge:
步骤8：客户机响应挑战：
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9: Server informs client of successful authentication:
步骤9：服务器通知客户端身份验证成功：
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9 (alt): Server informs client of failed authentication:
步骤9（alt）：服务器通知客户端身份验证失败：
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/>
</failure>
</stream:stream>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/>
</failure>
</stream:stream>
Step 10: Client initiates a new stream to server:
步骤10：客户端向服务器发起新流：
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 11: Server responds by sending a stream header to client along with any additional features (or an empty features element):
步骤11：服务器通过向客户端发送流头以及任何附加功能（或空功能元素）来响应：
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_345'
from='example.com'
version='1.0'>
<stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
</stream:features>
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_345'
from='example.com'
version='1.0'>
<stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
</stream:features>
The following example shows the data flow for a server authenticating with another server using SASL, normally after successful TLS negotiation (note: the alternate steps shown below are provided to illustrate the protocol for failure cases; they are not exhaustive and would not necessarily be triggered by the data sent in the example).
以下示例显示了通常在成功的TLS协商之后，使用SASL与另一台服务器进行身份验证的服务器的数据流（注意：以下所示的备选步骤用于说明故障情况下的协议；这些步骤并不详尽，也不一定由示例中发送的数据触发）。
Step 1: Server1 initiates stream to Server2:
步骤1:Server1向Server2发起流：
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 2: Server2 responds with a stream tag sent to Server1:
步骤2:Server2响应发送到Server1的流标记：
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_234'
version='1.0'>
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_234'
version='1.0'>
Step 3: Server2 informs Server1 of available authentication mechanisms:
步骤3:Server2通知Server1可用的身份验证机制：
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism>
</mechanisms>
</stream:features>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism>
</mechanisms>
</stream:features>
Step 4: Server1 selects an authentication mechanism:
步骤4:Server1选择身份验证机制：
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='DIGEST-MD5'/>
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='DIGEST-MD5'/>
Step 5: Server2 sends a [BASE64] encoded challenge to Server1:
步骤5:Server2向Server1发送[BASE64]编码的质询：
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9
ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz
</challenge>
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9
ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz
</challenge>
The decoded challenge is:
解码的挑战是：
realm="somerealm",nonce="OA6MG9tEQGm2hh",\
qop="auth",charset=utf-8,algorithm=md5-sess
realm="somerealm",nonce="OA6MG9tEQGm2hh",\
qop="auth",charset=utf-8,algorithm=md5-sess
Step 5 (alt): Server2 returns error to Server1:
步骤5（alt）：Server2向Server1返回错误：
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<incorrect-encoding/>
</failure>
</stream:stream>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<incorrect-encoding/>
</failure>
</stream:stream>
Step 6: Server1 sends a [BASE64] encoded response to the challenge:
步骤6:Server1向质询发送[BASE64]编码响应：
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
dXNlcm5hbWU9ImV4YW1wbGUub3JnIixyZWFsbT0ic29tZXJlYWxtIixub25j
ZT0iT0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5j
PTAwMDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5v
cmciLHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3
LGNoYXJzZXQ9dXRmLTgK
</response>
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
dXNlcm5hbWU9ImV4YW1wbGUub3JnIixyZWFsbT0ic29tZXJlYWxtIixub25j
ZT0iT0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5j
PTAwMDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5v
cmciLHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3
LGNoYXJzZXQ9dXRmLTgK
</response>
The decoded response is:
解码的响应是：
username="example.org",realm="somerealm",\
nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\
nc=00000001,qop=auth,digest-uri="xmpp/example.org",\
response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
username="example.org",realm="somerealm",\
nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\
nc=00000001,qop=auth,digest-uri="xmpp/example.org",\
response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
Step 7: Server2 sends another [BASE64] encoded challenge to Server1:
步骤7:Server2向Server1发送另一个[BASE64]编码的质询：
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
</challenge>
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
</challenge>
The decoded challenge is:
解码的挑战是：
rspauth=ea40f60335c427b5527b84dbabcdfffd
rspauth=ea40f60335c427b5527b84dbabcdfffd
Step 7 (alt): Server2 returns error to Server1:
步骤7（alt）：Server2向Server1返回错误：
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<invalid-authzid/>
</failure>
</stream:stream>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<invalid-authzid/>
</failure>
</stream:stream>
Step 8: Server1 responds to the challenge:
步骤8:Server1响应挑战：
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 8 (alt): Server1 aborts negotiation:
步骤8（alt）：服务器1中止协商：
<abort xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
<abort xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9: Server2 informs Server1 of successful authentication:
步骤9:Server2通知Server1身份验证成功：
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9 (alt): Server2 informs Server1 of failed authentication:
步骤9（alt）：Server2通知Server1身份验证失败：
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<aborted/>
</failure>
</stream:stream>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<aborted/>
</failure>
</stream:stream>
Step 10: Server1 initiates a new stream to Server2:
步骤10:Server1向Server2启动一个新流：
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 11: Server2 responds by sending a stream header to Server1 along with any additional features (or an empty features element):
步骤11:Server2通过向Server1发送流头以及任何附加功能（或空功能元素）来响应：
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_345'
version='1.0'>
<stream:features/>
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_345'
version='1.0'>
<stream:features/>
After SASL negotiation (Section 6) with the receiving entity, the initiating entity MAY want or need to bind a specific resource to that stream. In general this applies only to clients: in order to conform to the addressing format (Section 3) and stanza delivery rules (Section 10) specified herein, there MUST be a resource identifier associated with the <node@domain> of the client (which is
在与接收实体进行SASL协商（第6节）后，发起实体可能希望或需要将特定资源绑定到该流。通常，这仅适用于客户端：为了符合本文规定的寻址格式（第3节）和节交付规则（第10节），必须有与<node@domain>客户（即
either generated by the server or provided by the client application); this ensures that the address for use over that stream is a "full JID" of the form <node@domain/resource>.
由服务器生成或由客户端应用程序提供）；这确保在该流上使用的地址是表单的“完整JID”<node@domain/资源>。
Upon receiving a success indication within the SASL negotiation, the client MUST send a new stream header to the server, to which the server MUST respond with a stream header as well as a list of available stream features. Specifically, if the server requires the client to bind a resource to the stream after successful SASL negotiation, it MUST include an empty <bind/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace in the stream features list it presents to the client upon sending the header for the response stream sent after successful SASL negotiation (but not before):
在SASL协商中收到成功指示后，客户机必须向服务器发送一个新的流头，服务器必须用流头以及可用流功能列表对其进行响应。具体来说，如果服务器要求客户端在成功的SASL协商后将资源绑定到流，它必须包含一个空的<bind/>元素，该元素在成功SASL协商后（但不是之前）发送响应流的标头时，向客户端显示流功能列表中的“urn:ietf:params:xml:ns:xmpp bind”命名空间限定该元素：
Server advertises resource binding feature to client:
服务器向客户端播发资源绑定功能：
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_345'
from='example.com'
version='1.0'>
<stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
</stream:features>
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_345'
from='example.com'
version='1.0'>
<stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
</stream:features>
Upon being so informed that resource binding is required, the client MUST bind a resource to the stream by sending to the server an IQ stanza of type "set" (see IQ Semantics (Section 9.2.3)) containing data qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace.
在被告知需要资源绑定后，客户机必须通过向服务器发送“set”类型的IQ节（参见IQ语义（第9.2.3节））将资源绑定到流，该IQ节包含由“urn:ietf:params:xml:ns:xmpp bind”命名空间限定的数据。
If the client wishes to allow the server to generate the resource identifier on its behalf, it sends an IQ stanza of type "set" that contains an empty <bind/> element:
如果客户端希望允许服务器代表其生成资源标识符，它将发送一个“set”类型的IQ节，其中包含一个空的<bind/>元素：
Client asks server to bind a resource:
客户端要求服务器绑定资源：
<iq type='set' id='bind_1'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
</iq>
<iq type='set' id='bind_1'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
</iq>
A server that supports resource binding MUST be able to generate a resource identifier on behalf of a client. A resource identifier generated by the server MUST be unique for that <node@domain>.
支持资源绑定的服务器必须能够代表客户端生成资源标识符。服务器生成的资源标识符必须是唯一的<node@domain>.
If the client wishes to specify the resource identifier, it sends an IQ stanza of type "set" that contains the desired resource identifier as the XML character data of a <resource/> element that is a child of the <bind/> element:
如果客户端希望指定资源标识符，它将发送一个类型为“set”的IQ节，其中包含所需的资源标识符，作为<resource/>元素的XML字符数据，该元素是<bind/>元素的子元素：
Client binds a resource:
客户端绑定资源：
<iq type='set' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
</iq>
<iq type='set' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
</iq>
Once the server has generated a resource identifier for the client or accepted the resource identifier provided by the client, it MUST return an IQ stanza of type "result" to the client, which MUST include a <jid/> child element that specifies the full JID for the connected resource as determined by the server:
一旦服务器为客户机生成了资源标识符或接受了客户机提供的资源标识符，它必须向客户机返回一个类型为“result”的IQ节，该IQ节必须包含一个<jid/>子元素，指定由服务器确定的连接资源的完整jid：
Server informs client of successful resource binding:
服务器通知客户端资源绑定成功：
<iq type='result' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<jid>somenode@example.com/someresource</jid>
</bind>
</iq>
<iq type='result' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<jid>somenode@example.com/someresource</jid>
</bind>
</iq>
A server SHOULD accept the resource identifier provided by the client, but MAY override it with a resource identifier that the server generates; in this case, the server SHOULD NOT return a stanza error (e.g., <forbidden/>) to the client but instead SHOULD communicate the generated resource identifier to the client in the IQ result as shown above.
服务器应接受客户端提供的资源标识符，但可以使用服务器生成的资源标识符覆盖该标识符；在这种情况下，服务器不应该向客户端返回节错误（例如，<禁止/>），而是应该在IQ结果中将生成的资源标识符传递给客户端，如上所示。
When a client supplies a resource identifier, the following stanza error conditions are possible (see Stanza Errors (Section 9.3)):
当客户端提供资源标识符时，可能出现以下节错误情况（请参阅节错误（第9.3节））：
o The provided resource identifier cannot be processed by the server in accordance with Resourceprep (Appendix B).
o 服务器无法根据Resourceprep（附录B）处理提供的资源标识符。
o The client is not allowed to bind a resource to the stream (e.g., because the node or user has reached a limit on the number of connected resources allowed).
o 不允许客户端将资源绑定到流（例如，因为节点或用户已达到允许连接资源数量的限制）。
o The provided resource identifier is already in use but the server does not allow binding of multiple connected resources with the same identifier.
o 提供的资源标识符已在使用中，但服务器不允许使用同一标识符绑定多个连接的资源。
The protocol for these error conditions is shown below.
这些错误条件的协议如下所示。
Resource identifier cannot be processed:
无法处理资源标识符：
<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
Client is not allowed to bind a resource:
不允许客户端绑定资源：
<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='cancel'>
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='cancel'>
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
Resource identifier is in use:
资源标识符正在使用中：
<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
If, before completing the resource binding step, the client attempts to send an XML stanza other than an IQ stanza with a <bind/> child qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, the server MUST NOT process the stanza and SHOULD return a <not-authorized/> stanza error to the client.
如果在完成资源绑定步骤之前，客户端尝试发送一个XML节，而不是IQ节，该IQ节带有一个由“urn:ietf:params:XML:ns:xmpp bind”命名空间限定的<bind/>子节，则服务器不得处理该节，并应向客户端返回<NOT authorized/>节错误。
The Jabber protocols from which XMPP was adapted include a "server dialback" method for protecting against domain spoofing, thus making it more difficult to spoof XML stanzas. Server dialback is not a security mechanism, and results in weak verification of server identities only (see Server-to-Server Communications (Section 14.4) regarding this method's security characteristics). Domains requiring robust security SHOULD use TLS and SASL; see Server-to-Server Communications (Section 14.4) for details. If SASL is used for server-to-server authentication, dialback SHOULD NOT be used since it is unnecessary. Documentation of dialback is included mainly for the sake of backward-compatibility with existing implementations and deployments.
XMPP采用的Jabber协议包括一种防止域欺骗的“服务器回拨”方法，从而使欺骗XML节变得更加困难。服务器回拨不是一种安全机制，只会导致服务器身份的弱验证（有关此方法的安全特性，请参阅服务器到服务器通信（第14.4节））。需要强大安全性的域应使用TLS和SASL；有关详细信息，请参阅服务器到服务器通信（第14.4节）。如果SASL用于服务器到服务器身份验证，则不应使用回拨，因为它是不必要的。包含回拨文档主要是为了与现有实现和部署向后兼容。
The server dialback method is made possible by the existence of the Domain Name System (DNS), since one server can (normally) discover the authoritative server for a given domain. Because dialback depends on DNS, inter-domain communications MUST NOT proceed until the Domain Name System (DNS) hostnames asserted by the servers have been resolved (see Server-to-Server Communications (Section 14.4)).
由于域名系统（DNS）的存在，服务器回拨方法成为可能，因为一台服务器（通常）可以发现给定域的权威服务器。由于回拨依赖于DNS，在解析服务器断言的域名系统（DNS）主机名之前，域间通信不得继续（请参阅服务器到服务器通信（第14.4节））。
Server dialback is uni-directional, and results in (weak) verification of identities for one stream in one direction. Because server dialback is not an authentication mechanism, mutual authentication is not possible via dialback. Therefore, server dialback MUST be completed in each direction in order to enable bi-directional communications between two domains.
服务器回拨是单向的，会导致在一个方向上对一个流的身份进行（弱）验证。由于服务器回拨不是身份验证机制，因此无法通过回拨进行相互身份验证。因此，必须在每个方向上完成服务器回拨，以便在两个域之间实现双向通信。
The method for generating and verifying the keys used in server dialback MUST take into account the hostnames being used, the stream ID generated by the receiving server, and a secret known by the authoritative server's network. The stream ID is security-critical in server dialback and therefore MUST be both unpredictable and non-repeating (see [RANDOM] for recommendations regarding randomness for security purposes).
生成和验证服务器回拨中使用的密钥的方法必须考虑正在使用的主机名、接收服务器生成的流ID以及权威服务器网络已知的秘密。流ID在服务器回拨中是安全关键的，因此必须是不可预测和不重复的（请参阅[RANDOM]，以了解出于安全目的有关随机性的建议）。
Any error that occurs during dialback negotiation MUST be considered a stream error, resulting in termination of the stream and of the underlying TCP connection. The possible error conditions are specified in the protocol description below.
在回拨协商期间发生的任何错误都必须视为流错误，导致流和底层TCP连接终止。下面的协议描述中指定了可能的错误条件。
The following terminology applies:
以下术语适用：
o Originating Server -- the server that is attempting to establish a connection between two domains.
o 原始服务器--尝试在两个域之间建立连接的服务器。
o Receiving Server -- the server that is trying to authenticate that the Originating Server represents the domain which it claims to be.
o 接收服务器——尝试验证发起服务器是否代表其声称的域的服务器。
o Authoritative Server -- the server that answers to the DNS hostname asserted by the Originating Server; for basic environments this will be the Originating Server, but it could be a separate machine in the Originating Server's network.
o 权威服务器——响应发起服务器断言的DNS主机名的服务器；对于基本环境，这将是原始服务器，但它可以是原始服务器网络中的一台独立计算机。
The following is a brief summary of the order of events in dialback:
以下是回拨事件顺序的简要摘要：
1. The Originating Server establishes a connection to the Receiving Server.
1. 发起服务器与接收服务器建立连接。
2. The Originating Server sends a 'key' value over the connection to the Receiving Server.
2. 发起服务器通过连接向接收服务器发送“密钥”值。
3. The Receiving Server establishes a connection to the Authoritative Server.
3. 接收服务器建立到权威服务器的连接。
4. The Receiving Server sends the same 'key' value to the Authoritative Server.
4. 接收服务器向权威服务器发送相同的“密钥”值。
5. The Authoritative Server replies that key is valid or invalid.
5. 权威服务器答复密钥有效或无效。
6. The Receiving Server informs the Originating Server whether it is authenticated or not.
6. 接收服务器通知发起服务器它是否经过身份验证。
We can represent this flow of events graphically as follows:
我们可以用图形表示这一事件流，如下所示：
Originating Receiving
Server Server
----------- ---------
| |
| establish connection |
| ----------------------> |
| |
| send stream header |
| ----------------------> |
| |
| send stream header |
| <---------------------- |
| | Authoritative
| send dialback key | Server
| ----------------------> | -------------
| | |
| establish connection |
| ----------------------> |
| |
| send stream header |
| ----------------------> |
| |
| send stream header |
| <---------------------- |
| |
| send verify request |
| ----------------------> |
| |
| send verify response |
| <---------------------- |
|
| report dialback result |
| <---------------------- |
| |
Originating Receiving
Server Server
----------- ---------
| |
| establish connection |
| ----------------------> |
| |
| send stream header |
| ----------------------> |
| |
| send stream header |
| <---------------------- |
| | Authoritative
| send dialback key | Server
| ----------------------> | -------------
| | |
| establish connection |
| ----------------------> |
| |
| send stream header |
| ----------------------> |
| |
| send stream header |
| <---------------------- |
| |
| send verify request |
| ----------------------> |
| |
| send verify response |
| <---------------------- |
|
| report dialback result |
| <---------------------- |
| |
The detailed protocol interaction between the servers is as follows:
服务器之间的详细协议交互如下所示：
1. The Originating Server establishes TCP connection to the Receiving Server.
1. 发起服务器与接收服务器建立TCP连接。
2. The Originating Server sends a stream header to the Receiving Server:
2. 发起服务器向接收服务器发送流头：
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'>
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'>
Note: The 'to' and 'from' attributes are OPTIONAL on the root stream element. The inclusion of the xmlns:db namespace declaration with the name shown indicates to the Receiving Server that the Originating Server supports dialback. If the namespace name is incorrect, then the Receiving Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection.
注意：“to”和“from”属性在根流元素上是可选的。包含名称为的xmlns:db命名空间声明向接收服务器表明发起服务器支持回拨。如果名称空间名称不正确，则接收服务器必须生成<invalid namespace/>流错误条件，并终止XML流和底层TCP连接。
3. The Receiving Server SHOULD send a stream header back to the Originating Server, including a unique ID for this interaction:
3. 接收服务器应将流头发送回原始服务器，包括此交互的唯一ID：
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
id='457F9224A0...'>
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
id='457F9224A0...'>
Note: The 'to' and 'from' attributes are OPTIONAL on the root stream element. If the namespace name is incorrect, then the Originating Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection. Note well that the Receiving Server SHOULD reply but MAY silently terminate the XML stream and underlying TCP connection depending on security policies in place; however, if the Receiving Server desires to proceed, it MUST send a stream header back to the Originating Server.
注意：“to”和“from”属性在根流元素上是可选的。如果名称空间名称不正确，则发起服务器必须生成<invalid namespace/>流错误条件，并终止XML流和底层TCP连接。请注意，接收服务器应该应答，但可能会根据适当的安全策略以静默方式终止XML流和底层TCP连接；但是，如果接收服务器希望继续，它必须将流头发送回原始服务器。
4. The Originating Server sends a dialback key to the Receiving Server:
4. 发起服务器向接收服务器发送回拨密钥：
<db:result
to='Receiving Server'
from='Originating Server'>
98AF014EDC0...
</db:result>
<db:result
to='Receiving Server'
from='Originating Server'>
98AF014EDC0...
</db:result>
Note: This key is not examined by the Receiving Server, since the Receiving Server does not keep information about the Originating Server between sessions. The key generated by the Originating Server MUST be based in part on the value of the ID provided by the
注意：接收服务器不检查此密钥，因为接收服务器在会话之间不保留有关原始服务器的信息。发起服务器生成的密钥必须部分基于服务器提供的ID值
Receiving Server in the previous step, and in part on a secret shared by the Originating Server and Authoritative Server. If the value of the 'to' address does not match a hostname recognized by the Receiving Server, then the Receiving Server MUST generate a <host-unknown/> stream error condition and terminate both the XML stream and the underlying TCP connection. If the value of the 'from' address matches a domain with which the Receiving Server already has an established connection, then the Receiving Server MUST maintain the existing connection until it validates whether the new connection is legitimate; additionally, the Receiving Server MAY choose to generate a <not-authorized/> stream error condition for the new connection and then terminate both the XML stream and the underlying TCP connection related to the new request.
在上一步中接收服务器，并且部分基于由发起服务器和权威服务器共享的机密。如果“to”地址的值与接收服务器识别的主机名不匹配，则接收服务器必须生成<host unknown/>流错误条件，并终止XML流和底层TCP连接。如果“发件人”地址的值与接收服务器已建立连接的域相匹配，则接收服务器必须保持现有连接，直到验证新连接是否合法；此外，接收服务器可以选择为新连接生成<not authorized/>流错误条件，然后终止XML流和与新请求相关的底层TCP连接。
5. The Receiving Server establishes a TCP connection back to the domain name asserted by the Originating Server, as a result of which it connects to the Authoritative Server. (Note: As an optimization, an implementation MAY reuse an existing connection here.)
5. 接收服务器建立一个TCP连接，返回到发起服务器所断言的域名，从而连接到权威服务器。（注意：作为一种优化，实现可以在此处重用现有连接。）
6. The Receiving Server sends the Authoritative Server a stream header:
6. 接收服务器向权威服务器发送一个流头：
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'>
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'>
Note: The 'to' and 'from' attributes are OPTIONAL on the root stream element. If the namespace name is incorrect, then the Authoritative Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection.
注意：“to”和“from”属性在根流元素上是可选的。如果名称空间名称不正确，则权威服务器必须生成<invalid namespace/>流错误条件，并终止XML流和底层TCP连接。
7. The Authoritative Server sends the Receiving Server a stream header:
7. 权威服务器向接收服务器发送一个流头：
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
id='1251A342B...'>
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
id='1251A342B...'>
Note: If the namespace name is incorrect, then the Receiving Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection between it and the Authoritative Server. If a stream error occurs between the Receiving Server and the Authoritative Server, then the Receiving Server MUST generate a <remote-connection-failed/> stream
注意：如果名称空间名称不正确，则接收服务器必须生成<invalid namespace/>流错误条件，并终止XML流及其与权威服务器之间的底层TCP连接。如果接收服务器和权威服务器之间发生流错误，则接收服务器必须生成<remote connection failed/>流
error condition and terminate both the XML stream and the underlying TCP connection between it and the Originating Server.
设置错误条件并终止XML流及其与原始服务器之间的底层TCP连接。
8. The Receiving Server sends the Authoritative Server a request for verification of a key:
8. 接收服务器向权威服务器发送验证密钥的请求：
<db:verify
from='Receiving Server'
to='Originating Server'
id='457F9224A0...'>
98AF014EDC0...
</db:verify>
<db:verify
from='Receiving Server'
to='Originating Server'
id='457F9224A0...'>
98AF014EDC0...
</db:verify>
Note: Passed here are the hostnames, the original identifier from the Receiving Server's stream header to the Originating Server in Step 3, and the key that the Originating Server sent to the Receiving Server in Step 4. Based on this information, as well as shared secret information within the Authoritative Server's network, the key is verified. Any verifiable method MAY be used to generate the key. If the value of the 'to' address does not match a hostname recognized by the Authoritative Server, then the Authoritative Server MUST generate a <host-unknown/> stream error condition and terminate both the XML stream and the underlying TCP connection. If the value of the 'from' address does not match the hostname represented by the Receiving Server when opening the TCP connection (or any validated domain thereof, such as a validated subdomain of the Receiving Server's hostname or another validated domain hosted by the Receiving Server), then the Authoritative Server MUST generate an <invalid-from/> stream error condition and terminate both the XML stream and the underlying TCP connection.
注意：此处传递的是主机名、在步骤3中从接收服务器的流头传递到发起服务器的原始标识符，以及在步骤4中发起服务器发送到接收服务器的密钥。基于此信息以及权威服务器网络中的共享秘密信息，验证密钥。可以使用任何可验证的方法来生成密钥。如果“to”地址的值与权威服务器识别的主机名不匹配，则权威服务器必须生成<host unknown/>流错误条件，并终止XML流和底层TCP连接。如果“发件人”地址的值与打开TCP连接时接收服务器表示的主机名（或其任何验证域，如接收服务器主机名的验证子域或接收服务器托管的另一验证域）不匹配，然后，权威服务器必须生成<invalid from/>流错误条件，并终止XML流和底层TCP连接。
9. The Authoritative Server verifies whether the key was valid or invalid:
9. 权威服务器验证密钥是否有效：
<db:verify
from='Originating Server'
to='Receiving Server'
type='valid'
id='457F9224A0...'/>
<db:verify
from='Originating Server'
to='Receiving Server'
type='valid'
id='457F9224A0...'/>
or
或
<db:verify
from='Originating Server'
to='Receiving Server'
type='invalid'
id='457F9224A0...'/>
<db:verify
from='Originating Server'
to='Receiving Server'
type='invalid'
id='457F9224A0...'/>
Note: If the ID does not match that provided by the Receiving Server in Step 3, then the Receiving Server MUST generate an <invalid-id/> stream error condition and terminate both the XML stream and the underlying TCP connection. If the value of the 'to' address does not match a hostname recognized by the Receiving Server, then the Receiving Server MUST generate a <host-unknown/> stream error condition and terminate both the XML stream and the underlying TCP connection. If the value of the 'from' address does not match the hostname represented by the Originating Server when opening the TCP connection (or any validated domain thereof, such as a validated subdomain of the Originating Server's hostname or another validated domain hosted by the Originating Server), then the Receiving Server MUST generate an <invalid-from/> stream error condition and terminate both the XML stream and the underlying TCP connection. After returning the verification to the Receiving Server, the Authoritative Server SHOULD terminate the stream between them.
注意：如果ID与接收服务器在步骤3中提供的ID不匹配，则接收服务器必须生成<invalid ID/>流错误条件，并终止XML流和底层TCP连接。如果“to”地址的值与接收服务器识别的主机名不匹配，则接收服务器必须生成<host unknown/>流错误条件，并终止XML流和底层TCP连接。如果在打开TCP连接时，“发件人”地址的值与原始服务器表示的主机名不匹配（或其任何验证域，如原始服务器主机名的验证子域或原始服务器承载的另一验证域），然后，接收服务器必须生成<invalid from/>流错误条件，并终止XML流和底层TCP连接。将验证返回到接收服务器后，权威服务器应终止它们之间的流。
10. The Receiving Server informs the Originating Server of the result:
10. 接收服务器将结果通知发起服务器：
<db:result
from='Receiving Server'
to='Originating Server'
type='valid'/>
<db:result
from='Receiving Server'
to='Originating Server'
type='valid'/>
Note: At this point, the connection has either been validated via a type='valid', or reported as invalid. If the connection is invalid, then the Receiving Server MUST terminate both the XML stream and the underlying TCP connection. If the connection is validated, data can be sent by the Originating Server and read by the Receiving Server; before that, all XML stanzas sent to the Receiving Server SHOULD be silently dropped.
注意：此时，连接已通过type='valid'验证，或报告为无效。如果连接无效，则接收服务器必须终止XML流和底层TCP连接。如果连接已验证，则数据可由发起服务器发送并由接收服务器读取；在此之前，发送到接收服务器的所有XML节都应该以静默方式删除。
The result of the foregoing is that the Receiving Server has verified the identity of the Originating Server, so that the Originating Server can send, and the Receiving Server can accept, XML stanzas over the "initial stream" (i.e., the stream from the Originating Server to the Receiving Server). In order to verify the identities of the entities using the "response stream" (i.e., the stream from the Receiving Server to the Originating Server), dialback MUST be completed in the opposite direction as well.
前述的结果是，接收服务器已经验证了发起服务器的身份，使得发起服务器可以通过“初始流”（即，从发起服务器到接收服务器的流）发送并且接收服务器可以接受XML节。为了验证使用“响应流”（即从接收服务器到发起服务器的流）的实体的身份，还必须以相反的方向完成回拨。
After successful dialback negotiation, the Receiving Server SHOULD accept subsequent <db:result/> packets (e.g., validation requests sent to a subdomain or other hostname serviced by the Receiving Server) from the Originating Server over the existing validated connection; this enables "piggybacking" of the original validated connection in one direction.
成功的回拨协商后，接收服务器应通过现有的已验证连接接受来自发起服务器的后续<db:result/>数据包（例如，发送到子域或接收服务器提供服务的其他主机名的验证请求）；这样就可以在一个方向上“背负”原始的已验证连接。
Even if dialback negotiation is successful, a server MUST verify that all XML stanzas received from the other server include a 'from' attribute and a 'to' attribute; if a stanza does not meet this restriction, the server that receives the stanza MUST generate an <improper-addressing/> stream error condition and terminate both the XML stream and the underlying TCP connection. Furthermore, a server MUST verify that the 'from' attribute of stanzas received from the other server includes a validated domain for the stream; if a stanza does not meet this restriction, the server that receives the stanza MUST generate an <invalid-from/> stream error condition and terminate both the XML stream and the underlying TCP connection. Both of these checks help to prevent spoofing related to particular stanzas.
即使回拨协商成功，服务器也必须验证从其他服务器接收的所有XML节是否包含“from”属性和“to”属性；如果节不满足此限制，则接收节的服务器必须生成<不正确寻址/>流错误条件，并终止XML流和底层TCP连接。此外，服务器必须验证从其他服务器接收的节的“from”属性是否包含流的已验证域；如果节不满足此限制，则接收节的服务器必须生成<invalid from/>流错误条件，并终止XML流和底层TCP连接。这两种检查都有助于防止与特定节相关的欺骗。
After TLS negotiation (Section 5) if desired, SASL negotiation (Section 6), and Resource Binding (Section 7) if necessary, XML stanzas can be sent over the streams. Three kinds of XML stanza are defined for the 'jabber:client' and 'jabber:server' namespaces: <message/>, <presence/>, and <iq/>. In addition, there are five common attributes for these kinds of stanza. These common attributes, as well as the basic semantics of the three stanza kinds, are defined herein; more detailed information regarding the syntax of XML stanzas in relation to instant messaging and presence applications is provided in [XMPP-IM].
在TLS协商（第5节）（如果需要）、SASL协商（第6节）和资源绑定（第7节）（如果需要）之后，可以通过流发送XML节。为“jabber:client”和“jabber:server”名称空间定义了三种XML节：<message/>、<presence/>和<iq/>。此外，这类诗节有五个常见属性。本文定义了这些共同属性以及三个小节类型的基本语义；[XMPP-IM]中提供了与即时消息和状态应用程序相关的XML节语法的更多详细信息。
The following five attributes are common to message, presence, and IQ stanzas:
以下五个属性是消息、状态和IQ节共有的：
The 'to' attribute specifies the JID of the intended recipient for the stanza.
“to”属性指定节的预期收件人的JID。
In the 'jabber:client' namespace, a stanza SHOULD possess a 'to' attribute, although a stanza sent from a client to a server for handling by that server (e.g., presence sent to the server for broadcasting to other entities) SHOULD NOT possess a 'to' attribute.
在“jabber:client”命名空间中，节应具有“to”属性，尽管从客户端发送到服务器以供该服务器处理的节（例如，发送到服务器以向其他实体广播的状态）不应具有“to”属性。
In the 'jabber:server' namespace, a stanza MUST possess a 'to' attribute; if a server receives a stanza that does not meet this restriction, it MUST generate an <improper-addressing/> stream error condition and terminate both the XML stream and the underlying TCP connection with the offending server.
在'jabber:server'名称空间中，节必须具有'to'属性；如果服务器接收到不符合此限制的节，它必须生成一个<不正确寻址/>流错误条件，并终止XML流和与违规服务器的底层TCP连接。
If the value of the 'to' attribute is invalid or cannot be contacted, the entity discovering that fact (usually the sender's or recipient's server) MUST return an appropriate error to the sender, setting the 'from' attribute of the error stanza to the value provided in the 'to' attribute of the offending stanza.
如果“to”属性的值无效或无法联系，发现该事实的实体（通常是发件人或收件人的服务器）必须向发件人返回适当的错误，将错误节的“from”属性设置为有问题节的“to”属性中提供的值。
The 'from' attribute specifies the JID of the sender.
“from”属性指定发件人的JID。
When a server receives an XML stanza within the context of an authenticated stream qualified by the 'jabber:client' namespace, it MUST do one of the following:
当服务器在“jabber:client”命名空间限定的经过身份验证的流的上下文中接收到XML节时，它必须执行以下操作之一：
1. validate that the value of the 'from' attribute provided by the client is that of a connected resource for the associated entity
1. 验证客户端提供的“from”属性的值是否为关联实体的已连接资源的值
2. add a 'from' address to the stanza whose value is the bare JID (<node@domain>) or the full JID (<node@domain/resource>) determined by the server for the connected resource that generated the stanza (see Determination of Addresses (Section 3.5))
2. 将“发件人”地址添加到值为裸JID的节中(<node@domain>)还是全面的JID(<node@domain/资源>）由服务器为生成节的连接资源确定（请参阅地址确定（第3.5节））
If a client attempts to send an XML stanza for which the value of the 'from' attribute does not match one of the connected resources for that entity, the server SHOULD return an <invalid-from/> stream error to the client. If a client attempts to send an XML stanza over a stream that is not yet authenticated, the server SHOULD return a <not-authorized/> stream error to the client. If generated, both of these conditions MUST result in closure of the stream and termination of the underlying TCP connection; this helps to prevent a denial of service attack launched from a rogue client.
如果客户机试图发送一个XML节，“from”属性的值与该实体的一个已连接资源不匹配，则服务器应向客户机返回<invalid from/>流错误。如果客户机试图通过尚未经过身份验证的流发送XML节，服务器应向客户机返回<not authorized/>流错误。如果生成，这两个条件都必须导致流的关闭和底层TCP连接的终止；这有助于防止恶意客户端发起拒绝服务攻击。
When a server generates a stanza from the server itself for delivery to a connected client (e.g., in the context of data storage services provided by the server on behalf of the client), the stanza MUST either (1) not include a 'from' attribute or (2) include a 'from' attribute whose value is the account's bare JID (<node@domain>) or client's full JID (<node@domain/resource>). A server MUST NOT send to the client a stanza without a 'from' attribute if the stanza was not generated by the server itself. When a client receives a stanza that does not include a 'from' attribute, it MUST assume that the stanza is from the server to which the client is connected.
当服务器从服务器本身生成一个节以交付给连接的客户端（例如，在服务器代表客户端提供的数据存储服务的上下文中）时，该节必须（1）不包含“from”属性或（2）包含值为帐户的裸JID的“from”属性(<node@domain>)还是客户的全部JID(<node@domain/资源>）。如果节不是由服务器本身生成的，则服务器不得向客户端发送没有“from”属性的节。当客户端接收到不包含“from”属性的节时，它必须假定该节来自客户端所连接的服务器。
In the 'jabber:server' namespace, a stanza MUST possess a 'from' attribute; if a server receives a stanza that does not meet this restriction, it MUST generate an <improper-addressing/> stream error condition. Furthermore, the domain identifier portion of the JID
在'jabber:server'名称空间中，节必须具有'from'属性；如果服务器接收到不符合此限制的节，则必须生成<不正确寻址/>流错误条件。此外，JID的域标识符部分
contained in the 'from' attribute MUST match the hostname of the sending server (or any validated domain thereof, such as a validated subdomain of the sending server's hostname or another validated domain hosted by the sending server) as communicated in the SASL negotiation or dialback negotiation; if a server receives a stanza that does not meet this restriction, it MUST generate an <invalid-from/> stream error condition. Both of these conditions MUST result in closing of the stream and termination of the underlying TCP connection; this helps to prevent a denial of service attack launched from a rogue server.
“from”属性中包含的内容必须与SASL协商或回拨协商中传达的发送服务器的主机名（或其任何验证域，如发送服务器主机名的验证子域或发送服务器托管的另一验证域）相匹配；如果服务器收到不符合此限制的节，则必须生成<invalid from/>流错误条件。这两种情况都必须导致流关闭和底层TCP连接终止；这有助于防止从恶意服务器发起拒绝服务攻击。
The optional 'id' attribute MAY be used by a sending entity for internal tracking of stanzas that it sends and receives (especially for tracking the request-response interaction inherent in the semantics of IQ stanzas). It is OPTIONAL for the value of the 'id' attribute to be unique globally, within a domain, or within a stream. The semantics of IQ stanzas impose additional restrictions; see IQ Semantics (Section 9.2.3).
可选的“id”属性可由发送实体用于内部跟踪其发送和接收的节（特别是用于跟踪IQ节语义中固有的请求-响应交互）。“id”属性的值在域或流中全局唯一是可选的。IQ节的语义施加了额外的限制；参见IQ语义（第9.2.3节）。
The 'type' attribute specifies detailed information about the purpose or context of the message, presence, or IQ stanza. The particular allowable values for the 'type' attribute vary depending on whether the stanza is a message, presence, or IQ; the values for message and presence stanzas are specific to instant messaging and presence applications and therefore are defined in [XMPP-IM], whereas the values for IQ stanzas specify the role of an IQ stanza in a structured request-response "conversation" and thus are defined under IQ Semantics (Section 9.2.3) below. The only 'type' value common to all three stanzas is "error"; see Stanza Errors (Section 9.3).
“type”属性指定有关消息、状态或IQ节的目的或上下文的详细信息。“type”属性的特定允许值因节是消息、状态还是IQ而不同；消息和状态节的值特定于即时消息和状态应用程序，因此在[XMPP-IM]中定义，而IQ节的值指定了IQ节在结构化请求-响应“对话”中的角色，因此在下面的IQ语义（第9.2.3节）中定义。所有三个小节共有的唯一“type”值是“error”；见节错误（第9.3节）。
A stanza SHOULD possess an 'xml:lang' attribute (as defined in Section 2.12 of [XML]) if the stanza contains XML character data that is intended to be presented to a human user (as explained in RFC 2277 [CHARSET], "internationalization is for humans"). The value of the 'xml:lang' attribute specifies the default language of any such human-readable XML character data, which MAY be overridden by the 'xml:lang' attribute of a specific child element. If a stanza does not possess an 'xml:lang' attribute, an implementation MUST assume that the default language is that specified for the stream as defined under Stream Attributes (Section 4.4) above. The value of the 'xml:lang' attribute MUST be an NMTOKEN and MUST conform to the format defined in RFC 3066 [LANGTAGS].
如果节中包含要呈现给人类用户的xml字符数据（如RFC 2277[CHARSET]，“国际化是为人类的”），则节应具有“xml:lang”属性（如[xml]第2.12节所定义）。“xml:lang”属性的值指定任何此类人类可读xml字符数据的默认语言，该数据可能被特定子元素的“xml:lang”属性覆盖。如果节不具有“xml:lang”属性，则实现必须假定默认语言是为上述流属性（第4.4节）下定义的流指定的语言。“xml:lang”属性的值必须是NMTOKEN，并且必须符合RFC 3066[LANGTAGS]中定义的格式。
The <message/> stanza kind can be seen as a "push" mechanism whereby one entity pushes information to another entity, similar to the communications that occur in a system such as email. All message stanzas SHOULD possess a 'to' attribute that specifies the intended recipient of the message; upon receiving such a stanza, a server SHOULD route or deliver it to the intended recipient (see Server Rules for Handling XML Stanzas (Section 10) for general routing and delivery rules related to XML stanzas).
<message/>节类可以看作是一种“推送”机制，一个实体将信息推送到另一个实体，类似于电子邮件等系统中发生的通信。所有消息节都应具有“to”属性，指定消息的预期收件人；在接收到这样的节时，服务器应该将其路由或交付给预期的接收者（有关XML节的一般路由和交付规则，请参阅处理XML节的服务器规则（第10节））。
The <presence/> element can be seen as a basic broadcast or "publish-subscribe" mechanism, whereby multiple entities receive information about an entity to which they have subscribed (in this case, network availability information). In general, a publishing entity SHOULD send a presence stanza with no 'to' attribute, in which case the server to which the entity is connected SHOULD broadcast or multiplex that stanza to all subscribing entities. However, a publishing entity MAY also send a presence stanza with a 'to' attribute, in which case the server SHOULD route or deliver that stanza to the intended recipient. See Server Rules for Handling XML Stanzas (Section 10) for general routing and delivery rules related to XML stanzas, and [XMPP-IM] for presence-specific rules in the context of an instant messaging and presence application.
<presence/>元素可以看作是一种基本的广播或“发布-订阅”机制，其中多个实体接收有关其已订阅的实体的信息（在本例中为网络可用性信息）。通常，发布实体应该发送一个不带“to”属性的状态节，在这种情况下，该实体所连接的服务器应该将该节广播或多路传输到所有订阅实体。但是，发布实体也可以发送带有“to”属性的状态节，在这种情况下，服务器应该将该节路由或传递给预期的收件人。有关XML节的一般路由和传递规则，请参见处理XML节的服务器规则（第10节）；有关即时消息和状态应用程序上下文中的状态特定规则，请参见[XMPP-IM]。
Info/Query, or IQ, is a request-response mechanism, similar in some ways to [HTTP]. The semantics of IQ enable an entity to make a request of, and receive a response from, another entity. The data content of the request and response is defined by the namespace declaration of a direct child element of the IQ element, and the interaction is tracked by the requesting entity through use of the 'id' attribute. Thus, IQ interactions follow a common pattern of structured data exchange such as get/result or set/result (although an error may be returned in reply to a request if appropriate):
信息/查询，或IQ，是一种请求-响应机制，在某些方面类似于[HTTP]。IQ的语义使一个实体能够向另一个实体发出请求，并从另一个实体接收响应。请求和响应的数据内容由IQ元素的直接子元素的名称空间声明定义，请求实体通过使用“id”属性跟踪交互。因此，IQ交互遵循一种常见的结构化数据交换模式，如get/result或set/result（尽管在适当的情况下，响应请求时可能会返回错误）：
Requesting Responding
Entity Entity
---------- ----------
| |
| <iq type='get' id='1'> |
| ------------------------> |
| |
| <iq type='result' id='1'> |
| <------------------------ |
| |
| <iq type='set' id='2'> |
| ------------------------> |
| |
| <iq type='error' id='2'> |
| <------------------------ |
| |
Requesting Responding
Entity Entity
---------- ----------
| |
| <iq type='get' id='1'> |
| ------------------------> |
| |
| <iq type='result' id='1'> |
| <------------------------ |
| |
| <iq type='set' id='2'> |
| ------------------------> |
| |
| <iq type='error' id='2'> |
| <------------------------ |
| |
In order to enforce these semantics, the following rules apply:
为了实施这些语义，以下规则适用：
1. The 'id' attribute is REQUIRED for IQ stanzas.
1. IQ节需要“id”属性。
2. The 'type' attribute is REQUIRED for IQ stanzas. The value MUST be one of the following:
2. IQ节需要“type”属性。该值必须是以下值之一：
* get -- The stanza is a request for information or requirements.
* get——这一节是对信息或需求的请求。
* set -- The stanza provides required data, sets new values, or replaces existing values.
* set——该节提供所需数据、设置新值或替换现有值。
* result -- The stanza is a response to a successful get or set request.
* 结果——该节是对成功的get或set请求的响应。
* error -- An error has occurred regarding processing or delivery of a previously-sent get or set (see Stanza Errors (Section 9.3)).
* 错误——在处理或传递以前发送的get或set时发生错误（请参阅节错误（第9.3节））。
3. An entity that receives an IQ request of type "get" or "set" MUST reply with an IQ response of type "result" or "error" (the response MUST preserve the 'id' attribute of the request).
3. 接收类型为“get”或“set”的IQ请求的实体必须使用类型为“result”或“error”的IQ响应进行回复（响应必须保留请求的“id”属性）。
4. An entity that receives a stanza of type "result" or "error" MUST NOT respond to the stanza by sending a further IQ response of type "result" or "error"; however, as shown above, the requesting entity MAY send another request (e.g., an IQ of type "set" in order to provide required information discovered through a get/result pair).
4. 接收“结果”或“错误”类型节的实体不得通过发送“结果”或“错误”类型的进一步IQ响应来响应该节；然而，如上所示，请求实体可以发送另一个请求（例如，“set”类型的IQ，以便提供通过get/result对发现的所需信息）。
5. An IQ stanza of type "get" or "set" MUST contain one and only one child element that specifies the semantics of the particular request or response.
5. “get”或“set”类型的IQ节必须包含一个且仅包含一个子元素，该子元素指定特定请求或响应的语义。
6. An IQ stanza of type "result" MUST include zero or one child elements.
6. “结果”类型的IQ节必须包含零或一个子元素。
7. An IQ stanza of type "error" SHOULD include the child element contained in the associated "get" or "set" and MUST include an <error/> child; for details, see Stanza Errors (Section 9.3).
7. 类型为“error”的IQ节应包含相关“get”或“set”中包含的子元素，并且必须包含<error/>子元素；有关详细信息，请参见节错误（第9.3节）。
Stanza-related errors are handled in a manner similar to stream errors (Section 4.7). However, unlike stream errors, stanza errors are recoverable; therefore error stanzas include hints regarding actions that the original sender can take in order to remedy the error.
节相关错误的处理方式类似于流错误（第4.7节）。但是，与流错误不同，节错误是可恢复的；因此，错误节包括关于原始发送者可以采取的纠正错误的操作的提示。
The following rules apply to stanza-related errors:
以下规则适用于节相关错误：
o The receiving or processing entity that detects an error condition in relation to a stanza MUST return to the sending entity a stanza of the same kind (message, presence, or IQ), whose 'type' attribute is set to a value of "error" (such a stanza is called an "error stanza" herein).
o 检测到与节相关的错误条件的接收或处理实体必须向发送实体返回相同类型的节（消息、存在或IQ），其“类型”属性设置为“错误”值（这种节在本文中称为“错误节”）。
o The entity that generates an error stanza SHOULD include the original XML sent so that the sender can inspect and, if necessary, correct the XML before attempting to resend.
o 生成错误节的实体应包括发送的原始XML，以便发送方可以在尝试重新发送之前检查并纠正XML（如有必要）。
o An error stanza MUST contain an <error/> child element.
o 错误节必须包含<error/>子元素。
o An <error/> child MUST NOT be included if the 'type' attribute has a value other than "error" (or if there is no 'type' attribute).
o 如果“type”属性的值不是“error”（或者如果没有“type”属性），则不能包含<error/>子级。
o An entity that receives an error stanza MUST NOT respond to the stanza with a further error stanza; this helps to prevent looping.
o 接收错误节的实体不得使用进一步的错误节响应该节；这有助于防止循环。
The syntax for stanza-related errors is as follows:
节相关错误的语法如下所示：
<stanza-kind to='sender' type='error'>
[RECOMMENDED to include sender XML here]
<error type='error-type'>
<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
xml:lang='langcode'>
OPTIONAL descriptive text
</text>
[OPTIONAL application-specific condition element]
</error>
</stanza-kind>
<stanza-kind to='sender' type='error'>
[RECOMMENDED to include sender XML here]
<error type='error-type'>
<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
xml:lang='langcode'>
OPTIONAL descriptive text
</text>
[OPTIONAL application-specific condition element]
</error>
</stanza-kind>
The stanza-kind is one of message, presence, or iq.
节类是信息、存在或智商的一种。
The value of the <error/> element's 'type' attribute MUST be one of the following:
<error/>元素的“type”属性的值必须是以下值之一：
o cancel -- do not retry (the error is unrecoverable) o continue -- proceed (the condition was only a warning) o modify -- retry after changing the data sent o auth -- retry after providing credentials o wait -- retry after waiting (the error is temporary)
o 取消--不要重试（错误不可恢复）o继续--继续（条件只是警告）o修改--更改发送的数据后重试o身份验证--提供凭据后重试o等待--等待后重试（错误是暂时的）
The <error/> element:
<error/>元素：
o MUST contain a child element corresponding to one of the defined stanza error conditions specified below; this element MUST be qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace.
o 必须包含与以下指定的已定义节错误条件之一对应的子元素；此元素必须由“urn:ietf:params:xml:ns:xmpp节”命名空间限定。
o MAY contain a <text/> child containing XML character data that describes the error in more detail; this element MUST be qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace and SHOULD possess an 'xml:lang' attribute.
o 可能包含一个子元素，该子元素包含更详细地描述错误的XML字符数据；此元素必须由“urn:ietf:params:xml:ns:xmpp节”命名空间限定，并应具有“xml:lang”属性。
o MAY contain a child element for an application-specific error condition; this element MUST be qualified by an application-defined namespace, and its structure is defined by that namespace.
o 可能包含应用程序特定错误条件的子元素；此元素必须由应用程序定义的命名空间限定，其结构由该命名空间定义。
The <text/> element is OPTIONAL. If included, it SHOULD be used only to provide descriptive or diagnostic information that supplements the meaning of a defined condition or application-specific condition. It SHOULD NOT be interpreted programmatically by an application. It
<text/>元素是可选的。如果包括，则应仅用于提供补充定义条件或特定应用条件含义的描述性或诊断信息。应用程序不应以编程方式解释它。信息技术
SHOULD NOT be used as the error message presented to a user, but MAY be shown in addition to the error message associated with the included condition element (or elements).
不应用作向用户显示的错误消息，但可在与包含的条件元素相关联的错误消息之外显示。
Finally, to maintain backward compatibility, the schema (specified in [XMPP-IM]) allows the optional inclusion of a 'code' attribute on the <error/> element.
最后，为了保持向后兼容性，模式（在[XMPP-IM]中指定）允许在<error/>元素上可选地包含“code”属性。
The following conditions are defined for use in stanza errors.
以下条件定义用于节错误。
o <bad-request/> -- the sender has sent XML that is malformed or that cannot be processed (e.g., an IQ stanza that includes an unrecognized value of the 'type' attribute); the associated error type SHOULD be "modify".
o <bad request/>——发送方发送的XML格式不正确或无法处理（例如，包含“type”属性的无法识别值的IQ节）；关联的错误类型应为“修改”。
o <conflict/> -- access cannot be granted because an existing resource or session exists with the same name or address; the associated error type SHOULD be "cancel".
o <conflict/>--无法授予访问权限，因为存在同名或地址的现有资源或会话；关联的错误类型应为“取消”。
o <feature-not-implemented/> -- the feature requested is not implemented by the recipient or server and therefore cannot be processed; the associated error type SHOULD be "cancel".
o <feature not implemented/>——请求的功能未由收件人或服务器实现，因此无法处理；关联的错误类型应为“取消”。
o <forbidden/> -- the requesting entity does not possess the required permissions to perform the action; the associated error type SHOULD be "auth".
o <forbidden/>——请求实体不具备执行该操作所需的权限；关联的错误类型应为“auth”。
o <gone/> -- the recipient or server can no longer be contacted at this address (the error stanza MAY contain a new address in the XML character data of the <gone/> element); the associated error type SHOULD be "modify".
o <Goe/>--无法再通过此地址联系收件人或服务器（错误节可能在<Goe/>元素的XML字符数据中包含新地址）；关联的错误类型应为“修改”。
o <internal-server-error/> -- the server could not process the stanza because of a misconfiguration or an otherwise-undefined internal server error; the associated error type SHOULD be "wait".
o <internal server error/>--由于配置错误或未定义的内部服务器错误，服务器无法处理节；关联的错误类型应为“等待”。
o <item-not-found/> -- the addressed JID or item requested cannot be found; the associated error type SHOULD be "cancel".
o <item not found/>——无法找到已寻址的JID或请求的项；关联的错误类型应为“取消”。
o <jid-malformed/> -- the sending entity has provided or communicated an XMPP address (e.g., a value of the 'to' attribute) or aspect thereof (e.g., a resource identifier) that does not adhere to the syntax defined in Addressing Scheme (Section 3); the associated error type SHOULD be "modify".
o <jid-malformed/>——发送实体提供或传递的XMPP地址（例如，to属性的值）或其方面（例如，资源标识符）不符合寻址方案（第3节）中定义的语法；关联的错误类型应为“修改”。
o <not-acceptable/> -- the recipient or server understands the request but is refusing to process it because it does not meet criteria defined by the recipient or server (e.g., a local policy regarding acceptable words in messages); the associated error type SHOULD be "modify".
o <not acceptable/>——收件人或服务器理解请求，但拒绝处理请求，因为它不符合收件人或服务器定义的标准（例如，关于消息中可接受单词的本地策略）；关联的错误类型应为“修改”。
o <not-allowed/> -- the recipient or server does not allow any entity to perform the action; the associated error type SHOULD be "cancel".
o <not allowed/>——收件人或服务器不允许任何实体执行该操作；关联的错误类型应为“取消”。
o <not-authorized/> -- the sender must provide proper credentials before being allowed to perform the action, or has provided improper credentials; the associated error type SHOULD be "auth".
o <not authorized/>发送方必须在被允许执行操作之前提供正确的凭据，或者提供了不正确的凭据；关联的错误类型应为“auth”。
o <payment-required/> -- the requesting entity is not authorized to access the requested service because payment is required; the associated error type SHOULD be "auth".
o <payment required/>——由于需要付款，请求实体无权访问请求的服务；关联的错误类型应为“auth”。
o <recipient-unavailable/> -- the intended recipient is temporarily unavailable; the associated error type SHOULD be "wait" (note: an application MUST NOT return this error if doing so would provide information about the intended recipient's network availability to an entity that is not authorized to know such information).
o <recipient unavailable/>——目标收件人暂时不可用；关联的错误类型应为“等待”（注意：如果这样做会向未被授权了解此类信息的实体提供有关预期收件人网络可用性的信息，则应用程序不得返回此错误）。
o <redirect/> -- the recipient or server is redirecting requests for this information to another entity, usually temporarily (the error stanza SHOULD contain the alternate address, which MUST be a valid JID, in the XML character data of the <redirect/> element); the associated error type SHOULD be "modify".
o <redirect/>——收件人或服务器正在将此信息的请求重定向到另一个实体，通常是暂时的（错误节应包含<redirect/>元素的XML字符数据中的备用地址，该地址必须是有效的JID）；关联的错误类型应为“修改”。
o <registration-required/> -- the requesting entity is not authorized to access the requested service because registration is required; the associated error type SHOULD be "auth".
o <registration required/>——由于需要注册，请求实体无权访问请求的服务；关联的错误类型应为“auth”。
o <remote-server-not-found/> -- a remote server or service specified as part or all of the JID of the intended recipient does not exist; the associated error type SHOULD be "cancel".
o <remote server not found/>——指定为预期收件人JID的一部分或全部的远程服务器或服务不存在；关联的错误类型应为“取消”。
o <remote-server-timeout/> -- a remote server or service specified as part or all of the JID of the intended recipient (or required to fulfill a request) could not be contacted within a reasonable amount of time; the associated error type SHOULD be "wait".
o <remote server timeout/>——指定为预期收件人JID的一部分或全部（或完成请求所需的）的远程服务器或服务无法在合理的时间内联系到；关联的错误类型应为“等待”。
o <resource-constraint/> -- the server or recipient lacks the system resources necessary to service the request; the associated error type SHOULD be "wait".
o <resource constraint/>——服务器或收件人缺少服务请求所需的系统资源；关联的错误类型应为“等待”。
o <service-unavailable/> -- the server or recipient does not currently provide the requested service; the associated error type SHOULD be "cancel".
o <service unavailable/>--服务器或收件人当前未提供请求的服务；关联的错误类型应为“取消”。
o <subscription-required/> -- the requesting entity is not authorized to access the requested service because a subscription is required; the associated error type SHOULD be "auth".
o <subscription required/>——由于需要订阅，请求实体无权访问请求的服务；关联的错误类型应为“auth”。
o <undefined-condition/> -- the error condition is not one of those defined by the other conditions in this list; any error type may be associated with this condition, and it SHOULD be used only in conjunction with an application-specific condition.
o <undefined condition/>——错误条件不是此列表中其他条件定义的条件之一；任何错误类型都可能与此条件关联，并且只能与特定于应用程序的条件结合使用。
o <unexpected-request/> -- the recipient or server understood the request but was not expecting it at this time (e.g., the request was out of order); the associated error type SHOULD be "wait".
o <unexpected request/>——收件人或服务器理解该请求，但此时不希望收到该请求（例如，该请求出现故障）；关联的错误类型应为“等待”。
As noted, an application MAY provide application-specific stanza error information by including a properly-namespaced child in the error element. The application-specific element SHOULD supplement or further qualify a defined element. Thus, the <error/> element will contain two or three child elements:
如前所述，应用程序可以通过在error元素中包含正确命名的子元素来提供特定于应用程序的节错误信息。特定于应用程序的元素应补充或进一步限定已定义的元素。因此，<error/>元素将包含两个或三个子元素：
<iq type='error' id='some-id'>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<too-many-parameters xmlns='application-ns'/>
</error>
</iq>
<iq type='error' id='some-id'>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<too-many-parameters xmlns='application-ns'/>
</error>
</iq>
<message type='error' id='another-id'>
<error type='modify'>
<undefined-condition
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xml:lang='en'
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
Some special application diagnostic information...
</text>
<special-application-condition xmlns='application-ns'/>
</error>
</message>
<message type='error' id='another-id'>
<error type='modify'>
<undefined-condition
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xml:lang='en'
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
Some special application diagnostic information...
</text>
<special-application-condition xmlns='application-ns'/>
</error>
</message>
Compliant server implementations MUST ensure in-order processing of XML stanzas between any two entities.
兼容的服务器实现必须确保在任意两个实体之间按顺序处理XML节。
Beyond the requirement for in-order processing, each server implementation will contain its own "delivery tree" for handling stanzas it receives. Such a tree determines whether a stanza needs to be routed to another domain, processed internally, or delivered to a resource associated with a connected node. The following rules apply:
除了订单处理的要求外，每个服务器实现都将包含自己的“交付树”，用于处理接收到的节。这样的树决定了一个节是否需要路由到另一个域、在内部进行处理或传递到与连接节点关联的资源。以下规则适用：
If the stanza possesses no 'to' attribute, the server SHOULD process it on behalf of the entity that sent it. Because all stanzas received from other servers MUST possess a 'to' attribute, this rule applies only to stanzas received from a registered entity (such as a client) that is connected to the server. If the server receives a presence stanza with no 'to' attribute, the server SHOULD broadcast it to the entities that are subscribed to the sending entity's presence, if applicable (the semantics of presence broadcast for instant messaging and presence applications are defined in [XMPP-IM]). If the server receives an IQ stanza of type "get" or "set" with no 'to' attribute and it understands the namespace that qualifies the content of the stanza, it MUST either process the stanza on behalf of the sending entity (where the meaning of "process" is determined by the semantics of the qualifying namespace) or return an error to the sending entity.
如果节不具有“to”属性，则服务器应代表发送该节的实体处理该节。由于从其他服务器接收的所有节都必须具有“to”属性，因此此规则仅适用于从连接到服务器的注册实体（如客户端）接收的节。如果服务器接收到不带“to”属性的状态节，则服务器应将其广播给订阅发送实体状态的实体（如果适用）（即时消息和状态应用程序的状态广播语义在[XMPP-IM]中定义）。如果服务器接收到类型为“get”或“set”且没有“to”属性的IQ节，并且它了解限定节内容的名称空间，则它必须代表发送实体处理节（其中“process”的含义由限定名称空间的语义确定）或将错误返回给发送实体。
If the hostname of the domain identifier portion of the JID contained in the 'to' attribute does not match one of the configured hostnames of the server itself or a subdomain thereof, the server SHOULD route the stanza to the foreign domain (subject to local service provisioning and security policies regarding inter-domain communication). There are two possible cases:
如果“to”属性中包含的JID的域标识符部分的主机名与服务器本身或其子域的一个配置主机名不匹配，服务器应将节路由到外域（取决于本地服务提供和域间通信的安全策略）。有两种可能的情况：
A server-to-server stream already exists between the two domains: The sender's server routes the stanza to the authoritative server for the foreign domain over the existing stream
两个域之间已经存在服务器到服务器的流：发送方的服务器通过现有流将节路由到外部域的权威服务器
There exists no server-to-server stream between the two domains: The sender's server (1) resolves the hostname of the foreign domain (as defined under Server-to-Server Communications (Section 14.4)), (2) negotiates a server-to-server stream between the two domains (as defined under Use of TLS (Section 5) and Use of SASL (Section
两个域之间不存在服务器到服务器的流：发送方服务器（1）解析外域的主机名（定义见服务器到服务器通信（第14.4节）），（2）在两个域之间协商服务器到服务器的流（定义见使用TLS（第5节）和使用SASL（第5节）
6)), and (3) routes the stanza to the authoritative server for the foreign domain over the newly-established stream
6） ），和（3）通过新建立的流将节路由到外部域的权威服务器
If routing to the recipient's server is unsuccessful, the sender's server MUST return an error to the sender; if the recipient's server can be contacted but delivery by the recipient's server to the recipient is unsuccessful, the recipient's server MUST return an error to the sender by way of the sender's server.
如果到收件人服务器的路由不成功，则发件人服务器必须向发件人返回错误；如果可以联系收件人的服务器，但收件人的服务器向收件人的传递不成功，则收件人的服务器必须通过发件人的服务器向发件人返回错误。
If the hostname of the domain identifier portion of the JID contained in the 'to' attribute matches a subdomain of one of the configured hostnames of the server itself, the server MUST either process the stanza itself or route the stanza to a specialized service that is responsible for that subdomain (if the subdomain is configured), or return an error to the sender (if the subdomain is not configured).
如果“to”属性中包含的JID的域标识符部分的主机名与服务器本身配置的主机名之一的子域相匹配，则服务器必须处理节本身或将节路由到负责该子域的专用服务（如果子域已配置），或者将错误返回给发件人（如果未配置子域）。
If the hostname of the domain identifier portion of the JID contained in the 'to' attribute matches a configured hostname of the server itself and the JID contained in the 'to' attribute is of the form <domain> or <domain/resource>, the server (or a defined resource thereof) MUST either process the stanza as appropriate for the stanza kind or return an error stanza to the sender.
如果“to”属性中包含的JID的域标识符部分的主机名与服务器本身的配置主机名匹配，并且“to”属性中包含的JID的形式为<domain>或<domain/resource>，则服务器（或其定义的资源）必须根据节类型处理节，或者将错误节返回给发送方。
If the hostname of the domain identifier portion of the JID contained in the 'to' attribute matches a configured hostname of the server itself and the JID contained in the 'to' attribute is of the form <node@domain> or <node@domain/resource>, the server SHOULD deliver the stanza to the intended recipient of the stanza as represented by the JID contained in the 'to' attribute. The following rules apply:
如果“to”属性中包含的JID的域标识符部分的主机名与服务器本身的配置主机名匹配，并且“to”属性中包含的JID的形式为<node@domain>或<node@domain/资源>,，服务器应将节传递给节的预期收件人，如“to”属性中包含的JID所表示的。以下规则适用：
1. If the JID contains a resource identifier (i.e., is of the form <node@domain/resource>) and there exists a connected resource that matches the full JID, the recipient's server SHOULD deliver the stanza to the stream or session that exactly matches the resource identifier.
1. 如果JID包含一个资源标识符（即<node@domain/如果存在与完整JID匹配的已连接资源，则接收方的服务器应将节传递到与资源标识符完全匹配的流或会话。
2. If the JID contains a resource identifier and there exists no connected resource that matches the full JID, the recipient's server SHOULD return a <service-unavailable/> stanza error to the sender.
2. 如果JID包含资源标识符，并且不存在与完整JID匹配的已连接资源，则收件人的服务器应向发件人返回<service unavailable/>节错误。
3. If the JID is of the form <node@domain> and there exists at least one connected resource for the node, the recipient's server SHOULD deliver the stanza to at least one of the connected resources, according to application-specific rules (a set of delivery rules for instant messaging and presence applications is defined in [XMPP-IM]).
3. 如果JID的形式是<node@domain>并且节点至少存在一个连接的资源，接收方的服务器应根据特定于应用程序的规则（即时消息和状态应用程序的一组传递规则在[XMPP-IM]中定义）将节传递给至少一个连接的资源。
XMPP is a simplified and specialized protocol for streaming XML elements in order to exchange structured information in close to real time. Because XMPP does not require the parsing of arbitrary and complete XML documents, there is no requirement that XMPP needs to support the full feature set of [XML]. In particular, the following restrictions apply.
XMPP是一种简化的专门协议，用于流式传输XML元素，以便接近实时地交换结构化信息。因为XMPP不需要解析任意完整的XML文档，所以XMPP不需要支持[XML]的完整特性集。特别是，以下限制适用。
With regard to XML generation, an XMPP implementation MUST NOT inject into an XML stream any of the following:
关于XML生成，XMPP实现不得向XML流中注入以下任何内容：
o comments (as defined in Section 2.5 of [XML])
o 注释（定义见[XML]第2.5节）
o processing instructions (Section 2.6 therein)
o 处理说明（其中第2.6节）
o internal or external DTD subsets (Section 2.8 therein)
o 内部或外部DTD子集（其中第2.8节）
o internal or external entity references (Section 4.2 therein) with the exception of predefined entities (Section 4.6 therein)
o 内部或外部实体参考（其中第4.2节），预定义实体除外（其中第4.6节）
o character data or attribute values containing unescaped characters that map to the predefined entities (Section 4.6 therein); such characters MUST be escaped
o 包含映射到预定义实体的未缩放字符的字符数据或属性值（其中第4.6节）；这些字符必须转义
With regard to XML processing, if an XMPP implementation receives such restricted XML data, it MUST ignore the data.
关于XML处理，如果XMPP实现接收到这样的受限XML数据，它必须忽略这些数据。
XML Namespaces [XML-NAMES] are used within all XMPP-compliant XML to create strict boundaries of data ownership. The basic function of namespaces is to separate different vocabularies of XML elements that are structurally mixed together. Ensuring that XMPP-compliant XML is namespace-aware enables any allowable XML to be structurally mixed with any data element within XMPP. Rules for XML namespace names and prefixes are defined in the following subsections.
XML名称空间[XML-NAMES]用于所有符合XMPP的XML中，以创建严格的数据所有权边界。名称空间的基本功能是分离在结构上混合在一起的XML元素的不同词汇表。确保与XMPP兼容的XML具有名称空间意识，使得任何允许的XML都能够在结构上与XMPP中的任何数据元素混合。XML命名空间名称和前缀的规则在以下小节中定义。
A streams namespace declaration is REQUIRED in all XML stream headers. The name of the streams namespace MUST be 'http://etherx.jabber.org/streams'. The element names of the <stream/> element and its <features/> and <error/> children MUST be qualified by the streams namespace prefix in all instances. An implementation SHOULD generate only the 'stream:' prefix for these elements, and for historical reasons MAY accept only the 'stream:' prefix.
在所有XML流头中都需要streams命名空间声明。streams命名空间的名称必须为'http://etherx.jabber.org/streams'. 在所有实例中，<stream/>元素及其<features/>和<error/>子元素的元素名必须由streams名称空间前缀限定。实现应该只为这些元素生成“stream:”前缀，并且出于历史原因，可能只接受“stream:”前缀。
A default namespace declaration is REQUIRED and is used in all XML streams in order to define the allowable first-level children of the root stream element. This namespace declaration MUST be the same for the initial stream and the response stream so that both streams are qualified consistently. The default namespace declaration applies to the stream and all stanzas sent within a stream (unless explicitly qualified by another namespace, or by the prefix of the streams namespace or the dialback namespace).
为了定义根流元素允许的第一级子元素，需要在所有XML流中使用默认名称空间声明。对于初始流和响应流，此命名空间声明必须相同，以便两个流的限定一致。默认名称空间声明适用于流和在流中发送的所有节（除非由另一个名称空间或流名称空间或回拨名称空间的前缀显式限定）。
A server implementation MUST support the following two default namespaces (for historical reasons, some implementations MAY support only these two default namespaces):
服务器实现必须支持以下两个默认名称空间（出于历史原因，某些实现可能仅支持这两个默认名称空间）：
o jabber:client -- this default namespace is declared when the stream is used for communications between a client and a server
o jabber:client——当流用于客户端和服务器之间的通信时，会声明此默认命名空间
o jabber:server -- this default namespace is declared when the stream is used for communications between two servers
o jabber:server——当流用于两台服务器之间的通信时，会声明此默认名称空间
A client implementation MUST support the 'jabber:client' default namespace, and for historical reasons MAY support only that default namespace.
客户端实现必须支持“jabber:client”默认名称空间，并且出于历史原因，可能仅支持该默认名称空间。
An implementation MUST NOT generate namespace prefixes for elements in the default namespace if the default namespace is 'jabber:client' or 'jabber:server'. An implementation SHOULD NOT generate namespace prefixes for elements qualified by content (as opposed to stream) namespaces other than 'jabber:client' and 'jabber:server'.
如果默认命名空间为“jabber:client”或“jabber:server”，则实现不得为默认命名空间中的元素生成命名空间前缀。实现不应为除“jabber:client”和“jabber:server”之外的内容（与流相反）命名空间限定的元素生成命名空间前缀。
Note: The 'jabber:client' and 'jabber:server' namespaces are nearly identical but are used in different contexts (client-to-server communications for 'jabber:client' and server-to-server communications for 'jabber:server'). The only difference between the two is that the 'to' and 'from' attributes are OPTIONAL on stanzas sent within 'jabber:client', whereas they are REQUIRED on stanzas
注意：'jabber:client'和'jabber:server'名称空间几乎相同，但在不同的上下文中使用（“jabber:client”的客户端到服务器通信和“jabber:server”的服务器到服务器通信）。这两者之间的唯一区别是，“to”和“from”属性在“jabber:client”中发送的节上是可选的，而在节上是必需的
sent within 'jabber:server'. If a compliant implementation accepts a stream that is qualified by the 'jabber:client' or 'jabber:server' namespace, it MUST support the common attributes (Section 9.1) and basic semantics (Section 9.2) of all three core stanza kinds (message, presence, and IQ).
在“jabber:server”内发送。如果兼容实现接受由“jabber:client”或“jabber:server”命名空间限定的流，则它必须支持所有三种核心节类型（消息、状态和IQ）的公共属性（第9.1节）和基本语义（第9.2节）。
A dialback namespace declaration is REQUIRED for all elements used in server dialback (Section 8). The name of the dialback namespace MUST be 'jabber:server:dialback'. All elements qualified by this namespace MUST be prefixed. An implementation SHOULD generate only the 'db:' prefix for such elements and MAY accept only the 'db:' prefix.
服务器回拨中使用的所有元素都需要回拨名称空间声明（第8节）。拨回命名空间的名称必须为“jabber:server:dialback”。此命名空间限定的所有元素都必须加前缀。实现应该只为这些元素生成'db:'前缀，并且可以只接受'db:'前缀。
Except as noted with regard to 'to' and 'from' addresses for stanzas within the 'jabber:server' namespace, a server is not responsible for validating the XML elements forwarded to a client or another server; an implementation MAY choose to provide only validated data elements but this is OPTIONAL (although an implementation MUST NOT accept XML that is not well-formed). Clients SHOULD NOT rely on the ability to send data which does not conform to the schemas, and SHOULD ignore any non-conformant elements or attributes on the incoming XML stream. Validation of XML streams and stanzas is OPTIONAL, and schemas are included herein for descriptive purposes only.
除“jabber:server”命名空间中节的“to”和“from”地址外，服务器不负责验证转发到客户端或其他服务器的XML元素；实现可以选择只提供经过验证的数据元素，但这是可选的（尽管实现不能接受格式不正确的XML）。客户机不应该依赖于发送不符合模式的数据的能力，而应该忽略传入XML流上的任何不一致的元素或属性。XML流和节的验证是可选的，本文包含的模式仅用于描述目的。
Implementations SHOULD send a text declaration before sending a stream header. Applications MUST follow the rules in [XML] regarding the circumstances under which a text declaration is included.
实现应该在发送流头之前发送文本声明。应用程序必须遵循[XML]中关于包含文本声明的情况的规则。
Implementations MUST support the UTF-8 (RFC 3629 [UTF-8]) transformation of Universal Character Set (ISO/IEC 10646-1 [UCS2]) characters, as required by RFC 2277 [CHARSET]. Implementations MUST NOT attempt to use any other encoding.
实现必须支持通用字符集（ISO/IEC 10646-1[UCS2]）字符的UTF-8（RFC 3629[UTF-8]）转换，如RFC 2277[CHARSET]所要求。实现不得尝试使用任何其他编码。
This section summarizes the specific aspects of the Extensible Messaging and Presence Protocol that MUST be supported by servers and clients in order to be considered compliant implementations, as well as additional protocol aspects that SHOULD be supported. For compliance purposes, we draw a distinction between core protocols
本节总结了服务器和客户端必须支持的可扩展消息和状态协议的特定方面，以被视为兼容的实现，以及应支持的其他协议方面。出于法规遵从性目的，我们对核心协议进行了区分
(which MUST be supported by any server or client, regardless of the specific application) and instant messaging protocols (which MUST be supported only by instant messaging and presence applications built on top of the core protocols). Compliance requirements that apply to all servers and clients are specified in this section; compliance requirements for instant messaging servers and clients are specified in the corresponding section of [XMPP-IM].
（必须由任何服务器或客户端支持，无论具体应用程序如何）和即时消息协议（必须仅由构建在核心协议之上的即时消息和状态应用程序支持）。本节规定了适用于所有服务器和客户端的合规性要求；[XMPP-IM]的相应章节中规定了即时消息服务器和客户端的法规遵从性要求。
In addition to all defined requirements with regard to security, XML usage, and internationalization, a server MUST support the following core protocols in order to be considered compliant:
除了与安全性、XML使用和国际化相关的所有已定义要求外，服务器必须支持以下核心协议才能被视为符合要求：
o Application of the [NAMEPREP], Nodeprep (Appendix A), and Resourceprep (Appendix B) profiles of [STRINGPREP] to addresses (including ensuring that domain identifiers are internationalized domain names as defined in [IDNA])
o 将[STRINGPREP]的[NAMEPREP]、Nodeprep（附录A）和Resourceprep（附录B）配置文件应用于地址（包括确保域标识符是[IDNA]中定义的国际化域名）
o XML streams (Section 4), including Use of TLS (Section 5), Use of SASL (Section 6), and Resource Binding (Section 7)
o XML流（第4节），包括TLS的使用（第5节）、SASL的使用（第6节）和资源绑定（第7节）
o The basic semantics of the three defined stanza kinds (i.e., <message/>, <presence/>, and <iq/>) as specified in stanza semantics (Section 9.2)
o 节语义（第9.2节）中规定的三种定义节类型（即<message/>、<presence/>和<iq/>）的基本语义
o Generation (and, where appropriate, handling) of error syntax and semantics related to streams, TLS, SASL, and XML stanzas
o 生成（并在适当情况下处理）与流、TLS、SASL和XML节相关的错误语法和语义
In addition, a server MAY support the following core protocol:
此外，服务器可支持以下核心协议：
o Server dialback (Section 8)
o 服务器回拨（第8节）
A client MUST support the following core protocols in order to be considered compliant:
客户端必须支持以下核心协议才能被视为符合要求：
o XML streams (Section 4), including Use of TLS (Section 5), Use of SASL (Section 6), and Resource Binding (Section 7)
o XML流（第4节），包括TLS的使用（第5节）、SASL的使用（第6节）和资源绑定（第7节）
o The basic semantics of the three defined stanza kinds (i.e., <message/>, <presence/>, and <iq/>) as specified in stanza semantics (Section 9.2)
o 节语义（第9.2节）中规定的三种定义节类型（即<message/>、<presence/>和<iq/>）的基本语义
o Handling (and, where appropriate, generation) of error syntax and semantics related to streams, TLS, SASL, and XML stanzas
o 处理（并在适当情况下生成）与流、TLS、SASL和XML节相关的错误语法和语义
In addition, a client SHOULD support the following core protocols:
此外，客户端应支持以下核心协议：
o Generation of addresses to which the [NAMEPREP], Nodeprep (Appendix A), and Resourceprep (Appendix B) profiles of [STRINGPREP] can be applied without failing
o 生成可应用[STRINGPREP]的[NAMEPREP]、Nodeprep（附录A）和Resourceprep（附录B）配置文件而不会失败的地址
XML streams MUST be encoded in UTF-8 as specified under Character Encoding (Section 11.5). As specified under Stream Attributes (Section 4.4), an XML stream SHOULD include an 'xml:lang' attribute that is treated as the default language for any XML character data sent over the stream that is intended to be presented to a human user. As specified under xml:lang (Section 9.1.5), an XML stanza SHOULD include an 'xml:lang' attribute if the stanza contains XML character data that is intended to be presented to a human user. A server SHOULD apply the default 'xml:lang' attribute to stanzas it routes or delivers on behalf of connected entities, and MUST NOT modify or delete 'xml:lang' attributes from stanzas it receives from other entities.
XML流必须按照字符编码（第11.5节）中的规定以UTF-8编码。如流属性（第4.4节）中所述，XML流应包含“XML:lang”属性，该属性被视为通过流发送的任何XML字符数据的默认语言，该数据将呈现给人类用户。如xml:lang（第9.1.5节）所述，如果xml节包含要呈现给人类用户的xml字符数据，则xml节应包含“xml:lang”属性。服务器应将默认的“xml:lang”属性应用于代表连接实体路由或传递的节，并且不得修改或删除从其他实体接收的节中的“xml:lang”属性。
For the purposes of XMPP communications (client-to-server and server-to-server), the term "high security" refers to the use of security technologies that provide both mutual authentication and integrity-checking; in particular, when using certificate-based authentication to provide high security, a chain-of-trust SHOULD be established out-of-band, although a shared certificate authority signing certificates could allow a previously unknown certificate to establish trust in-band. See Section 14.2 below regarding certificate validation procedures.
对于XMPP通信（客户端到服务器和服务器到服务器），术语“高安全性”是指使用同时提供相互认证和完整性检查的安全技术；特别是，当使用基于证书的身份验证来提供高安全性时，应该在带外建立信任链，尽管共享证书颁发机构签署证书可以允许以前未知的证书在带内建立信任。关于证书验证程序，见下文第14.2节。
Implementations MUST support high security. Service provisioning SHOULD use high security, subject to local security policies.
实现必须支持高安全性。服务供应应使用高安全性，并遵守本地安全策略。
When an XMPP peer communicates with another peer securely, it MUST validate the peer's certificate. There are three possible cases:
当XMPP对等机与另一对等机安全通信时，它必须验证对等机的证书。有三种可能的情况：
Case #1: The peer contains an End Entity certificate which appears to be certified by a chain of certificates terminating in a trust anchor (as described in Section 6.1 of [X509]).
案例#1：对等方包含最终实体证书，该证书似乎由终止于信任锚点的证书链认证（如[X509]第6.1节所述）。
Case #2: The peer certificate is certified by a Certificate Authority not known to the validating peer.
案例2：对等方证书由验证对等方不知道的证书颁发机构认证。
Case #3: The peer certificate is self-signed.
案例3：对等证书是自签名的。
In Case #1, the validating peer MUST do one of two things:
在情况#1中，验证对等方必须执行以下两项操作之一：
1. Verify the peer certificate according to the rules of [X509]. The certificate SHOULD then be checked against the expected identity of the peer following the rules described in [HTTP-TLS], except that a subjectAltName extension of type "xmpp" MUST be used as the identity if present. If one of these checks fails, user-oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients SHOULD terminate the connection (with a bad certificate error) and log the error to an appropriate audit log. Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting that enables it.
1. 根据[X509]的规则验证对等证书。然后，应按照[HTTP-TLS]中描述的规则，根据对等方的预期标识检查证书，除非必须使用类型为“xmpp”的subjectAltName扩展名作为标识（如果存在）。如果其中一项检查失败，面向用户的客户端必须通知用户（在任何情况下，客户端都可能给用户继续连接的机会），或者使用错误的证书终止连接。自动客户端应终止连接（出现错误证书），并将错误记录到适当的审核日志中。自动客户端可以提供禁用此检查的配置设置，但必须提供启用此检查的设置。
2. The peer SHOULD show the certificate to a user for approval, including the entire certificate chain. The peer MUST cache the certificate (or some non-forgeable representation such as a hash). In future connections, the peer MUST verify that the same certificate was presented and MUST notify the user if it has changed.
2. 对等方应向用户显示证书以供批准，包括整个证书链。对等方必须缓存证书（或一些不可伪造的表示，如哈希）。在将来的连接中，对等方必须验证是否提供了相同的证书，并且必须在证书发生更改时通知用户。
In Case #2 and Case #3, implementations SHOULD act as in (2) above.
在案例2和案例3中，实现应如上文（2）所示。
A compliant client implementation MUST support both TLS and SASL for connections to a server.
兼容的客户端实现必须同时支持TLS和SASL以连接到服务器。
The TLS protocol for encrypting XML streams (defined under Use of TLS (Section 5)) provides a reliable mechanism for helping to ensure the confidentiality and data integrity of data exchanged between two entities.
用于加密XML流的TLS协议（在TLS的使用（第5节）中定义）提供了一种可靠的机制，有助于确保两个实体之间交换的数据的机密性和数据完整性。
The SASL protocol for authenticating XML streams (defined under Use of SASL (Section 6)) provides a reliable mechanism for validating that a client connecting to a server is who it claims to be.
用于验证XML流的SASL协议（在SASL的使用（第6节）中定义）提供了一种可靠的机制，用于验证连接到服务器的客户端是否是它声称的用户。
Client-to-server communications MUST NOT proceed until the DNS hostname asserted by the server has been resolved. Such resolutions SHOULD first attempt to resolve the hostname using an [SRV] Service of "xmpp-client" and Proto of "tcp", resulting in resource records such as "_xmpp-client._tcp.example.com." (the use of the string
在解析服务器断言的DNS主机名之前，客户端到服务器的通信不得继续。此类解析应首先尝试使用“xmpp-client”的[SRV]服务和“tcp”的Proto解析主机名，从而生成资源记录，如“_xmpp-client._tcp.example.com”。（字符串的使用
"xmpp-client" for the service identifier is consistent with the IANA registration). If the SRV lookup fails, the fallback is a normal IPv4/IPv6 address record resolution to determine the IP address, using the "xmpp-client" port of 5222, registered with the IANA.
服务标识符的“xmpp客户端”与IANA注册一致）。如果SRV查找失败，则回退是一个正常的IPv4/IPv6地址记录解析，以使用向IANA注册的“xmpp客户端”端口5222确定IP地址。
The IP address and method of access of clients MUST NOT be made public by a server, nor are any connections other than the original server connection required. This helps to protect the client's server from direct attack or identification by third parties.
服务器不得公开客户端的IP地址和访问方法，也不需要原始服务器连接以外的任何连接。这有助于保护客户端服务器免受第三方的直接攻击或识别。
A compliant server implementation MUST support both TLS and SASL for inter-domain communications. For historical reasons, a compliant implementation SHOULD also support Server Dialback (Section 8).
兼容的服务器实现必须支持域间通信的TLS和SASL。出于历史原因，兼容实现还应支持服务器回拨（第8节）。
Because service provisioning is a matter of policy, it is OPTIONAL for any given domain to communicate with other domains, and server-to-server communications MAY be disabled by the administrator of any given deployment. If a particular domain enables inter-domain communications, it SHOULD enable high security.
由于服务提供是一个策略问题，因此任何给定域与其他域通信都是可选的，并且任何给定部署的管理员都可能禁用服务器到服务器的通信。如果特定域启用域间通信，则应启用高安全性。
Administrators may want to require use of SASL for server-to-server communications in order to ensure both authentication and confidentiality (e.g., on an organization's private network). Compliant implementations SHOULD support SASL for this purpose.
管理员可能需要使用SASL进行服务器到服务器的通信，以确保身份验证和机密性（例如，在组织的专用网络上）。为此，兼容实现应支持SASL。
Inter-domain connections MUST NOT proceed until the DNS hostnames asserted by the servers have been resolved. Such resolutions MUST first attempt to resolve the hostname using an [SRV] Service of "xmpp-server" and Proto of "tcp", resulting in resource records such as "_xmpp-server._tcp.example.com." (the use of the string "xmpp-server" for the service identifier is consistent with the IANA registration; note well that the "xmpp-server" service identifier supersedes the earlier use of a "jabber" service identifier, since the earlier usage did not conform to [SRV]; implementations desiring to be backward compatible should continue to look for or answer to the "jabber" service identifier as well). If the SRV lookup fails, the fallback is a normal IPv4/IPv6 address record resolution to determine the IP address, using the "xmpp-server" port 5269, registered with the IANA.
在解析服务器断言的DNS主机名之前，域间连接不得继续。此类解析必须首先尝试使用“xmpp服务器”的[SRV]服务和“tcp”的Proto解析主机名，从而生成资源记录，如“_xmpp-server._tcp.example.com”。（使用字符串“xmpp server”作为服务标识符与IANA注册一致；请注意，“xmpp服务器”服务标识符取代了“jabber”服务标识符的早期使用，因为早期使用不符合[SRV]；希望向后兼容的实现也应继续查找或回答“jabber”服务标识符）。如果SRV查找失败，则回退是一个正常的IPv4/IPv6地址记录解析，以使用IANA注册的“xmpp服务器”端口5269确定IP地址。
Server dialback helps protect against domain spoofing, thus making it more difficult to spoof XML stanzas. It is not a mechanism for authenticating, securing, or encrypting streams between servers as is done via SASL and TLS, and results in weak verification of server identities only. Furthermore, it is susceptible to DNS poisoning attacks unless DNSSec [DNSSEC] is used, and even if the DNS
服务器回拨有助于防止域欺骗，从而使欺骗XML节变得更加困难。它不是通过SASL和TLS对服务器之间的流进行身份验证、安全保护或加密的机制，并且只会导致服务器身份的弱验证。此外，除非使用DNSSec[DNSSec]，否则它很容易受到DNS中毒攻击，即使DNS
information is accurate, dialback cannot protect from attacks where the attacker is capable of hijacking the IP address of the remote domain. Domains requiring robust security SHOULD use TLS and SASL. If SASL is used for server-to-server authentication, dialback SHOULD NOT be used since it is unnecessary.
信息是准确的，如果攻击者能够劫持远程域的IP地址，则回拨无法防止攻击。需要强大安全性的域应使用TLS和SASL。如果SASL用于服务器到服务器身份验证，则不应使用回拨，因为它是不必要的。
The order of layers in which protocols MUST be stacked is as follows:
协议必须堆叠的层顺序如下：
1. TCP 2. TLS 3. SASL 4. XMPP
1. TCP 2。TLS 3。SASL 4。XMPP
The rationale for this order is that [TCP] is the base connection layer used by all of the protocols stacked on top of TCP, [TLS] is often provided at the operating system layer, [SASL] is often provided at the application layer, and XMPP is the application itself.
这种顺序的基本原理是，[TCP]是堆叠在TCP之上的所有协议使用的基本连接层，[TLS]通常在操作系统层提供，[SASL]通常在应用层提供，XMPP是应用程序本身。
The SASL framework does not provide a mechanism to bind SASL authentication to a security layer providing confidentiality and integrity protection that was negotiated at a lower layer. This lack of a "channel binding" prevents SASL from being able to verify that the source and destination end points to which the lower layer's security is bound are equivalent to the end points that SASL is authenticating. If the end points are not identical, the lower layer's security cannot be trusted to protect data transmitted between the SASL authenticated entities. In such a situation, a SASL security layer should be negotiated that effectively ignores the presence of the lower layer security.
SASL框架不提供将SASL身份验证绑定到安全层的机制，该安全层提供在较低层协商的机密性和完整性保护。由于缺乏“通道绑定”，SASL无法验证较低层安全性绑定到的源和目标端点是否与SASL正在验证的端点等效。如果端点不相同，则无法信任较低层的安全性来保护SASL认证实体之间传输的数据。在这种情况下，应协商SASL安全层，该层实际上忽略了较低安全层的存在。
At a minimum, all implementations MUST support the following mechanisms:
至少，所有实现必须支持以下机制：
for authentication: the SASL [DIGEST-MD5] mechanism
用于身份验证：SASL[DIGEST-MD5]机制
for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher)
为了保密：TLS（使用TLS\u RSA\u和\u 3DES\u EDE\u CBC\u SHA密码）
for both: TLS plus SASL EXTERNAL(using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side certificates)
对于两者：TLS+SASL外部（使用TLS\u RSA\u和支持客户端证书的\u 3DES\u EDE\u CBC\u SHA密码）
Communications using XMPP normally occur over [TCP] connections on port 5222 (client-to-server) or port 5269 (server-to-server), as registered with the IANA (see IANA Considerations (Section 15)). Use of these well-known ports allows administrators to easily enable or disable XMPP activity through existing and commonly-deployed firewalls.
使用XMPP的通信通常通过IANA注册的端口5222（客户端到服务器）或端口5269（服务器到服务器）上的[TCP]连接进行（参见IANA注意事项（第15节））。使用这些众所周知的端口，管理员可以通过现有的和通常部署的防火墙轻松启用或禁用XMPP活动。
Both the client and the server MUST verify any [BASE64] data received during SASL negotiation. An implementation MUST reject (not ignore) any characters that are not explicitly allowed by the base64 alphabet; this helps to guard against creation of a covert channel that could be used to "leak" information. An implementation MUST NOT break on invalid input and MUST reject any sequence of base64 characters containing the pad ('=') character if that character is included as something other than the last character of the data (e.g., "=AAA" or "BBBB=CCC"); this helps to guard against buffer overflow attacks and other attacks on the implementation. Base 64 encoding visually hides otherwise easily recognized information, such as passwords, but does not provide any computational confidentiality. Base 64 encoding MUST follow the definition in Section 3 of RFC 3548 [BASE64].
客户端和服务器都必须验证SASL协商期间接收到的任何[BASE64]数据。实现必须拒绝（而不是忽略）base64字母表不明确允许的任何字符；这有助于防止创建可用于“泄漏”信息的隐蔽通道。实现不得在无效输入时中断，并且必须拒绝包含pad（“=”）字符的任何base64字符序列（如果该字符不是作为数据的最后一个字符（例如“=AAA”或“BBBB=CCC”）包含）；这有助于防范缓冲区溢出攻击和对实现的其他攻击。Base64编码直观地隐藏了其他易于识别的信息，如密码，但不提供任何计算机密性。Base 64编码必须遵循RFC 3548[BASE64]第3节中的定义。
XMPP makes use of the [NAMEPREP] profile of [STRINGPREP] for the processing of domain identifiers; for security considerations related to Nameprep, refer to the appropriate section of [NAMEPREP].
XMPP利用[STRINGPREP]的[NAMEPREP]配置文件来处理域标识符；有关Nameprep的安全注意事项，请参阅[Nameprep]的相应部分。
In addition, XMPP defines two profiles of [STRINGPREP]: Nodeprep (Appendix A) for node identifiers and Resourceprep (Appendix B) for resource identifiers.
此外，XMPP定义了[STRINGPREP]的两个配置文件：节点标识符的Nodeprep（附录A）和资源标识符的Resourceprep（附录B）。
The Unicode and ISO/IEC 10646 repertoires have many characters that look similar. In many cases, users of security protocols might do visual matching, such as when comparing the names of trusted third parties. Because it is impossible to map similar-looking characters without a great deal of context, such as knowing the fonts used, stringprep does nothing to map similar-looking characters together, nor to prohibit some characters because they look like others.
Unicode和ISO/IEC10646指令集有许多看起来相似的字符。在许多情况下，安全协议的用户可能会进行视觉匹配，例如在比较受信任的第三方的名称时。因为在没有大量上下文的情况下（例如知道所使用的字体），不可能映射相似外观的字符，stringprep不会将相似外观的字符映射到一起，也不会禁止某些字符，因为它们看起来像其他字符。
A node identifier 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; many other kinds of entities could use node identifiers as part of their
在XMPP中，节点标识符可以用作实体地址的一部分。一种常见用法是作为即时消息用户的用户名；另一种是作为多用户聊天室的名称；许多其他类型的实体可以使用节点标识符作为其属性的一部分
addresses. The security of such services could be compromised based on different interpretations of the internationalized node identifier; for example, a user entering a single internationalized node identifier could access another user's account information, or a user could gain access to an otherwise restricted chat room or service.
地址。基于对国际化节点标识符的不同解释，此类服务的安全性可能受到损害；例如，输入单个国际化节点标识符的用户可以访问另一个用户的帐户信息，或者用户可以访问其他受限的聊天室或服务。
A resource identifier 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 (active session); another is as the nickname of a user in a multi-user chat room; many other kinds of entities could use resource identifiers as part of their addresses. The security of such services could be compromised based on different interpretations of the internationalized resource identifier; for example, a user could attempt to initiate multiple sessions with the same name, or a user could send a message to someone other than the intended recipient in a multi-user chat room.
在XMPP中，资源标识符可以用作实体地址的一部分。一种常见用法是作为即时消息用户的连接资源（活动会话）的名称；另一种是多用户聊天室中用户的昵称；许多其他类型的实体可以使用资源标识符作为其地址的一部分。基于对国际化资源标识符的不同解释，此类服务的安全性可能会受到损害；例如，用户可以尝试启动具有相同名称的多个会话，或者用户可以向多用户聊天室中的预期收件人以外的其他人发送消息。
A URN sub-namespace for TLS-related data in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in The IETF XML Registry [XML-REG].)
可扩展消息和状态协议（XMPP）中TLS相关数据的URN子命名空间定义如下。（此命名空间名称遵循IETF XML注册表[XML-REG]中定义的格式。）
URI: urn:ietf:params:xml:ns:xmpp-tls
Specification: RFC 3920
Description: This is the XML namespace name for TLS-related data in
the Extensible Messaging and Presence Protocol (XMPP) as defined
by RFC 3920.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
URI: urn:ietf:params:xml:ns:xmpp-tls
Specification: RFC 3920
Description: This is the XML namespace name for TLS-related data in
the Extensible Messaging and Presence Protocol (XMPP) as defined
by RFC 3920.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
A URN sub-namespace for SASL-related data in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in [XML-REG].)
可扩展消息和状态协议（XMPP）中SASL相关数据的URN子命名空间定义如下。（此命名空间名称遵循[XML-REG]中定义的格式。）
URI: urn:ietf:params:xml:ns:xmpp-sasl
Specification: RFC 3920
Description: This is the XML namespace name for SASL-related data in
the Extensible Messaging and Presence Protocol (XMPP) as defined
by RFC 3920.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
URI: urn:ietf:params:xml:ns:xmpp-sasl
Specification: RFC 3920
Description: This is the XML namespace name for SASL-related data in
the Extensible Messaging and Presence Protocol (XMPP) as defined
by RFC 3920.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
A URN sub-namespace for stream-related error data in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in [XML-REG].)
可扩展消息和状态协议（XMPP）中与流相关的错误数据的URN子命名空间定义如下。（此命名空间名称遵循[XML-REG]中定义的格式。）
URI: urn:ietf:params:xml:ns:xmpp-streams
Specification: RFC 3920
Description: This is the XML namespace name for stream-related error
data in the Extensible Messaging and Presence Protocol (XMPP) as
defined by RFC 3920.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
URI: urn:ietf:params:xml:ns:xmpp-streams
Specification: RFC 3920
Description: This is the XML namespace name for stream-related error
data in the Extensible Messaging and Presence Protocol (XMPP) as
defined by RFC 3920.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
A URN sub-namespace for resource binding in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in [XML-REG].)
可扩展消息和状态协议（XMPP）中用于资源绑定的URN子命名空间定义如下。（此命名空间名称遵循[XML-REG]中定义的格式。）
URI: urn:ietf:params:xml:ns:xmpp-bind
Specification: RFC 3920
Description: This is the XML namespace name for resource binding in
the Extensible Messaging and Presence Protocol (XMPP) as defined
by RFC 3920.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
URI: urn:ietf:params:xml:ns:xmpp-bind
Specification: RFC 3920
Description: This is the XML namespace name for resource binding in
the Extensible Messaging and Presence Protocol (XMPP) as defined
by RFC 3920.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
A URN sub-namespace for stanza-related error data in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in [XML-REG].)
可扩展消息和状态协议（XMPP）中与节相关的错误数据的URN子命名空间定义如下。（此命名空间名称遵循[XML-REG]中定义的格式。）
URI: urn:ietf:params:xml:ns:xmpp-stanzas
Specification: RFC 3920
Description: This is the XML namespace name for stanza-related error
data in the Extensible Messaging and Presence Protocol (XMPP) as
defined by RFC 3920.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
URI: urn:ietf:params:xml:ns:xmpp-stanzas
Specification: RFC 3920
Description: This is the XML namespace name for stanza-related error
data in the Extensible Messaging and Presence Protocol (XMPP) as
defined by RFC 3920.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
The Nodeprep profile of stringprep is defined under Nodeprep (Appendix A). The IANA has registered Nodeprep in the stringprep profile registry.
stringprep的Nodeprep配置文件在Nodeprep（附录A）中定义。IANA已在stringprep配置文件注册表中注册了Nodeprep。
Name of this profile:
此配置文件的名称：
Nodeprep
Nodeprep
RFC in which the profile is defined:
定义配置文件的RFC：
RFC 3920
RFC 3920
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 profile registry.
stringprep的Resourceprep配置文件在Resourceprep（附录B）下定义。IANA已在stringprep配置文件注册表中注册Resourceprep。
Name of this profile:
此配置文件的名称：
Resourceprep
资源准备
RFC in which the profile is defined:
定义配置文件的RFC：
RFC 3920
RFC 3920
Indicator whether or not this is the newest version of the profile:
指示此配置文件是否为最新版本：
This is the first version of Resourceprep
这是Resourceprep的第一个版本
The IANA has registered "xmpp" as a GSSAPI [GSS-API] service name, as defined under SASL Definition (Section 6.3).
IANA已将“xmpp”注册为GSSAPI[GSS-API]服务名称，定义见SASL定义（第6.3节）。
The IANA has registered "xmpp-client" and "xmpp-server" as keywords for [TCP] ports 5222 and 5269 respectively.
IANA已将“xmpp客户端”和“xmpp服务器”分别注册为[TCP]端口5222和5269的关键字。
These ports SHOULD be used for client-to-server and server-to-server communications respectively, but their use is OPTIONAL.
这些端口应分别用于客户端到服务器和服务器到服务器的通信，但它们的使用是可选的。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[BASE64]Josefsson，S.，“Base16、Base32和BASE64数据编码”，RFC3548，2003年7月。
[CHARSET] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[CHARSET]Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[DIGEST-MD5]Leach，P.和C.Newman，“使用摘要认证作为SASL机制”，RFC 28312000年5月。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[GSS-API] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[GSS-API]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[HTTP-TLS]Rescorla，E.，“TLS上的HTTP”，RFC 28182000年5月。
[IDNA] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[IDNA]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[IPv6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[IPv6]Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[LANGTAGS] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[LANGTAGS]Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[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月。
[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RANDOM]Eastlake 3rd，D.，Crocker，S.，和J.Schiller，“安全的随机性建议”，RFC 1750，1994年12月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
[SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[SRV]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[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月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]Postel，J.，“传输控制协议”，STD 7，RFC 793，1981年9月。
[TERMS] 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月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，1999年1月。
[UCS2] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS) - Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2, October 1996.
[UCS2]国际标准化组织，“信息技术-通用多八位编码字符集（UCS）-修改件2：UCS转换格式8（UTF-8）”，ISO标准10646-1附录2，1996年10月。
[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月。
[X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[X509]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[XML]Bray，T.，Paoli，J.，Sperberg McQueen，C.，和E.Maler，“可扩展标记语言（XML）1.0（第二版）”，W3C REC XML，2000年10月<http://www.w3.org/TR/REC-xml>.
[XML-NAMES] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-names>.
[XML-NAMES]Bray，T.，Hollander，D.，和A.Layman，“XML中的名称空间”，W3C REC XML名称，1999年1月<http://www.w3.org/TR/REC-xml-names>.
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC22441997年11月。
[ASN.1] CCITT, "Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1)", 1988.
[ASN.1]CCITT，“建议X.208：抽象语法符号1规范（ASN.1）”，1988年。
[DNSSEC] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[DNSSEC]Eastlake 3rd，D.，“域名系统安全扩展”，RFC 25351999年3月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[IMP-REQS] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[IMP-REQS]Day，M.，Aggarwal，S.，Mohr，G.，和J.Vincent，“即时消息/存在协议要求”，RFC 27792000年2月。
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
[IRC]Oikarinen，J.和D.Reed，“互联网中继聊天协议”，RFC 1459，1993年5月。
[JEP-0029] Kaes, C., "Definition of Jabber Identifiers (JIDs)", JSF JEP 0029, October 2003.
[JEP-0029]Kaes，C.“Jabber标识符（JID）的定义”，JSF JEP 00292003年10月。
[JEP-0078] Saint-Andre, P., "Non-SASL Authentication", JSF JEP 0078, July 2004.
[JEP-0078]圣安德烈，P.，“非SASL认证”，JSF JEP 0078，2004年7月。
[JEP-0086] Norris, R. and P. Saint-Andre, "Error Condition Mappings", JSF JEP 0086, February 2004.
[JEP-0086]Norris，R.和P.Saint Andre，“错误条件映射”，JSF JEP 0086，2004年2月。
[JSF] Jabber Software Foundation, "Jabber Software Foundation", <http://www.jabber.org/>.
JBF] Jabbor软件基金会，“JabBER软件基金会”，<http://www.jabber.org/>.
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[SIMPLE] SIMPLE Working Group, "SIMPLE WG", <http://www.ietf.org/html.charters/simple-charter.html>.
[简单]简单工作组，“简单工作组”<http://www.ietf.org/html.charters/simple-charter.html>.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[USINGTLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[USINGTLS]Newman，C.，“将TLS与IMAP、POP3和ACAP一起使用”，RFC 25951999年6月。
[XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[XML-REG]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[XMPP-IM] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[XMPP-IM]Saint Andre，P.，Ed.“可扩展消息和状态协议（XMPP）：即时消息和状态”，RFC 39212004年10月。
This appendix defines the "Nodeprep" profile of [STRINGPREP]. As such, it specifies processing rules that will enable users to enter internationalized node identifiers in the Extensible Messaging and Presence Protocol (XMPP) and have the highest chance of getting the content of the strings correct. (An XMPP node identifier is the optional portion of an XMPP address that precedes a domain identifier and the '@' separator; it is often but not exclusively associated with an instant messaging username.) These processing rules are intended only for XMPP node identifiers and are not intended for arbitrary text or any other aspect of an XMPP address.
本附录定义了[STRINGPREP]的“Nodeprep”配置文件。因此，它指定了处理规则，使用户能够在可扩展消息和状态协议（XMPP）中输入国际化节点标识符，并有最大的机会获得正确的字符串内容。（XMPP节点标识符是XMPP地址的可选部分，位于域标识符和“@”分隔符之前；它通常但不是唯一与即时消息用户名关联。）这些处理规则仅适用于XMPP节点标识符，不适用于任意文本或XMPP地址的任何其他方面。
This profile defines the following, as required by [STRINGPREP]:
根据[STRINGPREP]的要求，此配置文件定义了以下内容：
o The intended applicability of the profile: internationalized node identifiers within XMPP o The character repertoire that is the input and output to stringprep: Unicode 3.2, specified in Section 2 of this Appendix o The mappings used: specified in Section 3 o The Unicode normalization used: specified in Section 4 o The characters that are prohibited as output: specified in Section 5 o Bidirectional character handling: specified in Section 6
o 概要文件的预期适用性：XMPP中的国际化节点标识符o作为stringprep:Unicode 3.2的输入和输出的字符集，本附录o第2节规定了使用的映射：第3节规定了使用的Unicode规范化：第4节规定了禁止输出的字符：第5节规定了双向字符处理：第6节规定了
This profile uses Unicode 3.2 with the list of unassigned code points being Table A.1, both 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 Unicode characters are also prohibited:
此外，还禁止使用以下Unicode字符：
#x22 (")
#x26 (&)
#x27 (')
#x2F (/)
#x3A (:)
#x3C (<)
#x3E (>)
#x40 (@)
#x22 (")
#x26 (&)
#x27 (')
#x2F (/)
#x3A (:)
#x3C (<)
#x3E (>)
#x40 (@)
This profile specifies the checking of bidirectional strings, as described in Section 6 of [STRINGPREP].
此配置文件指定双向字符串的检查，如[STRINGPREP]第6节所述。
This appendix defines the "Resourceprep" profile of [STRINGPREP]. As such, it specifies processing rules that will enable users to enter internationalized resource identifiers in the Extensible Messaging and Presence Protocol (XMPP) and have the highest chance of getting the content of the strings correct. (An XMPP resource identifier is the optional portion of an XMPP address that follows a domain identifier and the '/' separator; it is often but not exclusively associated with an instant messaging session name.) These processing rules are intended only for XMPP resource identifiers and are not intended for arbitrary text or any other aspect of an XMPP address.
本附录定义了[STRINGPREP]的“Resourceprep”配置文件。因此，它指定了处理规则，使用户能够在可扩展消息和状态协议（XMPP）中输入国际化的资源标识符，并有最大的机会获得正确的字符串内容。（XMPP资源标识符是在域标识符和“/”分隔符之后的XMPP地址的可选部分；它通常但不是唯一与即时消息会话名称关联。）这些处理规则仅适用于XMPP资源标识符，不适用于任意文本或XMPP地址的任何其他方面。
This profile defines the following, as required by [STRINGPREP]:
根据[STRINGPREP]的要求，此配置文件定义了以下内容：
o The intended applicability of the profile: internationalized resource identifiers within XMPP
o 概要文件的预期适用性：XMPP中的国际化资源标识符
o The character repertoire that is the input and output to stringprep: Unicode 3.2, specified in Section 2 of this Appendix
o 作为stringprep:Unicode 3.2输入和输出的字符集，在本附录第2节中指定
o The mappings used: specified in Section 3
o 使用的映射：在第3节中指定
o The Unicode normalization used: specified in Section 4
o 使用的Unicode规范化：在第4节中指定
o The characters that are prohibited as output: specified in Section 5
o 禁止作为输出的字符：在第5节中指定
o Bidirectional character handling: specified in Section 6
o 双向字符处理：在第6节中规定
This profile uses Unicode 3.2 with the list of unassigned code points being Table A.1, both 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 using Unicode normalization form KC, as described in [STRINGPREP].
此配置文件使用Unicode规范化形式KC进行指定，如[STRINGPREP]中所述。
This profile specifies prohibiting use of 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节所述。
The following XML schemas are descriptive, not normative. For schemas defining the 'jabber:client' and 'jabber:server' namespaces, refer to [XMPP-IM].
以下XML模式是描述性的，不是规范性的。有关定义“jabber:client”和“jabber:server”命名空间的架构，请参阅[XMPP-IM]。
<?xml version='1.0' encoding='UTF-8'?>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://etherx.jabber.org/streams'
xmlns='http://etherx.jabber.org/streams'
elementFormDefault='unqualified'>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://etherx.jabber.org/streams'
xmlns='http://etherx.jabber.org/streams'
elementFormDefault='unqualified'>
<xs:element name='stream'>
<xs:complexType>
<xs:sequence xmlns:client='jabber:client'
xmlns:server='jabber:server'
xmlns:db='jabber:server:dialback'>
<xs:element ref='features' minOccurs='0' maxOccurs='1'/>
<xs:any namespace='urn:ietf:params:xml:ns:xmpp-tls'
minOccurs='0'
maxOccurs='unbounded'/>
<xs:any namespace='urn:ietf:params:xml:ns:xmpp-sasl'
minOccurs='0'
<xs:element name='stream'>
<xs:complexType>
<xs:sequence xmlns:client='jabber:client'
xmlns:server='jabber:server'
xmlns:db='jabber:server:dialback'>
<xs:element ref='features' minOccurs='0' maxOccurs='1'/>
<xs:any namespace='urn:ietf:params:xml:ns:xmpp-tls'
minOccurs='0'
maxOccurs='unbounded'/>
<xs:any namespace='urn:ietf:params:xml:ns:xmpp-sasl'
minOccurs='0'
maxOccurs='unbounded'/>
<xs:choice minOccurs='0' maxOccurs='1'>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
<xs:element ref='client:message'/>
<xs:element ref='client:presence'/>
<xs:element ref='client:iq'/>
</xs:choice>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
<xs:element ref='server:message'/>
<xs:element ref='server:presence'/>
<xs:element ref='server:iq'/>
<xs:element ref='db:result'/>
<xs:element ref='db:verify'/>
</xs:choice>
</xs:choice>
<xs:element ref='error' minOccurs='0' maxOccurs='1'/>
</xs:sequence>
<xs:attribute name='from' type='xs:string' use='optional'/>
<xs:attribute name='id' type='xs:NMTOKEN' use='optional'/>
<xs:attribute name='to' type='xs:string' use='optional'/>
<xs:attribute name='version' type='xs:decimal' use='optional'/>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:complexType>
</xs:element>
maxOccurs='unbounded'/>
<xs:choice minOccurs='0' maxOccurs='1'>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
<xs:element ref='client:message'/>
<xs:element ref='client:presence'/>
<xs:element ref='client:iq'/>
</xs:choice>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
<xs:element ref='server:message'/>
<xs:element ref='server:presence'/>
<xs:element ref='server:iq'/>
<xs:element ref='db:result'/>
<xs:element ref='db:verify'/>
</xs:choice>
</xs:choice>
<xs:element ref='error' minOccurs='0' maxOccurs='1'/>
</xs:sequence>
<xs:attribute name='from' type='xs:string' use='optional'/>
<xs:attribute name='id' type='xs:NMTOKEN' use='optional'/>
<xs:attribute name='to' type='xs:string' use='optional'/>
<xs:attribute name='version' type='xs:decimal' use='optional'/>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='features'>
<xs:complexType>
<xs:all xmlns:tls='urn:ietf:params:xml:ns:xmpp-tls'
xmlns:sasl='urn:ietf:params:xml:ns:xmpp-sasl'
xmlns:bind='urn:ietf:params:xml:ns:xmpp-bind'
xmlns:sess='urn:ietf:params:xml:ns:xmpp-session'>
<xs:element ref='tls:starttls' minOccurs='0'/>
<xs:element ref='sasl:mechanisms' minOccurs='0'/>
<xs:element ref='bind:bind' minOccurs='0'/>
<xs:element ref='sess:session' minOccurs='0'/>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name='features'>
<xs:complexType>
<xs:all xmlns:tls='urn:ietf:params:xml:ns:xmpp-tls'
xmlns:sasl='urn:ietf:params:xml:ns:xmpp-sasl'
xmlns:bind='urn:ietf:params:xml:ns:xmpp-bind'
xmlns:sess='urn:ietf:params:xml:ns:xmpp-session'>
<xs:element ref='tls:starttls' minOccurs='0'/>
<xs:element ref='sasl:mechanisms' minOccurs='0'/>
<xs:element ref='bind:bind' minOccurs='0'/>
<xs:element ref='sess:session' minOccurs='0'/>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name='error'>
<xs:complexType>
<xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-streams'>
<xs:group ref='err:streamErrorGroup'/>
<xs:element ref='err:text'
minOccurs='0'
maxOccurs='1'/>
</xs:sequence>
</xs:complexType>
<xs:element name='error'>
<xs:complexType>
<xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-streams'>
<xs:group ref='err:streamErrorGroup'/>
<xs:element ref='err:text'
minOccurs='0'
maxOccurs='1'/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:element>
</xs:schema>
</xs:schema>
<?xml version='1.0' encoding='UTF-8'?>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-streams'
xmlns='urn:ietf:params:xml:ns:xmpp-streams'
elementFormDefault='qualified'>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-streams'
xmlns='urn:ietf:params:xml:ns:xmpp-streams'
elementFormDefault='qualified'>
<xs:element name='bad-format' type='empty'/>
<xs:element name='bad-namespace-prefix' type='empty'/>
<xs:element name='conflict' type='empty'/>
<xs:element name='connection-timeout' type='empty'/>
<xs:element name='host-gone' type='empty'/>
<xs:element name='host-unknown' type='empty'/>
<xs:element name='improper-addressing' type='empty'/>
<xs:element name='internal-server-error' type='empty'/>
<xs:element name='invalid-from' type='empty'/>
<xs:element name='invalid-id' type='empty'/>
<xs:element name='invalid-namespace' type='empty'/>
<xs:element name='invalid-xml' type='empty'/>
<xs:element name='not-authorized' type='empty'/>
<xs:element name='policy-violation' type='empty'/>
<xs:element name='remote-connection-failed' type='empty'/>
<xs:element name='resource-constraint' type='empty'/>
<xs:element name='restricted-xml' type='empty'/>
<xs:element name='see-other-host' type='xs:string'/>
<xs:element name='system-shutdown' type='empty'/>
<xs:element name='undefined-condition' type='empty'/>
<xs:element name='unsupported-encoding' type='empty'/>
<xs:element name='unsupported-stanza-type' type='empty'/>
<xs:element name='unsupported-version' type='empty'/>
<xs:element name='xml-not-well-formed' type='empty'/>
<xs:element name='bad-format' type='empty'/>
<xs:element name='bad-namespace-prefix' type='empty'/>
<xs:element name='conflict' type='empty'/>
<xs:element name='connection-timeout' type='empty'/>
<xs:element name='host-gone' type='empty'/>
<xs:element name='host-unknown' type='empty'/>
<xs:element name='improper-addressing' type='empty'/>
<xs:element name='internal-server-error' type='empty'/>
<xs:element name='invalid-from' type='empty'/>
<xs:element name='invalid-id' type='empty'/>
<xs:element name='invalid-namespace' type='empty'/>
<xs:element name='invalid-xml' type='empty'/>
<xs:element name='not-authorized' type='empty'/>
<xs:element name='policy-violation' type='empty'/>
<xs:element name='remote-connection-failed' type='empty'/>
<xs:element name='resource-constraint' type='empty'/>
<xs:element name='restricted-xml' type='empty'/>
<xs:element name='see-other-host' type='xs:string'/>
<xs:element name='system-shutdown' type='empty'/>
<xs:element name='undefined-condition' type='empty'/>
<xs:element name='unsupported-encoding' type='empty'/>
<xs:element name='unsupported-stanza-type' type='empty'/>
<xs:element name='unsupported-version' type='empty'/>
<xs:element name='xml-not-well-formed' type='empty'/>
<xs:group name='streamErrorGroup'>
<xs:choice>
<xs:element ref='bad-format'/>
<xs:element ref='bad-namespace-prefix'/>
<xs:element ref='conflict'/>
<xs:element ref='connection-timeout'/>
<xs:element ref='host-gone'/>
<xs:element ref='host-unknown'/>
<xs:element ref='improper-addressing'/>
<xs:group name='streamErrorGroup'>
<xs:choice>
<xs:element ref='bad-format'/>
<xs:element ref='bad-namespace-prefix'/>
<xs:element ref='conflict'/>
<xs:element ref='connection-timeout'/>
<xs:element ref='host-gone'/>
<xs:element ref='host-unknown'/>
<xs:element ref='improper-addressing'/>
<xs:element ref='internal-server-error'/>
<xs:element ref='invalid-from'/>
<xs:element ref='invalid-id'/>
<xs:element ref='invalid-namespace'/>
<xs:element ref='invalid-xml'/>
<xs:element ref='not-authorized'/>
<xs:element ref='policy-violation'/>
<xs:element ref='remote-connection-failed'/>
<xs:element ref='resource-constraint'/>
<xs:element ref='restricted-xml'/>
<xs:element ref='see-other-host'/>
<xs:element ref='system-shutdown'/>
<xs:element ref='undefined-condition'/>
<xs:element ref='unsupported-encoding'/>
<xs:element ref='unsupported-stanza-type'/>
<xs:element ref='unsupported-version'/>
<xs:element ref='xml-not-well-formed'/>
</xs:choice>
</xs:group>
<xs:element ref='internal-server-error'/>
<xs:element ref='invalid-from'/>
<xs:element ref='invalid-id'/>
<xs:element ref='invalid-namespace'/>
<xs:element ref='invalid-xml'/>
<xs:element ref='not-authorized'/>
<xs:element ref='policy-violation'/>
<xs:element ref='remote-connection-failed'/>
<xs:element ref='resource-constraint'/>
<xs:element ref='restricted-xml'/>
<xs:element ref='see-other-host'/>
<xs:element ref='system-shutdown'/>
<xs:element ref='undefined-condition'/>
<xs:element ref='unsupported-encoding'/>
<xs:element ref='unsupported-stanza-type'/>
<xs:element ref='unsupported-version'/>
<xs:element ref='xml-not-well-formed'/>
</xs:choice>
</xs:group>
<xs:element name='text'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='text'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
</xs:schema>
<?xml version='1.0' encoding='UTF-8'?>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-tls'
xmlns='urn:ietf:params:xml:ns:xmpp-tls'
elementFormDefault='qualified'>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-tls'
xmlns='urn:ietf:params:xml:ns:xmpp-tls'
elementFormDefault='qualified'>
<xs:element name='starttls'>
<xs:complexType>
<xs:sequence>
<xs:element
name='required'
minOccurs='0'
maxOccurs='1'
type='empty'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='starttls'>
<xs:complexType>
<xs:sequence>
<xs:element
name='required'
minOccurs='0'
maxOccurs='1'
type='empty'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='proceed' type='empty'/>
<xs:element name='failure' type='empty'/>
<xs:element name='proceed' type='empty'/>
<xs:element name='failure' type='empty'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
</xs:schema>
<?xml version='1.0' encoding='UTF-8'?>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-sasl'
xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
elementFormDefault='qualified'>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-sasl'
xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
elementFormDefault='qualified'>
<xs:element name='mechanisms'>
<xs:complexType>
<xs:sequence>
<xs:element name='mechanism'
maxOccurs='unbounded'
type='xs:string'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='mechanisms'>
<xs:complexType>
<xs:sequence>
<xs:element name='mechanism'
maxOccurs='unbounded'
type='xs:string'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='auth'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='mechanism'
<xs:element name='auth'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='mechanism'
type='xs:string'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
type='xs:string'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='challenge' type='xs:string'/>
<xs:element name='response' type='xs:string'/>
<xs:element name='abort' type='empty'/>
<xs:element name='success' type='empty'/>
<xs:element name='challenge' type='xs:string'/>
<xs:element name='response' type='xs:string'/>
<xs:element name='abort' type='empty'/>
<xs:element name='success' type='empty'/>
<xs:element name='failure'>
<xs:complexType>
<xs:choice minOccurs='0'>
<xs:element name='aborted' type='empty'/>
<xs:element name='incorrect-encoding' type='empty'/>
<xs:element name='invalid-authzid' type='empty'/>
<xs:element name='invalid-mechanism' type='empty'/>
<xs:element name='mechanism-too-weak' type='empty'/>
<xs:element name='not-authorized' type='empty'/>
<xs:element name='temporary-auth-failure' type='empty'/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
<xs:element name='failure'>
<xs:complexType>
<xs:choice minOccurs='0'>
<xs:element name='aborted' type='empty'/>
<xs:element name='incorrect-encoding' type='empty'/>
<xs:element name='invalid-authzid' type='empty'/>
<xs:element name='invalid-mechanism' type='empty'/>
<xs:element name='mechanism-too-weak' type='empty'/>
<xs:element name='not-authorized' type='empty'/>
<xs:element name='temporary-auth-failure' type='empty'/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
</xs:schema>
<?xml version='1.0' encoding='UTF-8'?>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-bind'
xmlns='urn:ietf:params:xml:ns:xmpp-bind'
elementFormDefault='qualified'>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-bind'
xmlns='urn:ietf:params:xml:ns:xmpp-bind'
elementFormDefault='qualified'>
<xs:element name='bind'>
<xs:complexType>
<xs:choice minOccurs='0' maxOccurs='1'>
<xs:element name='resource' type='xs:string'/>
<xs:element name='jid' type='xs:string'/>
<xs:element name='bind'>
<xs:complexType>
<xs:choice minOccurs='0' maxOccurs='1'>
<xs:element name='resource' type='xs:string'/>
<xs:element name='jid' type='xs:string'/>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:schema>
</xs:schema>
<?xml version='1.0' encoding='UTF-8'?>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='jabber:server:dialback'
xmlns='jabber:server:dialback'
elementFormDefault='qualified'>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='jabber:server:dialback'
xmlns='jabber:server:dialback'
elementFormDefault='qualified'>
<xs:element name='result'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:token'>
<xs:attribute name='from' type='xs:string' use='required'/>
<xs:attribute name='to' type='xs:string' use='required'/>
<xs:attribute name='type' use='optional'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='invalid'/>
<xs:enumeration value='valid'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='result'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:token'>
<xs:attribute name='from' type='xs:string' use='required'/>
<xs:attribute name='to' type='xs:string' use='required'/>
<xs:attribute name='type' use='optional'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='invalid'/>
<xs:enumeration value='valid'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='verify'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:token'>
<xs:attribute name='from' type='xs:string' use='required'/>
<xs:attribute name='id' type='xs:NMTOKEN' use='required'/>
<xs:attribute name='to' type='xs:string' use='required'/>
<xs:attribute name='type' use='optional'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='invalid'/>
<xs:enumeration value='valid'/>
</xs:restriction>
<xs:element name='verify'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:token'>
<xs:attribute name='from' type='xs:string' use='required'/>
<xs:attribute name='id' type='xs:NMTOKEN' use='required'/>
<xs:attribute name='to' type='xs:string' use='required'/>
<xs:attribute name='type' use='optional'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='invalid'/>
<xs:enumeration value='valid'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
</xs:schema>
<?xml version='1.0' encoding='UTF-8'?>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-stanzas'
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
elementFormDefault='qualified'>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-stanzas'
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
elementFormDefault='qualified'>
<xs:element name='bad-request' type='empty'/>
<xs:element name='conflict' type='empty'/>
<xs:element name='feature-not-implemented' type='empty'/>
<xs:element name='forbidden' type='empty'/>
<xs:element name='gone' type='xs:string'/>
<xs:element name='internal-server-error' type='empty'/>
<xs:element name='item-not-found' type='empty'/>
<xs:element name='jid-malformed' type='empty'/>
<xs:element name='not-acceptable' type='empty'/>
<xs:element name='not-allowed' type='empty'/>
<xs:element name='payment-required' type='empty'/>
<xs:element name='recipient-unavailable' type='empty'/>
<xs:element name='redirect' type='xs:string'/>
<xs:element name='registration-required' type='empty'/>
<xs:element name='remote-server-not-found' type='empty'/>
<xs:element name='remote-server-timeout' type='empty'/>
<xs:element name='resource-constraint' type='empty'/>
<xs:element name='service-unavailable' type='empty'/>
<xs:element name='subscription-required' type='empty'/>
<xs:element name='undefined-condition' type='empty'/>
<xs:element name='unexpected-request' type='empty'/>
<xs:element name='bad-request' type='empty'/>
<xs:element name='conflict' type='empty'/>
<xs:element name='feature-not-implemented' type='empty'/>
<xs:element name='forbidden' type='empty'/>
<xs:element name='gone' type='xs:string'/>
<xs:element name='internal-server-error' type='empty'/>
<xs:element name='item-not-found' type='empty'/>
<xs:element name='jid-malformed' type='empty'/>
<xs:element name='not-acceptable' type='empty'/>
<xs:element name='not-allowed' type='empty'/>
<xs:element name='payment-required' type='empty'/>
<xs:element name='recipient-unavailable' type='empty'/>
<xs:element name='redirect' type='xs:string'/>
<xs:element name='registration-required' type='empty'/>
<xs:element name='remote-server-not-found' type='empty'/>
<xs:element name='remote-server-timeout' type='empty'/>
<xs:element name='resource-constraint' type='empty'/>
<xs:element name='service-unavailable' type='empty'/>
<xs:element name='subscription-required' type='empty'/>
<xs:element name='undefined-condition' type='empty'/>
<xs:element name='unexpected-request' type='empty'/>
<xs:group name='stanzaErrorGroup'>
<xs:choice>
<xs:element ref='bad-request'/>
<xs:element ref='conflict'/>
<xs:element ref='feature-not-implemented'/>
<xs:element ref='forbidden'/>
<xs:element ref='gone'/>
<xs:group name='stanzaErrorGroup'>
<xs:choice>
<xs:element ref='bad-request'/>
<xs:element ref='conflict'/>
<xs:element ref='feature-not-implemented'/>
<xs:element ref='forbidden'/>
<xs:element ref='gone'/>
<xs:element ref='internal-server-error'/>
<xs:element ref='item-not-found'/>
<xs:element ref='jid-malformed'/>
<xs:element ref='not-acceptable'/>
<xs:element ref='not-allowed'/>
<xs:element ref='payment-required'/>
<xs:element ref='recipient-unavailable'/>
<xs:element ref='redirect'/>
<xs:element ref='registration-required'/>
<xs:element ref='remote-server-not-found'/>
<xs:element ref='remote-server-timeout'/>
<xs:element ref='resource-constraint'/>
<xs:element ref='service-unavailable'/>
<xs:element ref='subscription-required'/>
<xs:element ref='undefined-condition'/>
<xs:element ref='unexpected-request'/>
</xs:choice>
</xs:group>
<xs:element ref='internal-server-error'/>
<xs:element ref='item-not-found'/>
<xs:element ref='jid-malformed'/>
<xs:element ref='not-acceptable'/>
<xs:element ref='not-allowed'/>
<xs:element ref='payment-required'/>
<xs:element ref='recipient-unavailable'/>
<xs:element ref='redirect'/>
<xs:element ref='registration-required'/>
<xs:element ref='remote-server-not-found'/>
<xs:element ref='remote-server-timeout'/>
<xs:element ref='resource-constraint'/>
<xs:element ref='service-unavailable'/>
<xs:element ref='subscription-required'/>
<xs:element ref='undefined-condition'/>
<xs:element ref='unexpected-request'/>
</xs:choice>
</xs:group>
<xs:element name='text'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='text'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
</xs:schema>
This section is non-normative.
本节是非规范性的。
XMPP has been adapted from the protocols originally developed in the Jabber open-source community, which can be thought of as "XMPP 0.9". Because there exists a large installed base of Jabber implementations and deployments, it may be helpful to specify the key differences between the relevant Jabber protocols and XMPP in order to expedite and encourage upgrades of those implementations and deployments to XMPP. This section summarizes the core differences, while the corresponding section of [XMPP-IM] summarizes the differences that relate specifically to instant messaging and presence applications.
XMPP是从Jabber开源社区最初开发的协议改编而来的，可以将其视为“XMPP 0.9”。由于存在大量Jabber实现和部署的安装基础，因此指定相关Jabber协议和XMPP之间的关键区别可能会有所帮助，以加快并鼓励将这些实现和部署升级到XMPP。本节总结了核心差异，[XMPP-IM]的相应部分总结了与即时消息和状态应用程序相关的差异。
It was common practice in the Jabber community to use SSL for channel encryption on ports other than 5222 and 5269 (the convention is to use ports 5223 and 5270). XMPP uses TLS over the IANA-registered ports for channel encryption, as defined under Use of TLS (Section 5) herein.
Jabber社区的常见做法是在5222和5269以外的端口上使用SSL进行通道加密（约定使用端口5223和5270）。XMPP在IANA注册端口上使用TLS进行信道加密，如本文中使用TLS（第5节）所定义。
The client-server authentication protocol developed in the Jabber community used a basic IQ interaction qualified by the 'jabber:iq:auth' namespace (documentation of this protocol is contained in [JEP-0078], published by the Jabber Software Foundation [JSF]). XMPP uses SASL for authentication, as defined under Use of SASL (Section 6) herein.
JabBER社区中开发的客户机-服务器身份验证协议使用了由Jabb:IQ:Auth'命名空间限定的基本IQ交互（该协议的文档包含在JabBePraseFrase[JSF]发布的[JEP-078]）中。XMPP使用SASL进行身份验证，如本文使用SASL（第6节）所定义。
The Jabber community did not develop an authentication protocol for server-to-server communications, only the Server Dialback (Section 8) protocol to prevent server spoofing. XMPP supersedes Server Dialback with a true server-to-server authentication protocol, as defined under Use of SASL (Section 6) herein.
Jabber社区没有为服务器到服务器通信开发身份验证协议，只有服务器回拨（第8节）协议可以防止服务器欺骗。XMPP使用真正的服务器到服务器身份验证协议取代服务器回拨，如本文使用SASL（第6节）所定义。
Resource binding in the Jabber community was handled via the 'jabber:iq:auth' namespace (which was also used for client authentication with a server). XMPP defines a dedicated namespace for resource binding as well as the ability for a server to generate a resource identifier on behalf of a client, as defined under Resource Binding (Section 7).
Jabber社区中的资源绑定是通过“Jabber:iq:auth”命名空间处理的（该命名空间还用于与服务器的客户端身份验证）。XMPP定义了资源绑定的专用命名空间，以及服务器代表客户机生成资源标识符的能力，如资源绑定（第7节）中所定义。
JID processing was somewhat loosely defined by the Jabber community (documentation of forbidden characters and case handling is contained in [JEP-0029], published by the Jabber Software Foundation [JSF]). XMPP specifies the use of [NAMEPREP] for domain identifiers and supplements Nameprep with two additional [STRINGPREP] profiles for JID processing: Nodeprep (Appendix A) for node identifiers and Resourceprep (Appendix B) for resource identifiers.
JID处理有点松散的Jabbe社区定义（禁止字符和案件处理文件）包含在[JPE-029 ]，由JabBER软件基金会[JSF]发布。XMPP指定域标识符使用[NAMEPREP]，并为NAMEPREP添加两个额外的[STRINGPREP]配置文件用于JID处理：节点标识符使用Nodeprep（附录A），资源标识符使用Resourceprep（附录B）。
Stream-related errors were handled in the Jabber community via XML character data text in a <stream:error/> element. In XMPP, stream-related errors are handled via an extensible mechanism defined under Stream Errors (Section 4.7) herein.
Jabber社区通过<Stream:error/>元素中的XML字符数据文本处理与流相关的错误。在XMPP中，与流相关的错误通过本文流错误（第4.7节）中定义的可扩展机制进行处理。
Stanza-related errors were handled in the Jabber community via HTTP-style error codes. In XMPP, stanza-related errors are handled via an extensible mechanism defined under Stanza Errors (Section 9.3) herein. (Documentation of a mapping between Jabber and XMPP error handling mechanisms is contained in [JEP-0086], published by the Jabber Software Foundation [JSF].)
Jabber社区通过HTTP样式的错误代码处理与节相关的错误。在XMPP中，与节相关的错误通过在节错误（第9.3节）中定义的可扩展机制进行处理。JabBER和XMPP错误处理机制之间的映射文档包含在JabbFieldFrase[JSF]发布的[JEPP-086]中。
Although use of UTF-8 has always been standard practice within the Jabber community, the community did not define mechanisms for specifying the language of human-readable text provided in XML character data. XMPP specifies the use of the 'xml:lang' attribute in such contexts, as defined under Stream Attributes (Section 4.4) and xml:lang (Section 9.1.5) herein.
尽管UTF-8的使用一直是Jabber社区的标准实践，但该社区没有定义用于指定XML字符数据中提供的人类可读文本的语言的机制。XMPP指定在此类上下文中使用“xml:lang”属性，如本文的流属性（第4.4节）和xml:lang（第9.1.5节）所定义。
The Jabber community did not include a 'version' attribute in stream headers. XMPP specifies inclusion of that attribute as a way to signal support for the stream features (authentication, encryption, etc.) defined under Version Support (Section 4.4.1) herein.
Jabber社区未在流标头中包含“version”属性。XMPP指定包含该属性，作为表示支持本文版本支持（第4.4.1节）中定义的流特性（身份验证、加密等）的一种方式。
Contributors
贡献者
Most of the core aspects of the Extensible Messaging and Presence Protocol were developed originally within the Jabber open-source community in 1999. This community was founded by Jeremie Miller, who released source code for the initial version of the jabber server in January 1999. Major early contributors to the base protocol also included Ryan Eatmon, Peter Millard, Thomas Muldowney, and Dave Smith. Work by the XMPP Working Group has concentrated especially on security and internationalization; in these areas, protocols for the use of TLS and SASL were originally contributed by Rob Norris, and stringprep profiles were originally contributed by Joe Hildebrand. The error code syntax was suggested by Lisa Dusseault.
可扩展消息和状态协议的大多数核心方面最初是在1999年Jabber开源社区中开发的。该社区由Jeremie Miller创建，他于1999年1月发布了jabber服务器初始版本的源代码。基本协议的主要早期贡献者还包括Ryan Eatmon、Peter Millard、Thomas Muldowney和Dave Smith。XMPP工作组的工作重点是安全和国际化；在这些领域，TLS和SASL的使用协议最初由Rob Norris提供，stringprep配置文件最初由Joe Hildebrand提供。错误代码语法是由Lisa Dusseault建议的。
Acknowledgements
致谢
Thanks are due to a number of individuals in addition to the contributors listed. Although it is difficult to provide a complete list, the following individuals were particularly helpful in defining the protocols or in commenting on the specifications in this memo: Thomas Charron, Richard Dobson, Sam Hartman, Schuyler Heath, Jonathan Hogg, Cullen Jennings, Craig Kaes, Jacek Konieczny, Alexey Melnikov, Keith Minkler, Julian Missig, Pete Resnick, Marshall Rose, Alexey Shchepin, Jean-Louis Seguineau, Iain Shigeoka, Greg Troxel, and David Waite. Thanks also to members of the XMPP Working Group and the IETF community for comments and feedback provided throughout the life of this memo.
除了列出的贡献者之外，还要感谢许多个人。虽然很难提供完整的清单，但以下人员在定义协议或评论本备忘录中的规范方面特别有帮助：托马斯·查伦、理查德·多布森、山姆·哈特曼、舒勒·希思、乔纳森·霍格、卡伦·詹宁斯、克雷格·凯斯、雅切克·科尼茨尼、阿列克谢·梅尔尼科夫、基思·明克尔、，朱利安·米斯格、皮特·雷斯尼克、马歇尔·罗斯、阿列克西·谢潘、让·路易斯·塞吉诺、伊恩·希戈卡、格雷格·特罗塞尔和大卫·韦特。还感谢XMPP工作组和IETF社区的成员在本备忘录的整个生命周期中提供的意见和反馈。
Author's Address
作者地址
Peter Saint-Andre (editor) Jabber Software Foundation
Peter Saint Andre（编辑）Jabbor软件基金会
EMail: stpeter@jabber.org
EMail: stpeter@jabber.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、其代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。