XMPP协议中文版Word文件下载.docx
《XMPP协议中文版Word文件下载.docx》由会员分享，可在线阅读，更多相关《XMPP协议中文版Word文件下载.docx（72页珍藏版）》请在冰点文库上搜索。
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.网络
因为每个服务器都是由一个网络地址来标识的并且服务器之间的通信是客户-服务器协议的直接扩展，实际上整个系统是由很多互通的服务器构成的。
例如，<
juliet@>
可以和<
romeo@>
交换消息,出席信息和其他信息。
这种模式常见于那些需要使网络地址标准化的协议（比如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-literal
fqdn=（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,它放在域名的后面并由符号"
分开。
资源名可以跟在<
后面也可以跟在<
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”（<
）应该（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/>
元素）。
“初始的流”由初始化实体（通常是一个客户端或服务器）和接收实体（通常是一个服务器）握手，从接收实体来看，它就是那个初始实体的"
会话"
.初始化流允许从初始化实体到接收实体的单向通信;
为了使接收实体能够和初始实体交换信息,接收实体必须发起一个反向的握手（应答流）.
XML节的定义:
一个XML节是一个实体通过XML流向另一个实体发送的结构化信息中的一个离散的语义单位。
一个XML直接存在于根元素<
stream/>
的下一级，并且如果这样就能够满足[XML]内容的production43,那么它被认为是均衡的.任何XML节都是从一个XML流的下一级的某个打开标签（如<
presence>
）开始，到相应的关闭标签（如<
/presence>
一个XML节可以（MAY）包含子元素（相关的属性,元素,和XML字符数据等）以表达完整的信息.在这里定义的XML节仅限于<
<
和<
元素，具体描述见XMLStanzas（第九章）；
为TLS握手（第五章）、SASL握手（第六章）、服务器回拨（第八章）的需要而发送的XML元素，不被认为是一个XML节。
设想一个客户端和服务器会话的例子。
为了连接一个服务器，一个客户端必须（MUST）发送一个打开标签<
给服务器，初始化一个XML流，也可选择（OPTIONAL）在这之前发送一段文本声明XML版本和支持的字符集（参见文本声明的内容（第十一章第四节）;
也可看字符编码（第十一章第五节））。
视本地化策略和提供的服务而定，服务器应该（SHOULD）回复一个XML流给客户端，同样的，也可选择在这之前发送一段文本声明。
一旦客户端完成了SASL握手（第六章），客户端可以（MAY）通过流发送不限量的XML节给网络中的任何接收者。
当客户端想关闭这个流，它只需要简单的发送一个关闭标签<
给服务器（或者作为另一个选择，可能由服务器关闭这个流）。
然后，客户端和服务器都应该（SHOULD）彻底地终止这个连接（通常是一个TCP连接）。
那些习惯认为XML是一个以文本为中心风格的人可能希望看看一个与服务器连接的客户端会话，包含两个打开-关闭XML文档：
一个是从客户端到服务器，一个是从服务器到客户端。
下图中，根元素<
可以被认为是每个“文档”的文档实体，这两个“文档”通过累积那些在XML上传输的XML节来搭建的。
无论如何，下图只是方便理解；
实际上XMPP并不处理文档而是处理XML流和XML节。
基本上，一个XML流相当于一个会话期间所有XML节的一个信封。
我们可以简单的把它描述成下图：
|----------------------------
|<
show/>
messageto='
foo'
>
body/>
/message>
iqto='
bar'
query/>
/iq>
|…
4.2.绑定到TCP
虽然有很多非必需的连接使用XML流来绑定[TCP]连接（两个实体可以通过别的机制来互联，比如通过[HTPP]连接轮询），本规范只定义了XMPP到TCP的绑定。
在客户和服务器通信的过程中，服务器必须（MUST）允许客户端共享一个TCP连接来传输XML节，包括从客户端传到服务器和从服务器传到客户端。
在服务器之间的通信过程中，服务器必须（MUST）用一个TCP连接向对方发送XML节，另一个TCP连接（由对方初始化）接收对方的XML节，一共两个TCP连接。
4.3.流的安全
在XMPP1.0中，当XML流开始握手时，TLS应该（SHOULD）按第五章：
TLS的使用中的规定来使用，SASL必须（MUST）按第六章：
SASL的使用中的规定来使用。
尽管可能（MAY）存在某种共有的机制能够保证双向安全，但是“初始化流”（比如从初始化实体发给接收实体的流）和“应答流”（比如从接收实体发给初始化实体的流）还是必须（MUST）安全的分开。
在流被验证之间，实体不应该（SHOULDNOT）尝试通过流发送XML节（第九章）；
就算它这样做了，对方的实体也不能（MUSTNOT）接受这些XML节，并且应该（SHOULD）返回一个<
not-authorized/>
的流错误信息并且终止当前TCP连接上双方的XML流；
注意，这仅仅是针对XML节（包含在缺省命名空间中的<
元素），而不是指那些用于TLS握手（第五章）、SASL握手（第六章）握手的流。
4.4.流属性
流元素的属性如下:
∙to--'
to'
属性应该（SHOULD）仅用于从初始化实体到接收实体的XML流的头，并且必须（MUST）设成为接收实体提供服务的主机名。
注意，不应该（SHOULDNOT）有'
属性出现在接收实体应答初始实体的XML流的头中；
无论如何，如果'
属性出现在应答流中，初始化实体应该（SHOULD）忽略它。
∙from--'
from'
属性应该（SHOULD）仅用于接收实体应答初始化实体的XML流的头，并且必须（MUST）设成为接收实体（正在给初始实体授权）提供服务的主机名。
属性出现在初始实体发送给接收实体的XML流的头中；
属性出现在初始化流中，接收实体应该（SHOULD）忽略它。
∙id--'
id'
属性应该（SHOULD）仅用于接收实体发送给初始化实体XML流的头。
这个属性是一个由接收实体创建的具有唯一性的ID,一个初始实体和接收实体之间的会话ID，并且它在接收方的应用程序中（通常是一个服务器）必须（MUST）是唯一的。
注意，这个流ID必须是足够安全的，所以它必须是不可预知的和不可重复的（参见RANDOM了解如何获得随机性以保证安全性）。
不应该（SHOULDNOT）有'
∙xml:
lang--'
xml:
lang'
属性（定义在[XML]中的第二章第十二节）应该（SHOULD）包含在初始化实体发给接收实体的XML流的头中，以指定在流中传输的可读XML字符所使用的缺省语言。
如果这个属性出现了，接收实体应该（SHOULD）记住它的值，作为初始化流和应答流的缺省属性；
如果这个属性没有出现，接收实体应该（SHOULD）用一个可配置的缺省值用于双方的流，这个属性值必须（MUST）在应答流的头中传达。
对于所有初始化流中传输的节，如果初始实体没有提供'
属性，接收实体应该（SHOULD）应用缺省值；
如果初始实体提供了'
属性，接收实体不能（MUSTNOT）修改或删除它（参见第九章第一节第五小节xml:
lang）。
'
属性的值必须（MUST）是一个NMTOKEN（定义在[XML]的第二章第三节）并且必须（MUST）遵守RFC3066[LANGTAGS]规定的格式。
∙version--version属性（最少需要"
1.0"
）为本规范中和流相关的协议提供了支持。
关于这个属性的生成和处理的详细规则将在下文中定义。
我们现在可以总结如下:
初始化方发给接收方
接收方发给初始化方
to
接收方的主机名
忽略
from
id
会话键值
lang
缺省语言
version
支持XMPP1.0
4.4.1.版本支持
在这里XMPP的版本是"
；
准确地说，这里囊括了和流相关的所有协议（TLS的使用（第五章）,SASL的使用（第六章）,和流错误（第四章第七节）），以及三个定义好的XML节类型（<
和<
XMPP版本号的编号顺序是“<
主版本号>
.<
副版本号>
”。
主版本和副版本号必须（MUST）是独立的整数并且每个号码可以（MAY）单独以阿拉伯数字增长。
这样，"
XMPP2.4"
的版本将比"
XMPP2.13"
更低。
号码前面的“0”（比如XMPP6.01）必须（MUST）被接收方忽略并且不能（MUSTNOT）被发送出去.
如果流和节的格式或者必需的处理方式有了显著的改变，以至于老版本的实体如果只是简单的忽略它不理解的节和属性并且继续像老版本一样的处理方式，会使得老版本的实体不能够和新版本的实体交互，只有在这时候主版本号才应该（SHOULD）增加。
副版本号显示新的性能，它必须（MUST）被副版本号更低的实体忽略，但被高（副）版本号的实体用于了解信息。
例如，一个副版本号显示处理某种新定义的"
type"
属性的值（用于message,presence或IQ节）的能力；
副版本号高的实体将会了解到与之通信的对方不能够理解这个"
属性的值，所以将不会发送它。
以下规则是用于'
版本'
属性在实现流的头信息时如何生成和处理:
1.初始化实体必须（MUST）在初始化流的头信息中把'
的值设置成它所支持的最高版本。
（比如，如果最高版本支持就是本规范，那么它必须（MUST）设置成"
）.
2.接收实体必须（MUST）在应答流的头信息中把'
的值设置成初始化实体所提供的版本或它所支持的最高版本,取其中版本号较低的那一个。
接收实体必须（MUST）把主版本号和副版本号作为数字来比较,而不是对"
主版本号.副版本号"
这个字符串进行比较.
3.如果在应答流的头信息的版本号中至少有一个主版本号低于初始化流的头信息的版本号,并且如前所述,新版本的实体不能够和旧版本实体交互,初始化实体应该（SHUOULD）生成一个<
unsu
升级会员 