XMPP协议中文版

RFC3920可扩展的消息和出席信息协议(XMPP):核心协议关于本文的说明本文为互联网社区定义了一个互联网标准跟踪协议，并且申请讨论协议和提出了改进的建议。请参照“互联网官方协议标准”的最新版本（STD1）获得这个协议的标准化进程和状态。本文可以不受限制的分发。版权声明本文版权属于互联网社区(C)TheInternetSociety(2004).摘要本文定义了可扩展消息和出席信息协议（XMPP）的核心功能，这个协议采用XML流实现在任意两个网络终端接近实时的交换结构化信息。XMPP提供一个通用的可扩展的框架来交换XML数据，它主要用来建立即时消息和出席信息应用以实现RFC2779的需求。目录1.绪论2.通用的架构3.地址空间4.XML流5.TLS的使用6.SASL的使用7.资源绑定8.服务器回拨9.XML节10.服务器处理XML节的规则11.XMPP中的XML用法12.核心的兼容性要求13.国际化事项14.安全性事项15.IANA事项16.参考1.绪论1.1.概览XMPP是一个开放式的XML协议，设计用于准实时消息和出席信息以及请求-响应服务。其基本的语法和语义最初主要是由Jabber开放源代码社区于1999年开发的。2002年，XMPP工作组被授权接手开发和改编Jabber协议以适应IETF的消息和出席信息技术。作为XMPP工作组的成果，本文定义了XMPP1.0的核心功能；在RFC2779[IMP-REQS]中指定的提供即时消息和出席信息功能的扩展，定义在XMPP-IM协议[theExtensibleMessagingandPresenceProtocol(XMPP):InstantMessagingandPresence]中。1.2.术语本文中大写的关键字MUST,MUSTNOT,REQUIRED,SHALL,SHALLNOT,SHOULD,SHOULDNOT,RECOMMENDED,MAY,和OPTIONAL的确切含义符合BCP14,RFC2119[TERMS].2.通用的架构2.1.概览尽管XMPP没有结合任何特定的网络结构，通常认为它是客户-服务器架构的一种实现，在这里客户端用XMPP的方式访问服务器采用的是TCP连接，服务器之间的通信也是TCP连接。以下是这一架构的抽象的示意图(这里-表示使用XMPP通讯，=表示可使用任何协议通讯)。C1----S1---S2---C3|C2----+---G1===FN1===FC1符号代表的意思如下:C1,C2,C3=XMPP客户端S1,S2=XMPP服务器G1=一个XMPP和外部（非XMPP）消息网络之间进行“翻译”的网关FN1=一个外部消息网络FC1=外部消息网络上的一个客户端2.2.服务器服务器充当XMPP通信的一个智能抽象层，它主要负责：管理发出的连接或其他实体的会话，在XML流（第四章）的表单中接收和发送给授权的客户端，服务器和其他实体。用XML流通过实体转发特定地址的XML消息（第九章）大部分XMPP兼容的服务器也负责存储客户端使用的数据(比如基于XMPP应用的联系人名单);在这种情况下，XML数据直接由服务器代替客户端处理而不需要转发到其他实体。2.3.客户端大部分客户端通过TCP连接直接连到服务器，并通过XMPP获得由服务器和任何相关的服务所提供的全部功能。多个不同资源（比如不同的设备和地点）的客户端可以同时登陆并且并发的连接到一个服务器，每个不同资源的客户端通过XMPP地址的资源标识符来区分（比如node@domain/home和node@domain/work），参见地址空间（第三章）。__建议__的客户端和服务器连接的端口是5222，这个端口已经在IANA（在第十五章第九节查阅端口号码）注册了。.2.4.网关网关是一个特殊用途的服务器端的服务，主要功能是把XMPP翻译成外部(非XMPP)消息系统，并把返回的消息翻译成XMPP。例如到email（参见[SMTP]），IRC（参见[IRC]），SIMPLE（参见[SIMPLE]），SMS的网关；还有和别的消息服务的网关，比如AIM，ICQ，MSNMessenger，Yahoo!InstantMessenger。网关和服务器之间的通信，网关和外部消息系统的通信，不在本文描述范围之内。2.5.网络因为每个服务器都是由一个网络地址来标识的并且服务器之间的通信是客户-服务器协议的直接扩展，实际上整个系统是由很多互通的服务器构成的。例如，[e-mail]可以和[e-mail]交换消息,出席信息和其他信息。这种模式常见于那些需要使网络地址标准化的协议（比如SMTP）。任意两个服务器之间的通信是可选（OPTIONAL）的。如果被激活，那么这种通信应该（SHOULD）通过XML流绑定到TCP连接上进行。建议的（RECOMMENDED）服务器之间的连接端口为5269，这个端口号已经在IANA（在第十五章第九节查阅端口号码）注册了。3.地址空间3.1.概览一个实体可以是任何一个被认为是一个网络端点的东西(例如网络上的一个ID)，而且它是通过XMPP进行通信的。所有这些实体都有一个具有唯一性的地址，并符合RFC2396[URI]规范要求的格式。由于历史原因，一个XMPP实体的地址被称为JabberIdentifier或JID。一个合法的JID包括一组排列好的元素，包括域名（domainidentifier），节点名（nodeidentifier），和资源名（resourceidentifier）。JID的语法定义，使用[ABNF]中的AugmentedBackus-Naur格式。（IPv4地址和IPv6地址规则在附录B中的[IPv6]中定义；确定节点规则的合法字符顺序由附录A的[STRINGPREP]的Nodeprep部分来定义；确定资源规则的合法字符顺序由附录B的[STRINGPREP]的Resourceprep部分来定义；子域名规则参考[IDNA]中关于国际域名标签的描述。）。jid=[node@]domain[/resource]domain=fqdn/address-literalfqdn=(sub-domain1*(.sub-domain))sub-domain=(internationalizeddomainlabel)address-literal=IPv4address/IPv6address所有JID都是基于上述的结构。类似user@host/resource这种结构，最常用来标识一个即时消息用户，这个用户所连接的服务器，以及这个用户用于连接的资源（比如特定类型的客户端软件）。不过,节点类型不是客户端也是有可能的，比如一个用来提供多用户聊天服务的特定的聊天室，地址可以是room@service（这里“room“是聊天室的名字而”service“是多用户聊天服务的主机名），而加入了这个聊天室的某个特定的用户的地址则是room@service/nick（这里”nick“是用户在聊天室的昵称）。许多其他的JID类型都是可能的（例如domain/resource可能是一个服务器端的脚本或服务）。一个JID的每个合法部分（节点名，域名，资源名）的长度不能（MUSTNOT）超过1023字节。也就是整体长度（包括'@'和'/'）不能超过3071字节。3.2.域名域名是一个主要的ID并且是JID中唯一必需（REQUIRED）的元素（一个纯粹的域名也是一个合法的JID）。它通常代表网络的网关或者“主”服务器，其他实体通过连接它来实现XML转发和数据管理功能。然而，由一个域名标识引用的实体，并非总是一个服务器，它也可能是一个服务器的子域地址，提供额外的功能（比如多用户聊天服务，用户目录，或一个到外部消息系统的网关）。每个服务器或者服务的域名，可以（MAY）是一个IP地址，但应该（SHOULD）是一个完全合法的域名(参见[DNS]).一个域名ID必须(MUST)是[IANA]里定义的“国际化域名”，并且按[STRINGPREP]中的[NAMEPREP]profile进行成功的字符转换。在比较两个域名ID之前，服务器必须(MUST),客户端应该(SHOULD)首先按照Nameprepprofile(定义在[IANA]中)来转换每个域名的字符。3.3.节点名节点名是一个可选（OPTIONAL）的第二ID，放在域名之前并用符号@分开.它通常表示一个向服务器或网关请求和使用网络服务的实体(比如一个客户端),当然它也能够表示其他的实体(比如在多用户聊天系统中的一个房间).节点名所代表的实体，它的地址依赖于一个特定的域名;在XMPP的即时消息和出席信息应用系统中，这个地址是“纯JID”node@domain中的一部分。一个节点名必须按[STRINGPREP]中的Nodeprepprofile进行成功的字符转换。在比较两个节点ID之前，服务器必须（MUST）,客户端应该(SHOULD)首先按Nodeprepprofile转换每个ID的字符。3.4.资源名资源名是一个可选的第三ID,它放在域名的后面并由符号/分开。资源名可以跟在node@domain后面也可以跟在domain后面。它通常表示一个特定的会话，连接（比如设备或者所在位置），或者一个附属于某个节点ID实体相关实体的对象（比如多用户聊天室中的一个参加者）。对于服务器和和其他客户端来说，资源名是不透明的。当它提供必需的信息以完成资源绑定（参见第七章）的时候，通常是由客户端来实现的（尽管可以由客户端向服务器请求完成），然后显示为“已连接的资源”。一个实体可以(MAY)并发维护多个已连接的资源。每个已连接的资源由不同的资源ID来区分。一个资源名必须（MUST）按[STRINGPREP]中的Resourceprepprofile进行成功的格式化。在比较两个资源ID之前，服务器必须（MUST）,客户端应该(SHOULD)首先按Resourceprepprofile转换每个ID的字符。3.5.地址的确认在SASL（见第六章）握手之后（如果必要的话，也在资源绑定（见第七章）之后），正在接收流信息的实体必须（MUST）确认初始实体的ID。对于服务器间的通信，在SASL握手时，如果没有指明授权的ID，这个初始的实体应该（SHOULD）是经过认证实体（参见简单认证和安全层协议[SASL]中的定义）授权的ID（见第六章）。对于客户端和服务器的通信，在SASL握手时，如果没有指明授权的ID，“纯JID”(node@domain)应该（SHOULD）是经过认证实体（参见[SASL]中的定义）授权的ID，“全JID”(node@domain/resource)的资源ID部分应该（SHOULD）是由客户端和服务器在资源绑定的时候商定的（参见第七章）。接收的实体必须（MUST）确保结果JID（包括节点名，域名，资源名以及分隔符）与本章前面部分描述的规则和格式相一致；为了满足这些约束条件，接收实体可能（MAY）需要把初始实体的发送方JID替换成接收实体认可的规范JID。4.XML流4.1.概览两个基本概念，XML流和XML节，使得在出席信息已知的实体之间，异步交换低负载的结构化信息成为可能。这两个术语定义如下：XML流的定义：一个XML流是一个容器，包含了两个实体之间通过网络交换的XML元素。一个XML流是由一个XML打开标签stream(包含适当的属性和名字空间声明)开始的,流的结尾则是一个XML关闭L标签/stream。在流的整个生命周期，初始化它的实体可以通过流发送大量的XML元素，用于流的握手(例如TLS握手(第五章)或SASL握手(第六章))或XML节（在这里指符合缺省名字空间的元素,包括message/,presence/,或iq/元素）。“初始的流”由初始化实体（通常是一个客户端或服务器）和接收实体（通常是一个服务器）握手，从接收实体来看，它就是那个初始实体的会话.初始化