移動網(wǎng)絡(luò)推送業(yè)務(wù)技術(shù)報告——華為

1、yd/t 移動網(wǎng)絡(luò)推送業(yè)務(wù)技術(shù)報告ics 19目 次1 業(yè)務(wù)概述31.1 push安全需求31.2 系統(tǒng)元素52 業(yè)務(wù)特征62.1 pap62.2 push ota協(xié)議82.3 push特定的媒體類型92.4 尋址102.5 安全考慮123 push 代理網(wǎng)關(guān)服務(wù)133.1 概述133.2 ppg 的操作133.3 客戶端尋址214 push訪問協(xié)議244.1 概述244.2 pap協(xié)議處理過程分析244.3 pap尋址284.4 消息格式294.5 控制元素和屬性314.6 版本控制424.7 能力協(xié)商454.8 pap 參考信息454.9 舉例514.10 基于http的pap535 pu

2、sh ota 協(xié)議545.1 概述545.2 協(xié)議變量545.3 wsp上的push ota協(xié)議（ota-wsp）555.4 http上的push ota （ota-http）625.5 sip上的pushota協(xié)議（ota-sip）805.6 會話初始請求966 push 消息1056.1 概述1056.2 push 消息定義1066.3 代理規(guī)則1097 push客戶端與應(yīng)用接口1107.1 概述1107.2 push客戶端-應(yīng)用接口（push-cai）定義1107.3 安全考慮113附錄a （資料性）114附錄b114（資料性）114i1 業(yè)務(wù)概述1.1 push安全需求本技術(shù)報告定義與

3、push業(yè)務(wù)相關(guān)技術(shù)及安全相關(guān)的安全要求。push技術(shù)允許業(yè)務(wù)的使用者能接收推送的數(shù)據(jù)到他們的移動客戶端上。最初一個用戶可以去瀏覽push發(fā)起者pi維護(hù)的網(wǎng)頁。pi將提供業(yè)務(wù)給用戶。一個push業(yè)務(wù)的例子可以是本地的天氣預(yù)報業(yè)務(wù)，pi每天早上推送本地天氣預(yù)報到用戶的客戶端。 push的結(jié)構(gòu)定義了三個實體：push業(yè)務(wù)發(fā)起者pi， push代理網(wǎng)關(guān)ppg和客戶端。當(dāng)推送無連接的內(nèi)容到用戶的客戶端時，pi與ppg使用pap協(xié)議進(jìn)行交互。ppg依次編譯push消息，并經(jīng)過ota協(xié)議發(fā)送到用戶的客戶端。push的安全方面的定義當(dāng)前還不能滿足行業(yè)中各類提供wap push業(yè)務(wù)供應(yīng)商的安全需要。因此，定義

4、push的各種安全需求是必要的。最終的目的是為了在pi與客戶端之間有一個完整的安全鏈，這樣用戶將可以完全相信客戶端將收到的push消息是來自可信任的發(fā)起者的。圖 1 push框架上圖展示了 push框架中的四個實體。不同實體間的安全/信任關(guān)系是push 安全的關(guān)鍵方面。這些關(guān)系及相關(guān)的關(guān)鍵問題有： 用戶應(yīng)能夠信任pi傳遞的內(nèi)容是其請求的內(nèi)容。 用戶應(yīng)能夠信任ppg傳遞的內(nèi)容是其從pi請求的內(nèi)容，并且用戶支持相應(yīng)的push-ota的操作。e.g. 會話初始請求。 pi應(yīng)該能夠信任ppg不會對push內(nèi)容做目標(biāo)push客戶端及push-ota協(xié)議需要轉(zhuǎn)化的格式之外的任何修改。pi和ppg之間的交互

5、一般將會在面向連接的協(xié)議上發(fā)送，e.g. .http并且能夠使用已經(jīng)建立的internet安全協(xié)議，如ssl等，來確保保密性，完整性和鑒權(quán)。ppg與客戶端的交互按以下兩種方式進(jìn)行： 面向無連接push 面向連接push面向無連接push可以使用ota方法發(fā)送，最常用的為sms。當(dāng)前，當(dāng)使用面向無連接的push時，未陳述安全問題。當(dāng)使用面向連接的push時，各自承載層使用底層的安全協(xié)議，例如如果http協(xié)議則使用ssl。在nat和公共ip地址的終端情況時將要注意安全相關(guān)問題。1.1.1 威脅分析安全風(fēng)險解釋：l 未授權(quán)的會話初始：嘗試使一個設(shè)備與一個未授權(quán)的ppg建立一個push會話（通過sir

6、）。這個未授權(quán)的會話發(fā)起可能引發(fā)攻擊，導(dǎo)致用戶的個人信息（信息盜?。┍I取或向用戶發(fā)送垃圾郵件。l sir一般通過sms傳遞，未授權(quán)的sir通過ip層上傳遞的風(fēng)險或許很低，但仍需要驗證。 l 有害的內(nèi)容傳遞：任何破壞用戶業(yè)務(wù)或威脅網(wǎng)絡(luò)安全的內(nèi)容的傳遞。有害內(nèi)容傳遞的目的可能使業(yè)務(wù)中斷，盜取，導(dǎo)致用戶被攻擊或病毒擴(kuò)散。它可以直接在設(shè)備上操作，或欺騙設(shè)備或用戶來取回一些有害的內(nèi)容。l 業(yè)務(wù)的拒絕：重復(fù)push消息的傳遞干擾用戶業(yè)務(wù)。業(yè)務(wù)拒絕的目的可能為了困擾用戶或騷擾用戶而更換網(wǎng)絡(luò)提供商。l 未授權(quán)的push：嘗試傳遞未請求的push內(nèi)容。下表表示了當(dāng)使用push時，不同情景的威脅分析的評估， l

7、高：相對容易實行，盡管可能不常見。網(wǎng)絡(luò)阻擋的能力較低。l 中：更多的工作完成l 低：很難意識到，網(wǎng)絡(luò)辦法容易實行場景風(fēng)險類別公共ip地址私有ip地址運營商ip策略或授權(quán)的第三方ppg 網(wǎng)絡(luò)初始的移動終止sms移動初始的sms開放接入控制未授權(quán)的會話初始lowlownonenonehighhigh有害的內(nèi)容傳遞highmediumhighhigh to low (1)highhigh業(yè)務(wù)的拒絕highmediumhighhigh to low (1)highhigh未授權(quán)的pushhighmediumhighhigh to low (1)highhigh表 1 push威脅分析評估. 有效的接入

8、控制可以大量減少風(fēng)險。情景解釋：l 公共ip設(shè)備地址移動網(wǎng)絡(luò)為設(shè)備分配公共ip地址。運營商可以提供一個ppg或依靠第三方ppg。 l 私有ip設(shè)備地址移動網(wǎng)絡(luò)為設(shè)備分配私有ip地址。第三方ppg 實現(xiàn)的push傳遞非常復(fù)雜，需要私網(wǎng)到公網(wǎng)的地址轉(zhuǎn)換（nat），運營商專門提供一個ppg。l 運營商或授權(quán)的第三方ppg指定開放的pi策略ppg不提供特殊的push來源、地址、內(nèi)容類型、或服務(wù)質(zhì)量的控制。l 運營商或授權(quán)的第三方ppg進(jìn)行接入控制的pi策略ppg 對push來源、地址、內(nèi)容類型、或服務(wù)質(zhì)量提供一些級別的接入控制。l 網(wǎng)絡(luò)發(fā)起的止于移動設(shè)備的smspush消息由基于網(wǎng)絡(luò)的sms源發(fā)起的，

9、可能包含一些其它承載網(wǎng)絡(luò)中的不安全來源。沒有根據(jù)sms來源，目的地，或內(nèi)容設(shè)定特定的控制。l 移動設(shè)備發(fā)起sms移動設(shè)備發(fā)起push消息。沒有根據(jù)sms來源，目的地，或內(nèi)容特定的控制。1.2 系統(tǒng)元素push安全需求應(yīng)在當(dāng)前push結(jié)構(gòu)框架中提出。pi為在普通web服務(wù)器上運行的一種典型的應(yīng)用，與ppg使用pap通過http連接進(jìn)行通信。ppg使用push-ota協(xié)議傳遞push內(nèi)容到客戶端。pap基于標(biāo)準(zhǔn)的internet協(xié)議，用來xml表達(dá)傳遞指令并且push內(nèi)容可以為任何mime媒體類型。 ppg負(fù)責(zé)傳遞push內(nèi)容到客戶端。這樣，其轉(zhuǎn)換pi提供的客戶端地址成為 一個移動網(wǎng)絡(luò)可以識別的格

10、式，如果客戶端當(dāng)前不可用時存儲內(nèi)容等。ppg不只完成傳遞消息的功能，它還可以通知pi關(guān)于push提交的最終結(jié)果，選擇性的取消，覆蓋或為pi請求客戶端能力。 push-ota協(xié)議是完成push框架的一部分，負(fù)責(zé)從ppg傳輸內(nèi)容到客戶端及其用戶代理。通過http（ota-http），wsp（ota-wsp）或其他協(xié)議實現(xiàn)。ppg為push框架中主要功能實體。其責(zé)任包括作為從internet向移動網(wǎng)絡(luò)push內(nèi)容的接入點，及隨之相關(guān)的所有事情（鑒權(quán)，抵制解析等）。ppg為移動網(wǎng)絡(luò)的接入點，將執(zhí)行網(wǎng)絡(luò)的接入控制策略。例如，push內(nèi)容發(fā)送權(quán)限控制。2 業(yè)務(wù)特征2.1 pappap協(xié)議為pi推送內(nèi)容到移

11、動網(wǎng)絡(luò)的方法，并且能夠?qū)ぶ菲鋚pg。 圖 2 pap框架pap原來設(shè)計是獨立于底層傳輸機(jī)制。http為首選pap傳輸?shù)膮f(xié)議，其他協(xié)議（例如smtp）可以在未來描述。pap攜帶push 相關(guān)ppg使用的控制信息。這些信息使用xml表達(dá)。例如，一個新的消息被提交到 ppg， 控制信息和push內(nèi)容都攜帶在mime multipart/relatedrfc2387體中。這意味一個單獨的mime實體被傳輸獨立于操作類型。2.1.1 pap操作 pap 支持以下操作：l push提交（pi到ppg）l 結(jié)果通知（ppg到pi）l push取消（pi到ppg）l 之前提交的push消息的替換（pi到ppg

12、）l push操作的狀態(tài)詢問（pi 到ppg）l 無線設(shè)備的能力查詢（pi到ppg） push提交push提交消息包含三個實體：控制實體，內(nèi)容實體和可選的能力實體。它們封裝放入一個的multipart/related消息中，從pi發(fā)送到ppg?？刂茖嶓w為一個xml文件，包含給ppg的傳遞指令，內(nèi)容實體是傳遞給客戶端的。在通過ota傳遞之前，ppg可轉(zhuǎn)換或不轉(zhuǎn)換內(nèi)容實體成優(yōu)化帶寬的形式?？蛇x的能力實體包含的終端能力，該信息以uaprof形式。pi可以包含此實體指示其假設(shè)的客戶端能力情況。如果此假設(shè)的能力信息與ppg識別的能力信息不一致 ，ppg可以拒絕該消息。 結(jié)果通

13、知如果pi請求關(guān)于最終傳遞的結(jié)果，結(jié)果通知消息將從ppg傳遞到pi指定的uri。該消息可以是xml實體，指示傳遞成功或失?。蛻舳瞬豢蛇_(dá)，超時等）。push框架的一個主要特點是：pi有可能依賴ppg發(fā)來的響應(yīng)。當(dāng)且僅當(dāng)目標(biāo)應(yīng)用已經(jīng)接受push內(nèi)容時，終端才會返回確認(rèn)。如果不能接受，必須中斷操作，pi知道內(nèi)容不能到達(dá)目的地。 push取消該消息是pi給ppg傳輸?shù)膞ml實體，用來取消之前提交的消息。ppg用一個xml實體進(jìn)行響應(yīng)，指示取消操作是否成功。 push替換如果pi請求替換一個之前push提交操作中提交的消息，重置可能有兩種情況：新的消息只發(fā)送給那些未接收到原

14、始消息的接受者，或新的消息應(yīng)發(fā)送給所有的接收者。任何一種情況，對于未被傳遞的接收者的原消息應(yīng)被取消。 狀態(tài)詢問狀態(tài)詢問是從pi到ppg的xml實體，用來請求之前提交消息的狀態(tài)。ppg用一個包含當(dāng)前狀態(tài)的xml實體進(jìn)行響應(yīng)。 客戶端能力詢問客戶端能力詢問從pi傳遞到ppg的xml實體，請求網(wǎng)絡(luò)中一個特定設(shè)備的能力。ppg的響應(yīng)包含一個multipart/related實體，包含兩個部分，第一部分包含請求結(jié)果，第二部分包含uaprof格式祖師的設(shè)備能力信息。 http傳輸當(dāng)pap使用http作為傳輸協(xié)議時，信息傳輸使用http post請求和響應(yīng)方法。當(dāng)h

15、ttp傳輸成功，http的響應(yīng)包含202響應(yīng)碼（已經(jīng)接受待處理），當(dāng)http處理成功， pap的響應(yīng)文件可以包含pap錯誤信息， 關(guān)于http1.1具體參見rfc2616。2.2 push ota協(xié)議push ota協(xié)議是push框架組成部分，負(fù)責(zé)將push內(nèi)容從ppg傳遞給客戶端和其用戶代理。它運行在http（ota-http）或wsp（ota-wsp）之上。ota-wsp經(jīng)常用于在ppg和客戶端之間執(zhí)行無連接的push。面向連接的push，使用ota-http或ota-wsp是可選的。圖 3 ota框架2.2.1 ota-wspota-wsp協(xié)議變量構(gòu)造上為wsp協(xié)議之上簡單的協(xié)議層，可以

16、用于oma定義的任何承載使用。ota-wsp使用由wsp提供的特性，并且擴(kuò)展push特定的需求，通過引入新的業(yè)務(wù)原語和擴(kuò)展現(xiàn)有的新的頭域。例如，ota-wsp繼承wsp的能力協(xié)商特性（可能使用uaprof），提供無連接（非確認(rèn)push）和面向連接的（非確認(rèn)和確認(rèn)的push）業(yè)務(wù)。2.2.2 ota-http此協(xié)議變量使用http完成ppg與客戶端的空中通信，主要是基于ip承載網(wǎng)絡(luò)。http變量只提供面向連接的push。push內(nèi)容通過http post方式傳遞，意味著ppg作為http客戶端并且用戶作為 http服務(wù)器。為了避免客戶端因此被混淆，在push ota中使用ota-http時客戶端

17、稱作“終端”。push ota規(guī)范定義了兩種建立一個激活的tcp連接的方法（例如，用來傳遞push內(nèi)容的一個tcp連接）。這個方法包括ppg發(fā)起的建立tcp（po-tcp）連接和終端發(fā)起建立tcp（to-tcp）連接兩種。當(dāng)承載已激活時，po-tcp允許建立一個激活的tcp連接，并且ppg應(yīng)獲知終端的ip地址。to-tcp方法為另一種情況，經(jīng)常用在與sir機(jī)制聯(lián)合使用。通過使用長期會話的概念，ota-wsp個i客戶端提供了向ppg傳遞能力信息的方法。在ota-http中，終端注冊到ppg上，提供相似的功能性。這通過ppg發(fā)送http options請求給終端完成的，終端在響應(yīng)中包含其能力和設(shè)置

18、信息（cpi）（可以選擇使用uaprof）。當(dāng)ppg已經(jīng)知道cpi后，為了提高空中傳輸?shù)男?，提供了避免信息轉(zhuǎn)發(fā)給終端的機(jī)制。ota-http也提供識別和選擇性鑒權(quán)終端和ppg的方法。鑒權(quán)方案使用rfc2617定義的“basic”和“digest” ，終端用來鑒權(quán)ppg。而向ppg鑒權(quán)終端則使用一個稍微修改的變量（rfc2617只定義了http客戶端，這里為ppg如何被鑒權(quán)的）。2.2.3 會話初始應(yīng)用（sia）無論使用ota-http或ota-wsp，客戶端需要進(jìn)行通信初始化。sia的指定就是為了完成客戶端一側(cè)通信初始化這個目的。sia監(jiān)聽來自ppg發(fā)起的sir，通過激活相應(yīng)的承載，并且和該

19、ppg聯(lián)系作為響應(yīng)。當(dāng)使用ota-wsp，經(jīng)常是客戶端發(fā)起初始化建立底層的wsp會話。當(dāng)期望建立發(fā)送push消息的wsp會話時，ppg發(fā)送sir到客戶端?？蛻舳私邮盏絪ir后，激活該sir中指明的承載，并且在該建立的承載上向指示的ppg建立一個wsp會話。sir機(jī)制經(jīng)常與 ota-http結(jié)合使用，尤其當(dāng)ppg不知道客戶端ip地址，和/或當(dāng)ppg不能激活所需的承載。這種情況下，sir指示客戶端激活一個特定的承載，并且向sir指定的ppg 建立一個激活的tcp連接（使用to-tcp方式）。無論接下來與ppg聯(lián)系時客戶端使用ota-wsp或是ota-http，發(fā)送到客戶端的sir使用面向無連接pu

20、sh（由ota-wsp提供）。在通常情況下需要確保sir足夠簡單能夠適合放到單個sms中。在多數(shù)當(dāng)前移動網(wǎng)絡(luò)中，sms是可用的，使用一個well-know客戶端地址（msisdn，）并且提供可靠的傳輸層方法（例如，當(dāng)使用面向無連接push時提供高可靠性）。2.3 push特定的媒體類型push框架允許在pi與客戶端之間傳遞任何mime媒體類型。本節(jié)描述的媒體類型的創(chuàng)建是為了滿足現(xiàn)有mime類型未能提供的功能而進(jìn)行的擴(kuò)展。其他帶有push規(guī)范化語法的媒體類型已經(jīng)由oma定義，滿足特定應(yīng)用的需求（例如mms和provisioning）。注意：如果push指定的語法既不是為媒體類型本身定義，又不是為

21、用戶代理接收特定媒體類型使用，這樣的媒體類型將放置緩存中或在push接收后刪除（whl中使用）。2.3.1 業(yè)務(wù)指示 （si）業(yè)務(wù)指示（si）媒體類型以異步方式發(fā)送通知到終端用戶的能力。例如，這樣的通知可能是一個新到的郵件，股票價格的變動，新聞頭條消息，廣告，以及余額不多的提醒。si的最基本形式包含一個短消息和一個指示業(yè)務(wù)的uri。消息在終端用戶接收后顯示，并且用戶可以選擇立即啟動uri指示的服務(wù)，也可以推遲到以后處理。如果si延遲處理，客戶端會先存儲，終端用戶可以遲些操作。除了上面給出的基本功能，si允許pi控制以下：l 用戶中斷的級別(給每個si分配一個特定的優(yōu)先級)l 替換（接收到新的s

22、i即替換舊的si）l 刪除（通過發(fā)送“delete”si，刪除一個已經(jīng)接收的si） l 過期（為si分配一個過期的時間期限）這一章節(jié)描述的媒體類型中，si是客戶端執(zhí)行push時唯一強制使用的媒體類型。2.3.2 業(yè)務(wù)加載對比于si，業(yè)務(wù)加載（sl）不含任何用戶參與過程。一個sl傳輸包含指向內(nèi)容的uri，由客戶端自動下載而不需要終端用戶確認(rèn)。還包含一個指示信息，指示內(nèi)容是否應(yīng)被執(zhí)行、呈現(xiàn)或存放進(jìn)緩存中是需要。如果內(nèi)容應(yīng)該執(zhí)行或呈現(xiàn)，pi可以控制用戶中斷的級別。2.3.3 cache 緩存操作co緩存操作媒體類型提供一個使客戶端緩存中的特定對象失效，或使共享同一uri索引的所有對象實效的方法。這個

23、特性在緩存內(nèi)容的期限時間預(yù)先不能確定的情況下使用（例如，產(chǎn)看郵箱），以及內(nèi)容變更（新郵件到達(dá)）頻率要比用戶接入快的情況下使用非常有效。2.4 尋址push地址在客戶端和應(yīng)用層出現(xiàn)。另外，兩個注冊的端口（安全和非安全）在無連接push上使用。當(dāng)面向連接的ota-wsp使用時，任何攜帶push能力集的wsp會話都可以使用。ota-http只用在面向連接的push，使用激活tcp連接概念，專門特別永在push中。更多關(guān)于端口，會話，和激活tcp連接可以在pushota查找。2.4.1 客戶端尋址 pi使用客戶端地址指令ppg push消息應(yīng)該發(fā)送到的客戶端。push ppg規(guī)范介紹了允許的地址配置。

24、l 用戶定義的識別符任意的文本字符串（例如，一個email地址）用來識別客戶端。ppg負(fù)責(zé)轉(zhuǎn)換此字符串成為一個移動網(wǎng)絡(luò)識別的地址格式。push ppg中的舉例，wappush=john.doe%40/type=user;為定義的用戶定義識別符wappush=+155519990730/type=user; 看上去向電話號碼的用戶定義識別符l 設(shè)備地址一個移動網(wǎng)絡(luò)識別的地址，例如，msisdn（sms等），或ip地址（gprs等）。push ppg中的舉例，wappush=+155519990730/type=plmn; 為一些無線網(wǎng)絡(luò)的電話號的設(shè)備地

25、址 wappush=0/type=ipv4; ipv4的設(shè)備地址type交換指示地址的類型（用戶定義或設(shè)備地址包含地址類型），并且 部分是一個ppg的internet主機(jī)名稱。更多信息，參看pushppg。2.4.2 應(yīng)用及尋址 push內(nèi)容總是指向一個設(shè)備上的特定的用戶代理（或更多一般，一個特定的應(yīng)用）。應(yīng)用識別符可以是一個uri或一個注冊在omna數(shù)字值，來識別一個用戶代理。pushmsg定義了pi在push消息中包含x-wap-application的應(yīng)用識別符。這個頭域當(dāng)ppg傳遞消息客戶端時也傳輸?shù)娇蛻舳?，允許客戶端分派消息到目的用戶代理。 o

26、ta效率和數(shù)字識別符為了提高ota效率，一個數(shù)字識別符可以用來代替一個uri。omaomna已經(jīng)為well-known的用戶代理分配了數(shù)字，例如設(shè)備wae上的瀏覽器，來避免發(fā)送一個uri的開銷。如果ppg請求推送攜帶一個應(yīng)用識別的uri的內(nèi)容，這個uri認(rèn)為是一個由omna分配的數(shù)字識別符的uri，那么這個uri用數(shù)字識別符替代。pi本身使用一個數(shù)字識別符當(dāng)push消息提交到ppg時，可能是一個未注冊的識別符。如果未注冊的識別符不建議用來配置應(yīng)用，因為可能發(fā)生沖突。這個主要是為一些還未公共配置的用戶代理使用。2.4.3 舉例假設(shè)pi已經(jīng)提交一個消息給客戶端foo，為了一個bar的應(yīng)用，到客戶端

27、foo的服務(wù)的ppg。另外，pi已經(jīng)請求消息應(yīng)該以一個確認(rèn)的方式（指面向連接的傳遞）傳遞。ppg（支持ota-http和ota-wsp）之前還未與客戶端進(jìn)行通信，因此也不知道是否其支持ota-http或ota-wsp（或兩個）。當(dāng)前沒有push會話或激活tcp連接在ppg和客戶端foo之間，也不需要建立。ppg發(fā)送一個sir到foo以一個面向無連接的方式，使用例如sms， 指示其希望推送一些內(nèi)容到應(yīng)用bar。既然ppg不知道是否客戶端支持ota-http或ota-wsp，其包含sir中兩個變量的ppg聯(lián)系點。這個請求被發(fā)送到foo中的sia，就像任何其它push內(nèi)容（例如，通過指定專用的無連接

28、的push的一個端口，并且含有sia業(yè)能夠用識別符）?？蛻舳私邮盏絻?nèi)容，考慮使用sia向前發(fā)送。sia，接收到這個請求，檢查是否目標(biāo)應(yīng)用安裝在foo中，可能用戶設(shè)置指示目標(biāo)應(yīng)用接收push內(nèi)容。應(yīng)用bar實際安裝在此客戶端上，因此客戶端在sir上執(zhí)行。假設(shè)客戶端只支持ota-wsp，意味著應(yīng)該用其向ppg建立會話。 目前，此特定設(shè)備的擁有者不希望其它人知道其設(shè)備上安裝的應(yīng)用（隱私保護(hù)）。sia注意到這點，向ppg建立一個push會話，指示會話接收任何應(yīng)用的內(nèi)容。如果用戶已經(jīng)沒有嚴(yán)格要求隱私，會話可以用的應(yīng)用可以清晰地列出來。 一旦會話已經(jīng)建立，ppg在這個會話上完成確認(rèn)的push，并且客戶端接

29、收到pi提交的push內(nèi)容?？蛻舳私邮盏竭@個內(nèi)容，查看這個內(nèi)容是給應(yīng)用bar的，并且傳遞到這個應(yīng)用。當(dāng)（僅當(dāng)）應(yīng)用負(fù)責(zé)push內(nèi)容，push原路返回確認(rèn)（如果請求的話）。2.5 安全考慮當(dāng)執(zhí)行push，安全和信任模型需要在多個領(lǐng)域內(nèi)考慮。以下給出可能遇到的問題的舉例： l pi如何被鑒權(quán)l(xiāng) ppg在其安全和信任模型中的角色l 對于pi和push內(nèi)容的接入控制策略l 客戶端如何鑒權(quán)其沒有證書的目標(biāo)不管以上的事件，push框架都有能力提供客戶端足夠的信息來提供一個可信任的模型和其自己的安全策略。2.5.1 鑒權(quán)一個push 發(fā)起者pi在一種形式或另一種形式中被鑒權(quán)，依靠pi和ppg操作的安全環(huán)境。

30、下面列出一些可能解決方案：l 會話級證書的使用（tls，ssl）如果在pi和ppg之間的網(wǎng)絡(luò)不可信任（例如，internet，一個非常大的企業(yè)內(nèi)部網(wǎng)絡(luò)），tls/ssl能在pi和ppg之間使用。l http鑒權(quán)盡管http鑒權(quán)最普通的形式為基本的鑒權(quán)（例如，一個用戶id/密碼），其它形式的http鑒權(quán)（例如，分類）可能更優(yōu)越。這種方法和tls/ssl的主要不同為tls/ssl在可測量性和隱私性更強，前者在這些方面弱一些。l 技術(shù)的結(jié)合技術(shù)應(yīng)該聯(lián)合使用。例如，pi與ppg間建立一個匿名的tls/ssl會話，因此http鑒權(quán)可以用來鑒權(quán)pi。l 共享隱秘的內(nèi)容類型參數(shù)使用共享的秘密，可能產(chǎn)生內(nèi)容類

31、型參數(shù)附加到push特定內(nèi)容類型。這些參數(shù)本質(zhì)上相似于那些為配置加載（provisioning bootstrap）的使用。l 可信任的網(wǎng)絡(luò)在一些真實的裝置情況下，pi和ppg之間的網(wǎng)絡(luò)是一個私網(wǎng)，因此，pi清晰地信任這樣的整套裝置。2.5.2 客戶端pi鑒權(quán)的委托“鑒權(quán)的委托”參考鑒權(quán)能夠傳遞的原理。如果客戶端和ppg可以建立信任，ppg可以為客戶端鑒權(quán)pi。例如，在客戶端已經(jīng)使用了wtls或waptls提供的方法來鑒權(quán)ppg，客戶端可以查看其可信任ppg列表。如果ppg列為可信任的，客戶端可以信任這個ppg，并且因此正確識別此pi。使用前面章節(jié)描述的方法，ppg可以通過各種隱私級別鑒權(quán)一個

32、pi。如果確實，ota協(xié)議可以為ppg指示此pi中傳遞給客戶端的消息是鑒權(quán)過的。如果這種方式中的ppg是可信任的，那么ppg的識別通過可以攜帶客戶端上的可選擇的過濾“whitelist”策略進(jìn)行交叉檢測。如果ppg身份不再列表內(nèi)，也不在設(shè)備上的網(wǎng)關(guān)配置集中，客戶端可以忽略接收到的任何push消息。3 push 代理網(wǎng)關(guān)服務(wù)3.1 概述push服務(wù)是wap的一個組成部分，其體系結(jié)構(gòu)如圖3所示，這個體系結(jié)構(gòu)使得信息內(nèi)容能夠從有線網(wǎng)絡(luò)上被推送到兼容wap的移動設(shè)備上。push業(yè)務(wù)技術(shù)規(guī)范主要是針對內(nèi)容提供商把內(nèi)容推送（即不需要同步請求的發(fā)送）到客戶端（即支持push相應(yīng)功能的移動設(shè)備）的需求。這與“

33、pull”技術(shù)相反?！皃ull”技術(shù)需要客戶端發(fā)出的同步請求。利用有線網(wǎng)絡(luò)和無線網(wǎng)絡(luò)之間的網(wǎng)關(guān)使得push業(yè)務(wù)更為便利。該網(wǎng)關(guān)稱為push代理網(wǎng)關(guān)（ppg）。本部分規(guī)范就是要規(guī)范ppg的功能。3.2 ppg 的操作3.2.1 概述本節(jié)主要定義ppg所執(zhí)行的操作：包括push提交處理、結(jié)果通知、傳送取消，以及push訪問協(xié)議（pap）狀態(tài)查詢等。ppg操作被定義為獨立的處理每一個push提交（包括隨后和這些push消息相關(guān)的操作）。當(dāng)然，在各push提交之間還是有一些受限的交互。例如，對于可以支持多發(fā)送優(yōu)先級的ppg，一條消息可能會影響到另一消息(如低優(yōu)先級的)的處理時間，并且最終影響到發(fā)送的成

34、敗。需要注意的是，ppg并不應(yīng)采用特定的順序發(fā)送push消息。3.2.2 push 提交處理 概述push發(fā)起者通過向ppg發(fā)送push消息觸發(fā)push的提交處理。push提交處理包括四個操作，下面三個操作在執(zhí)行時應(yīng)按照先后的順序：l push提交的接受或者拒絕；l push消息在空中傳送，前提是push消息被接受并且符合ppg的策略和push發(fā)起者的要求；l 消息傳送的結(jié)果通知，前提是push消息已經(jīng)被終端所接收，并且push發(fā)起者要求傳送結(jié)果通知。第四個操作可以接收在push消息后的任何時間執(zhí)行，這取決于ppg的實現(xiàn)，即l pap協(xié)議的push消息應(yīng)答。本節(jié)將對這四種操作予以

35、說明。 push 提交的接收和拒絕ppg對收到的每一個push提交消息可選擇接受或拒絕。ppg建議接收可能最終傳送到ota客戶端的pap push提交消息。但是如果push提交消息中包含的pap pushmessege元素不符合它的文檔定義dtd的要求，則這條push提交消息應(yīng)被拒絕。其它用來決定push提交是否被接受的標(biāo)準(zhǔn)隨具體的實現(xiàn)而定。對于空中傳送所要求的消息處理（在描述）沒有完成的已接收、但還未傳送的push消息，應(yīng)有如下的信息狀態(tài)報告：pap 屬性屬性值message-statepending.1 對先前提交的push消息的替換對先前提交的p

36、ush消息的替換是可選功能，主要完成對已提交、待push消息的替換。如果ppg支持替換功能，同時消息替換處于已確認(rèn)狀態(tài)，則ppg應(yīng)替換pap push-message消息pushpap所請求的消息。若ppg不支持替換功能，則當(dāng)push發(fā)起者發(fā)出替換請求時，ppg應(yīng)拒絕這個push提交。.2 客戶端發(fā)起的內(nèi)容請求ppg應(yīng)支持ota-http或ota-sip方法指示客戶端，pi接受客戶端在響應(yīng)中返回的內(nèi)容，以便滿足qos參數(shù)中要求的“confirmed-with-response”的傳遞方法。不支持ota-http或ota-sip方法的ppg，應(yīng)拒絕pi使用此特征的push提交操作。

37、 空中消息傳送.1 概述消息的空中傳送包括兩個功能：l 消息處理；l 消息的空中傳送。本節(jié)將描述這兩個功能。.2 消息處理.2.1 概述為準(zhǔn)備空中傳輸，ppg可能會轉(zhuǎn)換包含在push提交中的消息實體（如pushmsg中定義）。典型的轉(zhuǎn)換原因包括針對空中傳送效率的編輯或優(yōu)化，以及將內(nèi)容實體轉(zhuǎn)換成無線終端可接受的內(nèi)容類型。本節(jié)具體描述了這種轉(zhuǎn)換功能。.2.2 實體和消息頭的轉(zhuǎn)換ppg不能對任何在如rfc2616中定義的notransform緩存控制指示范圍內(nèi)無效的實體的消息體進(jìn)行轉(zhuǎn)換。否則，ppg可能會以與實現(xiàn)相關(guān)的方式進(jìn)行轉(zhuǎn)換

38、。所有被轉(zhuǎn)換實體的消息頭應(yīng)進(jìn)行修正以便能夠正確地反映被轉(zhuǎn)換的實體。所有的轉(zhuǎn)換應(yīng)與pushmsg中的要求一致。..2.2.1 wsp 特定轉(zhuǎn)換ppg應(yīng)支持wsp中所定義的二進(jìn)制消息頭編碼。除非確切知道被尋址的終端支持非編碼格式，否則，ppg應(yīng)為在ota-wsppushota上傳送而將內(nèi)容實體編碼成為對應(yīng)的壓縮二進(jìn)制格式wbxml。例如：在無連接模式發(fā)送的情況下，服務(wù)指示通常應(yīng)被編碼成wbxmlwbxml。..2.2.2 http特定轉(zhuǎn)換為了減小在空中的數(shù)據(jù)傳送量，ppg建議支持基于otahttp之上ota傳送的內(nèi)容編碼。如果ppg支持，它應(yīng)實現(xiàn)rfc1951中所定義的

39、壓縮編碼。..2.2.3 sip特定轉(zhuǎn)換為了減小在空中的數(shù)據(jù)傳送量，ppg建議支持基于ota-sip之上ota傳送的內(nèi)容編碼，如果ppg支持，ppg應(yīng)實現(xiàn)rfc1951中定義的壓縮編碼。當(dāng)ppg清楚知道目標(biāo)終端支持以二進(jìn)制格式wbxml方式編碼，則內(nèi)容實體可以用此編碼格式編碼。.2.3 x-wap-application-id（application-id）消息頭處理ppg應(yīng)按照如下說明處理 pushmsg x-wap-application-id（application-id）的消息頭信息：l 如果消息頭包含一個已在omna中注冊的app-assigned-cod

40、e的pushmsg absoluteuri格式的application-id，則ppg應(yīng)從消息頭信息中去掉所有app-assigned-code格式的application-id（ 如果存在的話） ， 然后用absoluteuri 格式的application-id 替換已注冊的app-assigned-code格式的application-id。l 如果消息頭包含一個沒有在omna中注冊app-assigned-code的pushmsgabsoluteuri格式的application-id ， 則ppg 應(yīng)使用這個值， 除非存在pushmsg app-assigned-code 格式的ap

41、plication-id。這種情況（如果存在app-assigned-code格式的application-id）下，則應(yīng)去掉absoluteuri格式的application-id。l 如果消息頭只包含pushmsgapp-assigned-code格式的application-id，則不需要進(jìn)行替換或者刪除。l 如果處理后的消息頭標(biāo)識了客戶端的默認(rèn)應(yīng)用，則ppg可能會去掉該消息頭。l 如果在push消息中沒有包含pushmsgx-wap-application-id的消息頭，則除非客戶端默認(rèn)的application-id是wml用戶代理，ppg應(yīng)加上消息頭。如果加上了消息頭，則applic

42、ation-id應(yīng)是wml用戶代理的application-id。l 如果使用ota-sip方式，ppg應(yīng)以urn形式，添加x-wap-application-id頭域的值為g.oma.pusheventapp特征標(biāo)簽作為push資源標(biāo)識符。如果是在oman注冊過的眾所周知的地址類型，那么建議使用名稱空間指定的字符串類型。否則，應(yīng)包含urn的名稱空間標(biāo)識。ppg可能會除掉含有客戶端默認(rèn)值的所有消息頭。這個默認(rèn)值可能會在ota協(xié)議定義，并利用與實現(xiàn)相關(guān)的機(jī)制進(jìn)行提供或建立。例如如果客戶端只有一種push應(yīng)用，則含有x-wap-application-id消息頭可能被去除，以優(yōu)化ota的通信。如果

43、沒有被編碼成數(shù)字格式，包含已注冊值的x-wap-application-id消息頭不能在空中傳送。.2.4 消息狀態(tài)對于上面步驟中可能遇到錯誤，或很明顯不可能成功進(jìn)行消息發(fā)送的push提交，不能嘗試發(fā)送消息。注意，這可能會導(dǎo)致發(fā)送papresultnotification-message。對于實體和消息頭轉(zhuǎn)換處理失敗的消息應(yīng)有如下的狀態(tài)報告：pap 屬性屬性值message-stateundeliverablecodetransformation-failure如果消息轉(zhuǎn)換成功，對于未傳送的消息應(yīng)有如下狀態(tài)報告：pap 屬性屬性值message-statepending3.2.2

44、.3.3 消息的空中傳送.3.1 概述該功能的目的是向ota客戶端傳送消息。實現(xiàn)這項功能的關(guān)鍵所在是push otapushota協(xié)議的選擇、確認(rèn)和非確認(rèn)push方式的選擇，以及消息的空中傳送。ppg的實現(xiàn)可能包括對消息過期和取消、消息重傳和傳送超時、承載管理和wsp會話(如果使用otawsp)、注冊上下文（如果使用otahttp）管理或注冊狀態(tài)（如果使用ota-sip）等等的測試。.3.2 push ota 協(xié)議的選擇移動終端可能會同時支持otawsp和otahttp見pushota。ppg按照與實現(xiàn)相關(guān)的方式為面向連接的push選擇ota協(xié)議變量。ppg通過發(fā)送

45、會話初始請求（sir）向終端提交選取結(jié)果，sir中包含ota-wsp和otahttp的連接點的列表。這一過程和sir在 pushota中定義。ppg應(yīng)通過獲得終端信息或網(wǎng)絡(luò)信息，根據(jù)對push客戶端已知的情況獲得push客戶端信息，選擇ota協(xié)議變量，如下：l 基于檢查在移動終端和ppg之間是否有sip注冊l 承載網(wǎng)絡(luò)是否可用l 通過查詢uaprof，判斷是否是移動終端能力支持的協(xié)議變量l pi指示push客戶端的信息還包括客戶端的承載方式列表，優(yōu)先級信息，客戶端的在線信息，能力信息，偏好信息或客戶端設(shè)置的信息等。ppg根據(jù)以上push客戶端信息，網(wǎng)絡(luò)情況信息，判斷使用的ota協(xié)議變量，向選擇

46、的push客戶端發(fā)送push消息。當(dāng)優(yōu)先級高的ota協(xié)議變量不可用時，使用下一級協(xié)議變量作為push消息的承載方式。ppg可以通過發(fā)送sir消息，并在sir消息中給出ota-wsp，ota-http和ota-sip聯(lián)系點列表讓終端選擇適當(dāng)?shù)某休d方式。此方法在push ota有定義。當(dāng)然，pi如果指示其接受客戶端在響應(yīng)中返回內(nèi)容來響應(yīng)“confirmed push ”，那么應(yīng)選擇ota-http或ota-sip方法。如果ppg無法選擇ota-http或ota-sip方法，pap應(yīng)在“resultnotificationmessage”消息中指示傳遞方法選擇失敗。.3.3 承載網(wǎng)絡(luò)選

47、擇如果在pap push-message元素的qos部分要求使用特定的承載和或網(wǎng)絡(luò)，則ppg應(yīng)使用特定的承載和或網(wǎng)絡(luò)，或?qū)τ趲в腥缦聽顟B(tài)報告的消息發(fā)送失?。簆ap 屬性屬性值message-stateundeliverabledescan appropriate, implementation-dependent valueevent-timetime or estimated time of failure.3.4 會話或注冊上下文的選擇與創(chuàng)建ppg可能會使用已有的wsp會話（如果使用otawsp）或注冊上下文（如果使用otahttp），或者采用實現(xiàn)相關(guān)的方式來創(chuàng)建合適的wsp

48、會話或注冊上下文（例如發(fā)起ota會話創(chuàng)建請求）。對于ota-sip，ppg建議使用push ota描述的流程，決定傳遞動作發(fā)起的時間。如果由于不能或失敗于創(chuàng)建合適的wsp會話或注冊上下文，ppg選擇不再做進(jìn)一步的發(fā)送，則應(yīng)報告如下的消息狀態(tài)：pap 屬性屬性值message-stateundeliverabledescan appropriate, implementation-dependent valueevent-timetime or estimated time of failure.3.5 傳送時間約束如果ppg支持傳送時間約束，則ppg不能超出pap deliver

49、-after-timestamp時間發(fā)送push消息。如果不能在pap deliver-before-timestamp時間內(nèi)傳送，則操作失敗，且應(yīng)報告如下消息狀態(tài)：pap attributevaluemessage-stateexpireddescan appropriate, implementation-dependent valueevent-timetime or estimated time of failure.3.6 空中傳送假設(shè)沒有出現(xiàn)錯誤，如果用otawsp進(jìn)行 ota傳送，則ppg應(yīng)發(fā)送確認(rèn)（po-confirmedpush）或非確認(rèn)(po-push 或 p

50、o-unit-push)方式的push原語。如果用otahttp進(jìn)行ota傳送，則ppg應(yīng)利用httppost的方法傳送消息。如果使用ota-sip方式，ppg應(yīng)使用sip invite/msrp方法傳遞消息。如果使用ota-http或ota-sip方式，pi支持接受客戶端在響應(yīng)中返回內(nèi)容來響應(yīng)“confirmed push”, x-wap-push-info頭域應(yīng)包含“response”屬性標(biāo)簽。對確認(rèn)和非確認(rèn)push方式的使用取決于pap delivery-method的屬性，并且和ppg的實現(xiàn)策略相關(guān)。..3.6.1 非確認(rèn)push方式。ppg應(yīng)利用otawsp（po-pu

51、sh.req或po-unit-push.req原語）或者otahttp發(fā)送非確認(rèn)消息。如果使用otahttp，則ppg應(yīng)報告同樣的pap result-notification消息，如同消息是利用ota-wsp以非確認(rèn)方式發(fā)送的一樣。如果ppg發(fā)送po-push.req或 po-unit-push.req原語，或ppg利用ota-http代理這些原語發(fā)送消息，則應(yīng)報告如下的消息狀態(tài)：pap attributevaluemessage-statedelivereddelivery-methodunconfirmedevent-timetime or estimated time of deliv

52、ery..3.6.2 確認(rèn)push方式ppg應(yīng)利用ota-wsp（po-confirmedpush.req原語）或ota-http發(fā)送確認(rèn)信息。接下來的處理依賴于下述的push類型。如果ppg發(fā)送了po-confirmedpush.req原語或使用ota-http，最終結(jié)果如下依賴于push信息是否得到應(yīng)答。1） 發(fā)送成功：如果ppg接收到說明成功發(fā)送到ota客戶端的po-confirmedpush.res原語，或包含說明成功發(fā)送的x-wap-push-status消息頭的http響應(yīng)，則可能在與實現(xiàn)相關(guān)的ppg重試之后，應(yīng)報告下述消息狀態(tài)：pap 屬性屬性值message-st

53、atedelivereddelivery-methodunconfirmedevent-timetime or estimated time of delivery2） 因為中斷而失?。喝绻鹥pg接收到說明是被中斷的push嘗試的po-pushabort.ind原語，或說明push信息被拒絕的x-wap-push-status消息頭（ota-http），或通過msrp failure-report指示傳遞失?。╫ta-sip），則應(yīng)報告如下的消息狀態(tài)：pap 屬性屬性值message-stateabortedcodepap-specified representation of the abo

54、rt parameter specified in push otadescan appropriate, implementation-dependent valueevent-timetime or estimated time of aborted delivery attempt3） 因為超時而失?。喝绻褂胦ta-wsp ，當(dāng)ppg 在與實現(xiàn)相關(guān)的時間周期內(nèi)沒有收到otapo-confirmedpf時超時發(fā)生。如果使用ota-http，當(dāng)ppg在與實現(xiàn)相關(guān)的時間周期內(nèi)沒有收到對http post請求的應(yīng)答時超時發(fā)生。如果使用ota-sip，當(dāng)ppg在與實現(xiàn)相關(guān)的時間周期內(nèi)沒有收到ms

55、rp success-report指示傳遞成功時，超時發(fā)生。如果超時發(fā)生時ppg選擇不再進(jìn)行發(fā)送嘗試，則應(yīng)報告如下的消息狀態(tài)：pap 屬性屬性值message-statetimeoutdescan appropriate, implementation-dependent valueevent-timetime or estimated time of last delivery attempt..3.6.3 oneshot傳遞ppg根據(jù).5.1方式傳遞“oneshot”消息。ppg應(yīng)只嘗試傳遞一次push消息，并確保底層承載也使用此種傳遞嘗試。使用該種方法時，應(yīng)報告如下消息狀態(tài)：pap 屬性屬性值message-statedelivereddelivery-methodoneshotevent-timetime or estimated time of delivery3.2.3 結(jié)果通知 概述如果在push