MOQT URI Scheme — MoQT draft-21 §6.1.

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 6.2.1), so the path-abempty and query components use the same syntax as https URIs.

6.1.1. Fragment Identifiers

The media type for resources identified by moqt URIs is application/moqt (see Section 16.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 16.3).

6.1.2. Dereferencing a MOQT URI

The default operation for dereferencing a moqt URI is to establish a MOQT session to the identified server.

The moqt URI scheme has the following security considerations:

The authority component is sent in the TLS SNI extension during connection establishment, exposing the target server identity to on-path observers. Encrypted Client Hello (ECH) [RFC9580] can mitigate this exposure.
The path-abempty and query components are visible to the relay that terminates the client's connection.

TODO: Add internationalization statement per RFC 7595 Section 3.6.

The client resolves the host subcomponent of the authority to one or more network addresses, most commonly using DNS A [RFC1035] and AAAA [RFC3596] records.

When SVCB-compatible records [RFC9460] are published for the authority, a client MAY use them to learn the server's endpoints and supported ALPN protocols before connecting. A client using WebTransport resolves the https URI derived in Section 6.2.1 using HTTPS resource records as for any https origin. TODO: reference moqt SVCB record draft once available.

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 6.2.2. If the server selects h3, the client establishes a WebTransport session as described in Section 6.2.1. On a TCP+TLS connection, the client offers h2 in its TLS ClientHello and establishes a WebTransport session as described in Section 6.2.1.