- 论坛徽章:
- 0
|
Category: Standards Track October 2004
分类:标准跟踪2004年10月
Extensible Messaging and Presence Protocol (XMPP): Core
扩展消息和表示
协议
(XMPP):核心
Status of this Memo
本文状态
本文档为互联网社区描述了一种互联网标准协议,需要经过讨论和建议进行进一步的改进。请参考当前版本的“互联网官方协议标准”(STD 1)对本文描述的协议进行标准表述和状态指定。对本文的分发是不收限制的。
Copyright Notice
Copyright (C) The Internet Society (2004).
摘要
本文定义了消息扩展和表现协议的核心特性,该协议采用流方式的扩展标记语言(XML)元素以实现
网络
中任意两个端点之间近乎实时的结构化信息交互。XMPP提供了一种通用的、可扩展的XML数据交换框架,它主要用于建立实时消息和表示
应用
以满足RFC 2779中的需求。
Saint-Andre, Ed. Standards Track [Page 1]
目录
1.
简介
. . . . . . . . . . . . . . . . . . . . . . . . 2
2. 整体构架 . . . . . . . . . . . . . . . . . . 3
3. 编址
方案
. . . . . . . . . . . . . . . . . . . . . 5
4. XML流 . . . . . . . . . . . . . . . . . . . . . . . . 7
5. TLS的使用 . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. SASL的使用 . . . . . . . . . . . . . . . . . . . . . . . . 27
7. 资源绑定 . . . . . . . . . . . . . . . . . . . . . . 37
8.
服务
器回拨 . . . . . . . . . . . . . . . . . . . . . . 41
9. XML 节. . . . . . . . . . . . . . . . . . . . . . . . 48
10. XML节处理的服务器规则 . . . . . . . . . . . 58
11. XMPP中XML的使用 . . . . . . . . . . . . . . . . . . . 60
12. 核心兼容需求 . . . . . . . . . . . . . . . . 62
13. 国际化考虑 . . . . . . . . . . . . 64
14. 安全性考虑 . . . . . . . . . . . . . . . . . . 64
15. IANA 考虑 . . . . . . . . . . . . . . . . . . . . 69
16. 参考文献. . . . . . . . . . . . . . . . . . . . . . . . . 71
A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B. Resourceprep . . . . . . . . . . . . . . . . . . . . . . . . 76
C. XML 概要 . . . . . . . . . . . . . . . . . . . . . . . . 78
D. Jabber核心协议 and XMPP的区别 . . . . . 87
贡献者. . . . . . . . . . . . . . . . . . . . . . . . . . . 89
致谢. . . . . . . . . . . . . . . . . . . . . . . . . 89
作者地址 . . . . . . . . . . . . . . . . . . . . . . . . 89
完整的版权申明. . . . . . . . . . . . . . . . . . . . . 90
1. 简介
1.1. 概述
扩展消息表现协议(XMPP)是一种用于接近实时消息传递、表现以及请求响应服务的扩展标记语言。其最基本的语法和语义是从1999年左右从Jabber开源社区
发展
而来。2002年,XMPP工作组受命改进Jabber协议使其适用于IETF的即时通讯(IM)和表现
技术
。作为XMPP工作组的成果之一,本文定义了XMPP1.0的核心协议;用于提供及时消息和表现
功能
的扩展在RFC2779中进行了定义[IMP-REQS],这些扩展在扩展消息协议XMPP[XMPP-IM]中进行了说明。
Saint-Andre, Ed. Standards Track [Page 2]
2. 整体构架
2.1. 概述
尽管XMPP并不限定网络结构,但目前它通常在客户-服务器构架下实现。其中客户端 在连接[TCP]上使用XMPP访问服务器,服务器之间也通过
TCP
连接进行通讯。
下图从上层对这个结构进行了描述(其中“-”表示使用XMPP通讯,“=”表示使用其他协议进行通讯)。
C1----S1---S2---C3
|
C2----+--G1===FN1===FC1
符号含义如下:
o C1, C2, C3 =XMPP客户端
o S1, S2 = XMPP 服务器
o G1 = 用于XMPP与其他非XMPP协议网络进行转换的网关
o FN1 = 其他形式的消息网络
o FC1 = 其他形式的消息网络中客户端
2.2. 服务器
服务器是对XMPP通讯的一层智能抽象,其主要功能包括: o 为其他实体
管理
连接或会话,以XML流的形式到达或者来自验证的客户端、服务端以及其它实体
Saint-Andre, Ed. Standards Track [Page 3]
o 在实体间使用XML流对恰当编制的XML节进行
路由
(第九节)
大多数支持XMPP协议的服务器同时担当这存储用户
数据
的职责(例如 ,基于XMPP及时消息和表现应用中的用户联系人地址);这种情况下,XML数据直接有服务器代替客户端处理,并且不会被路由到其他实体中去。
2.3. 客户端
大多数客户端通过TCP与服务器进行直接连接并且使用XMPP协议来充分利用服务器以及辅助服务器所提供的所有功能。多个资源(例如,设备或者位置信息)可能同时代表各自的验证客户端向服务器发起连接。不同的资源通过XMPP地址中的资源区分(例如,vs.),这部分内容定义在编址策略中(3节)。服务器和客户端之间的推荐端口为5222,该端口号已经向IANA注册(见端口号分配(15.9节))
2.4. 网关
网关是服务器端的一个特定用途的服务,其主要功能就是将XMPP翻译成其他非XMPP消息
系统
的协议以及将返回数据转换成XMPP形式。例子有电子邮件网关(见[SMTP]),互联网中继聊天网关(见[IRC]),SIMPLE网关(见[SIMPLE]),短消息服务网关[见(SMS)],以及目前已有的及时消息服务如AIM,ICQ,MSN以及Yahoo!。网关与服务器、网关与非XMPP消息系统的通讯在本文档中未被定义。
2.5. 网络
每个服务器是通过网络地址来唯一标识的并且服务器与服务器之间的通讯是客户-服务器通讯协议的一个直接扩展,因此,在实际部署中系统是由相互通讯的服务器网络构成的。这样,
[email=%E5%8F%AF%E4%BB%A5%E4%B8%8E]可以与[/email]
之间交换消息,表示以及其他信息。这种 模式在利用网络编址标准的消息协议(如SMTP)中很常见。任意两服务器之间的通讯都是可选的。一旦激活,这种通讯可以在连接[TCP]上通过XML流进行。服务器间的推荐通讯端口为5269,该端口目前已向IANA注册(见端口分配(15.9))。
Saint-Andre, Ed. Standards Track [Page 4]
3. 编址方案
3.1. 概述
一个实体可以被认作一个网络端点(例如,一个网络ID),并且可以使用XMPP进行通讯。所有这种实体都是可以RFC 2396[URI]中的形式进行唯一编址的。由于历史的原因,XMPP实体的地址被叫做Jabber标识符或JID。一个合法的JID包含一个有序的元素集合,改集合包含域名标识,节点标识以及资源标识。
JID的语法由下面的ABNF[ABNF]范式来定义. (IPv4地址和IPv6的地址转换规则在附录B的IPv6部分定义;遵循节点规则可用字符串在节点预备简介[STRINGPREP]中定义,并作为本文档的附录A;遵循资源规则的可用字符串在资源预备简介[STRINGPREP]中定义,并作为本文档的附录B;子域规则参考[IDNA]中描述的国际化域标识。
jid = [ node "@" ] domain [ "/" resource ]
domain = fqdn / address-literal
fqdn = (sub-domain 1*("." sub-domain))
sub-domain = (internationalized domain label)
address-literal = IPv4address / IPv6address
所有JID都是基于上述结构的。该结构的最常见的用法是标识与服务器相连的即时通讯用户,以与用户相连的资源(如特殊客户端)。此外,还可能用来标记节点类型,例如,由一个多用户聊天服务器支持的特定功能聊天室可以被编址为(其中“room”是聊天室的名称,“service”是多用户聊天服务的主机名)。并且该房间的一个特定占有人被标记为(其中“nickel”是占有人的房间昵称)。也可能会有很多其他JID类型(例如,可以使服务端侧的脚本或者服务)。
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.
JID中每个可用部分长度(节点标识,域标识以及资源标识)都不能超过1023个字节,这样总长度(包含‘@’和‘/’)就不能超过3071字节。
Saint-Andre, Ed. Standards Track [Page 5]
本文来自ChinaUnix博客,如果查看原文请点:http://blog.chinaunix.net/u/29089/showart_1686220.html |
|