idnits 2.17.00 (12 Aug 2021) /tmp/idnits10049/draft-damaggio-webpush-http2-00.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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 6, 2015) is 2632 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'CAP-URI' == Outdated reference: draft-ietf-httpbis-http2 has been published as RFC 7540 ** Downref: Normative reference to an Informational RFC: RFC 2818 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBPUSH E. Damaggio 3 Internet-Draft B. Raymor 4 Intended status: Standards Track Microsoft 5 Expires: September 7, 2015 March 6, 2015 7 Generic Event Delivery Using HTTP Push 8 draft-damaggio-webpush-http2-00 10 Abstract 12 A simple protocol for the delivery of realtime events to user agents 13 is described. This scheme uses HTTP/2 server push. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 7, 2015. 32 Copyright Notice 34 Copyright (c) 2015 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 51 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 2.1. HTTP Resources . . . . . . . . . . . . . . . . . . . . . 6 53 3. Registration . . . . . . . . . . . . . . . . . . . . . . . . 6 54 4. Subscribing . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 5. Requesting Push Message Delivery . . . . . . . . . . . . . . 7 56 5.1. Requesting Push Message Receipts . . . . . . . . . . . . 8 57 6. Receiving Push Messages . . . . . . . . . . . . . . . . . . . 9 58 6.1. Acknowledging Push Message Receipts . . . . . . . . . . . 10 59 7. Operational Considerations . . . . . . . . . . . . . . . . . 11 60 7.1. Load Management . . . . . . . . . . . . . . . . . . . . . 11 61 7.2. Push Message Expiration . . . . . . . . . . . . . . . . . 11 62 7.3. Subscription Expiration . . . . . . . . . . . . . . . . . 12 63 7.4. Implications for Application Reliability . . . . . . . . 12 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 8.1. Confidentiality from Push Service Access . . . . . . . . 13 66 8.2. Privacy Considerations . . . . . . . . . . . . . . . . . 13 67 8.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 14 68 8.4. Denial of Service Considerations . . . . . . . . . . . . 15 69 8.5. Logging Risks . . . . . . . . . . . . . . . . . . . . . . 15 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 74 11.2. Informative References . . . . . . . . . . . . . . . . . 18 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 77 1. Introduction 79 Many applications on mobile and embedded devices require continuous 80 access to network communications so that real-time events - such as 81 incoming calls or messages - can be conveyed (or "pushed") in a 82 timely fashion. 84 Mobile and embedded devices typically have limited power reserves, so 85 finding more efficient ways to serve application requirements greatly 86 benefits the application ecosystem. One significant contributor to 87 power usage is the radio. Radio communications consume a significant 88 portion of the energy budget on a wirelessly connected device. 90 Uncoordinated use of persistent connections or sessions can 91 contribute to unnecessary use of the device radio, since each 92 independent session independently incurs overheads. In particular, 93 keep alive traffic used to ensure that middleboxes do not prematurely 94 time out sessions, can result in significant waste. Maintenance 95 traffic tends to dominate over the long term, since events are 96 relatively rare. 98 Consolidating all real-time events into a single session ensures more 99 efficient use of network and radio resources. A single service 100 consolidates all events, distributing those events to applications as 101 they arrive. This requires just one session, avoiding duplicated 102 overhead costs. 104 A push server that does not support reliable delivery over 105 intermittent network connections or failing applications on devices, 106 forces the device to acknowledge receipt directly to the application 107 server, incurring additional power drain in order to establish 108 (usually secure) connections to the individual application servers. 110 While reliability is not required for messages that expire in few 111 seconds (e.g. an incoming call) or collapsible ones (e.g. the current 112 number of unread emails), it is more important when messages contain 113 information that is longer lasting, e.g. a command to update a 114 configuration value, or the acknowledgement of a financial 115 transaction or workflow step. In particular, in the case of power- 116 constrained devices, it is preferable to transmit the actual 117 information in the "pushed" message reliably, instead of forcing them 118 to reconnect periodically to get the current state. 120 An open standard to "push" messages to embedded and mobile devices: 122 o Simplifies deployment of "push" features across a variety of 123 mobile and embedded device platforms 125 o Creates an ecosystem of services (e.g. consolidation services) and 126 development tools enabling efficient "push" 128 o Technically enables consolidating real-time events into a single 129 session which is impossible when each "push" implementation is 130 built in isolation 132 There are two primary scenarios under consideration: 134 o Web applications in a mobile user agent and 136 o Embedded devices receiving push messages from cloud services 137 through an intermediate "field gateway", i.e. a reasonably 138 powerful device (capable of secure HTTP/2 communications), which 139 acts as a local agent. 141 The W3C Web Push API [API] describes an API that enables the use of a 142 consolidated push service from web applications. This expands on 143 that work by describing a protocol that can be used to: 145 o request the delivery of a push message to a user agent, 147 o create new push message delivery subscriptions, and 149 o monitor for new push messages. 151 Requesting the delivery of events is particularly important for the 152 Web Push API. The registration, management and monitoring functions 153 are currently fulfilled by proprietary protocols; these are adequate, 154 but do not offer any of the advantages that standardization affords. 156 In the embedded field gateway scenario, small (possibly much less 157 capable devices) connect to a field gateway to receive push messages. 158 This protocol does not detail the device-to-field gateway connection, 159 instead it details how the field-gateway can efficiently receive push 160 messages on behalf of many devices. 162 This document intentionally does not describe how a push service is 163 discovered. Discovery of push services is left for future efforts, 164 if it turns out to be necessary at all. User agents are expected to 165 be configured with a URL for one (or more) push services. 167 1.1. Conventions and Terminology 169 In cases where normative language needs to be emphasized, this 170 document falls back on established shorthands for expressing 171 interoperability requirements on implementations: the capitalized 172 words "MUST", "MUST NOT", "SHOULD" and "MAY". The meaning of these 173 is described in [RFC2119]. 175 This document defines the following terms: 177 application: Both the sender and ultimate consumer of push messages. 178 Many applications have components that are run on a user agent and 179 other components that run on servers. 181 application server: The component of an application that runs on a 182 server and requests the delivery of a push message. 184 push message: A message, sent from an application server to a user 185 agent via a push service. 187 push service: A service that delivers push messages to user agents. 189 subscription: A message delivery context that is established between 190 the user agent and the push service and shared with applications. 191 All push messages are associated with a subscription. 193 user agent: A device and software that is the recipient of push 194 messages. 196 Examples in this document use the HTTP/1.1 message format [RFC7230]. 197 Many of the exchanges can be completed using HTTP/1.1, where HTTP/2 198 is necessary, the more verbose frame format from 199 [I-D.ietf-httpbis-http2] is used. 201 2. Overview 203 A general model for push services includes three basic actors: a user 204 agent, a push service, and an application (server). 206 +-------+ +--------------+ +-------------+ 207 | UA | | Push Service | | Application | 208 +-------+ +--------------+ +-------------+ 209 | | | 210 | Subscribe | | 211 |--------------------->| | 212 | Monitor | | 213 |<====================>| | 214 | | | 215 | Provide Subscription | 216 |-------------------------------------------->| 217 | | | 218 : : : 219 | | Push Message | 220 | Push Message |<---------------------| 221 |<---------------------| | 222 | | | 224 At the very beginning of the process, a new subscription is created 225 by the user agent and then distributed to an application server. The 226 subscription is the basis of all future interactions between the user 227 agent and push service. 229 It is expected that a different subscription will be provided to each 230 application; however, there are no inherent cardinality constraints 231 in the protocol. Multiple subscriptions might be created for the 232 same application, or multiple applications could use the same 233 subscription. Note however that sharing subscriptions can have 234 security and privacy implications. 236 Application servers use subscriptions to deliver push messages to 237 user agents, via the push service. 239 Subscriptions have a limited lifetime. They can also be terminated 240 by either push service or user agent at any time. User agents and 241 application servers need to be prepared to manage changes in 242 subscription state. 244 2.1. HTTP Resources 246 This protocol uses HTTP resources [RFC7230] and link relations 247 [RFC5988]. The following resources are defined: 249 push service: This resource is used in Subscribing (Section 4). It 250 is configured into user agents. 252 subscription: A link relation of type "urn:ietf:params:push" refers 253 to a subscription resource. Subscription resources are used to 254 deliver push messages. An application server sends push messages 255 (Section 5) and a user agent receives push messages (Section 6) 256 using this resource. 258 receipt: A link relation of type "urn:ietf:params:push:receipt" 259 refers to a delivery receipt resource. An application server 260 receives delivery confirmation (Section 5.1) for push messages 261 using this resource. 263 3. Registration 265 The Registration and Subscribe resources referenced in 266 [I-D.draft-thomson-webpush-http2-02] were deprecated to eliminate the 267 overhead of maintaining registration-subscription relationships in 268 the push server. 270 4. Subscribing 272 A user agent sends a POST request to its configured push service 273 resource to create a new subscription. 275 POST /subscribe/ HTTP/1.1 276 Host: push.example.net 278 A response with a 201 (Created) status code includes a URI for the 279 subscription in the Location header field. 281 HTTP/1.1 201 Created 282 Date: Thu, 11 Dec 2014 23:56:52 GMT 283 Link:

; 284 rel="urn:ietf:params:push" 285 Location: https://push.example.net/p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx 286 Cache-Control: max-age:864000, private 288 The user agent should securely distribute the "subscription" resource 289 to its application server. (Details are outside the scope of this 290 document.) 292 5. Requesting Push Message Delivery 294 An application server requests the delivery of a push message by 295 sending an HTTP POST request to the "subscription" resource 296 distributed by its user agent. The push message is included in the 297 body of the request. 299 The push message is a JSON [RFC7159] object which contains the push 300 message data and directives for the push server: 302 +-----------------+----------+--------------------------------------+ 303 | Member | Use | Description | 304 +-----------------+----------+--------------------------------------+ 305 | message | optional | A JSON object that contains push | 306 | | | message data | 307 | request_receipt | optional | A JSON boolean indicating whether | 308 | | | the application server requests a | 309 | | | confirmation that the push message | 310 | | | was delivered to the user agent. Its | 311 | | | default value is false. | 312 | time_to_live | optional | A JSON number that represents the | 313 | | | expiration time in seconds for a | 314 | | | push message. It is relative to the | 315 | | | time that the push server receives | 316 | | | the request. A message MUST NOT be | 317 | | | delivered after it expires. | 318 +-----------------+----------+--------------------------------------+ 320 Table 1: Push Message Request Format 322 POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 323 Host: push.example.net 324 Content-Type: application/json 325 Content-Length: ... 327 { 328 "request_receipt": true, 329 "message": {"data": "Hello World"} 330 } 332 A response with a 201 (Created) status code includes a URI for the 333 message in the Location header field. This does not indicate that 334 the message was delivered to the user agent. If a receipt was 335 requested, then a URI for the receipt resource is included in the 336 Link header field in the response. 338 HTTP/1.1 201 Created 339 Date: Thu, 11 Dec 2014 23:56:55 GMT 340 Link: . 738 [I-D.draft-thomson-webpush-http2-02] 739 Thomson, M., "Generic Event Delivery Using HTTP Push (work 740 in progress)", December 2014, 741 . 744 [I-D.ietf-httpbis-http2] 745 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 746 Protocol version 2", draft-ietf-httpbis-http2-17 (work in 747 progress), February 2015. 749 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 750 Requirement Levels", BCP 14, RFC 2119, March 1997. 752 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 754 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 755 IETF URN Sub-namespace for Registered Protocol 756 Parameters", BCP 73, RFC 3553, June 2003. 758 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 759 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 760 May 2008. 762 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 764 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 765 Interchange Format", RFC 7159, March 2014. 767 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 768 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 769 2014. 771 [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 772 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 774 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 775 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 776 2014. 778 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, June 2014. 780 11.2. Informative References 782 [API] Sullivan, B. and E. Fullea, "Web Push API", ED push-api, 783 December 2014, . 785 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 786 Morris, J., Hansen, M., and R. Smith, "Privacy 787 Considerations for Internet Protocols", RFC 6973, July 788 2013. 790 Authors' Addresses 792 Elio Damaggio 793 Microsoft 794 One Microsoft Way 795 Redmond, WA 98052 796 US 798 Email: elioda@microsoft.com 800 Brian Raymor 801 Microsoft 802 One Microsoft Way 803 Redmond, WA 98052 804 US 806 Email: brian.raymor@microsoft.com