idnits 2.17.1 draft-vvv-webtransport-http3-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([HTTP3], [OVERVIEW]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (June 30, 2020) is 1397 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 (-05) exists of draft-schinazi-quic-h3-datagram-04 ** Downref: Normative reference to an Experimental draft: draft-schinazi-quic-h3-datagram (ref. 'H3-DATAGRAM') -- No information found for draft-ietf-webtrans-overview-latest - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'OVERVIEW' ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Vasiliev 3 Internet-Draft Google 4 Intended status: Standards Track June 30, 2020 5 Expires: January 1, 2021 7 WebTransport over HTTP/3 8 draft-vvv-webtransport-http3-02 10 Abstract 12 WebTransport [OVERVIEW] is a protocol framework that enables clients 13 constrained by the Web security model to communicate with a remote 14 server using a secure multiplexed transport. This document describes 15 Http3Transport, a WebTransport protocol that is based on HTTP/3 16 [HTTP3] and provides support for unidirectional streams, 17 bidirectional streams and datagrams, all multiplexed within the same 18 HTTP/3 connection. 20 Note to Readers 22 Discussion of this draft takes place on the WebTransport mailing list 23 (webtransport@ietf.org), which is archived at 24 . 26 The repository tracking the issues for this draft can be found at 27 . The web API draft 28 corresponding to this document can be found at 29 . 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 1, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Session IDs . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 4 70 4.1. Establishing a Transport-Capable HTTP/3 Connection . . . 4 71 4.2. Extended CONNECT in HTTP/3 . . . . . . . . . . . . . . . 5 72 4.3. Creating a New Session . . . . . . . . . . . . . . . . . 5 73 4.4. Limiting the Number of Simultaneous Sessions . . . . . . 6 74 5. WebTransport Features . . . . . . . . . . . . . . . . . . . . 6 75 5.1. Unidirectional streams . . . . . . . . . . . . . . . . . 6 76 5.2. Client-Initiated Bidirectional Streams . . . . . . . . . 7 77 5.3. Server-Initiated Bidirectional Streams . . . . . . . . . 7 78 5.4. Datagrams . . . . . . . . . . . . . . . . . . . . . . . . 8 79 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 8 80 7. Transport Properties . . . . . . . . . . . . . . . . . . . . 8 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 83 9.1. Upgrade Token Registration . . . . . . . . . . . . . . . 9 84 9.2. QUIC Transport Parameter Registration . . . . . . . . . . 10 85 9.3. Frame Type Registration . . . . . . . . . . . . . . . . . 10 86 9.4. Stream Type Registration . . . . . . . . . . . . . . . . 10 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 89 10.2. Informative References . . . . . . . . . . . . . . . . . 12 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 HTTP/3 [HTTP3] is a protocol defined on top of QUIC [QUIC-TRANSPORT] 95 that can multiplex HTTP requests over a QUIC connection. This 96 document defines Http3Transport, a mechanism for multiplexing non- 97 HTTP data with HTTP/3 in a manner that conforms with the WebTransport 98 protocol framework [OVERVIEW]. Using the mechanism described here, 99 multiple Http3Transport instances can be multiplexed simultaneously 100 with regular HTTP traffic on the same HTTP/3 connection. 102 1.1. Terminology 104 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 This document follows terminology defined in Section 1.2 of 111 [OVERVIEW]. Note that this document distinguishes between a 112 WebTransport server and an HTTP/3 server. An HTTP/3 server is the 113 server that terminates HTTP/3 connections; a WebTransport server is 114 an application that accepts WebTransport sessions, which can be 115 accessed via an HTTP/3 server. 117 2. Protocol Overview 119 Http3Transport servers are identified by a pair of authority value 120 and path value (defined in [RFC3986] Sections 3.2 and 3.3 121 correspondingly). 123 When an HTTP/3 connection is established, the client and server have 124 to negotiate a specific set of QUIC transport parameters that 125 indicate support for various Http3Transport features. Most notably, 126 the "http3_transport_support" parameter signals Http3Transport 127 support to the peer. 129 Http3Transport sessions are initiated inside a given HTTP/3 130 connection by the client, who sends an extended CONNECT request 131 [RFC8441]. If the server accepts the request, an Http3Transport 132 session is established. As a part of this process, the client 133 proposes, and the server confirms, a session ID. A session ID (SID) 134 is unique within a given HTTP/3 connection, and is used to associate 135 all of the streams and datagrams with the specific session. 137 After the session is established, the peers can exchange data using 138 the following mechanisms: 140 o A client can create a bidirectional stream using a special 141 indefinite-length HTTP/3 frame that transfers ownership of the 142 stream to Http3Transport. 144 o A server can create a bidirectional stream, which is possible 145 since HTTP/3 does not define any semantics for server-initiated 146 bidirectional streams. 148 o Both client and server can create a unidirectional stream using a 149 special stream type. 151 o A datagram can be sent using a QUIC DATAGRAM frame 152 [QUIC-DATAGRAM]. 154 An Http3Transport session is terminated when the CONNECT stream that 155 created it is closed. 157 3. Session IDs 159 In order to allow multiple Http3Transport sessions to occur within 160 the same HTTP/3 connection, Http3Transport assigns every session a 161 unique ID, further referred to as session ID. A session ID is a 162 62-bit number that is unique within the scope of an HTTP/3 163 connection, and is never reused even after the session is closed. 164 The client unilaterally picks the session ID. As the IDs are encoded 165 using QUIC variable length integers, the client SHOULD start with 166 zero and then sequentially increment the IDs. A session ID is 167 considered to be used, and thus ineligible for new transports, as 168 soon as the client sends a request proposing it. These reuse 169 requirements guarantee that both HTTP/3 endpoints have a consistent 170 view of the session ID space. 172 The Session ID is a hop-by-hop property: if Http3Transport is 173 proxied, the same session can have different IDs from the client's 174 and server's perspective. Because of that, session IDs SHOULD NOT be 175 exposed to the application. 177 4. Session Establishment 179 4.1. Establishing a Transport-Capable HTTP/3 Connection 181 In order to indicate support for Http3Transport, both the client and 182 server MUST send an empty "http3_transport_support" transport 183 parameter. Endpoints MUST NOT use any Http3Transport-related 184 functionality unless the parameter has been negotiated. The 185 negotiation is done through a QUIC transport parameter instead of an 186 HTTP/3-level setting as it allows the server to customize the 187 transport parameters it intends to send based on whether the client 188 has indicated support for Http3Transport. 190 If "http3_transport_support" is negotiated, support for the QUIC 191 DATAGRAM extension MUST be negotiated. The 192 "initial_max_bidi_streams" MUST be greater than zero, overriding the 193 existing requirement in [HTTP3]. 195 4.2. Extended CONNECT in HTTP/3 197 [RFC8441] defines an extended CONNECT method in Section 4, enabled by 198 the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter. That parameter is 199 only defined for HTTP/2. This document does not create a new multi- 200 purpose parameter to indicate support for extended CONNECT in HTTP/3; 201 instead, the "http3_transport_support" transport parameter implies 202 that an endpoint supports extended CONNECT. 204 4.3. Creating a New Session 206 As Http3Transport sessions are established over HTTP/3, they are 207 identified using the "https" URI scheme [RFC7230]. 209 In order to create a new Http3Transport session, a client can send an 210 HTTP CONNECT request. The ":protocol" pseudo-header field MUST be 211 set to "webtransport". The ":scheme" field MUST be "https". Both 212 the ":authority" and the ":path" value MUST be set; those fields 213 indicate the desired WebTransport server. The client MUST pick a new 214 session ID as described in Section 3 and send it encoded as a 215 hexadecimal literal in ":sessionid" header. An "Origin" header 216 [RFC6454] MUST be provided within the request. 218 Upon receiving an extended CONNECT request with a ":protocol" field 219 set to ":webtransport", the HTTP/3 server can check if it has a 220 WebTransport server associated with the specified ":authority" and 221 ":path" values. If it does not, it SHOULD reply with status code 404 222 (Section 6.5.4, [RFC7231]). If it does, it MAY accept the session by 223 replying with status code 200. Before accepting it, the HTTP/3 224 server MUST verify that the proposed session ID does not conflict 225 with any currently open sessions, and it MAY verify that it was not 226 used ever before on this connection. The WebTransport server MUST 227 verify the "Origin" header to ensure that the specified origin is 228 allowed to access the server in question. 230 From the client's perspective, an Http3Transport session is 231 established when the client receives a 200 response. From the 232 server's perspective, a session is established once it sends a 200 233 response. Both endpoints MUST NOT open any streams or send any 234 datagrams on a given session before that session is established. 235 Http3Transport does not support 0-RTT. 237 4.4. Limiting the Number of Simultaneous Sessions 239 From the flow control perspective, Http3Transport sessions count 240 against the stream flow control just like regular HTTP requests, 241 since they are established via an HTTP CONNECT request. This 242 document does not make any effort to introduce a separate flow 243 control mechanism for sessions, nor to separate HTTP requests from 244 WebTransport data streams. If the server needs to limit the rate of 245 incoming requests, it has alternative mechanisms at its disposal: 247 o "HTTP_REQUEST_REJECTED" error code defined in [HTTP3] indicates to 248 the receiving HTTP/3 stack that the request was not processed in 249 any way. 251 o HTTP status code 429 indicates that the request was rejected due 252 to rate limiting [RFC6585]. Unlike the previous method, this 253 signal is directly propagated to the application. 255 5. WebTransport Features 257 Http3Transport provides the following features described in 258 [OVERVIEW]: unidirectional streams, bidirectional streams and 259 datagrams, initiated by either endpoint. 261 Session IDs are used to demultiplex streams and datagrams belonging 262 to different Http3Transport sessions. On the wire, session IDs are 263 encoded using the QUIC variable length integer scheme described in 264 [QUIC-TRANSPORT]. 266 5.1. Unidirectional streams 268 Once established, both endpoints can open unidirectional streams. 269 The HTTP/3 control stream type SHALL be 0x54. The body of the stream 270 SHALL be the stream type, followed by the session ID, encoded as a 271 variable-length integer, followed by the user-specified stream data 272 (Figure 1). 274 0 1 2 3 275 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | 0x54 (i) ... 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Session ID (i) ... 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Stream Body ... 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Figure 1: Unidirectional Http3Transport stream format 286 5.2. Client-Initiated Bidirectional Streams 288 Http3Transport clients can initiate bidirectional streams by opening 289 an HTTP/3 bidirectional stream and sending an HTTP/3 frame with type 290 "WEBTRANSPORT_STREAM" (type=0x41). The format of the frame SHALL be 291 the frame type, followed by the session ID, encoded as a variable- 292 length integer, followed by the user-specified stream data 293 (Figure 2). The frame SHALL last until the end of the stream. 295 0 1 2 3 296 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | 0x41 (i) ... 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Session ID (i) ... 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Stream Body ... 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 2: WEBTRANSPORT_STREAM frame format 307 5.3. Server-Initiated Bidirectional Streams 309 Http3Transport servers can initiate bidirectional streams by opening 310 a bidirectional stream within the HTTP/3 connection. Note that since 311 HTTP/3 does not define any semantics for server-initiated 312 bidirectional streams, this document is a normative reference for the 313 semantics of such streams for all HTTP/3 connections in which the 314 "http3_transport_support" option is negotiated. The format of those 315 streams SHALL be the session ID, encoded as a variable-length 316 integer, followed by the user-specified stream data (Figure 3). 318 0 1 2 3 319 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Session ID (i) ... 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Stream Body ... 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Figure 3: Server-initiated bidirectional stream format 328 5.4. Datagrams 330 Datagrams can be sent using the DATAGRAM frame as defined in 331 [QUIC-DATAGRAM] and [H3-DATAGRAM]. For all HTTP/3 connections in 332 which the "http3_transport_support" option is negotiated, the Flow 333 Identifier is set to the session ID. In other words, the format of 334 datagrams SHALL be the session ID, followed by the user-specified 335 payload (Figure 4). 337 0 1 2 3 338 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Session ID (i) ... 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Datagram Body ... 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 Figure 4: Datagram format 347 In QUIC, a datagram frame can span at most one packet. Because of 348 that, the applications have to know the maximum size of the datagram 349 they can send. However, when proxying the datagrams, the hop-by-hop 350 MTUs can vary. TODO: Describe how the path MTU can be computed, 351 specifically propagation across HTTP proxies. 353 6. Session Termination 355 An Http3Transport is terminated when either endpoint closes the 356 stream associated with the CONNECT request that initiated the 357 session. Upon learning about the session being terminated, the 358 endpoint MUST stop sending new datagrams and reset all of the streams 359 associated with the session. 361 7. Transport Properties 363 Http3Transport supports most of the WebTransport features described 364 in Table 1. 366 +---------------------+--------------------------+ 367 | Property | Support | 368 +---------------------+--------------------------+ 369 | Stream independence | Always supported | 370 | | | 371 | Partial reliability | Always supported | 372 | | | 373 | Pooling support | Always supported | 374 | | | 375 | Connection mobility | Implementation-dependent | 376 +---------------------+--------------------------+ 378 Table 1: Transport properties of Http3Transport 380 8. Security Considerations 382 Http3Transport satisfies all of the security requirements imposed by 383 [QUIC-TRANSPORT] on WebTransport protocols, thus providing a secure 384 framework for client-server communication in cases when the client is 385 potentially untrusted. Since HTTP/3 is QUIC-based, a lot of the 386 analysis in [WEBTRANSPORT-QUIC] applies here. 388 Http3Transport requires explicit opt-in through the use of a QUIC 389 transport parameter; this avoids potential protocol confusion attacks 390 by ensuring the HTTP/3 server explicitly supports it. It also 391 requires the use of the Origin header, providing the server with the 392 ability to deny access to Web-based clients that do not originate 393 from a trusted origin. 395 Just like HTTP/3 itself, Http3Transport pools traffic to different 396 origins within a single connection. Different origins imply 397 different trust domains, meaning that the implementations have to 398 treat each transport as potentially hostile towards others on the 399 same connection. One potential attack is a resource exhaustion 400 attack: since all of the transports share both congestion control and 401 flow control context, a single client aggressively using up those 402 resources can cause other transports to stall. The user agent thus 403 SHOULD implement a fairness scheme that ensures that each transport 404 within connection gets a reasonable share of controlled resources; 405 this applies both to sending data and to opening new streams. 407 9. IANA Considerations 409 9.1. Upgrade Token Registration 411 The following entry is added to the "Hypertext Transfer Protocol 412 (HTTP) Upgrade Token Registry" registry established by [RFC7230]: 414 The "webtransport" label identifies HTTP/3 used as a protocol for 415 WebTransport: 417 Value: webtransport 419 Description: WebTransport over HTTP/3 421 Reference: This document 423 9.2. QUIC Transport Parameter Registration 425 The following entry is added to the "QUIC Transport Parameter 426 Registry" registry established by [QUIC-TRANSPORT]: 428 The "http3_transport_support" parameter indicates that the specified 429 HTTP/3 connection is Http3Transport-capable. 431 Value: 0x???? 433 Parameter Name: http3_transport_support 435 Specification: This document 437 9.3. Frame Type Registration 439 The following entry is added to the "HTTP/3 Frame Type" registry 440 established by [HTTP3]: 442 The "WEBTRANSPORT_STREAM" frame allows HTTP/3 client-initiated 443 bidirectional streams to be used by WebTransport: 445 Code: 0x54 447 Frame Type: WEBTRANSPORT_STREAM 449 Specification: This document 451 9.4. Stream Type Registration 453 The following entry is added to the "HTTP/3 Stream Type" registry 454 established by [HTTP3]: 456 The "WebTransport stream" type allows unidirectional streams to be 457 used by WebTransport: 459 Code: 0x41 461 Stream Type: WebTransport stream 462 Specification: This document 464 Sender: Both 466 10. References 468 10.1. Normative References 470 [H3-DATAGRAM] 471 Schinazi, D., "Using QUIC Datagrams with HTTP/3", draft- 472 schinazi-quic-h3-datagram-04 (work in progress), April 473 2020. 475 [HTTP3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 476 (HTTP/3)", draft-ietf-quic-http (work in progress). 478 [OVERVIEW] 479 Vasiliev, V., "The WebTransport Protocol Framework", 480 draft-ietf-webtrans-overview-latest (work in progress). 482 [QUIC-DATAGRAM] 483 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 484 Datagram Extension to QUIC", draft-pauly-quic-datagram 485 (work in progress). 487 [QUIC-TRANSPORT] 488 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 489 Multiplexed and Secure Transport", draft-ietf-quic- 490 transport (work in progress). 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, 494 DOI 10.17487/RFC2119, March 1997, 495 . 497 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 498 Resource Identifier (URI): Generic Syntax", STD 66, 499 RFC 3986, DOI 10.17487/RFC3986, January 2005, 500 . 502 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 503 DOI 10.17487/RFC6454, December 2011, 504 . 506 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 507 Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, 508 . 510 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 511 Protocol (HTTP/1.1): Message Syntax and Routing", 512 RFC 7230, DOI 10.17487/RFC7230, June 2014, 513 . 515 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 516 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 517 DOI 10.17487/RFC7231, June 2014, 518 . 520 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 521 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 522 May 2017, . 524 [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", 525 RFC 8441, DOI 10.17487/RFC8441, September 2018, 526 . 528 10.2. Informative References 530 [WEBTRANSPORT-QUIC] 531 Vasiliev, V., "WebTransport over QUIC", draft-vvv- 532 webtransport-quic-02 (work in progress). 534 Author's Address 536 Victor Vasiliev 537 Google 539 Email: vasilvv@google.com