idnits 2.17.1 draft-thomson-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 (May 12, 2014) is 3637 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) == Outdated reference: A later version (-14) exists of draft-ietf-httpbis-alt-svc-01 == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-12 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 May 12, 2014 5 Expires: November 13, 2014 7 Generic Event Delivery Using HTTP Push 8 draft-thomson-webpush-http2-00 10 Abstract 12 A simple scheme for the delivery of realtime events to clients is 13 described. This scheme uses HTTP/2 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 November 13, 2014. 32 Copyright Notice 34 Copyright (c) 2014 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 . . . . . . . . . . . . . . . 3 51 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Delivering Push Messages . . . . . . . . . . . . . . . . . . 5 53 4. Registering . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 6. Monitoring and Receiving Push Messages . . . . . . . . . . . 6 56 7. Store and Forward Operation . . . . . . . . . . . . . . . . . 6 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 61 10.2. Informative References . . . . . . . . . . . . . . . . . 8 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 64 1. Introduction 66 Mobile computing devices are increasingly relied upon for a great 67 many applications. Mobile devices typically have limited power 68 reserves, so finding more efficient ways to serve application 69 requirements is an important part of any mobile platform. 71 One significant contributor to power usage mobile devices is the 72 radio. Cellular - and to a lesser extent, IEEE 802 radios - consume 73 a significant portion of the energy budget on a wirelessly connected 74 mobile device. 76 Many applications require continuous access to network communications 77 so that real-time events - such as incoming calls or messages - can 78 be conveyed (or "pushed") to the user in a timely fashion. 79 Uncoordinated use of persistent connections or sessions from multiple 80 applications can contribute to unnecessary use of the device radio, 81 since each independent session independently incurs overheads. In 82 particular, keep alive traffic used to ensure that middleboxes do not 83 prematurely time out sessions, can result in significant waste. 84 Maintenance traffic tends to dominate over the long term, since 85 events are relatively rare. 87 Consolidating all real-time events into a single session ensures more 88 efficient use of network and radio resources. A single service 89 consolidates all events, distributing those events to applications as 90 they arrive. This requires just one session, avoiding duplicated 91 overhead costs. 93 The Web Push API [API] describes an API that enables the use of a 94 consolidated push service from web applications. This expands on 95 that work by describing a protocol that can be used to: 97 o request the delivery of an event to an attached device 99 o register a new device, create new event delivery channels, and 100 monitor those channels for new events 102 This is intentionally split into these two categories because 103 requesting the delivery of events is required for immediate use by 104 the Web Push API. The registration, management and monitoring 105 functions are currently fulfilled by proprietary protocols; these are 106 adequate, but do not offer any advantages that standardization 107 affords. 109 The monitoring function described in this document is intended to be 110 replaceable, enabling the use of monitoring schemes that are better 111 optimized for the network environment and the device. For instance, 112 using notification systems like the GSM Short Message Service (SMS) 113 can take advantage of the native paging capabilities of a cellular 114 network, avoiding the ongoing maintainence cost of a persistent TCP 115 connection. 117 This document intentionally does not describe how a push server is 118 discovered. Discovery of push servers is left for future efforts, if 119 it turns out to be necessary at all. Devices are expected to be 120 configured with a push server URL. 122 Similarly, discovery of support for and negotiation of use of 123 alternative monitoring schemes is left to documents that extend this 124 basic protocol. 126 1.1. Conventions and Terminology 128 In cases where normative language needs to be emphasized, this 129 document falls back on established shorthands for expressing 130 interoperability requirements on implementations: the capitalized 131 words "MUST", "MUST NOT", "SHOULD" and "MAY". The meaning of these 132 is described in [RFC2119]. 134 This document will use the terminology from [API], though 135 "application" will be used in preference to "webapp", since the 136 described protocols are not restricted to web use. This document 137 introduces the term "device", which refers to the consumer of push 138 messages. 140 2. Overview 142 A general model for push services includes three basic actors: a 143 device, a push server, and an application. 145 +-----------+ +-------------+ +-------------+ 146 | Device | | Push Server | | Application | 147 +-----------+ +-------------+ +-------------+ 148 | | | 149 | Register | | 150 |--------------------->| | 151 | Monitor | | 152 |<====================>| | 153 | Get Channel | | 154 |--------------------->| | 155 | Provide Channel | 156 |-------------------------------------------->| 157 | | Push Message | 158 | Push Message |<---------------------| 159 |<---------------------| | 160 | | | 162 At the very beginning of the process, the device registers with the 163 push server. This establishes a shared session between the device 164 and push server that will be used to aggregate push messages from all 165 applications that the device interacts with. 167 The registration response includes details on how the device is 168 expected to monitor for incoming push messages. This document 169 describes one such mechanism, though more efficient means of 170 monitoring could be optionally defined (and this is expressly 171 permitted). 173 A registration after creation has no channels associated with it. 174 New channels can be requested by the device and then distributed to 175 applications. It is expected that devices will distribute a 176 different channel to each application, with the potential for 177 multiple channels being provided to the same application. 179 Applications use channels to deliver push messages to devices, via 180 the push server. 182 Both registrations and channels have a limited lifetime. These will 183 need to be refreshed over time. 185 3. Delivering Push Messages 187 A push channel is identified with an HTTP URI 188 [I-D.ietf-httpbis-p1-messaging]. An application can request the 189 delivery of a push message by sending an HTTP PUT request to this 190 URI, including the push message in the body of the request. 192 A push server can acknowledge the end-to-end delivery of a push 193 message by responding with a 200 (OK) status code. A push server 194 that stores the message for later delivery (see Section 7) could 195 respond with a 202 (Accepted) status code to indicate that the 196 message was stored, but not delivered. 198 4. Registering 200 A device that wishes to establish a new or replacement registration 201 sends an HTTP POST request to its configured push server URL. The 202 request contains no entity body. 204 The push server creates a new registration in response to this 205 request, creating two new resources and allocating an HTTP URI for 206 each. These URIs are included in link relations that are included in 207 Link header fields in the response. 209 monitor: A link relation of type "...:push:monitor" includes the URL 210 of a resource that the device can monitor for events. Monitoring 211 is described in Section 6. 213 channel: A link relation of type "...:push:channel" includes a URL 214 of a resource where the device can create new channels. Creating 215 channels is described in Section 5. 217 The push server includes the "monitor" link relation in a Location 218 header field. 220 The push server MUST include expiration information in the response 221 to this request in either the Expires header field, or by setting a 222 "max-age" parameter on a Cache-Control header field. The Cache- 223 Control header field MUST include the "private" directive 224 [I-D.ietf-httpbis-p6-cache]. 226 The push server SHOULD also provide the "channel" link and expiration 227 information in response to requests to the "monitor" resource. 229 5. Channels 231 A client sends a POST request to the "channel" resource to create a 232 new channel. 234 A response with a 201 status code includes the channel URI in the 235 Location header field. 237 A channel can expire. Servers indicate this using the Expires header 238 field, or by setting a "max-age" parameter on a Cache-Control header 239 field. 241 A client can explicitly delete a channel by sending a DELETE request 242 to channel URI. 244 6. Monitoring and Receiving Push Messages 246 A device monitors for new events by making a GET request to the 247 monitor resource. The server does not respond to these request, it 248 instead uses server push [I-D.ietf-httpbis-http2] to send the 249 contents of push messages as applications send them. 251 Each push message consists of a synthesized GET request to the 252 channel URI that was the target of the push. The response body is 253 the entity body from the PUT request. 255 A device can request the monitor resource immediately by including a 256 Prefer header field [I-D.snell-http-prefer] with a "wait" parmeter 257 set to "0". 259 A server that wishes to redistribute load can do so using The 260 alternative services mechanisms that are part of HTTP/2 261 [I-D.ietf-httpbis-alt-svc]. The ALTSVC frame type allows for 262 redistribution of load whilst retaining the same monitor resource. 263 Once a device has established a replacement connection, it can notify 264 the server of imminent shutdown using a GOAWAY frame, which allows 265 the server to respond to the long-standing GET request and gracefully 266 shut down the connection. This allows for seamless migration between 267 servers. 269 7. Store and Forward Operation 271 Push servers are not obligated to store messages for any time. If a 272 client is not actively monitoring for push messages, messages can be 273 lost. 275 Push servers are permitted to store messages for some time to allow 276 for limited recovery from transient faults. If a message is stored, 277 but not delivered, the push server can indicate the probable duration 278 of storage by including expiration information in the response to the 279 push request. 281 Messages that were stored and not delivered to a client MAY be 282 delivered when a client commences monitoring. These messages should 283 include a Last-Modified header field. If a server stores push 284 messages, a GET request to a channel URI returns the last message 285 sent by an application to that channel. 287 Push servers that store push messages might need to limit the size of 288 push messages to avoid being subject to overloading. Push servers 289 that don't store can stream the payload of push messages to devices. 290 This can use HTTP/2 flow control to limit the state commitment this 291 requires. However, push servers MAY place an upper limit on the size 292 of push messages that they permit. 294 8. IANA Considerations 296 TODO: register link relation types, as necessary. 298 9. Security Considerations 300 This protocol does not specific a single authorization framework for 301 managing access to push servers, either by devices or applications. 302 Thus, there is a very real possibility that this could be exploited 303 to mount denial of service attacks on the push service. 305 Push services MAY choose to authorize requests based on any HTTP- 306 compatible means available, of which there are numerous options. 308 A malicious application can use the greater resources of a push 309 server to mount a denial of service attack on devices. Push servers 310 MAY limit the rate at which push messages are sent to devices. 312 One basic protection against misuse of push channels is to ensure 313 that only authorized applications are given channel URIs and to make 314 it extremely difficult to successfully guess a valid channel URI. 315 Encoding a large amount of random entropy in the URI path is one 316 technique for ensuring that channel URIs are able to act as bearer 317 tokens. 319 A push server is able to see (and modify) the content of push 320 messages. Applications that depend on end-to-end guarantees MUST use 321 object security mechanisms to protect the confidentiality and 322 integrity of push messages. Since the application frequently resides 323 both in the server that originates the push messages and in the 324 device, and there is a requirement for direct communications between 325 these two instances to exchange channel information, this provides a 326 perfect medium for key agreement. 328 A push server is also able to deny service. In addition to malicious 329 reasons, delivery of push messages can fail due to transient faults 330 in networks, the device being temporarily unavailable, or other 331 similar faults. Therefore, applications that rely on the content of 332 push messages being delivered MUST ensure that they provide other 333 means of delivering messages to devices. 335 10. References 337 10.1. Normative References 339 [I-D.ietf-httpbis-alt-svc] 340 mnot, m., McManus, P., and J. Reschke, "HTTP Alternative 341 Services", draft-ietf-httpbis-alt-svc-01 (work in 342 progress), April 2014. 344 [I-D.ietf-httpbis-http2] 345 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 346 Protocol version 2", draft-ietf-httpbis-http2-12 (work in 347 progress), April 2014. 349 [I-D.ietf-httpbis-p1-messaging] 350 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 351 (HTTP/1.1): Message Syntax and Routing", draft-ietf- 352 httpbis-p1-messaging-26 (work in progress), February 2014. 354 [I-D.ietf-httpbis-p6-cache] 355 Fielding, R., mnot, m., and J. Reschke, "Hypertext 356 Transfer Protocol (HTTP/1.1): Caching", draft-ietf- 357 httpbis-p6-cache-26 (work in progress), February 2014. 359 [I-D.snell-http-prefer] 360 Snell, J., "Prefer Header for HTTP", draft-snell-http- 361 prefer-18 (work in progress), January 2013. 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, March 1997. 366 10.2. Informative References 368 [API] Sullivan, B. and E. Fullea, "Web Push API", Editor's Draft 369 push-api, May 2014, . 372 Author's Address 374 Martin Thomson 375 Mozilla 376 331 E Evelyn Street 377 Mountain View, CA 94041 378 US 380 Email: martin.thomson@gmail.com