專利名稱：：用于轉發(fā)文檔的可擴展標記語言文檔管理系統(tǒng)方法
技術領域：
：本發(fā)明涉及實現(xiàn)XML文檔管理(XDM)轉發(fā)功能的系統(tǒng)和方法，XDM轉發(fā)功能是XDMv2.0使能器的文檔管理功能之一。
背景技術：
：作為XDMv2.0使能器的文檔管理功能之一的XDM轉發(fā)功能在XDMv2.0》見才各(requirement)[XDM2一RD](參見"OMAXMLDocumentManagementrequirements"，Version2.0,OpenMobileAlliance,OMA-RD-XDM-V2—0，URL:http:〃www.ope譲obilealliance.org/)和XDMv2.0架構[XDM2—AD](參見"OMAXMLDocumentManagementArchitecture"，Version2.0，OpenMobileAlliance,OMA-AD-XDM-V2—0，URL:http:〃麗w罕nmobilealliance.org/)中描述。XDM轉發(fā)功能是指由用戶向其他用戶轉發(fā)存儲在XDMS中的XML文檔的文檔管理功能。在執(zhí)行轉發(fā)中，用戶或者可以轉發(fā)相應的XML文檔的全部，或者可以選擇性地轉發(fā)該XML文檔的一個部分，或者可以在修改其一部分后轉發(fā)該XML文檔。在接收到XML文檔之后，接收用戶做出該用戶是否將接受所轉發(fā)的XML文檔的決定。當接收用戶接受XML文檔時，該經(jīng)轉發(fā)的文檔歸該用戶所有并^皮存儲在XDMS內該用戶的用戶目錄中。同時，用于[XDM2—RD]的XDM轉發(fā)功能的規(guī)格概要技術包括與上述XDM轉發(fā)功能相關聯(lián)的以下說明1、具有適當權限的用戶能夠向其他用戶(多個用戶)轉發(fā)XML文檔(多個文檔)；2、轉發(fā)請求用戶能夠在不影響原始目標XML文檔的同時對其一部分進行調整之后轉發(fā)該目標XML文檔；3、在接收到所轉發(fā)的文檔之后，接收用戶能夠做出該用戶是否將接受所轉發(fā)的文檔的決定。接著，當該接收用戶接受所轉發(fā)的XML文檔時，其相應的部分生成為該接收用戶的新的XML文檔以存儲所產(chǎn)生的XML文檔。
發(fā)明內容技術問題需要用于實現(xiàn)XDM轉發(fā)功能的系統(tǒng)和方法。技術解決方法
技術領域：
：本發(fā)明提供用于實現(xiàn)如在[XDM2—RD]和[XDM2一AD]中所描述的XDM轉發(fā)功能的系統(tǒng)和方法。依照本發(fā)明的一個方面，提供一種用于實現(xiàn)XDM(XML文檔管理)轉發(fā)功能的XDM系統(tǒng)，該XDM系統(tǒng)包括XDM轉發(fā)請求用戶，用于發(fā)送轉發(fā)請求消息以便向XDM轉發(fā)接收用戶轉發(fā)期望轉發(fā)的XML文檔；XDMS，用于接收轉發(fā)請求消息，確定XDM轉發(fā)請求用戶是否已經(jīng)被授權來轉發(fā)所請求的目標XML文檔，當XDM轉發(fā)請求用戶想要修改并轉發(fā)目標XML文檔時確定XDM轉發(fā)請求用戶是否已經(jīng)被授權來調整目標XML文檔，當XMD轉發(fā)請求用戶已經(jīng)被授權來轉發(fā)目標XML文檔并^皮授權來修改目標XML文檔時向XDM轉發(fā)接收用戶轉發(fā)所請求的XML文檔、或通過篩選和修改而調整的所請求的XML文檔的一部分，執(zhí)行用于確定XDM轉發(fā)接收用戶是否能夠接受所轉發(fā)的XML文檔、或XML文檔的經(jīng)調整部分的接收者授權，以及當已經(jīng)成功執(zhí)行接收者授權時確認XDM轉發(fā)接收用戶擁有所轉發(fā)的XML文檔、或XML文檔的經(jīng)調整部分并將經(jīng)處理的XML文檔存儲在XDM轉發(fā)接收用戶的用戶目錄中；以及XDM轉發(fā)接收用戶，用于當XDMS做出針對接收者授權的請求時根據(jù)用戶響應向XDMS發(fā)送與XML文檔的4矣受相關聯(lián)的響應。根據(jù)本發(fā)明的另一方面，提供一種用于在包含XDM轉發(fā)請求用戶、XDMS以及XDM轉發(fā)接收用戶的XDM系統(tǒng)中實現(xiàn)XDM轉發(fā)功能的方法，所述方法包括以下步驟由XDM轉發(fā)請求用戶將用于向XDM轉發(fā)接收用戶轉發(fā)期望的XML文檔的轉發(fā)請求消息發(fā)送到XDMS;由XDMS接收該轉發(fā)請求消息，確定XDM轉發(fā)請求用戶是否已經(jīng)被授予用于轉發(fā)所請求的目標XML文檔的轉發(fā)權限或者當XDM轉發(fā)請求用戶想要修改并轉發(fā)該目標XML文檔時確定XDM轉發(fā)請求用戶是否已經(jīng)被授權來4務改目標XML文檔，當XDM轉發(fā)請求用戶已經(jīng)被授權來轉發(fā)目標XML文檔以及一皮授權來#"改該目標XML文檔時向XDM轉發(fā)接收用戶轉發(fā)所請求的XML文檔、或者通過篩選及修改而調整的所請求的XML文檔的一部分，以及執(zhí)行用于確定XDM轉發(fā)接收用戶是否能夠接受所轉發(fā)的XML文檔、或XML文檔的經(jīng)調整的部分的接收者授權；當XDMS做出針對接收者授權的請求時，由XDM轉發(fā)接收用戶根據(jù)用戶的響應向XDMS發(fā)送與XML文檔的接受相關聯(lián)的響應；以及當已經(jīng)成功地執(zhí)行接收者授權時，由XDMS確認XDM轉發(fā)接收用戶擁有所轉發(fā)的XML文檔并將經(jīng)處理的XML文檔存儲在用戶目錄中。有益效果根據(jù)在本發(fā)明中所提出的方法，可以具體地實現(xiàn)XDMV2.0服務使能器的XDM轉發(fā)功能。圖1是示出根據(jù)本發(fā)明實施例的單個域中的XDM轉發(fā)功能實現(xiàn)的結構以及各個結構之間的信令的信令流程圖2是示出根據(jù)本發(fā)明實施例的多個域中的XDM轉發(fā)功能實現(xiàn)的結構和各個結構之間的信令的信令流程圖3是示出根據(jù)本發(fā)明實施例的將目標XML文檔直接插入到XDM轉發(fā)請求中的情況的信令流程圖4是示出根據(jù)本發(fā)明實施例的通過僅將目標XML文檔的XCAPURI插入到XDM轉發(fā)請求中來間接地記錄目標XML文檔的情況的信令流程圖5是示出根據(jù)本發(fā)明實施例的將篩選規(guī)則應用到XML文檔的情況的概念圖6是用于解釋根據(jù)本發(fā)明實施例的用于路由XDM轉發(fā)請求的方法當中的用于首先路由XDM轉發(fā)請求到XDM轉發(fā)請求用戶的XDMS的方法的圖7是用于解釋根據(jù)本發(fā)明實施例的用于路由XDM轉發(fā)請求的方法當中的用于首先路由XDM轉發(fā)請求到XDM轉發(fā)接收用戶的XDMS的方法的圖8是用于解釋#4居本發(fā)明實施例的用于多個用戶的XDM轉發(fā)的圖；圖9是用于解釋才艮據(jù)本發(fā)明實施例的用于組的XDM轉發(fā)的圖；圖10是示出'application/vnd.oma.foward+xml，的XML結構的示例的圖；圖11是示出根據(jù)本發(fā)明實施例的通過利用直接包含XDM轉發(fā)目標XCAPPUT請求來實現(xiàn)XDM轉發(fā)功能的情況的過程流程的URI的XCAPPUT請求來實現(xiàn)XDM轉發(fā)功能的情況的過程流程的圖。具體實施例方式以下，將參照附圖描述本發(fā)明的示范性實施例。在下面的描述中，相同的元件將由相同的引用數(shù)字來指明，盡管它們在不同的圖中示出。此外，在本發(fā)明的下面的描述中，當其可能使本發(fā)明的主旨更不清楚時，將省略這里合并的公知功能以及結構的詳細描述。在本發(fā)明中，將更詳細地提出實現(xiàn)如在[XDM2—RD]以及[XDM2—AD]中所描述的XDM轉發(fā)功能的方法。為此，本發(fā)明定義XDMC內的XDM轉發(fā)請求者、XDMS內的XDM轉發(fā)處理引擎、以及XDM轉發(fā)接收者的功能以便描述它們的交互操作。這里，XDM轉發(fā)請求者請求用戶的XDM轉發(fā)功能，XDM轉發(fā)處理引擎執(zhí)行所請求的XDM轉發(fā)功能，而XDM轉發(fā)接收者做出用戶是否將接受所接收的XML文檔的決定。首先，將參照圖1說明根據(jù)本發(fā)明實施例的XDM轉發(fā)功能實現(xiàn)的概況。圖1是示出根據(jù)本發(fā)明實施例的單個域中的XDM轉發(fā)功能實現(xiàn)的結構以及各個結構之間的信令的信令流程圖。圖1對應于本發(fā)明的一個實施例，其中，存儲相應的XML文檔的XDMS、以及相應的XML文檔纟皮傳遞到的XDM轉發(fā)接收用戶的XDMS屬于相同的單個域。首先，在步驟100，考慮用戶10(其為XDM客戶端(XDMC),該客戶端實際被用戶用于XML文檔管理請求，下文簡單地稱之為"XDM轉發(fā)請求用戶")請求向特定的用戶14(此后，筒單地稱之為"XDM轉發(fā)接收用戶")轉發(fā)XDMS12內的特定的XML文檔。這里，可以轉發(fā)相應的XML文檔的全部、或部分、或經(jīng)^修改的部分。XDM轉發(fā)i青求;波轉發(fā)到存儲相應的XML文檔的XDMS12。在步驟102,具有所傳遞的XDM轉發(fā)請求的XDMS12(實際上，XDM轉發(fā)請求是在XDMS內的XDM轉發(fā)處理引擎中處理的)確定XDM轉發(fā)請求用戶10是否已經(jīng)被授予用于所請求的XML文檔的XDM轉發(fā)權限。此外，當XDM轉發(fā)請求用戶10打算修改并轉發(fā)相應的XML文檔時，XDMS12還確定XDM轉發(fā)請求用戶10是否已經(jīng)被授予用于相應的XML文檔的修改8權限。在本發(fā)明中，如上所描述的這樣的一系列的權限查驗過程被稱為請求者授權。這里，僅當XDM轉發(fā)請求用戶具有轉發(fā)整個的相應的XML文檔的權限時，XDM轉發(fā)請求用戶才能夠轉發(fā)甚至相應的XML文檔的一部分而不用單獨的請求者授權。這是因為差別僅在于發(fā)送整個XML文檔和發(fā)送XML文檔的一部分。接著，XDMS12成功地執(zhí)行請求者授權。在步驟104，當請求包含有關相應的XML文檔的篩選器或修改的信息時，在應用該信息到相應的XML文檔之后，XDMS12調整將要轉發(fā)的相應的XML文檔的一部分。否則，XDMS12直接進行到步驟106。在步驟106,XDMS12轉發(fā)相應的XML文檔到XDM轉發(fā)接收用戶14,其是用于傳遞相應的XML文檔到XDM轉發(fā)接收用戶的XDMS的過程。當請求篩選或修改相應的XML文檔時，XDMS傳遞根據(jù)所請求的篩選和修改而調整的XML文檔。在單個域的情況下，由于一個XDMS在單個域中主管相同的應用唯一ID(AUID)，用于存儲相應的XML文檔的XDMS可以與相應的XML文檔將被傳遞到的XDM轉發(fā)接收用戶的XDMS相同。因此，該過程可以是用于傳遞相應的XML文檔到相同的XDMS內的XDM轉發(fā)接收用戶的用戶目錄的過程。然而，由于XDMS是功能實體，在實際實現(xiàn)時，一個XDMS也能夠由多個實例來實現(xiàn)。在這種情況下，轉發(fā)過程也可以是主管相同的AUID的兩個XDMS實例之間的傳遞過程。在步驟108中，已經(jīng)傳遞相應的XML文檔的XDMS12確定XDM轉發(fā)接收用戶14是否能夠接受相應的XML文檔。在本發(fā)明中，確定XDM轉發(fā)接收用戶14是否能夠接受XML文檔的過程被稱為接收者授權。執(zhí)行這樣的接收者授權的方法包括兩種方法，這兩種方法包括根據(jù)已經(jīng)由用戶定義的存取規(guī)則來確定XDM轉發(fā)接收用戶是否能夠接受XML文檔而不直接地詢問用戶的先發(fā)(proactive)方法；以及直接地詢問用戶以便查驗XDM轉發(fā)接收用戶是否能夠接受XML文檔的反應(reactive)授權方法。當在步驟108成功地執(zhí)行接收者授權之后，由于所轉發(fā)的XML文檔屬于相應的XDM轉發(fā)接收用戶所有，XDMS12將所轉發(fā)的XML文檔存儲在XDM轉發(fā)接收用戶的用戶目錄中(步驟IIO)。在步驟112，XDMS12響應于XDM轉發(fā)請求而將執(zhí)行結果發(fā)送到XDM轉發(fā)請求用戶10。9參照圖2,將描述其中存儲相應的XML文檔的XDMS與相應的XML文檔將被傳遞到的XDM轉發(fā)接收用戶14的XDMS不相同的多個域的情況。圖2是示出本發(fā)明所提出的XDM轉發(fā)功能實現(xiàn)的結構和操作的信令流程圖。首先，在步驟200，XDM轉發(fā)請求用戶IO請求向特定的XDM轉發(fā)接收用戶22轉發(fā)XDMS12中的特定的XML文檔。這里，相應的XML文檔的全部、或部分、或經(jīng)修改的部分可以;故轉發(fā)。XDM轉發(fā)請求被傳遞到存儲相應的XML文檔的XDMS12。在步驟202,具有所傳遞的XML文檔的XDMS12執(zhí)行請求者授權，用于確定XDM轉發(fā)請求用戶10是否已經(jīng)被授予用于所請求的XML文檔的XDM轉發(fā)的權限以及當XDM轉發(fā)請求用戶10打算修改并轉發(fā)相應的XML文檔時確定XDM轉發(fā)請求用戶10是否已經(jīng)^皮授予用于相應的XML文檔的修改的權限。在成功地執(zhí)行請求者授權之后，在步驟204，XDMS12通過篩選或修改相應的XML文檔來調整相應的XML文檔。在步驟206,所請求的XML文檔或在步驟204中所調整的XML文檔被傳遞到域B(即，另一個域)的XDMS20。在域B的XDMS20已經(jīng)傳遞XML文檔之后，在步驟208,XDMS20執(zhí)行用于確定XDM轉發(fā)接收用戶22是否可以接受所轉發(fā)的XML文檔的接收者授權。在XDMS20成功地執(zhí)行接收者授權之后，所轉發(fā)的XML文檔為相應的XDM轉發(fā)接收用戶所有，并且接著在步驟210,XDMS20將XML文檔存儲在該用戶的用戶目錄中。在步驟212中，XDMS20響應于XDM轉發(fā)請求而將執(zhí)行結果通過域A的XDMS12發(fā)送到XDM轉發(fā)請求用戶10。多個域之間的XDM轉發(fā)功能的基本程序也與在上面所描述的圖2中的單個域的相同。然而，區(qū)別在于所請求的XML文檔是從一個域的XDMS被傳遞到另一個域的XDMS,而且接收者授權和所轉發(fā)的XML文檔的存儲是由XDM接收用戶所屬的域的XDMS來執(zhí)行的?，F(xiàn)在將在下文說明在實現(xiàn)XDM轉發(fā)功能中要考慮的問題。首先，本發(fā)明所提出的實現(xiàn)被設計為不僅滿足上述[XDM2一RD]的XDM轉發(fā)功能的需要，而且也適于下面的四種條件。1、使用XCAPURI表示目標XML文檔1將參照圖3來說明，當作為XDM轉發(fā)目標的XML文檔被直接包含在XDM轉發(fā)請求中時，XDM轉發(fā)請求用戶在做出針對XDM轉發(fā)的請求之前首先從XDMS取得相應的XML文檔，并接著將已取得的XML文檔插入到XDM轉發(fā)請求中。XDM轉發(fā)請求用戶10通過向XDMS12發(fā)送XCAPGET請求消息來請求目標XML文檔。接著，XDMS12通過200OK消息傳遞目標XML文檔。在接收到該消息之后，XDM轉發(fā)請求用戶10將包含目標XML文檔的XDM轉發(fā)請求消息發(fā)送到XDMS12。在接收到目標XML文檔之后，XDMS12將XDM轉發(fā)的結果傳遞到XDM轉發(fā)請求用戶10。如從圖3可以看到的，這樣的過程導致當在XDM轉發(fā)請求用戶10與XDMS12之間反復交換目標XML文檔時發(fā)生信令開銷。具體地，當XDM轉發(fā)請求用戶的接入網(wǎng)絡是無線網(wǎng)絡時，信令開銷可以導致接入信道資源的浪費以及響應時間的延遲。本發(fā)明提出一種實現(xiàn)XDM轉發(fā)功能的方法以解決這些問題，該方法為不將作為XDM轉發(fā)目標的XML文檔直接包含在XDM轉發(fā)請求中，而僅將記錄存儲目標XML文檔的XDMS的位置的XCAPURI包含在XDM轉發(fā)請求中，以使得相應的XML文檔能夠被間接地記錄在XDM轉發(fā)請求中。現(xiàn)在將參照圖4說明通過僅包含代替目標XML文檔的XCAPURI的XDM轉發(fā)請求消息來執(zhí)行轉發(fā)功能的過程。首先，XDM轉發(fā)請求用戶10將包含目標XML文檔的XCAPURI的XDM轉發(fā)請求消息發(fā)送到XDMS12。接收到XDM轉發(fā)請求消息之后，然后，XDMS12將XDM轉發(fā)的結果傳遞到XDM轉發(fā)請求用戶10。目標XML文檔的間接記錄導致XDM轉發(fā)請求用戶和XDMS之間的信令開銷的減少。因此，可以解決如圖3的情況中由反復的信息交換引發(fā)的信道資源的浪費以及響應時間的延遲。2、應用篩選器(filter)到目標XML文檔在本發(fā)明中，XDM轉發(fā)請求用戶有可能僅將目標XML文檔的一部分XDM轉發(fā)而不修改原始目標XML文檔。為此，本發(fā)明使得XDM轉發(fā)請求用戶能夠通過向目標XML文檔應用篩選器而在XDM轉發(fā)請求中包含用于目標XML文檔的篩選規(guī)則。此時，篩選器的應用使得僅僅轉發(fā)由篩選規(guī)則導致的目標XML文檔的一部分而不影響原始目標XML文檔。圖5是示ii出對目標XML文檔應用篩選的概念圖。參照圖5，通過篩選規(guī)則502將原始XML文檔500產(chǎn)生為經(jīng)篩選的XML文檔504。3、路由XDM轉發(fā)請求的方法路由XDM轉發(fā)請求的方法包括兩種方法，包括首先路由XDM轉發(fā)請求到XDM轉發(fā)請求用戶的XDMS的方法、以及路由XDM轉發(fā)請求到XDM轉發(fā)接收用戶的XDMS的方法。當XDM轉發(fā)請求用戶的域不同于XDM轉發(fā)接收用戶的域時，這兩種方法具有清楚的差別，其將參照圖6和圖7來說明。首先，將參照圖6來說明首先路由XDM轉發(fā)請求到XDM轉發(fā)請求用戶的XDMS的方法。參照圖6，域A的XDM轉發(fā)請求用戶10通過XDM轉發(fā)請求消息做出針對XDM轉發(fā)的請求，并接著首先路由XDM轉發(fā)請求到域A(其為與XDM轉發(fā)請求用戶IO的域A相同的域)的XDMS12。接著，XDMS12查驗域A(即，相同的域)的XDM轉發(fā)請求用戶的權限并向包括XDM轉發(fā)接收用戶的域B的XDMS20傳遞由篩選規(guī)則調整的XML文檔的一部分、或者目標XML文檔。在確定域B(即，相同的域)中的XDM轉發(fā)接收用戶22能否接收所傳遞的文檔之后，域B的XDMS20存儲所傳遞的文檔。在相同的域之內的信息的交換和管理是容易的，而在不同的域之間的信息的交換和管理是通過網(wǎng)絡到網(wǎng)絡的接口(NNI)來完成并且需要更復雜的程序。在這點上，圖6所示的方法是高效率的。這是因為，圖6的方法中，在互相不同的域中發(fā)生的操作僅對應于在它們之間的目標XML文檔、或目標XML文檔的經(jīng)篩選的部分的簡單的交換，而不需要諸如其授權的管理。如上所述，因為請求者授權和接收者授權僅在每個相同域內的XDMS和用戶之間完成，在互相不同的域之間可以不需要授權。此外，在圖6所示的方法中，當目標XML文檔在互相不同的域之間傳遞時，由于僅傳遞根據(jù)篩選產(chǎn)生的XML文檔的一部分，由XDM轉發(fā)請求用戶篩選的期望的部分永遠不會被傳遞到不同的域。因此，可以這樣說圖6中所示的方法在XDM轉發(fā)請求用戶的信息的安全維護方面是可靠的。其次，將參照圖7說明路由XDM轉發(fā)請求到XDM轉發(fā)接收用戶的XDMS的方法。參照圖7，域A的XDM轉發(fā)請求用戶10通過XDM轉發(fā)請求消息做出針對XDM轉發(fā)的請求，并將XDM轉發(fā)請求路由到將在其中存儲轉發(fā)的目標的域B的XDM轉發(fā)接收用戶22的XDMS20。域B的XDMS20向已經(jīng)存儲相應的XML文檔的域A的XDMS12做出針對相應的XML文檔的請求。接著，域A的XDMS12確定XDM轉發(fā)請求用戶10是否已經(jīng)被授予恰當?shù)臋嘞?，并且將目標XML文檔傳遞到域B的XDMS20。當XDM轉發(fā)請求包含篩選規(guī)則時，域B的XDMS22通過向所傳遞的XML文檔應用該篩選規(guī)則來調整所傳遞的XML文檔的一部分，確定XDM轉發(fā)接收用戶能否接受經(jīng)調整的XML文檔，并存儲該經(jīng)調整的XML文檔。由于圖7中所描述的方法基于如下事實向到XDMS傳遞XDM轉發(fā)請求的過程和取得目標XML文檔的過程兩者都是在互相不同的域之間通過NNI接口來執(zhí)行的，因此圖7中所描述的方法不如圖6中所描述的方法高效率。此外，在圖7所示的方法中，篩選規(guī)則與XDM轉發(fā)請求一起被傳遞到另一個域，接著另一個域的XDMS(即，域B的XDMS)直接將該篩選頭見則應用到相應的XML文檔。因此，在XDM轉發(fā)請求用戶10的信息的安全維護中可能存在問題，因為包含由XDM轉發(fā)請求用戶篩選的期望的部分的相應的XML文檔的全部必須凈皮傳遞到域B(即，另一個域)。因而，本發(fā)明建議在實現(xiàn)XDM轉發(fā)功能時圖6的方法應當優(yōu)先于圖7的方法。4、XDM轉發(fā)到或者多個用戶或者一個組如圖8和圖9中所示，根據(jù)XDM轉發(fā)功能，應當通過使用一個XDM轉發(fā)請求將相應的XML文檔XDM轉發(fā)到或者多個XDM轉發(fā)接收用戶、或者一組XMD轉發(fā)接收用戶。參照圖8,XDM轉發(fā)請求用戶10向XDMS12發(fā)送針對多個用戶的XDM轉發(fā)請求消息。接著，XDMS12接收到該消息，并針對相應的n個XDM轉發(fā)接收用戶14-1至14-n執(zhí)行XDM轉發(fā)功能。如圖9中所示，當由XDM轉發(fā)請求用戶10向XDMS12所請求的用以轉發(fā)XML文檔的目標對應于組時，即，針對組的XDM轉發(fā)請求的情況，XDMS12從組XDMS13取得該組信息、執(zhí)行成員的分辨(resolution)，并執(zhí)行到組成員15-1至15-n中的每一個的XDM轉發(fā)。接著，基于上述的[XDM2—RD]的XDM轉發(fā)功能的需要以及上述的在實現(xiàn)XDM轉發(fā)功能中要考慮的四個問題，本發(fā)明提出XDM轉發(fā)功能的具體13的實現(xiàn)方法。具體地，本發(fā)明提出用于實現(xiàn)XDM轉發(fā)功能的四種方法。首先，為了解釋本發(fā)明所提出的XDM轉發(fā)功能實現(xiàn)，使用下面表l的PoC組文檔作為XDM轉發(fā)的目標的XML文檔的示例。假設，用作示例的PoC組文檔是基于[PoC—XMD](文獻"PoCXDMSpecification",Version1.0,OpenMobileAlliance,OMA-TS-PoC—XDM-Vl一O,URL:http:〃www.openmobilealliance.org/)來描述的，該文檔的所有者是"sip:source—user@example.com",而該文檔的文4牛名是"source畫poc-group.xml，，。還々支i殳PoC纟且文才當已經(jīng)#皮存4渚在當前"example.com"i或的PoCXDMS(它的AUID是org.openmobilealliance.poc)內的"sip:source—user②example.com"的用戶目錄中。因此，PoC組文檔在XDMS內的位置#L記錄為"http:〃xcap.example.com/org.openmobilealliance.poc/users/sip:source—user@example.com/source-poc-group.xml"的XCAPURI。表1<xmlversion-"l.CTencoding=rTTTF-8rr>,,<groupxmln3-"um:oma:xml:poc:list-service"xmlns■rl-"um::pai:aias■xml:ns:resource-lisWixmlns:ci:-"ui:n:ietf:params:xial:n3:co腿on-policY"丄xmliis:ocr=r'urn:oma:xiial:xdm:co腿on-policy"x,<list-serviceuri=rrsip:my_pocgroupOexample.co加').，<list>,i<entxyuri-"tel:+43012345678V>,,<entrYui:i="tel:+822546511Mr7>'(entryuri-"sip:cherE沖lossoml3example■coia"/》<enti:Yuri="sip:jayGother.domain,comr7>.,<invite-meml)ers>true</invite-members>.,<cr:Euleset>.,<cc:ruleid-"45x<cr:conditions:^,<oci::0thee-identity/>，</cr:conditions:*-'<ce:sctions>.,<j0in-hand丄ing>falus</30in-handling>,,</cr:rulesetx,</list-se]:vice>.,首先，將說明XDM轉發(fā)實現(xiàn)方法當中的利用HTTPPOST請求的方法。本發(fā)明提出XDM轉發(fā)功能應當基于具有以下子分句(sub-clause)的HTTPPOST請求來實現(xiàn)，而且XDM系統(tǒng)依照下面四種情況來處理XDM轉發(fā)請求。1、XDM轉發(fā)請求的實現(xiàn)本發(fā)明提出下面的基于HTTPPOST請求的XDM轉發(fā)請求的實現(xiàn)。下面的表2示出與XDM轉發(fā)請求的實現(xiàn)相關I關的示例。表2POSThttp://xcap,example,com/org,openmobilea丄丄iance,poc/forwai:dHTTP/1,1'Host:xc鄰，exaiople,comtUseE—Agent:XDM—c丄ient/0HA丄，0>Date:Tue,01Aug200617:00:01GHT+9.,X-XCAP-Assei:ted-Identity:"sip:fooTarciei:@example,com",Content—Type:application/vrwi,o邊a,forward+xmliContent-Length-(…)，<xmlversion-"l,0"encoding-"UTF-8">.i<foEwacdid-"xxx"xmlnWum:03aa:xial:xdBi:forwai:d">t<!—XCAPURIofthetargetXMLdocumenttobeXDMForwarded—>,<targetappid-"oi:g.opermobileal丄iance.poc"》http:〃xcap.example.com/org.openmobilealliance.poc/users/sip:source一userGexamplecom/source-poc-group.xml,<!—Listo￡recipientsofXDMForward—<i:ecipients>,,"ecipient>sip:recipient一Jjexample,coia</recipient>,<recipient>sip:recipient一20example.com</Eecipient>,<recipient>sip:foi:wai:d-gi:oup(3example.com</recipient>,<recipient>sip:usei:@exaiaple2.com</recipient>f</Eecipients>.,l)請求行HTTPPOST請求的請求行，XDM轉發(fā)請求通過其來記錄HTTPURI,該HTTPURI包含用于處理記錄在內容主體中的XDM轉發(fā)的XDMS、以及該XDMS內的XDM轉發(fā)處理引擎兩者。在這種情況中，XDM轉發(fā)請求被路由到的XDMS必須是其中已經(jīng)存儲將要XDM轉發(fā)的XML文檔的場所。在表2的示例中，請求行為"http:〃xcap.example.com/org.openmobilealliance.poc/forward，，。其意味HTTPPOST請求被路由到PoCXDMS(即，"example.com"域的"負責org.openmobilealliance.poc"的AUID的XDMS)，而且將要在該PoCXDMS內的"/forward"中的XDM轉發(fā)處理引擎中處理該HTTPPOST請求。用于在內容主體中所記錄的目標XML文檔的XCAPURI的格式為"http:〃xcap.example.com/org.openmobilealliance.poc/users/sip:source—user@example.com/source-poc-group.xml",其中,"http:〃xcap.example.com/org.openmobilealliance.poc"對應于存儲文檔的XDMS的地址。因此，注意到用于存儲文檔的XDMS的地址與HTTPPOST請求的請求行中所記錄的PoCXDMS的地址相同。即，這個目標XML文檔已經(jīng)被存儲在PoCXDMS中。2)XDM轉發(fā)請求用戶的ID做出XDM轉發(fā)的請求的XDM轉發(fā)請求用戶10可以被記錄在"X-XCAP-Asserted-ID"[XDM—Core]中(文獻"XMLDocumentManagement(XDM)Specification",Version1.0,OpenMobileAlliance,OMA-TS-XDM_CORE-Vl—0,URL:http:〃www.openmobilealliance.org/)或者相應的HTTP首部中?？梢岳斫?，XDM轉發(fā)請求用戶與表2的示例中的"sip:forwarder②example.com，，相對應。3)XDM轉發(fā)的內容XDM轉發(fā)的內容必須基本上如下來記錄(a)作為XDM轉發(fā)的目標的XML文檔的XCAPURI;以及(b)XDM轉發(fā)的內容將要傳遞到的(多個)XDM轉發(fā)接收用戶。這樣的內容可以用XML表達。在這種情況下，有必要定義用于表達的新的內容類型。本發(fā)明中，布支設該類型為"application/vnd.oma.foward+xml"。圖10示出于其中記錄XDM轉發(fā)內容的XML結構的示例。參照圖10，根元素是〈forward、其包括記錄作為XDM轉發(fā)的目標的XML文檔的XCAPURI的〈target〉、記錄XDM轉發(fā)接收用戶的<recipients>、以及記錄要應用到目標XML文檔的篩選規(guī)貝'J的〈forward-filter-set〉的子元素。其中，由于〈targe1^和〈recipients〉基本上記錄XML文檔轉發(fā)的內容，所以它們必須不可避免的存在，而〈filter-rule-set〉可以選擇性的存在。以下，將更詳細地說明篩選規(guī)則。在〈recipients〉中，每一個XDM轉發(fā)接收用戶々ecipient〉是由々ecipien^子元素來記錄的。因此，可能存在多個〈recipient〉元素。表2示出"application/vnd.oma.foward+xml"內容類型的XDM轉發(fā)內容的示例。也就是說，記錄在〈target〉元素中的目標XML文檔的XCAPURI是"http:〃xcap.example.com/org.openmobilealliance.poc/users/sip:source一user@example.com/source-poc-group.xml"。在這種情況中，〈targe1^元素的"auid，，屬性代表它的AUID并且提供XML文檔的種類。而且，記錄在々ecipients〉中的XDM轉發(fā)接收用戶對應于sip:recipient—l@example.com、sip:recipient—2@example.com以及sip:forward—group@example.com、sip:user@example2.com。如在要考慮的問題中所描述的，可以完成針對多個XDM轉發(fā)接收用戶16或該組的XDM轉發(fā)。根據(jù)表2的示例很清楚，目標XML文檔要被XDM舉爭發(fā)到"example.com"i或內的用戶"sip:recipient—l@example.com"和"sip:recipient一2@example.com"以及ii"sip:forward—group@example.com"、以及"example2.com"i或內的"sip:user②example2.com"。4)XDM轉發(fā)篩選器如上所述，XDM轉發(fā)請求用戶使用篩選器，以使得能夠僅能夠XDM轉發(fā)目標文檔的一部分。為此，可以在XDM轉發(fā)請求中包含篩選規(guī)則。這樣的篩選規(guī)則必須基本上記錄下面的條件。(a)要應用篩選規(guī)則的目標XML文檔(b)篩選規(guī)則應用的情況(如，僅當XML文檔被轉發(fā)到特定的接收者時應用篩選身見則)(c)記錄要篩選的內容如圖10的示例中所示的，"application/vnd.oma.foward+xml，，的內容在<forward-filter-set>中記錄應用于記錄在<target>中的目標XML文檔的篩選規(guī)則。這樣的〈forward-filter-set〉可以具有多個〈forward-filter〉子元素，而每個〈forward-filter〉子元素記錄每個篩選規(guī)則?！磃orward-filter〉的"id"屬性代表該篩選規(guī)則的標識，而"recipient"屬性代表應用所記錄的篩選MJ'j時的XDM轉發(fā)接收用戶。在沒有"recipient"屬性的情況中，在向全部XDM轉發(fā)接收用戶進行XDM轉發(fā)時應用所記錄的篩選規(guī)則。實際上，記錄篩選規(guī)則的方法包括兩種方法，包括僅記錄要^皮從原始XML文檔濾除的且將被排除在外的一部分的方法；以及僅記錄要被篩選到原始XML文檔并被包含在內的一部分的方法。它們被記錄在〈exclude〉元素以及〈include〉元素中，即〈forward-filter〉的子元素。其中，要被從目標XML文檔濾除且在XDM轉發(fā)時排除的該部分的最高元素的XPATH節(jié)點而[XCAP](文獻"TheExtensibleMarkupLanguage(XML)ConfigurationAccessprotocol(XCAP)，，，J.Rosenberg,May5,2006,URL:http:〃www.ietf.org/intemet-drafts/draft-ietf-simple-xcap-ll,txt)#皮i己錄在〈exclude〉元素中。其中，在目標XML文檔中要被篩選且在XDM轉發(fā)時被包括的部分的XPATH節(jié)點URI[XCAP]被記錄在<include>元素中。〈ns-bindings〉元素指定在記錄XPATHURI時所使用的名字空間綁定。下面17的表3示出一個示例，其中將上面所解釋的篩選規(guī)則添加到表2的XDM轉發(fā)請求中。表3_POSThttp:〃xc鄰，example,com/org.openmobilealliance,poc/foi:wardHTTP/1,1,Host:xcap.example,coi,User-Agent:XM-c丄ieiat/0HA1.0,Date:Tue,01Aug200617:00:01GHT+9,X-XCAP-Asserted-Identity:"sip:foruai:deEl3example.com"!Content-Type:鄰plication/vnd.oma.forward+xml,Content-Length:(…),<xmlveEsion="l.0"encoding-"UTF-3"x'<!—XCAPURIofthetai:getXHLdocumenttobeXDHForwarded—>.,<tai:getappid-"org,openmobileslliance,poc'),http:"xcap,example,com/ong,openmobilealliance-poc/usees/sip:sounce一user@example-com/soiu:ce-pac-<!—ListofrecipientsofXDMForuaEd—<recipients>,"ecipient>sip:recipient一10example.com</recipient>,"ecipient>sip:recipient一2Gexample.com</i:ecipieiit>t<Eecipient>sip:forwai:d_gEoup0example,com</i:ecipient>,<Eecipient>sip:userGexaiaple2.coia</i:ecipient>,</necipients>,<!--FilterrulestobeappliedtothetargetXHLdocumentwhenXDMForwarded-->,ietf:paEams:xml:ns:co皿on-p01ic/>><!—"xyz'filterrule—>s<forward-filtecid-'rxyz'r>:<excludetype='fxpath">.i/poc:group/poc:list-service/poc:invite-memljeEs,i</exclude>><excludetype=f'xpath">,/poc:gEoup/poc:list-sei:vice/ci::Euleset,,</exclude>.,</forward-filter>,<!—'abc'filterEule-->，<forward—filterid="atic'rrecipient="sip:recipient_2@example,com">.<excludetype-rrxpath">,,/poc:gnoup/poc:list-service/poc:list/poc:entry[6uri-"sip:cherrYblosson8example.com"]'</foi:wai:d-filtei:>，</forwai:d>,表3中的XDM轉發(fā)請求的內容示出應用于具有"http:〃xcap.example.com/org.openmobilealliance.poc/users/sip:source一user@example.com/source-poc-group.xmr的XCAPURI的PoC組文檔(即，XDM轉發(fā)請求的目標)的兩種類型的篩選規(guī)則。一種是具有"xyz"的"id"的篩選規(guī)則，以及另一種是具有"abc"的"id"的篩選規(guī)則。在"xyz"篩選規(guī)則中，沒有"recipient"屬性，因此，篩選規(guī)則在XDM轉發(fā)時被應用于所有的XDM轉發(fā)接收用戶，從而從目標PoC組文檔中移除々ulese^的所有內<!--Wamesapcebinding—<ns-binding3>,<ns-bindiiigprefix-"pocr'urn='fum:<ns-bindingprefix-"cr"urn-"um:</ns-bindings>,容。在"abc"篩選規(guī)則中，僅當XML文檔被轉發(fā)到"sip:recipient—2⑥example.com"的用戶時應用篩選規(guī)則，而且"abc"篩選規(guī)則記錄可以從PoC組列表中移除記錄"sip:cherryblossom⑥example.com"的<entry>。下面的表4示出一種情況，其中將"xyz"篩選規(guī)則應用于將要傳遞到除了"sip:recipient—2@example.com"的接收者以外的其余的接收者的目標PoC組文檔。圖5示出一種情況，其中"xyz"篩選器和"abc"篩選器兩者都被應用于將要傳遞到"sip:recipient—2@example.com的接收者的目標PoC組文檔。其中，注意到，僅當其為XDM轉發(fā)時才應用這些篩選規(guī)則而不影響原始XML文檔。表4《，xndveEsion-"l.O"encoding=r'UTF-8">.<gE0upxialns'uEn:oma:xml:poc:list-service"丄xndns:i:丄-"uni:ietf:parajas:xml:ns:resoui:ce—JLi3t:s"丄xmlns:ci:="uni:ietf:paEams:xial:ns:conoaon-poliCY"i<list-serviceui:i-"sip:mY_pocgi:oup@example,com"><<enti:Yuri=r'tel:+43012345678'7>.;(entryuri="tel:+6225465U54r7>,"ntryuri=r'sip:cheri:Yblossoml3example,conL'7>f<entryui:i="sip:jay(other,domain,com"/:^</Ust>i<71ist-seEvice>i</gnoup>,___表5<xmlversion-"l.O"encoding-"UTF_8'r>(<groupxmlns="UEn:oma:xml:poc:list-service"ixmlns:cl=r'urn:ietf:params:xml:ns:resource—lists"丄xmln3:cr-"ui:ii:ietf:paEam3:xnLl:ns:co皿ori-policy"丄xm丄ns:ocr="ui:n:oma:xml:Kdm:co腿on—policy'),<list-serviceui:i="sip:mY_pocgEoup@e>tample,com">,<li3t>,<enti:YUEi="tel:+430123W78'7>""ntEYuri="i:el:+82254651154'7>,<entryuci-"sip:jay@other-domain.com'7>,</list>,</list-seEvice>i</gEoup>,___2、已實現(xiàn)的XDM轉發(fā)請求的處理已實現(xiàn)的XDM轉發(fā)請求是由圖1和圖2的程序來處理的。也就是說，表3中所實現(xiàn)的XDM轉發(fā)請求的情形是按照下面來處理的1)"sip:forwarder@example.com，，的用戶做出表3中所示的XDM轉發(fā)的請求并且該XDM轉發(fā)請求一皮傳遞到example.com域的PoCXDMS;2)example.comi或的PoCXDMS確定"sip:forward@example.com"的用戶是否已經(jīng)被授權以XDM轉發(fā)"sip:source—user@example.com"的用戶的"source-poc-group.xml";193)在隨后查驗之后，example.com域的PoCXDMS通過應用"xyz"篩選規(guī)則到"source-poc-group.xml"來生成表4的內容。PoCXDMS還通過應用"xyz，，篩選規(guī)則和"abc，，篩選規(guī)則來生成表5的內容；以及4)example.com域的PoCXDMS將"sip:forward一group@example.com"識別為共享的組URI,并因此從example.com域的共享的XDMS取得其成員列表。在這種情況中，假設該組的全部成員都是example.com域的用戶。表4的內容凈皮傳遞到成員列表用戶的用戶以及"sip:recipient—1@example.com，，的用戶的PoCXDMS中的用戶目錄，并且表5的內容被傳遞到"sip:recipient—2@example.com，，的用戶目錄。此夕卜，example.com域的PoCXDMS辨識到"sip:user⑥example2.com，，的用戶存在于example2.com域中，并因此傳遞表4的內容到example2.com域的PoCXDMS。example2.com域中的處理遵循子步驟5-1)之后的處理；5)example.comi或的PoCXDMS確定"sip:forward—group@example.com"的成員用戶以及"sip:recipient—l@example.com"的用戶是否想要才妄收表4的內容以及"sip:recipient—2@example.com"的用戶是否想要接收表5的內容。在這種情況中，PoCXDMS可以根據(jù)由用戶預定義的針對example.com域的PoCXDMS的規(guī)則、或者到相應的用戶的直接的請求來執(zhí)行接收者授權。6)在成功地執(zhí)行接收者授權之后，example.com域的PoCXDMS在每一個用戶的用戶目錄中存儲每一個所傳遞的內容。在這種情況中，能夠使用任何文件名。其中，用戶名是通過將XDM轉發(fā)請求用戶的ID添加到原始XML文檔來表示的。也就是說，所存儲的內容是在source-poc-group[forwarder@example.com].xml的文〈牛名下來存+者的。7)example.comi或的PoCXDMS向"sip:forwarder②example.com，，發(fā)送XDM轉發(fā)請求的執(zhí)行結果。已經(jīng)如步驟4)中所述接收表4的內容的example2.com域的PoCXDMS依照下面的子步驟執(zhí)行5-1)example2.comi或的PoCXDMS確定"sip:user②example2.com,，的用戶是否想要接收表4的內容；6-1)在成功地執(zhí)行接收者授權之后，example2.com域的PoCXDMS將表4的內容存儲在"sip:user⑥example2.com"的用戶的用戶目錄中；7-1)example2.com域的PoCXDMS向example.com域的PoCXDMS發(fā)送XDM轉發(fā)請求的執(zhí)行結果。3、在域之間傳遞目標XML文檔或其經(jīng)篩選的部分的方法在步驟4)中，向example2.com域的PoCXDMS傳遞表4的內容可以通過HTTPPUT請求或通過XDM轉發(fā)請求來實現(xiàn)。下面的表6和表7示出其中分別通過HTTPPUT請求或通過XDM轉發(fā)請求來實現(xiàn)傳遞方法的示例。表6說明了通過使用HTTPPUT請求在域之間傳遞目標XML文檔或其經(jīng)篩選的部分的方法。表7說明通過使用XDM轉發(fā)請求在域之間傳遞目標XML文檔或其經(jīng)篩選的部分的方法。表6PUThttp:〃xcap,ex簡p:Le2,com/org,openmobilea:Lliance,poc/useES/sip:U3eE(5example2,com/source-poc-gEoup[f0orai:der8exaniple.com],xmlHTTP/1.1,Host:xc鄰.examp丄e2.com,User-Agent:XDM-client/0MAl,0iDate:Tue,01Aug200617:00:05,X—XCAP-AsseEted-Identity:"sip:fOEwarderGexaiaple-com",Conwnt-Type:appliestion/vnd.oma,poc.groups+xml;Content-Length:(…)，<xmlversion-"!.0rrencoding-"UTF-8''>,<groupxmlri3-"ui:risoma:xml:poclist—setvice"ixia丄ns:i:l='rui:ii:ietf:pai:am3:xml:n3:Eesoui:ce—lists"丄xmlns:cr-"ucn:ietf:params:xml:ns:common-policy"ixialns:ocr=r'urn:oma:xml:xdm:common-policY">*<list-serviceuri='rsip:my_pocgi:oup@example,com"》<list>,'<enti:yuri-"tel:+43012345678'V>i(entryuri="sip:cherrrytilossom@exaiaple,com'7>.<entryuri-"sip:jay@othei:.domain,com"/>.</list>,</list-sei:vice><</gEOup>.i表7POSTlittp:〃xcap,example2,com/org,opemaobileailiance，poc/fonwardHTTP/1,l.,Host:xc鄰2，example.com.'User-Agent:XDM-clieni:/0HA1,0>Date:Tue,01Aug200617:00:05,X-XCAP-Asserted-Identi巧"sip:fOEwardeEGexample.com"-,Content-Type:application/vnd,oma，fooraEd+xml,Coni:ent"-Length:(…)-,<xmlvei:sion=rrl,CTencoding="UTF-8r'>(<foi:waEdid-'r123'rxialns-''ui:n:oma:xnil:xdm:foi:Tirai:d">'<!—InsteadofXCAPURI,thefilteredcontentsofthetargetXHLdocumenttobeXDMForwardedisdirectlyspecified—>,<targetappid-"oi:g,ope皿obilealliance，poc'r>'<![CDATA[;<XHdversion-"l.0"encoding="UTF-8r'>.,<groupxmlns-"um:oma:xnd:poc:list-service"1xmlns:El="um:ietf:params:xml:ns:Eesoui:ce-li3ts"丄xmlns:cWurn:ietf:params:xml:ns:common-policy"xmlns:ocr='rum:oma:xial:xdm:common-policy">■><list-sei:viceuni=r'sip:myjpocgi:oup(3exaiaple,com,-,<Ust>.,<enti:yui:i-"i:el:+43012345678'7》<enti:Yui:i-"tel:+62254651154'7>,<entcyuri-"sip:cherrYblossom0exaffiple,com'V〉，<entryuri="sip:jay@other.domain.contr'/>-'</list-service>,i*c/gEoup>;']]>'<!—ListofrecipientsofXDMForwand—>i<i:ecipients>,"ecipient>sip:usei:l]example2.com</i:ecipient>.</cecipients>,<!--Uotethatthere'3noneedfoi:filterdescriptionanymorebecausethefilteredcontentisalreadyincludedundei:<tai:get>intheabove-->,</foi:waEd>i在如表6中所示的使用HTTPPUT的方法中，PoC組文檔的相應的經(jīng)篩選的內容被請求直接存儲到example2.com域的PoCXDMS內的"sip:user@example2.com"的用戶的用戶目錄中。其中，可以使用任何要被存儲的文件名。在本發(fā)明中，為了避免要被存儲的文件名與已有的文件名發(fā)生沖突，使用將XDM轉發(fā)請求的id添加到原始XML文檔文件名所獲得的"source-poc-group[forward⑥example.com]，M乍為示例。在如表7中所示的使用XDM轉發(fā)請求的方法中，在請求行中記錄XDM轉發(fā)處理引擎的URI、以及請求將要傳遞到的example2.com域的PoCXDMS的URI，而且直接在〈target〉元素中記錄XML文檔的經(jīng)篩選的內容代替目標XML文檔的XCAPURI。因此，不再需要〈forward-filter-set〉。請求將要傳遞到的example2.com域的XDM轉發(fā)4妄收用戶(即，"sip:user@example2.com，，的用戶)被記錄在〈recipients〉中。在這種情況中，兩種方法都需要通過"X-XCAP-Assserted-Identity"或22相應的HTTP首部來包含XDM轉發(fā)請求用戶的信息。這是因為XDM轉發(fā)請求用戶的請求是通過example.com域的PoCXDMS而不是另外的域的XDMS來執(zhí)行的，并且XDM轉發(fā)請求用戶的信息被用作用于確定接收者授權的基礎。example2.com域的PoCXDMS接收該請求，確定"sip:user②example2.com"的用戶是否想要接受所傳遞的PoC組文檔的內容，并接著存儲所傳遞的內容。這與已有的接收者授權相同。4、接收者授權的實現(xiàn)如在步驟5)中所述的，確定XDM轉發(fā)接收用戶是否接受經(jīng)XDM轉發(fā)的內容的過程被稱為接收者授權。用于執(zhí)行該過程的方法包括先發(fā)授權以及反應授權。反應授權中，在XDM轉發(fā)發(fā)生時，XDMS直接詢問XDM轉發(fā)接收用戶以確定XDM轉發(fā)接收用戶是否接受相應的內容。先發(fā)授權中，關于XDM轉發(fā)接收用戶是否接受經(jīng)XDM轉發(fā)的內容的存取許可規(guī)則根據(jù)[XDM2—Core](文獻"XMLDocumentManagement(XDM)Specification",Version2.0，OpenMobileAlliance,OMA-TS-XDM—CORE-V2—0,URL:http:〃www.openmobilealliance.org/)來記錄，并接著被存儲在XDMS中。當實際產(chǎn)生XDM轉發(fā)時，XDMS才艮據(jù)預先記錄的存取許可規(guī)則來確定XDM轉發(fā)接收用戶是否能夠接受XML文檔，而不是直接詢問XDM轉發(fā)接收用戶以確定XDM轉發(fā)接收用戶是否接受XDM轉發(fā)。在這種情況中，選擇性地，XDMS發(fā)送先發(fā)授權的結果到XDM轉發(fā)接收用戶，從而報告XDMS的哪些內容新近已被XDM轉發(fā)到相應的接收者。以下，將說明利用XCAPGET請求的方法，該方法是用于實現(xiàn)XDM轉發(fā)功能的方法的第二種方法。本發(fā)明提出用于使用XCAPGET請求的XDM系統(tǒng)，以使得XDM轉發(fā)請求能夠按照下面來實現(xiàn)及處理。借助于XCAPGET請求而記錄的內容與借助于HTTPPOST請求(其在"1、XDM轉發(fā)請求的實現(xiàn)，，中被提及，為用于實現(xiàn)XDM轉發(fā)功能的方法中的第一種方法)相同，僅在關于描述方法上XDM轉發(fā)功能與HTTPPOST之間存在略孩t的區(qū)別。23下面的表8示出根據(jù)XCAPGET請求來修改由表3中所示的HTTPPOST請求所實現(xiàn)的XDM轉發(fā)請求的示例。表8GEThttp:〃xc鄰，example,com/oropenmobilealliance.poc/usei:s/sip:source一userOexample,com/soui:ce-poc-group,xmlHTTP/1,1,<一Host:xcap.example.com.'Usei:-Agent:XDM-client/0HA1,0,Date:Tue,01Aug200617:00:01GHT+9.'X-XCAP-Asserted-Identity:"sip:forwarderGexample.com",X-XCAP-Forward-to:"sip:recipient_l@example.com'r,"sip:recipient一2(5example，com","sip:fooraEd一group@example,com","sip:usei:@example2,com",;Content-Type:application/vnd.oma,forward-filter+xml.,Content-Iiength:(…).<xmlver3ion-'rl.0"encoding="UTF-8r'>,<!—FilterrulestobeappliedtothetargetXHLdocumentwhenXDnFoEwaEded—>,<fOEwaEd-filter-set:xmlns=rrum:oma:xial:xdia:foi:wai:d—filtei:">>oiaa:xial:poc:list-service"/;^ietf:params:xml:ns:common-policY"/>'<!--'xyz'filterrule—>,<forward-filteEid="XYZ">,<excludetype-"xpath"x,/poc:group/poc:list-service/poc:invite-memiiei:s,</exclude>.,<exeludetype-r'xpath">,/poc:group/poc:list-sei:vice/ci::rulesets</exclude>,<!--"abc'filterrule—>s<forward-filteEid-"abc"recipient=rrsip:recipient一2Gexample,com">*<excludetype-"xpath—/poc:gi:oup/poc:list-service/po"li3t/poc:enti:Y[Bui:i=r'sip:chercyblossonSexample,com"].,</exclude>,</foi:war:d-filtei:>.t</fOEwai:d-filter-setx,如能夠從表8看到的，與上面在"1、XDM轉發(fā)請求的實現(xiàn)"中所提及的使用HTTPPOST的方法形成對比，使用XCAPGET的方法是基于以下事實的XDM轉發(fā)的目標XML文檔的XCAPURI、以及它們將要傳遞到的XDM轉發(fā)接收用戶沒有被記錄在XML中的內容主體中，但是，在HTTPGET請求的請求行中記錄將要XDM轉發(fā)的目標XML文檔的XCAPURI,并且，在新的HTTP首部中記錄XDM轉發(fā)將要傳遞到的用戶(為本發(fā)明的描述方便，稱之為"X-XCAP-Forward-to")。然而，XDM轉發(fā)請求用戶的ID以及XDM轉發(fā)篩選器是借助于與在"1、XDM轉發(fā)請求的實現(xiàn)，，中所提及的使用HTTPPOST的方法相同的方法來記錄的。也就是說，XDM轉發(fā)請求用戶的ID是在"X-XCAP-Asserted-Identity"或相應的HTTP首部中記錄的，并在內容主體中。24<!—Uamesapcebinding—>,<ns-bindings>,<ns-bindingprefix=''poc"urn="urn:<ns-tiindingprefix="cr"um="urn:已經(jīng)接收由XCAPGET請求所實現(xiàn)的XDM轉發(fā)請求的XDMS通過X-XCAP-Foward-to首部的存在能夠確定該請求不是通常的XCAPGET請求，而是XDM轉發(fā)請求。接著，通過使用HTTPPOST請求，XDMS執(zhí)行與用于實現(xiàn)XDM轉發(fā)的方法(包括"2、XDM轉發(fā)請求的處理"、"3、在域之間傳遞目標XML文檔或經(jīng)篩選的內容的方法，，以及"4、接收者授權的實現(xiàn)")的過程相同的過程?，F(xiàn)在，將說明使用直接包含XDM轉發(fā)的目標的XCAPPUT請求的方法，其為用于實現(xiàn)XDM轉發(fā)功能的方法當中的第三種方法。本發(fā)明提出通過在XCAPPUT請求中直接包含作為XDM目標的XML文檔或其內容來實現(xiàn)XDM轉發(fā)功能的方法。與上面所描述的用于實現(xiàn)XDM轉發(fā)功能的方法當中的第一種以及第二種方法形成對比，在第三種方法中，將目標XML文檔或其經(jīng)修改的內容代替目標XML文檔的XCAPURI直接包含在XCAPPUT請求內。因而，當XDM轉發(fā)請求用戶還沒有處理目標XML文檔時，XDM轉發(fā)請求用戶必須通過XCAPGET請求取得相應的XML文檔。接著，在XCAPPUT請求內直接記錄將要XDM轉發(fā)的相應的XML文檔或其內容。與用于實現(xiàn)XDM轉發(fā)功能的方法當中的第一種以及第二種實現(xiàn)方法相對比，在第三種實現(xiàn)方法中，由于由XDM轉發(fā)請求用戶把將要XDM轉發(fā)的內容直接包含在XCAPPUT請求內，因此不需要XDM轉發(fā)篩選器。下面的表9示出一個示例，其中XDM轉發(fā)請求用戶取得表1所示的PoC組文檔，并接著通過在XCAPPUT請求中僅包含將傳遞的已取得的PoC組文檔的期望的部分來執(zhí)行XDM轉發(fā)功能。這里，將要傳遞的已取得的PoC組文檔的期望的部分與表3的"xyz"XDM轉發(fā)篩選器所應用的內容相同。表9PUThttp:〃xcap,example,co邊/oEg，openmobilealliance.poc/users/sip:recipient_l@example,co邁/source-poc-group[foi:wai:dei:@exai[Lple.coia〗.xmlHTTP/1.1'Host:xc鄰國example,com(User-Agent:XDH-client/0M1,0」Date:Tue,01Aug200617:00:05GHT+9iX-XCAP-Asserted-IdentitY:"sip:foorai:dei:@example.com".'Content-Type:柳lication/vnd.oiaa.poc.groups+xmLContent-Length:(…)，<xmlvension-"l,CTencoding="UTF-6'r>,<groupxmlns-"ui:n:oma:xnil:poc:list-service"ixmlns:rl=rrum:ietf:paraias:xml:n3:Eesoui:ce-lists"丄xmlns:cr-"urn:ietf:params:xml:ns:co腿cm-policy''ixIaln3:ocr-"ui:n:oiaa:xml:xdm:co腿on-policy,,,<list-servicem:i-"sip:my_pocgi:oup@exaniple,com'),<entEyuri-"tel:+822S躬51154'》'<entEYUEi="sip:chei:i:ylDlossom(example,com"/X!<entr:Yuri-"sip:jay(3othei:.domain.com'7>,</list>,^/list-service:^</gi:oup>,,如在表9中能夠看到的，根據(jù)該實現(xiàn)方法，XDM轉發(fā)接收用戶的XDMS內其中將要存儲所傳遞的內容的用戶目錄、以及將要存儲的所傳遞的內容的文件名兩者都直接在XCAPPUT請求的請求行中被指定?？梢允褂萌魏挝募Ｆ渲?，通過將XDM轉發(fā)請求用戶的ID添加到原始XML文檔來表示文件名。如從圖ll可以看到的，與用于實現(xiàn)XDM轉發(fā)功能的方法中的第一種以及第二種實現(xiàn)方法形成對比，將利用XCAPPUT的XDM轉發(fā)請求直接路由到其中將要存儲目標XML文檔或其內容的XDMS。此外，與用于實現(xiàn)XDM轉發(fā)功能的方法中的第一種以及第二種實現(xiàn)方法形成對比，在XCAPPUT請求中，由于必須在XCAPPUT請求的請求行中記錄具體的XDM轉發(fā)接收用戶的用戶目錄，無法執(zhí)行XDM轉發(fā)到多個用戶或一個組。可以依照圖ll所示完成以該方式所實現(xiàn)的XDM轉發(fā)請求的一般處理過程。也就是說，當域A的XDM轉發(fā)請求用戶10不處理將要XDM轉發(fā)的XML文檔時，XDM轉發(fā)請求用戶10從域A的XDMS12取得相應的XML文檔，基于已取得的XML文檔直接將將要轉發(fā)的期望的內容包含在XCAPPUT的主體中，并直接傳遞該內容到將要轉發(fā)的域B的期望的XDMS20。域B的XDMS20確定XDM轉發(fā)接收用戶22是否能夠接收所轉發(fā)的內容，并接著將所轉發(fā)的內容存儲在XDMS20中。與第一種以及第二種實現(xiàn)方法相對比，在第三種實現(xiàn)方法中，由于XDM轉發(fā)請求用戶通過XDMS直接取得相應的內容并將已取得的內容存儲在XCAPPUT請求中，因此難以執(zhí)行針對該用戶的請求者授權。這是因為，當26XDM轉發(fā)請求用戶通過XCAPGET請求取得相應的XML文檔時，查驗該用戶是否已經(jīng)僅被授予取得這樣的XML文檔的權限。因此，即使在用戶取執(zhí)行用于確定用戶是否能夠執(zhí)行相應的XML文檔的XDM轉發(fā)的請求者授權。如上所述，通過這樣的XCAPPUT請求的XDM轉發(fā)請求被直接傳遞到于其中存儲目標的XDMS。由于內容主體內的內容是由所述請求直接請求產(chǎn)生，XDMS以與通常的XCAPPUT請求相同的方式對待及處理該請求。因而，根據(jù)該實現(xiàn)方法，以與用于XDM轉發(fā)請求用戶的接收者授權相同的方式來執(zhí)行用于XDM轉發(fā)請求的接收者授權。最后，將說明通過使用包含XDM轉發(fā)目標的XCAPURI的XCAPPUT請求的實現(xiàn)XDM轉發(fā)請求的方法，該方法是用于實現(xiàn)XDM轉發(fā)功能的方法當中的第四種方法。本發(fā)明提出通過在XCAPPUT請求中包含作為XDM轉發(fā)目標的XML文檔的XCAPURI來實現(xiàn)XDM轉發(fā)功能的方法。上述第四種實現(xiàn)方法在使用XCAPPUT請求方法方面與上面所提及的用于實現(xiàn)XDM轉發(fā)功能的方法當中的第三種方法相同。但是，第四種實現(xiàn)方法在以下方面具有區(qū)別以與第一種以及第二種實現(xiàn)方法相同的方式^f又間接記錄通過目標XML文檔的目標XML文檔的XCAPURI,而不是在直4妾的XCAPPUT請求中直接記錄目標XML文檔。在如上所述的第四種實現(xiàn)方法中，通過使用XCAPURI間接地記錄XML文檔。^v而，在第四種方法中，也能夠以與第一種以及第二種實現(xiàn)方法中相同的方式來記錄XDM轉發(fā)篩選器。表10、11和12示出以該方式實現(xiàn)的XDM轉發(fā)請求的示例。表10PUThttp://xcap,example,com/oEg,ope皿obilealliance,poc/users/sip:recipient—lGexample■com/soui:ce-poc-group[foojai:der0example,com],xmlHTTP/1,1;Host:xcap.example.com,UseE-Agent:XDM-client/0HAl，Date:Tue,01Aug200617:00:05，X-XCAP-Assert:ed-Iderii:itY:"sip:forwardeiiGexample.com"，Content-Type:message/external-body^,ACCESS-TYPE-URL;,URL="http:〃xcap，example,com/org,openmobilealliance,pocAjsens/sip:source一usei:8exaiaple,com/source-Content-Length:(...),,Content-Type:鄰plication/vnd,oma.poc.groups+xmL表llPUThttp:;7xcap,example,com/org,opeimobilealliance，pocAisei:s/sip:regroup[foEwaEdei:@examp丄e.c],xialHT丁P/丄，丄.，Host:xcap,example,com,.User-Agent:XDH-client/OHAl.0.Date:Tue,01Aug200617:00:05GHT+9.,X-XCAP-AsseEted-IdentitY:"sip:foruarderGexaiople,com",,Content-Type:multipart/mixed,boundary-zz993453,i:ipient一l(3example,com/soui:ce-poc-—zz993453..Content-Type:message/external-bodyACCESS-TYPE-URL;.,URL="htxp:〃xc鄰，example,com/org,ope皿obilealliance,poc/user3/sippoc-group.xml"r,size=…，Content-Length:(■■).,:soiuce—usedexample,com/soui:ce-Content-Type:applicstion/vnd,oma,poc,group3+xial.'Content-Description:XCAPURIofthetargetPoCGroupXMLdocument;:obeXDHForwarded,,Content-Type:applicaticm/vnd.ona.fowai:d-filteE+xml,,Content-Length:(…).'<xialversion=r'l,0'rencoding-"UTF-8"》<!--FilterrulestobeappliedtothetargetXMLdocumentwhenXDM<forwai:d-filtei:-setxmlns=rruEn:oma:xml:xdm:forwai:d-filteE">,,Forwarded--<!--Namesapcebinding--<ns-bindings>.,<ns-bindingpre￡ix="poc"urn-"ui:n:oiaa:x邁l:poc:list-service"/;*.,<ns-bindingprefiWcr"urn-"um:ietf:params:x瓜l:ns:common-policy'7》<7ns-bindings>,'<!--、ys'filterrule—》<excludetypWxpath'Vi/poc:group/poc:list-senrice/poc:invite-meiabei:s.,</exclude>.><excludetype-"xpath/poc:group/poc:list-seEvice/cr:ruleset-,</exclude:>.;</foi:ij(rai:d-filtei:-setx,—zz993453,'表1228<table>tableseeoriginaldocumentpage29</column></row><table>表10示出于通過使用包含作為XDM轉發(fā)目標的XML文檔的XCAPURI的XCAPPUT請求來實現(xiàn)XDM轉發(fā)請求的示例。表11示出于通過使用作為XDM轉發(fā)目標的XML文檔的XCAPURI、以及用于其的XDM轉發(fā)篩選器來實現(xiàn)XDM轉發(fā)請求的示例。此外，表12示出于通過使用包含作為XDM轉發(fā)目標的XML文檔的XCAPURI的XCAPPUT、以及用于其的XDM轉發(fā)篩選器來實現(xiàn)XDM轉發(fā)請求的示例。以及通過新的HTTP首部記錄XCAPURI的示例。表10及表11中，是通過使用在[RFC2017](文獻"DefinitionoftheURLMIMEExternal-BodyAccess-Type",N.Freed等，RFC2017,October1996，URL:http:〃www.ietf.org/rfc/rfc2017.txt)和「RFC44831(文獻:"AMechanismforContentIndirectioninSessionInitiationProtocol(SIPMessages)，，，E.Burger,Ed.，RFC4483,May2006,URL:http:〃www.ietf.org/rfc/rfc4483.txt)中所定義的"message/external-body"內容類型來包含XCAPPUT請求內的XML文檔的XCAPURI。此外，通過使用表ll中所示的"multipart/mixed"內容類型，可以將用于目標XML文檔的XDM轉發(fā)篩選器與"message/external-body"內容類型一起i己錄。如在表12中所示的，可以通過使用新的HTTP首部來記錄目標XML文檔的XCAPURI,并且可以通過使用XCAPPUT請求的主體來記錄其XDM在第四種實現(xiàn)方法中，以與上面所提及的用于實現(xiàn)XDM轉發(fā)功能的方法當中的第三種實現(xiàn)方法相同的方式直接指定XDM轉發(fā)接收用戶的XDMS內的將要存儲所傳遞的內容的用戶目錄以及其文件名?？梢允褂萌魏挝募?。其中，通過將XDM轉發(fā)請求用戶的ID添加到原始XML文檔來表示文件名。因此，與在第三種實現(xiàn)方法的情形一樣，將XDM轉發(fā)請求直接路由到于將要存儲目標XML文檔或其內容的XDMS。因而，在XCAPPUT請求中，必須以與第三種實現(xiàn)方法相同的方式在XCAPPUT請求的請求行中記錄具體的XDM轉發(fā)接收用戶的用戶目錄，因此，不同于第一種以及第二種實現(xiàn)方法，無法執(zhí)行XDM轉發(fā)到多個用戶或一個組。以該方式實現(xiàn)的XDM轉發(fā)請求的通常處理過程可以依照圖12中所示的來完成。也就是說，將由包含目標XML文檔的XCAPURI以及XDM轉發(fā)篩選器的XCAPPUT請求實現(xiàn)的XDM轉發(fā)請求直接傳遞到域B的XDMS20，其為將要存儲經(jīng)XDM轉發(fā)的內容的XDMS。XDMS20利用XCAPURI通過XCAPGET請求從域A的XDMS12取得目標XML文檔，然后當存在XDM轉發(fā)篩選器時，向已取得的XML文檔應用XDM轉發(fā)篩選器。接著，XDMS20確認XDM轉發(fā)接收用戶22是否能夠接受目標XML文檔的經(jīng)篩選的內容并將已接受的內容存儲在XDMS20中。在該實現(xiàn)方法中，在XDM轉發(fā)請求用戶10的信息安全維護上可能有問題，因為將XDM轉發(fā)篩選規(guī)則直接傳遞到XDM轉發(fā)接收用戶22的XDMS20,或者XDMS20直接從XDM轉發(fā)請求用戶的XDMS12取得目標XML文檔，如參照圖6和圖7針對路由XDM轉發(fā)請求的方法所述。盡管已經(jīng)參照其某些示范性實施例示出并說明了本發(fā)明，但本領域的技術人員應當理解到，于其中可以在形式及細節(jié)上作出多種變化，而不脫離由所附權利要求限定的本發(fā)明的精神和范圍。權利要求1、一種用于實現(xiàn)XDM(XML文檔管理)轉發(fā)功能的XDM系統(tǒng)，所述XDM系統(tǒng)包括XDM轉發(fā)請求用戶，用于發(fā)送轉發(fā)請求消息，以使得將期望轉發(fā)的XML文檔轉發(fā)到XDM轉發(fā)接收用戶；XDMS，用于接收所述轉發(fā)請求消息，確定所述XDM轉發(fā)請求用戶是否已經(jīng)被授予轉發(fā)所請求的目標XML文檔的權限，當所述XDM轉發(fā)請求用戶想要修改并轉發(fā)目標XML文檔時確定所述XDM轉發(fā)請求用戶是否已經(jīng)被授予調整目標XML文檔的權限，當所述XDM轉發(fā)請求用戶已經(jīng)被授予轉發(fā)所述目標XML文檔的權限、以及修改所述目標XML文檔的權限時向所述XDM轉發(fā)接收用戶轉發(fā)所請求的XML文檔、或通過篩選及修改而調整的所請求的XML文檔的一部分，執(zhí)行用于確定XDM轉發(fā)接收用戶是否能夠接受所轉發(fā)的XML文檔、或XML文檔的經(jīng)調整的部分的接收者授權，以及當已經(jīng)成功地執(zhí)行所述接收者授權時，確認所述XDM轉發(fā)接收用戶擁有所轉發(fā)的XML文檔、或XML文檔的經(jīng)調整的部分并在所述XDM轉發(fā)接收用戶的用戶目錄中存儲經(jīng)處理的XML文檔；以及所述XDM轉發(fā)接收用戶，用于當XDMS做出針對接收者授權的請求時，根據(jù)用戶的響應向XDMS發(fā)送與XML文檔的接受相關的響應。2、根據(jù)權利要求1所述的系統(tǒng)，其中，在XDM轉發(fā)請求用戶在轉發(fā)請求消息中包含用于調整及轉發(fā)XML文檔的信息并且發(fā)送包含該信息的轉發(fā)請求消息之后，當接收到包含用于調整及轉發(fā)XML文檔的信息的轉發(fā)請求消息時，XDMS確定XDM轉發(fā)請求用戶是否已經(jīng)被授予調整相應的XML文檔的權限，以及當XDM轉發(fā)請求用戶已經(jīng)被授予調整的權限時，XDMS向XDM轉發(fā)接收用戶轉發(fā)通過應用該調整信息到相應的XML文檔而獲得的XML文檔。3、根據(jù)權利要求2所述的系統(tǒng)，其中，所述用于調整及轉發(fā)XML文檔的信息與用于對于轉發(fā)請求僅對經(jīng)篩選的XML文檔執(zhí)行XDM轉發(fā)而不修改原始XML文檔的篩選規(guī)則相對應。4、根據(jù)權利要求3所述的系統(tǒng)，其中，當接收到的轉發(fā)請求消息包含所述篩選規(guī)則時，XDMS在通過轉發(fā)權限向XDM轉發(fā)接收用戶轉發(fā)所請求的XML文檔時應用該篩選規(guī)則，并接著轉發(fā)經(jīng)應用的XML文檔。5、才艮據(jù)權利要求1所述的系統(tǒng)，其中，XDMS在XDM轉發(fā)接收用戶的用戶目錄中存儲所轉發(fā)的XML文檔并將轉發(fā)執(zhí)行結果發(fā)送到XDM轉發(fā)請求用戶。6、根據(jù)權利要求1所述的系統(tǒng)，其中，當XDM轉發(fā)接收用戶不包含在相同的域中時，在向XDM轉發(fā)接收用戶轉發(fā)所請求的XML文檔時，XDMS轉發(fā)所請求的XML文檔到包含相應的XDM轉發(fā)接收用戶的域的具有相同的應用唯一ID(AUID)的XDMS。7、根據(jù)權利要求1所述的系統(tǒng)，其中，當將要轉發(fā)的XML文檔被傳遞到包括XDM轉發(fā)接收用戶的域的XDMS時，該XDMS執(zhí)行接收者授權以確定XDM轉發(fā)接收用戶是否能夠接受XML文檔，以及當已經(jīng)成功地執(zhí)行接收者授權時確認XDM轉發(fā)接收用戶擁有所轉發(fā)的XML文檔并將經(jīng)處理的XML文檔存儲在XMD轉發(fā)接收用戶的用戶目錄中。8、根據(jù)權利要求1所述的系統(tǒng)，其中，轉發(fā)請求消息包含與用于轉發(fā)的XML文檔相對應的XCAPURI。9、一種在包括XDM轉發(fā)請求用戶、XDMS及XDM轉發(fā)接收用戶的XDM系統(tǒng)中實現(xiàn)XDM轉發(fā)功能的方法，所述方法包括以下步驟由XDM轉發(fā)請求用戶向XDMS發(fā)送用于轉發(fā)期望的XML文檔到XDM轉發(fā)接收用戶的轉發(fā)請求消息；由XDMS接收轉發(fā)請求消息，確定XDM轉發(fā)請求用戶是否已經(jīng)被授予用于所請求轉發(fā)的目標XML文檔的轉發(fā)權限或者當XDM轉發(fā)請求用戶想要修改并轉發(fā)目標XML文檔時確定XDM轉發(fā)請求用戶是否已經(jīng)被4受予修改目標XML文檔的權限，當XDM轉發(fā)請求用戶已經(jīng)^先授予轉發(fā)目標XML文檔的權限以及修改該目標XML文檔的權限時向XDM轉發(fā)接收用戶轉發(fā)所請求的XML文檔、或通過篩選及修改而調整的所請求的XML文檔的一部分，以及執(zhí)行用于確定XDM轉發(fā)接收用戶是否能夠接受所轉發(fā)的XML文檔、或XML文檔的經(jīng)調整的部分的接收者授權；當XDMS做出針對接收者授權的請求時，由XDM轉發(fā)接收用戶根據(jù)用戶的響應向XDMS發(fā)送與XDM文檔的接受相關的響應；以及當已經(jīng)成功地執(zhí)行接收者授權時，由XDMS確認XDM轉發(fā)接收用戶擁有所轉發(fā)的XML文檔并將經(jīng)處理的XML文檔存儲在用戶目錄中。10、根據(jù)權利要求9所述的方法，其中，XDM轉發(fā)請求用戶在轉發(fā)請求消息中包含用于調整及轉發(fā)XML文檔的轉發(fā)信息并且發(fā)送包含該信息的轉發(fā)請求消息。11、根據(jù)權利要求IO所述的方法，還包括下列步驟當XDMS接收到包含用于調整及轉發(fā)XML文檔的信息的轉發(fā)請求消息時，由XDMS確定XDM轉發(fā)請求用戶是否已經(jīng)被授予調整相應的XML文檔的權限；以及向XDM轉發(fā)4妄收用戶轉發(fā)通過向相應的XML文檔應用調整信息而獲得的XML文檔。12、根據(jù)權利要求11所述的方法，其中，所述用于調整及轉發(fā)XML文檔的信息與用于對于轉發(fā)請求僅對經(jīng)篩選的XML文檔執(zhí)行XDM轉發(fā)而不修改原始XML文檔的篩選規(guī)則相對應。13、根據(jù)權利要求12所述的方法，還包括步驟當接收到的轉發(fā)請求消息包含篩選規(guī)則時，由XDMS在通過轉發(fā)權限向XDM轉發(fā)接收用戶轉發(fā)所請求的XML文檔時應用篩選規(guī)則，并接著轉發(fā)經(jīng)應用的XML文檔。14、根據(jù)權利要求9所述的方法，還包括步驟由XDMS將所轉發(fā)的XML文檔存儲在XDM轉發(fā)接收用戶的用戶目錄中，并將轉發(fā)執(zhí)行結果發(fā)送到XDM轉發(fā)請求用戶。15、根據(jù)權利要求9所述的方法，還包括步驟當XDM轉發(fā)接收用戶不包含在相同的域中時，在向XDM轉發(fā)接收用戶轉發(fā)所請求的XML文檔時，由該XDMS轉發(fā)所請求的XML文檔到包含相應的XDM轉發(fā)接收用戶的域的具有相同的應用唯一ID(AUID)的XDMS。16、根據(jù)權利要求9所述的方法，還包括步驟當將要轉發(fā)的XML文檔被傳遞到包括XDM轉發(fā)接收用戶的域的XDMS時，由該XDMS執(zhí)行用于確定XDM轉發(fā)接收用戶是否能夠接受XML文檔的接收者授權，以及當已經(jīng)成功地執(zhí)行接收者授權時確認XDM轉發(fā)接收用戶擁有所轉發(fā)的XML文檔并在XDM轉發(fā)接收用戶的用戶目錄中存儲經(jīng)處理的XML文檔。17、根據(jù)權利要求9所述的方法，其中，所述轉發(fā)請求消息包括與用于轉發(fā)的XML文檔相對應的XCAPURI。全文摘要公開一種用于實現(xiàn)在[XDM2_RD]和[XDM2_AD]中描述的XDM轉發(fā)功能的系統(tǒng)和方法。所述方法包括步驟如下由XDM轉發(fā)請求用戶向XDMS發(fā)送用于轉發(fā)期望的XML文檔的轉發(fā)請求消息；由XDMS接收轉發(fā)請求消息，確定XDM轉發(fā)請求用戶是否已經(jīng)被授予針對所請求轉發(fā)的目標XML文檔的轉發(fā)權限，當XDM轉發(fā)請求用戶已經(jīng)被授予權限以轉發(fā)目標XML文檔時轉發(fā)所請求的XML文檔到XDM轉發(fā)接收用戶，執(zhí)行用于確定XDM轉發(fā)接收用戶是否能夠接受所轉發(fā)的XML文檔的接收者授權，以及當已成功地執(zhí)行接收者授權時確認XDM轉發(fā)接收用戶擁有所轉發(fā)的XML文檔并將經(jīng)處理的XML文檔存儲在用戶目錄中。文檔編號G06F17/00GK101506799SQ200780030327公開日2009年8月12日申請日期2007年8月16日優(yōu)先權日2006年8月16日發(fā)明者吉迪岡塔·文卡特斯瓦,吳載權,旭金申請人:三星電子株式會社