XMPP翻译：RFC 3920[2]（Chapter1-3）
本篇内容翻译了XMPP核心协议RFC 3920的1到3章。内容为绪论、通用的构架及编址方案。
注：
-
部分参考自蜗牛档案室
1. Introduction
//绪论
1.1 Overview
//摘要
The Extensible Messaging and Presence Protocol (XMPP) is an open Extensible Markup Language XML[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 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence [XMPP-IM].
/* XMPP是一个开放的可扩展标记语言[XML]协议，用于近实时的消息、出席与请求-响应服务。基本语法语义最初是由Jabber开源社区在1999年开发的。2002年，XMPP工作组授权开发一个Jabber协议的改写本，以适用于IETF的即时消息（IM）与出席技术。作为XMPP工作组的成果，目前的文档定义了XMPP1.0的核心性质；该扩展要提供的在RFC2779[IM-REQS]中所定义的即时消息与即时出席功能，是由XMPP：即时消息与与即时出席[XMPP-IM]指定。*/
1.2 Terminology
//术语
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].
/* 文档中的大写关键字："MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"在BCP14, 在RFC 2119 [TERMS]描述中有解释。*/
2. Generalized Architecture
//一般架构2.1 Overview
//概述
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
The symbols are as follows:
//符号表示如下：
C1, C2, C3 = XMPP clients //XMPP客户端
S1, S2 = XMPP servers //XMPP服务器
G1 = A gateway that translates between XMPP and the protocol(s) used on a foreign (non-XMPP) messaging network //网关：在XMPP与外部协议（非XMPP）的消息网络间转换
FN1 = A foreign messaging network //外部消息网络
FC1 = A client on a foreign messaging network //外部消息网络的客户端
2.2 Server
//服务器
A server acts as an intelligent abstraction layer for XMPP communications. Its primary responsibilities are:
//服务器在XMPP通信中作为一个智能的抽象层。它的主要作用是：
to manage connections from or sessions for other entities, in the form of XML streamsXML Streams to and from authorized clients, servers, and other entities
//管理连接其它实体的会话，以XML流格式在已授权的客户端、服务器以及其它实体间来回传送
to route appropriately-addressed XML stanzasXML Stanzas among such entities over XML streams
//通过XML流在实体间路由具有合适地址的XML节
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数据由服务器自身代表客户端直接处理，并不路由到其它实体。*/
2.3 Client
//客户端
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 SchemeAddressing Scheme. The RECOMMENDED port for connections between a client and a server is 5222, as registered with the IANA (see Port NumbersPort Numbers).
/* 大多数客户端通过[TCP]连接直接连到服务器，并且使用XMPP，充分利用由服务器及任何相关服务所提供的功能。多种资源（例如：设备或位置）可能代表每个被授权客户端同时连到服务器上。每个资源均由定义在地址方案（第3节）下的XMPP地址的资源标识符来区别（例如：<node@domain/home> vs. <node@domain/work>）。客户端与服务器的推荐连接端口为5222，已由IANA注册（参考端口编号（15.9节））。*/
2.4 Gateway
//网关
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]Klensin, J., Simple Mail Transfer Protocol, April 2001.), Internet Relay Chat (see [IRC]Oikarinen, J. and D. Reed, Internet Relay Chat Protocol, May 1993.), SIMPLE (see [SIMPLE]SIMPLE Working Group, SIMPLE WG, .), 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。例如EMAIL网关（参考[SMTP]），Internet Relay Chat（参考[IRC]），SIMPLE（参考[SIIMPLE]，Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions），短消息服务（SMS），遗留即时消息服务，诸如AIM，ICQ，MSN Messenger，Yahoo! Instant Messenger。网关与服务器间的通信，网关与外部消息系统间的通信，均未在此文档中定义。*/
2.5 Network
//网络
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]Klensin, J., Simple Mail Transfer Protocol, April 2001.) 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]Postel, J., Transmission Control Protocol, September 1981. connections. The RECOMMENDED port for connections between servers is 5269, as registered with the IANA (see Port NumbersPort Numbers).
/* 由于每个服务器由网络地址指定，并且由于服务器与服务器间的通信是客户与服务器协议的直接扩展，实际上，系统由互相通信的服务器网络组成。举个例子，<juliet@example.com>能与<romeo@example.net>交换消息、即时会议，以及其它信息。这是使用网络寻址标准的消息协议（例如[SMTP]）所熟悉的模式。任意两服务器间的通信是可选的。如果可通信，此类通信就应当发生在绑定到[TCP]连接的XML流上。服务器间连接的推荐端口为5269，已由IANA注册（参考端口编号（15.9节））*/
3. Addressing Scheme
//寻址方案3.1 Overview
//概述
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.
/* 一个实体可被看作是使用XMPP进行通信的一个网络端点的任何事物（例如：一个网络上的ID）。所有此类实体均以符合RFC2396[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]（Augmented Backus-Naur Form）。（Ipv4地址与Ipv6地址规则定义在[Ipv6]的附录B；符合结点规则的允许字符序列由Nodeprep profile of [STRINGPREP]定义，编入本文档的附录A；符合资源规则的允许字符序列由Resourceprep profile of [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
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/resource>形式标识一个即时消息用户、用户连接的服务器及用户连接的资源（例如：特定的客户端）。然而，结点类型可能不仅是客户端，举个例子，一个提供多用户聊天服务的特定聊天室，可以以<room@service>（“room”是聊天室名，“service”是多用户聊天服务的主机名）作为地址。并且，此聊天室的特别拥有者可能以<room@service/nick>（“nick”是此拥有者的房间昵称）作地址。许多其它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字节。*/
3.2 Domain Identifier
//域标识符
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]，Nameprep [NAMEPREP] profile of stringprep [STRINGPREP]可以无错应用。比较两个域标识符之前，服务器必须（客户端是应该）首先对标签（定义在[IDNA]）应用Nameprep profile，以补足每个标识符。*/
3.3 Node Identifier
/* 节点标识符是一个可选的辅助标识符，放在域标识符之前，后以‘@’字符分隔。它通常表示实体请求与使用由服务器或网关（例如：一个客户端）提供的网络访问，虽然它也能表示其它种类的实体（例如：有多用户聊天服务功能的聊天室）。由结点标识符表示的实体，在特定域上下文中，在XMPP即时消息与即时会议应用中被加以地址，此类地址称作“bare JID”，形式为<node@domain>。*/
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即时消息与即时会议应用中，此类地址称作“bare JID”，形式为<node@domain>。*/
A node identifier MUST be formatted such that the Nodeprep profile of [STRINGPREP] can be applied without failing. Before comparing two node identifiers, a server MUST (and a client SHOULD) first apply the Nodeprep profile to each identifier.
/*结点标识符必须格式化以使得Nodeprep profile of [STRINGPREP]可以无错应用。在比较两个结点标识符之前，服务器必须（客户端应该）首先对每个标识符应用Nameprep profile。*/
3.4 Resource Identifier
//资源标识符
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 to both servers and other clients, and is typically defined by a client implementation when it provides the information necessary to complete Resource Binding (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.
/* 资源标识符是一个可选的第三位标识符，位于域标识符之后，后跟‘/’作为分隔符。资源标识符可以更进<node@domain>地址，也可以只是纯粹的<domain>地址。它通常表示一个特别的会话、连接（例如：一个设备或位置），或属于带有节点标识符的对象（例如：在多用户聊天室的一个参与者）。当提供必要的信息来完成资源绑定（第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.
/*资源标识符必须按Resourceprep profile of [STRINGPREP]格式化，才能无错应用。比较两个资源标识符前，服务器必须（客户端应该）首先为每个标识符应用Resourceprep profile。*/
3.5 Determination of Addresses
//决定地址
After SASL negotiation and, if appropriate, Resource Binding, 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.
/*如果SASL协商（第6节）期间未指定授权身份，对服务器与服务器间的通信，初始实体的JID应当被授权身份，派生于认证身份，在SASL（Simple Authentication and Security Layer简单授权与安全层）说明[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; 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.
/*如果SASL协商（第6节）期间未指定授权身份，对客户端到服务器的通信，“bare JID”（<node@domain>）应该被授权身份，被派生于授权认证，定义在[SASL]。在资源绑定期间（第7节）“full JID”（<node@domain/resource>）的资源标识符部分应当是客户端与服务器间协商的资源标识符。*/
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。*/
XMPP翻译：RFC 3920[2]到此结束，请继续关注下一篇 XMPP翻译：RFC 3920[3]
