idnits 2.17.1 draft-ietf-webtrans-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 (25 October 2021) is 914 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 (-11) exists of draft-ietf-masque-h3-datagram-05 -- 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) -- Possible downref: Normative reference to a draft: ref. 'SEMANTICS' == Outdated reference: A later version (-08) exists of draft-ietf-webtrans-http2-01 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Frindell 3 Internet-Draft Facebook 4 Intended status: Standards Track E. Kinnear 5 Expires: 28 April 2022 Apple Inc. 6 V. Vasiliev 7 Google 8 25 October 2021 10 WebTransport over HTTP/3 11 draft-ietf-webtrans-http3-02 13 Abstract 15 WebTransport [OVERVIEW] is a protocol framework that enables clients 16 constrained by the Web security model to communicate with a remote 17 server using a secure multiplexed transport. This document describes 18 a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides 19 support for unidirectional streams, bidirectional streams and 20 datagrams, all multiplexed within the same HTTP/3 connection. 22 Note to Readers 24 Discussion of this draft takes place on the WebTransport mailing list 25 (webtransport@ietf.org), which is archived at 26 . 28 The repository tracking the issues for this draft can be found at 29 . The web API draft corresponding to this document can be 31 found at . 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 28 April 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Session Establishment . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Establishing a Transport-Capable HTTP/3 Connection . . . 4 71 3.2. Extended CONNECT in HTTP/3 . . . . . . . . . . . . . . . 4 72 3.3. Creating a New Session . . . . . . . . . . . . . . . . . 4 73 3.4. Limiting the Number of Simultaneous Sessions . . . . . . 5 74 4. WebTransport Features . . . . . . . . . . . . . . . . . . . . 5 75 4.1. Unidirectional streams . . . . . . . . . . . . . . . . . 6 76 4.2. Bidirectional Streams . . . . . . . . . . . . . . . . . . 6 77 4.3. Resetting Data Streams . . . . . . . . . . . . . . . . . 7 78 4.4. Datagrams . . . . . . . . . . . . . . . . . . . . . . . . 8 79 4.5. Buffering Incoming Streams and Datagrams . . . . . . . . 8 80 5. Session Termination . . . . . . . . . . . . . . . . . . . . . 9 81 6. Negotiating the Draft Version . . . . . . . . . . . . . . . . 10 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 8.1. Upgrade Token Registration . . . . . . . . . . . . . . . 11 85 8.2. HTTP/3 SETTINGS Parameter Registration . . . . . . . . . 11 86 8.3. Frame Type Registration . . . . . . . . . . . . . . . . . 12 87 8.4. Stream Type Registration . . . . . . . . . . . . . . . . 12 88 8.5. HTTP/3 Error Code Registration . . . . . . . . . . . . . 12 89 8.6. Datagram Format Type . . . . . . . . . . . . . . . . . . 13 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 92 9.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 95 1. Introduction 97 HTTP/3 [HTTP3] is a protocol defined on top of QUIC [RFC9000] that 98 can multiplex HTTP requests over a QUIC connection. This document 99 defines a mechanism for multiplexing non-HTTP data with HTTP/3 in a 100 manner that conforms with the WebTransport protocol requirements and 101 semantics [OVERVIEW]. Using the mechanism described here, multiple 102 WebTransport instances can be multiplexed simultaneously with regular 103 HTTP traffic on the same HTTP/3 connection. 105 1.1. Terminology 107 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 This document follows terminology defined in Section 1.2 of 114 [OVERVIEW]. Note that this document distinguishes between a 115 WebTransport server and an HTTP/3 server. An HTTP/3 server is the 116 server that terminates HTTP/3 connections; a WebTransport server is 117 an application that accepts WebTransport sessions, which can be 118 accessed via an HTTP/3 server. 120 2. Protocol Overview 122 WebTransport servers in general are identified by a pair of authority 123 value and path value (defined in [RFC3986] Sections 3.2 and 3.3 124 correspondingly). 126 When an HTTP/3 connection is established, both the client and server 127 have to send a SETTINGS_ENABLE_WEBTRANSPORT setting in order to 128 indicate that they both support WebTransport over HTTP/3. 130 WebTransport sessions are initiated inside a given HTTP/3 connection 131 by the client, who sends an extended CONNECT request [RFC8441]. If 132 the server accepts the request, an WebTransport session is 133 established. The resulting stream will be further referred to as a 134 _CONNECT stream_, and its stream ID is used to uniquely identify a 135 given WebTransport session within the connection. The ID of the 136 CONNECT stream that established a given WebTransport session will be 137 further referred to as a _Session ID_. 139 After the session is established, the peers can exchange data using 140 the following mechanisms: 142 * A client can create a bidirectional stream using a special 143 indefinite-length HTTP/3 frame that transfers ownership of the 144 stream to WebTransport. 146 * A server can create a bidirectional stream, which is possible 147 since HTTP/3 does not define any semantics for server-initiated 148 bidirectional streams. 150 * Both client and server can create a unidirectional stream using a 151 special stream type. 153 * A datagram can be sent using HTTP Datagrams [HTTP-DATAGRAM]. 155 An WebTransport session is terminated when the CONNECT stream that 156 created it is closed. 158 3. Session Establishment 160 3.1. Establishing a Transport-Capable HTTP/3 Connection 162 In order to indicate support for WebTransport, both the client and 163 the server MUST send a SETTINGS_ENABLE_WEBTRANSPORT value set to "1" 164 in their SETTINGS frame. The SETTINGS_ENABLE_WEBTRANSPORT parameter 165 value SHALL be either "0" or "1", with "0" being the default; an 166 endpoint that receives a value other than "0" or "1" MUST close the 167 connection with the H3_SETTINGS_ERROR error code. 169 The client MUST NOT send a WebTransport request until it has received 170 the setting indicating WebTransport support from the server. 171 Similarly, the server MUST NOT process any incoming WebTransport 172 requests until the client settings have been received, as the client 173 may be using a version of WebTransport extension that is different 174 from the one used by the 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 ([RFC8441]) 192 MUST be set to webtransport. The :scheme field MUST be https. Both 193 the :authority and the :path value MUST be set; those fields indicate 194 the desired WebTransport server. An Origin header [RFC6454] MUST be 195 provided within the request. 197 Upon receiving an extended CONNECT request with a :protocol field set 198 to webtransport, the HTTP/3 server can check if it has a WebTransport 199 server associated with the specified :authority and :path values. If 200 it does not, it SHOULD reply with status code 404 (Section 6.5.4, 201 [RFC7231]). If it does, it MAY accept the session by replying with a 202 2xx series status code, as defined in Section 15.3 of [SEMANTICS]. 203 The WebTransport server MUST verify the Origin header to ensure that 204 the specified origin is allowed to access the server in question. 206 From the client's perspective, a WebTransport session is established 207 when the client receives a 2xx response. From the server's 208 perspective, a session is established once it sends a 2xx response. 209 WebTransport over HTTP/3 does not support 0-RTT. 211 The webtransport HTTP Upgrade Token uses the Capsule Protocol as 212 defined in [HTTP-DATAGRAM]. 214 3.4. Limiting the Number of Simultaneous Sessions 216 From the flow control perspective, WebTransport sessions count 217 against the stream flow control just like regular HTTP requests, 218 since they are established via an HTTP CONNECT request. This 219 document does not make any effort to introduce a separate flow 220 control mechanism for sessions, nor to separate HTTP requests from 221 WebTransport data streams. If the server needs to limit the rate of 222 incoming requests, it has alternative mechanisms at its disposal: 224 * HTTP_REQUEST_REJECTED error code defined in [HTTP3] indicates to 225 the receiving HTTP/3 stack that the request was not processed in 226 any way. 228 * HTTP status code 429 indicates that the request was rejected due 229 to rate limiting [RFC6585]. Unlike the previous method, this 230 signal is directly propagated to the application. 232 4. WebTransport Features 234 WebTransport over HTTP/3 provides the following features described in 235 [OVERVIEW]: unidirectional streams, bidirectional streams and 236 datagrams, initiated by either endpoint. 238 Session IDs are used to demultiplex streams and datagrams belonging 239 to different WebTransport sessions. On the wire, session IDs are 240 encoded using the QUIC variable length integer scheme described in 241 [RFC9000]. 243 If at any point a session ID is received that cannot a valid ID for a 244 client-initiated bidirectional stream, the recepient MUST close the 245 connection with an H3_ID_ERROR error code. 247 4.1. Unidirectional streams 249 Once established, both endpoints can open unidirectional streams. 250 The HTTP/3 unidirectional stream type SHALL be 0x54. The body of the 251 stream SHALL be the stream type, followed by the session ID, encoded 252 as a variable-length integer, followed by the user-specified stream 253 data (Figure 1). 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | 0x54 (i) ... 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Session ID (i) ... 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Stream Body ... 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 1: Unidirectional WebTransport stream format 267 4.2. Bidirectional Streams 269 WebTransport endpoints can initiate bidirectional streams by opening 270 an HTTP/3 bidirectional stream and sending an HTTP/3 frame with type 271 WEBTRANSPORT_STREAM (type=0x41). The format of the frame SHALL be 272 the frame type, followed by the session ID, encoded as a variable- 273 length integer, followed by the user-specified stream data 274 (Figure 2). The frame SHALL last until the end of the stream. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | 0x41 (i) ... 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Session ID (i) ... 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Stream Body ... 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 2: WEBTRANSPORT_STREAM frame format 287 HTTP/3 does not by itself define any semantics for server-initiated 288 bidirectional streams. If WebTransport setting is negotiated by both 289 endpoints, the syntax of the server-initiated bidirectional streams 290 SHALL be the same as the syntax of client-initated bidirectional 291 streams, that is, a sequence of HTTP/3 frames. The only frame 292 defined by this document for use within server-initiated 293 bidirectional streams is WEBTRANSPORT_STREAM. 295 TODO: move the paragraph above into a separate draft; define what 296 happens with already existing HTTP/3 frames on server-initiated 297 bidirectional streams. 299 4.3. Resetting Data Streams 301 A WebTransport endpoint may send a RESET_STREAM or a STOP_SENDING 302 frame for a WebTransport data stream. Those signals are propagated 303 by the WebTransport implementation to the application. 305 A WebTransport application SHALL provide an error code for those 306 operations. Since WebTransport shares the error code space with 307 HTTP/3, WebTransport application errors for streams are limited to an 308 unsigned 8-bit integer, assuming values between 0x00 and 0xff. 309 WebTransport implementations SHALL remap those error codes into an 310 error range where 0x00 corresponds to 0x52e4a40fa8db, and 0xff 311 corresponds to 0x52e4a40fa9e2. Note that there are code points 312 inside that range of form "0x1f * N + 0x21" that are reserved by 313 Section 8.1 of [HTTP3]; those have to be accounted for when mapping 314 the error codes by skipping them (i.e. the two HTTP/3 error 315 codepoints adjacent to a GREASE codepoint would map to two adjacent 316 WebTransport application error codepoints). An example pseudocode 317 can be seen in Figure 3. 319 first = 0x52e4a40fa8db 320 last = 0x52e4a40fa9e2 322 def webtransport_code_to_http_code(n): 323 return first + n + floor(n / 0x1e) 325 def http_code_to_webtransport_code(h): 326 assert(first <= h <= last) 327 assert((h - 0x21) % 0x1f != 0) 328 shifted = h - first 329 return shifted - shifted // 0x1f 331 Figure 3: Pseudocode for converting between WebTransport 332 application errors and HTTP/3 error codes; here, `//` is integer 333 division 335 WebTransport data streams are associated with sessions through a 336 header at the beginning of the stream; resetting a stream may result 337 in that data being discarded. Because of that, WebTransport 338 application error codes are best effort, as the WebTransport stack is 339 not always capable of associating the reset code with a session. The 340 only exception is the situation where there is only one session on a 341 given HTTP/3 connection, and no intermediaries between the client and 342 the server. 344 WebTransport implementations SHALL forward the error code for a 345 stream associated with a known session to the application that owns 346 that session; similarly, the intermediaries SHALL reset the streams 347 with corresponding error code when receiving a reset from the peer. 348 If a WebTransport implementation intentionally allows only one 349 session over a given HTTP/3 connection, it SHALL forward the error 350 codes within WebTransport application error code range to the 351 application that owns the only session on that connection. 353 4.4. Datagrams 355 Datagrams can be sent using HTTP Datagrams, using the WEB_TRANSPORT 356 HTTP Datagram Format Type (see value in Section 8.6). When using the 357 WEB_TRANSPORT HTTP Datagram Format Type, the WebTransport datagram 358 payload is sent unmodified in the "HTTP Datagram Payload" field of an 359 HTTP Datagram. When sending a registration capsule using the 360 "Datagram Format Type" set to WEB_TRANSPORT, the "Datagram Format 361 Additional Data" field SHALL be empty. 363 In QUIC, a datagram frame can span at most one packet. Because of 364 that, the applications have to know the maximum size of the datagram 365 they can send. However, when proxying the datagrams, the hop-by-hop 366 MTUs can vary. TODO: Describe how the path MTU can be computed, 367 specifically propagation across HTTP proxies. 369 4.5. Buffering Incoming Streams and Datagrams 371 In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, 372 as well as multiple WebTransport CONNECT requests, WebTransport data 373 streams and WebTransport datagrams, all within a single flight. As 374 those can arrive out of order, a WebTransport server could be put 375 into a situation where it receives a stream or a datagram without a 376 corresponding session. Similarly, a client may receive a server- 377 initiated stream or a datagram before receiving the CONNECT response 378 headers from the server. 380 To handle this case, WebTransport endpoints SHOULD buffer streams and 381 datagrams until those can be associated with an established session. 382 To avoid resource exhaustion, the endpoints MUST limit the number of 383 buffered streams and datagrams. When the number of buffered streams 384 is exceeded, a stream SHALL be closed by sending a RESET_STREAM and/ 385 or STOP_SENDING with the H3_WEBTRANSPORT_BUFFERED_STREAM_REJECTED 386 error code. When the number of buffered datagrams is exceeded, a 387 datagram SHALL be dropped. It is up to an implementation to choose 388 what stream or datagram to discard. 390 5. Session Termination 392 A WebTransport session over HTTP/3 is considered terminated when 393 either of the following conditions is met: 395 * the CONNECT stream is closed, either cleanly or abruptly, on 396 either side; or 398 * a CLOSE_WEBTRANSPORT_SESSION capsule is either sent or received. 400 Upon learning that the session has been terminated, the endpoint MUST 401 reset all of the streams associated with the session; it MUST NOT 402 send any new datagrams or open any new streams. 404 To terminate a session with a detailed error message, an application 405 MAY send an HTTP capsule [HTTP-DATAGRAM] of type 406 CLOSE_WEBTRANSPORT_SESSION (0x2843). The format of the capsule SHALL 407 be as follows: 409 CLOSE_WEBTRANSPORT_SESSION Capsule { 410 Type (i) = CLOSE_WEBTRANSPORT_SESSION, 411 Length (i), 412 Application Error Code (32), 413 Application Error Message (..8192), 414 } 416 CLOSE_WEBTRANSPORT_SESSION has the following fields: 418 Application Error Code: A 32-bit error code provided by the 419 application closing the connection. 421 Application Error Message: A UTF-8 encoded error message string 422 provided by the application closing the connection. The message 423 takes up the remainer of the capsule, and its length MUST NOT 424 exceed 1024 bytes. 426 A CLOSE_WEBTRANSPORT_SESSION capsule MUST be followed by a FIN on the 427 sender side. If any additional stream data is received on the 428 CONNECT stream after CLOSE_WEBTRANSPORT_SESSION, the stream MUST be 429 reset with code H3_MESSAGE_ERROR. The recipient MUST close the 430 stream upon receiving a FIN. If the sender of 431 CLOSE_WEBTRANSPORT_SESSION does not receive a FIN after some time, it 432 SHOULD send STOP_SENDING on the CONNECT stream. 434 Cleanly terminating a CONNECT stream without a 435 CLOSE_WEBTRANSPORT_SESSION capsule SHALL be semantically equivalent 436 to terminating it with a CLOSE_WEBTRANSPORT_SESSION capsule that has 437 an error code of 0 and an empty error string. 439 6. Negotiating the Draft Version 441 [[RFC editor: please remove this section before publication.]] 443 WebTransport over HTTP/3 uses two different mechanisms to negotiate 444 versions for the different parts of the draft. 446 The hop-by-hop wire format aspects of the protocol are negotiated by 447 changing the codepoint used for the SETTINGS_ENABLE_WEBTRANSPORT 448 parameter. Because of that, any WebTransport endpoint MUST wait for 449 the peer's SETTINGS frame before sending or processing any 450 WebTransport traffic. When multiple versions are supported by both 451 of the peers, the most recent version supported by both is selected. 453 The data exchanged over the CONNECT stream is transmitted across 454 intermediaries, and thus cannot be versioned using a SETTINGS 455 parameter. To indicate support for different versions of the 456 protocol defined in this draft, the clients SHALL send a header for 457 each version of the draft supported. The header corresponding to the 458 version described in this draft is Sec-Webtransport-Http3-Draft02; 459 its value SHALL be 1. The server SHALL reply with a Sec- 460 Webtransport-Http3-Draft header indicating the selected version; its 461 value SHALL be draft02 for the version described in this draft. 463 7. Security Considerations 465 WebTransport over HTTP/3 satisfies all of the security requirements 466 imposed by [OVERVIEW] on WebTransport protocols, thus providing a 467 secure framework for client-server communication in cases when the 468 client is potentially untrusted. 470 WebTransport over HTTP/3 requires explicit opt-in through the use of 471 a QUIC transport parameter; this avoids potential protocol confusion 472 attacks by ensuring the HTTP/3 server explicitly supports it. It 473 also requires the use of the Origin header, providing the server with 474 the ability to deny access to Web-based clients that do not originate 475 from a trusted origin. 477 Just like HTTP traffic going over HTTP/3, WebTransport pools traffic 478 to different origins within a single connection. Different origins 479 imply different trust domains, meaning that the implementations have 480 to treat each transport as potentially hostile towards others on the 481 same connection. One potential attack is a resource exhaustion 482 attack: since all of the transports share both congestion control and 483 flow control context, a single client aggressively using up those 484 resources can cause other transports to stall. The user agent thus 485 SHOULD implement a fairness scheme that ensures that each transport 486 within connection gets a reasonable share of controlled resources; 487 this applies both to sending data and to opening new streams. 489 8. IANA Considerations 491 8.1. Upgrade Token Registration 493 The following entry is added to the "Hypertext Transfer Protocol 494 (HTTP) Upgrade Token Registry" registry established by [RFC7230]: 496 The "webtransport" label identifies HTTP/3 used as a protocol for 497 WebTransport: 499 Value: webtransport 501 Description: WebTransport over HTTP/3 503 Reference: This document and [I-D.ietf-webtrans-http2] 505 8.2. HTTP/3 SETTINGS Parameter Registration 507 The following entry is added to the "HTTP/3 Settings" registry 508 established by [HTTP3]: 510 The SETTINGS_ENABLE_WEBTRANSPORT parameter indicates that the 511 specified HTTP/3 connection is WebTransport-capable. 513 Setting Name: ENABLE_WEBTRANSPORT 515 Value: 0x2b603742 517 Default: 0 518 Specification: This document 520 8.3. Frame Type Registration 522 The following entry is added to the "HTTP/3 Frame Type" registry 523 established by [HTTP3]: 525 The WEBTRANSPORT_STREAM frame allows HTTP/3 client-initiated 526 bidirectional streams to be used by WebTransport: 528 Code: 0x41 530 Frame Type: WEBTRANSPORT_STREAM 532 Specification: This document 534 8.4. Stream Type Registration 536 The following entry is added to the "HTTP/3 Stream Type" registry 537 established by [HTTP3]: 539 The "WebTransport stream" type allows unidirectional streams to be 540 used by WebTransport: 542 Code: 0x54 544 Stream Type: WebTransport stream 546 Specification: This document 548 Sender: Both 550 8.5. HTTP/3 Error Code Registration 552 The following entry is added to the "HTTP/3 Error Code" registry 553 established by [HTTP3]: 555 Name: H3_WEBTRANSPORT_BUFFERED_STREAM_REJECTED 557 Value: 0x3994bd84 559 Description: WebTransport data stream rejected due to lack of 560 associated session. 562 Specification: This document. 564 In addition, the following range of entries is registered: 566 Name: H3_WEBTRANSPORT_APPLICATION_00 ... 567 H3_WEBTRANSPORT_APPLICATION_FF 569 Value: 0x52e4a40fa8db to 0x52e4a40fa9e2 inclusive, with the 570 exception of 0x52e4a40fa8f9, 0x52e4a40fa918, 0x52e4a40fa937, 571 0x52e4a40fa956, 0x52e4a40fa975, 0x52e4a40fa994, 0x52e4a40fa9b3, 572 and 0x52e4a40fa9d2. 574 Description: WebTransport application error codes. 576 Specification: This document. 578 8.6. Datagram Format Type 580 This document will request IANA to register WEB_TRANSPORT in the 581 "HTTP Datagram Format Types" registry established by [HTTP-DATAGRAM]. 583 +===============+==========+===============+ 584 | Type | Value | Specification | 585 +===============+==========+===============+ 586 | WEB_TRANSPORT | 0xff7c00 | This Document | 587 +---------------+----------+---------------+ 589 Table 1: Registered Datagram Format Type 591 9. References 593 9.1. Normative References 595 [HTTP-DATAGRAM] 596 Schinazi, D. and L. Pardue, "Using Datagrams with HTTP", 597 Work in Progress, Internet-Draft, draft-ietf-masque-h3- 598 datagram-05, 25 October 2021, 599 . 602 [HTTP3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 603 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 604 quic-http, . 607 [OVERVIEW] Vasiliev, V., "The WebTransport Protocol Framework", Work 608 in Progress, Internet-Draft, draft-ietf-webtrans-overview- 609 latest, . 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, 614 DOI 10.17487/RFC2119, March 1997, 615 . 617 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 618 Resource Identifier (URI): Generic Syntax", STD 66, 619 RFC 3986, DOI 10.17487/RFC3986, January 2005, 620 . 622 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 623 DOI 10.17487/RFC6454, December 2011, 624 . 626 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 627 Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, 628 . 630 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 631 Protocol (HTTP/1.1): Message Syntax and Routing", 632 RFC 7230, DOI 10.17487/RFC7230, June 2014, 633 . 635 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 636 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 637 DOI 10.17487/RFC7231, June 2014, 638 . 640 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 641 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 642 May 2017, . 644 [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", 645 RFC 8441, DOI 10.17487/RFC8441, September 2018, 646 . 648 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 649 Multiplexed and Secure Transport", RFC 9000, 650 DOI 10.17487/RFC9000, May 2021, 651 . 653 [SEMANTICS] 654 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 655 Semantics", Work in Progress, Internet-Draft, draft-ietf- 656 httpbis-semantics-19, 12 September 2021, 657 . 660 9.2. Informative References 662 [I-D.ietf-webtrans-http2] 663 Frindell, A., Kinnear, E., Pauly, T., Vasiliev, V., and G. 664 Xie, "WebTransport using HTTP/2", Work in Progress, 665 Internet-Draft, draft-ietf-webtrans-http2-01, 30 July 666 2021, . 669 Authors' Addresses 671 Alan Frindell 672 Facebook 674 Email: afrind@fb.com 676 Eric Kinnear 677 Apple Inc. 679 Email: ekinnear@apple.com 681 Victor Vasiliev 682 Google 684 Email: vasilvv@google.com