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

1.1. Status of this Memo/ 說(shuō)明

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.

本文檔詳細(xì)說(shuō)明了應(yīng)用于 Internet 通訊的標(biāo)準(zhǔn)協(xié)議。對(duì)于本協(xié)議的更新的一些需求討論和建議，請(qǐng)?zhí)峤划?dāng)前版本到“國(guó)際標(biāo)準(zhǔn)協(xié)議組織”。本文檔分發(fā)不受限制。

1.2. Copyright Notice/ 版權(quán)申明

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 協(xié)議的核心特性。 XMPP 是基于 XML 流元素?cái)U(kuò)展的，它旨在向兩個(gè)網(wǎng)絡(luò)終端在近乎實(shí)時(shí)的情況下交換結(jié)構(gòu)信息。 XMPP 也提供了一個(gè)沒(méi)有顯著特點(diǎn)的，可擴(kuò)展的 XML 數(shù)據(jù)交換的框架結(jié)構(gòu)模型。在 RFC 2779 標(biāo)準(zhǔn)定義的需求下，它應(yīng)用于建立即時(shí)通訊和即時(shí)會(huì)議的應(yīng)用程序。

1.4. Table of Contents/ 目錄

1.?????? Introduction/ 簡(jiǎn)介

2.?????? Generalized Architecture/ 通用的結(jié)構(gòu)

3.?????? Addressing Scheme/ 地址配置

4.?????? XML Streams/ XML 流

5.?????? Use of TLS/ TSL 的應(yīng)用

6.?????? Use of SASL?/ SASL 的應(yīng)用

7.?????? Resource Binding?/ 資源綁定 ?

8.?????? Server Dialback?/ 服務(wù)回叫

9.?????? XML Stanzas?/ XML 節(jié)

10.??? Server Rules for Handling XML Stanzas?/?XML 操作的服務(wù)規(guī)則 ?

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

12.??? Core Compliance Requirements?/?? 核心需求

13.??? Internationalization Considerations?/ 國(guó)際化考慮 ?

14.??? Security Considerations?/ 安全考慮 ?

15.??? IANA Considerations / IANA 考慮

16.??? References / 參考文獻(xiàn)

17.??? Nodeprep / 節(jié)點(diǎn)命名

·???????? B. Resourceprep / 資源命名

·???????? C. XML Schemas / XML 計(jì)劃

·???????? D. Differences Between Core Jabber Protocols and XMPP / JABBER 和 XMPP 核心協(xié)議的區(qū)別

?????? ·???????? Contributors/ 貢獻(xiàn)者

·???????? Acknowledgements/ 知識(shí)準(zhǔn)備

·???????? Author's Address/ 作者地址

·???????? Full Copyright Statement/ 版權(quán)申明????????????? 待續(xù).........

1.4?? 1. Introduction/簡(jiǎn)介

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是一個(gè)開(kāi)放的基于xml的 提供 近乎實(shí)時(shí)消息、現(xiàn)場(chǎng)勘察和請(qǐng)求應(yīng)答服務(wù)的協(xié)議。它最初是由jabber開(kāi)源社區(qū)在大約 1999年發(fā)起并一直領(lǐng)導(dǎo)的即時(shí)消息的實(shí)時(shí)系統(tǒng)，在2002年，xmpp WG 。作為xmppWG的工作結(jié)果，當(dāng)前備忘錄定義了xmpp1.0的核心特征;在 這個(gè)擴(kuò)展部要求提供定義在<<rfc 2779>>的即時(shí)消息和現(xiàn)場(chǎng)勘察功能，是列在xmpp 中: [xmpp-im]。

1.4? 1.2 Terminology/術(shù)語(yǔ)

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

下面大寫(xiě)的關(guān)鍵字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "REC OMMENDED", "MAY", and "OPTIONAL" 在這篇文檔中的意義 請(qǐng)參見(jiàn)RFC 2119

1.4 ?2. Generalized Architecture/通用的結(jié)構(gòu)

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不想與任何特殊的網(wǎng)絡(luò)體系機(jī)構(gòu)相結(jié)合，但它通常是基于c/s架構(gòu)的， 其中一個(gè)客戶(hù)端通過(guò)一個(gè)tcp連接按著 xmpp 訪(fǎng)問(wèn)一個(gè)服務(wù)器， 服務(wù)器同樣也是 通過(guò)tcp與其它實(shí)體通信。

下面的圖表提供了這個(gè)體系機(jī)構(gòu)的高層視圖(--代表用xmpp進(jìn)行通信，=代表是 其它協(xié)議進(jìn)行通信 )。

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

• |

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

·C1,C2,C3 代表 XMPP客戶(hù)端

·S1,S2代表XMPP服務(wù)器

·G1代表一個(gè)網(wǎng)關(guān)，它XMPP和 其它外部(非xmpp)消息網(wǎng)絡(luò)之間的翻譯。

·FN1 代表一個(gè)外部消息網(wǎng)絡(luò)

·FC1 代表一個(gè)外部消息網(wǎng)絡(luò)的客戶(hù)端。???????????????????????????????? 待續(xù).........

?

1.4? 2.2. Server/服務(wù)器

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.

一個(gè)服務(wù)擔(dān)當(dāng)一個(gè)XMPP通信的智能提取層，這主要負(fù)責(zé)：

·管理一個(gè)來(lái)自其它通信實(shí)體的以xml流方式的連接或會(huì)話(huà)， 它可以來(lái)自于授權(quán)的客戶(hù)端、服務(wù)器、或者其它通信實(shí)體

·路由在基于xml流實(shí)體中具有正確地址的xml節(jié)( 第九節(jié))

大多數(shù)的支持xmpp的服務(wù)器也可能為用戶(hù)擔(dān)任數(shù)據(jù)存儲(chǔ)的職責(zé)( 如用戶(hù)的聯(lián)系列表);既然這樣，服務(wù)器代表用戶(hù)直接處理xml數(shù)據(jù)，而不被路由到另一個(gè)實(shí)體。

1.4? 2.3 Client/客戶(hù)端

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

大多數(shù)的客戶(hù)端直接通過(guò)tcp與服務(wù)器連接，用XMPP協(xié)議充分利用一個(gè)服務(wù)和任何相關(guān)的服務(wù)提供的功能。多個(gè)的資源(如設(shè)備或地區(qū))可能同時(shí)連接到一個(gè)服務(wù)器，各自代表的一個(gè)授權(quán)的客戶(hù)，它們通過(guò)XMPP地址(如 <node@domain/home> 和 <node@domain/work>)的resource標(biāo)識(shí)符來(lái)區(qū)別。推薦的連接端口為5222, 它已向IANA注冊(cè)。

1.4 ?2.4 Gateway/網(wǎng)關(guān)

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.

一個(gè)網(wǎng)關(guān)是服務(wù)器上的一個(gè)具有特殊目的的服務(wù)。它主要的功能是與外部消息系統(tǒng)通信時(shí)，將xmpp數(shù)據(jù)翻譯成該系統(tǒng)的協(xié)議數(shù)據(jù)，同是將該系統(tǒng)返回的數(shù)據(jù)翻譯成xmpp數(shù)據(jù)。例如email, irc, SIMPLE,SMS, 和其它的即時(shí)消息如 AIM,ICQ, MSN Messenger, Yahoo!.網(wǎng)關(guān)與服務(wù)器之間的通信 和 網(wǎng)關(guān)與外部消息系統(tǒng)之間 的通信的定義不在這篇文檔中。

1.4 ?2.5 ?Network/網(wǎng)絡(luò)

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

因?yàn)槊恳粋€(gè)服務(wù)器都可以通過(guò)一個(gè)網(wǎng)絡(luò)地址來(lái)標(biāo)識(shí)，同時(shí)因?yàn)榉?wù)器之間的通信是客戶(hù)端與服務(wù)器之間的通信協(xié)議的一個(gè)直接的擴(kuò)展，在實(shí)踐中，系統(tǒng)由交互通信的服務(wù)器網(wǎng)絡(luò)組成。因此，例如< juliet@example.com >能夠與< romeo@example.net > 交換消息、現(xiàn)場(chǎng)勘察和其它信息。這種模式在使用網(wǎng)絡(luò)地址標(biāo)準(zhǔn)的消息通信協(xié)議 (如SMTP)中是常見(jiàn)的，任何兩個(gè)通信是可選的。如開(kāi)啟，那么通信在基于xml流上發(fā)生，它一定要建立TCP連接。推薦的連接端口為5269, 它已向IANA注冊(cè)。

1.4 ?3. Addressing Scheme/地址配置

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

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.

一個(gè)實(shí)體可以是任何網(wǎng)絡(luò)端點(diǎn)(如網(wǎng)絡(luò)中的一個(gè)ID)并能夠用XMPP通信的事 物。 所有這一類(lèi)的實(shí)體可以唯一編址的，并符合[RFC 2396 [URI]]風(fēng)格。 因?yàn)闅v史原因，一個(gè)XMPP實(shí)體的地址被叫做Jabber標(biāo)識(shí)符或JID。一個(gè)有效的JID包括三個(gè)部分：域標(biāo)識(shí)符，節(jié)點(diǎn)標(biāo)識(shí)符和資源標(biāo)識(shí)符

JID語(yǔ)法使用[ABNF]表達(dá)式定義。(IPv4地址和IPv6地址的規(guī)則的定義在附錄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都是基于上述結(jié)構(gòu)中的。這個(gè)結(jié)構(gòu)大多是用來(lái)標(biāo)識(shí)一個(gè)即時(shí)消息通信的用戶(hù)，在服務(wù)器上有哪幾個(gè)連接，及用戶(hù)的連接資源以<user@host/resource> 的形式. 可是,節(jié)點(diǎn)的類(lèi)型可能不是客戶(hù)端;例如一個(gè)聊天室提供多用戶(hù)聊天服務(wù)，它的地址可以可以是<room@service>( “room”是 聊天室的名字，"service"是提供多用戶(hù)聊天服務(wù)的主機(jī)名) 。或者一個(gè)聊天室中的 某個(gè)用戶(hù)被編址為<room@service/nick> ( "mick"是該用戶(hù)在聊天室中的昵稱(chēng)). 具有多個(gè)其它JID類(lèi)型是可能的(如<domain/resource>可以是一個(gè)服務(wù)器端的 script或服務(wù))。

一個(gè)JID的每一部分(域標(biāo)識(shí)符，節(jié)點(diǎn)標(biāo)識(shí)符和資源標(biāo)識(shí)符)的長(zhǎng)度都不能超過(guò)1023 個(gè)字節(jié)，從而總字節(jié)數(shù)(包括"@"和"/")不能超過(guò)3071個(gè)字節(jié)。

???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 待續(xù)......