TC11WG1037即时通信系统互联互通和服务质量规范讨论稿.docx
《TC11WG1037即时通信系统互联互通和服务质量规范讨论稿.docx》由会员分享，可在线阅读，更多相关《TC11WG1037即时通信系统互联互通和服务质量规范讨论稿.docx（41页珍藏版）》请在冰豆网上搜索。
TC11WG1037即时通信系统互联互通和服务质量规范讨论稿
移动即时通信系统互联互通接口和服务质量规范
1 范围
本标准规定了移动终端即时通信服务的互联互通接口标准和服务质量规范，包括即时通信系统互联互通的架构，重点定义了实现即时通信系统互通所需网关的基本功能和接口。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。
凡是注日期的引用文件，仅所注日期的版本适用于本文件。
凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
RFC6120ExtensibleMessagingandPresenceProtocol（XMPP）:
Core
RFC6122ExtensibleMessagingandPresenceProtocol（XMPP）:
AddressFormat
RFC3920ExtensibleMessagingandPresenceProtocol（XMPP）:
Core
RFC3921ExtensibleMessagingandPresenceProtocol（XMPP）:
InstantMessagingandPresence
RFC3428SessionInitiationProtocol（SIP）ExtensionforInstantMessaging
RFC3856APresenceEventPackagefortheSessionInitiationProtocol（SIP）
RFC2142MAILBOXNAMESFORCOMMONSERVICES,ROLESANDFUNCTIONS
RFC5234AugmentedBNFforSyntaxSpecifications:
ABNF
RFC4422SimpleAuthenticationandSecurityLayer（SASL）
RFC5246TheTransportLayerSecurity（TLS）ProtocolVersion1.2
3 定义和缩略
3.1 术语和定义
简JID：
是指具有如下形式的XMPP地址，（服务器的一个账号）或（服务器）。
完全JID：
是指具有如下形式的XMPP地址，（与一个账号相关的特定授权客户或设备）或（与一个服务器相关的特定资源或脚本）
XML实体：
是指可以用XMPP通信的网络端点，有发起实体和接收实体。
发起实体指首先产生一个XML节并在XMPP网络上发送的实体，如客户端，附加服务，或服务器。
接收实体通常是服务器。
XML流：
XML流就是一个容器，用于两个实体间通过网络交换XML元素。
一个XML流以开始，以结束。
在流的整个生命周期，始发实体可以通过流发送大量的XML元素，用于流的握手或SASL握手或XML节（包括,或元素）。
XML节：
一个XML节是XMPP中的一个基本的语义单位。
一个节就是一个第一层元素（在流的第一级），它的元素名是”message","presence",或"iq"，它的合法的命名空间是'jabber:
client'或'jabber:
server'。
相比之下,任何其他命名空间限定的第一层元素都不是一个XML节（streamerrors,streamfeatures,TLS相关的元素,SASL相关的元素,等等。
），由'jabber:
client'或'jabber:
server'命名空间限定的,,或元素但不在第一层（例如,包含在一个扩展元素中的元素也不是一个XML节,不是命名空间'jabber:
client'或'jabber:
server'限定的,,或元素也不是一个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怎样声明内容命名空间"jabber:
server"作为缺省的命名空间并为流相关的元素使用前缀,反之Server2使用免前缀标准。
TLS
第一步:
Server1发起流到Server2:
stream
from=’’
to=’’
version=’1.0’
xmlns=’jabber:
server’
xmlns:
stream=’http:
//etherx.jabber.org/streams’>
第二步:
Server2发送一个应答流头到Server1来应答:
from=’’
id=’hTiXkW+ih9k2SqdGkk/AZi0OJ/Q=’
to=’’
version=’1.0’
xmlns=’http:
//etherx.jabber.org/streams’>
第三步:
Server2发送流特性给Server1（在这个点上只有STARTTLS扩展,它是强制协商的）:
//etherx.jabber.org/streams’>
ietf:
params:
xml:
ns:
xmpp-tls’>
第四步:
Server1发送STARTTLS指令给Server2:
ietf:
params:
xml:
ns:
xmpp-tls’/>
第五步:
Server2通知Server1，允许它继续:
ietf:
params:
xml:
ns:
xmpp-tls’/>
第五步（替代）:
Server2通知Server1STARTTLS协商失败了,关闭流,并中止TCP连接（于是,流协商过程以不成功结束并且双方不再进行下一步）:
ietf:
params:
xml:
ns:
xmpp-tls’/>
第六步:
Server1和Server2尝试通过TCP完成TLS协商。
第七步:
如果TLS协商成功了,Server1在受TLS保护的TCP连接上初始化一个新流到Server2:
stream
from=’’
to=’’
version=’1.0’
xmlns=’jabber:
server’
xmlns:
stream=’http:
//etherx.jabber.org/streams’>
第七步（替代）:
如果TLS协商不成功,Server2关闭TCP连接（所以,流协商过程以不成功结束并且双方不再进行下一步）。
SASL
第八步:
Server2发送一个应答流头给Server1并带上可用的流特性（包括优先的SASLEXTERNAL机制）:
from=’’
id=’RChdjlgj/TIBcbT9Keu31zDihH4=’
to=’’
version=’1.0’
xmlns=’http:
//etherx.jabber.org/streams’>
//etherx.jabber.org/streams’>
ietf:
params:
xml:
ns:
xmpp-sasl’>
EXTERNAL
第九步:
Server1选择EXTERNAL机制（包含一个"="的空应答）:
ietf:
params:
xml:
ns:
xmpp-sasl’
mechanism=’EXTERNAL’>=
第十步:
Server2返回成功:
ietf:
params:
xml:
ns:
xmpp-sasl’/>
第十步（替代）:
Server2通知Server1验证失败了（所以,流协商过程以不成功结束并且双方不再进行下一步）:
ietf:
params:
xml:
ns:
xmpp-sasl’>
第十一步:
Server1初始化一个新流到Server2:
stream
from=’’
to=’’
version=’1.0’
xmlns=’jabber:
server’
xmlns:
stream=’http:
//etherx.jabber.org/streams’>
第十二步:
Server2发送一个流头给并带上任何附加的特性（或,在这个例子中,一个空的特性元素）来应答:
from=’’
id=’MbbV2FeojySpUIP6J91qaa+TWHM=’
to=’’
version=’1.0’
xmlns=’http:
//etherx.jabber.org/streams’>
//etherx.jabber.org/streams’/>
节交换
现在Server1被允许通过已协商的从到的流发送XML节给Server2;这里我们假定被传输的节就是前面演示的那些客户端-服务器通讯的节,尽管是在一个服务器-服务器由'jabber:
server'命名空间限定的流上。
Server1发送XML节给Server2:
id=’ju2ba41c’
to=’romeo@’
type=’chat’
xml:
lang=’en’>
ArtthounotRomeo,andaMontague?
关闭
不想再发送更多消息,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字节。
通常，服务器地址为形式（例如，<>），服务器上的账户为形式（例如，,称为简JID），一个授权代表某个账户进行交互的特定被连设备或资源为
升级会员 