[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
WebPush                                                       M. Thomson
Internet-Draft                                                   Mozilla
Intended status: Standards Track                        October 08, 2014
Expires: April 11, 2015


                      Web Push Channel Aggregation
                   draft-thomson-webpush-aggregate-00

Abstract

   The Web Push protocol provides a means of ensuring constant network
   availability of devices that would otherwise have limited
   availability.  This document describes extensions to that protocol
   that enable the efficient delivery of messages to multiple devices.
   This allows an application to request that a web push server deliver
   the same message to a potentially large set of devices.

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 April 11, 2015.

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




Thomson                  Expires April 11, 2015                 [Page 1]


Internet-Draft              Push Aggregation                October 2014


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  List Registration Service . . . . . . . . . . . . . . . . . .   2
     3.1.  Creating an Aggregated Channel  . . . . . . . . . . . . .   3
     3.2.  Aggregation Channel Request Format  . . . . . . . . . . .   3
     3.3.  Determining Aggregation Set Status  . . . . . . . . . . .   4
     3.4.  Modifying the Aggregation Set . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Registration of Link Relation Type  . . . . . . . . . . .   5
     5.2.  Registration of MIME Media Type . . . . . . . . . . . . .   5
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   The delivery of the same message to large numbers of devices is a
   common feature of push notification services.  This document
   describes a mechanism based on the Web Push protocol
   [I-D.thomson-webpush-http2].

   A new link relation is added to the Web Push registration response.
   This identifies a service that can be used to create a push channel
   endpoint that aggregates multiple individual push channels.

   Applications can use the aggregated channel to deliver the same push
   message on all of the aggregated channels with a single request.
   This makes the large-scale delivery of identical messages more
   efficient.

2.  Terminology

   In cases where normative language needs to be emphasized, this
   document 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].

3.  List Registration Service

   A new link relation [RFC5988], "....:push:aggregate", is provided in
   response to a push registration or channel creation request.  This




Thomson                  Expires April 11, 2015                 [Page 2]


Internet-Draft              Push Aggregation                October 2014


   link relation identifies an aggregation service that can be used to
   create a new aggregated push channel.

   If the link relation is provided in response to a push registration
   creation request, it applies to all channels created on that
   registration; if the link relation is provided in response to a
   channel creation request, it applies to just that channel.

   Applications that send notifications to a large number of users first
   establish a list of devices that have the same aggregation service
   URI.  Push servers provide a small number of different values for the
   aggregate link relation.

   Note:  Though the use of different push servers will ensure that
      applications will need to support multiple aggregation services, a
      large number of endpoints diminishes the value of having messages
      distributed by the push server.

   Absence of the "...:aggregate" link relation indicates that the push
   server does not support channel aggregation.

3.1.  Creating an Aggregated Channel

   A new aggregated channel is created by sending an HTTP POST request
   to the aggregation service URI.  The request contains

   The response is identical to the response to the "channel" resource,
   as described in Section 5 of [I-D.thomson-webpush-http2].  The 201
   (Created) response contains the identity of the aggregated channel in
   the Location header field.

   Messages pushed to the aggregated channel URI (see Section 3 of
   [I-D.thomson-webpush-http2]) are forwarded to all of the channels
   that are included in the provided list.

3.2.  Aggregation Channel Request Format

   The content of this request is a JSON [RFC7159] object.  The keys in
   the object are the URIs of the channels being aggregated.  The
   corresponding value is an object containing the following keys:

   expires:  A date and time in [RFC3339] format that identifies when
      the provided channel becomes invalid.  The push server MUST remove
      the channel from the aggregation set when this time expires.  This
      field is optional, in which case the channel does not expire.

   pubkey:  The public key to be used for encrypting messages on ths
      channel.  This field is optional.  [[TBD: This - primarily the



Thomson                  Expires April 11, 2015                 [Page 3]


Internet-Draft              Push Aggregation                October 2014


      corresponding CPU load - is probably the largest problem with this
      security architecture.]]

   This format is identified using a MIME media type of "application/
   push-aggregation+json" Section 5.

   Push aggregation services MUST support gzip Content-Encoding for this
   format.

3.3.  Determining Aggregation Set Status

   Editors note: This might needs to live on a different URI to avoid
   confusion about what is being PUT there (for pushing) and all this
   stuff.

   A GET request to the aggregated channel URI does not provide the last
   message sent.  Instead, it produces the current set of channels that
   are included in "application/push-aggregation+json" format.

3.4.  Modifying the Aggregation Set

   A PATCH request to the aggregated channel URI can be used to update
   the set of channels that are included in the set.  This uses an
   request body containing a JSON Merge
   [I-D.ietf-appsawg-json-merge-patch] document.

4.  Security Considerations

   This protocol provides an application a way to use a relatively small
   message to cause a large amount of data to be sent.  This adds
   considerably to the denial of service risks the protocol poses to
   devices.  The basic mitigations in [I-D.thomson-webpush-http2] apply,
   though these are significantly more important.

   Of particular concern is access control to the aggregated channel
   URI.  The aggregate channel URI is only used by the entity that
   requests its creation; therefore, this can be ensured by making the
   URI difficult to guess.  That is, the same entropy requirements apply
   to aggregated channel URIs as for other channel URIs.

   Messages sent over aggregated push channels do not have
   confidentiality and integrity protection, unless applications provide
   a mechanism within the message payload.  Since the information is
   pushed to multiple recipients, these channels are unsuitable for
   confidential information.






Thomson                  Expires April 11, 2015                 [Page 4]


Internet-Draft              Push Aggregation                October 2014


5.  IANA Considerations

   TODO: expand with details

5.1.  Registration of Link Relation Type

   A link relation for the link aggregation resource is registered
   accordinging to the rules in [RFC5988].

5.2.  Registration of MIME Media Type

   A new MIME media type, "application/push-aggregation+json" is
   registered according to the rules in TODO.

6.  Normative References

   [I-D.ietf-appsawg-json-merge-patch]
              Hoffman, P. and J. Snell, "JSON Merge Patch", draft-ietf-
              appsawg-json-merge-patch-07 (work in progress), August
              2014.

   [I-D.thomson-webpush-http2]
              Thomson, M., "Generic Event Delivery Using HTTP Push",
              draft-thomson-webpush-http2-00 (work in progress), May
              2014.

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

   [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
              Internet: Timestamps", RFC 3339, July 2002.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988, October 2010.

   [RFC7159]  Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, March 2014.

Author's Address

   Martin Thomson
   Mozilla
   331 E Evelyn Street
   Mountain View  94041
   United States

   Email: martin.thomson@gmail.com





Thomson                  Expires April 11, 2015                 [Page 5]