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. The RESET_STREAM_AT [I-D.draft-ietf-quic-reliable-stream-reset] extension to QUIC can be used by MOQT, but the protocol is also designed to work correctly when the extension is not supported.
There is no definition of the protocol over other transports, such as TCP, and applications using MoQ 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.
[[RFC editor: please remove the remainder of this section before publication.]]
The ALPN value [RFC7301] for the final version of this specification
is moqt. 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 CLIENT_SETUP and SERVER_SETUP messages.
3.1.1. WebTransport
An MOQT server that is accessible via WebTransport can be identified using an HTTPS URI ([RFC9110], Section 4.2.2). An MOQT session can be established by sending an extended CONNECT request to the host and the path indicated by the URI, as described in ([WebTransport], Section 3).
3.1.2. QUIC
An MOQT server that is accessible via native QUIC can be identified by a URI with a "moqt" scheme. The "moqt" URI scheme is defined as follows, using definitions from [RFC3986]:
moqt-URI = "moqt" "://" authority path-abempty [ "?" query ]
The authority portion MUST NOT contain an empty host portion.
The moqt URI scheme supports the /.well-known/ path prefix defined in
[RFC8615].
This protocol does not specify any semantics on the path-abempty and
query portions of the URI. The contents of those are left up to the
application.
The client can establish a connection to an MOQT server identified by a given
URI by setting up a QUIC connection to the host and port identified by the
authority section of the URI. The authority, path-abempty and query
portions of the URI are also transmitted in SETUP parameters (see
Section 9.3.1). If the port is omitted in the URI, a default port of 443 is
used for setting up the QUIC connection.
3.1.3. Connection URL
Each track MAY have one or more associated connection URLs specifying network hosts through which a track may be accessed. The syntax of the Connection URL and the associated connection setup procedures are specific to the underlying transport protocol usage (see Section 3).