Push Access Protocol

PAP is a protocol defined in WAP-164 of the Wireless Application Protocol suite from the Open Mobile Alliance. PAP is used for communicating with the Push Proxy Gateway, which is usually part of a WAP Gateway.

PAP is intended for use in delivering content from Push Initiators to Push Proxy Gateways for subsequent delivery to narrow band devices, including cellular phones and pagers. Example messages include news, stock quotes, weather, traffic reports, and notification of events such as email arrival. With push functionality, users are able to get information without having to request that information. In many cases it is important for the user to get the information as soon as it is available.

The push access protocol is not intended for use over the air.

PAP is designed to be independent of the underlying transport protocol. PAP specifies the following possible operations between the Push Initiator and the Push Proxy Gateway:

a) Submit a Push

b) Cancel a Push

c) Query for status of a Push

d) Query for wireless device capabilities

e) Result notification

The interaction between the Push Initators and the Push Proxy Gateways is in the form of XML messages.

Push Submission

The purpose of the Push Submission is to deliver a push message from a Push Initiator to a PPG, which should then deliver the message to a user agent in a device on the wireless network. The Push message contains a control entity and a content entity, and MAY contain a capabilities entity. The control entity is an XML document that contains control information (push-message) for the PPG to use in processing the message for delivery. The content entity represents content to be sent to the wireless device. The capabilities entity contains client capabilities assumed by the Push Initiator and is in the RDF [RDF] format as defined in the User Agent Profile [UAPROF]. The PPG MAY use the capabilities information to validate that the message is appropriate for the client. The response to the push request is an XML document (push-response, section 9.3) that indicates initial acceptance or failure. At minimum the PPG MUST validate against the DTD [XML] the control entity in the message and report the result in the response. The PPG MAY indicate, using progress-note (if requested by the Push initiator in the progress-notes-requested attribute), that other validations have been completed. The contents and number of progress-notes are implementation specific. A typical response message may contain progress notes for each stage of internal processing. The processing stages used are implementation specific. There are provisions in the Push message to specify multiple recipients. The response message corresponds to the submit message, so there is one response message for one push message, regardless of the number of addresses specified. If the Push Initiator desires information related to the final outcome of the delivery, then it MUST request a result notification information in the push submission and provide a return address (e.g. URL).

Result Notification:

This operation is used by the PPG to inform the initiator of the final outcome of a push submission, if requested by the Push Initiator. This notification (arrow 5, below) tells the Push Initiator that the message was sent (transmitted, as in arrow 3), delivered (confirmation received from wireless device, as in arrow 4), it expired, was cancelled, or there was an error. If there was a processing error, the notification SHOULD be sent immediately upon detection of the error to the Push Initiator and the message should not be sent to the client. Otherwise, the notification MUST be sent after the message delivery process has been completed. The delivery process is considered completed when the message is no longer a candidate for delivery, e.g. the message has expired. If the push submission is indicated as rejected in step two in figure 3, then no result notification will be sent. The Push Initiator MUST have provided a return address (e.g. URL) during the push operation for this notification to be possible.

== Push Cancellation: ==

The purpose of the Push Cancellation is to allow the Push Initiator to attempt to cancel a previously submitted push message. The Push Initiator initiates this operation. The PPG responds with an indication of whether the request was successful or not.