WebTransport over WebSocket

3.1. Connection and version negotiation

The WebSocket connection is established according to Section 4 of [WEBSOCKET] or [WEBSOCKET-H2].¶

When a WebSocket connection is established, both the client and server select the WebTransport-Websocket protocol by setting |Sec-WebSocket-Protocol| Section 1.9 of [WEBSOCKET] 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 Section 4.1 of [WEBSOCKET] and Section 4.2.2 of [WEBSOCKET]. No protocol extensions MUST BE negotiated.¶

3.2. Data framing

The protocol uses the data frames as defined in Section 5 of [WEBSOCKET]. PING and PONG frame handling is not changed Section 5.5 of [WEBSOCKET].¶

The CLOSE frame Section 5.5.1 of [WEBSOCKET] replaces the mechanism invoked after CONNECT stream closure in Section 2 of [WEBTRANSPORT-H2]. The body MUST include a UTF-8 encoded reason string when transmitted by a protocol-aware client or server. The reason string has the form "CODE:REASONSTRING", where CODE is a text representation of an unsigned 32-bit decimal integer in the range of between 0x00000000 and 0xffffffff Section 4.3 of [WEBTRANSPORT-H3]. REASONSTRING is the actual reason transmitted through WebTransport. A close FRAME without a reason may be sent by protocol-unaware WebClients or proxies. In such instances, the CODE and REASONSTRING are reconstructed using the WebSocket Close Code Number as specified in the WebSocketCloseCode Registry outlined in Section 11.7 of [WEBSOCKET].¶

Data Frames containing Text are reserved for future use and MUST NOT be sent. Binary Data Frames transport CAPSULE content defined in [WEBTRANSPORT-H2] and [DATAGRAM]. For details, refer to the next section Section 3.3. Their length is limited by WebTransport flow control, and a violation SHOULD lead to connection termination. CONTINUATION frames are processed per [WEBSOCKET] specifications. Given the streaming nature of the content, partial DATA frames or CONTINUATION frames should be promptly forwarded to corresponding streams reducing latency.¶

3.3. Capsule frames

This protocol adopts the mechanisms and intrinsic elements outlined in [WEBTRANSPORT-H2], which itself is constructed upon the CAPSULE protocol originating from [DATAGRAM].¶

A CAPSULE has the form in [DATAGRAM]:¶

Capsule {
  Capsule Type (i),
  Capsule Length (i),
  Capsule Value (..),
}

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:¶

WebSocketDataFrameCapsule {
  FrameHeader (..),
  PayloadData (..)
}

FrameHeader contains the first two bytes of the FRAME, and if present the extended payload length and masking key as defined in Section 5.2 of [WEBSOCKET]. PayloadData is defined as:¶

PayloadData {
  Capsule Type (i),
  Capsule Value (..)
}

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 Section 5.2 of [WEBSOCKET]:¶

  Capsule Length = Payload Length - sizeof(Capsule Type),

as no Extension Data is allowed.¶

3.4. Replacement for SETTINGS

Section 3.1 of [WEBTRANSPORT-H2] 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 Section 3.4 of [WEBTRANSPORT-H2] 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.¶

6.1. 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.¶

6.2. 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 [RFC5226].¶

As part of this registry, IANA manages the following information (similar to [WEBSOCKET] versions):¶

Version String The version string name as part of the subprotocol defined in Section 6.1 and Section 3.1. 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 [RFC5226] 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 [RFC5226] applies to the "Interim" version names. The initial Designated Experts need to be determined.¶