One document matched: draft-thomson-webpush-aggregate-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<rfc ipr="trust200902" docName="draft-thomson-webpush-aggregate-00" category="std">

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

  <front>
    <title abbrev="Push Aggregation">Web Push Channel Aggregation</title>

    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <postal>
          <street>331 E Evelyn Street</street>
          <city>Mountain View</city>
          <code>94041</code>
          <country>United States</country>
        </postal>
        <email>martin.thomson@gmail.com</email>
      </address>
    </author>

    <date year="2014" month="October" day="08"/>

    <area>RAI</area>
    <workgroup>WebPush</workgroup>
    <keyword>Internet-Draft</keyword> <keyword>Push</keyword> <keyword>Web Push</keyword> <keyword>Notification</keyword> <keyword>Broadcast</keyword> <keyword>Multicast</keyword>

    <abstract>


<t>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.</t>



    </abstract>


  </front>

  <middle>


<section anchor="intro" title="Introduction">

<t>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 <xref target="I-D.thomson-webpush-http2"/>.</t>

<t>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.</t>

<t>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.</t>

</section>
<section anchor="terminology" title="Terminology">

<t>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 <xref target="RFC2119"/>.</t>

</section>
<section anchor="list-registration-service" title="List Registration Service">

<t>A new link relation <xref target="RFC5988"/>, <spanx style="verb">....:push:aggregate</spanx>, is provided in response
to a push registration or channel creation request.  This link relation
identifies an aggregation service that can be used to create a new aggregated
push channel.</t>

<t>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.</t>

<t>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.</t>

<t><list style="hanging">
  <t hangText='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.</t>
</list></t>

<t>Absence of the <spanx style="verb">...:aggregate</spanx> link relation indicates that the push server does
not support channel aggregation.</t>

<section anchor="creating-an-aggregated-channel" title="Creating an Aggregated Channel">

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

<t>The response is identical to the response to the <spanx style="verb">channel</spanx> resource, as
described in Section 5 of <xref target="I-D.thomson-webpush-http2"/>.  The 201 (Created)
response contains the identity of the aggregated channel in the Location header
field.</t>

<t>Messages pushed to the aggregated channel URI (see Section 3 of
<xref target="I-D.thomson-webpush-http2"/>) are forwarded to all of the channels that are
included in the provided list.</t>

</section>
<section anchor="aggregation-channel-request-format" title="Aggregation Channel Request Format">

<t>The content of this request is a JSON <xref target="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:</t>

<t><list style="hanging">
  <t hangText='expires:'>
  A date and time in <xref target="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.</t>
  <t hangText='pubkey:'>
  The public key to be used for encrypting messages on ths channel. This field
is optional.  [[TBD: This - primarily the corresponding CPU load - is probably
the largest problem with this security architecture.]]</t>
</list></t>

<t>This format is identified using a MIME media type of
“application/push-aggregation+json” <xref target="IANA"/>.</t>

<t>Push aggregation services MUST support gzip Content-Encoding for this format.</t>

</section>
<section anchor="determining-aggregation-set-status" title="Determining Aggregation Set Status">

<t>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.</t>

<t>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.</t>

</section>
<section anchor="modifying-the-aggregation-set" title="Modifying the Aggregation Set">

<t>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 <xref target="I-D.ietf-appsawg-json-merge-patch"/> document.</t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>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
<xref target="I-D.thomson-webpush-http2"/> apply, though these are significantly more
important.</t>

<t>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.</t>

<t>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.</t>

</section>
<section anchor="IANA" title="IANA Considerations">

<t>TODO: expand with details</t>

<section anchor="registration-of-link-relation-type" title="Registration of Link Relation Type">

<t>A link relation for the link aggregation resource is registered accordinging to
the rules in <xref target="RFC5988"/>.</t>

</section>
<section anchor="registration-of-mime-media-type" title="Registration of MIME Media Type">

<t>A new MIME media type, “application/push-aggregation+json” is registered
according to the rules in TODO.</t>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='RFC2119'>

<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      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
      RFC 2119.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>

<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>



<reference anchor='I-D.thomson-webpush-http2'>
<front>
<title>Generic Event Delivery Using HTTP Push</title>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<date month='May' day='12' year='2014' />

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

</front>

<seriesInfo name='Internet-Draft' value='draft-thomson-webpush-http2-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-thomson-webpush-http2-00.txt' />
</reference>



<reference anchor='RFC5988'>

<front>
<title>Web Linking</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
<organization /></author>
<date year='2010' month='October' />
<abstract>
<t>This document specifies relation types for Web links, and defines a registry for them.  It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='5988' />
<format type='TXT' octets='46834' target='http://www.rfc-editor.org/rfc/rfc5988.txt' />
</reference>



<reference anchor='RFC7159'>

<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author initials='T.' surname='Bray' fullname='T. Bray'>
<organization /></author>
<date year='2014' month='March' />
<abstract>
<t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t><t> This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t></abstract></front>

<seriesInfo name='RFC' value='7159' />
<format type='TXT' octets='27451' target='http://www.rfc-editor.org/rfc/rfc7159.txt' />
</reference>



<reference anchor='I-D.ietf-appsawg-json-merge-patch'>
<front>
<title>JSON Merge Patch</title>

<author initials='P' surname='Hoffman' fullname='Paul Hoffman'>
    <organization />
</author>

<author initials='J' surname='Snell' fullname='James Snell'>
    <organization />
</author>

<date month='August' day='21' year='2014' />

<abstract><t>This specification defines the JSON merge patch format and processing rules.  The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-appsawg-json-merge-patch-07' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-merge-patch-07.txt' />
</reference>



<reference anchor='RFC3339'>

<front>
<title>Date and Time on the Internet: Timestamps</title>
<author initials='G.' surname='Klyne' fullname='Graham Klyne' role='editor'>
<organization>Clearswift Corporation</organization>
<address>
<postal>
<street>1310 Waterside</street>
<street>Arlington Business Park</street>
<city>Theale</city>
<region>Reading</region>
<code>RG7 4SA</code>
<country>UK</country></postal>
<phone>+44 11 8903 8903</phone>
<facsimile>+44 11 8903 9000</facsimile>
<email>GK@ACM.ORG</email></address></author>
<author initials='C.' surname='Newman' fullname='Chris Newman'>
<organization>Sun Microsystems</organization>
<address>
<postal>
<street>1050 Lakes Drive, Suite 250</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>USA</country></postal>
<email>chris.newman@sun.com</email></address></author>
<date year='2002' month='July' />
<abstract>
<t>
   This document defines a date and time format for use in Internet
   protocols that is a profile of the ISO 8601 standard for
   representation of dates and times using the Gregorian calendar.
     </t></abstract></front>

<seriesInfo name='RFC' value='3339' />
<format type='TXT' octets='35064' target='http://www.rfc-editor.org/rfc/rfc3339.txt' />
<format type='HTML' octets='65570' target='http://xml.resource.org/public/rfc/html/rfc3339.html' />
<format type='XML' octets='37259' target='http://xml.resource.org/public/rfc/xml/rfc3339.xml' />
</reference>




    </references>




  </back>
</rfc>