idnits 2.17.1 draft-ietf-httpbis-binary-message-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 : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 November 2021) is 884 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 (-07) exists of draft-ietf-httpbis-http2bis-06 -- Possible downref: Normative reference to a draft: ref. 'HTTP' -- Possible downref: Normative reference to a draft: ref. 'MESSAGING' -- Obsolete informational reference (is this intentional?): RFC 2518 (Obsoleted by RFC 4918) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track C.A. Wood 5 Expires: 28 May 2022 Cloudflare 6 24 November 2021 8 Binary Representation of HTTP Messages 9 draft-ietf-httpbis-binary-message-00 11 Abstract 13 This document defines a binary format for representing HTTP messages. 15 Discussion Venues 17 This note is to be removed before publishing as an RFC. 19 Discussion of this document takes place on the HTTP Working Group 20 mailing list (ietf-http-wg@w3.org), which is archived at 21 https://lists.w3.org/Archives/Public/ietf-http-wg/. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 28 May 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 58 3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Known Length Messages . . . . . . . . . . . . . . . . . . 3 60 3.2. Indeterminate Length Messages . . . . . . . . . . . . . . 5 61 3.3. Framing Indicator . . . . . . . . . . . . . . . . . . . . 6 62 3.4. Request Control Data . . . . . . . . . . . . . . . . . . 6 63 3.5. Response Control Data . . . . . . . . . . . . . . . . . . 7 64 3.5.1. Informational Status Codes . . . . . . . . . . . . . 7 65 3.6. Header and Trailer Field Lines . . . . . . . . . . . . . 8 66 3.7. Content . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 4. Invalid Messages . . . . . . . . . . . . . . . . . . . . . . 9 68 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. Request Example . . . . . . . . . . . . . . . . . . . . . 9 70 5.2. Response Example . . . . . . . . . . . . . . . . . . . . 11 71 6. "message/bhttp" Media Type . . . . . . . . . . . . . . . . . 13 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 76 9.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 This document defines a simple format for representing an HTTP 83 message ([HTTP]), either request or response. This allows for the 84 encoding of HTTP messages that can be conveyed outside of an HTTP 85 protocol. This enables the transformation of entire messages, 86 including the application of authenticated encryption. 88 This format is informed by the framing structure of HTTP/2 ([H2]) and 89 HTTP/3 ([H3]). In comparison, this format simpler by virtue of not 90 including either header compression ([HPACK], [QPACK]) or a generic 91 framing layer. 93 This format provides an alternative to the message/http content type 94 defined in [MESSAGING]. A binary format permits more efficient 95 encoding and processing of messages. A binary format also reduces 96 exposure to security problems related to processing of HTTP messages. 98 Two modes for encoding are described: 100 * a known-length encoding includes length prefixes for all major 101 message components; and 103 * an indefinite-length encoding enables efficient generation of 104 messages where lengths are not known when encoding starts. 106 2. Conventions and Definitions 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in 111 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 This document uses terminology from HTTP ([HTTP]) and notation from 115 QUIC (Section 1.3 of [QUIC]). 117 3. Format 119 Section 6 of [HTTP] defines five distinct parts to HTTP messages. A 120 framing indicator is added to signal how these parts are composed: 122 1. Framing indicator. This format uses a single integer to describe 123 framing, which describes whether the message is a request or 124 response and how subsequent sections are formatted; see 125 Section 3.3. 127 2. For a response, any number of interim responses, each consisting 128 of an informational status code and header section. 130 3. Control data. For a request, this contains the request method 131 and target. For a response, this contains the status code. 133 4. Header section. This contains zero or more header fields. 135 5. Content. This is a sequence of zero or more bytes. 137 6. Trailer section. This contains zero or more trailer fields. 139 All lengths and numeric values are encoded using the variable-length 140 integer encoding from Section 16 of [QUIC]. 142 3.1. Known Length Messages 144 A message that has a known length at the time of construction uses 145 the format shown in Figure 1. 147 Message with Known-Length { 148 Framing Indicator (i) = 0..1, 149 Known-Length Informational Response (..) ..., 150 Control Data (..), 151 Known-Length Field Section (..), 152 Known-Length Content (..), 153 Known-Length Field Section (..), 154 } 156 Known-Length Field Section { 157 Length (i) = 2.., 158 Field Line (..) ..., 159 } 161 Known-Length Content { 162 Content Length (i), 163 Content (..) 164 } 166 Known-Length Informational Response { 167 Informational Response Control Data (..), 168 Known-Length Field Section (..), 169 } 171 Figure 1: Known-Length Message 173 That is, a known-length message consists of a framing indicator, a 174 block of control data that is formatted according to the value of the 175 framing indicator, a header section with a length prefix, binary 176 content with a length prefix, and a trailer section with a length 177 prefix. 179 Response messages that contain informational status codes result in a 180 different structure; see Section 3.5.1. 182 Fields in the header and trailer sections consist of a length- 183 prefixed name and length-prefixed value. Both name and value are 184 sequences of bytes that cannot be zero length. 186 The format allows for the message to be truncated before any of the 187 length prefixes that precede the field sections or content. This 188 reduces the overall message size. A message that is truncated at any 189 other point is invalid; see Section 4. 191 The variable-length integer encoding means that there is a limit of 192 2^62-1 bytes for each field section and the message content. 194 3.2. Indeterminate Length Messages 196 A message that is constructed without encoding a known length for 197 each section uses the format shown in Figure 2: 199 Indeterminate-Length Message { 200 Framing Indicator (i) = 2..3, 201 Indeterminate-Length Informational Response (..) ..., 202 Control Data (..), 203 Indeterminate-Length Field Section (..), 204 Indeterminate-Length Content (..) ..., 205 Indeterminate-Length Field Section (..), 206 } 208 Indeterminate-Length Content { 209 Indeterminate-Length Content Chunk (..) ..., 210 Content Terminator (i) = 0, 211 } 213 Indeterminate-Length Content Chunk { 214 Chunk Length (i) = 1.., 215 Chunk (..) 216 } 218 Indeterminate-Length Field Section { 219 Field Line (..) ..., 220 Content Terminator (i) = 0, 221 } 223 Indeterminate-Length Informational Response { 224 Informational Response Control Data (..), 225 Indeterminate-Length Field Section (..), 226 } 228 Figure 2: Indeterminate-Length Message 230 That is, an indeterminate length consists of a framing indicator, a 231 block of control data that is formatted according to the value of the 232 framing indicator, a header section that is terminated by a zero 233 value, any number of non-zero-length chunks of binary content, a zero 234 value, and a trailer section that is terminated by a zero value. 236 Response messages that contain informational status codes result in a 237 different structure; see Section 3.5.1. 239 Indeterminate-length messages can be truncated in a similar way as 240 known-length messages. Truncation occurs after the control data, or 241 after the Content Terminator field that ends a field section or 242 sequence of content chunks. A message that is truncated at any other 243 point is invalid; see Section 4. 245 Indeterminate-length messages use the same encoding for field lines 246 as known-length messages; see Section 3.6. 248 3.3. Framing Indicator 250 The start of each is a framing indicator that is a single integer 251 that describes the structure of the subsequent sections. The framing 252 indicator can take just four values: 254 * A value of 0 describes a request of known length. 256 * A value of 1 describes a response of known length. 258 * A value of 2 describes a request of indeterminate length. 260 * A value of 3 describes a response of indeterminate length. 262 Other values cause the message to be invalid; see Section 4. 264 3.4. Request Control Data 266 The control data for a request message includes four values that 267 correspond to the values of the :method, :scheme, :authority, and 268 :path pseudo-header fields described in HTTP/2 (Section 8.3.1 of 269 [H2]). These fields are encoded, each with a length prefix, in the 270 order listed. 272 The rules in Section 8.3 of [H2] for constructing pseudo-header 273 fields apply to the construction of these values. However, where the 274 :authority pseudo-header field might be omitted in HTTP/2, a zero- 275 length value is encoded instead. 277 The format of request control data is shown in Figure 3. 279 Request Control Data { 280 Method Length (i), 281 Method (..), 282 Scheme Length (i), 283 Scheme (..), 284 Authority Length (i), 285 Authority (..), 286 Path Length (i), 287 Path (..), 288 } 290 Figure 3: Format of Request Control Data 292 3.5. Response Control Data 294 The control data for a request message includes a single field that 295 corresponds to the :status pseudo-header field in HTTP/2; see 296 Section 8.3.2 of [H2]. This field is encoded as a single variable 297 length integer, not a decimal string. 299 The format of final response control data is shown in Figure 4. 301 Final Response Control Data { 302 Status Code (i) = 200..599, 303 } 305 Figure 4: Format of Final Response Control Data 307 3.5.1. Informational Status Codes 309 Responses that include information status codes (see Section 15.2 of 310 [HTTP]) are encoded by repeating the response control data and 311 associated header section until the final status code is encoded. 313 The format of the informational response control data is shown in 314 Figure 5. 316 Informational Response Control Data { 317 Status Code (i) = 100..199, 318 } 320 Figure 5: Format of Informational Response Control Data 322 A response message can include any number of informational responses. 323 If the response control data includes an informational status code 324 (that is, a value between 100 and 199 inclusive), the control data is 325 followed by a header section (encoded with known- or indeterminate- 326 length according to the framing indicator). After the header 327 section, another response control data block follows. 329 3.6. Header and Trailer Field Lines 331 Header and trailer sections consist of zero or more field lines; see 332 Section 5 of [HTTP]. The format of a field section depends on 333 whether the message is known- or intermediate-length. 335 Each field line includes a name and a value. Both the name and value 336 are sequences of bytes, with the name including at least one byte. 337 The format of a field line is shown in Figure 6. 339 Field Line { 340 Name Length (i) = 1.., 341 Name (..), 342 Value Length (i), 343 Value (..), 344 } 346 Figure 6: Format of a Field Line 348 For field names, byte values that are not permitted in an HTTP field 349 name cause the message to be invalid; see Section 5.1 of [HTTP] for a 350 definition of what is valid and Section 4 for handling of invalid 351 messages. 353 Field names and values MUST be constructed and validated according to 354 the rules of Section 8.2.1 of [H2]. A recipient MUST treat a message 355 that contains field values that would cause an HTTP/2 message to be 356 malformed (Section 8.1.1 of [H2]) as invalid; see Section 4. 358 The same field name can be repeated in multiple field lines; see 359 Section 5.2 of [HTTP] for the semantics of repeated field names and 360 rules for combining values. 362 Like HTTP/2, this format has an exception for the combination of 363 multiple instances of the Cookie field. Instances of fields with the 364 ASCII-encoded value of cookie are combined using a semicolon octet 365 (0x3b) rather than a comma; see Section 8.2.3 of [H2]. 367 This format provides fixed locations for content that would be 368 carried in HTTP/2 pseudo-fields. Therefore, there is no need to 369 include field lines containing a name of :method, :scheme, 370 :authority, :path, or :status. Fields that contain one of these 371 names cause the message to be invalid; see Section 4. Pseudo-fields 372 that are defined by protocol extensions MAY be included. Field lines 373 containing pseudo-fields MUST precede other field lines; a message 374 that contains a pseudo-field after any other field is invalid; see 375 Section 4. 377 3.7. Content 379 The content of messages is a sequence of bytes of any length. Though 380 a known-length message has a limit, this limit is large enough that 381 it is unlikely to be a practical limitation. There is no limit to 382 the size of content in an indeterminate length message. 384 Omitting content by truncating a message is only possible if the 385 content is zero-length. 387 4. Invalid Messages 389 This document describes a number of ways that a message can be 390 invalid. Invalid messages MUST NOT be processed except to log an 391 error and produce an error response. 393 The format is designed to allow incremental processing. 394 Implementations need to be aware of the possibility that an error 395 might be detected after performing incremental processing. 397 5. Examples 399 This section includes example requests and responses encoded in both 400 known-length and indefinite-length forms. 402 5.1. Request Example 404 The example HTTP/1.1 message in Figure 7 shows the content of a 405 message/http. 407 Valid HTTP/1.1 messages require lines terminated with CRLF (the two 408 bytes 0x0a and 0x0d). For simplicity and consistency, the content of 409 these examples is limited to text, which also uses CRLF for line 410 endings. 412 GET /hello.txt HTTP/1.1 413 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 414 Host: www.example.com 415 Accept-Language: en, mi 417 Figure 7: Sample HTTP Request 419 This can be expressed as a binary message (type message/bhttp) using 420 a known-length encoding as shown in hexadecimal in Figure 8. 421 Figure 8 view includes some of the text alongside to show that most 422 of the content is not modified. 424 00034745 54056874 74707300 0a2f6865 ..GET.https../he 425 6c6c6f2e 74787440 6c0a7573 65722d61 llo.txt@l.user-a 426 67656e74 34637572 6c2f372e 31362e33 gent4curl/7.16.3 427 206c6962 6375726c 2f372e31 362e3320 libcurl/7.16.3 428 4f70656e 53534c2f 302e392e 376c207a OpenSSL/0.9.7l z 429 6c69622f 312e322e 3304686f 73740f77 lib/1.2.3.host.w 430 77772e65 78616d70 6c652e63 6f6d0f61 ww.example.com.a 431 63636570 742d6c61 6e677561 67650665 ccept-language.e 432 6e2c206d 690000 n, mi.. 434 Figure 8: Known-Length Binary Encoding of Request 436 This example shows that the Host header field is not replicated in 437 the :authority field, as is required for ensuring that the request is 438 reproduced accurately; see Section 8.3.1 of [H2]. 440 The same message can be truncated with no effect on interpretation. 441 In this case, the last two bytes - corresponding to content and a 442 trailer section - can each be removed without altering the semantics 443 of the message. 445 The same message, encoded using an indefinite-length encoding is 446 shown in Figure 9. As the content of this message is empty, the 447 difference in formats is negligible. 449 02034745 54056874 74707300 0a2f6865 ..GET.https../he 450 6c6c6f2e 7478740a 75736572 2d616765 llo.txt.user-age 451 6e743463 75726c2f 372e3136 2e33206c nt4curl/7.16.3 l 452 69626375 726c2f37 2e31362e 33204f70 ibcurl/7.16.3 Op 453 656e5353 4c2f302e 392e376c 207a6c69 enSSL/0.9.7l zli 454 622f312e 322e3304 686f7374 0f777777 b/1.2.3.host.www 455 2e657861 6d706c65 2e636f6d 0f616363 .example.com.acc 456 6570742d 6c616e67 75616765 06656e2c ept-language.en, 457 206d6900 0000 mi... 459 Figure 9: Indefinite-Length Binary Encoding of Request 461 This indefinite-length encoding can be truncated by two bytes in the 462 same way. 464 5.2. Response Example 466 Response messages can contain interim (1xx) status codes as the 467 message in Figure 10 shows. Figure 10 includes examples of 468 informational status codes defined in [RFC2518] and [RFC8297]. 470 HTTP/1.1 102 Processing 471 Running: "sleep 15" 473 HTTP/1.1 103 Early Hints 474 Link: ; rel=preload; as=style 475 Link: ; rel=preload; as=script 477 HTTP/1.1 200 OK 478 Date: Mon, 27 Jul 2009 12:28:53 GMT 479 Server: Apache 480 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT 481 ETag: "34aa387-d-1568eb00" 482 Accept-Ranges: bytes 483 Content-Length: 51 484 Vary: Accept-Encoding 485 Content-Type: text/plain 487 Hello World! My content includes a trailing CRLF. 489 Figure 10: Sample HTTP Response 491 As this is a longer example, only the indefinite-length encoding is 492 shown in Figure 11. Note here that the specific text used in the 493 reason phrase is not retained by this encoding. 495 03406607 72756e6e 696e670a 22736c65 .@f.running."sle 496 65702031 35220040 67046c69 6e6b233c ep 15".@g.link#< 497 2f737479 6c652e63 73733e3b 2072656c /style.css>; rel 498 3d707265 6c6f6164 3b206173 3d737479 =preload; as=sty 499 6c65046c 696e6b24 3c2f7363 72697074 le.link$; rel=preloa 501 643b2061 733d7363 72697074 0040c804 d; as=script.@.. 502 64617465 1d4d6f6e 2c203237 204a756c date.Mon, 27 Jul 503 20323030 39203132 3a32383a 35332047 2009 12:28:53 G 504 4d540673 65727665 72064170 61636865 MT.server.Apache 505 0d6c6173 742d6d6f 64696669 65641d57 .last-modified.W 506 65642c20 3232204a 756c2032 30303920 ed, 22 Jul 2009 507 31393a31 353a3536 20474d54 04657461 19:15:56 GMT.eta 508 67142233 34616133 38372d64 2d313536 g."34aa387-d-156 509 38656230 30220d61 63636570 742d7261 8eb00".accept-ra 510 6e676573 05627974 65730e63 6f6e7465 nges.bytes.conte 511 6e742d6c 656e6774 68023531 04766172 nt-length.51.var 512 790f4163 63657074 2d456e63 6f64696e y.Accept-Encodin 513 670c636f 6e74656e 742d7479 70650a74 g.content-type.t 514 6578742f 706c6169 6e003348 656c6c6f ext/plain.3Hello 515 20576f72 6c642120 4d792063 6f6e7465 World! My conte 516 6e742069 6e636c75 64657320 61207472 nt includes a tr 517 61696c69 6e672043 524c462e 0d0a0000 ailing CRLF..... 519 Figure 11: Binary Response including Interim Responses 521 A response that uses the chunked encoding (see Section 7.1 of 522 [MESSAGING]) as shown for Figure 12 can be encoded using indefinite- 523 length encoding, which minimizes buffering needed to translate into 524 the binary format. However, chunk boundaries do not need to be 525 retained and any chunk extensions cannot be conveyed using the binary 526 format. 528 HTTP/1.1 200 OK 529 Transfer-Encoding: chunked 531 4 532 This 533 6 534 conte 535 13;chunk-extension=foo 536 nt contains CRLF. 538 0 539 Trailer: text 541 Figure 12: Chunked Encoding Example 543 Figure 13 shows this message using the known-length coding. Note 544 that the transfer-encoding header field is removed. 546 0140c800 1d546869 7320636f 6e74656e .@...This conten 547 7420636f 6e746169 6e732043 524c462e t contains CRLF. 548 0d0a0d07 74726169 6c657204 74657874 ....trailer.text 550 Figure 13: Known-Length Encoding of Response 552 6. "message/bhttp" Media Type 554 The message/http media type can be used to enclose a single HTTP 555 request or response message, provided that it obeys the MIME 556 restrictions for all "message" types regarding line length and 557 encodings. 559 Type name: message 561 Subtype name: bhttp 563 Required parameters: N/A 565 Optional parameters: None 567 Encoding considerations: only "8bit" or "binary" is permitted 569 Security considerations: see Section 7 571 Interoperability considerations: N/A 573 Published specification: this specification 575 Applications that use this media type: N/A 577 Fragment identifier considerations: N/A 579 Additional information: Magic number(s): N/A 581 Deprecated alias names for this type: N/A 583 File extension(s): N/A 585 Macintosh file type code(s): N/A 587 Person and email address to contact for further information: see Aut 588 hors' Addresses section 590 Intended usage: COMMON 591 Restrictions on usage: N/A 593 Author: see Authors' Addresses section 595 Change controller: IESG 597 7. Security Considerations 599 Many of the considerations that apply to HTTP message handling apply 600 to this format; see Section 17 of [HTTP] and Section 11 of 601 [MESSAGING] for common issues in handling HTTP messages. 603 Strict parsing of the format with no tolerance for errors can help 604 avoid a number of attacks. However, implementations still need to be 605 aware of the possibility of resource exhaustion attacks that might 606 arise from receiving large messages, particularly those with large 607 numbers of fields. 609 The format is designed to allow for minimal state when translating 610 for use with HTTP proper. However, producing a combined value for 611 fields, which might be necessary for the Cookie field when 612 translating this format (like HTTP/1.1 [MESSAGING]), can require the 613 commitment of resources. Implementations need to ensure that they 614 aren't subject to resource exhaustion attack from a maliciously 615 crafted message. 617 8. IANA Considerations 619 Please add the "Media Types" registry at 620 https://www.iana.org/assignments/media-types 621 (https://www.iana.org/assignments/media-types) with the registration 622 information in Section 6 for the media type "message/bhttp". 624 9. References 626 9.1. Normative References 628 [H2] Thomson, M. and C. Benfield, "Hypertext Transfer Protocol 629 Version 2 (HTTP/2)", Work in Progress, Internet-Draft, 630 draft-ietf-httpbis-http2bis-06, 18 November 2021, 631 . 634 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 635 Semantics", Work in Progress, Internet-Draft, draft-ietf- 636 httpbis-semantics-19, 12 September 2021, 637 . 640 [MESSAGING] 641 Fielding, R. T., Nottingham, M., and J. Reschke, 642 "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- 643 httpbis-messaging-19, 12 September 2021, 644 . 647 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 648 Multiplexed and Secure Transport", RFC 9000, 649 DOI 10.17487/RFC9000, May 2021, 650 . 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, 654 DOI 10.17487/RFC2119, March 1997, 655 . 657 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 658 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 659 May 2017, . 661 9.2. Informative References 663 [H3] Bishop, M., "Hypertext Transfer Protocol Version 3 664 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 665 quic-http-34, 2 February 2021, 666 . 669 [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for 670 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 671 . 673 [QPACK] Krasic, C. '., Bishop, M., and A. Frindell, "QPACK: Header 674 Compression for HTTP/3", Work in Progress, Internet-Draft, 675 draft-ietf-quic-qpack-21, 2 February 2021, 676 . 679 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 680 Jensen, "HTTP Extensions for Distributed Authoring -- 681 WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999, 682 . 684 [RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints", 685 RFC 8297, DOI 10.17487/RFC8297, December 2017, 686 . 688 Acknowledgments 690 TODO: credit where credit is due. 692 Authors' Addresses 694 Martin Thomson 695 Mozilla 697 Email: mt@lowentropy.net 699 Christopher A. Wood 700 Cloudflare 702 Email: caw@heapingbits.net