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 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.
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 a MoQ 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 path-abempty
and query portions of the URI are communicated to the server using the
PATH parameter (Section 8.3.2.1) which is sent in the CLIENT_SETUP message at the
start of the session. The ALPN value [RFC7301] used by the protocol
is moq-00.
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).