Skip to main content

1. Introduction

1. Introduction​

Many applications on mobile and embedded devices require continuous access to network communications so that real-time events -- such as incoming calls or messages -- can be delivered (or "pushed") in a timely fashion. These devices typically have limited power reserves, so finding more efficient ways to serve application requirements greatly benefits the application ecosystem.

One significant contributor to power usage is the radio. Radio communications consume a significant portion of the energy budget on a wireless device.

Uncoordinated use of persistent connections or sessions from multiple applications can contribute to unnecessary use of the device radio, since each independent session can incur its own overhead. In particular, keep-alive traffic used to ensure that middleboxes do not prematurely time out sessions can result in significant waste. Maintenance traffic tends to dominate over the long term, since events are relatively rare.

Consolidating all real-time events into a single session ensures more efficient use of network and radio resources. A single service consolidates all events, distributing those events to applications as they arrive. This requires just one session, avoiding duplicated overhead costs.

The W3C Push API [API] describes an API that enables the use of a consolidated push service from web applications. This document expands on that work by describing a protocol that can be used to:

  • request the delivery of a push message to a user agent,

  • create new push message delivery subscriptions, and

  • monitor for new push messages.

A standardized method of event delivery is particularly important for the W3C Push API, where application servers might need to use multiple push services. The subscription, management, and monitoring functions are currently fulfilled by proprietary protocols; these are adequate, but do not offer any of the advantages that standardization affords.

This document intentionally does not describe how a push service is discovered. Discovery of push services is left for future efforts, if it turns out to be necessary at all. User agents are expected to be configured with a URL for a push service.

1.1. Conventions and Terminology​

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

This document defines the following terms:

application: Both the sender and the ultimate consumer of push messages. Many applications have components that are run on a user agent and other components that run on servers.

application server: The component of an application that usually runs on a server and requests the delivery of a push message.

push message subscription: A message delivery context that is established between the user agent and the push service, and shared with the application server. All push messages are associated with a push message subscription.

push message subscription set: A message delivery context that is established between the user agent and the push service that collects multiple push message subscriptions into a set.

push message: A message sent from an application server to a user agent via a push service.

push message receipt: A message delivery confirmation sent from the push service to the application server.

push service: A service that delivers push messages to user agents.

user agent: A device and software that is the recipient of push messages.

Examples in this document use the HTTP/1.1 message format [RFC7230]. Many of the exchanges can be completed using HTTP/1.1:

  • Subscribing for Push Messages (Section 4)

  • Requesting Push Message Delivery (Section 5)

  • Replacing Push Messages (Section 5.4)

  • Acknowledging Push Messages (Section 6.2)

When an example depends on HTTP/2 server push, the more verbose frame format from [RFC7540] is used:

  • Receiving Push Messages for a Subscription (Section 6)

  • Receiving Push Messages for a Subscription Set (Section 6.1)

  • Receiving Push Message Receipts (Section 6.3)

All examples use HTTPS over the default port (443) rather than the registered port (1001). A push service deployment might prefer this configuration to maximize chances for user agents to reach the service. A push service might use HTTP alternative services to redirect a user agent to the registered port (1001) to gain the benefits of the standardized HTTPS port without sacrificing reachability (see Section 3). This would only be apparent in the examples through the inclusion of the Alt-Used header field [RFC7838] in requests from the user agent to the push service.

Examples do not include specific methods for push message encryption or application server authentication because the protocol does not define a mandatory system. The examples in Voluntary Application Server Identification [VAPID] and Message Encryption for WebPush [ENCRYPT] demonstrate the approach adopted by the W3C Push API [API] for its requirements.

Last updated on