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