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", "REC OMMENDED", "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, < 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)中是常見的，任何兩個通信是可選的。如開啟，那么通信在基于xml流上發生，它一定要建立TCP連接。推薦的連接端口為5269, 它已向IANA注冊。

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.

一個實體可以是任何網絡端點(如網絡中的一個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個字節。

???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 待續......