WEBPUSH                                                       M. Thomson
Internet-Draft                                                   Mozilla
Intended status: Standards Track                            May 12, 2014
Expires: November 13, 2014

                 Generic Event Delivery Using HTTP Push


   A simple scheme for the delivery of realtime events to clients is
   described.  This scheme uses HTTP/2 push.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 13, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Thomson                 Expires November 13, 2014               [Page 1]

Internet-Draft                  HTTP Push                       May 2014

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Delivering Push Messages  . . . . . . . . . . . . . . . . . .   5
   4.  Registering . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Channels  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Monitoring and Receiving Push Messages  . . . . . . . . . . .   6
   7.  Store and Forward Operation . . . . . . . . . . . . . . . . .   6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     10.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Mobile computing devices are increasingly relied upon for a great
   many applications.  Mobile devices typically have limited power
   reserves, so finding more efficient ways to serve application
   requirements is an important part of any mobile platform.

   One significant contributor to power usage mobile devices is the
   radio.  Cellular - and to a lesser extent, IEEE 802 radios - consume
   a significant portion of the energy budget on a wirelessly connected
   mobile device.

   Many applications require continuous access to network communications
   so that real-time events - such as incoming calls or messages - can
   be conveyed (or "pushed") to the user in a timely fashion.
   Uncoordinated use of persistent connections or sessions from multiple
   applications can contribute to unnecessary use of the device radio,
   since each independent session independently incurs overheads.  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.

Thomson                 Expires November 13, 2014               [Page 2]

Internet-Draft                  HTTP Push                       May 2014

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

   o  request the delivery of an event to an attached device

   o  register a new device, create new event delivery channels, and
      monitor those channels for new events

   This is intentionally split into these two categories because
   requesting the delivery of events is required for immediate use by
   the Web Push API.  The registration, management and monitoring
   functions are currently fulfilled by proprietary protocols; these are
   adequate, but do not offer any advantages that standardization

   The monitoring function described in this document is intended to be
   replaceable, enabling the use of monitoring schemes that are better
   optimized for the network environment and the device.  For instance,
   using notification systems like the GSM Short Message Service (SMS)
   can take advantage of the native paging capabilities of a cellular
   network, avoiding the ongoing maintainence cost of a persistent TCP

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

   Similarly, discovery of support for and negotiation of use of
   alternative monitoring schemes is left to documents that extend this
   basic protocol.

1.1.  Conventions and Terminology

   In cases where normative language needs to be emphasized, this
   document falls back on established shorthands for expressing
   interoperability requirements on implementations: the capitalized
   words "MUST", "MUST NOT", "SHOULD" and "MAY".  The meaning of these
   is described in [RFC2119].

   This document will use the terminology from [API], though
   "application" will be used in preference to "webapp", since the
   described protocols are not restricted to web use.  This document
   introduces the term "device", which refers to the consumer of push

Thomson                 Expires November 13, 2014               [Page 3]

Internet-Draft                  HTTP Push                       May 2014

2.  Overview

   A general model for push services includes three basic actors: a
   device, a push server, and an application.

     +-----------+        +-------------+        +-------------+
     |  Device   |        | Push Server |        | Application |
     +-----------+        +-------------+        +-------------+
          |                      |                      |
          |      Register        |                      |
          |--------------------->|                      |
          |       Monitor        |                      |
          |<====================>|                      |
          |     Get Channel      |                      |
          |--------------------->|                      |
          |           Provide Channel                   |
          |                      |     Push Message     |
          |    Push Message      |<---------------------|
          |<---------------------|                      |
          |                      |                      |

   At the very beginning of the process, the device registers with the
   push server.  This establishes a shared session between the device
   and push server that will be used to aggregate push messages from all
   applications that the device interacts with.

   The registration response includes details on how the device is
   expected to monitor for incoming push messages.  This document
   describes one such mechanism, though more efficient means of
   monitoring could be optionally defined (and this is expressly

   A registration after creation has no channels associated with it.
   New channels can be requested by the device and then distributed to
   applications.  It is expected that devices will distribute a
   different channel to each application, with the potential for
   multiple channels being provided to the same application.

   Applications use channels to deliver push messages to devices, via
   the push server.

   Both registrations and channels have a limited lifetime.  These will
   need to be refreshed over time.

Thomson                 Expires November 13, 2014               [Page 4]

Internet-Draft                  HTTP Push                       May 2014

3.  Delivering Push Messages

   A push channel is identified with an HTTP URI
   [I-D.ietf-httpbis-p1-messaging].  An application can request the
   delivery of a push message by sending an HTTP PUT request to this
   URI, including the push message in the body of the request.

   A push server can acknowledge the end-to-end delivery of a push
   message by responding with a 200 (OK) status code.  A push server
   that stores the message for later delivery (see Section 7) could
   respond with a 202 (Accepted) status code to indicate that the
   message was stored, but not delivered.

4.  Registering

   A device that wishes to establish a new or replacement registration
   sends an HTTP POST request to its configured push server URL.  The
   request contains no entity body.

   The push server creates a new registration in response to this
   request, creating two new resources and allocating an HTTP URI for
   each.  These URIs are included in link relations that are included in
   Link header fields in the response.

   monitor:  A link relation of type "...:push:monitor" includes the URL
      of a resource that the device can monitor for events.  Monitoring
      is described in Section 6.

   channel:  A link relation of type "...:push:channel" includes a URL
      of a resource where the device can create new channels.  Creating
      channels is described in Section 5.

   The push server includes the "monitor" link relation in a Location
   header field.

   The push server MUST include expiration information in the response
   to this request in either the Expires header field, or by setting a
   "max-age" parameter on a Cache-Control header field.  The Cache-
   Control header field MUST include the "private" directive

   The push server SHOULD also provide the "channel" link and expiration
   information in response to requests to the "monitor" resource.

Thomson                 Expires November 13, 2014               [Page 5]

Internet-Draft                  HTTP Push                       May 2014

5.  Channels

   A client sends a POST request to the "channel" resource to create a
   new channel.

   A response with a 201 status code includes the channel URI in the
   Location header field.

   A channel can expire.  Servers indicate this using the Expires header
   field, or by setting a "max-age" parameter on a Cache-Control header

   A client can explicitly delete a channel by sending a DELETE request
   to channel URI.

6.  Monitoring and Receiving Push Messages

   A device monitors for new events by making a GET request to the
   monitor resource.  The server does not respond to these request, it
   instead uses server push [I-D.ietf-httpbis-http2] to send the
   contents of push messages as applications send them.

   Each push message consists of a synthesized GET request to the
   channel URI that was the target of the push.  The response body is
   the entity body from the PUT request.

   A device can request the monitor resource immediately by including a
   Prefer header field [I-D.snell-http-prefer] with a "wait" parmeter
   set to "0".

   A server that wishes to redistribute load can do so using The
   alternative services mechanisms that are part of HTTP/2
   [I-D.ietf-httpbis-alt-svc].  The ALTSVC frame type allows for
   redistribution of load whilst retaining the same monitor resource.
   Once a device has established a replacement connection, it can notify
   the server of imminent shutdown using a GOAWAY frame, which allows
   the server to respond to the long-standing GET request and gracefully
   shut down the connection.  This allows for seamless migration between

7.  Store and Forward Operation

   Push servers are not obligated to store messages for any time.  If a
   client is not actively monitoring for push messages, messages can be

   Push servers are permitted to store messages for some time to allow
   for limited recovery from transient faults.  If a message is stored,

Thomson                 Expires November 13, 2014               [Page 6]

Internet-Draft                  HTTP Push                       May 2014

   but not delivered, the push server can indicate the probable duration
   of storage by including expiration information in the response to the
   push request.

   Messages that were stored and not delivered to a client MAY be
   delivered when a client commences monitoring.  These messages should
   include a Last-Modified header field.  If a server stores push
   messages, a GET request to a channel URI returns the last message
   sent by an application to that channel.

   Push servers that store push messages might need to limit the size of
   push messages to avoid being subject to overloading.  Push servers
   that don't store can stream the payload of push messages to devices.
   This can use HTTP/2 flow control to limit the state commitment this
   requires.  However, push servers MAY place an upper limit on the size
   of push messages that they permit.

8.  IANA Considerations

   TODO: register link relation types, as necessary.

9.  Security Considerations

   This protocol does not specific a single authorization framework for
   managing access to push servers, either by devices or applications.
   Thus, there is a very real possibility that this could be exploited
   to mount denial of service attacks on the push service.

   Push services MAY choose to authorize requests based on any HTTP-
   compatible means available, of which there are numerous options.

   A malicious application can use the greater resources of a push
   server to mount a denial of service attack on devices.  Push servers
   MAY limit the rate at which push messages are sent to devices.

   One basic protection against misuse of push channels is to ensure
   that only authorized applications are given channel URIs and to make
   it extremely difficult to successfully guess a valid channel URI.
   Encoding a large amount of random entropy in the URI path is one
   technique for ensuring that channel URIs are able to act as bearer

   A push server is able to see (and modify) the content of push
   messages.  Applications that depend on end-to-end guarantees MUST use
   object security mechanisms to protect the confidentiality and
   integrity of push messages.  Since the application frequently resides
   both in the server that originates the push messages and in the
   device, and there is a requirement for direct communications between

Thomson                 Expires November 13, 2014               [Page 7]

Internet-Draft                  HTTP Push                       May 2014

   these two instances to exchange channel information, this provides a
   perfect medium for key agreement.

   A push server is also able to deny service.  In addition to malicious
   reasons, delivery of push messages can fail due to transient faults
   in networks, the device being temporarily unavailable, or other
   similar faults.  Therefore, applications that rely on the content of
   push messages being delivered MUST ensure that they provide other
   means of delivering messages to devices.

10.  References

10.1.  Normative References

              mnot, m., McManus, P., and J. Reschke, "HTTP Alternative
              Services", draft-ietf-httpbis-alt-svc-01 (work in
              progress), April 2014.

              Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
              Protocol version 2", draft-ietf-httpbis-http2-12 (work in
              progress), April 2014.

              Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Message Syntax and Routing", draft-ietf-
              httpbis-p1-messaging-26 (work in progress), February 2014.

              Fielding, R., mnot, m., and J. Reschke, "Hypertext
              Transfer Protocol (HTTP/1.1): Caching", draft-ietf-
              httpbis-p6-cache-26 (work in progress), February 2014.

              Snell, J., "Prefer Header for HTTP", draft-snell-http-
              prefer-18 (work in progress), January 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

   [API]      Sullivan, B. and E. Fullea, "Web Push API", Editor's Draft
              push-api, May 2014, <https://w3c.github.io/push-api/

Thomson                 Expires November 13, 2014               [Page 8]

Internet-Draft                  HTTP Push                       May 2014

Author's Address

   Martin Thomson
   331 E Evelyn Street
   Mountain View, CA  94041

   Email: martin.thomson@gmail.com

Thomson                 Expires November 13, 2014               [Page 9]