idnits 2.17.1 draft-hurst-quic-http-data-offset-frame-01.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 (13 August 2021) is 986 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-17 ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hurst 3 Internet-Draft BBC Research & Development 4 Intended status: Experimental 13 August 2021 5 Expires: 14 February 2022 7 An Offset Extension Frame For HTTP/3 Data 8 draft-hurst-quic-http-data-offset-frame-01 10 Abstract 12 This document specifies an optional extension frame type for HTTP/3 13 that extends the functionality of the "DATA" frame type to include an 14 offset for the HTTP message payload. This is useful in situations 15 where the HTTP/3 exchange is taking place over an unreliable 16 transport mechanism. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 14 February 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 53 3. DATA_WITH_OFFSET Extension Frame . . . . . . . . . . . . . . 3 54 4. Realising HTTP Multipart Range Responses With HTTP/3 Binary 55 Framing . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. Response Headers . . . . . . . . . . . . . . . . . . . . 4 57 4.2. Usage of DATA_WITH_OFFSET frame with HTTP Range 58 Responses . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Negotiating Support For The DATA_WITH_OFFSET Frame . . . . . 6 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 8.2. Informative References . . . . . . . . . . . . . . . . . 8 65 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 66 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 8 67 B.1. Changes since 68 draft-hurst-quic-http-data-offset-frame-00 . . . . . . . 8 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 HTTP/3 [QUIC-HTTP] supports the transfer of HTTP semantics over the 74 QUIC transport protocol [RFC9000]. In a conventional HTTP/3 message 75 exchange, messages consist of a header field section sent as a single 76 "HEADERS" frame, an optional HTTP message payload sent as a series of 77 "DATA" frames, followed optionally by a trailer field section sent as 78 a single "HEADERS" frame. Each "DATA" frame does not describe its 79 position within the HTTP message payload; rather this is calculated 80 from the position within the QUIC stream minus the overhead from 81 HTTP/3 frame headers and the contents of the header field section. 83 In the case where the message exchange is taking place across a 84 partially reliable or unreliable profile of [RFC9000], packet loss 85 could result in a lack of synchronisation in the receiver between the 86 perceived HTTP/3 "DATA" frame offset and the QUIC "STREAM" frame 87 offset, potentially resulting in a corrupt HTTP representation at the 88 receiver. 90 In addition, there are other use cases, such as HTTP multipart range 91 requests, where the HTTP/3 payload offset has no direct mapping to 92 the value calculated by the method described above. 94 This document introduces an extension frame type "DATA_WITH_OFFSET" 95 which can be used to explicitly signal the offset in the original 96 representation of the data being conveyed within the frame. 98 2. Conventions and Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 This document uses the variable-length integer encoding from 107 [RFC9000]. The packet and frame diagrams in this document use the 108 bespoke format specified in [RFC9000]. 110 3. DATA_WITH_OFFSET Extension Frame 112 Based on the "DATA" frame defined in [QUIC-HTTP], the 113 "DATA_WITH_OFFSET" frame conveys arbitrary, variable-length sequences 114 of bytes at a defined offset of an HTTP representation. By carrying 115 an explicit payload offset in the HTTP/3 frame header, the HTTP 116 message payload offset is decoupled from the QUIC "STREAM" frame 117 header offset value. The additional payload offset field takes the 118 form of a variable-length integer, as shown in Figure 1 below. 120 DATA_WITH_OFFSET Frame { 121 Type (i) = 0xd00, 122 Length (i), 123 Offset (i), 124 Data (..), 125 } 127 Figure 1: DATA_WITH_OFFSET Frame 129 If its peer has indicated support for the "DATA_WITH_OFFSET" 130 extension frame type (as described in Section 5 below) a sender MAY 131 choose to use either "DATA" frames or "DATA_WITH_OFFSET" frames to 132 transmit an HTTP representation. Senders MUST NOT mix the use of 133 "DATA" and "DATA_WITH_OFFSET" frames on the same QUIC stream (i.e. in 134 the same HTTP message). 136 *Author's Note:* The author welcomes comments about relaxation of 137 the requirement to not mix the usage of "DATA" and 138 "DATA_WITH_OFFSET" frames in the same HTTP message. 140 [QUIC-HTTP] defines three stream types: control stream, request 141 stream and push stream. The "DATA_WITH_OFFSET" frame is only 142 permitted to appear on request streams and push streams. A 143 "DATA_WITH_OFFSET" frame MUST NOT appear on control streams. If a 144 "DATA_WITH_OFFSET" frame is received on a control stream, the 145 recipient MUST respond with a connection error of type 146 "H3_FRAME_UNEXPECTED", as described in [QUIC-HTTP]. 148 The purpose of the "DATA_WITH_OFFSET" frame is only to assist in 149 locating a particular slice of data carried as part of an HTTP 150 message payload, and not as a means to send data out of order. 151 Senders MUST send data in order, i.e. with increasing values in the 152 Offset field. In cases where the underlying transport does not 153 guarantee in-order delivery of HTTP/3 frames, the receiver MUST be 154 prepared to deal with out-of-order reception of "DATA_WITH_OFFSET" 155 frames. 157 4. Realising HTTP Multipart Range Responses With HTTP/3 Binary Framing 159 HTTP Range Requests, described in [HTTP-SEMANTICS], is an optional 160 feature of HTTP that allows a client to request transfer of one or 161 more subranges of a given representation. Despite the move to binary 162 framing for HTTP in [RFC7540] and subsequently [QUIC-HTTP], multiple 163 part HTTP Range Requests still rely on textual encoding - including 164 boundary strings - which is inefficient. These boundary strings then 165 preface additional HTTP headers for each body part, which always 166 carry a "Content-Range" field, and may additionally carry a "Content- 167 Type" field which is likely to be repeated across every body part. 168 It is not possible to compress these headers using [QUIC-QPACK]. 170 By using the "DATA_WITH_OFFSET" frame described in Section 3, the 171 network efficiency of multiple part range requests is improved by no 172 longer needing to encode a boundary string into the representation 173 response. Instead, the offset of each part of a representation is 174 simply encoded in the header of a fresh HTTP "DATA_WITH_OFFSET" 175 frame. 177 4.1. Response Headers 179 [HTTP-SEMANTICS] specifies how a server may respond to an HTTP 180 multipart range request using the 206 (Partial Content) status code. 181 The response message carries a "Content-Type" response header 182 indicating the "multipart/byteranges" media type with its required 183 boundary parameter. This boundary parameter allows each body part to 184 carry its own header area containing a "Content-Range" header to 185 describe what range of the selected representation this body part 186 conveys, as well as a "Content-Type" header (if applicable) which 187 describes the actual media type of the selected representation. 189 (Note that section 14.2 of [HTTP-SEMANTICS] describes several reasons 190 why a server may choose to deliver a different selection of parts 191 than what the client originally requested.) 193 Because a selected representation may only contain a single "Content- 194 Type" header field with a single value, repeating this header field 195 in every body part is highly inefficient. Moreover, the unbounded 196 length of the boundary parameter further reduces transmission 197 efficiency. 199 This specification modifies the syntax of the "Content-Range" header 200 and explicitly defines it as a list-based field as per section 5.6.1 201 of [HTTP-SEMANTICS] that is carried in the first "HEADERS" block sent 202 as part of an HTTP/3 response. In addition, when used on the same 203 QUIC stream as "DATA_WITH_OFFSET" frames, this specification permits 204 the "Content-Range" and "Content-Type" HTTP headers to appear in the 205 "HEADERS" frame of a 206 (Partial Content) response, enabling it to 206 indicate the MIME media type of the whole representation without 207 needing to duplicate it for each body part. 209 Content-Range = 1#range-item 210 range-item = range-unit SP 211 ( range-resp / unsatisfied-range ) 213 range-resp = incl-range "/" ( complete-length / "*" ) 214 incl-range = first-pos "-" last-pos 215 unsatisfied-range = "*/" complete-length 217 complete-length = 1*DIGIT 219 Figure 2: ABNF for extended Content-Range 221 :status = 206 222 content-type = video/mp4 223 content-range = bytes 10000-17999/18879543, bytes 24000-41999/18879543 225 Figure 3: Range-Response header example 227 Implementations advertising support for the "DATA_WITH_OFFSET" frame 228 as described in Section 5 MUST be able to consume this overloaded 229 form of the "Content-Range" HTTP response header. 231 A server MAY continue to use the method described in [HTTP-SEMANTICS] 232 even if a client has expressed support for the "DATA_WITH_OFFSET" 233 frame. 235 *Author's Note:* Is it possibly worth splitting this out into its 236 own HTTP setting value? 238 4.2. Usage of DATA_WITH_OFFSET frame with HTTP Range Responses 240 The "DATA_WITH_OFFSET" frame may be used in conjunction with HTTP 241 Range Requests, as described in [HTTP-SEMANTICS]. When carrying data 242 for a byte range response, the Offset field in the frame header MUST 243 reflect the starting byte position of the frame's payload in the HTTP 244 representation and not the offset within the HTTP/3 exchange. For 245 example, for an HTTP/3 range request made with a request header of 246 "range: bytes=1000-1999", the first "DATA_WITH_OFFSET" frame in the 247 response MUST carry the value 1000 in the Offset field of the frame 248 header. 250 For HTTP response messages carrying a set of byte ranges, a 251 "DATA_WITH_OFFSET" frame MUST NOT carry data for more than one 252 contiguous byte range within that set. An individual byte range MAY 253 be carried over multiple instances of the "DATA_WITH_OFFSET" frame. 255 5. Negotiating Support For The DATA_WITH_OFFSET Frame 257 The "DATA_WITH_OFFSET" frame described in Section 3 is an optional 258 extension to the regular HTTP/3 protocol specification and, as such, 259 usage of the frame type must be negotiated as described in section 9 260 of [QUIC-HTTP]. For a conventional HTTP/3 connection, this is done 261 using HTTP/3 "SETTINGS" frames carried on the control streams. 263 This specification defines the following setting: 265 SETTINGS_ENABLE_DATA_WITH_OFFSET_FRAME (0xd00): A boolean value with 266 a default value of 0 (false). Any non-zero value is true. 268 *Author's Note:* It is intended that the value of the H3 269 "SETTINGS" frame should mirror the value of the frame to indicate 270 which version of the "DATA_WITH_OFFSET" frame it understands, 271 should subsequent revisions of this draft change the frame type. 273 An endpoint that implements this specification SHOULD send a 274 "SETTINGS_ENABLE_DATA_WITH_OFFSET_FRAME" setting at the beginning of 275 the connection to indicate that it is able to process 276 "DATA_WITH_OFFSET" frames from its peer. 278 An endpoint MUST NOT send a "DATA_WITH_OFFSET" frame unless it has 279 received a positive (i.e. non-zero) 280 "SETTINGS_ENABLE_DATA_WITH_OFFSET_FRAME" setting from its peer. 282 6. Security Considerations 284 This document introduces no new security considerations beyond those 285 discussed in [QUIC-HTTP]. 287 7. IANA Considerations 289 This specification registers a new frame type in the "HTTP/3 Frame 290 Type" registry ([QUIC-HTTP]). 292 +==================+=======+===============+ 293 | Frame Type | Value | Specification | 294 +==================+=======+===============+ 295 | DATA_WITH_OFFSET | 0xd00 | Section 3 | 296 +------------------+-------+---------------+ 298 Table 1: Registered HTTP/3 Frame Type 300 *Author's Note:* The final, intended value of the frame type is 301 0xd0f, but in order to allow for this extension to naturally 302 evolve and allow for the frame format to change, it starts at 303 0xd00 and subsequent revisions of this extension can take 304 incrementally higher frame type values between 0xd00 and 0xd0e. 306 This specification registers a new setting in the "HTTP/3 Settings" 307 registry ([QUIC-HTTP]). 309 +=======================================+=====+=============+=======+ 310 |Setting |Value|Specification|Default| 311 +=======================================+=====+=============+=======+ 312 |SETTINGS_ENABLE_DATA_WITH_OFFSET_FRAME |0xd00|Section 5 |0 | 313 +---------------------------------------+-----+-------------+-------+ 315 Table 2: Registered HTTP/3 Settings 317 8. References 319 8.1. Normative References 321 [HTTP-SEMANTICS] 322 Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 323 Ed., "HTTP Semantics", Work in Progress, Internet-Draft, 324 draft-ietf-httpbis-semantics-17, 325 . 328 [QUIC-HTTP] 329 Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 330 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 331 quic-http-34, . 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, 336 DOI 10.17487/RFC2119, March 1997, 337 . 339 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 340 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 341 DOI 10.17487/RFC7540, May 2015, 342 . 344 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 345 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 346 May 2017, . 348 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 349 Multiplexed and Secure Transport", RFC 9000, 350 DOI 10.17487/RFC9000, May 2021, 351 . 353 8.2. Informative References 355 [QUIC-QPACK] 356 Crasic, C., Ed., Bishop, M., Ed., and A. Frindell, Ed., 357 "QPACK: Header Compression for HTTP/3", Work in Progress, 358 Internet-Draft, draft-ietf-quic-qpack-21, 359 . 362 Appendix A. Acknowledgements 364 The author would like to thank the following for their contributions 365 to the design described in the present document: Lucas Pardue, 366 Richard Bradbury and David Waring. 368 I am also grateful for Chris Poole's helpful review comments. 370 Appendix B. Changelog 372 *RFC Editor's Note:* Please remove this section prior to 373 publication of a final version of this document. 375 B.1. Changes since draft-hurst-quic-http-data-offset-frame-00 377 * Update reference to QUIC transport I-D to [RFC9000]. 379 * Update reference to [HTTP-SEMANTICS] I-D. 381 Author's Address 383 Sam Hurst 384 BBC Research & Development 386 Email: sam.hurst@bbc.co.uk