Defining a connection URL syntax and method of connection

[wilaw]

Defines a URL syntax along with methods of connecting over WebTransport and raw QUIC.

Example URLs

• URL pointing at a catalog
  moqt://example.com/relay-app/relayID?ns=customerID/broadcastID

• URL pointing at a non-catalog track
  moqt://example.com/relay-app/relayID?ns=customerID/broadcastID&t=video

• URL pointing at a subclip of a catalog
  moqt://example.com/relay-app/relayID?ns=customerID/broadcastID&location-range=34-0-64-16

• URL pointing at a catalog and supplying a token

  moqt://example.com/relay-app/relayID?ns=customerID/broadcastID&c4m=gqhkYWxnIGVzaGFyqGR0eXB
  lY2NhdZ9hdWQAY3VybGZlbWlzcwZleWV2aW5uZWlhdGVwQWNyZW5lYnJmcmVqMTIzNDU2NzgwMHZpc3VlZF9hdD0xN
  zMwNDM4NDAw

Fixes #60

[michalhosna]

I apologize for the longish, nitpicky review, but I do think we need more clarity.

I am happy to help with integrating the commentary; I'm not sure what the best way there. Should I send my own counter-PR?

I think the story around the fragment was not really resolved, and I still think it's more elegant than this. But if we can get better consensus on the query, let's go this way.

[michalhosna]

As I read it, not sending query is incompatible with current MOQT wording, which defines moqt:// handling:

https://www.ietf.org/archive/id/draft-ietf-moq-transport-15.html#section-3.1.2

The client can establish a connection to an MOQT server identified by a given URI by setting up a QUIC connection to the host and port identified by the authority section of the URI. The authority, path-abempty and query portions of the URI are also transmitted in SETUP parameters (see Section 9.3.1).

Switching to a custom scheme sidesteps this problem. .

[michalhosna]

I think only reserved params should be stripped.

As MOQT defines "query," I think it is expected that query can be used to send data to the server, and I do think that we need to keep in some kind of custom extensibility similar to HTTP given that we are trying to replace HTTP in some contexts.

I do understand that it is not elegant.

[michalhosna]

What about leading /?

I am not sure if I am missing something, but neither MOQT nor WARP seem to disallow zero-sized components. So //a// could be ("", "", "a", "", "")?

EDIT: moq-wg/moq-transport#1041 talks about zero length fields

[michalhosna]

I do think we need to describe how to escape / if needed.

[michalhosna]

Is / allowed in t? Should it be always treated as literal here? I think it should be noted explicitly here that the parser for t must be diffent than for ns

[michalhosna]

What if only t is present?

[michalhosna]

Don't we want to support open ranges?

[michalhosna]

I think there needs to be commentary on percent encoding.

E.g. May I encode / as a tuple separator in the ns query arg? Or is that effectively escaping, and / must always be non encoded?

I think RFC3986 is insufficient for this use case, especially given it specifically mentions / in query section.

[michalhosna]

How does one use this range for non-catalog tracks?

[michalhosna]

I think wording from [7.1. ]Media Timeline track payload may be taken here.

"media presentation timestamp, rounded to the nearest millisecond"

Sidenote, why are we not using timescale, if catalog defines it? Now I am confusing myself. Does even LOC have PTS?

[vasilvv]

I am confused, is the URL intentionally does not specify the protocol that is used for connecting to the server?

Also, I am still not convinced that using query string is better than using the fragment.

[wilaw]

I am confused, is the URL intentionally does not specify the protocol that is used for connecting to the server?

Correct. The desire was for this to be at the determination of the client. Originally we had proposed a https://.. URL to indicate a Webtransport connection and moqt://... to indicate raw QUIC. However at IETF #123 there was pushback on this as the https:// URL could be assumed by many systems to have a HTTP GET response. See also this comment.

Also, I am still not convinced that using query string is better than using the fragment.

At the Toronto interim I did propose your fragment concept for the URL - see https://docs.google.com/presentation/d/1pFZ7kdp1s1CY2K6YgRQ1M_9tpwNIWK6j1gNuJj3UoJ0/edit?slide=id.g3630ee1ef9b_0_22#slide=id.g3630ee1ef9b_0_22. The concern was that a fragment response has a Mime-type associated with it and that the fragment construct of pointing at a subset of a resource was being abused to code in additional information not related to the resource. For this, flexible query arguments were considered a cleaner and more extensible fit. It was that feedback in Toronto which drove the establishment of this PR.

An additional issue with fragment is that there can be only one per URL. For MSF, we need to give the client both a namespace and a name (as they are applied separately in all MOQT messages). So we then need to create formatting rules for the fragment to separate namespace from name. At that point, you are inventing something that looks like KV pairs, so why not just use the well-understood scheme of query args?

[vasilvv]

Correct. The desire was for this to be at the determination of the client.

I don't understand the circumstances under which this would be useful. Usually I would expect a MOQT resource to be available either via WT or raw QUIC, but not both. A URL "provide a means of locating the resource by describing its primary access mechanism" (RFC 3986), so not knowing the protocol sounds like a glaring omission.

The #60 (comment) was that a fragment response has a Mime-type associated with it

We can register a media type for MOQT, if that is necessary.

that the fragment construct of pointing at a subset of a resource was being abused to code in additional information not related to the resource

The information is obviously related to the resource. I don't understand this objection.

flexible query arguments were considered a cleaner and more extensible fit

What if the application already uses some of those query parameters? RFC 8820, Section 2.4 discourages/proscribes this kind of approach for this reason in some scenarios.

For MSF, we need to give the client both a namespace and a name (as they are applied separately in all MOQT messages). So we then need to create formatting rules for the fragment to separate namespace from name.

I think Cullen has already attempted to do that in moq-wg/moq-transport#1355.

---

Actually, now that I think more about this, is there anything MSF-specific in this proposal? As far as I can tell, this basically explains how to access a MOQT track, so I do wonder if MOQT would be a more appropriate place for this.

[michalhosna]

I don't understand the circumstances under which this would be useful. Usually I would expect a MOQT resource to be available either via WT or raw QUIC, but not both.

I would expect that quite a lot of content may be available over both. Servers essentially have to support WebTransport for browsers. Supporting raw QUIC on the server is then straightforward, as one already has a QUIC stack anyway.
For clients, I would expect that non-browser clients could often implement QUIC only so as not to have an unnecessarily heavy HTTP stack. This is, of course, dependent on what we decide here.

A URL "provide a means of locating the resource by describing its primary access mechanism" (RFC 3986), so not knowing the protocol sounds like a glaring omission.

https:// currently means H1/H2/H3 with vastly different transports underlying it. I think it works fine in practice, and we do not have duplicate URLs representing the same resource. I do understand there is a fallback and discovery upgrade mechanism.

That discovery works even better here. Both clients and servers can do ALPN, signaling their preferred and supported protocols. No race or additional RTTs required.

I do not like having two schemes, as that would create an ecosystem split. Which is, in my opinion, unfavorable, and in this case unnecessary given the high similarity of raw QUIC and WT. If the stated goal is to have compatibility with existing CMS systems, having a single URL representing a single piece of content is favorable.

Also, what about WebTransport over H2? That one will have entirely different transport. Then having one scheme for raw QUIC and another for WT that would mean QUIC or TCP under the hood makes no sense to me. And having a different scheme from WT/H3 and WT/H2 would totally break a fallback use case.

If we introduce more than one scheme/URL format, I would expect we'll have one transport (WT) in practice, and nobody will support the other ones. The proposed solution of a single URL allowing multiple transports seems not that different in that case. We could mandate relay/server support for WT in here.

I think Cullen has already attempted to do that in moq-wg/moq-transport#1355.

+1 from me on unifying format here with what comes out of 1355 (if it ends up URL compatible, which is one of the current goals there).

---

Actually, now that I think more about this, is there anything MSF-specific in this proposal? As far as I can tell, this basically explains how to access a MOQT track, so I do wonder if MOQT would be a more appropriate place for this.

I think the problem is in the "content type". As we do not have, for now at least, a way to identify what kind of data are in the track, and for generic MOQT you cannot assume anything. This could be solved by multitude of ways, like having a content type extension/"header" in MOQT or having a custom scheme here that always represents a warp/msf catalog or track, but I do not think there is now a good way in MOQT itself.