WEBPUSH E. Damaggio Internet-Draft B. Raymor Intended status: Standards Track Microsoft Expires: September 7, 2015 March 6, 2015 Generic Event Delivery Using HTTP Push draft-damaggio-webpush-http2-00 Abstract A simple protocol for the delivery of realtime events to user agents is described. This scheme uses HTTP/2 server push. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 7, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Damaggio & Raymor Expires September 7, 2015 [Page 1] Internet-Draft HTTP Web Push March 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. HTTP Resources . . . . . . . . . . . . . . . . . . . . . 6 3. Registration . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Subscribing . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Requesting Push Message Delivery . . . . . . . . . . . . . . 7 5.1. Requesting Push Message Receipts . . . . . . . . . . . . 8 6. Receiving Push Messages . . . . . . . . . . . . . . . . . . . 9 6.1. Acknowledging Push Message Receipts . . . . . . . . . . . 10 7. Operational Considerations . . . . . . . . . . . . . . . . . 11 7.1. Load Management . . . . . . . . . . . . . . . . . . . . . 11 7.2. Push Message Expiration . . . . . . . . . . . . . . . . . 11 7.3. Subscription Expiration . . . . . . . . . . . . . . . . . 12 7.4. Implications for Application Reliability . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8.1. Confidentiality from Push Service Access . . . . . . . . 13 8.2. Privacy Considerations . . . . . . . . . . . . . . . . . 13 8.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 14 8.4. Denial of Service Considerations . . . . . . . . . . . . 15 8.5. Logging Risks . . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Many applications on mobile and embedded devices require continuous access to network communications so that real-time events - such as incoming calls or messages - can be conveyed (or "pushed") in a timely fashion. Mobile and embedded devices typically have limited power reserves, so finding more efficient ways to serve application requirements greatly benefits the application ecosystem. One significant contributor to power usage is the radio. Radio communications consume a significant portion of the energy budget on a wirelessly connected device. Uncoordinated use of persistent connections or sessions can contribute to unnecessary use of the device radio, since each independent session independently incurs overheads. In particular, keep alive traffic used to ensure that middleboxes do not prematurely time out sessions, can result in significant waste. Maintenance Damaggio & Raymor Expires September 7, 2015 [Page 2] Internet-Draft HTTP Web Push March 2015 traffic tends to dominate over the long term, since events are relatively rare. Consolidating all real-time events into a single session ensures more efficient use of network and radio resources. A single service consolidates all events, distributing those events to applications as they arrive. This requires just one session, avoiding duplicated overhead costs. A push server that does not support reliable delivery over intermittent network connections or failing applications on devices, forces the device to acknowledge receipt directly to the application server, incurring additional power drain in order to establish (usually secure) connections to the individual application servers. While reliability is not required for messages that expire in few seconds (e.g. an incoming call) or collapsible ones (e.g. the current number of unread emails), it is more important when messages contain information that is longer lasting, e.g. a command to update a configuration value, or the acknowledgement of a financial transaction or workflow step. In particular, in the case of power- constrained devices, it is preferable to transmit the actual information in the "pushed" message reliably, instead of forcing them to reconnect periodically to get the current state. An open standard to "push" messages to embedded and mobile devices: o Simplifies deployment of "push" features across a variety of mobile and embedded device platforms o Creates an ecosystem of services (e.g. consolidation services) and development tools enabling efficient "push" o Technically enables consolidating real-time events into a single session which is impossible when each "push" implementation is built in isolation There are two primary scenarios under consideration: o Web applications in a mobile user agent and o Embedded devices receiving push messages from cloud services through an intermediate "field gateway", i.e. a reasonably powerful device (capable of secure HTTP/2 communications), which acts as a local agent. Damaggio & Raymor Expires September 7, 2015 [Page 3] Internet-Draft HTTP Web Push March 2015 The W3C Web Push API [API] describes an API that enables the use of a consolidated push service from web applications. This expands on that work by describing a protocol that can be used to: o request the delivery of a push message to a user agent, o create new push message delivery subscriptions, and o monitor for new push messages. Requesting the delivery of events is particularly important for the Web Push API. The registration, management and monitoring functions are currently fulfilled by proprietary protocols; these are adequate, but do not offer any of the advantages that standardization affords. In the embedded field gateway scenario, small (possibly much less capable devices) connect to a field gateway to receive push messages. This protocol does not detail the device-to-field gateway connection, instead it details how the field-gateway can efficiently receive push messages on behalf of many devices. This document intentionally does not describe how a push service is discovered. Discovery of push services is left for future efforts, if it turns out to be necessary at all. User agents are expected to be configured with a URL for one (or more) push services. 1.1. Conventions and Terminology In cases where normative language needs to be emphasized, this document falls back on established shorthands for expressing interoperability requirements on implementations: the capitalized words "MUST", "MUST NOT", "SHOULD" and "MAY". The meaning of these is described in [RFC2119]. This document defines the following terms: application: Both the sender and ultimate consumer of push messages. Many applications have components that are run on a user agent and other components that run on servers. application server: The component of an application that runs on a server and requests the delivery of a push message. push message: A message, sent from an application server to a user agent via a push service. push service: A service that delivers push messages to user agents. Damaggio & Raymor Expires September 7, 2015 [Page 4] Internet-Draft HTTP Web Push March 2015 subscription: A message delivery context that is established between the user agent and the push service and shared with applications. All push messages are associated with a subscription. user agent: A device and software that is the recipient of push messages. Examples in this document use the HTTP/1.1 message format [RFC7230]. Many of the exchanges can be completed using HTTP/1.1, where HTTP/2 is necessary, the more verbose frame format from [I-D.ietf-httpbis-http2] is used. 2. Overview A general model for push services includes three basic actors: a user agent, a push service, and an application (server). +-------+ +--------------+ +-------------+ | UA | | Push Service | | Application | +-------+ +--------------+ +-------------+ | | | | Subscribe | | |--------------------->| | | Monitor | | |<====================>| | | | | | Provide Subscription | |-------------------------------------------->| | | | : : : | | Push Message | | Push Message |<---------------------| |<---------------------| | | | | At the very beginning of the process, a new subscription is created by the user agent and then distributed to an application server. The subscription is the basis of all future interactions between the user agent and push service. It is expected that a different subscription will be provided to each application; however, there are no inherent cardinality constraints in the protocol. Multiple subscriptions might be created for the same application, or multiple applications could use the same subscription. Note however that sharing subscriptions can have security and privacy implications. Damaggio & Raymor Expires September 7, 2015 [Page 5] Internet-Draft HTTP Web Push March 2015 Application servers use subscriptions to deliver push messages to user agents, via the push service. Subscriptions have a limited lifetime. They can also be terminated by either push service or user agent at any time. User agents and application servers need to be prepared to manage changes in subscription state. 2.1. HTTP Resources This protocol uses HTTP resources [RFC7230] and link relations [RFC5988]. The following resources are defined: push service: This resource is used in Subscribing (Section 4). It is configured into user agents. subscription: A link relation of type "urn:ietf:params:push" refers to a subscription resource. Subscription resources are used to deliver push messages. An application server sends push messages (Section 5) and a user agent receives push messages (Section 6) using this resource. receipt: A link relation of type "urn:ietf:params:push:receipt" refers to a delivery receipt resource. An application server receives delivery confirmation (Section 5.1) for push messages using this resource. 3. Registration The Registration and Subscribe resources referenced in [I-D.draft-thomson-webpush-http2-02] were deprecated to eliminate the overhead of maintaining registration-subscription relationships in the push server. 4. Subscribing A user agent sends a POST request to its configured push service resource to create a new subscription. POST /subscribe/ HTTP/1.1 Host: push.example.net A response with a 201 (Created) status code includes a URI for the subscription in the Location header field. Damaggio & Raymor Expires September 7, 2015 [Page 6] Internet-Draft HTTP Web Push March 2015 HTTP/1.1 201 Created Date: Thu, 11 Dec 2014 23:56:52 GMT Link:

; rel="urn:ietf:params:push" Location: https://push.example.net/p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx Cache-Control: max-age:864000, private The user agent should securely distribute the "subscription" resource to its application server. (Details are outside the scope of this document.) 5. Requesting Push Message Delivery An application server requests the delivery of a push message by sending an HTTP POST request to the "subscription" resource distributed by its user agent. The push message is included in the body of the request. The push message is a JSON [RFC7159] object which contains the push message data and directives for the push server: +-----------------+----------+--------------------------------------+ | Member | Use | Description | +-----------------+----------+--------------------------------------+ | message | optional | A JSON object that contains push | | | | message data | | request_receipt | optional | A JSON boolean indicating whether | | | | the application server requests a | | | | confirmation that the push message | | | | was delivered to the user agent. Its | | | | default value is false. | | time_to_live | optional | A JSON number that represents the | | | | expiration time in seconds for a | | | | push message. It is relative to the | | | | time that the push server receives | | | | the request. A message MUST NOT be | | | | delivered after it expires. | +-----------------+----------+--------------------------------------+ Table 1: Push Message Request Format Damaggio & Raymor Expires September 7, 2015 [Page 7] Internet-Draft HTTP Web Push March 2015 POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 Host: push.example.net Content-Type: application/json Content-Length: ... { "request_receipt": true, "message": {"data": "Hello World"} } A response with a 201 (Created) status code includes a URI for the message in the Location header field. This does not indicate that the message was delivered to the user agent. If a receipt was requested, then a URI for the receipt resource is included in the Link header field in the response. HTTP/1.1 201 Created Date: Thu, 11 Dec 2014 23:56:55 GMT Link: . [I-D.draft-thomson-webpush-http2-02] Thomson, M., "Generic Event Delivery Using HTTP Push (work in progress)", December 2014, . [I-D.ietf-httpbis-http2] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer Protocol version 2", draft-ietf-httpbis-http2-17 (work in progress), February 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014. [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014. Damaggio & Raymor Expires September 7, 2015 [Page 17] Internet-Draft HTTP Web Push March 2015 [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014. [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, June 2014. 11.2. Informative References [API] Sullivan, B. and E. Fullea, "Web Push API", ED push-api, December 2014, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013. Authors' Addresses Elio Damaggio Microsoft One Microsoft Way Redmond, WA 98052 US Email: elioda@microsoft.com Brian Raymor Microsoft One Microsoft Way Redmond, WA 98052 US Email: brian.raymor@microsoft.com Damaggio & Raymor Expires September 7, 2015 [Page 18]