idnits 2.17.1 draft-ietf-webtrans-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 (19 May 2021) is 1073 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) -- 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: 3 errors (**), 0 flaws (~~), 2 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 19 May 2021 5 Expires: 20 November 2021 7 WebTransport over HTTP/3 8 draft-ietf-webtrans-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 a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides 16 support for unidirectional streams, bidirectional streams and 17 datagrams, all multiplexed within the same HTTP/3 connection. 19 Note to Readers 21 Discussion of this draft takes place on the WebTransport mailing list 22 (webtransport@ietf.org), which is archived at 23 . 25 The repository tracking the issues for this draft can be found at 26 . The web API draft corresponding to this document can be 28 found at . 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 20 November 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Session Establishment . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Establishing a Transport-Capable HTTP/3 Connection . . . 4 68 3.2. Extended CONNECT in HTTP/3 . . . . . . . . . . . . . . . 4 69 3.3. Creating a New Session . . . . . . . . . . . . . . . . . 5 70 3.4. Limiting the Number of Simultaneous Sessions . . . . . . 5 71 4. WebTransport Features . . . . . . . . . . . . . . . . . . . . 6 72 4.1. Unidirectional streams . . . . . . . . . . . . . . . . . 6 73 4.2. Bidirectional Streams . . . . . . . . . . . . . . . . . . 6 74 4.3. Datagrams . . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.4. Buffering Incoming Streams and Datagrams . . . . . . . . 8 76 5. Session Termination . . . . . . . . . . . . . . . . . . . . . 8 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 7.1. Upgrade Token Registration . . . . . . . . . . . . . . . 9 80 7.2. HTTP/3 SETTINGS Parameter Registration . . . . . . . . . 9 81 7.3. Frame Type Registration . . . . . . . . . . . . . . . . . 9 82 7.4. Stream Type Registration . . . . . . . . . . . . . . . . 10 83 7.5. HTTP/3 Error Code Registration . . . . . . . . . . . . . 10 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 86 8.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 HTTP/3 [HTTP3] is a protocol defined on top of QUIC [QUIC-TRANSPORT] 92 that can multiplex HTTP requests over a QUIC connection. This 93 document defines a mechanism for multiplexing non-HTTP data with 94 HTTP/3 in a manner that conforms with the WebTransport protocol 95 requirements and semantics [OVERVIEW]. Using the mechanism described 96 here, multiple WebTransport instances can be multiplexed 97 simultaneously with regular HTTP traffic on the same HTTP/3 98 connection. 100 1.1. Terminology 102 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 This document follows terminology defined in Section 1.2 of 109 [OVERVIEW]. Note that this document distinguishes between a 110 WebTransport server and an HTTP/3 server. An HTTP/3 server is the 111 server that terminates HTTP/3 connections; a WebTransport server is 112 an application that accepts WebTransport sessions, which can be 113 accessed via an HTTP/3 server. 115 2. Protocol Overview 117 WebTransport servers in general are identified by a pair of authority 118 value and path value (defined in [RFC3986] Sections 3.2 and 3.3 119 correspondingly). 121 When an HTTP/3 connection is established, both the client and server 122 have to send a SETTINGS_ENABLE_WEBTRANSPORT setting in order to 123 indicate that they both support WebTransport over HTTP/3. 125 WebTransport sessions are initiated inside a given HTTP/3 connection 126 by the client, who sends an extended CONNECT request [RFC8441]. If 127 the server accepts the request, an WebTransport session is 128 established. The resulting stream will be further referred to as a 129 _CONNECT stream_, and its stream ID is used to uniquely identify a 130 given WebTransport session within the connection. The ID of the 131 CONNECT stream that established a given WebTransport session will be 132 further referred to as a _Session ID_. 134 After the session is established, the peers can exchange data using 135 the following mechanisms: 137 * A client can create a bidirectional stream using a special 138 indefinite-length HTTP/3 frame that transfers ownership of the 139 stream to WebTransport. 141 * A server can create a bidirectional stream, which is possible 142 since HTTP/3 does not define any semantics for server-initiated 143 bidirectional streams. 145 * Both client and server can create a unidirectional stream using a 146 special stream type. 148 * A datagram can be sent using a QUIC DATAGRAM frame 149 [QUIC-DATAGRAM]. 151 An WebTransport session is terminated when the CONNECT stream that 152 created it is closed. 154 3. Session Establishment 156 3.1. Establishing a Transport-Capable HTTP/3 Connection 158 In order to indicate support for WebTransport, both the client and 159 the server MUST send a SETTINGS_ENABLE_WEBTRANSPORT value set to "1" 160 in their SETTINGS frame. Endpoints MUST NOT use any WebTransport- 161 related functionality unless the parameter has been negotiated. 163 If SETTINGS_ENABLE_WEBTRANSPORT is negotiated, support for the QUIC 164 DATAGRAMs within HTTP/3 MUST be negotiated as described in 165 [HTTP3-DATAGRAM]; negotiating WebTransport support without 166 negotiating QUIC DATAGRAM extension SHALL result in a 167 H3_SETTINGS_ERROR error. 169 [HTTP3] requires client's "initial_max_bidi_streams" transport 170 parameter to be set to zero. Existing implementation might enforce 171 this requirement before negotiating settings; thus, the client MUST 172 send a non-zero MAX_STREAMS for client-initiated bidirectional 173 streams after receiving an appropriate SETTINGS frame from the 174 server. 176 3.2. Extended CONNECT in HTTP/3 178 [RFC8441] defines an extended CONNECT method in Section 4, enabled by 179 the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter. That parameter is 180 only defined for HTTP/2. This document does not create a new multi- 181 purpose parameter to indicate support for extended CONNECT in HTTP/3; 182 instead, the SETTINGS_ENABLE_WEBTRANSPORT setting implies that an 183 endpoint supports extended CONNECT. 185 3.3. Creating a New Session 187 As WebTransport sessions are established over HTTP/3, they are 188 identified using the "https" URI scheme [RFC7230]. 190 In order to create a new WebTransport session, a client can send an 191 HTTP CONNECT request. The ":protocol" pseudo-header field 192 ([RFC8441]) MUST be set to "webtransport". The ":scheme" field MUST 193 be "https". Both the ":authority" and the ":path" value MUST be set; 194 those fields indicate the desired WebTransport server. An "Origin" 195 header [RFC6454] MUST be provided within the request. 197 Upon receiving an extended CONNECT request with a ":protocol" field 198 set to "webtransport", the HTTP/3 server can check if it has a 199 WebTransport server associated with the specified ":authority" and 200 ":path" values. If it does not, it SHOULD reply with status code 404 201 (Section 6.5.4, [RFC7231]). If it does, it MAY accept the session by 202 replying with status code 200. The WebTransport server MUST verify 203 the "Origin" header to ensure that the specified origin is allowed to 204 access the server in question. 206 From the client's perspective, a WebTransport session is established 207 when the client receives a 200 response. From the server's 208 perspective, a session is established once it sends a 200 response. 209 WebTransport over HTTP/3 does not support 0-RTT. 211 3.4. Limiting the Number of Simultaneous Sessions 213 From the flow control perspective, WebTransport sessions count 214 against the stream flow control just like regular HTTP requests, 215 since they are established via an HTTP CONNECT request. This 216 document does not make any effort to introduce a separate flow 217 control mechanism for sessions, nor to separate HTTP requests from 218 WebTransport data streams. If the server needs to limit the rate of 219 incoming requests, it has alternative mechanisms at its disposal: 221 * "HTTP_REQUEST_REJECTED" error code defined in [HTTP3] indicates to 222 the receiving HTTP/3 stack that the request was not processed in 223 any way. 225 * HTTP status code 429 indicates that the request was rejected due 226 to rate limiting [RFC6585]. Unlike the previous method, this 227 signal is directly propagated to the application. 229 4. WebTransport Features 231 WebTransport over HTTP/3 provides the following features described in 232 [OVERVIEW]: unidirectional streams, bidirectional streams and 233 datagrams, initiated by either endpoint. 235 Session IDs are used to demultiplex streams and datagrams belonging 236 to different WebTransport sessions. On the wire, session IDs are 237 encoded using the QUIC variable length integer scheme described in 238 [QUIC-TRANSPORT]. 240 4.1. Unidirectional streams 242 Once established, both endpoints can open unidirectional streams. 243 The HTTP/3 unidirectional stream type SHALL be 0x54. The body of the 244 stream SHALL be the stream type, followed by the session ID, encoded 245 as a variable-length integer, followed by the user-specified stream 246 data (Figure 1). 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | 0x54 (i) ... 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Session ID (i) ... 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Stream Body ... 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Figure 1: Unidirectional WebTransport stream format 260 4.2. Bidirectional Streams 262 WebTransport endpoints can initiate bidirectional streams by opening 263 an HTTP/3 bidirectional stream and sending an HTTP/3 frame with type 264 "WEBTRANSPORT_STREAM" (type=0x41). The format of the frame SHALL be 265 the frame type, followed by the session ID, encoded as a variable- 266 length integer, followed by the user-specified stream data 267 (Figure 2). The frame SHALL last until the end of the stream. 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | 0x41 (i) ... 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Session ID (i) ... 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Stream Body ... 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 2: WEBTRANSPORT_STREAM frame format 281 HTTP/3 does not by itself define any semantics for server-initiated 282 bidirectional streams. If WebTransport setting is negotiated by both 283 endpoints, the syntax of the server-initiated bidirectional streams 284 SHALL be the same as the syntax of client-initated bidirectional 285 streams, that is, a sequence of HTTP/3 frames. The only frame 286 defined by this document for use within server-initiated 287 bidirectional streams is WEBTRANSPORT_STREAM. 289 TODO: move the paragraph above into a separate draft; define what 290 happens with already existing HTTP/3 frames on server-initiated 291 bidirectional streams. 293 4.3. Datagrams 295 Datagrams can be sent using the DATAGRAM frame as defined in 296 [QUIC-DATAGRAM] and [HTTP3-DATAGRAM]. For all HTTP/3 connections in 297 which the SETTINGS_ENABLE_WEBTRANSPORT option is negotiated, the Flow 298 Identifier is set to the session ID. In other words, the format of 299 datagrams SHALL be the session ID, followed by the user-specified 300 payload (Figure 3). 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Session ID (i) ... 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Datagram Body ... 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Figure 3: Datagram format 312 In QUIC, a datagram frame can span at most one packet. Because of 313 that, the applications have to know the maximum size of the datagram 314 they can send. However, when proxying the datagrams, the hop-by-hop 315 MTUs can vary. TODO: Describe how the path MTU can be computed, 316 specifically propagation across HTTP proxies. 318 4.4. Buffering Incoming Streams and Datagrams 320 In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, 321 as well as multiple WebTransport CONNECT requests, WebTransport data 322 streams and WebTransport datagrams, all within a single flight. As 323 those can arrive out of order, a WebTransport server could be put 324 into a situation where it receives a stream or a datagram without a 325 corresponding session. Similarly, a client may receive a server- 326 initiated stream or a datagram before receiving the CONNECT response 327 headers from the server. 329 To handle this case, WebTransport endpoints SHOULD buffer streams and 330 datagrams until those can be associated with an established session. 331 To avoid resource exhaustion, the endpoints MUST limit the number of 332 buffered streams and datagrams. When the number of buffered streams 333 is exceeded, a stream SHALL be closed by sending a RESET_STREAM and/ 334 or STOP_SENDING with the "H3_WEBTRANSPORT_BUFFERED_STREAM_REJECTED" 335 error code. When the number of buffered datagrams is exceeded, a 336 datagram SHALL be dropped. It is up to an implementation to choose 337 what stream or datagram to discard. 339 5. Session Termination 341 An WebTransport session over HTTP/3 is terminated when either 342 endpoint closes the stream associated with the CONNECT request that 343 initiated the session. Upon learning about the session being 344 terminated, the endpoint MUST stop sending new datagrams and reset 345 all of the streams associated with the session. 347 6. Security Considerations 349 WebTransport over HTTP/3 satisfies all of the security requirements 350 imposed by [OVERVIEW] on WebTransport protocols, thus providing a 351 secure framework for client-server communication in cases when the 352 client is potentially untrusted. 354 WebTransport over HTTP/3 requires explicit opt-in through the use of 355 a QUIC transport parameter; this avoids potential protocol confusion 356 attacks by ensuring the HTTP/3 server explicitly supports it. It 357 also requires the use of the Origin header, providing the server with 358 the ability to deny access to Web-based clients that do not originate 359 from a trusted origin. 361 Just like HTTP traffic going over HTTP/3, WebTransport pools traffic 362 to different origins within a single connection. Different origins 363 imply different trust domains, meaning that the implementations have 364 to treat each transport as potentially hostile towards others on the 365 same connection. One potential attack is a resource exhaustion 366 attack: since all of the transports share both congestion control and 367 flow control context, a single client aggressively using up those 368 resources can cause other transports to stall. The user agent thus 369 SHOULD implement a fairness scheme that ensures that each transport 370 within connection gets a reasonable share of controlled resources; 371 this applies both to sending data and to opening new streams. 373 7. IANA Considerations 375 7.1. Upgrade Token Registration 377 The following entry is added to the "Hypertext Transfer Protocol 378 (HTTP) Upgrade Token Registry" registry established by [RFC7230]: 380 The "webtransport" label identifies HTTP/3 used as a protocol for 381 WebTransport: 383 Value: webtransport 385 Description: WebTransport over HTTP/3 387 Reference: This document and [I-D.kinnear-webtransport-http2] 389 7.2. HTTP/3 SETTINGS Parameter Registration 391 The following entry is added to the "HTTP/3 Settings" registry 392 established by [HTTP3]: 394 The "SETTINGS_ENABLE_WEBTRANSPORT" parameter indicates that the 395 specified HTTP/3 connection is WebTransport-capable. 397 Setting Name: ENABLE_WEBTRANSPORT 399 Value: 0x2b603742 401 Default: 0 403 Specification: This document 405 7.3. Frame Type Registration 407 The following entry is added to the "HTTP/3 Frame Type" registry 408 established by [HTTP3]: 410 The "WEBTRANSPORT_STREAM" frame allows HTTP/3 client-initiated 411 bidirectional streams to be used by WebTransport: 413 Code: 0x41 414 Frame Type: WEBTRANSPORT_STREAM 416 Specification: This document 418 7.4. Stream Type Registration 420 The following entry is added to the "HTTP/3 Stream Type" registry 421 established by [HTTP3]: 423 The "WebTransport stream" type allows unidirectional streams to be 424 used by WebTransport: 426 Code: 0x54 428 Stream Type: WebTransport stream 430 Specification: This document 432 Sender: Both 434 7.5. HTTP/3 Error Code Registration 436 The following entry is added to the "HTTP/3 Error Code" registry 437 established by [HTTP3]: 439 Name: H3_WEBTRANSPORT_BUFFERED_STREAM_REJECTED 441 Value: 0x3994bd84 443 Description: WebTransport data stream rejected due to lack of 444 associated session. 446 Specification: This document. 448 8. References 450 8.1. Normative References 452 [HTTP3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 453 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 454 quic-http, 455 . 457 [HTTP3-DATAGRAM] 458 Schinazi, D. and L. Pardue, "Using QUIC Datagrams with 459 HTTP/3", Work in Progress, Internet-Draft, draft-schinazi- 460 masque-h3-datagram-04, 5 January 2021, 461 . 464 [OVERVIEW] Vasiliev, V., "The WebTransport Protocol Framework", Work 465 in Progress, Internet-Draft, draft-ietf-webtrans-overview- 466 latest, . 469 [QUIC-DATAGRAM] 470 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 471 Datagram Extension to QUIC", Work in Progress, Internet- 472 Draft, draft-pauly-quic-datagram, 473 . 475 [QUIC-TRANSPORT] 476 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 477 Multiplexed and Secure Transport", Work in Progress, 478 Internet-Draft, draft-ietf-quic-transport, 479 . 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 8.2. Informative References 519 [I-D.kinnear-webtransport-http2] 520 Frindell, A., Kinnear, E., Pauly, T., Vasiliev, V., and G. 521 Xie, "WebTransport using HTTP/2", Work in Progress, 522 Internet-Draft, draft-kinnear-webtransport-http2-02, 22 523 February 2021, . 526 Author's Address 528 Victor Vasiliev 529 Google 531 Email: vasilvv@google.com