Wireless Application Protocol (WAP) is a technical standard for accessing information over a mobile wireless network. A WAP browser is a web browser for mobile devices such as mobile phones that uses the protocol. Introduced with much hype in 1999, WAP achieved some popularity in the early 2000s, but by the 2010s it had been largely superseded by more modern standards. Most modern handset internet browsers now fully support HTML, so they do not need to use WAP markup for web page compatibility, and therefore, most are no longer able to render and display pages written in WML, WAP's markup language.
The Open Mobile Alliance (OMA) is a standards body which develops open standards for the mobile phone industry. It is not a formal government-sponsored standards organization like the ITU, but a forum for industry stakeholders to agree on common specifications for products and services.
A Push Proxy Gateway is a component of WAP Gateways that pushes URL notifications to mobile handsets. Notifications typically include MMS, email, IM, ringtone downloads, and new device firmware notifications. Most notifications will have an audible alert to the user of the device. The notification will typically be a text string with a URL link. Note that only a notification is pushed to the device; the device must do something with the notification in order to download or view the content associated with it.
PAP is intended for use in delivering content from Push Initiators to Push Proxy Gateways for subsequent delivery to narrow band devices, including mobile 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 receive information without having to request it. In many cases it is important for the user to get the information as soon as it is available.
A mobile phone, cell phone, cellphone, or hand phone, sometimes shortened to simply mobile, cell or just phone, is a portable telephone that can make and receive calls over a radio frequency link while the user is moving within a telephone service area. The radio frequency link establishes a connection to the switching systems of a mobile phone operator, which provides access to the public switched telephone network (PSTN). Modern mobile telephone services use a cellular network architecture, and, therefore, mobile telephones are called cellular telephones or cell phones, in North America. In addition to telephony, 2000s-era mobile phones support a variety of other services, such as text messaging, MMS, email, Internet access, short-range wireless communications, business applications, video games, and digital photography. Mobile phones offering only those capabilities are known as feature phones; mobile phones which offer greatly advanced computing capabilities are referred to as smartphones.
A pager is a wireless telecommunications device that receives and displays alphanumeric or voice messages. One-way pagers can only receive messages, while response pagers and two-way pagers can also acknowledge, reply to, and originate messages using an internal transmitter.
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:
Submit a Push
Cancel a Push
Query for status of a Push
Query for wireless device capabilities
Result notification
The interaction between the Push Initiators and the Push Proxy Gateways is in the form of XML messages.
Extensible Markup Language (XML) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. The W3C's XML 1.0 Specification and several other related specifications—all of them free open standards—define XML.
Operations
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.
Status Query
The status query operation allows the Push Initiator to request the current status of a message that has been previously submitted. If status is requested for a message which is addressed to multiple recipients, the PPG MUST send back a single response containing status query results for each of the recipients.
Client Capabilities Query
This operation allows the Push Initiator to query the PPG for the capabilities of a specific device. The response is a multipart/related document containing the ccq-response (section 9.11) element in an XML document and, in the second entity, the actual client capabilities information in RDF [RDF] as defined in the User Agent Profile [UAPROF]. The PPG MAY add to the capabilities reported if the PPG is willing to perform transformations to the formats supported by the client. For example, if a client has JPG support but not GIF and a PPG is willing to convert GIF files to JPG, then the PPG may report that the client can support JPG and GIF files. The capabilities reported may be the combined PPG and client capabilities and they may have been derived from session capabilities or retrieved from a CC/PP server. Capabilities may also be derived using implementation dependent means.
Addressing
There are three addresses to be considered by the Push Initiator: the push proxy gateway address, the wireless device address, and the result notification address. The push proxy gateway address must be known by the Push Initiator. This address is needed at the layer below the push access protocol. The push proxy gateway is addressed using a unique address that depends on the underlying protocol. For example, when the underlying protocol is HTTP, a URL [RFC1738] is used. The device addressing information is included as part of the message content (XML tagged content). Any character allowed in an RFC822 address may appear in the device address field. In addition, a “notify-requested-to” address may be provided by the Push Initiator when required so that the push proxy gateway can later respond to the Push Initiator with result notification.
Multiple Recipient Addressing
There are scenarios in which a Push Initiator may want to send identical messages to multiple recipients. Rather than submitting multiple identical push messages, one to each recipient, the Push Initiator may submit a single push message addressed to multiple recipients. This section is intended to clarify behaviour related to operations on multiple recipients. When the PPG returns the push-response message, after a push submission to multiple recipients, the response corresponds to the message, regardless of the number of recipients specified in the push submission (there is one response for each push submission). When a Push Initiator requests status (section 9.8) with multiple addresses specified, the PPG MUST reply with a single statusquery-response (section 9.9) containing the individual statuses. The same is true when only a push-id is specified (no address specified) in the query for status of a multiple recipient message. Result notifications (section 9.6) MUST be sent by the PPG for each individual recipient, if result notification is requested by the Push Initiator during the submission of a message to multiple recipients. In cases where a message is sent to multiple recipients and later a cancel is requested by the initiator, the PPG MAY send back individual responses related to each of the multiple recipients or it MAY send responses related to many or all of the recipients. Support of multiple addresses is OPTIONAL in a PPG.
Multicast/Broadcast Addresses
There are scenarios in which a single address submitted by a PI may be expanded by a PPG into multiple addresses for delivery. In addition, a single address transmitted on a wireless network may be received by multiple devices (e.g. broadcast). This type of service is expected for the distribution of information of interest to a broad population (e.g. news, weather, and traffic). This section is intended to clarify behaviour related to operations involving multicast and broadcast addresses. Since the address expansion is done in the PPG or in the wireless network, the behaviour between the PI and the PPG is identical to behaviour as if the address were not expanded. The response contains the individual address as submitted by the PI.
In computer networking, multicast is group communication where data transmission is addressed to a group of destination computers simultaneously. Multicast can be one-to-many or many-to-many distribution. Multicast should not be confused with physical layer point-to-multipoint communication.
Message Format
The push access protocol is independent of the transport used. PAP messages carry control information, and in the case of a push submission, also content and optionally client capabilities information. Control information includes command/response messages between the PPG and the Push Initiator, and parameters passed to the PPG for use in sending content to the wireless device. Examples of this type of information include the wireless device address, the delivery priority of the message, etc. This information is not normally delivered to the wireless device. Content is information that is intended for the wireless device. This information might be intelligible only to the wireless device (e.g. may be encrypted by the Push Initiator or may be application data for an application unknown to the PPG) or it may be recognisable by the PPG (e.g. HTML or WML). The PPG may be configured to perform some transformation on recognisable content (e.g. HTML to WML) for certain wireless devices. The other category of information is client capability information as specified in the User Agent Profile [UAPROF]. When more than control is carried in a message, the format of the message is a MIME multipart/related [RFC2387] compound object. When only control information (e.g. for message responses) is carried in a message, the format of the message is a simple application/xml entity. All information is transported within a single message body. In the multipart messages, the first entity contains all push related control information in an XML document, the second entity contains the content for the wireless device, the third entity, if present, contains UAPROF client capabilities. The format of the content entity is specified in [PushMsg].
Control Entity Format
The control entity is a MIME body part which holds an XML document containing one pap element as defined in section 9.1. The control entity MUST be included in every PAP request and response. The control entity MUST be the first entity in the MIME multipart/related message.
Content Entity Format
The content entity is a MIME body part containing the content to be sent to the wireless device. The content type is not defined by the PAP, but can be any type as long as it is described by MIME. The content entity is included only in the push submission and is not included in any other operation request or response. The content entity MUST be the second entity in the MIME multipart/related message.
Capabilities Entity Format
The capabilities entity is a MIME body part containing the Push Initiator's assumed subset of the capabilities of the wireless device/user agent. The capabilities format is specified in the User Agent Profile [UAPROF]. The capabilities entity, if present, MUST be the third entity in the Push Submission MIME multipart/related message and MUST be the second entity in a Client Capabilities Query response.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
Related Research Articles
In computing, the Internet Message Access Protocol (IMAP) is an Internet standard protocol used by email clients to retrieve email messages from a mail server over a TCP/IP connection. IMAP is defined by RFC 3501.
Multipurpose Internet Mail Extensions (MIME) is an Internet standard that extends the format of email to support:
The Simple Mail Transfer Protocol (SMTP) is a communication protocol for electronic mail transmission. As an Internet standard, SMTP was first defined in 1982 by RFC 821, and updated in 2008 by RFC 5321 to Extended SMTP additions, which is the protocol variety in widespread use today. Mail servers and other message transfer agents use SMTP to send and receive mail messages. Proprietary systems such as Microsoft Exchange and IBM Notes and webmail systems such as Outlook.com, Gmail and Yahoo! Mail may use non-standard protocols internally, but all use SMTP when sending to or receiving email from outside their own systems. SMTP servers commonly use the Transmission Control Protocol on port number 25.
The Session Initiation Protocol (SIP) is a signaling protocol used for initiating, maintaining, and terminating real-time sessions that include voice, video and messaging applications. SIP is used for signaling and controlling multimedia communication sessions in applications of Internet telephony for voice and video calls, in private IP telephone systems, in instant messaging over Internet Protocol (IP) networks as well as mobile phone calling over LTE (VoLTE).
Simple Network Management Protocol (SNMP) is an Internet Standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. Devices that typically support SNMP include cable modems, routers, switches, servers, workstations, printers, and more.
An email client, email reader or more formally mail user agent (MUA) is a computer program used to access and manage a user's email.
In computer networks, a proxy server is a server that acts as an intermediary for requests from clients seeking resources from other servers. A client connects to the proxy server, requesting some service, such as a file, connection, web page, or other resource available from a different server and the proxy server evaluates the request as a way to simplify and control its complexity. Proxies were invented to add structure and encapsulation to distributed systems.
In computer and telecommunications networks, presence information is a status indicator that conveys ability and willingness of a potential communication partner—for example a user—to communicate. A user's client provides presence information via a network connection to a presence service, which is stored in what constitutes his personal availability record and can be made available for distribution to other users to convey his availability for communication. Presence information has wide application in many communication services and is one of the innovations driving the popularity of instant messaging or recent implementations of voice over IP clients.
In email, a return receipt is an acknowledgment by the recipient's email client to the sender of receipt of an email message. What acknowledgment, if any, is sent by the recipient to the sender is dependent on the email software of the recipient.
Push notifications are small messages that can reach audiences anywhere and anytime. There’s a difference between pop-ups and push notifications. Pop-ups appear only when audiences are on the site they belong to. Push messages are independent of sites. They are associated with web browsers and apps.
OMA Device Management is a device management protocol specified by the Open Mobile Alliance (OMA) Device Management (DM) Working Group and the Data Synchronization (DS) Working Group. The current approved specification of OMA DM is version 1.2.1, the latest modifications to this version released in June 2008. The candidate release 2.0 was scheduled to be finalized in September 2013.
Exchange ActiveSync is a proprietary protocol designed for the synchronization of email, contacts, calendar, tasks, and notes from a messaging server to a smartphone or other mobile devices. The protocol also provides mobile device management and policy controls. The protocol is based on XML. The mobile device communicates over HTTP or HTTPS.
The MMS Architecture is the set of standards used by the Multimedia Messaging Service in mobile networks. The standards are prepared by 3GPP.
Constrained Application Protocol (CoAP) is a specialized Internet Application Protocol for constrained devices, as defined in RFC 7252. It enables those constrained devices called "nodes" to communicate with the wider Internet using similar protocols.
CoAP is designed for use between devices on the same constrained network, between devices and general nodes on the Internet, and between devices on different constrained networks both joined by an internet. CoAP is also being used via other mechanisms, such as SMS on mobile communication networks.
Port Control Protocol (PCP) is a computer networking protocol that allows hosts on IPv4 or IPv6 networks to control how the incoming IPv4 or IPv6 packets are translated and forwarded by an upstream router that performs network address translation (NAT) or packet filtering. By allowing hosts to create explicit port forwarding rules, handling of the network traffic can be easily configured to make hosts placed behind NATs or firewalls reachable from the rest of the Internet, which is a requirement for many applications.
The Session Initiation Protocol (SIP) is the signaling protocol selected by the 3rd Generation Partnership Project (3GPP) to create and control multimedia sessions with two or more participants in the IP Multimedia Subsystem (IMS), and therefore is a key element in the IMS framework.
