]> Technische Universität Berlin

marten.richter@tu-berlin.de

art webtrans Internet-Draft WebTransport , a protocol framework within the Web security model, empowers Web clients to initiate secure multiplexed transport for low-level client-server interactions with remote servers. This document outlines a protocol, based on WebSocket , offering WebTransport capabilities similar to the HTTP/2 variant . It serves as an alternative when UDP-based protocols are inaccessible, and the client environment exclusively supports WebSocket . Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction WebTransport is designed to facilitate communication for Web clients over HTTP/3 , leveraging QUIC semantics with streams or datagrams . In cases where UDP-based traffic is restricted, HTTP/2 protocol serves as an alternative built solely on HTTP semantics. Both and variants require a native WebClient implementation due to the usual unavailability of plain UDP and TCP/IP socket access for scripts within WebClients This document defines a protocol implementable on the WebClient using available scripting languages, without altering the WebClient's native code. It uses the widespread WebSocket protocol as the base without modification. However, a direct implementation in a WebClient is possible. The protocol utilizes capsule semantics derived from and translates them into WebSocket frames. By relying on WebSockets, also intermediates such as proxies unaware of WebTransports can apply application layer processing. An implementation should support both WebSocket over http/1 and http/2. The server should incorporate WebTransport flow control constraints and capsule processing into its WebSocket parser code. Therefore, using unmodified existing WebSocket code is not recommended.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The document follows the terminology defined in .

Protocol Overview WebTransport servers are identified by an HTTPS URI per . The protocol uses semantics with the following modifications.

Connection and version negotiation The WebSocket connection is established according to or . When a WebSocket connection is established, both the client and server select the WebTransport-Websocket protocol by setting |Sec-WebSocket-Protocol| to the supported versions. The protocol names follow the scheme "webtransport_VERSIONAME", where VERSIONNAME identifies the particular protocol version. For this protocol VERSIONAME would be "kDraft1" and the |Sec-WebSocket-Protocol| field would include "webtransport_kDraft1". The protocol negotiation follows the procedures as described in and . No protocol extensions MUST BE negotiated.

Data framing The protocol uses the data frames as defined in . PING and PONG frame handling is not changed . For closing a session a CLOSE_WEBTRANSPORT_SESSION capsule followed by the CLOSE frame is sent. Data Frames containing Text are reserved for future use and MUST NOT be sent. Binary Data Frames transport CAPSULE content defined in and . For details, refer to the next section . Their length is limited by WebTransport flow control, and a violation SHOULD lead to connection termination. CONTINUATION frames are processed per specifications. Given the streaming nature of the content, partial DATA frames or CONTINUATION frames should be promptly forwarded to corresponding streams reducing latency.

Capsule frames This protocol adopts the mechanisms and intrinsic elements outlined in , which itself is constructed upon the CAPSULE protocol originating from . A CAPSULE has the form in : where Capsule Type and Length are variable-length integers. The Capsule Value represents the payload of the capsule, and its semantics are determined by the payload type In the context of WebTransport over WebSockets, CAPSULEs are substituted by binary DATA FRAMES of WebSockets, following the format: FrameHeader contains the first two bytes of the FRAME, and if present the extended payload length and masking key as defined in . PayloadData is defined as: with the variable length integer Capsule Type and Capsule Value as in the CAPSULE protocol. Capsule length can be calculated from the Payload Length as set in : as no Extension Data is allowed.

Replacement for SETTINGS requires sending an SETTINGS_WEBTRANSPORT_MAX_SESSIONS settings parameter. This is not required here, as the protocol type is negotiated using the subprotocol mechanism of WebSockets and SETTINGS_WEBTRANSPORT_MAX_SESSIONS equal to 1 is assumed per WebSocket connection(HTTP1)/stream(HTTP2). Subsections of require sending initial SETTINGS for flow control. As SETTINGS are not accessible for the WebSocket protocol using the existing WebSocket interfaces, a replacement is required. Therefore client and server MUST send the initial flow control values using CAPSULES immediately before ANY other capsules such as WT_STREAM or DATAGRAM capsules have been sent.

Implementation Status The protocol is implemented in a node.js package.

Security Considerations The security considerations of also apply here. The last paragraph of is equally applicable to this protocol.

IANA Considerations

WebSocket Subprotocol Name Registry All possible subprotocol names following the format "webtransport_VERSION," where VERSION is an alphanumeric string denoting the subprotocol version of this protocol, are added to the registry as domains for this protocol and its successors.

WebTransport WebSocket Protocol Version Registry This specification establishes a new IANA registry for WebTransort Protocol Version names, intended for use with the WebSocket WebTransport Protocol, in alignment with the principles outlined in . As part of this registry, IANA manages the following information (similar to versions): Version String The version string name as part of the subprotocol defined in and . The value must only include alphanumeric characters. Reference The RFC requesting a new version number or a draft name with version number (see below). Status Either "Interim" or "Standard". See below for a description. A version string can be either "Interim" or "Standard". A "Standard" version string is part of an RFC and identifies a major, stable version of the WebTransport-WebSocket protocol. The "IETF Review" IANA registration policy applies to "Standard" version string. An Internet-Draft documents an "Interim" version string. Internet-Drafts helps implementors to identify and interoperate with the WebTransport-WebSocket protocol, as this current draft. The "Expert Review" IANA registration policy applies to the "Interim" version names. The initial Designated Experts need to be determined.

References Normative References Google The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with an abstract model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional. Facebook Apple Inc. Google WebTransport [OVERVIEW] is a protocol framework that enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. This document describes a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams and datagrams, all multiplexed within the same HTTP/3 connection. Facebook Inc. Apple Inc. Apple Inc. Mozilla Google Facebook Inc. WebTransport defines a set of low-level communications features designed for client-server interactions that are initiated by Web clients. This document describes a protocol that can provide many of the capabilities of WebTransport over HTTP/2. This protocol enables the use of WebTransport when a UDP-based protocol is not available. Adobe Fastly greenbytes GmbH The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or s and long polling). [STANDARDS-TRACK] This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA. This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Informative References This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. Akamai The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.

Acknowledgments Parts of the text were rephrased using ChatGPT. Portions of this document are based upon a modification of text parts from the underlying standards.