RVP：存在和即时消息传送协议 (1)

2000年12月09日 02:22:00

Rob Osborne
Sonu Aggarwal
Lisa Lippert
Peter Beebee
Martin Calsyn
Leon Wong
Microsoft Corporation

2000年8月

摘要：此文档详细介绍了 RVP 协议及其相关方案，并且旨在为那些需要使其产品与 Microsoft Exchange Instant Messaging 进行交互的第三方开发人员提供参考。

目录

摘要 概述 协议简介 协议方法 身份验证 标头

新的 RVP 标头 返回码 XML 文档类型定义 MIME 有效负载 参考资料

---

摘要

Exchange Instant Messaging (IM) 已经成为 Internet 上一种非常流行的新型通信手段，其出现的动力来源于以下用户需求：用户想立即知道另一个用户是否在线，当另一个用户在线时得到通知，或者“实时”发送消息。这些都是 Internet 上通知处理技术涉及的主要问题中的特殊情况。根据设计，RVP 协议用于在一组松散耦合（联合）的服务器上传送通知和消息，并且能够满足用户的需求，以一种安全、可靠和可伸缩的方式来传送通知。RVP 包括客户机-服务器和服务器-服务器的交互。

即将发行的 Microsoft® Exchange 2000 Server 包括基于 RVP 有线协议的 Instant Messaging （即时消息传送）服务。此文档详细介绍了 RVP 协议及其有关方案，并且旨在为那些需要使其产品与 Microsoft Exchange Instant Messaging 进行交互的第三方开发人员提供参考。有关进一步的信息，这些开发人员可以使用 Exchange Instant Messaging SDK，其中对 RVP 协议元素有深入的说明。任何评论或问题都应该发送给作者。

RVP 协议与 Internet Engineering Task Force (互联网工程工作组，IETF) 的 Instant Messaging and Presence Protocol Working group (即时消息传送和存在协议工作组，IMPP) 所做的工作有关。RVP 并不打算与 IMPP 的努力竞争，而是通过提供一种已有的实现方法来进一步促进该设计过程。

---

概述

根据设计，RVP 协议用来在组织内和一组松散耦合（联合）的组织间建立订阅，并且传送通知和消息。这些组织可以是大型的可伸缩的多服务器运作模式，也可以是小型的单服务器运作模式。

RVP 是 HTTP/1.1 的严格扩展。因为 RVP 使用扩展的 HTTP，所以可以使用现有的那些灵活且出色的技术，如防火墙支持和代理。此外，对基本身份验证和重定向的要求已经在 HTTP 中得到了解决。

---

协议简介

RVP 特定的信息通常用新方法传送，或者通过在 HTTP 协议元素的 XML 主体内 XML 格式的数据中指定 RVP 名称空间进行传送。这样使用 XML 使得 RVP 服务器可以与 HTTP 服务器共存。XML 用于提供灵活性和可扩展性。

体系结构

RVP 使 WATCHERS （观察者）可以获得 PRESENCE INFORMATION （存在信息）和 PRESENTITIES（存在体），并在当前域或不同的域中将 INSTANT MESSAGES 发送到 INSTANT INBOX（即时收件箱）。为了做到这一点，Exchange 2000 Server 使用下列体系结构。有关这些大写术语的定义，请参阅在参考资料部分中列出的文章：[MODEL] 和 [IMPP-REQTS]。

图 1. Exchange 2000 Server 的体系结构

在上图中，客户机由一个 PRESENTITY、一个 WATCHER 和/或一个 INSTANT INBOX 组成。路由器用作所有实体的主接触点，并用来确定哪个本地服务器负责某一特定客户机。路由器可以重定向请求，也可以代理请求。

本地服务器负责为指定给它的任何 PRESENTITY 保持当前的 PRESENCE INFORMATION，并负责将对 PRESENTITY 当前在线状态所做更改的任何 NOTIFICATION （通知）发布给任何 SUBSCRIBER（订阅者）。为 PRESENTITY 预定的任何 INSTANT MESSAGE 最初都必须发送到相应的本地服务器。

客户机被同时用作某一特定 PRINCIPALL（主体）的 PRESENTITY 和 INSTANT INBOX。客户机还控制着 PRINCIPAL 可能发布的任何 SUBSCRIPTION（订阅）请求。

一般交互

对于一个要找出相应的服务器来执行操作（如为其 PRESENTITY 更新 PRESENCE INFORMATION，或者将 INSTANT MESSAGE 发送到 INSTANT INBOX）的客户机来说，它必须首先查找该域的域名服务器 (DNS) 的 SRV 记录。该域可以是包含该 PRESENTITY 的域，也可以是包含另一个 PRESENTITY 的域。查找 SRV 记录将返回负责此域的服务器的主机名。如果此域的 SRV 记录不可用，则客户机会为 IM 服务器查找 DNS A 记录。

然后，客户机连接到域服务器，就好像它是目标本地服务器一样，并将请求发送给域服务器。如果此服务器是本地服务器，则它将处理请求。然而，如果此服务器是路由器，则它要么代理请求，要么使用 HTTP 重定向来通知客户机，使它连接特定的本地服务器。客户机可以将对目标本地服务器的请求高速缓存一段时间，以提高后续请求的速度。

服务器之间的这种交互为非常灵活的组织拓扑之间的联合做好了准备。客户机能够找到 PRESENCE INFORMATION 并在域之间发送 INSTANT MESSAGES。各个组织可以根据它们的需求创建它们自己的拓扑。例如，一个仅拥有几百台客户机的小组织可以用一台服务器来充当路由器/本地服务器。一个拥有数十万台客户机的较大组织则可以结合使用负载平衡和目录查找，来控制对其多个路由器和本地服务器的访问。

寻址

寻址是通过使用 URL 完成的。这些 URL 由一个节点层次结构组成，每个节点代表一个实体。实体可以是 PRESENTITY、WATCHER、INSTANT INBOX 或者所有三者的组合。可以对此层次结构加以组织，以便将不同的实体组合在一起。例如，可以将所有人员 PRINCIPAL 组合在一起，如下所示：

http://im.somedomain.com/instmsg/aliases/aaronc

http://im.somedomain.com/instmsg/aliases/sherrih

另一个示例是将股票信息组合在一起，如下所示：

http://im.somedomain.com/information/stock/companyA

http://im.somedomain.com/information/stock/companyB

又如，可以将打印机或手机之类的设备组合在一起，如下所示：

http://im.somedomain.com/devices/printers/floor1prn

http://im.somedomain.com/devices/cellphones/555-1234

URL 有两种类型：逻辑 URL 和物理 URL。逻辑 URL 是默认类型，它确定节点所处的域。例如，一个像 beverlyj@domain1.com 这样的电子邮件地址可以映射到一个逻辑 URL http://im.domain1.com/instmsg/aliases/beverlyj。

物理 URL 可以与逻辑 URL 相同，也可以提供有关哪个服务器负责该实体的额外信息。在路由器重定向对某个特定实体的请求时使用物理 URL。例如，如果电子邮件地址 garrettv@domain2.com 处在一个拥有一个路由器和几个本地服务器的域内，则可以将对路由器的任何请求都重定向到物理 URL http://imhome1.domain2.com/instmsg/local/im.domain2.com/instmsg/aliases/garrettv。此物理 URL 随后被用来访问位于本地服务器 imhome1.domain2.com 的节点。

身份验证

实体可以向其本地服务器进行身份验证，但并不要求这样做。每个请求都可以包含用户凭据，使用 HTTP 句法向实际处理请求的服务器验证实体的身份。有关详细信息，请参阅标题为身份验证的部分。

在收到修改信息的请求时，处理请求的服务器必须对身份进行验证，并核对任何访问控制列表 (ACL) 项，这可能会阻止请求的完成。有关详细信息，请参阅标题为 ACL 的部分。

RVP 提供 HTTP 格式的返回码，以表明访问权限不足。

示例

RVP 协议有多种实际用途。然而，整个此文档中的示例都与即时消息传送和存在有关，因为这些示例是此项技术公认的用途。RVP 协议可以用于这样的应用程序，它们需要订阅，并提供事件何时发生的通知，如股票订购极限的执行、某个过程的完成或库存耗尽。

---

协议方法

RVP 协议支持许多不同的协议方法：SUBSCRIBE、UNSUBSCRIBE、SUBSCRIPTIONS、PROPFIND、PROPPATCH、NOTIFY、ACL 以及其它方法。

SUBSCRIBE

SUBSCRIBE （订阅）方法取自“一般事件通知体系结构”(GENA) 库，它建立了 WATCHER 对某一资源的订阅。WATCHER 可以接收打算用于此资源的通知或此资源属性更改的通知。例如，一个 RVP WATCHER 可以发出一个 SUBSCRIBE 请求来接收 PRESENTITY 的联系人列表上 PRINCIPALS 的在线状态。当这些 PRINCIPALS 的在线状态发生更改时，就会通知该 WATCHER。

订阅 ID

PRESENCE SERVICE （存在服务）必须为每个成功的订阅返回一个 Subscription-Id 标头。此标头包含一个对订阅唯一的号码，并且可以由 PRESENCE SERVICE 和 WATCHER 在将来涉及订阅的所有交互中加以引用。

租用的订阅

订阅可以是静态的（永久的，除非由 UNSUBSCRIBE [撤消订阅] 请求显式删除），也可以是租用的（临时的）。因为 Exchange 2000 Server 不接受静态订阅，所以它会返回一个错误响应。对于租用的订阅，没有显式更新的订阅将到期，因此使对资源的订阅保持“相关”状态。例如，一个 WATCHER 可以对 PRESENTITY 的在线状态订阅为期一天的时间。如果在建立此订阅之后，该 WATCHER 保持离线状态，则订阅将到期，并且 PRESENTITY 的 PRESENCE SERVICE 将不会为一个不需要的订阅维持开销。

对 PRESENCE SERVICE 的 SUBSCRIBE 请求中的 Subscription-Lifetime 标头，表明一个租用订阅的生存期（以秒计）。如果 PRESENCE SERVICE 对租用订阅请求的响应包括一个 Subscription-Lifetime 标头，则订阅将在此时间间隔之后到期（要管理负载，RESENCE SERVICE 可以选择一个不同于所请求的生存期）。响应中缺少 Subscription-Lifetime 标头表明订阅是永久的。

为了刷新租用订阅，WATCHERS 通过使用 Subscription-Id 和 Subscription-Lifetime 标头来发布新的 SUBSCRIBE 请求。

通知类型

任何 RVP 节点都可以充当一个通知接收器 — 即通知的目标。例如，当一个 RVP PRESENTITY 登录后，可以由 RVP 实体（如 RVP PRESENCE SERVICE 或 RVP PRINCIPALS）将任何通知发送给 PRINCIPAL 的 URL（如 http://im.example.com/instmsg/aliases/deriks）。可以在通知接收器上进行订阅。一个组节点（如 http://im.example.com/groups/recycling）可以充当通知接收器。然后，组的成员就可以订阅此节点。发送给接收器节点的通知会传递给该接收器的订阅者。

RVP 实体可能也需要得到其它节点属性更改的通知。例如，如果 PRINCIPAL A 在一个联系人列表上有 PRINCIPAL B，则 PRINCIPAL A 会订阅 PRINCIPAL B 的属性，其中包括 PRINCIPAL B 的“在线状态”属性。这使 A 能够在“在线状态”属性更改时得到通知。SUBSCRIBE 请求中的 Notification-Type 标头允许请求者指定是否订阅目标节点上的属性更改（如果标头的值是 update/propchange），或是否订阅目标节点接收器上的一般通知（如果标头的值是 pragma/notify)。

通知发送

异步回调要求有一个 Call-Back 标头。此标头为接收此回调的资源指定 URL。回调 URL 可以是 PRINCIPAL 的 Public URL（公用 URL），也可以是由 WATCHER 托管的 URL。Public URL 允许通过 PRESENCE SERVICE 来传递通知。由 WATCHER 自身托管的回调允许将通知从 PRESENCE SERVICE 传递给 WATCHER。

例如，机器 deriks1.example.com 上的 WATCHER 可以向 http://im.example.com/instmsg/aliases/deriks 发出一个 SUBSCRIBE 请求，并提供一个类似于 http://198.176.154.132:1234 的 Call-Back 标头 URL。WATCHER 还可以向 http://im.acme.com/instmsg/aliases/maxb 发出一个 SUBSCRIBE 请求，并提供一个 Call-Back 标头 URL (http://im.example.com/instmsg/aliases/deriks)。IP 地址和 URL 之间的差异保证了来自该域以外的任何请求都不会试图直接连接到该客户机。

对 Max 的属性的任何更改都会导致向 http://im.example.com/instmsg/aliases/deriks 发送一个通知。而且，任何 INSTANT MESSAGES 都会被发送到同一节点。当 im.example.com 接收到此节点的任何通知后，它会将这些通知发送到 Call-Back 标头 URL http:// 198.176.154.132:1234。这就保证了只有 PRESENTITY 的本地服务器才知晓其 IP 地址，并且所有通知都通过它进行传递。这样的通知是通过 NOTIFY （通知）请求发送的。（在上一个示例中，PRESENCE SERVICE 向 WATCHER 发出了一个 NOTIFY 请求。）

更改/丢弃订阅

要更改其它订阅的特征，WATCHER 必须发出一个 UNSUBSCRIBE 请求，然后用新设置发出一个 SUBSCRIBE 请求。RVP 服务器不准丢弃它确定为互为副本的订阅；这样的订阅由它们的 Subscription-Id 标头单独管理。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=3224