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

1、yd/t 移動(dòng)網(wǎng)絡(luò)推送業(yè)務(wù)技術(shù)報(bào)告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 會(huì)話初始請求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ù)報(bào)告定義與

3、push業(yè)務(wù)相關(guān)技術(shù)及安全相關(guān)的安全要求。push技術(shù)允許業(yè)務(wù)的使用者能接收推送的數(shù)據(jù)到他們的移動(dòng)客戶端上。最初一個(gè)用戶可以去瀏覽push發(fā)起者pi維護(hù)的網(wǎng)頁。pi將提供業(yè)務(wù)給用戶。一個(gè)push業(yè)務(wù)的例子可以是本地的天氣預(yù)報(bào)業(yè)務(wù)，pi每天早上推送本地天氣預(yù)報(bào)到用戶的客戶端。 push的結(jié)構(gòu)定義了三個(gè)實(shí)體：push業(yè)務(wù)發(fā)起者pi， push代理網(wǎng)關(guān)ppg和客戶端。當(dāng)推送無連接的內(nèi)容到用戶的客戶端時(shí)，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與客戶端之間有一個(gè)完整的安全鏈，這樣用戶將可以完全相信客戶端將收到的push消息是來自可信任的發(fā)起者的。圖 1 push框架上圖展示了 push框架中的四個(gè)實(shí)體。不同實(shí)體間的安全/信任關(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. 會(huì)話初始請求。 pi應(yīng)該能夠信任ppg不會(huì)對(duì)push內(nèi)容做目標(biāo)push客戶端及push-ota協(xié)議需要轉(zhuǎn)化的格式之外的任何修改。pi和ppg之間的交互

5、一般將會(huì)在面向連接的協(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時(shí)，未陳述安全問題。當(dāng)使用面向連接的push時(shí)，各自承載層使用底層的安全協(xié)議，例如如果http協(xié)議則使用ssl。在nat和公共ip地址的終端情況時(shí)將要注意安全相關(guān)問題。1.1.1 威脅分析安全風(fēng)險(xiǎn)解釋：l 未授權(quán)的會(huì)話初始：嘗試使一個(gè)設(shè)備與一個(gè)未授權(quán)的ppg建立一個(gè)push會(huì)話（通過sir

6、）。這個(gè)未授權(quán)的會(huì)話發(fā)起可能引發(fā)攻擊，導(dǎo)致用戶的個(gè)人信息（信息盜取）盜取或向用戶發(fā)送垃圾郵件。l sir一般通過sms傳遞，未授權(quán)的sir通過ip層上傳遞的風(fēng)險(xiǎn)或許很低，但仍需要驗(yàn)證。 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時(shí)，不同情景的威脅分析的評(píng)估， l

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

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

9、可能包含一些其它承載網(wǎng)絡(luò)中的不安全來源。沒有根據(jù)sms來源，目的地，或內(nèi)容設(shè)定特定的控制。l 移動(dòng)設(shè)備發(fā)起sms移動(dòng)設(shè)備發(fā)起push消息。沒有根據(jù)sms來源，目的地，或內(nèi)容特定的控制。1.2 系統(tǒng)元素push安全需求應(yīng)在當(dāng)前push結(jié)構(gòu)框架中提出。pi為在普通web服務(wù)器上運(yùn)行的一種典型的應(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提供的客戶端地址成為 一個(gè)移動(dòng)網(wǎng)絡(luò)可以識(shí)別的格

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

11、動(dòng)網(wǎng)絡(luò)的方法，并且能夠?qū)ぶ菲鋚pg。 圖 2 pap框架pap原來設(shè)計(jì)是獨(dú)立于底層傳輸機(jī)制。http為首選pap傳輸?shù)膮f(xié)議，其他協(xié)議（例如smtp）可以在未來描述。pap攜帶push 相關(guān)ppg使用的控制信息。這些信息使用xml表達(dá)。例如，一個(gè)新的消息被提交到 ppg， 控制信息和push內(nèi)容都攜帶在mime multipart/relatedrfc2387體中。這意味一個(gè)單獨(dú)的mime實(shí)體被傳輸獨(dú)立于操作類型。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提交消息包含三個(gè)實(shí)體：控制實(shí)體，內(nèi)容實(shí)體和可選的能力實(shí)體。它們封裝放入一個(gè)的multipart/related消息中，從pi發(fā)送到ppg?？刂茖?shí)體為一個(gè)xml文件，包含給ppg的傳遞指令，內(nèi)容實(shí)體是傳遞給客戶端的。在通過ota傳遞之前，ppg可轉(zhuǎn)換或不轉(zhuǎn)換內(nèi)容實(shí)體成優(yōu)化帶寬的形式?？蛇x的能力實(shí)體包含的終端能力，該信息以u(píng)aprof形式。pi可以包含此實(shí)體指示其假設(shè)的客戶端能力情況。如果此假設(shè)的能力信息與ppg識(shí)別的能力信息不一致 ，ppg可以拒絕該消息。 結(jié)果通

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

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

15、ttp傳輸成功，http的響應(yīng)包含202響應(yīng)碼（已經(jīng)接受待處理），當(dāng)http處理成功， pap的響應(yīng)文件可以包含pap錯(cuò)誤信息， 關(guān)于http1.1具體參見rfc2616。2.2 push ota協(xié)議push ota協(xié)議是push框架組成部分，負(fù)責(zé)將push內(nèi)容從ppg傳遞給客戶端和其用戶代理。它運(yùn)行在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時(shí)客戶端

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

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

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

20、sh（由ota-wsp提供）。在通常情況下需要確保sir足夠簡單能夠適合放到單個(gè)sms中。在多數(shù)當(dāng)前移動(dòng)網(wǎng)絡(luò)中，sms是可用的，使用一個(gè)well-know客戶端地址（msisdn，）并且提供可靠的傳輸層方法（例如，當(dāng)使用面向無連接push時(shí)提供高可靠性）。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ā)送通知到終端用戶的能力。例如，這樣的通知可能是一個(gè)新到的郵件，股票價(jià)格的變動(dòng)，新聞?lì)^條消息，廣告，以及余額不多的提醒。si的最基本形式包含一個(gè)短消息和一個(gè)指示業(yè)務(wù)的uri。消息在終端用戶接收后顯示，并且用戶可以選擇立即啟動(dòng)uri指示的服務(wù)，也可以推遲到以后處理。如果si延遲處理，客戶端會(huì)先存儲(chǔ)，終端用戶可以遲些操作。除了上面給出的基本功能，si允許pi控制以下：l 用戶中斷的級(jí)別(給每個(gè)si分配一個(gè)特定的優(yōu)先級(jí))l 替換（接收到新的s

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

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

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

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

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

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

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

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

30、下面列出一些可能解決方案：l 會(huì)話級(jí)證書的使用（tls，ssl）如果在pi和ppg之間的網(wǎng)絡(luò)不可信任（例如，internet，一個(gè)非常大的企業(yè)內(nèi)部網(wǎng)絡(luò)），tls/ssl能在pi和ppg之間使用。l http鑒權(quán)盡管http鑒權(quán)最普通的形式為基本的鑒權(quán)（例如，一個(gè)用戶id/密碼），其它形式的http鑒權(quán)（例如，分類）可能更優(yōu)越。這種方法和tls/ssl的主要不同為tls/ssl在可測量性和隱私性更強(qiáng)，前者在這些方面弱一些。l 技術(shù)的結(jié)合技術(shù)應(yīng)該聯(lián)合使用。例如，pi與ppg間建立一個(gè)匿名的tls/ssl會(huì)話，因此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ò)在一些真實(shí)的裝置情況下，pi和ppg之間的網(wǎng)絡(luò)是一個(gè)私網(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列為可信任的，客戶端可以信任這個(gè)ppg，并且因此正確識(shí)別此pi。使用前面章節(jié)描述的方法，ppg可以通過各種隱私級(jí)別鑒權(quán)一個(gè)

32、pi。如果確實(shí)，ota協(xié)議可以為ppg指示此pi中傳遞給客戶端的消息是鑒權(quán)過的。如果這種方式中的ppg是可信任的，那么ppg的識(shí)別通過可以攜帶客戶端上的可選擇的過濾“whitelist”策略進(jìn)行交叉檢測。如果ppg身份不再列表內(nèi)，也不在設(shè)備上的網(wǎng)關(guān)配置集中，客戶端可以忽略接收到的任何push消息。3 push 代理網(wǎng)關(guān)服務(wù)3.1 概述push服務(wù)是wap的一個(gè)組成部分，其體系結(jié)構(gòu)如圖3所示，這個(gè)體系結(jié)構(gòu)使得信息內(nèi)容能夠從有線網(wǎng)絡(luò)上被推送到兼容wap的移動(dòng)設(shè)備上。push業(yè)務(wù)技術(shù)規(guī)范主要是針對(duì)內(nèi)容提供商把內(nèi)容推送（即不需要同步請求的發(fā)送）到客戶端（即支持push相應(yīng)功能的移動(dò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操作被定義為獨(dú)立的處理每一個(gè)push提交（包括隨后和這些push消息相關(guān)的操作）。當(dāng)然，在各push提交之間還是有一些受限的交互。例如，對(duì)于可以支持多發(fā)送優(yōu)先級(jí)的ppg，一條消息可能會(huì)影響到另一消息(如低優(yōu)先級(jí)的)的處理時(shí)間，并且最終影響到發(fā)送的成

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

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

36、ush消息的替換是可選功能，主要完成對(duì)已提交、待push消息的替換。如果ppg支持替換功能，同時(shí)消息替換處于已確認(rèn)狀態(tài)，則ppg應(yīng)替換pap push-message消息pushpap所請求的消息。若ppg不支持替換功能，則當(dāng)push發(fā)起者發(fā)出替換請求時(shí)，ppg應(yīng)拒絕這個(gè)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 概述消息的空中傳送包括兩個(gè)功能：l 消息處理；l 消息的空中傳送。本節(jié)將描述這兩個(gè)功能。.2 消息處理.2.1 概述為準(zhǔn)備空中傳輸，ppg可能會(huì)轉(zhuǎn)換包含在push提交中的消息實(shí)體（如pushmsg中定義）。典型的轉(zhuǎn)換原因包括針對(duì)空中傳送效率的編輯或優(yōu)化，以及將內(nèi)容實(shí)體轉(zhuǎn)換成無線終端可接受的內(nèi)容類型。本節(jié)具體描述了這種轉(zhuǎn)換功能。.2.2 實(shí)體和消息頭的轉(zhuǎn)換ppg不能對(duì)任何在如rfc2616中定義的notransform緩存控制指示范圍內(nèi)無效的實(shí)體的消息體進(jìn)行轉(zhuǎn)換。否則，ppg可能會(huì)以與實(shí)現(xiàn)相關(guān)的方式進(jìn)行轉(zhuǎn)換

38、。所有被轉(zhuǎn)換實(shí)體的消息頭應(yīng)進(jìn)行修正以便能夠正確地反映被轉(zhuǎn)換的實(shí)體。所有的轉(zhuǎn)換應(yīng)與pushmsg中的要求一致。..2.2.1 wsp 特定轉(zhuǎn)換ppg應(yīng)支持wsp中所定義的二進(jìn)制消息頭編碼。除非確切知道被尋址的終端支持非編碼格式，否則，ppg應(yīng)為在ota-wsppushota上傳送而將內(nèi)容實(shí)體編碼成為對(duì)應(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)實(shí)現(xiàn)rfc1951中所定義的

39、壓縮編碼。..2.2.3 sip特定轉(zhuǎn)換為了減小在空中的數(shù)據(jù)傳送量，ppg建議支持基于ota-sip之上ota傳送的內(nèi)容編碼，如果ppg支持，ppg應(yīng)實(shí)現(xiàn)rfc1951中定義的壓縮編碼。當(dāng)ppg清楚知道目標(biāo)終端支持以二進(jìn)制格式wbxml方式編碼，則內(nèi)容實(shí)體可以用此編碼格式編碼。.2.3 x-wap-application-id（application-id）消息頭處理ppg應(yīng)按照如下說明處理 pushmsg x-wap-application-id（application-id）的消息頭信息：l 如果消息頭包含一個(gè)已在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 如果消息頭包含一個(gè)沒有在omna中注冊app-assigned-code的pushmsgabsoluteuri格式的application-id ， 則ppg 應(yīng)使用這個(gè)值， 除非存在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)識(shí)了客戶端的默認(rèn)應(yīng)用，則ppg可能會(huì)去掉該消息頭。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)以u(píng)rn形式，添加x-wap-application-id頭域的值為g.oma.pusheventapp特征標(biāo)簽作為push資源標(biāo)識(shí)符。如果是在oman注冊過的眾所周知的地址類型，那么建議使用名稱空間指定的字符串類型。否則，應(yīng)包含urn的名稱空間標(biāo)識(shí)。ppg可能會(huì)除掉含有客戶端默認(rèn)值的所有消息頭。這個(gè)默認(rèn)值可能會(huì)在ota協(xié)議定義，并利用與實(shí)現(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)對(duì)于上面步驟中可能遇到錯(cuò)誤，或很明顯不可能成功進(jìn)行消息發(fā)送的push提交，不能嘗試發(fā)送消息。注意，這可能會(huì)導(dǎo)致發(fā)送papresultnotification-message。對(duì)于實(shí)體和消息頭轉(zhuǎn)換處理失敗的消息應(yīng)有如下的狀態(tài)報(bào)告：pap 屬性屬性值message-stateundeliverablecodetransformation-failure如果消息轉(zhuǎn)換成功，對(duì)于未傳送的消息應(yīng)有如下狀態(tài)報(bào)告：pap 屬性屬性值message-statepending3.2.2

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

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

46、的push客戶端發(fā)送push消息。當(dāng)優(yōu)先級(jí)高的ota協(xié)議變量不可用時(shí)，使用下一級(jí)協(xié)議變量作為push消息的承載方式。ppg可以通過發(fā)送sir消息，并在sir消息中給出ota-wsp，ota-http和ota-sip聯(lián)系點(diǎ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)報(bào)告的消息發(fā)送失敗：pap 屬性屬性值message-stateundeliverabledescan appropriate, implementation-dependent valueevent-timetime or estimated time of failure.3.4 會(huì)話或注冊上下文的選擇與創(chuàng)建ppg可能會(huì)使用已有的wsp會(huì)話（如果使用otawsp）或注冊上下文（如果使用otahttp），或者采用實(shí)現(xiàn)相關(guān)的方式來創(chuàng)建合適的wsp

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

49、-after-timestamp時(shí)間發(fā)送push消息。如果不能在pap deliver-before-timestamp時(shí)間內(nèi)傳送，則操作失敗，且應(yīng)報(bào)告如下消息狀態(tài)：pap attributevaluemessage-stateexpireddescan appropriate, implementation-dependent valueevent-timetime or estimated time of failure.3.6 空中傳送假設(shè)沒有出現(xiàn)錯(cuò)誤，如果用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)簽。對(duì)確認(rèn)和非確認(rèn)push方式的使用取決于pap delivery-method的屬性，并且和ppg的實(shí)現(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)報(bào)告同樣的pap result-notification消息，如同消息是利用ota-wsp以非確認(rèn)方式發(fā)送的一樣。如果ppg發(fā)送po-push.req或 po-unit-push.req原語，或ppg利用ota-http代理這些原語發(fā)送消息，則應(yīng)報(bào)告如下的消息狀態(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)，則可能在與實(shí)現(xiàn)相關(guān)的ppg重試之后，應(yīng)報(bào)告下述消息狀態(tài)：pap 屬性屬性值message-st

53、atedelivereddelivery-methodunconfirmedevent-timetime or estimated time of delivery2） 因?yàn)橹袛喽。喝绻鹥pg接收到說明是被中斷的push嘗試的po-pushabort.ind原語，或說明push信息被拒絕的x-wap-push-status消息頭（ota-http），或通過msrp failure-report指示傳遞失?。╫ta-sip），則應(yīng)報(bào)告如下的消息狀態(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） 因?yàn)槌瑫r(shí)而失?。喝绻褂胦ta-wsp ，當(dāng)ppg 在與實(shí)現(xiàn)相關(guān)的時(shí)間周期內(nèi)沒有收到otapo-confirmedpf時(shí)超時(shí)發(fā)生。如果使用ota-http，當(dāng)ppg在與實(shí)現(xiàn)相關(guān)的時(shí)間周期內(nèi)沒有收到對(duì)http post請求的應(yīng)答時(shí)超時(shí)發(fā)生。如果使用ota-sip，當(dāng)ppg在與實(shí)現(xiàn)相關(guān)的時(shí)間周期內(nèi)沒有收到ms

55、rp success-report指示傳遞成功時(shí)，超時(shí)發(fā)生。如果超時(shí)發(fā)生時(shí)ppg選擇不再進(jìn)行發(fā)送嘗試，則應(yīng)報(bào)告如下的消息狀態(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消息，并確保底層承載也使用此種傳遞嘗試。使用該種方法時(shí)，應(yīng)報(bào)告如下消息狀態(tài)：pap 屬性屬性值message-statedelivereddelivery-methodoneshotevent-timetime or estimated time of delivery3.2.3 結(jié)果通知 概述如果在push