RFC 3920 之 XMPP

1、Extensible Messaging and Presence Protocol (XMPP): Core

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

本文档详细说明了应用于Internet通讯的标准协议。对于本协议的更新的一些需求讨论和建议，请提交当前版本到“国际标准协议组织”。本文档分发不受限制。

1.2. Copyright Notice/版权申明

Copyright (C) The Internet Society (2004).

1.3. 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数据交换的框架结构模型。在RFC 2779标准定义的需求下，它应用于建立即时通讯和即时会议的应用程序。

1.4. Table of Contents/目录

1. Introduction/简介

2. Generalized Architecture/ 通用的结构

3. Addressing Scheme/ 地址配置

4. XML Streams/ XML流

5. Use of TLS/ TSL的应用

6. Use of SASL/ SASL的应用

7. Resource Binding/ 资源绑定

8. Server Dialback/ 服务回叫

9. XML Stanzas/ XML节

10. Server Rules for Handling XML Stanzas/XML操作的服务规则

11. XML Usage within XMPP/ XMPP的XML用法

12. Core Compliance Requirements/核心需求

13. Internationalization Considerations/ 国际化考虑

14. Security Considerations/ 安全考虑

15. IANA Considerations / IANA考虑

16. References / 参考文献

17. Nodeprep / 节点命名

· B. Resourceprep / 资源命名

· C. XML Schemas / XML计划

· D. Differences Between Core Jabber Protocols and XMPP / JABBER和XMPP核心协议的区别

· Contributors/ 贡献者

· Acknowledgements/ 知识准备

· Author's Address/ 作者地址

· Full Copyright Statement/ 版权申明 待续.........

/

/

/

/

1.4 1. Introduction/简介

1.4 1.1 Overview/综述

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 WG 。作为xmppWG的工作结果，当前备忘录定义了xmpp1.0的核心特征;在 这个扩展部要求提供定义在<<rfc 2779>>的即时消息和现场勘察功能，是列在xmpp 中: [xmpp-im]。

1.4 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", and "OPTIONAL" 在这篇文档中的意义 请参见RFC 2119

/

/

/

1.4 2. Generalized Architecture/通用的结构

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

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

C1---S1---S2--C3

• |

C2---+---G1==============FN1==================FC1

The symbols are as follows:

·C1, C2, C3 = XMPP clients

·S1, S2 = XMPP servers

·G1 = A gateway that translates between XMPP and the protocol(s)

used on a foreign (non-XMPP) messaging network

·FN1 = A foreign messaging network

·FC1 = A client on a foreign messaging network

尽管xmpp不想与任何特殊的网络体系机构相结合，但它通常是基于c/s架构的， 其中一个客户端通过一个tcp连接按着 xmpp 访问一个服务器， 服务器同样也是 通过tcp与其它实体通信。

下面的图表提供了这个体系机构的高层视图(--代表用xmpp进行通信，=代表是 其它协议进行通信 )。

C1---S1---S2--C3

• |

C2---+---G1==============FN1==================FC1

·C1,C2,C3 代表 XMPP客户端

·S1,S2代表XMPP服务器

·G1代表一个网关，它XMPP和 其它外部(非xmpp)消息网络之间的翻译。

·FN1 代表一个外部消息网络

·FC1 代表一个外部消息网络的客户端。 待续.........

1.4 2.2. Server/服务器

A server acts as an intelligent abstraction layer for XMPP communications. Its primary responsibilities are:

·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

·to route appropriately-addressed XML stanzas (Section 9) among such entities over XML streams

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通信的智能提取层，这主要负责：

·管理一个来自其它通信实体的以xml流方式的连接或会话， 它可以来自于授权的客户端、服务器、或者其它通信实体

·路由在基于xml流实体中具有正确地址的xml节( 第九节)

大多数的支持xmpp的服务器也可能为用户担任数据存储的职责( 如用户的联系列表);既然这样，服务器代表用户直接处理xml数据，而不被路由到另一个实体。

1.4 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 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/home> 和 <node@domain/work>)的resource标识符来区别。推荐的连接端口为5222, 它已向IANA注册。

1.4 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]), 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数据。例如email, irc, SIMPLE,SMS, 和其它的即时消息如 AIM,ICQ, MSN Messenger, Yahoo!.网关与服务器之间的通信 和 网关与外部消息系统之间 的通信的定义不在这篇文档中。

1.4 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, <[e-mail]> is able to exchange messages, presence, and other information with <[e-mail]>. 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)).

因为每一个服务器都可以通过一个网络地址来标识，同时因为服务器之间的通信是客户端与服务器之间的通信协议的一个直接的扩展，在实践中，系统由交互通信的服务器网络组成。因此，例如<[e-mail]>能够与<[e-mail]> 交换消息、现场勘察和其它信息。这种模式在使用网络地址标准的消息通信协议 (如SMTP)中是常见的，任何两个通信是可选的。如开启，那么通信在基于xml流上发生，它一定要建立TCP连接。推荐的连接端口为5269, 它已向IANA注册。

/

/

/

1.4 3. Addressing Scheme/地址配置

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

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

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.

一个实体可以是任何网络端点(如网络中的一个ID)并能够用XMPP通信的事 物。 所有这一类的实体可以唯一编址的，并符合[RFC 2396 [URI]]风格。 因为历史原因，一个XMPP实体的地址被叫做Jabber标识符或JID。一个有效的JID包括三个部分：域标识符，节点标识符和资源标识符

JID语法使用[ABNF]表达式定义。(IPv4地址和IPv6地址的规则的定义在附录B [IPv6] 中

jid = [ node "@" ] domain [ "/" resource ]

domain = fqdn / address-literal

fqdn = (sub-domain 1*("." sub-domain))

sub-domain = (internationalized domain label)

address-literal = IPv4address / IPv6address

所有的JID都是基于上述结构中的。这个结构大多是用来标识一个即时消息通信的用户，在服务器上有哪几个连接，及用户的连接资源以<user@host/resource> 的形式. 可是,节点的类型可能不是客户端;例如一个聊天室提供多用户聊天服务，它的地址可以可以是<room@service>( “room”是 聊天室的名字，"service"是提供多用户聊天服务的主机名) 。或者一个聊天室中的 某个用户被编址为<room@service/nick> ( "mick"是该用户在聊天室中的昵称). 具有多个其它JID类型是可能的(如<domain/resource>可以是一个服务器端的 script或服务)。

一个JID的每一部分(域标识符，节点标识符和资源标识符)的长度都不能超过1023 个字节，从而总字节数(包括"@"和"/")不能超过3071个字节。

待续.........

<!-- Search Google -->

输入您的搜索字词 提交搜索表单

<!-- google_ad_client = "pub-7330597899926046"; google_ad_format = "350x30_sdo"; google_link_target = 2; google_color_bg = "ffffff"; google_color_link = "000000"; google_encoding = "GB2312"; //-->

<!-- Search Google --> <!-- google_ad_client = "pub-7330597899926046"; google_ad_slot = "8791774696"; google_ad_width = 468; google_ad_height = 60; //-->