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.
3.1.1. MOQT URI Scheme
An MOQT server is identified using a URI with the "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].
The moqt URI scheme follows the generic URI syntax of [RFC3986] for
the authority, path-abempty, and query components, including the
use of reserved characters and percent-encoding defined therein. A moqt
URI can be converted to an https URI by replacing the scheme (see
Section 3.1.4), so the path-abempty and query components use the same
syntax as https URIs.
3.1.2. Fragment Identifiers
The media type for resources identified by moqt URIs is
application/moqt (see Section 15.2).
Fragment identifiers MAY be used with moqt URIs. The fragment is not
transmitted to the server; it is processed locally by the client after
establishing the MOQT session.
A moqt URI fragment MUST begin with a registered fragment type
identifier, followed by a colon (:), followed by a type-specific value:
moqt://example.com/app#<type>:<value>
Fragment type identifiers MUST consist of ASCII lowercase letters,
digits, and hyphens (a-z, 0-9, -). The
semantics of the value after the colon are defined by the specification
that registers the fragment type.
Fragment type identifiers are registered in the "MOQT URI Fragment Types" registry (Section 15.3).
3.1.3. Dereferencing a MOQT URI
The default operation for dereferencing a moqt URI is to establish a
MOQT session to the identified server.
TODO: Add URI scheme security considerations per RFC 7595 Section 3.7 (e.g., authority in SNI, path/query exposure).
TODO: Add internationalization statement per RFC 7595 Section 3.6.
If the port is omitted in the URI, a default port of 443 is used.
The client MAY use either native QUIC or WebTransport. On a QUIC connection,
the client offers any combination of MOQT ALPNs (e.g. moqt-1, moqt-2)
and h3 that it supports in its TLS ClientHello, in preference order. If the
server selects an MOQT ALPN, the session proceeds as described in
Section 3.1.5. If the server selects h3, the client establishes a
WebTransport session as described in Section 3.1.4. On a TCP+TLS
connection, the client offers h2 in its TLS ClientHello and establishes a
WebTransport session as described in Section 3.1.4.
3.1.4. 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).
3.1.5. 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 10.3.1).
3.1.6. 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).