彭榮群，糜正琨，張培陽

（南京郵電大學(xué)通信與信息工程學(xué)院 南京 210003）

1 引言

隨著電信網(wǎng)絡(luò)向全I(xiàn)P網(wǎng)絡(luò)的演進(jìn)，各種靈活的通信新業(yè)務(wù)不斷出現(xiàn)，特別在3G通信中，引入了多種新業(yè)務(wù)，如數(shù)字家庭業(yè)務(wù)、網(wǎng)上銀行業(yè)務(wù)、視頻電話業(yè)務(wù)等。一般每一種業(yè)務(wù)都有自己的地址簿，如手機地址簿、SIM卡地址簿、ISP提供的地址簿以及某些特定業(yè)務(wù)的地址本等，這使用戶面臨同時處理多個終端的多個地址簿的問題。由于每個終端都是獨立地存儲數(shù)據(jù)，當(dāng)某個終端丟失或出現(xiàn)故障時，丟失的地址簿信息很難恢復(fù)。特別是當(dāng)聯(lián)系人信息改變時，為了保持聯(lián)系人信息可用，需要手動修改各個終端上的地址簿數(shù)據(jù)，過程相當(dāng)繁瑣。為了適應(yīng)這樣的通信新環(huán)境，提升用戶體驗，有必要開發(fā)一種融合的地址簿系統(tǒng)。

vCard[1]，即電子商務(wù)卡或電子名片（electronic business card，versit Card)是目前常用的一種電子地址簿格式，它實現(xiàn)了傳統(tǒng)名片上個人信息的自動交換，主要應(yīng)用于互聯(lián)網(wǎng)電子郵件、語音郵件、Web瀏覽器、電話相關(guān)應(yīng)用、呼叫中心、視頻會議、個人信息管理(personal information manager，PIM)、PDA、尋呼、傳真、辦公設(shè)備以及智能卡等。vCard不但可以包含姓名、地址、電話號碼等文本信息，還可以包含URL、商標(biāo)、圖片甚至聲音片段等信息。

中國移動基于vCard開發(fā)了PIM業(yè)務(wù)[2]，它為用戶提供個性化服務(wù)，用戶可以將終端上的PIM數(shù)據(jù)備份到網(wǎng)絡(luò)側(cè)的服務(wù)器上，或從網(wǎng)絡(luò)側(cè)的服務(wù)器獲取PIM信息同步到終端，或者從移動終端備份到本地計算機上，最終達(dá)到移動終端、網(wǎng)絡(luò)服務(wù)器以及其他個人終端個人信息同步的目的。PIM服務(wù)基于同步標(biāo)記語言（synchronization markup language，SyncML[3])協(xié)議來實現(xiàn)。

中國聯(lián)通北京分公司的如意通信錄業(yè)務(wù)[4]是為聯(lián)通手機用戶提供的基于互聯(lián)網(wǎng)技術(shù)的增值業(yè)務(wù)，用戶使用該業(yè)務(wù)可以把手機通信錄、個人電話本、單位通信錄、客戶名片等各種聯(lián)系人的信息保存到如意通信錄系統(tǒng)中，并可以通過互聯(lián)網(wǎng)或手機短信等方式進(jìn)行實時更新、管理。用戶通過該產(chǎn)品可以批量上傳所有零散分布的通信錄信息，隨時隨地輕松查詢各個聯(lián)系人的詳細(xì)信息，用任何連接Internet的個人電腦編輯和更新手機通信錄中的聯(lián)系方式，制作、存儲自己及好友的電子名片等。

以上幾種地址簿系統(tǒng)，雖然存儲了用戶的各種地址簿信息，并且可以把地址簿備份到網(wǎng)絡(luò)側(cè)方便用戶管理，但是對于地址簿中信息的改變，都沒有一種機制能即時自動地更新到本地地址簿中。

融合地址簿(converged address book，CAB)系統(tǒng)提供了這樣一種機制，它既可以使用戶方便地管理本地終端上的地址簿信息，又可以使用戶方便地管理存儲在網(wǎng)絡(luò)上的地址簿信息。CAB系統(tǒng)的核心是位于網(wǎng)絡(luò)側(cè)的地址簿信息存儲，它不但要便于用戶訪問和管理，還要能通過訂閱與同步機制時刻保持與各種終端數(shù)據(jù)更新的同步，而且當(dāng)網(wǎng)絡(luò)側(cè)存儲的地址簿信息改變時，系統(tǒng)也要把改變的數(shù)據(jù)同時同步到用戶的各個終端。

開放移動聯(lián)盟（open mobile alliance，OMA）在 2008 年6月正式啟動了CAB系統(tǒng)的研究[5]，參加的成員有ATT、Ericsson、Orange、Nokia、Samsung Electronics、T-Mobile、RIM以及中國的中國移動、華為和中興等通信公司，各成員都提出了自己的系統(tǒng)架構(gòu)和關(guān)鍵技術(shù)解決方案。本文是作者關(guān)于CAB標(biāo)準(zhǔn)的部分研究成果。目前,在OMA中需求文檔（requirement document，RD）和架構(gòu)文檔(architecture document,AD)階段已經(jīng)結(jié)束，技術(shù)規(guī)范(technical specification，TS)階段正在進(jìn)行中。

2 融合地址簿系統(tǒng)構(gòu)架

（1）系統(tǒng)功能

根據(jù)OMA的CAB需求文檔[6]，CAB系統(tǒng)應(yīng)具備以下功能特征。

·管理

管理CAB，CAB系統(tǒng)提供CAB用戶融合地址簿的網(wǎng)絡(luò)存儲和管理功能；管理個人聯(lián)系卡（personal contact card，PCC），CAB系統(tǒng)允許 CAB用戶發(fā)布和管理(增、刪、改）其存儲于網(wǎng)絡(luò)數(shù)據(jù)庫的PCC信息，PCC信息經(jīng)授權(quán)后以視圖的形式發(fā)布給其他人。

·同步

同步CAB，地址簿的信息應(yīng)能在CAB用戶所有設(shè)備間更新同步；同步PCC，PCC的信息應(yīng)在CAB用戶所有設(shè)備間更新同步。

·訂閱

CAB用戶可訂閱其他CAB用戶的PCC信息并獲得其更新信息。

·共享

CAB用戶可通過消息機制與其他用戶共享其PCC和CAB的數(shù)據(jù)。

·搜索

CAB可以搜索CAB系統(tǒng)或其他地址簿系統(tǒng)內(nèi)的聯(lián)絡(luò)信息。

· 與傳統(tǒng)地址簿系統(tǒng)互通

CAB系統(tǒng)應(yīng)能與傳統(tǒng)地址簿系統(tǒng)交互，這就使得CAB用戶可從傳統(tǒng)地址簿系統(tǒng)導(dǎo)入或?qū)С鰯?shù)據(jù)。

· 狀態(tài)和通告信息

CAB用戶在下列情況下應(yīng)獲得通告信息：來自于其他CAB用戶的聯(lián)絡(luò)預(yù)約授權(quán)請求；訂閱的PCC信息發(fā)生修改；被其他CAB用戶加入其地址簿；聯(lián)絡(luò)狀態(tài)信息傳送。

·安全

能保證只有授權(quán)的用戶才能使用CAB功能，同時要保證數(shù)據(jù)的完整性和安全性。

（2）系統(tǒng)架構(gòu)

關(guān)于 CAB系統(tǒng)架構(gòu)，相關(guān)研究人員提出了 A[7]、B[8]、C[9]、D[10]4種CAB體系架構(gòu)，它們各有特色和不足。4種架構(gòu)模型雖各有差異，但它們均包括CAB客戶端、CAB服務(wù)器和XDM（XML document management，XML 文檔管理）[11]服務(wù)器（XDMS）。4種架構(gòu)模型的主要差異是同步方式，即使用XDM方式的同步還是使用基于OMA DS（data synchronization，數(shù)據(jù)同步）[12]的SyncML同步。本文在詳細(xì)分析了這4種已有體系架構(gòu)的基礎(chǔ)上，提出了一個融合各種架構(gòu)優(yōu)點、能完全實現(xiàn)需求文檔所規(guī)定功能的CAB架構(gòu)，如圖1所示。本架構(gòu)采用DS系統(tǒng)實現(xiàn)客戶端地址簿與網(wǎng)絡(luò)側(cè)地址簿的同步；采用XDM系統(tǒng)實現(xiàn)對存儲在網(wǎng)絡(luò)上的 PCC、CAB、UPP（user policy and preference，用戶策略和偏好）等XML形式文檔的管理和維護(hù)；采用DM（device management，器件管理）[13]系統(tǒng)實現(xiàn)設(shè)備的初始化和終端能力信息的獲取。另外，在本架構(gòu)中還引入在席(presence)系統(tǒng)信息以提高用戶體驗。

（3）模塊主要功能

系統(tǒng)主要包含三大模塊，分別為CAB客戶端、CAB服務(wù)器和XDM引擎。

· CAB客戶端

數(shù)據(jù)同步客戶端發(fā)送和接收來自同步服務(wù)器的同步操作；器件管理客戶端接收終端設(shè)備初始化的配置參數(shù)以及軟件更新；XDM客戶端實現(xiàn)對網(wǎng)絡(luò)側(cè)地址簿數(shù)據(jù)的管理（增加、刪除、修改、搜索等）操作；在席客戶端完成與在席相關(guān)的功能。

· CAB服務(wù)器

數(shù)據(jù)同步服務(wù)器接收來自數(shù)據(jù)同步客戶端的同步請求，并對請求進(jìn)行對應(yīng)的響應(yīng)操作；接收來自CAB的更改信息，并將更改同步到該用戶的所有終端設(shè)備上。

器件管理服務(wù)器為CAB用戶的終端設(shè)備進(jìn)行初始化參數(shù)配置以及后續(xù)的更新配置，更新CAB用戶終端設(shè)備上的軟件。

訂閱功能模塊主要負(fù)責(zé)對用戶的偏好及策略進(jìn)行查詢，獲得用戶定義的訂閱列表，然后代表用戶對列表中的聯(lián)系人信息進(jìn)行訂閱。

廣告訂閱模塊使得用戶能夠邀請對方來訂閱自己的聯(lián)系視圖，它以通知的形式告知被邀請方，并通過訂閱功能模塊和訂閱代理實現(xiàn)接受邀請后的訂閱；另外，它能夠結(jié)合XDM的搜索代理，實現(xiàn)CAB用戶（企業(yè)用戶）的廣告發(fā)布。

互通模塊完成與非CAB地址簿或外部地址簿的交互功能。

· XDM引擎

CAB XDMS：以XML格式存儲CAB系統(tǒng)的各種數(shù)據(jù)，接收來自客戶端的請求完成對數(shù)據(jù)的管理操作，接收對數(shù)據(jù)的訂閱請求并在被訂閱的數(shù)據(jù)修改后發(fā)出通知，接收來自客戶端的查詢請求并返回查詢結(jié)果,包括3種數(shù)據(jù)服務(wù)器：CAB XDMS、PCC XDMS 和 UPP XDMS。

聚合代理：負(fù)責(zé)對接入的CAB用戶進(jìn)行安全認(rèn)證；負(fù)責(zé) CAB 用 戶 XCAP(XML configuration access protocol，XML配置和訪問協(xié)議)請求到各個XDMS或者網(wǎng)絡(luò)互通模塊的選路；負(fù)責(zé)共享請求到共享服務(wù)器的選路；負(fù)責(zé)搜索請求到搜索代理的選路；負(fù)責(zé)將用戶對在席信息訂閱規(guī)則的修改發(fā)送至在席XDMS。

搜索代理：將來自聚合代理的用戶搜索請求發(fā)送至本域或外域的XDM服務(wù)器；接收來自本域或外域XDM服務(wù)器的響應(yīng)信息；將搜索結(jié)果合并后返回給用戶。

訂閱代理：接收來自CAB用戶的訂閱請求，執(zhí)行后臺的訂閱操作；接收來自XDMS被訂閱信息改變的通告，聚集后發(fā)給訂閱者。

聯(lián)系共享：接收來自聚合代理的共享請求，并路由到相應(yīng)的存儲服務(wù)器中（CAB XDMS,PCC XDMS或者用戶存儲模塊），將響應(yīng)發(fā)送至聚合代理模塊處理。

SIP/IP內(nèi)核：路由本地用戶和外域?qū)嶓w間的SIP請求和響應(yīng)。

網(wǎng)絡(luò)互通代理：路由本地用戶和外域?qū)嶓w間的XCAP、Xquery請求和響應(yīng)。

（4）主要外部接口或參考點

· 參考點XDM-1

處在XDM客戶端和SIP/IP內(nèi)核之間，傳送訂閱消息，采用SIP[14]。

· 參考點XDM-3

處在XDM客戶端和聚合代理之間，傳送數(shù)據(jù)管理(增加、刪除、更改等)消息，采用 XCAP[15]。

· 參考點XDM-4

處在聚合代理和訂閱功能模塊或互通模塊之間，傳送數(shù)據(jù)管理消息，采用 XCAP。

· 參考點XDM-5

處在XDM客戶端和聚合代理之間，傳送數(shù)據(jù)搜索消息，采用 XQuery協(xié)議[16]。

· 參考點XDM-7

處在聚合代理和互通模塊之間，傳送搜索外部數(shù)據(jù)消息，采用 XQuery協(xié)議。

· 參考點XDM-10

處在廣告訂閱模塊和SIP/IP內(nèi)核之間，傳送訂閱消息，采用 SIP。

·接口DS-1,2

處在數(shù)據(jù)同步客戶端和數(shù)據(jù)同步服務(wù)器之間，傳送數(shù)據(jù)同步消息，采用SyncML協(xié)議。

3 關(guān)鍵技術(shù)

能保證本地地址簿隨著聯(lián)系信息改變而同步更新的技術(shù)是訂閱/通告機制和同步機制，二者也是CAB系統(tǒng)中的關(guān)鍵技術(shù)。

（1）訂閱/通告機制

訂閱/通告機制的基本思想是用戶對感興趣的數(shù)據(jù)發(fā)送訂閱請求，在XDMS中產(chǎn)生訂閱關(guān)系；當(dāng)被訂閱的數(shù)據(jù)發(fā)生改變時，系統(tǒng)會立刻產(chǎn)生一個數(shù)據(jù)改變通告(里面包含有改變的數(shù)據(jù))發(fā)給訂閱者，使訂閱者及時獲得更改的數(shù)據(jù)，從而保持本地數(shù)據(jù)的最新性。

訂閱過程可分為由客戶端發(fā)起的訂閱、由CAB服務(wù)器發(fā)起的訂閱、根據(jù)UPP發(fā)起的自動訂閱以及邀請訂閱等。無論是哪種訂閱形式，最終的結(jié)果都是在XDMS中建立起一種訂閱關(guān)系，之后在被訂閱的數(shù)據(jù)發(fā)生改變時能夠及時獲得這些更改的數(shù)據(jù)。不失一般性，本文以客戶端發(fā)起的訂閱為例來闡述訂閱過程。訂閱流程如圖2所示。

對于流程中的每一個步驟，在圖中已經(jīng)說明得很清楚了，由于篇幅所限不再贅述，在此只作幾點說明。

· 在步驟7中，PCC取被訂閱者的UPP，目的是獲知被訂閱者的哪些PCC數(shù)據(jù)可以訂閱。在步驟10.b中，訂閱功能模塊取訂閱者自己的UPP是為了獲知當(dāng)收到了更改的被訂閱數(shù)據(jù)時訂閱者如何處理，是直接發(fā)送給終端還是處理后發(fā)送給CAB。

· 根據(jù)訂閱/通告機制[17]規(guī)范，一旦訂閱關(guān)系建立，即使沒有數(shù)據(jù)改變，PCC也要把當(dāng)前數(shù)據(jù)發(fā)送給訂閱者，即步驟 9a～12a。

·13.b “CAB通過同步機制將更新的數(shù)據(jù)同步到訂閱者的各個終端”的具體步驟參見圖3中的步驟5～11。

（2）同步機制

訂閱/通告機制保證了用戶能及時獲知聯(lián)系人數(shù)據(jù)的更改，但是當(dāng)用戶有多個終端設(shè)備時，為了保持各種設(shè)備之間地址簿的同步更新，還需要同步機制來完成。

同步機制由處于CAB服務(wù)器中的數(shù)據(jù)同步服務(wù)器完成，采用SyncML接口協(xié)議。同步方式可以分為直接或間接添加同步，復(fù)制、移動、軟刪除或硬刪除同步，局部或全局替換同步，過濾同步以及同步恢復(fù)等。圖3所示為直接添加聯(lián)系人信息的同步過程，其應(yīng)用場景為：用戶持有多個終端，每個終端上都存儲有網(wǎng)絡(luò)地址簿的一個子集。當(dāng)其中的一個終端手動添加了新的聯(lián)系人信息，數(shù)據(jù)同步客戶端會將新添加的信息自動更新到網(wǎng)絡(luò)地址簿；一旦網(wǎng)絡(luò)地址簿更新，數(shù)據(jù)同步服務(wù)器會自動及時地把更新的數(shù)據(jù)推送到用戶持有的每一個終端上，這樣的同步機制就保證了用戶的所有終端都持有最新的地址簿信息。

對以上流程的每個步驟不做詳細(xì)描述,在此只作幾點說明。

·客戶端與服務(wù)器之間的每一次同步會話必須進(jìn)行同步初始化，包括同步數(shù)據(jù)庫指定、同步類型協(xié)商和設(shè)備信息交互（步驟2和9）。

·客戶端與服務(wù)器之間的同步會話一般分為3個階段：同步初始化、同步數(shù)據(jù)交換和同步數(shù)據(jù)識別符映射階段（步驟 9、10和 11）。

·服務(wù)器向客戶端發(fā)起同步交互之前會與UPP交互獲取用戶同步偏好，然后進(jìn)行數(shù)據(jù)同步前的處理（步驟 6 和 7）。

· 同步過程必須由客戶端首先發(fā)起，所以當(dāng)服務(wù)器想同步數(shù)據(jù)時，必須向客戶端發(fā)送一個同步會話請求，客戶端收到會發(fā)起同步初始化過程，同步才能開始（步驟 8）。

4 系統(tǒng)仿真

（1）仿真系統(tǒng)結(jié)構(gòu)

為了實現(xiàn)CAB需求文檔描述的CAB功能特征，我們對CAB系統(tǒng)進(jìn)行仿真，仿真結(jié)構(gòu)如圖4所示。CAB客戶端由操作界面和本地數(shù)據(jù)存儲組成。操作界面由CAB的各個功能特征組成。其中，PCC/AB管理模塊用于對個人信息或聯(lián)系人信息以及視圖（包括搜索視圖）執(zhí)行增、刪、改等操作；搜索模塊用于對PCC信息及個人的聯(lián)系人信息執(zhí)行搜索操作；同步模塊用于對同一用戶多個終端的數(shù)據(jù)執(zhí)行同步操作；訂閱/邀請訂閱模塊用于根據(jù)開放的視圖對多個聯(lián)系人執(zhí)行訂閱和邀請訂閱操作；共享模塊用于對個人信息或聯(lián)系人信息執(zhí)行共享操作，接受共享方可以同時是多個CAB用戶；LAWMO（lock and wipe management object,上鎖和擦除管理對象）模塊用于對同一用戶不同終端設(shè)備執(zhí)行鎖定和擦除數(shù)據(jù)操作。本地數(shù)據(jù)存儲用于本地存儲CAB用戶的PCC及AB等信息。CAB服務(wù)器由服務(wù)器處理模塊和網(wǎng)絡(luò)存儲模塊組成。其中，服務(wù)器處理模塊用于解析和處理客戶端的請求信息，網(wǎng)絡(luò)存儲模塊采用SQL Server 2005，在網(wǎng)絡(luò)側(cè)存儲CAB用戶的PCC信息及AB等信息。CAB客戶端和服務(wù)器之間采用SOCKET通信，在網(wǎng)絡(luò)中傳輸XML格式數(shù)據(jù)文檔和操作指令。

（2）XML 格式數(shù)據(jù)文檔

我們在仿真中對PCC信息和聯(lián)系人信息采用XML格式在網(wǎng)絡(luò)中傳輸，客戶端或服務(wù)器收到XML格式數(shù)據(jù)后對其解析再分別存入本地數(shù)據(jù)存儲模塊和服務(wù)器數(shù)據(jù)存儲模塊，即SQL Server 2005。采用上述處理方法出于以下幾點考慮：一是XML在Internet環(huán)境中具有跨平臺的特點，因此采用XML格式傳輸可以使仿真程序不依賴于平臺,可移植性高；二是CAB系統(tǒng)的聯(lián)系人信息形式單一，是一種結(jié)構(gòu)化的文檔信息。因此，采用XML可以方便地處理聯(lián)系人信息，而且效率更高。下面是我們設(shè)計的部分XML格式的PCC信息：

對以上XML格式文檔作幾點說明。

· 第一行“XML”標(biāo)記說明它是一個 XML文檔，后面兩個屬性表明了它的版本號和編碼標(biāo)準(zhǔn)。

· “PCC”是根元素，其他子元素如“用戶名”、“真實姓名”、“性別”必須包含在根元素中。

· 子元素還可以包含子元素，如子元素“生日”包含子元素“月”和“日”，沒有子元素的元素稱為樹葉，如“Zhang San”、“張三”、“男”等。

（3）仿真結(jié)果

CAB用戶對客戶端界面的各個功能模塊執(zhí)行操作，服務(wù)器根據(jù)收到的操作指令解析并與SQL Server 2005進(jìn)行交互，獲取相應(yīng)信息并轉(zhuǎn)換成XML格式數(shù)據(jù)文檔發(fā)給CAB客戶端，CAB客戶端對收到的XML格式文檔進(jìn)行解析并顯示在相應(yīng)界面上同時存入本地數(shù)據(jù)存儲模塊中。根據(jù)上述簡要操作流程，通過仿真我們實現(xiàn)了CAB的大部分功能需求，包括PCC/AB管理（包括對視圖的增、刪、改等管理操作）、訂閱/邀請訂閱（包括同一時刻對多個人的訂閱和邀請訂閱的操作）、共享（包括同一時刻被共享方是多個CAB或非CAB用戶，接受共享方也是多個CAB用戶的操作）、搜索（包括搜索結(jié)果的摘要返回和根據(jù)用戶的搜索視圖返回相應(yīng)搜索結(jié)果的操作）、同步（包括同一用戶多個終端的PCC信息及聯(lián)系人信息的同步操作）以及LAWMO（包括同一用戶對某個被盜或丟失終端的鎖定和擦除數(shù)據(jù)操作）。實驗表明，該仿真能有效地滿足CAB系統(tǒng)的功能性需求，對于進(jìn)一步研究CAB系統(tǒng)的應(yīng)用有著積極的促進(jìn)作用。

5 結(jié)束語

采用訂閱通告/機制和數(shù)據(jù)同步技術(shù)，克服了傳統(tǒng)地址簿中因聯(lián)系人信息改變而使本地地址簿數(shù)據(jù)失效的問題，還可以保證用戶持有的各個終端的地址簿數(shù)據(jù)同步更新。融合地址簿系統(tǒng)極大地方便了用戶對本地地址簿和網(wǎng)絡(luò)地址簿的管理，在未來的通信系統(tǒng)，特別在3G通信中將會獲得廣泛的應(yīng)用。

1 IETF,RFC2426.vCard MIME directory profile,September 1998,http://www.ietf.org/rfc/rfc2426.txt

2 中國移動PIM業(yè)務(wù).http://www.chinamobile.com/whatsnew/newrelease/pim/

3 OMA,OMA-TS-SyncML-RepPro-V1_2,SyncML representation protocol,June 2007

4 中國聯(lián)通北京分公司如意通信錄業(yè)務(wù). http://www.bj.chinaunicom.com/products/sjgdhlwyw/zzyw/txl/

5 Open Mobile Alliance(tm).http://www.openmobilealliance.org/

6 OMA,OMA-RD-CAB-V1_0.Converged address book requirements,December 2008

7 OMA,OMA-MWG-CAB-2008-0112.CAB architecture modelA,October 2008

8 OMA,OMA-MWG-CAB-2008-0108.CAB architecturemodelB,October 2008

9 OMA,OMA-MWG-CAB-2008-0114.CAB architecture model C,October 2008

10 OMA,OMA-MWG-CAB-2008-0129.CAB architecture model D,October 2008

11 OMA, OMA-AD-XDM-V2_0.XML document management architecture,September 2008

12 OMA,OMA-TS-DS-V2.1.Data synchronization syntax,November 2008

13 OMA,OMA-AD-DM-V1_3.Devicemanagementarchitecture,January 2009

14 IETF,RFC 3261.SIP:session initiation protocol,June 2002,http://www.ietf.org/rfc/rfc3261.txt

15 IETF,RFC 4825.The extensible markup language (XML)configuration access protocol(XCAP),May 2007

16 W3C Recommendation,XQuery 1.0.An XML query language,January 2007,http://www.w3.org/TR/2007/RFC-xquery-20070123

17 IETF,RFC 3265.SIP-specific event notification，June 2002，http://www.ietf.org/rfc/rfc3265.txt