idnits 2.17.1 draft-pardue-quic-http-unbound-server-push-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 date (January 29, 2018) is 2278 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-09 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-09 ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Pardue 3 Internet-Draft BBC Research & Development 4 Intended status: Informational January 29, 2018 5 Expires: August 2, 2018 7 Unbound Server Push (USP) for HTTP/QUIC 8 draft-pardue-quic-http-unbound-server-push-00 10 Abstract 12 This document defines an HTTP semantic extension, Unbound Server Push 13 (USP), which allows HTTP resources to be pushed without the need for 14 a prior HTTP request. HTTP/QUIC clients opt in to this feature via 15 an HTTP/QUIC setting. 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 August 2, 2018. 34 Copyright Notice 36 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 53 2. The SETTINGS_ENABLE_UNBOUND_PUSH Parameter . . . . . . . . . 3 54 3. Usage of Unbound Server Push . . . . . . . . . . . . . . . . 3 55 4. 0-RTT Considerations . . . . . . . . . . . . . . . . . . . . 4 56 5. Handling Multiple Clients . . . . . . . . . . . . . . . . . . 4 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 7.1. Registration of SETTINGS_ENABLE_UNBOUND_PUSH parameter . 4 60 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 61 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 HTTP server push is a feature of HTTP/2 [RFC7540] and HTTP/QUIC 67 [QUIC-HTTP] that allows a server to pre-emptively send HTTP resources 68 to a client in association with a previous client-initiated request. 69 This binding to a request object aligns with paradigms familiar to 70 client and server implementations. Unbound server push, in contrast, 71 may provide benefits for use cases where holding a request object 72 open for long periods (long polling) is undesirable, or where a 73 request object does not exist (unidirectional flows). (The 74 introduction of unidirectional streams in the QUIC transport 75 [QUIC-TRANSPORT] provides a direct expression of this message 76 exchange pattern.) 78 This document defines an HTTP/QUIC protocol extension that allows a 79 server to send an HTTP/QUIC "PUSH_PROMISE" frame on a server- 80 initiated unidirectional stream. Endpoints opt in to the unbound 81 server push feature using a "SETTINGS" parameter (Section 2) in 82 accordance with Section 5.5 of [RFC7540]. This is the only 83 behavioural change to server push as described in [QUIC-HTTP]. 84 Unbound server push operates in addition to bound server push for any 85 HTTP/QUIC connection. 87 Unbound server push should used with care. It may introduce 88 complexities for implementations, particularly intermediaries, and it 89 can pose challenges for presentation to the application above HTTP. 91 In deployments where multiple client connections are trunked by a 92 reverse proxy onto a single upstream connection, unbound server push 93 is effectively a mechanism for achieving application-level multicast 94 to all downstream clients that have enabled this feature. 96 *Authors' Note:* Unbound server push is proposed as an extension 97 to HTTP/QUIC in order to start a discussion on whether this 98 feature should be incorporated into the core HTTP/QUIC 99 specification document. 101 1.1. Notational Conventions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 2. The SETTINGS_ENABLE_UNBOUND_PUSH Parameter 111 This document adds a new HTTP/QUIC "SETTINGS" Parameter to those 112 defined by [QUIC-HTTP] Section 5.2.5. 114 The new parameter is "SETTINGS_ENABLE_UNBOUND_PUSH" (type = 0xTBD). 115 This setting can be used to enable unbound server push. The value of 116 the parameter is an integer that MUST be 0 or 1. Any value other 117 than 0 or 1 MUST be treated as a connection error of type 118 "PROTOCOL_ERROR". 120 The initial value is 0, which indicates that unbound server push is 121 disabled by default. 123 3. Usage of Unbound Server Push 125 Unbound server push changes only one aspect of HTTP/QUIC server push: 126 the stream type on which an HTTP/QUIC "PUSH_PROMISE" frame can be 127 sent. It does not prevent the conventional use of bound server push; 128 both types MAY be used concurrently. The Push ID number space is 129 shared across both types. Unbound server push is subject to the 130 limits imposed by the HTTP/QUIC "MAX_PUSH_ID" frame. 132 An endpoint that receives the "SETTINGS_ENABLE_UNBOUND_PUSH" 133 parameter set to a value of 0 MUST only send an HTTP/QUIC 134 "PUSH_PROMISE" frame on an appropriate client-initiated bidirectional 135 request stream. An endpoint that has set this parameter to 0 and had 136 it acknowledged MUST treat the reception of an HTTP/QUIC 137 "PUSH_PROMISE" frame on any other stream type as a connection error 138 of type "PROTOCOL_ERROR". 140 A server that receives the "SETTINGS_ENABLE_UNBOUND_PUSH" parameter 141 set to a value of 1 MAY send an HTTP/QUIC "PUSH_PROMISE" frame on a 142 server-initiated unidirectional stream. 144 A client that has sent the "SETTINGS_ENABLE_UNBOUND_PUSH" parameter 145 set to 1, and received this parameter set to a value of 1, SHOULD be 146 ready for a server to send an HTTP/QUIC "PUSH_PROMISE" frame at any 147 time during the connection. 149 4. 0-RTT Considerations 151 Client 0-RTT is not affected by server push configuration. There are 152 no additional consideration to be made beyond those defined in 153 [QUIC-HTTP]. 155 5. Handling Multiple Clients 157 Unbound server push was discussed during the development of HTTP/2 158 [RFC7540]. The assessment was that servers that handle multiple 159 clients within the same stack or context (such as an HTTP 160 intermediary) may have a difficult time routing promises to the 161 correct client. The applicability of unbound server push should be 162 assessed and enabled where the risk of misdirected promises is 163 determined to be acceptable. 165 6. Security Considerations 167 There are believed to be no additional considerations beyond those 168 presented in [QUIC-HTTP]. 170 7. IANA Considerations 172 7.1. Registration of SETTINGS_ENABLE_UNBOUND_PUSH parameter 174 This document establishes an entry for the HTTP/QUIC Settings 175 Registry that is established by [QUIC-HTTP]. 177 Name: "SETTINGS_ENABLE_UNBOUND_PUSH" 179 Code: 0xTBD 181 Specification: This document 183 8. Normative References 185 [QUIC-HTTP] 186 Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over 187 QUIC", draft-ietf-quic-http-09 (work in progress). 189 [QUIC-TRANSPORT] 190 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 191 Multiplexed and Secure Transport", draft-ietf-quic- 192 transport-09 (work in progress). 194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 195 Requirement Levels", BCP 14, RFC 2119, 196 DOI 10.17487/RFC2119, March 1997, . 199 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 200 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 201 DOI 10.17487/RFC7540, May 2015, . 204 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 205 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 206 May 2017, . 208 Appendix A. Acknowledgements 210 The author would like to thank the following for review prior to 211 publication: Richard Bradbury. 213 Author's Address 215 Lucas Pardue 216 BBC Research & Development 218 Email: lucas.pardue@bbc.co.uk