TC11WG1037即时通信系统互联互通和服务质量规范讨论稿Word文件下载.docx
《TC11WG1037即时通信系统互联互通和服务质量规范讨论稿Word文件下载.docx》由会员分享，可在线阅读，更多相关《TC11WG1037即时通信系统互联互通和服务质量规范讨论稿Word文件下载.docx（41页珍藏版）》请在冰豆网上搜索。
localpart@domianpart/resourcepart>
（与一个账号相关的特定授权客户或设备）或<
domainpart/resourcepart>
（与一个服务器相关的特定资源或脚本）
XML实体：
是指可以用XMPP通信的网络端点，有发起实体和接收实体。
发起实体指首先产生一个XML节并在XMPP网络上发送的实体，如客户端，附加服务，或服务器。
接收实体通常是服务器。
XML流：
XML流就是一个容器，用于两个实体间通过网络交换XML元素。
一个XML流以<
stream>
开始，以<
/stream>
结束。
在流的整个生命周期，始发实体可以通过流发送大量的XML元素，用于流的握手或SASL握手或XML节（包括<
message/>
<
presence/>
或<
iq/>
元素）。
XML节：
一个XML节是XMPP中的一个基本的语义单位。
一个节就是一个第一层元素（在流的第一级），它的元素名是”message"
"
presence"
或"
iq"
，它的合法的命名空间是'
jabber:
client'
或'
server'
。
相比之下,任何其他命名空间限定的第一层元素都不是一个XML节（streamerrors,streamfeatures,TLS相关的元素,SASL相关的元素,等等。
），由'
或'
命名空间限定的<
或<
元素但不在第一层（例如,包含在一个扩展元素中的<
元素也不是一个XML节,不是命名空间'
限定的<
元素也不是一个XML节.。
一个XML节典型的包含一个或多个必要的子元素（以及相关的属性,元素,和XML字符串数据）来传达所需的信息,子元素可以使用任何XML命名空间。
这里定义的XML节仅限于<
和<
元素。
<
节是一个“推送”机制，一个实体推送信息到另一个实体；
节是一个特定的“广播”或“发布-订阅”机制,多个实体接收关于他们订阅的一个实体的信息（指网络可用性信息）；
信息查询（Info/Query）,或IQ,是一个“请求-应答”机制,类似某些情况下的超文本传输协议HTTP，IQ的语义允许一个实体对另一个实体做出一个请求,并接收一个应答。
3.2 缩略语
XMPPExtensibleMessagingPresenceProtocol
XMLExtensibleMarkupLanguage
JIDJabberIdentifier
TCPTransmissionControlProtocol
TLSTransmissionLayerSecurity
SASLSimpleAuthenticationandSecurityLayer
URIUniformResourceIndentifier
BNFBackus-NauruForm
XEPXMPPExtensionProtocol
XSFXMPPStandardsFoundation
IMPPInstantMessageandPresenceProtocol
SIMPLESIPforInstantMessagingandPresenceLeveragingExtensions
MSRPMessageSessionRelayProtocol
XCAPTheExtensibleMarkupLanguageConfigurationAccessProtocol
4 主流即时通信协议介绍
即时通信协议主要有三种：
IMPP,SIMPLE和XMPP，其中XMPP是最灵活的。
IMPP为即时通信系统提供一个抽象化、一般化的模型。
而后的SIMPLE和XMPP两个协议，都是遵照IMPP定义的架构、相关需求与消息格式，各自制定的通信协议。
4.1 IMPP
由IMPPWG所产生的标准RFC文件共有8篇，分別是：
AModelforPresenceandInstantMessaging（RFC2778）
InstantMessaging/PresenceProtocolRequirements（RFC2779）
DateandTimeontheInternet：
Timestamps（RFC3339）
CommonProfileforPresence（RFC3859）
CommonProfileforInstantMessaging（RFC3860）
AddressResolutionforInstantMessagingandPresence（RFC3861）
CommonPresenceandInstantMessaging：
MessageFormat（RFC3862）
PresenceInformationDataFormat（RFC3863）
IMPP工作组主要定义必要的协议和数据格式，用来构建一个具有空间接收、发布能力的即时信息系统。
RFC2778定义了一个即时通信系统（包括出席和即时消息）的抽象模型，定义了所有presence和IM服务的基本架构。
RFC2779是针对即时消息/呈现信息协议定义需求的，定义了IMPP的最小需求条件，还就presence服务定义了一些条款，如运行的命令、信息的格式，以及presence服务器如何把presence的状态变化通知给客户。
CPIM定义即时通信系统共同的消息格式以及必要的操作。
CPP则是定义出席信息的共同信息格式及必要的操作。
由于CPIM与CPP强调的是互通性，因此仅定义基本且必要的信息，CPIM和CPP提出与传输协议无关的即时消息和出席信息的共同标准规范，因此在不同即时通信系统互通上扮演中介的角色。
4.2 SIMPLE
SIMPLEWG成立于2000年末，由几个国际大厂如Dynamicsoft,Microsoft,Cisco等提案，选定SIP为即时消息与出席信息的基本通信协议，然后进行讨论并制定相关的SIP标准延伸。
SIMPLE是目前为止制定的较为完善的一个。
SIMPLE计划利用SIP来发送presence信息。
SIP是IETF中制定的会话初始化协议，主要用以协商、管理和终止媒体会话。
SIP一般考虑用在建立语音通话中，一旦连接以后，依靠如实时协议（RTP）来进行实际的语音发送。
但SIP不仅仅能被用在语音中，也可以用于视频。
SIMPLE致力于符合RFC2778的架构，依据RFC2779的需求，制定出一套完整的通信协议，同时消息格式也与CPIM相容。
更重要的是，不改变SIP原本的行为。
SIMPLE用MESSAGE请求来发送一次性的短消息，即寻呼机模式；
用SUBSCRIBE发送对出席信息的查询，用NOTIFY传输出席信息。
在持续较长的会话中，参与者在一段时间内交换多条消息，这时就用到MSRP，并且实现会议、保留和转接等复合式对话功能，即会议模式。
SIMPLE还制定了XCAP，以管理使用者的设定资料，如个人资料、好友名单、电话簿及出席信息的授权等。
使用者可将特定的资料用XML的形式储存于presence服务器，并定义存取方式，可支持使用者多个终端同时提供出席信息和即时消息交换。
目前，微软和IBM都致力于在它们的即时通讯系统中实现这个协议。
4.3 XMPP
XMPP是一个开放式实时通信协议，可以提供即时消息，呈现服务，多方聊天，语音和视频通话，协同工作，轻量中间件，内容联合和XML数据的普遍路由等。
XMPP最初是由Jabber开源社区提供的一款开放，安全的即时消息服务，用以代替封闭的即时消息服务。
IETF将核心的XML流协议标准化，于2004年发布了RFC3920和RFC3921，2011年又修订为RFC6120，RFC6121和RFC6122。
XMPP网络结构与email类似，是分散管理的，因此任何人都可以建立并运行自己XMPP服务器，使得个人和组织可以对他们的通信体验进行控制。
XMPP是可扩展的，任何人都可以在核心协议的基础上建立自己定制的功能，为了维护互操作性，一些公共的扩展由XSF通过标准程序发布为XEP系列。
已经由IETF标准化，它继承了在XML环境中灵活的发展性，这表明XMPP是可扩展的。
可以通过发送扩展的信息来处理用户的需求，以及在XMPP的顶端建立如内容发布系统和基于地址的服务等应用程序。
而且，XMPP包含了针对服务器端的软件协议，使之能与另一个进行通话，这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。
Skype,facebook在2009年增加了对XMPP的支持，MicrosoftLync，IBMLotusSametime增加了对XMPP的支持。
5 XMPP协议概览
5.1 功能描述
XMPP的主要作用是为网络上的两个（或更多个）实体之间提供交换数据的能力，数据称为XML节。
XMPP的典型结构是一个分布式的客户机-服务器形式，没有唯一的服务器负责为所有用户提供服务，而是很多的服务器都分散在不同位置，每一台服务器只为特定一批用户服务，如果位于不同服务器内的用户有通信需求，通过服务器和服务器通信来实现。
一个客户端连接到一个服务器，从而可以和其他实体交换数据（XML节）。
一个服务器连接到另一个服务器以进行域间或服务器间的通信，这时，两个服务器需要协商建立连接然后交换XML节。
建立连接的先决条件包括XML流协商，XML流头的交换，可选的信道加密（通过TLS），必须的认证（通过SASL），以及为客户寻址所做的资源绑定至流。
当建立连接后，XMPP客户端和XMPP服务器（或XMPP服务器和另一域中的XMPP服务器）就可以有一条长期存在的XML流，使得用户可以控制客户端发送和接收XML节。
这个流可用于交换消息，共享出席信息，以及实时地进行结构化的请求-响应交互。
当XML流协商完成后，典型的即时消息和呈现过程如下：
1提取联系人列表
2向服务器发送初始的出席信息，出席信息广播给所有订阅了该用户出席情况的联系人，表明该用户现在在线
3交换消息，管理出席订阅，执行联系人列表更新，以及其他一般过程。
4当需要时终止这个会话，发送不可用出席信息并关闭下层的XML流。
5.2 服务器连接服务器的例子
下面给出一个服务器和对端服务器协商XML流，交换XML节,和关闭已协商的流的数据流。
初始化服务器（"
Server1"
）是；
接收服务器（"
Server2"
）是，并且要求使用TLS；
递交一个证书并通过SASLEXTERNAL机制验证。
假定在发送初始化流头之前,Server1已经解析了一个SRV记录_xmpp-server._，并且已经打开了一个TCP连接到已解析的IP地址的声明的端口上。
注意：
Server1怎样声明内容命名空间"
server"
作为缺省的命名空间并为流相关的元素使用前缀,反之Server2使用免前缀标准。
TLS
第一步:
Server1发起流到Server2:
stream:
stream
from=’’
to=’’
version=’1.0’
xmlns=’jabber:
server’
xmlns:
stream=’http:
//etherx.jabber.org/streams’>
第二步:
Server2发送一个应答流头到Server1来应答:
id=’hTiXkW+ih9k2SqdGkk/AZi0OJ/Q=’
xmlns=’http:
第三步:
Server2发送流特性给Server1（在这个点上只有STARTTLS扩展,它是强制协商的）:
featuresxmlns=’http:
starttlsxmlns=’urn:
ietf:
params:
xml:
ns:
xmpp-tls’>
required/>
/starttls>
/features>
第四步:
Server1发送STARTTLS指令给Server2:
xmpp-tls’/>
第五步:
Server2通知Server1，允许它继续:
proceedxmlns=’urn:
第五步（替代）:
Server2通知Server1STARTTLS协商失败了,关闭流,并中止TCP连接（于是,流协商过程以不成功结束并且双方不再进行下一步）:
failurexmlns=’urn:
第六步:
Server1和Server2尝试通过TCP完成TLS协商。
第七步:
如果TLS协商成功了,Server1在受TLS保护的TCP连接上初始化一个新流到Server2:
第七步（替代）:
如果TLS协商不成功,Server2关闭TCP连接（所以,流协商过程以不成功结束并且双方不再进行下一步）。
SASL
第八步:
Server2发送一个应答流头给Server1并带上可用的流特性（包括优先的SASLEXTERNAL机制）:
id=’RChdjlgj/TIBcbT9Keu31zDihH4=’
mechanismsxmlns=’urn:
xmpp-sasl’>
mechanism>
EXTERNAL<
/mechanism>
/mechanisms>
第九步:
Server1选择EXTERNAL机制（包含一个"
="
的空应答）:
authxmlns=’urn:
xmpp-sasl’
mechanism=’EXTERNAL’>
=<
/auth>
第十步:
Server2返回成功:
successxmlns=’urn:
xmpp-sasl’/>
第十步（替代）:
Server2通知Server1验证失败了（所以,流协商过程以不成功结束并且双方不再进行下一步）:
not-authorized/>
/failure>
第十一步:
Server1初始化一个新流到Server2:
第十二步:
Server2发送一个流头给并带上任何附加的特性（或,在这个例子中,一个空的特性元素）来应答:
id=’MbbV2FeojySpUIP6J91qaa+TWHM=’
//etherx.jabber.org/streams’/>
节交换
现在Server1被允许通过已协商的从到的流发送XML节给Server2;
这里我们假定被传输的节就是前面演示的那些客户端-服务器通讯的节,尽管是在一个服务器-服务器由'
命名空间限定的流上。
Server1发送XML节给Server2:
messagefrom=’juliet@
id=’ju2ba41c’
to=’romeo@’
type=’chat’
lang=’en’>
body>
ArtthounotRomeo,andaMontague?
/body>
/message>
关闭
不想再发送更多消息,Server1关闭它到Server2的流，但是等待从Server2的进来的数据。
（实践中,流大部分时候保持打开一段时间,因为Server1和Server2不是立刻知道流是否还需要进行通信。
）
/stream:
和建议的流关闭握手一致,Server2同样关闭流:
Server1现在发送一个TLSclose_notify警告,从Server2接收一个close_notify警告应答,然后中止当前的TCP连接。
6 即时通信系统互联互通基本架构
图1所示为即时通信系统互联互通的基本架构，包括两种情况。
一种情况是XMPP系统与非XMPP系统的互通，非XMPP系统需提供网关，网关完成本系统协议与XMPP协议的转换，从而实现与XMPP系统的互通；
另一种情况是两个非XMPP系统的互通，这两个非XMPP系统分别提供网关完成本系统协议与XMPP协议的转换，从而这两个非XMPP系统通过XMPP协议实现互通。
本规范支持用户完成如下功能：
与用户的联系人交换消息；
与用户的联系人交换出席信息；
管理出席订阅（至联系人和来自联系人）。
本规范定义的接口为下图中的I接口，I接口由网关提供，I接口遵从XMPP协议。
有三种类型的消息通过网关：
出席订阅（订阅、更新、取消），出席信息，即时消息。
为实现即时通信系统互通，提供I接口的网关必须能够完成如下三方面的功能：
地址格式转换，订阅状态的转换，出席订阅管理，出席信息交换和即时消息交换。
地址格式的转换完成私有地址格式与XMPP格式的相互转换；
出席订阅管理包括出席信息订阅，出席信息取消订阅（联系人取消用户订阅资格和用户取消对某联系人的订阅）；
出席信息交换包括初始出席信息的交换，出席信息探查，后续出席信息的广播，不可用出席信息的交换和定向出席信息的交换。
7 地址格式转换
网关必须完成私有地址格式和XMPP地址格式的转换，XMPP地址格式定义如下。
7.1 XMPP地址
XMPP采用全球唯一地址（基于域名系统）以通过网络路由并提交消息。
所有的XMPP实体都可以通过网络寻址的，主要是客户机和服务器，也包括各种客户机和服务器可以访问的服务。
JID的语法用增强的BNF定义如下：
jid=[localpart"
@"
]domainpart["
/"
resourcepart]
localpart=1*（nodepoint）
domainpart=IP-literal/IPv4address/ifqdn
ifqdn=1*（namepoint）
resourcepart=1*（resourcepoint）
一个JID包括三个部分：
本地部分（localpart）,域名部分（domainpart）和资源部分（resourcepart）。
每个部分的长度不能超过1023字节，也就是总长度（包括分隔符’@’和’/’）不能超过3071字节。
通常，服务器地址为<
domianpart>
形式（例如，<
>
），服务器上的账户为<
juliet@>
称为简JID），一个授权代表某个账户进行交互的特定被连设备或资源为<
localpart@domainpart/resourc
升级会员 