This document defines a protocol that can be used interchangeably both over a QUIC connection directly [QUIC], and over WebTransport [WebTransport]. Both provide streams and datagrams with similar semantics (see [I-D.ietf-webtrans-overview], Section 4); thus, the main difference lies in how the servers are identified and how the connection is established. The QUIC DATAGRAM extension ([RFC9221]) MUST be supported and negotiated in the QUIC connection used for MOQT, which is already a requirement for WebTransport over HTTP/3.
There is no definition of the protocol over other transports, such as TCP, and applications using MOQT might need to fallback to another protocol when QUIC or WebTransport aren't available.
MOQT uses ALPN in QUIC and "WT-Available-Protocols" in WebTransport ([WebTransport], Section 3.3) to perform version negotiation.
The ALPN value [RFC7301] for the final version of this specification
is moqt.
[[RFC editor: please remove the remainder of this section before publication.]]
ALPNs used to identify IETF drafts are created by appending the draft number to "moqt-". For example, draft-ietf-moq-transport-13 would be identified as "moqt-13".
Note: Draft versions prior to -15 all used moq-00 ALPN, followed by version negotiation in the SETUP messages.
6.2.1. WebTransport
When the client uses WebTransport, it constructs an https URI from the moqt
URI by replacing the scheme with https.
For example, moqt://example.com/path becomes
https://example.com/path. The client sends an extended CONNECT request to this
URI to establish a WebTransport session, as described in
([WebTransport], Section 3). The client includes MOQT protocol identifiers in
the WT-Available-Protocols header ([WebTransport], Section 3.3).
6.2.2. Native QUIC
The client establishes a QUIC connection to the host and port identified by the
authority section of the URI.
When the client uses native QUIC, the authority, path-abempty and query
portions of the URI are transmitted in Setup Options (see Section 9.1).