| Internet-Draft | moq-uri | October 2026 |
| Jennings & Nandakumar | Expires 10 April 2027 | [Page] |
This document defines the moqt URI scheme, URI resolution mechanisms,
and discovery methods for the Media over QUIC Transport (MOQT) protocol.
It specifies the URI syntax, fragment identifiers, dereferencing
procedures, normalization rules, and X.509 certificate matching for
moqt URIs. It also defines DNS-based resolution using SVCB and SRV
records, as well as local network discovery via mDNS and DNS-SD.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-jennings-moq-uri/.¶
Discussion of this document takes place on the Media Over QUIC Working Group mailing list (mailto:moq@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/moq/. Subscribe at https://www.ietf.org/mailman/listinfo/moq/.¶
Source for this draft and an issue tracker can be found at https://github.com/suhasHere/draft-jennings-moq-uri.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 10 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Media over QUIC Transport (MOQT) protocol [moq-transport] identifies
servers using the moqt URI scheme. Clients establish MOQT sessions over
native QUIC or over WebTransport ([moq-transport], Section 3).¶
This document consolidates the URI definition, resolution, and discovery aspects of MOQT into a single specification. It is organized as follows:¶
Defines the moqt URI syntax, fragment identifiers, and dereferencing
procedures.¶
Specifies canonical forms for comparison and certificate matching.¶
Rules for validating server certificates against moqt URIs.¶
Unicast DNS records that carry connection parameters — including supported
ALPNs — alongside address records for native QUIC endpoints. Section 2.4
of [RFC9460] requires a mapping document for each URI scheme using SVCB;
this document fulfills that requirement for moqt. For WebTransport,
standard HTTPS resource record processing applies to the derived https
URI.¶
Unicast DNS records that provide port and target information for load balancing and failover.¶
Multicast DNS [RFC6762] and DNS Service Discovery [RFC6763] for local network discovery without a central DNS server.¶
This specification uses the terminology from [RFC3986], [RFC5280], and [RFC9525].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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
[moq-transport], Section 6.2.1), so the path-abempty and query
components use the same syntax as https URIs.¶
The media type for resources identified by moqt URIs is
application/moqt.¶
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.¶
The default operation for dereferencing a moqt URI is to establish a
MOQT session to the identified server. See
Section 9 for the security implications of
dereferencing a moqt URI.¶
A moqt URI can be dereferenced over two distinct transports
([moq-transport], Section 3):¶
Native QUIC, where the client opens a QUIC connection directly to the
authority of the moqt URI and negotiates a moqt/moqt-N ALPN.¶
WebTransport, where the moqt URI is first mapped to an https URI
([moq-transport], Section 6.2.1) and the client establishes a
WebTransport session over HTTP/3 (ALPN h3) or HTTP/2 (ALPN h2)
to that https origin.¶
The two transports use different DNS resolution and certificate validation procedures, summarized below.¶
For the native QUIC transport, when moqt-specific SVCB records are
published for the authority (Section 6), the client MAY use them to
learn the server's endpoints and moqt/moqt-N ALPNs before
connecting. When those records are not available, the client falls
back to SRV records (Section 7) or, on a local link, uses mDNS and DNS-SD
(Section 8). Otherwise the client resolves the host subcomponent of
the authority to one or more network addresses using DNS A
[RFC1035] and AAAA [RFC3596] records. If the port is omitted in
the URI, a default port of 443 is used. The server's X.509
certificate MUST be validated against the original moqt URI
authority as described in Section 5, and the URI MUST be
normalized as specified in Section 4 before certificate
comparison.¶
For the WebTransport transport, the client applies standard https
processing to the derived https URI: HTTPS resource records
([RFC9460]) are resolved as for any https origin, and the server's
X.509 certificate matching following the same procedures as defined
for native QUIC. No moqt-specific DNS records are
consulted on this path.¶
For comparison purposes, the URI, or part of the URI, is put in a canonical form and then bitwise compared to the data from the X.509 certificate after putting it into canonical form. This section defines how to create the canonical form.¶
The URI MUST be normalized using Case Normalization and Percent-Encoding Normalization as specified in Sections 6.2.2.1 and 6.2.2.2 of [RFC3986].¶
The "." and ".." sequences have no special meaning in MOQT URIs and are not changed during normalization.¶
If the port is missing, it MUST be replaced with the default port (443).¶
If the URI reg-name ends in a ".", that MUST be removed.¶
Internationalized Domain Names in the reg-name MUST be converted to IDNA format as defined in [RFC5890].¶
When comparing hostnames, wildcard matching MUST NOT be supported and the "*" character has no special meaning.¶
The fields referenced in this section are defined in [RFC5280] and [RFC4985].¶
The CN-ID field as defined in [RFC9525] MUST NOT be used.¶
Clients MUST implement dNSName, uniformResourceIdentifier and iPAddress matching.¶
If any one of the following identifiers in the subjectAltName of the certificate matches the URI, then the certificate is valid for that URI.¶
dNSName: The canonicalized dNSName from the certificate matches the host part of the authority from the canonicalized URI.¶
iPAddress: The host part of the authority from the canonicalized URI, parsed as an IP address, matches the iPAddress value from the certificate.¶
uniformResourceIdentifier: The canonicalized uniformResourceIdentifier MUST match the canonicalized URI with the query and fragment removed.¶
SRVName: Matched as described in Section 4 of [RFC4985] using the host part of the authority from the canonicalized URI as the name restriction and a SRVName restrictions of "_moqt".¶
When connecting via WebTransport, the TLS handshake terminates at an
https origin derived from the moqt URI ([moq-transport], Section 6.2.1). In this case, the client validates the server
certificate against that https URI using standard Web PKI procedures;
the moqt-specific matching rules above do not apply. The TLS SNI
extension MUST contain the host from the derived https URI.¶
The moqt-specific certificate matching defined in this section applies
only to native QUIC connections where the client connects directly to
the authority of the moqt URI. On such connections the TLS SNI
extension MUST contain the host from the original moqt URI.¶
When a client is redirected to a different target host via SVCB or SRV,
certificate matching MUST be performed against the authority from the
original moqt URI, not the resolved target name. The TLS SNI
extension likewise MUST contain the original authority's host. This is
consistent with the requirements in [RFC9460], Section 2.3 and with
the SRV rules in Section 7 of this document.¶
SRVName matching ([RFC4985]) applies regardless of whether the client
discovered the endpoint via SRV records or SVCB records, because the
_moqt service type is the same in both cases.¶
MOQT defines SVCB records [RFC9460] for native QUIC endpoints.
For WebTransport, a moqt URI maps to an https URI
([moq-transport], Section 6.2.1); the client resolves that https
URI using HTTPS resource records following standard https processing
rules ([RFC9460], Section 9.1).¶
For a moqt URI with host H and port P, the SVCB owner name is:¶
Unlike https (which implies h2/h3), the moqt URI scheme has no
implicit default ALPN. Every ServiceMode record MUST include an explicit
alpn SvcParamKey listing all supported protocols.¶
The following ALPN identifiers are defined for MOQT:¶
moqt:Connected with raw QUIC, published MOQT specification.¶
moqt-N (where N is a non-negative integer):Connect with raw QUIC using draft version N (e.g., moqt-15) of
the MOQT Transport draft.¶
Note to RFC Editor: Remove this bullet point in RFC¶
A client MUST treat a record whose alpn contains none of its supported
identifiers as unusable and proceed as if no record were present.¶
TODO: Define ALPN identifier and record-placement rules for qmux once the qmux specification matures.¶
The moqt scheme introduces no additional automatically mandatory
SvcParamKeys; standard [RFC9460] processing rules apply. Omitting alpn
is equivalent to publishing a record with no supported protocols
(Section 6.2), which clients will treat as unusable.¶
The alpn SvcParamKey MUST be present in every ServiceMode record
(see Section 6.2). The no-default-alpn SvcParamKey MUST NOT
appear; with no default ALPNs defined, it has no effect and would be
misleading.¶
When present, port specifies the UDP port for the native QUIC
endpoint. When absent, the port from the moqt URI is used,
defaulting to 443.¶
ECH [RFC9580] MAY appear in SVCB records. Clients that
support ECH SHOULD use it; without it, the moqt URI authority is
exposed in the TLS SNI extension ([moq-transport]).¶
MAY be used to provide address hints that reduce DNS round trips. Hints are advisory and do not replace A/AAAA resolution.¶
A client uses the alpn SvcParamKey to determine which connection modes
the server supports and connects using any ALPN identifier from the record
that it supports. Selection among multiple supported ALPNs is a matter of
local client policy and is out of scope for this document.¶
SRV records [RFC2782] provide port and target for load balancing and failover but carry no ALPN or connection parameters. SRV support is retained because it is required by DNS-SD (Section 8) and provides a transitional fallback for the native QUIC path in deployments where SVCB infrastructure is not yet available.¶
For a moqt URI with host H, SRV queries are performed at:¶
_moqt._udp.H¶
When SRV records are found:¶
The target hostname and port from the SRV record MUST be used as the connection endpoint.¶
The original moqt URI's host component MUST be used as the TLS
SNI value and for certificate validation; it MUST NOT be replaced by
the SRV target hostname.¶
SRV targets with a port of 0 and a dot (.) target indicate that the
service is not available at this name and MUST be treated as indicating
no service.¶
When SVCB records are available and usable for a moqt authority,
clients SHOULD prefer them over SRV records and MAY skip the SRV query
entirely.¶
Operators SHOULD publish SVCB records rather than (or in addition to) SRV records for new deployments.¶
mDNS [RFC6762] and DNS-SD [RFC6763] enable MOQT discovery on local links without a central DNS server.¶
MOQT uses the following DNS-SD service types, which are also registered for SRV use (Section 10.1):¶
_moqt._udp:Advertises MOQT endpoints (native QUIC and WebTransport over HTTP/3).¶
A MOQT relay on the local network announces itself by publishing PTR,
SRV, and TXT records under the appropriate service type in the .local.
domain, as specified in [RFC6763].¶
The TXT record for a MOQT DNS-SD instance MUST contain the following key-value pair:¶
alpn:The ALPN identifier for the transport mode advertised by this instance
(e.g., moqt, moqt-15, h3).¶
A client MUST treat an instance whose TXT record does not contain a
recognized alpn value as unusable.¶
This document does not define SVCB-based service parameter delivery for MOQT DNS-SD instances; the TXT record (Section 8.2) is the sole mechanism for conveying ALPN information in DNS-SD.¶
Dereferencing a moqt URI exposes the following information to on-path
observers and intermediaries:¶
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: Expand this section with additional considerations.¶
IANA is requested to register the following entry in the "Service Name and Transport Protocol Port Number Registry":¶
Service Name: moqt¶
Transport Protocol(s): udp¶
Assignee: IETF¶
Contact: moq@ietf.org¶
Description: Media over QUIC Transport¶
Reference: This document and [moq-transport]¶
Port Number: 443¶
This registration covers use of the _moqt._udp service label in SRV
records ([RFC2782]) and DNS-SD ([RFC6763]).¶
This document requests the registration of the following URI schemes in the "Uniform Resource Identifier (URI) Schemes" registry, per [RFC7595]:¶
Scheme name: moqt¶
Status: Permanent¶
Applications/protocols that use this scheme name: Media over QUIC Transport (MOQT) over native QUIC or WebTransport, as defined in this document.¶
Contact: IETF MoQ Working Group (moq@ietf.org)¶
Change controller: IETF¶
References: This document¶
TODO¶
TODO: Acknowledgments to be added.¶