:scheme

[martinthomson]

RFC 7540 requires that CONNECT requests omit the :scheme pseudo-header:

The ":scheme" and ":path" pseudo-header fields MUST be omitted.

Why does this draft need to define a URI scheme and then include that in :scheme?

There are already two different definitions for udp: URI scheme. Both seem - at least on face value - fairly sensible, but they both come with considerable baggage.

The question I'd like to ask is whether this protocol even needs a URI scheme at all. My first inclination is very much that it does not.

[martinthomson]

The template goes the same place you might put a URL. Right now, that is configuration.

[reschke]

Ah, I thought you wanted to put it into the ":path" pseudo header.

[enygren]

Closely related to this is whether: 1) Use a method per protocol (CONNECT-UDP, CONNECT-IP, etc) 2) Use a new common method (eg, CONNECTX) with protocol in either a pseudoheader or path component 3) Use Extended CONNECT with a ":protocol" psuedoheader

Given all of the baggage with CONNECT, I'd lean towards (2)

[enygren]

(This issue probably wants a more general name covering the set of interrelated topics here.)

[kazuho]

@enygren

Given all of the baggage with CONNECT, I'd lean towards (2)

As said at the meeting, to avoid intermediaries unaware of masque waiting for FIN before doing anything, I think it would be a good idea to make this an opt-in. For that, we need to use an ALPN, SETTING, or something that it being exchanged prior to the HTTP requests.

The problem with option 1 is that we'd need to introduce a new negotiation scheme for every protocol.

Option 2 is better in that respect because we need to introduce one negotiation scheme, and reuse it for different protocols.

But I'm not sure if hawing a new negotiation scheme is necessary, when option (3), i.e., the Extended CONNECT method, already provides us the necessary negotiation scheme with the ":protocol" psuedo header acting as a way of specifying the protocol.

[martinthomson]

Extended CONNECT does have the advantage of targeting a resource. The challenge then is in how the target (for UDP, that would be a hostname or IP plus a port) is encoded into that target URI. We have URI templates that have been successfully used elsewhere, so that might work. Webtransport can just use an arbitrary target URI.

The main complaint I have is that :protocol is terrible. HTTP Upgrade Tokens aren't ALPN, but that's almost what we want here: a unified protocol identification system. Of course, as a tunneled protocol, ALPN isn't right either, so maybe we can just reclaim upgrade tokens for this tunneling stuff.

[kazuho]

Yeah, I share the temptation to use ALPN. Though, talking specifically about masque, I'm not sure if it's an application protocol. Rather, it is a combination of an encapsulated datagram protocol and a way of specifying the remote address.

Let's say we want to use SRTP on top of a HTTP tunnel with support for datagrams. In such case, SRTP would be the ALPN, and we'd need another identifier for specifying that the transport carries datagrams, rather than a bidirectional stream.

Based on that, I am inclined to say that ":protocol" might be a better fit for masque, and separately, we could discuss adding a non-pseudo header field for specifying ALPN.

PS. And the other benefit of using Upgrade Tokens is that we can support HTTP/1.1 as well (though I'm not entirely sure if we want to officially support HTTP/1.1).

[martinthomson]

I keep forgetting that I wrote RFC 7639. Still, I agree on all counts. ALPN has a purpose, but it isn't quite right here. Update tokens are a little weird, but I think that they are actually perfect. We just need to reclaim them for use.

[DavidSchinazi]

One thing I do find appealing about using Upgrade Tokens is that it means that HTTP/1.1 support becomes easy: we just use Upgrade and keep the target in the path like in h2 and h3. And conceptually an upgrade is what we're doing: we're replacing the DATA stream with a new protocol that uses capsules/stream chunks. That's not too dissimilar to WebSocket.