URL syntax identifying both connection and track

[wilaw]

It would be convenient to be able to represent both a connection to a MOQT endpoint and a WARP catalog track as a URL. This would allow a Content Management System to vend a single URL to a player which would give it the information it needs to both connect to a MOQT distribution network (MDN) and discover a catalog track.

WebTransport endpoints have the form of a http3 connection and may have several path segments for business purposes

https://mdn.com/customerID/appID

A track can be represented as a namespace + name as a pseudo relative URL

example.com/live/broadcastID/catalog

We can combine these and add in an access token

https://mdn.com/customerID/appID/example.com/live/broadcastID/catalog?token=12345

The MDN will know which segments its needs to parse to accept the connection. However, how does the player know where the namespace begins in order to issue the SUBSCRIBE? Some options:

1. The player knows through some out-of-band information and we don't need to tell it. This seems fragile for interop.

2. We specify that the first segment after the hostname is always reserved for the connection. Separators other than / may be used by the MDN vendor to provide ancillary information.

https://mdn.com/customerID-appID/example.com/live/broadcastID/catalog?token=12345

3. We create a reserved path segment which identified the division between the two. In this case we use '!'

https://mdn.com/customerID/appID/!/example.com/live/broadcastID/catalog?token=12345

A second problem is that we need to tell the player that the query arg holds a token which should be extracted and supplied via the AUTHORIZATION TOKEN setup parameter , as well as a token for SUBSCRIBE, PUBLISH etc. For this, we can reserve a query arg name , for example 'warp-token'. Providers are not required to supply a token in this fashion (they may vend it as a separate asset to the player), but at least it provides an interoperable methd of providing a token to players which the content distributor does not control.

https://mdn.com/customerID/appID/!/example.com/live/broadcastID/catalog?warptoken=12345

[vasilvv]

The only viable way forward here I can think of is putting the track name into the fragment (e.g. define fragment as base64 encoding of serialized full track name); the rest URL is already taken for the HTTP URL itself.

[wilaw]

@vasilvv - do we need to serialize the full track name to base64? Having it human readable for debugging is a nice feature and we can constrain WARP full track names to not include #,?, and &

https://mdn.com/customerID/appID?warptoken=12345#example.com/live/broadcastID/catalog

[vasilvv]

For MOQT in general, we'd need base64. For WARP, I can imagine that would work, as long as we limit what characters we allow in track names.

[afrind]

I'm still confused about what happens when this URL is sent on the wire in a WebTransport CONNECT request. Does it imply a SUBSCRIBE to the named track? What about version negotiation, other parameters to SUBSCRIBE, or joining FETCH?

I understand why we need a single string to get started, but perhaps we can make it more of an API that instructs the user-agent to CONNECT and then SUBSCRIBE once the session is established, rather than sending the full URL in CONNECT.

[wilaw]

I'm still confused about what happens when this URL is sent on the wire in a WebTransport CONNECT request. Does it imply a SUBSCRIBE to the named track?

No, it doesn't auto subscribe. The CDN will use the URL to route to an edge relay and potentially look at some path components for further mapping or auth. Akamai routes purely on the hostname, but other CDNs are different. The fragment would get ignored by whole CONNECT mechanism. The player could strip off the fragment before making the CONNECT request, or send it, at the player's choice.

The WARP player would then use the fragment to issue a separate SUBSCRIBE following a successful CONNECT and setup.

but perhaps we can make it more of an API that instructs the user-agent to CONNECT and then SUBSCRIBE once the session is established

We could, but then we'd have to serialize all the current SUBSCRIBE options that the player might use. I don't think the CMS, which is vending the URL, should be in control of those. All we need to do is communicate the namespace and name of the catalog to the player. I also donlt think startup time will be hurt with a separate SUBSCRIBE, as Webtransport allows you to send streams immediately behind a CONNECT without waiting 1xRTT for notification of the successful connect.

[michalhosna]

After a couple of hallway discussions about this in Toronto, I have a few questions.
Why use the https scheme at all if we expect the URL to be interpreted by the MOQ application anyway?

What should happen if a basic GET or HEAD request is sent to that URL? Do we expect any handling there?
If we are passing https URLs around, such requests will likely be sent anyway. Users might click on them, applications may try to unfurl them, etc.

Wouldn’t it be better to use a custom scheme? That way, we wouldn’t have to comply with HTTP URL limitations, and we wouldn’t run into problems caused by applications expecting certain behavior.

Sorry if this was already discussed, but I couldn’t find it.

[wilaw]

The request to a webtransport connection HAS to be a https:// request - at least in a browser context. . It then gets upgraded to a WebTransport connection. IF a HEAD or GET request is directed at the same end-point without the :protocol extension, then it would get immediately rejected.

The steps are:

1. Establish QUIC/HTTP/3: The client first establishes a QUIC connection to the server. During the handshake, ALPN (Application-Layer Protocol Negotiation) is used to select the HTTP/3 application protocol.

2. Extended CONNECT Request: The client sends an HTTP CONNECT request on an HTTP/3 stream, but with an extension that signals the intent to switch to WebTransport. The key difference from a standard HTTPS CONNECT (used for proxies) is the inclusion of the :protocol pseudo-header field:

:method: CONNECT
:scheme: https
:authority: server.example.com
:protocol: webtransport ⬅️ Signals the WebTransport protocol
Server Response and Upgrade: If the server supports WebTransport, it responds with an HTTP 200 (OK) status code. This successful response signals the upgrade of that specific HTTP/3 stream.

3. WebTransport Session: After the 200 response, the stream is no longer used for HTTP/3 messages. It is repurposed as the control stream for the new WebTransport session, allowing the client and server to start exchanging data via WebTransport streams and datagrams, which are built on top of QUIC.

If we invent a custom scheme, then it won't work in a few billion web browsers (including all the current MOQ demos) which is not a desirable outcome. The advantage of URL-syntax is that it can be made to work consistently across all client application environments.

For those not connecting to raw QUIC instead of Webtransport, we could simply replace the protocol in the URL, for example

moqt://example.com/app/namespace/name/catalog

[michalhosna]

The request to a webtransport connection HAS to be a https:// request

Why couldn't the application change the scheme before it hands over to the browser?
Here, we expect that the MOQ application will need to process the URL (to strip out parts) anyway.

[wilaw]

Why couldn't the application change the scheme before it hands over to the browser?
Here, we expect that the MOQ application will need to process the URL (to strip out parts) anyway.

How would the player know what to change the scheme to? You could code up a format were you communicate the protocol, the host address and the catalog namespace and name, for example

https|example.com/app|namespace/name/catalog

but aren't you then just reinventing a URL with another name? Or do you have another scheme in mind?

[michalhosna]

I am not sure if I understand what you are asking. I'll try to expand.

The scheme doesn't have to be related to transport. E.g. https:// works for H1,H2,H3 with widely different transports and on-wire encodings.

Let's say we agree on a URL format like this one:

moqt://mdn.com/customerID/appID#example.com/live/broadcastID/catalog

We can define in spec, that a client that sees this URL parses authority, path and a fragment, then either

1. Connects over raw QUIC and send authority + path as defined in moqt now
2. Connects over WebTransport, in which case it tries to connect to https://authority/path

This would allow us to also unify raw QUIC and WebTransport connection URI. Which should go to MOQT spec.
Then this spec can say that a fragment is always sent inside the connection and we are not limited by http(s) URL spec.

As I see it, we can define any application URL handling we want here if we define a custom scheme. The more I think about it the more reasons against https I see.

but aren't you then just reinventing a URL with another name?

We need to define some URL handling somehow in the protocol anyway. The application has to parse the URL anyway.

I apologize if I'm misunderstanding and diverting the discussion completely off track.

[wilaw]

moqt://mdn.com/customerID/appID#example.com/live/broadcastID/catalog is still a URL. It is just a URL with a non-https protocol. So it would still need to comply with rules for paths, URls and fragments. However something like

moqt--8812--example.com/live/broadcastID/catalog

or

https--443--mdn.com/customerID/appID--example.com/live/broadcastID/catalog

would be custom and I agree we could specify our own rules.

[michalhosna]

There were voices in Toronto that following "http URL" limits would be harder than just "plain URL" limits. But I am not a URL/URI nor IETF expert.

My main point is that using https is a bad idea, with several disadvantages mentioned above.

I do see some reasons for using a custom scheme over completely custom format but I do not have a strong position on that at the moment.

[wilaw]

Discussion with Michal & Will. Some conclusions:

1. We should not use https URLs. Reason for this is that these endpoints are expected to respond to GET/POST requests and much of the internet workflow is built upon this supposition (auto thumbs in Slack for example). Also, #fragment interpretation is MIME-TYPE dependent and it is not currently specified for Webtransport responses. Currently IETF WebTransport explicitly forbids the use of fragments in connection requests.
2. A scheme which is MOQT specific allows us to control client and server behavior without inheriting assumptions and workflows from a HTTP world.
3. We propose a URI syntax comprised of the following

moqt:// + authority + path + query + fragment

along with the following processing rules

• The authority is required and holds the host and optional port. The default port will be 443.
• The path is optional and holds data that will be transferred to the server during both a Webtransport and raw QUIC connection
• The query is optional and holds application defined key-value data
• The fragment is optional and if present, defines the full-track name of the catalog.
• if the client wishes to use a WebTransport connection, it must replace the moqt protocol with https and strip the fragment from the connection URI.
• the '/' character in the fragment defines tuple field boundaries.
• the whole URL is URLEncoded, as defined by RFC 3986, particular Section 2.1 Percent-Encoding.

Some examples:

moqt://example.com:4433/customerID/appID?token=12345#example/live/broadcastID/catalog

The client would connect to the CDN using either

https://example.com:4433/customerID/appID?token=12345 (WebTransport)
then SUBSCRIBE example/live/broadcastID/catalog

or

moqt://example.com:4433 AUTHORITY=example.com:4433 ``PATH=/customerID/appID?token=12345 (raw QUIC)
then SUBSCRIBE example/live/broadcastID/catalog

If a content distributor wanted to implement an autosubscribe scheme, in which the server immediately subscribes upstream for the catalog, and then publish it to the client, it could do it by ensuring that the full track name is included in the path. The CDN would also need a config option to execute this behavior.

moqt://example.com:4433/customerID/appID?autosubscribe=example/live/broadcastID/catalog

[gwendalsimon]

Brilliant, thank you!

I understand that the "#" and what follows is the "fragment", which instructs the client where to SUBSCRIBE. Some questions here:

• Does it restrict to "catalog" track? I guess any track can be given
• What if we would like to instruct the client to FETCH a track? One way could be to indicate #action=SUBSCRIBE;tn=example/live/broadcastID/catalog
• If we go in this direction, then, for FETCH typically (also applies to SUBSCRIBE), we want to indicate some extra-parameters. For example, if we want to instruct a consumer to watch a goal, it would be something like: #action=FETCH;tn=example/live/broadcastID/video;param=standalone;param=start=(16437,0),end=(16749,0) or something in this spirit.

Have you discussed it too?