移动网络推送业务技术报告——华为.doc

移动网络推送业务技术报告ICS 目 次1 业务概述31.1 Push安全需求31.2 系统元素52 业务特征62.1 PAP62.2 Push OTA协议82.3 Push特定的媒体类型92.4 寻址102.5 安全考虑123 Push 代理网关服务133.1 概述133.2 PPG 的操作133.3 客户端寻址214 Push访问协议244.1 概述244.2 PAP协议处理过程分析244.3 PAP寻址284.4 消息格式294.5 控制元素和属性314.6 版本控制424.7 能力协商454.8 PAP 参考信息454.9 举例514.10 基于HTTP的PAP535 Push OTA 协议545.1 概述545.2 协议变量545.3 WSP上的Push OTA协议（OTA-WSP）555.4 HTTP上的Push OTA （OTA-HTTP）625.5 SIP上的PushOTA协议（OTA-SIP）805.6 会话初始请求966 Push 消息1056.1 概述1056.2 Push 消息定义1066.3 代理规则1097 Push客户端与应用接口1107.1 概述1107.2 Push客户端-应用接口（Push-CAI）定义1107.3 安全考虑113附录A （资料性）114附录B114（资料性）1141 业务概述1.1 Push安全需求本技术报告定义与Push业务相关技术及安全相关的安全要求。Push技术允许业务的使用者能接收推送的数据到他们的移动客户端上。最初一个用户可以去浏览Push发起者PI维护的网页。PI将提供业务给用户。一个Push业务的例子可以是本地的天气预报业务，PI每天早上推送本地天气预报到用户的客户端。 Push的结构定义了三个实体：Push业务发起者PI， Push代理网关PPG和客户端。当推送无连接的内容到用户的客户端时，PI与PPG使用PAP协议进行交互。PPG依次编译Push消息，并经过OTA协议发送到用户的客户端。Push的安全方面的定义当前还不能满足行业中各类提供WAP Push业务供应商的安全需要。因此，定义Push的各种安全需求是必要的。最终的目的是为了在PI与客户端之间有一个完整的安全链，这样用户将可以完全相信客户端将收到的Push消息是来自可信任的发起者的。图 1 Push框架上图展示了 Push框架中的四个实体。不同实体间的安全/信任关系是Push 安全的关键方面。这些关系及相关的关键问题有：Ø 用户应能够信任PI传递的内容是其请求的内容。Ø 用户应能够信任PPG传递的内容是其从PI请求的内容，并且用户支持相应的Push-OTA的操作。e.g. 会话初始请求。Ø PI应该能够信任PPG不会对Push内容做目标Push客户端及Push-OTA协议需要转化的格式之外的任何修改。PI和PPG之间的交互一般将会在面向连接的协议上发送，e.g. .HTTP并且能够使用已经建立的Internet安全协议，如SSL等，来确保保密性，完整性和鉴权。PPG与客户端的交互按以下两种方式进行：Ø 面向无连接PushØ 面向连接Push面向无连接Push可以使用OTA方法发送，最常用的为SMS。当前，当使用面向无连接的Push时，未陈述安全问题。当使用面向连接的Push时，各自承载层使用底层的安全协议，例如如果HTTP协议则使用SSL。在NAT和公共IP地址的终端情况时将要注意安全相关问题。1.1.1 威胁分析安全风险解释：l 未授权的会话初始：尝试使一个设备与一个未授权的PPG建立一个Push会话（通过SIR）。这个未授权的会话发起可能引发攻击，导致用户的个人信息（信息盗取）盗取或向用户发送垃圾邮件。l SIR一般通过SMS传递，未授权的SIR通过IP层上传递的风险或许很低，但仍需要验证。 l 有害的内容传递：任何破坏用户业务或威胁网络安全的内容的传递。有害内容传递的目的可能使业务中断，盗取，导致用户被攻击或病毒扩散。它可以直接在设备上操作，或欺骗设备或用户来取回一些有害的内容。l 业务的拒绝：重复Push消息的传递干扰用户业务。业务拒绝的目的可能为了困扰用户或骚扰用户而更换网络提供商。l 未授权的Push：尝试传递未请求的Push内容。下表表示了当使用Push时，不同情景的威胁分析的评估， l 高：相对容易实行，尽管可能不常见。网络阻挡的能力较低。l 中：更多的工作完成l 低：很难意识到，网络办法容易实行场景风险类别公共IP地址私有IP地址运营商IP策略或授权的第三方PPG 网络初始的移动终止SMS移动初始的SMS开放接入控制未授权的会话初始LowLowNoneNoneHighHigh有害的内容传递HighMediumHighHigh to low (1)HighHigh业务的拒绝HighMediumHighHigh to low (1)HighHigh未授权的PushHighMediumHighHigh to low (1)HighHigh表 1 Push威胁分析评估. 有效的接入控制可以大量减少风险。情景解释：l 公共IP设备地址移动网络为设备分配公共IP地址。运营商可以提供一个PPG或依靠第三方PPG。 l 私有IP设备地址移动网络为设备分配私有IP地址。第三方PPG 实现的Push传递非常复杂，需要私网到公网的地址转换（NAT），运营商专门提供一个PPG。l 运营商或授权的第三方PPG指定开放的PI策略PPG不提供特殊的Push来源、地址、内容类型、或服务质量的控制。l 运营商或授权的第三方PPG进行接入控制的PI策略PPG 对Push来源、地址、内容类型、或服务质量提供一些级别的接入控制。l 网络发起的止于移动设备的SMSPush消息由基于网络的SMS源发起的，可能包含一些其它承载网络中的不安全来源。没有根据SMS来源，目的地，或内容设定特定的控制。l 移动设备发起SMS移动设备发起Push消息。没有根据SMS来源，目的地，或内容特定的控制。1.2 系统元素Push安全需求应在当前Push结构框架中提出。PI为在普通web服务器上运行的一种典型的应用，与PPG使用PAP通过HTTP连接进行通信。PPG使用Push-OTA协议传递Push内容到客户端。PAP基于标准的Internet协议，用来XML表达传递指令并且Push内容可以为任何MIME媒体类型。 PPG负责传递Push内容到客户端。这样，其转换PI提供的客户端地址成为 一个移动网络可以识别的格式，如果客户端当前不可用时存储内容等。PPG不只完成传递消息的功能，它还可以通知PI关于Push提交的最终结果，选择性的取消，覆盖或为PI请求客户端能力。 Push-OTA协议是完成Push框架的一部分，负责从PPG传输内容到客户端及其用户代理。通过HTTP（OTA-HTTP），WSP（OTA-WSP）或其他协议实现。PPG为Push框架中主要功能实体。其责任包括作为从Internet向移动网络Push内容的接入点，及随之相关的所有事情（鉴权，抵制解析等）。PPG为移动网络的接入点，将执行网络的接入控制策略。例如，Push内容发送权限控制。2 业务特征2.1 PAPPAP协议为PI推送内容到移动网络的方法，并且能够寻址其PPG。 图 2 PAP框架PAP原来设计是独立于底层传输机制。HTTP为首选PAP传输的协议，其他协议（例如SMTP）可以在未来描述。PAP携带Push 相关PPG使用的控制信息。这些信息使用XML表达。例如，一个新的消息被提交到 PPG， 控制信息和Push内容都携带在MIME multipart/relatedRFC2387体中。这意味一个单独的MIME实体被传输独立于操作类型。2.1.1 PAP操作 PAP 支持以下操作：l Push提交（PI到PPG）l 结果通知（PPG到PI）l Push取消（PI到PPG）l 之前提交的Push消息的替换（PI到PPG）l Push操作的状态询问（PI 到PPG）l 无线设备的能力查询（PI到PPG）2.1.1.1 Push提交Push提交消息包含三个实体：控制实体，内容实体和可选的能力实体。它们封装放入一个的multipart/related消息中，从PI发送到PPG。控制实体为一个XML文件，包含给PPG的传递指令，内容实体是传递给客户端的。在通过OTA传递之前，PPG可转换或不转换内容实体成优化带宽的形式。可选的能力实体包含的终端能力，该信息以UAProf形式。PI可以包含此实体指示其假设的客户端能力情况。如果此假设的能力信息与PPG识别的能力信息不一致 ，PPG可以拒绝该消息。2.1.1.2 结果通知如果PI请求关于最终传递的结果，结果通知消息将从PPG传递到PI指定的URI。该消息可以是XML实体，指示传递成功或失败（客户端不可达，超时等）。Push框架的一个主要特点是：PI有可能依赖PPG发来的响应。当且仅当目标应用已经接受Push内容时，终端才会返回确认。如果不能接受，必须中断操作，PI知道内容不能到达目的地。2.1.1.3 Push取消该消息是PI给PPG传输的XML实体，用来取消之前提交的消息。PPG用一个XML实体进行响应，指示取消操作是否成功。2.1.1.4 Push替换如果PI请求替换一个之前Push提交操作中提交的消息，重置可能有两种情况：新的消息只发送给那些未接收到原始消息的接受者，或新的消息应发送给所有的接收者。任何一种情况，对于未被传递的接收者的原消息应被取消。2.1.1.5 状态询问状态询问是从PI到PPG的XML实体，用来请求之前提交消息的状态。PPG用一个包含当前状态的XML实体进行响应。2.1.1.6 客户端能力询问客户端能力询问从PI传递到PPG的XML实体，请求网络中一个特定设备的能力。PPG的响应包含一个multipart/related实体，包含两个部分，第一部分包含请求结果，第二部分包含UAProf格式祖师的设备能力信息。2.1.1.7 HTTP传输当PAP使用HTTP作为传输协议时，信息传输使用HTTP POST请求和响应方法。当HTTP传输成功，HTTP的响应包含202响应码（已经接受待处理），当HTTP处理成功， PAP的响应文件可以包含PAP错误信息， 关于HTTP1.1具体参见RFC2616。2.2 Push OTA协议Push OTA协议是Push框架组成部分，负责将Push内容从PPG传递给客户端和其用户代理。它运行在HTTP（OTA-HTTP）或WSP（OTA-WSP）之上。OTA-WSP经常用于在PPG和客户端之间执行无连接的Push。面向连接的Push，使用OTA-HTTP或OTA-WSP是可选的。图 3 OTA框架2.2.1 OTA-WSPOTA-WSP协议变量构造上为WSP协议之上简单的协议层，可以用于OMA定义的任何承载使用。OTA-WSP使用由WSP提供的特性，并且扩展Push特定的需求，通过引入新的业务原语和扩展现有的新的头域。例如，OTA-WSP继承WSP的能力协商特性（可能使用UAProf），提供无连接（非确认Push）和面向连接的（非确认和确认的Push）业务。2.2.2 OTA-HTTP此协议变量使用HTTP完成PPG与客户端的空中通信，主要是基于IP承载网络。HTTP变量只提供面向连接的Push。Push内容通过HTTP POST方式传递，意味着PPG作为HTTP客户端并且用户作为 HTTP服务器。为了避免客户端因此被混淆，在Push OTA中使用OTA-HTTP时客户端称作“终端”。Push OTA规范定义了两种建立一个激活的TCP连接的方法（例如，用来传递Push内容的一个TCP连接）。这个方法包括PPG发起的建立TCP（PO-TCP）连接和终端发起建立TCP（TO-TCP）连接两种。当承载已激活时，PO-TCP允许建立一个激活的TCP连接，并且PPG应获知终端的IP地址。TO-TCP方法为另一种情况，经常用在与SIR机制联合使用。通过使用长期会话的概念，OTA-WSP个i客户端提供了向PPG传递能力信息的方法。在OTA-HTTP中，终端注册到PPG上，提供相似的功能性。这通过PPG发送HTTP OPTIONS请求给终端完成的，终端在响应中包含其能力和设置信息（CPI）（可以选择使用UAProf）。当PPG已经知道CPI后，为了提高空中传输的效率，提供了避免信息转发给终端的机制。OTA-HTTP也提供识别和选择性鉴权终端和PPG的方法。鉴权方案使用RFC2617定义的“basic”和“digest” ，终端用来鉴权PPG。而向PPG鉴权终端则使用一个稍微修改的变量（RFC2617只定义了HTTP客户端，这里为PPG如何被鉴权的）。2.2.3 会话初始应用（SIA）无论使用OTA-HTTP或OTA-WSP，客户端需要进行通信初始化。SIA的指定就是为了完成客户端一侧通信初始化这个目的。SIA监听来自PPG发起的SIR，通过激活相应的承载，并且和该PPG联系作为响应。当使用OTA-WSP，经常是客户端发起初始化建立底层的WSP会话。当期望建立发送Push消息的WSP会话时，PPG发送SIR到客户端。客户端接收到SIR后，激活该SIR中指明的承载，并且在该建立的承载上向指示的PPG建立一个WSP会话。SIR机制经常与 OTA-HTTP结合使用，尤其当PPG不知道客户端IP地址，和/或当PPG不能激活所需的承载。这种情况下，SIR指示客户端激活一个特定的承载，并且向SIR指定的PPG 建立一个激活的TCP连接（使用TO-TCP方式）。无论接下来与PPG联系时客户端使用OTA-WSP或是OTA-HTTP，发送到客户端的SIR使用面向无连接Push（由OTA-WSP提供）。在通常情况下需要确保SIR足够简单能够适合放到单个SMS中。在多数当前移动网络中，SMS是可用的，使用一个well-Know客户端地址（MSISDN，）并且提供可靠的传输层方法（例如，当使用面向无连接Push时提供高可靠性）。2.3 Push特定的媒体类型Push框架允许在PI与客户端之间传递任何MIME媒体类型。本节描述的媒体类型的创建是为了满足现有MIME类型未能提供的功能而进行的扩展。其他带有Push规范化语法的媒体类型已经由OMA定义，满足特定应用的需求（例如MMS和Provisioning）。注意：如果Push指定的语法既不是为媒体类型本身定义，又不是为用户代理接收特定媒体类型使用，这样的媒体类型将放置缓存中或在Push接收后删除（WHL中使用）。2.3.1 业务指示 （SI）业务指示（SI）媒体类型以异步方式发送通知到终端用户的能力。例如，这样的通知可能是一个新到的邮件，股票价格的变动，新闻头条消息，广告，以及余额不多的提醒。SI的最基本形式包含一个短消息和一个指示业务的URI。消息在终端用户接收后显示，并且用户可以选择立即启动URI指示的服务，也可以推迟到以后处理。如果SI延迟处理，客户端会先存储，终端用户可以迟些操作。除了上面给出的基本功能，SI允许PI控制以下：l 用户中断的级别(给每个SI分配一个特定的优先级)l 替换（接收到新的SI即替换旧的SI）l 删除（通过发送“delete”SI，删除一个已经接收的SI） l 过期（为SI分配一个过期的时间期限）这一章节描述的媒体类型中，SI是客户端执行Push时唯一强制使用的媒体类型。2.3.2 业务加载对比于SI，业务加载（SL）不含任何用户参与过程。一个SL传输包含指向内容的URI，由客户端自动下载而不需要终端用户确认。还包含一个指示信息，指示内容是否应被执行、呈现或存放进缓存中是需要。如果内容应该执行或呈现，PI可以控制用户中断的级别。2.3.3 Cache 缓存操作CO缓存操作媒体类型提供一个使客户端缓存中的特定对象失效，或使共享同一URI索引的所有对象实效的方法。这个特性在缓存内容的期限时间预先不能确定的情况下使用（例如，产看邮箱），以及内容变更（新邮件到达）频率要比用户接入快的情况下使用非常有效。2.4 寻址Push地址在客户端和应用层出现。另外，两个注册的端口（安全和非安全）在无连接Push上使用。当面向连接的OTA-WSP使用时，任何携带Push能力集的WSP会话都可以使用。OTA-HTTP只用在面向连接的Push，使用激活TCP连接概念，专门特别永在Push中。更多关于端口，会话，和激活TCP连接可以在PushOTA查找。2.4.1 客户端寻址 PI使用客户端地址指令PPG Push消息应该发送到的客户端。Push PPG规范介绍了允许的地址配置。l 用户定义的识别符任意的文本字符串（例如，一个Email地址）用来识别客户端。PPG负责转换此字符串成为一个移动网络识别的地址格式。Push PPG中的举例，WAPPUSH=john.doe%40oma.org/TYPE=USER;为john.doeoma.org定义的用户定义识别符WAPPUSH=+155519990730/TYPE=USER; 看上去向电话号码的用户定义识别符l 设备地址一个移动网络识别的地址，例如，MSISDN（SMS等），或IP地址（GPRS等）。Push PPG中的举例，WAPPUSH=+155519990730/TYPE=PLMN; 为一些无线网络的电话号的设备地址 WAPPUSH=195.153.199.30/TYPE=IPv4; IPV4的设备地址TYPE交换指示地址的类型（用户定义或设备地址包含地址类型），并且 部分是一个PPG的Internet主机名称。更多信息，参看PushPPG。2.4.2 应用及寻址 Push内容总是指向一个设备上的特定的用户代理（或更多一般，一个特定的应用）。应用识别符可以是一个URI或一个注册在OMNA数字值，来识别一个用户代理。PushMsg定义了PI在Push消息中包含X-Wap-Application的应用识别符。这个头域当PPG传递消息客户端时也传输到客户端，允许客户端分派消息到目的用户代理。2.4.2.1 OTA效率和数字识别符为了提高OTA效率，一个数字识别符可以用来代替一个URI。OMAOMNA已经为well-known的用户代理分配了数字，例如设备WAE上的浏览器，来避免发送一个URI的开销。如果PPG请求推送携带一个应用识别的URI的内容，这个URI认为是一个由OMNA分配的数字识别符的URI，那么这个URI用数字识别符替代。PI本身使用一个数字识别符当Push消息提交到PPG时，可能是一个未注册的识别符。如果未注册的识别符不建议用来配置应用，因为可能发生冲突。这个主要是为一些还未公共配置的用户代理使用。2.4.3 举例假设PI已经提交一个消息给客户端Foo，为了一个Bar的应用，到客户端Foo的服务的PPG。另外，PI已经请求消息应该以一个确认的方式（指面向连接的传递）传递。PPG（支持OTA-HTTP和OTA-WSP）之前还未与客户端进行通信，因此也不知道是否其支持OTA-HTTP或OTA-WSP（或两个）。当前没有Push会话或激活TCP连接在PPG和客户端Foo之间，也不需要建立。PPG发送一个SIR到Foo以一个面向无连接的方式，使用例如SMS， 指示其希望推送一些内容到应用Bar。既然PPG不知道是否客户端支持OTA-HTTP或OTA-WSP，其包含SIR中两个变量的PPG联系点。这个请求被发送到Foo中的SIA，就像任何其它Push内容（例如，通过指定专用的无连接的Push的一个端口，并且含有SIA业能够用识别符）。客户端接收到内容，考虑使用SIA向前发送。SIA，接收到这个请求，检查是否目标应用安装在Foo中，可能用户设置指示目标应用接收Push内容。应用Bar实际安装在此客户端上，因此客户端在SIR上执行。假设客户端只支持OTA-WSP，意味着应该用其向PPG建立会话。 目前，此特定设备的拥有者不希望其它人知道其设备上安装的应用（隐私保护）。SIA注意到这点，向PPG建立一个Push会话，指示会话接收任何应用的内容。如果用户已经没有严格要求隐私，会话可以用的应用可以清晰地列出来。 一旦会话已经建立，PPG在这个会话上完成确认的Push，并且客户端接收到PI提交的Push内容。客户端接收到这个内容，查看这个内容是给应用Bar的，并且传递到这个应用。当（仅当）应用负责Push内容，Push原路返回确认（如果请求的话）。2.5 安全考虑当执行Push，安全和信任模型需要在多个领域内考虑。以下给出可能遇到的问题的举例： l PI如何被鉴权l PPG在其安全和信任模型中的角色l 对于PI和Push内容的接入控制策略l 客户端如何鉴权其没有证书的目标不管以上的事件，Push框架都有能力提供客户端足够的信息来提供一个可信任的模型和其自己的安全策略。2.5.1 鉴权一个Push 发起者PI在一种形式或另一种形式中被鉴权，依靠PI和PPG操作的安全环境。下面列出一些可能解决方案：l 会话级证书的使用（TLS，SSL）如果在PI和PPG之间的网络不可信任（例如，Internet，一个非常大的企业内部网络），TLS/SSL能在PI和PPG之间使用。l HTTP鉴权尽管HTTP鉴权最普通的形式为基本的鉴权（例如，一个用户ID/密码），其它形式的HTTP鉴权（例如，分类）可能更优越。这种方法和TLS/SSL的主要不同为TLS/SSL在可测量性和隐私性更强，前者在这些方面弱一些。l 技术的结合技术应该联合使用。例如，PI与PPG间建立一个匿名的TLS/SSL会话，因此HTTP鉴权可以用来鉴权PI。l 共享隐秘的内容类型参数使用共享的秘密，可能产生内容类型参数附加到Push特定内容类型。这些参数本质上相似于那些为配置加载（provisioning bootstrap）的使用。l 可信任的网络在一些真实的装置情况下，PI和PPG之间的网络是一个私网，因此，PI清晰地信任这样的整套装置。2.5.2 客户端PI鉴权的委托“鉴权的委托”参考鉴权能够传递的原理。如果客户端和PPG可以建立信任，PPG可以为客户端鉴权PI。例如，在客户端已经使用了WTLS或WAPTLS提供的方法来鉴权PPG，客户端可以查看其可信任PPG列表。如果PPG列为可信任的，客户端可以信任这个PPG，并且因此正确识别此PI。使用前面章节描述的方法，PPG可以通过各种隐私级别鉴权一个PI。如果确实，OTA协议可以为PPG指示此PI中传递给客户端的消息是鉴权过的。如果这种方式中的PPG是可信任的，那么PPG的识别通过可以携带客户端上的可选择的过滤“whitelist”策略进行交叉检测。如果PPG身份不再列表内，也不在设备上的网关配置集中，客户端可以忽略接收到的任何Push消息。3 Push 代理网关服务3.1 概述PUSH服务是WAP的一个组成部分，其体系结构如图3所示，这个体系结构使得信息内容能够从有线网络上被推送到兼容WAP的移动设备上。Push业务技术规范主要是针对内容提供商把内容推送（即不需要同步请求的发送）到客户端（即支持Push相应功能的移动设备）的需求。这与“pull”技术相反。“pull”技术需要客户端发出的同步请求。利用有线网络和无线网络之间的网关使得Push业务更为便利。该网关称为Push代理网关（PPG）。本部分规范就是要规范PPG的功能。3.2 PPG 的操作3.2.1 概述本节主要定义PPG所执行的操作：包括Push提交处理、结果通知、传送取消，以及Push访问协议（PAP）状态查询等。PPG操作被定义为独立的处理每一个push提交（包括随后和这些push消息相关的操作）。当然，在各push提交之间还是有一些受限的交互。例如，对于可以支持多发送优先级的PPG，一条消息可能会影响到另一消息(如低优先级的)的处理时间，并且最终影响到发送的成败。需要注意的是，PPG并不应采用特定的顺序发送push消息。3.2.2 Push 提交处理3.2.2.1 概述Push发起者通过向PPG发送push消息触发push的提交处理。Push提交处理包括四个操作，下面三个操作在执行时应按照先后的顺序：l Push提交的接受或者拒绝；l Push消息在空中传送，前提是push消息被接受并且符合PPG的策略和push发起者的要求；l 消息传送的结果通知，前提是push消息已经被终端所接收，并且push发起者要求传送结果通知。第四个操作可以接收在push消息后的任何时间执行，这取决于PPG的实现，即l PAP协议的push消息应答。本节将对这四种操作予以说明。3.2.2.2 Push 提交的接收和拒绝PPG对收到的每一个push提交消息可选择接受或拒绝。PPG建议接收可能最终传送到OTA客户端的PAP push提交消息。但是如果Push提交消息中包含的PAP pushmessege元素不符合它的文档定义DTD的要求，则这条push提交消息应被拒绝。其它用来决定push提交是否被接受的标准随具体的实现而定。对于空中传送所要求的消息处理（在6.2.2.3描述）没有完成的已接收、但还未传送的push消息，应有如下的信息状态报告：PAP 属性属性值message-state"pending"3.2.2.2.1 对先前提交的push消息的替换对先前提交的push消息的替换是可选功能，主要完成对已提交、待Push消息的替换。如果PPG支持替换功能，同时消息替换处于已确认状态，则PPG应替换PAP push-message消息PushPAP所请求的消息。若PPG不支持替换功能，则当Push发起者发出替换请求时，PPG应拒绝这个Push提交。3.2.2.2.2 客户端发起的内容请求PPG应支持OTA-HTTP或OTA-SIP方法指示客户端，PI接受客户端在响应中返回的内容，以便满足QoS参数中要求的“confirmed-with-response”的传递方法。不支持OTA-HTTP或OTA-SIP方法的PPG，应拒绝PI使用此特征的Push提交操作。3.2.2.3 空中消息传送3.2.2.3.1 概述消息的空中传送包括两个功能：l 消息处理；l 消息的空中传送。本节将描述这两个功能。3.2.2.3.2 消息处理3.2.2.3.2.1 概述为准备空中传输，PPG可能会转换包含在push提交中的消息实体（如PushMsg中定义）。典型的转换原因包括针对空中传送效率的编辑或优化，以及将内容实体转换成无线终端可接受的内容类型。本节具体描述了这种转换功能。3.2.2.3.2.2 实体和消息头的转换PPG不能对任何在如RFC2616中定义的NoTransform缓存控制指示范围内无效的实体的消息体进行转换。否则，PPG可能会以与实现相关的方式进行转换。所有被转换实体的消息头应进行修正以便能够正确地反映被转换的实体。所有的转换应与PushMsg中的要求一致。.3.2.2.3.2.2.1 WSP 特定转换PPG应支持WSP中所定义的二进制消息头编码。除非确切知道被寻址的终端支持非编码格式，否则，PPG应为在OTA-WSPPushOTA上传送而将内容实体编码成为对应的压缩二进制格式WBXML。例如：在无连接模式发送的情况下，服务指示通常应被编码成WBXMLWBXML。.3.2.2.3.2.2.2 HTTP特定转换为了减小在空中的数据传送量，PPG建议支持基于OTAHTTP之上OTA传送的内容编码。如果PPG支持，它应实现RFC1951中所定义的压缩编码。.3.2.2.3.2.2.3 SIP特定转换为了减小在空中的数据传送量，PPG建议支持基于OTA-SIP之上OTA传送的内容编码，如果PPG支持，PPG应实现RFC1951中定义的压缩编码。当PPG清楚知道目标终端支持以二进制格式WBXML方式编码，则内容实体可以用此编码格式编码。3.2.2.3.2.3 X-Wap-Application-Id（Application-ID）消息头处理PPG应按照如下说明处理 PushMsg X-Wap-Application-Id（Application-ID）的消息头信息：l 如果消息头包含一个已在OMNA中注册的app-assigned-code的PushMsg absoluteURI格式的Application-ID，则PPG应从消息头信息中去掉所有app-assigned-code格式的Application-ID（ 如果存在的话） ， 然后用absoluteURI 格式的Application-ID 替换已注册的app-assigned-code格式的Application-ID。l 如果消息头包含一个没有在OMNA中注册app-assigned-code的PushMsgabsoluteURI格式的Application-ID ， 则PPG 应使用这个值， 除非存在PushMsg app-assigned-code 格式的Application-ID。这种情况（如果存在app-assigned-code格式的Application-ID）下，则应去掉absoluteURI格式的Application-ID。l 如果消息头只包含PushMsgapp-assigned-code格式的Application-ID，则不需要进行替换或者删除。l 如果处理后的消息头标识了客户端的默认应用，则PPG可能会去掉该消息头。l 如果在push消息中没有包含PushMsgX-Wap-Application-Id的消息头，则除非客户端默认的Application-ID是WML用户代理，PPG应加上消息头。如果加上了消息头，则Application-ID应是WML用户代理的Application-ID。l 如果使用OTA-SIP方式，PPG应以URN形式，添加X-WAP-Application-Id头域的值为g.oma.pusheventapp特征标签作为Push资源标识符。如果是在OMAN注册过的众所周知的地址类型，那么建议使用名称空间指定的字符串类型。否则，应包含URN的名称空间标识。PPG可能会除掉含有客户端默认值的所有消息头。这个默认值可能会在OTA协议定义，并利用与实现相关的机制进行提供或建立。例如如果客户端只有一种push应用，则含有X-Wap-Application-Id消息头可能被去除，以优化OTA的通信。如果没有被编码成数字格式，包含已注册值的X-Wap-Application-Id消息头不能在空中传送。3.2.2.3.2.4 消息状态对于上面步骤中可能遇到错误，或很明显不可能成功进行消息发送的push提交，不能尝试发送消息。注意，这可能会导致发送PAPresultnotification-message。对于实体和消息头转换处理失败的消息应有如下的状态报告：PAP 属性属性值message-state"undeliverable"Code"transformation-failure"如果消息转换成功，对于未传送的消息应有如下状态报告：PAP 属性属性值message-state"pending"3.2.2.3.3 消息的空中传送3.2.2.3.3.1 概述该功能的目的是向OTA客户端传送消息。实现这项功能的关键所在是Push OTAPushOTA协议的选择、确认和非确认push方式的选择，以及消息的空中传送。PPG的实现可能包括对消息过期和取消、消息重传和传送超时、承载管理和WSP会话(如果使用OTAWSP)、注册上下文（如果使用OTAHTTP）管理或注册状态（如果使用OTA-SIP）等等的测试。3.2.2.3.3.2 Push OTA 协议的选择移动终端可能会同时支持OTAWSP和OTAHTTP见PushOTA。PPG按照与实现相关的方式为面向连接的Push选择OTA协议变量。PPG通过发送会话初始请求（SIR）向终端提交选取结果，SIR中包含OTA-WSP和OTAHTTP的连接点的列表。这一过程和SIR在 PushOTA中定义。PPG应通过获得终端信息或网络信息，根据对Push客户端已知的情况获得Push客户端信息，选择OTA协议变量，如下：l 基于检查在移动终端和PPG之间是否有SIP注册l 承载网络是否可用l 通过查询UAProf，判断是否是移动终端能力支持的协议变量l PI指示Push客户端的信息还包括客户端的承载方式列表，优先级信息，客户端的在线信息，能力信息，偏好信息或客户端设置的信息等。PPG根据以上Push客户端信息，网络情况信息，判断使用的OTA协议变量，向选择的Push客户端发送Push消息。当优先级高的OTA协议变量不可用时，使用下一级协议变量作为Push消息的承载方式。PPG可以通过发送SIR消息，并在SIR消息中给出OTA-WSP，OTA-HTTP和OTA-SIP联系点列表让终端选择适当的承载方式。此方法在Push OTA有定义。当然，PI如果指示其接受客户端在响应中返回内容来响应“confirmed Push ”，那么应选择OTA-HTTP或OTA-SIP方法。如果PPG无法选择OTA-HTTP或OTA-SIP方法，PAP应在“resultnotificationmessage”消息中指示传递方法选择失败。3.2.2.3.3.3 承载网络选择如果在PAP push-message元素的Qos部分要求使用特定的承载和或网络，则PPG应使用特定的承载和或网络，或对于带有如下状态报告的消息发送失败：P