idnits 2.17.1 draft-ietf-webpush-protocol-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. An push message without the Urgency header field defaults to a value of "normal". -- The document date (May 8, 2016) is 2910 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCthis' is mentioned on line 1191, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'CAP-URI' ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-09) exists of draft-ietf-webpush-encryption-02 == Outdated reference: A later version (-04) exists of draft-ietf-webpush-vapid-00 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBPUSH M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track E. Damaggio 5 Expires: November 9, 2016 B. Raymor, Ed. 6 Microsoft 7 May 8, 2016 9 Generic Event Delivery Using HTTP Push 10 draft-ietf-webpush-protocol-05 12 Abstract 14 A simple protocol for the delivery of realtime events to user agents 15 is described. This scheme uses HTTP/2 server push. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on November 9, 2016. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. HTTP Resources . . . . . . . . . . . . . . . . . . . . . 6 55 3. Connecting to the Push Service . . . . . . . . . . . . . . . 6 56 4. Subscribing for Push Messages . . . . . . . . . . . . . . . . 7 57 4.1. Collecting Subscriptions into Sets . . . . . . . . . . . 7 58 5. Requesting Push Message Delivery . . . . . . . . . . . . . . 8 59 5.1. Requesting Push Message Receipts . . . . . . . . . . . . 9 60 5.2. Push Message Time-To-Live . . . . . . . . . . . . . . . . 10 61 5.3. Push Message Urgency . . . . . . . . . . . . . . . . . . 11 62 5.4. Updating Push Messages . . . . . . . . . . . . . . . . . 12 63 6. Receiving Push Messages for a Subscription . . . . . . . . . 14 64 6.1. Receiving Push Messages for a Subscription Set . . . . . 15 65 6.2. Acknowledging Push Messages . . . . . . . . . . . . . . . 17 66 6.3. Receiving Push Message Receipts . . . . . . . . . . . . . 18 67 7. Operational Considerations . . . . . . . . . . . . . . . . . 19 68 7.1. Load Management . . . . . . . . . . . . . . . . . . . . . 19 69 7.2. Push Message Expiration . . . . . . . . . . . . . . . . . 19 70 7.3. Subscription Expiration . . . . . . . . . . . . . . . . . 20 71 7.3.1. Subscription Set Expiration . . . . . . . . . . . . . 21 72 7.4. Implications for Application Reliability . . . . . . . . 21 73 7.5. Subscription Sets and Concurrent HTTP/2 streams . . . . . 21 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 75 8.1. Confidentiality from Push Service Access . . . . . . . . 22 76 8.2. Privacy Considerations . . . . . . . . . . . . . . . . . 22 77 8.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 23 78 8.4. Denial of Service Considerations . . . . . . . . . . . . 24 79 8.5. Logging Risks . . . . . . . . . . . . . . . . . . . . . . 25 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 81 9.1. Header Field Registrations . . . . . . . . . . . . . . . 25 82 9.2. Link Relation URNs . . . . . . . . . . . . . . . . . . . 25 83 9.3. Service Name and Port Number Registration . . . . . . . . 27 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 28 87 11.2. Informative References . . . . . . . . . . . . . . . . . 29 88 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29 89 A.1. Since draft-ietf-webpush-protocol-00 . . . . . . . . . . 30 90 A.2. Since draft-ietf-webpush-protocol-01 . . . . . . . . . . 30 91 A.3. Since draft-ietf-webpush-protocol-02 . . . . . . . . . . 30 92 A.4. Since draft-ietf-webpush-protocol-03 . . . . . . . . . . 30 93 A.5. Since draft-ietf-webpush-protocol-04 . . . . . . . . . . 30 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 96 1. Introduction 98 Many applications on mobile and embedded devices require continuous 99 access to network communications so that real-time events - such as 100 incoming calls or messages - can be delivered (or "pushed") in a 101 timely fashion. These devices typically have limited power reserves, 102 so finding more efficient ways to serve application requirements 103 greatly benefits the application ecosystem. 105 One significant contributor to power usage is the radio. Radio 106 communications consume a significant portion of the energy budget on 107 a wireless device. 109 Uncoordinated use of persistent connections or sessions from multiple 110 applications can contribute to unnecessary use of the device radio, 111 since each independent session independently incurs overheads. In 112 particular, keep alive traffic used to ensure that middleboxes do not 113 prematurely time out sessions, can result in significant waste. 114 Maintenance traffic tends to dominate over the long term, since 115 events are relatively rare. 117 Consolidating all real-time events into a single session ensures more 118 efficient use of network and radio resources. A single service 119 consolidates all events, distributing those events to applications as 120 they arrive. This requires just one session, avoiding duplicated 121 overhead costs. 123 The W3C Push API [API] describes an API that enables the use of a 124 consolidated push service from web applications. This expands on 125 that work by describing a protocol that can be used to: 127 o request the delivery of a push message to a user agent, 129 o create new push message delivery subscriptions, and 131 o monitor for new push messages. 133 Requesting the delivery of events is particularly important for the 134 W3C Push API. The subscription, management and monitoring functions 135 are currently fulfilled by proprietary protocols; these are adequate, 136 but do not offer any of the advantages that standardization affords. 138 This document intentionally does not describe how a push service is 139 discovered. Discovery of push services is left for future efforts, 140 if it turns out to be necessary at all. User agents are expected to 141 be configured with a URL for a push service. 143 1.1. Conventions and Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 This document defines the following terms: 151 application: Both the sender and ultimate consumer of push messages. 152 Many applications have components that are run on a user agent and 153 other components that run on servers. 155 application server: The component of an application that runs on a 156 server and requests the delivery of a push message. 158 push message subscription: A message delivery context that is 159 established between the user agent and the push service and shared 160 with the application server. All push messages are associated 161 with a push message subscription. 163 push message subscription set: A message delivery context that is 164 established between the user agent and the push service that 165 collects multiple push message subscriptions into a set. 167 push message: A message sent from an application server to a user 168 agent via a push service. 170 push message receipt: A message delivery confirmation sent from the 171 push service to the application server. 173 push service: A service that delivers push messages to user agents. 175 user agent: A device and software that is the recipient of push 176 messages. 178 Examples in this document use the HTTP/1.1 message format [RFC7230]. 179 Many of the exchanges can be completed using HTTP/1.1, where HTTP/2 180 is necessary, the more verbose frame format from [RFC7540] is used. 182 2. Overview 184 A general model for push services includes three basic actors: a user 185 agent, a push service, and an application (server). 187 +-------+ +--------------+ +-------------+ 188 | UA | | Push Service | | Application | 189 +-------+ +--------------+ +-------------+ 190 | | | 191 | Subscribe | | 192 |--------------------->| | 193 | Monitor | | 194 |<====================>| | 195 | | | 196 | Distribute Push Resource | 197 |-------------------------------------------->| 198 | | | 199 : : : 200 | | Push Message | 201 | Push Message |<---------------------| 202 |<---------------------| | 203 | | | 205 At the very beginning of the process, a new message subscription is 206 created by the user agent and then distributed to its application 207 server. This subscription is the basis of all future interactions 208 between the actors. 210 To offer more control for authorization, a message subscription is 211 modeled as two resources with different capabilities: 213 o A subscription resource is used to receive messages from a 214 subscription and to delete a subscription. It is private to the 215 user agent. 217 o A push resource is used to send messages to a subscription. It is 218 public and shared by the user agent with its application server. 220 It is expected that a unique subscription will be distributed to each 221 application; however, there are no inherent cardinality constraints 222 in the protocol. Multiple subscriptions might be created for the 223 same application, or multiple applications could use the same 224 subscription. Note however that sharing subscriptions has security 225 and privacy implications. 227 Subscriptions have a limited lifetime. They can also be terminated 228 by either the push service or user agent at any time. User agents 229 and application servers must be prepared to manage changes in 230 subscription state. 232 2.1. HTTP Resources 234 This protocol uses HTTP resources [RFC7230] and link relations 235 [RFC5988]. The following resources are defined: 237 push service: This resource is used to create push message 238 subscriptions (Section 4). A URL for the push service is 239 configured into user agents. 241 push message subscription: This resource provides read and delete 242 access for a message subscription. A user agent receives push 243 messages (Section 6) using a push message subscription. Every 244 push message subscription has exactly one push resource associated 245 with it. 247 push message subscription set: This resource provides read and 248 delete access for a collection of push message subscriptions. A 249 user agent receives push messages (Section 6.1) for all the push 250 message subscriptions in the set. A link relation of type 251 "urn:ietf:params:push:set" identifies a push message subscription 252 set. 254 push: An application server requests the delivery (Section 5) of a 255 push message using a push resource. A link relation of type 256 "urn:ietf:params:push" identifies a push resource. 258 push message: The push service creates a push message resource to 259 identify push messages that have been accepted for delivery 260 (Section 5). The push message resource is also deleted by the 261 user agent to acknowledge receipt (Section 6.2) of a push message. 263 receipt subscription: An application server receives delivery 264 confirmations (Section 5.1) for push messages using a receipt 265 subscription. A link relation of type 266 "urn:ietf:params:push:receipt" identifies a receipt subscription. 268 3. Connecting to the Push Service 270 The push service shares the same default port number (443/TCP) with 271 HTTPS, but MAY also advertise the IANA allocated TCP System Port 1001 272 using HTTP alternative services [RFC7838]. 274 While the default port (443) offers broad reachability 275 characteristics, it is most often used for web browsing scenarios 276 with a lower idle timeout than other ports configured in middleboxes. 277 For webpush scenarios, this would contribute to unnecessary radio 278 communications to maintain the connection on battery-powered devices. 280 Advertising the alternate port (1001) allows middleboxes to optimize 281 idle timeouts for connections specific to push scenarios with the 282 expectation that data exchange will be infrequent. 284 Middleboxes SHOULD comply with REQ-5 in [RFC5382] which requires that 285 "the value of the 'established connection idle-timeout' MUST NOT be 286 less than 2 hours 4 minutes". 288 4. Subscribing for Push Messages 290 A user agent sends a POST request to its configured push service 291 resource to create a new subscription. 293 POST /subscribe HTTP/1.1 294 Host: push.example.net 296 A 201 (Created) response indicates that the a push subscription was 297 created. A URI for the push message subscription resource that was 298 created in response to the request MUST be returned in the Location 299 header field. 301 The push service MUST provide a URI for the push resource 302 corresponding to the push message subscription in a link relation of 303 type "urn:ietf:params:push". 305 An application-specific method is used to distribute the push URI to 306 the application server. Confidentiality protection and application 307 server authentication MUST be used to ensure that this URI is not 308 disclosed to unauthorized recipients (Section 8.3). 310 HTTP/1.1 201 Created 311 Date: Thu, 11 Dec 2014 23:56:52 GMT 312 Link:

; 313 rel="urn:ietf:params:push" 314 Link: ; 315 rel="urn:ietf:params:push:set" 316 Location: https://push.example.net/s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx 318 4.1. Collecting Subscriptions into Sets 320 Collecting multiple push message subscriptions into a subscription 321 set can represent a significant efficiency improvement for a push 322 service. The push service MAY provide a URI for a subscription set 323 resource in a link relation of type "urn:ietf:params:push:set". 325 When a subscription set is returned in a push message subscription 326 response, the user agent SHOULD include this subscription set in a 327 link relation of type "urn:ietf:params:push:set" in subsequent 328 requests to create new push message subscriptions. 330 A user agent MAY omit the subscription set if it is unable to receive 331 push messages that are aggregated for the lifetime of the 332 subscription. This might be necessary if the user agent is 333 forwarding requests from other clients. 335 POST /subscribe HTTP/1.1 336 Host: push.example.net 337 Link: ; 338 rel="urn:ietf:params:push:set" 340 The push service SHOULD return the same subscription set in its 341 response, although it MAY return a new subscription set if it is 342 unable to reuse the one provided by the user agent. 344 HTTP/1.1 201 Created 345 Date: Thu, 11 Dec 2014 23:56:52 GMT 346 Link:

; 347 rel="urn:ietf:params:push" 348 Link: ; 349 rel="urn:ietf:params:push:set" 350 Location: https://push.example.net/s/i-nQ3A9Zm4kgSWg8_ZijVQ 352 A push service MUST return a 400 (Bad Request) status code for 353 requests which contain an invalid subscription set. A push service 354 MAY return a 429 (Too Many Requests) status code [RFC6585] to reject 355 requests which omit a subscription set. 357 How a push service detects that requests originate from the same user 358 agent is implementation-specific but could take ambient information 359 into consideration, such as the TLS connection, source IP address and 360 port. Implementers are reminded that some heuristics can produce 361 false positives and cause requests to be rejected incorrectly. 363 5. Requesting Push Message Delivery 365 An application server requests the delivery of a push message by 366 sending a HTTP POST request to a push resource distributed to the 367 application server by a user agent. The push message is included in 368 the body of the request. 370 POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 371 Host: push.example.net 372 TTL: 15 373 Content-Type: text/plain;charset=utf8 374 Content-Length: 36 376 iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB 378 A 201 (Created) response indicates that the push message was 379 accepted. A URI for the push message resource that was created in 380 response to the request MUST be returned in the Location header 381 field. This does not indicate that the message was delivered to the 382 user agent. 384 HTTP/1.1 201 Created 385 Date: Thu, 11 Dec 2014 23:56:55 GMT 386 Location: https://push.example.net/d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk 388 5.1. Requesting Push Message Receipts 390 An application server can include the Prefer header field [RFC7240] 391 with the "respond-async" preference to request confirmation from the 392 push service when a push message is delivered and then acknowledged 393 by the user agent. 395 POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 396 Host: push.example.net 397 Prefer: respond-async 398 TTL: 15 399 Content-Type: text/plain;charset=utf8 400 Content-Length: 36 402 iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB 403 A 202 (Accepted) response indicates that the push message was 404 accepted. A URI for the push message resource that was created in 405 response to the request MUST be returned in the Location header 406 field. The push service MUST also provide a URI for the receipt 407 subscription resource in a link relation of type 408 "urn:ietf:params:push:receipt". 410 HTTP/1.1 202 Accepted 411 Date: Thu, 11 Dec 2014 23:56:55 GMT 412 Link: ; 413 rel="urn:ietf:params:push:receipt" 414 Location: https://push.example.net/d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk 416 For subsequent receipt requests to the same origin [RFC6454], the 417 application server SHOULD include the returned receipt subscription 418 in a link relation of type "urn:ietf:params:push:receipt". This 419 gives the push service an option to aggregate the receipts. The push 420 service SHOULD return the same receipt subscription in its response, 421 although it MAY return a new receipt subscription if it is unable to 422 reuse the one provided by the application server. 424 A push service MUST return a 400 (Bad Request) status code for 425 requests which contain an invalid receipt subscription. If a push 426 service wishes to limit the number of receipt subscriptions that it 427 maintains, it MAY return a 429 (Too Many Requests) status code 428 [RFC6585] to reject receipt requests which omit a receipt 429 subscription. 431 5.2. Push Message Time-To-Live 433 A push service can improve the reliability of push message delivery 434 considerably by storing push messages for a period. User agents are 435 often only intermittently connected, and so benefit from having short 436 term message storage at the push service. 438 Delaying delivery might also be used to batch communication with the 439 user agent, thereby conserving radio resources. 441 Some push messages are not useful once a certain period of time 442 elapses. Delivery of messages after they have ceased to be relevant 443 is wasteful. For example, if the push message contains a call 444 notification, receiving a message after the caller has abandoned the 445 call is of no value; the application at the user agent is forced to 446 suppress the message so that it does not generate a useless alert. 448 An application server MUST include the TTL (Time-To-Live) header 449 field in its request for push message delivery. The TTL header field 450 contains a value in seconds that suggests how long a push message is 451 retained by the push service. 453 TTL = 1*DIGIT 455 A push service MUST return a 400 (Bad Request) status code in 456 response to requests that omit the TTL header field. 458 A push service MAY retain a push message for a shorter duration than 459 requested. It indicates this by returning a TTL header field in its 460 response with the actual TTL. This TTL value MUST be less than or 461 equal to the value provided by the application server. 463 Once the TTL period elapses, the push service MUST NOT attempt to 464 deliver the push message to the user agent. A push service might 465 adjust the TTL value to account for time accounting errors in 466 processing. For instance, distributing a push message within a 467 server cluster might accrue errors due to clock skew or propagation 468 delays. 470 A push service is not obligated to account for time spent by the 471 application server in sending a push message to the push service, or 472 delays incurred while sending a push message to the user agent. An 473 application server needs to account for transit delays in selecting a 474 TTL header field value. 476 A Push message with a zero TTL is immediately delivered if the user 477 agent is available to receive the message. After delivery, the push 478 service is permitted to immediately remove a push message with a zero 479 TTL. This might occur before the user agent acknowledges receipt of 480 the message by performing a HTTP DELETE on the push message resource. 481 Consequently, an application server cannot rely on receiving 482 acknowledgement receipts for zero TTL push messages. 484 If the user agent is unavailable, a push message with a zero TTL 485 expires and is never delivered. 487 5.3. Push Message Urgency 489 For a device that is battery-powered, it is often critical that it 490 remains dormant for extended periods. Radio communication in 491 particular consumes significant power and limits the length of time 492 that the device can operate. 494 To avoid consuming resources to receive trivial messages, it is 495 helpful if an application server can communicate the urgency of a 496 message and if the user agent can request that the push server only 497 forward messages of a specific urgency. 499 An application server MAY include an Urgency header field in its 500 request for push message delivery. This header field indicates the 501 message urgency. The push service MUST not forward the Urgency 502 header field to the user agent. An push message without the Urgency 503 header field defaults to a value of "normal". 505 A user agent MAY include the Urgency header field when monitoring for 506 push messages to indicate the lowest urgency of push messages that it 507 is willing to receive. A push service MUST NOT deliver push messages 508 with lower urgency than the value indicated by the user agent in its 509 monitoring request. Push messages of any urgency are delivered to a 510 user agent that does not include an Urgency header field when 511 monitoring for messages. 513 Urgency = 1#(urgency-option) 514 urgency-option = ("very-low" / "low" / "normal" / "high") 516 In order of increasing urgency: 518 +----------+-----------------------------+--------------------------+ 519 | Urgency | Device State | Application Scenario | 520 +----------+-----------------------------+--------------------------+ 521 | very-low | On power and wifi | Advertisements | 522 | low | On either power or wifi | Topic updates | 523 | normal | On neither power nor wifi | Chat or Calendar Message | 524 | high | Low battery | Incoming phone call or | 525 | | | time-sensitive alert | 526 +----------+-----------------------------+--------------------------+ 528 Table 1: Table of Urgency Values 530 Multiple values for the Urgency header field MUST NOT be included in 531 requests; otherwise, the push service MUST return a 400 (Bad Request) 532 status code. 534 5.4. Updating Push Messages 536 A push message that has been stored by the push service can be 537 replaced with new content. If the user agent is offline during the 538 time that the push messages are sent, updating a push message avoids 539 the situation where outdated or redundant messages are sent to the 540 user agent. 542 Only push messages that have been assigned a topic can be updated. A 543 push message with a topic replaces any outstanding push message with 544 an identical topic. 546 A push message topic is a string carried in a Topic header field. A 547 topic is used to correlate push messages sent to the same 548 subscription and does not convey any other semantics. 550 The grammar for the Topic header field uses the "token" and "quoted- 551 string" rules defined in [RFC7230]. 553 Topic = token / quoted-string 555 Any double quotes from the "quoted-string" form are removed before 556 comparing topics for equality. 558 For use with this protocol, the Topic header field MUST be restricted 559 to no more than 32 characters from the URL and filename safe Base 64 560 alphabet [RFC4648]. A push service that receives a request with a 561 Topic header field that does not meet these constraints MUST return a 562 400 (Bad Request) status code to the application server. 564 A push message update request creates a new push message resource and 565 simultaneously deletes any existing message resource that has a 566 matching topic. In effect, the information that is stored for the 567 push message is updated, but a new resource is created to avoid 568 problems with in flight acknowledgments for the old message. The 569 push service MAY suppress acknowledgement receipts for the replaced 570 message. 572 A push message with a topic that is not shared by an outstanding 573 message to the same subscription is stored or delivered as normal. 575 For example, the following message could cause an existing message to 576 be updated: 578 POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 579 Host: push.example.net 580 TTL: 600 581 Topic: "upd" 582 Content-Type: text/plain;charset=utf8 583 Content-Length: 36 585 ZuHSZPKa2b1jtOKLGpWrcrn8cNqt0iVQyroF 586 If the push service identifies an outstanding push message with a 587 topic of "upd", then that message resource is deleted. A 201 588 (Created) response indicates that the push message update was 589 accepted. A URI for the new push message resource that was created 590 in response to the request is included in the Location header field. 592 HTTP/1.1 201 Created 593 Date: Thu, 11 Dec 2014 23:57:02 GMT 594 Location: https://push.example.net/d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk 596 The value of the Topic header field MUST NOT be forwarded to user 597 agents. Its value is neither encrypted nor authenticated. 599 6. Receiving Push Messages for a Subscription 601 A user agent requests the delivery of new push messages by making a 602 GET request to a push message subscription resource. The push 603 service does not respond to this request, it instead uses HTTP/2 604 server push [RFC7540] to send the contents of push messages as they 605 are sent by application servers. 607 A user agent MAY include a Urgency header field in its request. The 608 push service MUST NOT deliver messages with lower urgency than the 609 value of the header field as defined in the Table of Urgency Values. 611 Each push message is pushed as the response to a synthesized GET 612 request in a PUSH_PROMISE. This GET request is made to the push 613 message resource that was created by the push service when the 614 application server requested message delivery. The response headers 615 SHOULD provide a URI for the push resource corresponding to the push 616 message subscription in a link relation of type 617 "urn:ietf:params:push". The response body is the entity body from 618 the most recent request sent to the push resource by the application 619 server. 621 The following example request is made over HTTP/2. 623 HEADERS [stream 7] +END_STREAM +END_HEADERS 624 :method = GET 625 :path = /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx 626 :authority = push.example.net 628 The push service permits the request to remain outstanding. When a 629 push message is sent by an application server, a server push is 630 associated with the initial request. The response includes the push 631 message. 633 PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS 634 :method = GET 635 :path = /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk 636 :authority = push.example.net 638 HEADERS [stream 4] +END_HEADERS 639 :status = 200 640 date = Thu, 11 Dec 2014 23:56:56 GMT 641 last-modified = Thu, 11 Dec 2014 23:56:55 GMT 642 cache-control = private 643 :link =

; 644 rel="urn:ietf:params:push" 645 content-type = text/plain;charset=utf8 646 content-length = 36 648 DATA [stream 4] +END_STREAM 649 iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB 651 HEADERS [stream 7] +END_STREAM +END_HEADERS 652 :status = 200 654 A user agent can also request the contents of the push message 655 subscription resource immediately by including a Prefer header field 656 [RFC7240] with a "wait" preference set to "0". In response to this 657 request, the push service MUST generate a server push for all push 658 messages that have not yet been delivered. 660 A 204 (No Content) status code with no associated server pushes 661 indicates that no messages are presently available. This could be 662 because push messages have expired. 664 6.1. Receiving Push Messages for a Subscription Set 666 There are minor differences between receiving push messages for a 667 subscription and a subscripion set. If a subscription set is 668 available, the user agent SHOULD use the subscription set to monitor 669 for push messages rather than individual push message subscriptions. 671 A user agent requests the delivery of new push messages for a 672 collection of push message subscriptions by making a GET request to a 673 push message subscription set resource. The push service does not 674 respond to this request, it instead uses HTTP/2 server push [RFC7540] 675 to send the contents of push messages as they are sent by application 676 servers. 678 A user agent MAY include a Urgency header field in its request. The 679 push service MUST NOT deliver messages with lower urgency than the 680 value of the header field as defined in the Table of Urgency Values. 682 Each push message is pushed as the response to a synthesized GET 683 request sent in a PUSH_PROMISE. This GET request is made to the push 684 message resource that was created by the push service when the 685 application server requested message delivery. The synthetic request 686 MUST provide a URI for the push resource corresponding to the push 687 message subscription in a link relation of type 688 "urn:ietf:params:push". This enables the user agent to differentiate 689 the source of the message. The response body is the entity body from 690 the most recent request sent to the push resource by an application 691 server. 693 The following example request is made over HTTP/2. 695 HEADERS [stream 7] +END_STREAM +END_HEADERS 696 :method = GET 697 :path = /set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy 698 :authority = push.example.net 700 The push service permits the request to remain outstanding. When a 701 push message is sent by an application server, a server push is 702 associated with the initial request. The response includes the push 703 message. 705 PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS 706 :method = GET 707 :path = /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk 708 :authority = push.example.net 709 :link =

; 710 rel="urn:ietf:params:push" 712 HEADERS [stream 4] +END_HEADERS 713 :status = 200 714 date = Thu, 11 Dec 2014 23:56:56 GMT 715 last-modified = Thu, 11 Dec 2014 23:56:55 GMT 716 cache-control = private 717 content-type = text/plain;charset=utf8 718 content-length = 36 720 DATA [stream 4] +END_STREAM 721 iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB 723 HEADERS [stream 7] +END_STREAM +END_HEADERS 724 :status = 200 726 A user agent can request the contents of the push message 727 subscription set resource immediately by including a Prefer header 728 field [RFC7240] with a "wait" preference set to "0". In response to 729 this request, the push service MUST generate a server push for all 730 push messages that have not yet been delivered. 732 A 204 (No Content) status code with no associated server pushes 733 indicates that no messages are presently available. This could be 734 because push messages have expired. 736 6.2. Acknowledging Push Messages 738 To ensure that a push message is properly delivered to the user agent 739 at least once, the user agent MUST acknowledge receipt of the message 740 by performing a HTTP DELETE on the push message resource. 742 DELETE /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk HTTP/1.1 743 Host: push.example.net 744 If the push service receives the acknowledgement and the application 745 has requested a delivery receipt, the push service MUST return a 204 746 (No Content) response to the application server monitoring the 747 receipt subscription. 749 If the push service does not receive the acknowledgement within a 750 reasonable amount of time, then the message is considered to be not 751 yet delivered. The push service SHOULD continue to retry delivery of 752 the message until its advertised expiration. 754 The push service MAY cease to retry delivery of the message prior to 755 its advertised expiration due to scenarios such as an unresponsive 756 user agent or operational constraints. If the application has 757 requested a delivery receipt, then the push service MUST return a 410 758 (Gone) to the application server monitoring the receipt subscription. 760 6.3. Receiving Push Message Receipts 762 The application server requests the delivery of receipts from the 763 push service by making a HTTP GET request to the receipt subscription 764 resource. The push service does not respond to this request, it 765 instead uses HTTP/2 server push [RFC7540] to send push receipts when 766 messages are acknowledged (Section 6.2) by the user agent. 768 Each receipt is pushed as the response to a synthesized GET request 769 sent in a PUSH_PROMISE. This GET request is made to the same push 770 message resource that was created by the push service when the 771 application server requested message delivery. A successful response 772 includes a 204 (No Content) status code with no data. 774 The following example request is made over HTTP/2. 776 HEADERS [stream 13] +END_STREAM +END_HEADERS 777 :method = GET 778 :path = /r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM 779 :authority = push.example.net 781 The push service permits the request to remain outstanding. When the 782 user agent acknowledges the message, the push service pushes a 783 delivery receipt to the application server. A 204 (No Content) 784 status code confirms that the message was delivered and acknowledged. 786 PUSH_PROMISE [stream 13; promised stream 82] +END_HEADERS 787 :method = GET 788 :path = /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk 789 :authority = push.example.net 791 HEADERS [stream 82] +END_STREAM 792 +END_HEADERS 793 :status = 204 794 date = Thu, 11 Dec 2014 23:56:56 GMT 796 If the user agent fails to acknowledge the receipt of the push 797 message and the push service ceases to retry delivery of the message 798 prior to its advertised expiration, then the push service MUST push a 799 failure response with a status code of 410 (Gone). 801 7. Operational Considerations 803 7.1. Load Management 805 A push service is likely to have to maintain a very large number of 806 open TCP connections. Effective management of those connections can 807 depend on being able to move connections between server instances. 809 A user agent MUST support the 307 (Temporary Redirect) status code 810 [RFC7231], which can be used by a push service to redistribute load 811 at the time that a new subscription is requested. 813 A server that wishes to redistribute load can do so using HTTP 814 alternative services [RFC7838]. HTTP alternative services allows for 815 redistribution of load while maintaining the same URIs for various 816 resources. A user agent can ensure a graceful transition by using 817 the GOAWAY frame once it has established a replacement connection. 819 7.2. Push Message Expiration 821 Storage of push messages based on the TTL header field comprises a 822 potentially significant amount of storage for a push service. A push 823 service is not obligated to store messages indefinitely. A push 824 service is able to indicate how long it intends to retain a message 825 to an application server using the TTL header field (Section 5.2). 827 A user agent that does not actively monitor for push messages will 828 not receive messages that expire during that interval. 830 Push messages that are stored and not delivered to a user agent are 831 delivered when the user agent recommences monitoring. Stored push 832 messages SHOULD include a Last-Modified header field (Section 2.2 of 833 [RFC7232]) indicating when delivery was requested by an application 834 server. 836 A GET request to a push message subscription resource with only 837 expired messages results in a response as though no push message was 838 ever sent. 840 Push services might need to limit the size and number of stored push 841 messages to avoid overloading. To limit the size of messages, the 842 push service MAY return a 413 (Payload Too Large) status code 843 [RFC7231] in response to requests that include an entity body that is 844 too large. Push services MUST NOT return a 413 status code in 845 responses to an entity body that is 4k (4096 bytes) or less in size. 847 To limit the number of stored push messages, the push service MAY 848 either expire messages prior to their advertised Time-To-Live or 849 reduce their advertised Time-To-Live. 851 7.3. Subscription Expiration 853 In some cases, it may be necessary to terminate subscriptions so that 854 they can be refreshed. This applies to both push message 855 subscriptions and receipt subscriptions. 857 A push service can remove a subscription at any time. If a user 858 agent or application server has an outstanding request to a 859 subscription resource (Section 6), this MUST be signaled by returning 860 a 404 (Not Found) status code. 862 A push service MUST return a 404 (Not Found) status code if an 863 application server attempts to send a push message to a removed or 864 expired push message subscription. 866 A user agent can remove its push message subscription by sending a 867 DELETE request to the corresponding URI. An application server can 868 remove its receipt subscription by sending a DELETE request to the 869 corresponding URI. 871 7.3.1. Subscription Set Expiration 873 A push service MAY expire a subscription set at any time which MUST 874 also expire all push message subscriptions in the set. If a user 875 agent has an outstanding request to a push subscription set 876 (Section 6.1) this can be signaled by returning a 400-series status 877 code, such as 410 (Gone). 879 A user agent can request that a subscription set be removed by 880 sending a DELETE request to the subscription set URI. This MUST also 881 remove all push message subscriptions in the set. 883 If a specific push message subscription that is a member of a 884 subscription set is expired or removed, then it MUST also be removed 885 from its subscription set. 887 7.4. Implications for Application Reliability 889 A push service that does not support reliable delivery over 890 intermittent network connections or failing applications on devices, 891 forces the device to acknowledge receipt directly to the application 892 server, incurring additional power drain in order to establish 893 (usually secure) connections to the individual application servers. 895 Push message reliability can be important if messages contain 896 information critical to the state of an application. Repairing state 897 can be expensive, particularly for devices with limited 898 communications capacity. Knowing that a push message has been 899 correctly received avoids retransmissions, polling, and state 900 resynchronization. 902 The availability of push message delivery receipts ensures that the 903 application developer is not tempted to create alternative mechanisms 904 for message delivery in case the push service fails to deliver a 905 critical message. Setting up a polling mechanism or a backup 906 messaging channel in order to compensate for these shortcomings 907 negates almost all of the advantages a push service provides. 909 However, reliability might not be necessary for messages that are 910 transient (e.g. an incoming call) or messages that are quickly 911 superceded (e.g. the current number of unread emails). 913 7.5. Subscription Sets and Concurrent HTTP/2 streams 915 If the push service requires that the user agent use push message 916 subscription sets, then it MAY limit the number of concurrently 917 active streams with the SETTINGS_MAX_CONCURRENT_STREAMS parameter 918 within a HTTP/2 SETTINGS frame [RFC7540]. The user agent MAY be 919 limited to one concurrent stream to manage push message subscriptions 920 and one concurrent stream for each subscription set returned by the 921 push service. This could force the user agent to serialize 922 subscription requests to the push service. 924 8. Security Considerations 926 This protocol MUST use HTTP over TLS [RFC2818]. This includes any 927 communications between user agent and push service, plus 928 communications between the application and the push service. All 929 URIs therefore use the "https" scheme. This provides confidentiality 930 and integrity protection for subscriptions and push messages from 931 external parties. 933 Applications using this protocol MUST use mechanisms that provide 934 confidentiality, integrity and data origin authentication. The 935 application server sending the push message and the application on 936 the user agent that receives it are frequently just different 937 instances of the same application, so no standardized protocol is 938 needed to establish a proper security context. The distribution of 939 subscription information from the user agent to its application 940 server also offers a convenient medium for key agreement. 942 8.1. Confidentiality from Push Service Access 944 The protection afforded by TLS does not protect content from the push 945 service. Without additional safeguards, a push service can inspect 946 and modify the message content. 948 For its requirements, the W3C Push API [API] has adopted Message 949 Encryption for WebPush [I-D.ietf-webpush-encryption] to secure the 950 content of messages from the push service. Other scenarios can be 951 addressed by similar policies. 953 The Topic header field exposes information that allows more granular 954 correlation of push messages on the same subject. This might be used 955 to aid traffic analysis of push messages by the push service. 957 8.2. Privacy Considerations 959 Push message confidentiality does not ensure that the identity of who 960 is communicating and when they are communicating is protected. 961 However, the amount of information that is exposed can be limited. 963 The URIs provided for push resources MUST NOT provide any basis to 964 correlate communications for a given user agent. It MUST NOT be 965 possible to correlate any two push resource URIs based solely on 966 their contents. This allows a user agent to control correlation 967 across different applications, or over time. 969 Similarly, the URIs provided by the push service to identify a push 970 message MUST NOT provide any information that allows for correlation 971 across subscriptions. Push message URIs for the same subscription 972 MAY contain information that would allow correlation with the 973 associated subscription or other push messages for that subscription. 975 User and device information MUST NOT be exposed through a push or 976 push message URI. 978 In addition, push URIs established by the same user agent or push 979 message URIs for the same subscription MUST NOT include any 980 information that allows them to be correlated with the user agent. 982 Note: This need not be perfect as long as the resulting anonymity 983 set ([RFC6973], Section 6.1.1) is sufficiently large. A push URI 984 necessarily identifies a push service or a single server instance. 985 It is also possible that traffic analysis could be used to 986 correlate subscriptions. 988 A user agent MUST be able to create new subscriptions with new 989 identifiers at any time. 991 8.3. Authorization 993 This protocol does not define how a push service establishes whether 994 a user agent is permitted to create a subscription, or whether push 995 messages can be delivered to the user agent. A push service MAY 996 choose to authorize requests based on any HTTP-compatible 997 authorization method available, of which there are numerous options. 998 The authorization process and any associated credentials are expected 999 to be configured in the user agent along with the URI for the push 1000 service. 1002 Authorization is managed using capability URLs for the push message 1003 subscription, push, and receipt subscription resources ([CAP-URI]). 1004 A capability URL grants access to a resource based solely on 1005 knowledge of the URL. 1007 Capability URLs are used for their "easy onward sharing" and "easy 1008 client API" properties. These make it possible to avoid relying on 1009 relationships between push services and application servers, with the 1010 protocols necessary to build and support those relationships. 1012 Capability URLs act as bearer tokens. Knowledge of a push message 1013 subscription URI implies authorization to either receive push 1014 messages or delete the subscription. Knowledge of a push URI implies 1015 authorization to send push messages. Knowledge of a push message URI 1016 allows for reading and acknowledging that specific message. 1017 Knowledge of a receipt subscription URI implies authorization to 1018 receive push receipts. 1020 Encoding a large amount of random entropy (at least 120 bits) in the 1021 path component ensures that it is difficult to successfully guess a 1022 valid capability URL. 1024 8.4. Denial of Service Considerations 1026 A user agent can control where valid push messages originate by 1027 limiting the distribution of push URIs to authorized application 1028 servers. Ensuring that push URIs are hard to guess ensures that only 1029 application servers that have received a push URI can use it. 1031 Push messages that are not successfully authenticated by the user 1032 agent will not be delivered, but this can present a denial of service 1033 risk. Even a relatively small volume of push messages can cause 1034 battery-powered devices to exhaust power reserves. 1036 To address this case, the W3C Push API [API] has adopted Voluntary 1037 Application Server Identification [I-D.ietf-webpush-vapid], which 1038 allows a user agent to restrict a subscription to a specific 1039 application server. The push service can then identity and reject 1040 unwanted messages without contacting the user agent. 1042 A malicious application with a valid push URI could use the greater 1043 resources of a push service to mount a denial of service attack on a 1044 user agent. Push services SHOULD limit the rate at which push 1045 messages are sent to individual user agents. 1047 A push service MAY return a 429 (Too Many Requests) status code 1048 [RFC6585] when an application server has exceeded its rate limit for 1049 push message delivery to a push resource. The push service SHOULD 1050 also include a Retry-After header [RFC7231] to indicate how long the 1051 application server is requested to wait before it makes another 1052 request to the push resource. 1054 A push service or user agent MAY also terminate subscriptions 1055 (Section 7.3) that receive too many push messages. 1057 A push service is also able to deny service to user agents. 1058 Intentional failure to deliver messages is difficult to distinguish 1059 from faults, which might occur due to transient network errors, 1060 interruptions in user agent availability, or genuine service outages. 1062 8.5. Logging Risks 1064 Server request logs can reveal subscription-related URIs or 1065 relationships between subscription-related URIs for the same user 1066 agent. Limitations on log retention and strong access control 1067 mechanisms can ensure that URIs are not revealed to unauthorized 1068 entities. 1070 9. IANA Considerations 1072 This protocol defines new HTTP header fields in Section 9.1. New 1073 link relation types are identified using the URNs defined in 1074 Section 9.2. Port registration is defined in Section 9.3 1076 9.1. Header Field Registrations 1078 HTTP header fields are registered within the "Message Headers" 1079 registry maintained at . 1082 This document defines the following HTTP header fields, so their 1083 associated registry entries shall be added according to the permanent 1084 registrations below ([RFC3864]): 1086 +-------------------+----------+----------+--------------+ 1087 | Header Field Name | Protocol | Status | Reference | 1088 +-------------------+----------+----------+--------------+ 1089 | TTL | http | standard | Section 5.2 | 1090 | Urgency | http | standard | Section 5.3 | 1091 | Topic | http | standard | Section 5.4 | 1092 +-------------------+----------+----------+--------------+ 1094 The change controller is: "IETF (iesg@ietf.org) - Internet 1095 Engineering Task Force". 1097 9.2. Link Relation URNs 1099 This document registers URNs for use in identifying link relation 1100 types. These are added to a new "Web Push Identifiers" registry 1101 according to the procedures in Section 4 of [RFC3553]; the 1102 corresponding "push" sub-namespace is entered in the "IETF URN Sub- 1103 namespace for Registered Protocol Parameter Identifiers" registry. 1105 The "Web Push Identifiers" registry operates under the IETF Review 1106 policy [RFC5226]. 1108 Registry name: Web Push Identifiers 1109 URN Prefix: urn:ietf:params:push 1111 Specification: (this document) 1113 Repository: [Editor/IANA note: please include a link to the final 1114 registry location.] 1116 Index value: Values in this registry are URNs or URN prefixes that 1117 start with the prefix "urn:ietf:params:push". Each is registered 1118 independently. 1120 New registrations in the "Web Push Identifiers" are encouraged to 1121 include the following information: 1123 URN: A complete URN or URN prefix. 1125 Description: A summary description. 1127 Specification: A reference to a specification describing the 1128 semantics of the URN or URN prefix. 1130 Contact: Email for the person or group making the registration. 1132 Index value: As described in [RFC3553], URN prefixes that are 1133 registered include a description of how the URN is constructed. 1134 This is not applicable for specific URNs. 1136 These values are entered as the initial content of the "Web Push 1137 Identifiers" registry. 1139 URN: urn:ietf:params:push 1141 Description: This link relation type is used to identify a resource 1142 for sending push messages. 1144 Specification: (this document) 1146 Contact: The Web Push WG (webpush@ietf.org) 1148 URN: urn:ietf:params:push:set 1150 Description: This link relation type is used to identify a 1151 collection of push message subscriptions. 1153 Specification: (this document) 1155 Contact: The Web Push WG (webpush@ietf.org) 1156 URN: urn:ietf:params:push:receipt 1158 Description: This link relation type is used to identify a resource 1159 for receiving delivery confirmations for push messages. 1161 Specification: (this document) 1163 Contact: The Web Push WG (webpush@ietf.org) 1165 9.3. Service Name and Port Number Registration 1167 Service names and port numbers are registered within the "Service 1168 Name and Transport Protocol Port Number Registry" maintained at 1169 . 1172 IANA is requested to assign the System Port number 1001 and the 1173 service name "webpush" in accordance with [RFC6335]. 1175 Service Name. 1176 webpush 1178 Transport Protocol. 1179 tcp 1181 Assignee. 1182 IESG (iesg@ietf.org) 1184 Contact. 1185 The Web Push WG (webpush@ietf.org) 1187 Description. 1188 HTTP Web Push 1190 Reference. 1191 [RFCthis] 1193 Port Number. 1194 1001 1196 10. Acknowledgements 1198 Significant technical input to this document has been provided by Ben 1199 Bangert, Kit Cambridge, JR Conlin, Matthew Kaufman, Costin Manolache, 1200 Mark Nottingham, Robert Sparks, Darshak Thakore and many others. 1202 11. References 1204 11.1. Normative References 1206 [CAP-URI] Tennison, J., "Good Practices for Capability URLs", FPWD 1207 capability-urls, February 2014, 1208 . 1210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1211 Requirement Levels", BCP 14, RFC 2119, March 1997. 1213 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1215 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1216 IETF URN Sub-namespace for Registered Protocol 1217 Parameters", BCP 73, RFC 3553, June 2003. 1219 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1220 Procedures for Message Header Fields", BCP 90, RFC 3864, 1221 September 2004. 1223 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1224 Encodings", RFC 4648, October 2006. 1226 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1227 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1228 May 2008. 1230 [RFC5382] Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, 1231 "NAT Behavioral Requirements for TCP", RFC 5382, October 1232 2008. 1234 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 1236 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1237 Cheshire, "Internet Assigned Numbers Authority (IANA) 1238 Procedures for the Management of the Service Name and 1239 Transport Protocol Port Number Registry", RFC 6335, August 1240 2011. 1242 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 1243 2011. 1245 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 1246 Codes", RFC 6585, April 2012. 1248 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1249 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 1250 2014. 1252 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1253 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 1255 [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1256 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 1258 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, June 2014. 1260 [RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 1261 Protocol Version 2", RFC 7540, May 2015. 1263 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1264 Alternative Services", RFC 7838, April 2016. 1266 11.2. Informative References 1268 [API] van Ouwerkerk, M., Thomson, M., Sullivan, B., and E. 1269 Fullea, "W3C Push API", ED push-api, January 2016, 1270 . 1272 [I-D.ietf-webpush-encryption] 1273 Thomson, M., "Message Encryption for Web Push", draft- 1274 ietf-webpush-encryption-02 (work in progress), March 2016, 1275 . 1278 [I-D.ietf-webpush-vapid] 1279 Thomson, M. and P. Beverloo, "Voluntary Application Server 1280 Identification for Web Push", draft-ietf-webpush-vapid-00 1281 (work in progress), April 2016, 1282 . 1285 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1286 Morris, J., Hansen, M., and R. Smith, "Privacy 1287 Considerations for Internet Protocols", RFC 6973, July 1288 2013. 1290 Appendix A. Change Log 1292 [[The RFC Editor is requested to remove this section at 1293 publication.]] 1295 A.1. Since draft-ietf-webpush-protocol-00 1297 Editorial changes for Push Message Time-To-Live 1299 Editorial changes for Push Acknowledgements 1301 Removed subscription expiration based on HTTP cache headers 1303 A.2. Since draft-ietf-webpush-protocol-01 1305 Added Subscription Sets 1307 Added System Port as an alternate service with guidance for idle 1308 timeouts 1310 Finalized status codes for acknowledgements 1312 Editorial changes for Rate Limits 1314 A.3. Since draft-ietf-webpush-protocol-02 1316 Added explicit correlation for Subscription Sets 1318 Added Push Message Updates (message collapsing) 1320 Renamed the push:receipt link relation to push:receipts and 1321 transitioned the Push-Receipt header field to the push:receipt link 1322 relation type 1324 A.4. Since draft-ietf-webpush-protocol-03 1326 An application server MUST include the TTL (Time-To-Live) header 1327 field in its request for push message delivery. 1329 Added Push Message Urgency header field 1331 A.5. Since draft-ietf-webpush-protocol-04 1333 Simplified design for Push Receipts and eliminated the 1334 urn:ietf:params:push:receipts link relation 1336 Clarified Security Considerations section and added informative 1337 references to Message Encryption and Voluntary Application Server 1338 Identification 1340 Authors' Addresses 1342 Martin Thomson 1343 Mozilla 1344 331 E Evelyn Street 1345 Mountain View, CA 94041 1346 US 1348 Email: martin.thomson@gmail.com 1350 Elio Damaggio 1351 Microsoft 1352 One Microsoft Way 1353 Redmond, WA 98052 1354 US 1356 Email: elioda@microsoft.com 1358 Brian Raymor (editor) 1359 Microsoft 1360 One Microsoft Way 1361 Redmond, WA 98052 1362 US 1364 Email: brian.raymor@microsoft.com