summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8030.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8030.txt')
-rw-r--r--doc/rfc/rfc8030.txt1739
1 files changed, 1739 insertions, 0 deletions
diff --git a/doc/rfc/rfc8030.txt b/doc/rfc/rfc8030.txt
new file mode 100644
index 0000000..87f832e
--- /dev/null
+++ b/doc/rfc/rfc8030.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Thomson
+Request for Comments: 8030 Mozilla
+Category: Standards Track E. Damaggio
+ISSN: 2070-1721 B. Raymor, Ed.
+ Microsoft
+ December 2016
+
+
+ Generic Event Delivery Using HTTP Push
+
+Abstract
+
+ This document describes a simple protocol for the delivery of real-
+ time events to user agents. This scheme uses HTTP/2 server push.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc8030.
+
+Copyright Notice
+
+ Copyright (c) 2016 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, et al. Standards Track [Page 1]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4
+ 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.1. HTTP Resources . . . . . . . . . . . . . . . . . . . . . 7
+ 3. Connecting to the Push Service . . . . . . . . . . . . . . . 8
+ 4. Subscribing for Push Messages . . . . . . . . . . . . . . . . 8
+ 4.1. Collecting Subscriptions into Sets . . . . . . . . . . . 9
+ 5. Requesting Push Message Delivery . . . . . . . . . . . . . . 10
+ 5.1. Requesting Push Message Receipts . . . . . . . . . . . . 10
+ 5.2. Push Message Time-To-Live . . . . . . . . . . . . . . . . 11
+ 5.3. Push Message Urgency . . . . . . . . . . . . . . . . . . 13
+ 5.4. Replacing Push Messages . . . . . . . . . . . . . . . . . 14
+ 6. Receiving Push Messages for a Subscription . . . . . . . . . 15
+ 6.1. Receiving Push Messages for a Subscription Set . . . . . 17
+ 6.2. Acknowledging Push Messages . . . . . . . . . . . . . . . 18
+ 6.3. Receiving Push Message Receipts . . . . . . . . . . . . . 19
+ 7. Operational Considerations . . . . . . . . . . . . . . . . . 20
+ 7.1. Load Management . . . . . . . . . . . . . . . . . . . . . 20
+ 7.2. Push Message Expiration . . . . . . . . . . . . . . . . . 20
+ 7.3. Subscription Expiration . . . . . . . . . . . . . . . . . 21
+ 7.3.1. Subscription Set Expiration . . . . . . . . . . . . . 21
+ 7.4. Implications for Application Reliability . . . . . . . . 22
+ 7.5. Subscription Sets and Concurrent HTTP/2 Streams . . . . . 22
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
+ 8.1. Confidentiality from Push Service Access . . . . . . . . 23
+ 8.2. Privacy Considerations . . . . . . . . . . . . . . . . . 23
+ 8.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 24
+ 8.4. Denial-of-Service Considerations . . . . . . . . . . . . 25
+ 8.5. Logging Risks . . . . . . . . . . . . . . . . . . . . . . 25
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
+ 9.1. Header Field Registrations . . . . . . . . . . . . . . . 26
+ 9.2. Link Relation URNs . . . . . . . . . . . . . . . . . . . 26
+ 9.3. Service Name and Port Number Registration . . . . . . . . 28
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . 28
+ 10.2. Informative References . . . . . . . . . . . . . . . . . 30
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
+
+
+
+
+
+
+
+
+
+
+
+Thomson, et al. Standards Track [Page 2]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+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:
+
+ o request the delivery of a push message to a user agent,
+
+ o create new push message delivery subscriptions, and
+
+ o 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.
+
+
+
+Thomson, et al. Standards Track [Page 3]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+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:
+
+ o Subscribing for Push Messages (Section 4)
+
+ o Requesting Push Message Delivery (Section 5)
+
+ o Replacing Push Messages (Section 5.4)
+
+ o Acknowledging Push Messages (Section 6.2)
+
+
+
+
+
+
+Thomson, et al. Standards Track [Page 4]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ When an example depends on HTTP/2 server push, the more verbose frame
+ format from [RFC7540] is used:
+
+ o Receiving Push Messages for a Subscription (Section 6)
+
+ o Receiving Push Messages for a Subscription Set (Section 6.1)
+
+ o 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomson, et al. Standards Track [Page 5]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+2. Overview
+
+ A general model for push services includes three basic actors: a user
+ agent, a push service, and an application (server).
+
+ +-------+ +--------------+ +-------------+
+ | UA | | Push Service | | Application |
+ +-------+ +--------------+ | Server |
+ | | +-------------+
+ | Subscribe | |
+ |--------------------->| |
+ | Monitor | |
+ |<====================>| |
+ | | |
+ | Distribute Push Resource |
+ |-------------------------------------------->|
+ | | |
+ : : :
+ | | Push Message |
+ | Push Message |<---------------------|
+ |<---------------------| |
+ | | |
+
+ Figure 1: WebPush Architecture
+
+ At the very beginning of the process, a new message subscription is
+ created by the user agent and then distributed to its application
+ server. This subscription is the basis of all future interactions
+ between the actors. A subscription is used by the application server
+ to send messages to the push service for delivery to the user agent.
+ The user agent uses the subscription to monitor the push service for
+ any incoming message.
+
+ To offer more control for authorization, a message subscription is
+ modeled as two resources with different capabilities:
+
+ o A subscription resource is used to receive messages from a
+ subscription and to delete a subscription. It is private to the
+ user agent.
+
+ o A push resource is used to send messages to a subscription. It is
+ public and shared by the user agent with its application server.
+
+ It is expected that a unique subscription will be distributed to each
+ application; however, there are no inherent cardinality constraints
+ in the protocol. Multiple subscriptions might be created for the
+
+
+
+
+
+Thomson, et al. Standards Track [Page 6]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ same application, or multiple applications could use the same
+ subscription. Note, however, that sharing subscriptions has security
+ and privacy implications.
+
+ Subscriptions have a limited lifetime. They can also be terminated
+ by either the push service or the user agent at any time. User
+ agents and application servers must be prepared to manage changes in
+ the subscription state.
+
+2.1. HTTP Resources
+
+ This protocol uses HTTP resources [RFC7230] and link relations
+ [RFC5988]. The following resources are defined:
+
+ push service: This resource is used to create push message
+ subscriptions (Section 4). A URL for the push service is
+ configured into user agents.
+
+ push message subscription: This resource provides read and delete
+ access for a message subscription. A user agent receives push
+ messages (Section 6) using a push message subscription. Every
+ push message subscription has exactly one push resource associated
+ with it.
+
+ push message subscription set: This resource provides read and
+ delete access for a collection of push message subscriptions. A
+ user agent receives push messages (Section 6.1) for all the push
+ message subscriptions in the set. A link relation of type
+ "urn:ietf:params:push:set" identifies a push message subscription
+ set.
+
+ push: An application server requests the delivery (Section 5) of a
+ push message using a push resource. A link relation of type
+ "urn:ietf:params:push" identifies a push resource.
+
+ push message: The push service creates a push message resource to
+ identify push messages that have been accepted for delivery
+ (Section 5). The push message resource is also deleted by the
+ user agent to acknowledge receipt (Section 6.2) of a push message.
+
+ receipt subscription: An application server receives delivery
+ confirmations (Section 5.1) for push messages using a receipt
+ subscription. A link relation of type
+ "urn:ietf:params:push:receipt" identifies a receipt subscription.
+
+
+
+
+
+
+
+Thomson, et al. Standards Track [Page 7]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+3. Connecting to the Push Service
+
+ The push service MUST use HTTP over Transport Layer Security (TLS)
+ [RFC2818] following the recommendations in [RFC7525]. The push
+ service shares the same default port number (443/TCP) with HTTPS, but
+ MAY also advertise the IANA-allocated TCP System Port (1001) using
+ HTTP alternative services [RFC7838].
+
+ While the default port (443) offers broad reachability
+ characteristics, it is most often used for web-browsing scenarios
+ with a lower idle timeout than other ports configured in middleboxes.
+ For WebPush scenarios, this would contribute to unnecessary radio
+ communications to maintain the connection on battery-powered devices.
+
+ Advertising the alternate port (1001) allows middleboxes to optimize
+ idle timeouts for connections specific to push scenarios with the
+ expectation that data exchange will be infrequent.
+
+ Middleboxes SHOULD comply with REQ-5 in [RFC5382], which states that
+ "the value of the 'established connection idle-timeout' MUST NOT be
+ less than 2 hours 4 minutes".
+
+4. Subscribing for Push Messages
+
+ A user agent sends a POST request to its configured push service
+ resource to create a new subscription.
+
+ POST /subscribe HTTP/1.1
+ Host: push.example.net
+
+ A 201 (Created) response indicates that the push subscription was
+ created. A URI for the push message subscription resource that was
+ created in response to the request MUST be returned in the Location
+ header field.
+
+ The push service MUST provide a URI for the push resource
+ corresponding to the push message subscription in a link relation of
+ type "urn:ietf:params:push".
+
+ An application-specific method is used to distribute the push URI to
+ the application server. Confidentiality protection and application
+ server authentication MUST be used to ensure that this URI is not
+ disclosed to unauthorized recipients (Section 8.3).
+
+
+
+
+
+
+
+
+Thomson, et al. Standards Track [Page 8]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ HTTP/1.1 201 Created
+ Date: Thu, 11 Dec 2014 23:56:52 GMT
+ Link: </push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
+ rel="urn:ietf:params:push"
+ Link: </subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy>;
+ rel="urn:ietf:params:push:set"
+ Location: https://push.example.net/subscription/LBhhw0OohO-Wl4Oi971UG
+
+4.1. Collecting Subscriptions into Sets
+
+ Collecting multiple push message subscriptions into a subscription
+ set can represent a significant efficiency improvement for push
+ services and user agents. The push service MAY provide a URI for a
+ subscription set resource in a link relation of type
+ "urn:ietf:params:push:set".
+
+ When a subscription set is returned in a push message subscription
+ response, the user agent SHOULD include this subscription set in a
+ link relation of type "urn:ietf:params:push:set" in subsequent
+ requests to create new push message subscriptions.
+
+ A user agent MAY omit the subscription set if it is unable to receive
+ push messages in an aggregated way for the lifetime of the
+ subscription. This might be necessary if the user agent is
+ monitoring subscriptions on behalf of other push message receivers.
+
+ POST /subscribe HTTP/1.1
+ Host: push.example.net
+ Link: </subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy>;
+ rel="urn:ietf:params:push:set"
+
+ The push service SHOULD return the same subscription set in its
+ response, although it MAY return a new subscription set if it is
+ unable to reuse the one provided by the user agent.
+
+ HTTP/1.1 201 Created
+ Date: Thu, 11 Dec 2014 23:56:52 GMT
+ Link: </push/YBJNBIMwwA_Ag8EtD47J4A>;
+ rel="urn:ietf:params:push"
+ Link: </subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy>;
+ rel="urn:ietf:params:push:set"
+ Location: https://push.example.net/subscription/i-nQ3A9Zm4kgSWg8_ZijV
+
+ A push service MUST return a 400 (Bad Request) status code for
+ requests that contain an invalid subscription set. A push service
+ MAY return a 429 (Too Many Requests) status code [RFC6585] to reject
+ requests that omit a subscription set.
+
+
+
+
+Thomson, et al. Standards Track [Page 9]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ How a push service detects that requests originate from the same user
+ agent is implementation-specific but could take ambient information
+ into consideration, such as the TLS connection, source IP address,
+ and port. Implementers are reminded that some heuristics can produce
+ false positives and hence, cause requests to be rejected incorrectly.
+
+5. Requesting Push Message Delivery
+
+ An application server requests the delivery of a push message by
+ sending an HTTP POST request to a push resource distributed to the
+ application server by a user agent. The content of the push message
+ is included in the body of the request.
+
+ POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
+ Host: push.example.net
+ TTL: 15
+ Content-Type: text/plain;charset=utf8
+ Content-Length: 36
+
+ iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
+
+ A 201 (Created) response indicates that the push message was
+ accepted. A URI for the push message resource that was created in
+ response to the request MUST be returned in the Location header
+ field. This does not indicate that the message was delivered to the
+ user agent.
+
+ HTTP/1.1 201 Created
+ Date: Thu, 11 Dec 2014 23:56:55 GMT
+ Location: https://push.example.net/message/qDIYHNcfAIPP_5ITvURr-d6BGt
+
+5.1. Requesting Push Message Receipts
+
+ An application server can include the Prefer header field [RFC7240]
+ with the "respond-async" preference to request confirmation from the
+ push service when a push message is delivered and then acknowledged
+ by the user agent. The push service MUST support delivery
+ confirmations.
+
+ POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
+ Host: push.example.net
+ Prefer: respond-async
+ TTL: 15
+ Content-Type: text/plain;charset=utf8
+ Content-Length: 36
+
+ iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
+
+
+
+
+Thomson, et al. Standards Track [Page 10]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ When the push service accepts the message for delivery with
+ confirmation, it MUST return a 202 (Accepted) response. A URI for
+ the push message resource that was created in response to the request
+ MUST be returned in the Location header field. The push service MUST
+ also provide a URI for the receipt subscription resource in a link
+ relation of type "urn:ietf:params:push:receipt".
+
+ HTTP/1.1 202 Accepted
+ Date: Thu, 11 Dec 2014 23:56:55 GMT
+ Link: </receipt-subscription/3ZtI4YVNBnUUZhuoChl6omUvG4ZM>;
+ rel="urn:ietf:params:push:receipt"
+ Location: https://push.example.net/message/qDIYHNcfAIPP_5ITvURr-d6BGt
+
+ For subsequent receipt requests to the same origin [RFC6454], the
+ application server SHOULD include the returned receipt subscription
+ in a link relation of type "urn:ietf:params:push:receipt". This
+ gives the push service the option to aggregate the receipts. The
+ push service SHOULD return the same receipt subscription in its
+ response, although it MAY return a new receipt subscription if it is
+ unable to reuse the one provided by the application server.
+
+ An application server MAY omit the receipt subscription if it is
+ unable to receive receipts in an aggregated way for the lifetime of
+ the receipt subscription. This might be necessary if the application
+ server is monitoring receipt subscriptions on behalf of the other
+ push message senders.
+
+ A push service MUST return a 400 (Bad Request) status code for
+ requests that contain an invalid receipt subscription. If a push
+ service wishes to limit the number of receipt subscriptions that it
+ maintains, it MAY return a 429 (Too Many Requests) status code
+ [RFC6585] to reject receipt requests that omit a receipt
+ subscription.
+
+5.2. Push Message Time-To-Live
+
+ A push service can improve the reliability of push message delivery
+ considerably by storing push messages for a period. User agents are
+ often only intermittently connected, and so benefit from having
+ short-term message storage at the push service.
+
+ Delaying delivery might also be used to batch communication with the
+ user agent, thereby conserving radio resources.
+
+ Some push messages are not useful once a certain period of time
+ elapses. Delivery of messages after they have ceased to be relevant
+ is wasteful. For example, if the push message contains a call
+ notification, receiving a message after the caller has abandoned the
+
+
+
+Thomson, et al. Standards Track [Page 11]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ call is of no value; the application at the user agent is forced to
+ suppress the message so that it does not generate a useless alert.
+
+ An application server MUST include the TTL (Time-To-Live) header
+ field in its request for push message delivery. The TTL header field
+ contains a value in seconds that suggests how long a push message is
+ retained by the push service.
+
+ The TTL rule specifies a non-negative integer, representing time in
+ seconds. A recipient parsing and converting a TTL value to binary
+ form SHOULD use an arithmetic type of at least 31 bits of non-
+ negative integer range. If a recipient receives a TTL value greater
+ than the greatest integer it can represent, or if any of its
+ subsequent calculations overflows, it MUST consider the value to be
+ 2147483648 (2^31).
+
+ TTL = 1*DIGIT
+
+ A push service MUST return a 400 (Bad Request) status code in
+ response to requests that omit the TTL header field.
+
+ A push service MAY retain a push message for a shorter duration than
+ requested. It indicates this by returning a TTL header field in its
+ response with the actual TTL. This TTL value MUST be less than or
+ equal to the value provided by the application server.
+
+ Once the TTL period elapses, the push service MUST NOT attempt to
+ deliver the push message to the user agent. A push service might
+ adjust the TTL value to account for time accounting errors in
+ processing. For instance, distributing a push message within a
+ server cluster might accrue errors due to clock skew or propagation
+ delays.
+
+ A push service is not obligated to account for time spent by the
+ application server in sending a push message to the push service, or
+ delays incurred while sending a push message to the user agent. An
+ application server needs to account for transit delays in selecting a
+ TTL header field value.
+
+ A Push message with a zero TTL is immediately delivered if the user
+ agent is available to receive the message. After delivery, the push
+ service is permitted to immediately remove a push message with a zero
+ TTL. This might occur before the user agent acknowledges receipt of
+ the message by performing an HTTP DELETE on the push message
+ resource. Consequently, an application server cannot rely on
+ receiving acknowledgement receipts for zero TTL push messages.
+
+
+
+
+
+Thomson, et al. Standards Track [Page 12]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ If the user agent is unavailable, a push message with a zero TTL
+ expires and is never delivered.
+
+5.3. Push Message Urgency
+
+ For a device that is battery-powered, it is often critical that it
+ remains dormant for extended periods. Radio communication in
+ particular consumes significant power and limits the length of time
+ that the device can operate.
+
+ To avoid consuming resources to receive trivial messages, it is
+ helpful if an application server can communicate the urgency of a
+ message and if the user agent can request that the push server only
+ forwards messages of a specific urgency.
+
+ An application server MAY include an Urgency header field in its
+ request for push message delivery. This header field indicates the
+ message urgency. The push service MUST NOT forward the Urgency
+ header field to the user agent. A push message without the Urgency
+ header field defaults to a value of "normal".
+
+ A user agent MAY include the Urgency header field when monitoring for
+ push messages to indicate the lowest urgency of push messages that it
+ is willing to receive. A push service MUST NOT deliver push messages
+ with lower urgency than the value indicated by the user agent in its
+ monitoring request. Push messages of any urgency are delivered to a
+ user agent that does not include an Urgency header field when
+ monitoring for messages.
+
+ The grammar for the Urgency header field is as follows:
+
+ Urgency = urgency-option
+ urgency-option = ("very-low" / "low" / "normal" / "high")
+
+ In order of increasing urgency:
+
+ +----------+-----------------------------+--------------------------+
+ | Urgency | Device State | Example Application |
+ | | | Scenario |
+ +----------+-----------------------------+--------------------------+
+ | very-low | On power and Wi-Fi | Advertisements |
+ | low | On either power or Wi-Fi | Topic updates |
+ | normal | On neither power nor Wi-Fi | Chat or Calendar Message |
+ | high | Low battery | Incoming phone call or |
+ | | | time-sensitive alert |
+ +----------+-----------------------------+--------------------------+
+
+ Table 1: Illustrative Urgency Values
+
+
+
+Thomson, et al. Standards Track [Page 13]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ Multiple values for the Urgency header field MUST NOT be included in
+ requests; otherwise, the push service MUST return a 400 (Bad Request)
+ status code.
+
+5.4. Replacing Push Messages
+
+ A push message that has been stored by the push service can be
+ replaced with new content. If the user agent is offline during the
+ time that the push messages are sent, updating a push message avoids
+ the situation where outdated or redundant messages are sent to the
+ user agent.
+
+ Only push messages that have been assigned a topic can be replaced.
+ A push message with a topic replaces any outstanding push message
+ with an identical topic.
+
+ A push message topic is a string carried in a Topic header field. A
+ topic is used to correlate push messages sent to the same
+ subscription and does not convey any other semantics.
+
+ The grammar for the Topic header field uses the "token" rule defined
+ in [RFC7230].
+
+ Topic = token
+
+ For use with this protocol, the Topic header field MUST be restricted
+ to no more than 32 characters from the URL and a filename-safe Base
+ 64 alphabet [RFC4648]. A push service that receives a request with a
+ Topic header field that does not meet these constraints MUST return a
+ 400 (Bad Request) status code to the application server.
+
+ A push message replacement request creates a new push message
+ resource and simultaneously deletes any existing message resource
+ that has a matching topic. If an attempt was made to deliver the
+ deleted push message, an acknowledgment could arrive at the push
+ service after the push message has been replaced. Delivery receipts
+ for such deleted messages SHOULD be suppressed.
+
+ The replacement request also replaces the stored TTL, Urgency, and
+ any receipt subscription associated with the previous message in the
+ matching topic.
+
+ A push message with a topic that is not shared by an outstanding
+ message to the same subscription is stored or delivered as normal.
+
+
+
+
+
+
+
+Thomson, et al. Standards Track [Page 14]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ For example, the following message could cause an existing message to
+ be replaced:
+
+ POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
+ Host: push.example.net
+ TTL: 600
+ Topic: upd
+ Content-Type: text/plain;charset=utf8
+ Content-Length: 36
+
+ ZuHSZPKa2b1jtOKLGpWrcrn8cNqt0iVQyroF
+
+ If the push service identifies an outstanding push message with a
+ topic of "upd", then that message resource is deleted. A 201
+ (Created) response indicates that the push message replacement was
+ accepted. A URI for the new push message resource that was created
+ in response to the request is included in the Location header field.
+
+ HTTP/1.1 201 Created
+ Date: Thu, 11 Dec 2014 23:57:02 GMT
+ Location: https://push.example.net/message/qDIYHNcfAIPP_5ITvURr-d6BGt
+
+ The value of the Topic header field MUST NOT be forwarded to user
+ agents. Its value is neither encrypted nor authenticated.
+
+6. Receiving Push Messages for a Subscription
+
+ A user agent requests the delivery of new push messages by making a
+ GET request to a push message subscription resource. The push
+ service does not respond to this request; instead, it uses HTTP/2
+ server push [RFC7540] to send the contents of push messages as they
+ are sent by application servers.
+
+ A user agent MAY include an Urgency header field in its request. The
+ push service MUST NOT deliver messages with lower urgency than the
+ value of the header field as defined in Table 1 (Illustrative Urgency
+ Values).
+
+ Each push message is pushed as the response to a synthesized GET
+ request sent in a PUSH_PROMISE. This GET request is made to the push
+ message resource that was created by the push service when the
+ application server requested message delivery. The response headers
+ SHOULD provide a URI for the push resource corresponding to the push
+ message subscription in a link relation of type
+ "urn:ietf:params:push". The response body is the entity body from
+ the most recent request sent to the push resource by the application
+ server.
+
+
+
+
+Thomson, et al. Standards Track [Page 15]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ The following example request is made over HTTP/2:
+
+ HEADERS [stream 7] +END_STREAM +END_HEADERS
+ :method = GET
+ :path = /subscription/LBhhw0OohO-Wl4Oi971UG
+ :authority = push.example.net
+
+ The push service permits the request to remain outstanding. When a
+ push message is sent by an application server, a server push is
+ generated in association with the initial request. The response for
+ the server push includes the push message.
+
+ PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS
+ :method = GET
+ :path = /message/qDIYHNcfAIPP_5ITvURr-d6BGt
+ :authority = push.example.net
+
+ HEADERS [stream 4] +END_HEADERS
+ :status = 200
+ date = Thu, 11 Dec 2014 23:56:56 GMT
+ last-modified = Thu, 11 Dec 2014 23:56:55 GMT
+ cache-control = private
+ link = </push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
+ rel="urn:ietf:params:push"
+ content-type = text/plain;charset=utf8
+ content-length = 36
+
+ DATA [stream 4] +END_STREAM
+ iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
+
+ HEADERS [stream 7] +END_STREAM +END_HEADERS
+ :status = 200
+
+ A user agent can also request the contents of the push message
+ subscription resource immediately by including a Prefer header field
+ [RFC7240] with a "wait" preference set to "0". In response to this
+ request, the push service MUST generate a server push for all push
+ messages that have not yet been delivered.
+
+ A 204 (No Content) status code with no associated server pushes
+ indicates that no messages are presently available. This could be
+ because push messages have expired.
+
+
+
+
+
+
+
+
+
+Thomson, et al. Standards Track [Page 16]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+6.1. Receiving Push Messages for a Subscription Set
+
+ There are minor differences between receiving push messages for a
+ subscription and a subscription set. If a subscription set is
+ available, the user agent SHOULD use the subscription set to monitor
+ for push messages rather than individual push message subscriptions.
+
+ A user agent requests the delivery of new push messages for a
+ collection of push message subscriptions by making a GET request to a
+ push message subscription set resource. The push service does not
+ respond to this request; instead, it uses HTTP/2 server push
+ [RFC7540] to send the contents of push messages as they are sent by
+ application servers.
+
+ A user agent MAY include an Urgency header field in its request. The
+ push service MUST NOT deliver messages with lower urgency than the
+ value of the header field as defined in Table 1 (Illustrative Urgency
+ Values).
+
+ Each push message is pushed as the response to a synthesized GET
+ request sent in a PUSH_PROMISE. This GET request is made to the push
+ message resource that was created by the push service when the
+ application server requested message delivery. The synthetic request
+ MUST provide a URI for the push resource corresponding to the push
+ message subscription in a link relation of type
+ "urn:ietf:params:push". This enables the user agent to differentiate
+ the source of the message. The response body is the entity body from
+ the most recent request sent to the push resource by an application
+ server.
+
+ The following example request is made over HTTP/2.
+
+ HEADERS [stream 7] +END_STREAM +END_HEADERS
+ :method = GET
+ :path = /subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy
+ :authority = push.example.net
+
+ The push service permits the request to remain outstanding. When a
+ push message is sent by an application server, a server push is
+ generated in association with the initial request. The server push's
+ response includes the push message.
+
+ PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS
+ :method = GET
+ :path = /message/qDIYHNcfAIPP_5ITvURr-d6BGt
+ :authority = push.example.net
+
+
+
+
+
+Thomson, et al. Standards Track [Page 17]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ HEADERS [stream 4] +END_HEADERS
+ :status = 200
+ date = Thu, 11 Dec 2014 23:56:56 GMT
+ last-modified = Thu, 11 Dec 2014 23:56:55 GMT
+ link = </push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
+ rel="urn:ietf:params:push"
+ cache-control = private
+ content-type = text/plain;charset=utf8
+ content-length = 36
+
+ DATA [stream 4] +END_STREAM
+ iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
+
+ HEADERS [stream 7] +END_STREAM +END_HEADERS
+ :status = 200
+
+ A user agent can request the contents of the push message
+ subscription set resource immediately by including a Prefer header
+ field [RFC7240] with a "wait" preference set to "0". In response to
+ this request, the push service MUST generate a server push for all
+ push messages that have not yet been delivered.
+
+ A 204 (No Content) status code with no associated server pushes
+ indicates that no messages are presently available. This could be
+ because push messages have expired.
+
+6.2. Acknowledging Push Messages
+
+ To ensure that a push message is properly delivered to the user agent
+ at least once, the user agent MUST acknowledge receipt of the message
+ by performing an HTTP DELETE on the push message resource.
+
+ DELETE /message/qDIYHNcfAIPP_5ITvURr-d6BGt HTTP/1.1
+ Host: push.example.net
+
+ If the push service receives the acknowledgement and the application
+ has requested a delivery receipt, the push service MUST return a 204
+ (No Content) response to the application server monitoring the
+ receipt subscription.
+
+ If the push service does not receive the acknowledgement within a
+ reasonable amount of time, then the message is considered to be not
+ yet delivered. The push service SHOULD continue to retry delivery of
+ the message until its advertised expiration.
+
+ The push service MAY cease to retry delivery of the message prior to
+ its advertised expiration due to scenarios such as an unresponsive
+ user agent or operational constraints. If the application has
+
+
+
+Thomson, et al. Standards Track [Page 18]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ requested a delivery receipt, then the push service MUST return a 410
+ (Gone) response to the application server monitoring the receipt
+ subscription.
+
+6.3. Receiving Push Message Receipts
+
+ The application server requests the delivery of receipts from the
+ push service by making an HTTP GET request to the receipt
+ subscription resource. The push service does not respond to this
+ request; instead, it uses HTTP/2 server push [RFC7540] to send push
+ receipts when messages are acknowledged (Section 6.2) by the user
+ agent.
+
+ Each receipt is pushed as the response to a synthesized GET request
+ sent in a PUSH_PROMISE. This GET request is made to the same push
+ message resource that was created by the push service when the
+ application server requested message delivery. The response includes
+ a status code indicating the result of the message delivery and
+ carries no data.
+
+ The following example request is made over HTTP/2.
+
+ HEADERS [stream 13] +END_STREAM +END_HEADERS
+ :method = GET
+ :path = /receipt-subscription/3ZtI4YVNBnUUZhuoChl6omUvG4ZM
+ :authority = push.example.net
+
+ The push service permits the request to remain outstanding. When the
+ user agent acknowledges the message, the push service pushes a
+ delivery receipt to the application server. A 204 (No Content)
+ status code confirms that the message was delivered and acknowledged.
+
+ PUSH_PROMISE [stream 13; promised stream 82] +END_HEADERS
+ :method = GET
+ :path = /message/qDIYHNcfAIPP_5ITvURr-d6BGt
+ :authority = push.example.net
+
+ HEADERS [stream 82] +END_STREAM
+ +END_HEADERS
+ :status = 204
+ date = Thu, 11 Dec 2014 23:56:56 GMT
+
+ If the user agent fails to acknowledge the receipt of the push
+ message and the push service ceases to retry delivery of the message
+ prior to its advertised expiration, then the push service MUST push a
+ failure response with a status code of 410 (Gone).
+
+
+
+
+
+Thomson, et al. Standards Track [Page 19]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+7. Operational Considerations
+
+7.1. Load Management
+
+ A push service is likely to have to maintain a very large number of
+ open TCP connections. Effective management of those connections can
+ depend on being able to move connections between server instances.
+
+ A user agent MUST support the 307 (Temporary Redirect) status code
+ [RFC7231], which can be used by a push service to redistribute load
+ at the time that a new subscription is requested.
+
+ A server that wishes to redistribute load can do so using HTTP
+ alternative services [RFC7838]. HTTP alternative services allows for
+ redistribution of load while maintaining the same URIs for various
+ resources. A user agent can ensure a graceful transition by using
+ the GOAWAY frame once it has established a replacement connection.
+
+7.2. Push Message Expiration
+
+ Storage of push messages based on the TTL header field comprises a
+ potentially significant amount of storage for a push service. A push
+ service is not obligated to store messages indefinitely. A push
+ service is able to indicate how long it intends to retain a message
+ to an application server using the TTL header field (Section 5.2).
+
+ A user agent that does not actively monitor for push messages will
+ not receive messages that expire during that interval.
+
+ Push messages that are stored and have not been delivered to a user
+ agent are delivered when the user agent recommences monitoring.
+ Stored push messages SHOULD include a Last-Modified header field
+ (Section 2.2 of [RFC7232]) indicating when delivery was requested by
+ an application server.
+
+ A GET request to a push message subscription resource with only
+ expired messages results in a response as though no push message was
+ ever sent.
+
+ Push services might need to limit the size and number of stored push
+ messages to avoid overloading. To limit the size of messages, the
+ push service MAY return a 413 (Payload Too Large) status code
+ [RFC7231] in response to requests that include an entity body that is
+ too large. Push services MUST NOT return a 413 status code in
+ responses to an entity body that is 4096 bytes or less in size.
+
+
+
+
+
+
+Thomson, et al. Standards Track [Page 20]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ To limit the number of stored push messages, the push service MAY
+ respond with a shorter Time-To-Live than proposed by the application
+ server in its request for push message delivery (Section 5.2). Once
+ a message has been accepted, the push service MAY later expire the
+ message prior to its advertised Time-To-Live. If the application
+ server requested a delivery receipt, the push service MUST return a
+ failure response (Section 6.2).
+
+7.3. Subscription Expiration
+
+ In some cases, it may be necessary to terminate subscriptions so that
+ they can be refreshed. This applies to both push message
+ subscriptions and receipt subscriptions.
+
+ A push service MAY expire a subscription at any time. If there are
+ outstanding requests to an expired push message subscription resource
+ (Section 6) from a user agent or to an expired receipt subscription
+ resource (Section 6.3) from an application server, this MUST be
+ signaled by returning a 404 (Not Found) status code.
+
+ A push service MUST return a 404 (Not Found) status code if an
+ application server attempts to send a push message to an expired push
+ message subscription.
+
+ A user agent can remove its push message subscription by sending a
+ DELETE request to the corresponding URI. An application server can
+ remove its receipt subscription by sending a DELETE request to the
+ corresponding URI.
+
+7.3.1. Subscription Set Expiration
+
+ A push service MAY expire a subscription set at any time and MUST
+ also expire all push message subscriptions in the set. If a user
+ agent has an outstanding request to a push subscription set
+ (Section 6.1), this MUST be signaled by returning a 404 (Not Found)
+ status code.
+
+ A user agent can request that a subscription set be removed by
+ sending a DELETE request to the subscription set URI. This MUST also
+ remove all push message subscriptions in the set.
+
+ If a specific push message subscription that is a member of a
+ subscription set is expired or removed, then it MUST also be removed
+ from its subscription set.
+
+
+
+
+
+
+
+Thomson, et al. Standards Track [Page 21]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+7.4. Implications for Application Reliability
+
+ A push service that does not support reliable delivery over
+ intermittent network connections or failing applications on devices,
+ forces the device to acknowledge receipt directly to the application
+ server, incurring additional power drain in order to establish and
+ maintain (usually secure) connections to the individual application
+ servers.
+
+ Push message reliability can be important if messages contain
+ information critical to the state of an application. Repairing the
+ state can be expensive, particularly for devices with limited
+ communications capacity. Knowing that a push message has been
+ correctly received avoids retransmissions, polling, and state
+ resynchronization.
+
+ The availability of push message delivery receipts ensures that the
+ application developer is not tempted to create alternative mechanisms
+ for message delivery in case the push service fails to deliver a
+ critical message. Setting up a polling mechanism or a backup
+ messaging channel in order to compensate for these shortcomings
+ negates almost all of the advantages a push service provides.
+
+ However, reliability might not be necessary for messages that are
+ transient (e.g., an incoming call) or messages that are quickly
+ superseded (e.g., the current number of unread emails).
+
+7.5. Subscription Sets and Concurrent HTTP/2 Streams
+
+ If the push service requires that the user agent use push message
+ subscription sets, then it MAY limit the number of concurrently
+ active streams with the SETTINGS_MAX_CONCURRENT_STREAMS parameter
+ within an HTTP/2 SETTINGS frame [RFC7540]. The user agent MAY be
+ limited to one concurrent stream to manage push message subscriptions
+ and one concurrent stream for each subscription set returned by the
+ push service. This could force the user agent to serialize
+ subscription requests to the push service.
+
+8. Security Considerations
+
+ This protocol MUST use HTTP over TLS [RFC2818] following the
+ recommendations in [RFC7525]. This includes any communications
+ between the user agent and the push service, plus communications
+ between the application server and the push service. All URIs
+ therefore use the "https" scheme. This provides confidentiality and
+ integrity protection for subscriptions and push messages from
+ external parties.
+
+
+
+
+Thomson, et al. Standards Track [Page 22]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+8.1. Confidentiality from Push Service Access
+
+ The protection afforded by TLS does not protect content from the push
+ service. Without additional safeguards, a push service can inspect
+ and modify the message content.
+
+ Applications using this protocol MUST use mechanisms that provide
+ end-to-end confidentiality, integrity, and data origin
+ authentication. The application server sending the push message and
+ the application on the user agent that receives it are frequently
+ just different instances of the same application, so no standardized
+ protocol is needed to establish a proper security context. The
+ distribution of subscription information from the user agent to its
+ application server also offers a convenient medium for key agreement.
+
+ For this requirement, the W3C Push API [API] has adopted Message
+ Encryption for WebPush [ENCRYPT] to secure the content of messages
+ from the push service. Other scenarios can be addressed by similar
+ policies.
+
+ The Topic header field exposes information that allows more granular
+ correlation of push messages on the same subject. This might be used
+ to aid traffic analysis of push messages by the push service.
+
+8.2. Privacy Considerations
+
+ Push message confidentiality does not ensure that the identity of who
+ is communicating and when they are communicating is protected.
+ However, the amount of information that is exposed can be limited.
+
+ The URIs provided for push resources MUST NOT provide any basis to
+ correlate communications for a given user agent. It MUST NOT be
+ possible to correlate any two push resource URIs based solely on
+ their contents. This allows a user agent to control correlation
+ across different applications or over time. Of course, this does not
+ prevent correlation using other information that a user agent might
+ expose.
+
+ Similarly, the URIs provided by the push service to identify a push
+ message MUST NOT provide any information that allows for correlation
+ across subscriptions. Push message URIs for the same subscription
+ MAY contain information that would allow correlation with the
+ associated subscription or other push messages for that subscription.
+
+ User and device information MUST NOT be exposed through a push or
+ push message URI.
+
+
+
+
+
+Thomson, et al. Standards Track [Page 23]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ In addition, push URIs established by the same user agent or push
+ message URIs for the same subscription MUST NOT include any
+ information that allows them to be correlated with the user agent.
+
+ Note: This need not be perfect as long as the resulting anonymity
+ set ([RFC6973], Section 6.1.1) is sufficiently large. A push URI
+ necessarily identifies a push service or a single server instance.
+ It is also possible that traffic analysis could be used to
+ correlate subscriptions.
+
+ A user agent MUST be able to create new subscriptions with new
+ identifiers at any time.
+
+8.3. Authorization
+
+ This protocol does not define how a push service establishes whether
+ a user agent is permitted to create a subscription, or whether push
+ messages can be delivered to the user agent. A push service MAY
+ choose to authorize requests based on any HTTP-compatible
+ authorization method available, of which there are multiple options
+ (including experimental options) with varying levels of security.
+ The authorization process and any associated credentials are expected
+ to be configured in the user agent along with the URI for the push
+ service.
+
+ Authorization is managed using capability URLs for the push message
+ subscription, push, and receipt subscription resources ([CAP-URI]).
+ A capability URL grants access to a resource based solely on
+ knowledge of the URL.
+
+ Capability URLs are used for their "easy onward sharing" and "easy
+ client API" properties. These properties make it possible to avoid
+ relying on prearranged relationships or additional protocols between
+ push services and application servers.
+
+ Capability URLs act as bearer tokens. Knowledge of a push message
+ subscription URI implies authorization to either receive push
+ messages or delete the subscription. Knowledge of a push URI implies
+ authorization to send push messages. Knowledge of a push message URI
+ allows for reading and acknowledging that specific message.
+ Knowledge of a receipt subscription URI implies authorization to
+ receive push receipts.
+
+ Encoding a large amount of random entropy (at least 120 bits) in the
+ path component ensures that it is difficult to successfully guess a
+ valid capability URL.
+
+
+
+
+
+Thomson, et al. Standards Track [Page 24]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+8.4. Denial-of-Service Considerations
+
+ A user agent can control where valid push messages originate by
+ limiting the distribution of push URIs to authorized application
+ servers. Ensuring that push URIs are hard to guess ensures that only
+ application servers that have received a push URI can use it.
+
+ Push messages that are not successfully authenticated by the user
+ agent will not be delivered, but this can present a denial-of-service
+ risk. Even a relatively small volume of push messages can cause
+ battery-powered devices to exhaust power reserves.
+
+ To address this case, the W3C Push API [API] has adopted Voluntary
+ Application Server Identification [VAPID], which allows a user agent
+ to restrict a subscription to a specific application server. The
+ push service can then identify and reject unwanted messages without
+ contacting the user agent.
+
+ A malicious application with a valid push URI could use the greater
+ resources of a push service to mount a denial-of-service attack on a
+ user agent. Push services SHOULD limit the rate at which push
+ messages are sent to individual user agents.
+
+ A push service MAY return a 429 (Too Many Requests) status code
+ [RFC6585] when an application server has exceeded its rate limit for
+ push message delivery to a push resource. The push service SHOULD
+ also include a Retry-After header [RFC7231] to indicate how long the
+ application server is requested to wait before it makes another
+ request to the push resource.
+
+ A push service or user agent MAY also terminate subscriptions
+ (Section 7.3) that receive too many push messages.
+
+ A push service is also able to deny service to user agents.
+ Intentional failure to deliver messages is difficult to distinguish
+ from faults, which might occur due to transient network errors,
+ interruptions in user agent availability, or genuine service outages.
+
+8.5. Logging Risks
+
+ Server request logs can reveal subscription-related URIs or
+ relationships between subscription-related URIs for the same user
+ agent. Limitations on log retention and strong access control
+ mechanisms can ensure that URIs are not revealed to unauthorized
+ entities.
+
+
+
+
+
+
+Thomson, et al. Standards Track [Page 25]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+9. IANA Considerations
+
+ This protocol defines new HTTP header fields in Section 9.1. New
+ link relation types are identified using the URNs defined in
+ Section 9.2. Port registration is defined in Section 9.3
+
+9.1. Header Field Registrations
+
+ HTTP header fields are registered within the "Message Headers"
+ registry maintained at <https://www.iana.org/assignments/message-
+ headers/>.
+
+ This document defines the following HTTP header fields, and the
+ following entries have been added to the "Permanent Message Header
+ Field Names" registry ([RFC3864]):
+
+ +-------------------+----------+----------+--------------+
+ | Header Field Name | Protocol | Status | Reference |
+ +-------------------+----------+----------+--------------+
+ | TTL | http | standard | Section 5.2 |
+ | Urgency | http | standard | Section 5.3 |
+ | Topic | http | standard | Section 5.4 |
+ +-------------------+----------+----------+--------------+
+
+ The change controller is: "IETF (iesg@ietf.org) - Internet
+ Engineering Task Force".
+
+9.2. Link Relation URNs
+
+ This document registers URNs for use in identifying link relation
+ types. These have been added to a new "Web Push Identifiers"
+ registry according to the procedures in Section 4 of [RFC3553]; the
+ corresponding "push" sub-namespace has been entered in the "IETF URN
+ Sub-namespace for Registered Protocol Parameter Identifiers"
+ registry.
+
+ The "Web Push Identifiers" registry operates under the IETF Review
+ policy [RFC5226].
+
+ Registry name: Web Push Identifiers
+
+ URN Prefix: urn:ietf:params:push
+
+ Specification: RFC 8030 (this document)
+
+ Repository: http://www.iana.org/assignments/webpush-parameters/
+
+
+
+
+
+Thomson, et al. Standards Track [Page 26]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ Index Value: Values in this registry are URNs or URN prefixes that
+ start with the prefix "urn:ietf:params:push". Each is registered
+ independently.
+
+ Registrations in the "Web Push Identifiers" registry include the
+ following information:
+
+ URN: A complete URN or URN prefix.
+
+ Description: A summary description.
+
+ Contact: Email for the person or group making the registration.
+
+ Index Value: As described in [RFC3553]
+
+ Reference: A reference to a specification describing the semantics
+ of the URN or URN prefix.
+
+ URN prefixes that are registered include a description of how the
+ URN is constructed. This is not applicable for specific URNs.
+
+ These values are entered as the initial content of the "Web Push
+ Identifiers" registry.
+
+ URN: urn:ietf:params:push
+
+ Description: This link relation type is used to identify a resource
+ for sending push messages.
+
+ Contact: The WEBPUSH WG of the IETF (webpush@ietf.org)
+
+ Reference: RFC 8030 (this document)
+
+ URN: urn:ietf:params:push:set
+
+ Description: This link relation type is used to identify a
+ collection of push message subscriptions.
+
+ Contact: The WEBPUSH WG of the IETF (webpush@ietf.org)
+
+ Reference: RFC 8030 (this document)
+
+ URN: urn:ietf:params:push:receipt
+
+ Description: This link relation type is used to identify a resource
+ for receiving delivery confirmations for push messages.
+
+ Contact: The WEBPUSH WG of the IETF (webpush@ietf.org)
+
+
+
+Thomson, et al. Standards Track [Page 27]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ Reference: RFC 8030 (this document)
+
+9.3. Service Name and Port Number Registration
+
+ Service names and port numbers are registered within the "Service
+ Name and Transport Protocol Port Number Registry" maintained at
+ <https://www.iana.org/assignments/service-names-port-numbers/>.
+
+ In accordance with [RFC6335], IANA has assigned the System Port
+ number 1001 and the service name "webpush".
+
+ Service Name:
+ webpush
+
+ Port Number:
+ 1001
+
+ Transport Protocol:
+ tcp
+
+ Description:
+ HTTP Web Push
+
+ Assignee:
+ The IESG (iesg@ietf.org)
+
+ Contact:
+ The IETF Chair (chair@ietf.org)
+
+ Reference:
+ RFC 8030 (this document)
+
+10. References
+
+10.1. Normative References
+
+ [CAP-URI] Tennison, J., "Good Practices for Capability URLs", W3C
+ First Public Working Draft capability-urls, February 2014,
+ <http://www.w3.org/TR/capability-urls/>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
+ DOI 10.17487/RFC2818, May 2000,
+ <http://www.rfc-editor.org/info/rfc2818>.
+
+
+
+Thomson, et al. Standards Track [Page 28]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
+ IETF URN Sub-namespace for Registered Protocol
+ Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
+ 2003, <http://www.rfc-editor.org/info/rfc3553>.
+
+ [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
+ Procedures for Message Header Fields", BCP 90, RFC 3864,
+ DOI 10.17487/RFC3864, September 2004,
+ <http://www.rfc-editor.org/info/rfc3864>.
+
+ [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
+ Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
+ <http://www.rfc-editor.org/info/rfc4648>.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ DOI 10.17487/RFC5226, May 2008,
+ <http://www.rfc-editor.org/info/rfc5226>.
+
+ [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
+ Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
+ RFC 5382, DOI 10.17487/RFC5382, October 2008,
+ <http://www.rfc-editor.org/info/rfc5382>.
+
+ [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
+ DOI 10.17487/RFC5988, October 2010,
+ <http://www.rfc-editor.org/info/rfc5988>.
+
+ [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
+ Cheshire, "Internet Assigned Numbers Authority (IANA)
+ Procedures for the Management of the Service Name and
+ Transport Protocol Port Number Registry", BCP 165,
+ RFC 6335, DOI 10.17487/RFC6335, August 2011,
+ <http://www.rfc-editor.org/info/rfc6335>.
+
+ [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
+ DOI 10.17487/RFC6454, December 2011,
+ <http://www.rfc-editor.org/info/rfc6454>.
+
+ [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
+ Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
+ <http://www.rfc-editor.org/info/rfc6585>.
+
+ [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+ Protocol (HTTP/1.1): Message Syntax and Routing",
+ RFC 7230, DOI 10.17487/RFC7230, June 2014,
+ <http://www.rfc-editor.org/info/rfc7230>.
+
+
+
+
+Thomson, et al. Standards Track [Page 29]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+ [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+ Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
+ DOI 10.17487/RFC7231, June 2014,
+ <http://www.rfc-editor.org/info/rfc7231>.
+
+ [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+ Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
+ DOI 10.17487/RFC7232, June 2014,
+ <http://www.rfc-editor.org/info/rfc7232>.
+
+ [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240,
+ DOI 10.17487/RFC7240, June 2014,
+ <http://www.rfc-editor.org/info/rfc7240>.
+
+ [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
+ "Recommendations for Secure Use of Transport Layer
+ Security (TLS) and Datagram Transport Layer Security
+ (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
+ 2015, <http://www.rfc-editor.org/info/rfc7525>.
+
+ [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
+ Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
+ DOI 10.17487/RFC7540, May 2015,
+ <http://www.rfc-editor.org/info/rfc7540>.
+
+ [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
+ Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
+ April 2016, <http://www.rfc-editor.org/info/rfc7838>.
+
+10.2. Informative References
+
+ [API] Beverloo, P., Thomson, M., van Ouwerkerk, M., Sullivan,
+ B., and E. Fullea, "Push API", W3C Editor's Draft push-
+ api, November 2016, <https://w3c.github.io/push-api/>.
+
+ [ENCRYPT] Thomson, M., "Message Encryption for Web Push", Work in
+ Progress, draft-ietf-webpush-encryption-06, October 2016.
+
+ [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
+ Morris, J., Hansen, M., and R. Smith, "Privacy
+ Considerations for Internet Protocols", RFC 6973,
+ DOI 10.17487/RFC6973, July 2013,
+ <http://www.rfc-editor.org/info/rfc6973>.
+
+ [VAPID] Thomson, M. and P. Beverloo, "Voluntary Application Server
+ Identification for Web Push", Work in Progress,
+ draft-ietf-webpush-vapid-01, June 2016.
+
+
+
+
+Thomson, et al. Standards Track [Page 30]
+
+RFC 8030 HTTP Web Push December 2016
+
+
+Acknowledgements
+
+ Significant technical input to this document has been provided by Ben
+ Bangert, Peter Beverloo, Kit Cambridge, JR Conlin, Lucas Jenss,
+ Matthew Kaufman, Costin Manolache, Mark Nottingham, Idel Pivnitskiy,
+ Robert Sparks, Darshak Thakore, and many others.
+
+Authors' Addresses
+
+ Martin Thomson
+ Mozilla
+ 331 E Evelyn Street
+ Mountain View, CA 94041
+ United States of America
+
+ Email: martin.thomson@gmail.com
+
+
+ Elio Damaggio
+ Microsoft
+ One Microsoft Way
+ Redmond, WA 98052
+ United States of America
+
+ Email: elioda@microsoft.com
+
+
+ Brian Raymor (editor)
+ Microsoft
+ One Microsoft Way
+ Redmond, WA 98052
+ United States of America
+
+ Email: brian.raymor@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomson, et al. Standards Track [Page 31]
+