Internet-Draft moq-uri October 2026
Jennings & Nandakumar Expires 10 April 2027 [Page]
Workgroup:
Media Over QUIC
Internet-Draft:
draft-jennings-moq-uri-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
C. Jennings
Cisco
S. Nandakumar
Cisco

MOQT URI and Discovery

Abstract

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.

About This Document

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.

Status of This Memo

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.

1. Introduction

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:

MOQT URI Scheme (Section 3):

Defines the moqt URI syntax, fragment identifiers, and dereferencing procedures.

URI Normalization (Section 4):

Specifies canonical forms for comparison and certificate matching.

X.509 Certificate Matching (Section 5):

Rules for validating server certificates against moqt URIs.

SVCB Records (Section 6):

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.

SRV Records (Section 7):

Unicast DNS records that provide port and target information for load balancing and failover.

mDNS and DNS-SD (Section 8):

Multicast DNS [RFC6762] and DNS Service Discovery [RFC6763] for local network discovery without a central DNS server.

2. Conventions and Definitions

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.

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

3.1. Fragment Identifiers

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.

3.2. Dereferencing a MOQT URI

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.

4. URI Normalization

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.

5. X.509 Certificate Matching

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".

5.1. WebTransport Certificate Validation

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.

5.2. SVCB and SRV Indirection

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.

6. SVCB Records for MOQT

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).

6.1. SVCB Record Name

For a moqt URI with host H and port P, the SVCB owner name is:

  • _moqt.H when P is 443 or omitted (defaulting to 443).

  • _P._moqt.H when P is any other value.

6.2. Default ALPN Identifiers

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.

6.3. Automatically Mandatory SvcParamKeys

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.

6.4. Relevant SvcParamKeys

6.4.1. alpn and no-default-alpn

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.

6.4.2. port

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.

6.4.3. ech

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]).

6.4.4. ipv4hint and ipv6hint

MAY be used to provide address hints that reduce DNS round trips. Hints are advisory and do not replace A/AAAA resolution.

6.5. ALPN Selection

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.

7. SRV Records for MOQT

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.

7.1. SRV Record Names

For a moqt URI with host H, SRV queries are performed at:

  • _moqt._udp.H

7.2. Using SRV Target and Port

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.

7.3. Interaction with SVCB

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.

8. mDNS and DNS-SD Discovery for MOQT

mDNS [RFC6762] and DNS-SD [RFC6763] enable MOQT discovery on local links without a central DNS server.

8.1. DNS-SD Service Names

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].

8.2. TXT Record Parameters

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.

8.3. Interaction with SVCB

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.

9. Security Considerations

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.

10. IANA Considerations

10.1. Service Name Registration

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]).

10.2. URI Scheme Registrations

This document requests the registration of the following URI schemes in the "Uniform Resource Identifier (URI) Schemes" registry, per [RFC7595]:

10.2.1. "moqt" URI Scheme Registration

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

11. References

11.1. Normative References

[moq-transport]
Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-22, , <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-22>.
[RFC1035]
Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, , <https://www.rfc-editor.org/rfc/rfc1035>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2782]
Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, , <https://www.rfc-editor.org/rfc/rfc2782>.
[RFC3596]
Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, , <https://www.rfc-editor.org/rfc/rfc3596>.
[RFC3986]
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <https://www.rfc-editor.org/rfc/rfc3986>.
[RFC4985]
Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, DOI 10.17487/RFC4985, , <https://www.rfc-editor.org/rfc/rfc4985>.
[RFC5280]
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5890]
Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, , <https://www.rfc-editor.org/rfc/rfc5890>.
[RFC6762]
Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, , <https://www.rfc-editor.org/rfc/rfc6762>.
[RFC6763]
Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, , <https://www.rfc-editor.org/rfc/rfc6763>.
[RFC7301]
Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, , <https://www.rfc-editor.org/rfc/rfc7301>.
[RFC7595]
Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, , <https://www.rfc-editor.org/rfc/rfc7595>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8615]
Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, , <https://www.rfc-editor.org/rfc/rfc8615>.
[RFC9460]
Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, , <https://www.rfc-editor.org/rfc/rfc9460>.
[RFC9525]
Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, , <https://www.rfc-editor.org/rfc/rfc9525>.

11.2. Informative References

[RFC6943]
Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, , <https://www.rfc-editor.org/rfc/rfc6943>.
[RFC7838]
Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, , <https://www.rfc-editor.org/rfc/rfc7838>.
[RFC8499]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 8499, DOI 10.17487/RFC8499, , <https://www.rfc-editor.org/rfc/rfc8499>.
[RFC9110]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9580]
Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe, "OpenPGP", RFC 9580, DOI 10.17487/RFC9580, , <https://www.rfc-editor.org/rfc/rfc9580>.
[WebTransport]
Frindell, A., Kinnear, E., and V. Vasiliev, "WebTransport over HTTP/3", Work in Progress, Internet-Draft, draft-ietf-webtrans-http3-16, , <https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-16>.

Acknowledgments

TODO: Acknowledgments to be added.

Authors' Addresses

Cullen Jennings
Cisco
Suhas Nandakumar
Cisco