Internet DRAFT - draft-thomson-webpush-aggregate
draft-thomson-webpush-aggregate
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]
