Extended CONNECT, Capsules in DATA, HTTP Upgrade Tokens

Hi folks,

I'm sending this email to MASQUE with WebTransport and HTTP lists as BCC,
please reply only on the MASQUE list, registration link here: [1].

At IETF 111, we had some discussions in both the MASQUE and WEBTRANS
working groups around how we should be reasoning about these protocols and
their interaction with HTTP: are we building inside HTTP or over HTTP?
Martin Thomson wrote up the implications in this email [2].

Most importantly, the difference in how we reason about these protocols led
to
the following questions which impact the wire encoding in non-compatible
ways:

1) Capsules. We've reached some level of agreement that MASQUE and
WebTransport need a mechanism to reliably exchange information
bidirectionally
between client and server, even in the presence of intermediaries. While
the draft
currently [3] uses a new HTTP/3 and HTTP/2 frame for this, there was
agreement in
the room that this should be instead sent over the DATA stream (i.e. inside
DATA
frames for HTTP/2 and HTTP/3). And here comes the architectural twist:
we're no
longer sending an HTTP request and response on the DATA stream, we're now
using a new protocol over that stream.

2) Methods. WebTransport currently uses Extended CONNECT (RFC 8441) while
MASQUE uses new methods (CONNECT-UDP and CONNECT-IP). There was general
agreement that it would make sense to pick the same option for both. A
pragmatic
argument was made that there are implementations out there that wait for
the FIN bit
before parsing the client's headers which would break on these new methods,
whereas
requiring SETTINGS_ENABLE_CONNECT_PROTOCOL ensures that we aren't
speaking to one such broken implementation.

I personally see these two questions converging on a common solution: we
unify on
Extended CONNECT and define a new protocol which is simply a sequence of
capsules. This closely mirrors how WebSockets work over HTTP/2, and seems to
make sense architecturally. It also allows us to support HTTP/1.1 by using
the same
protocol with Upgrade.

If we decide to go this route, I think we have two main options to make it
work:

A) we have a document that defines the capsule protocol and register it
with the
IANA HTTP Upgrade Token Registry, but we then need a way to differentiate
between
WebTransport, CONNECT-UDP and CONNECT-IP (and other future applications).
The simplest way could be to define a separate HTTP header to convey the
application.

B) we have a document that defines the capsule protocol but does not
register an
Upgrade Token, and then every application defines its own Upgrade Token and
specifies
that its DATA stream will use the capsule protocol.

The main benefit of having the capsule protocol defined in one place is
that we can
have a single 62bit IANA registry for Capsule Types instead of having every
single
application define its own.

Does anyone have thoughts or opinions in this space?

Thanks,
David


[1] https://www.ietf.org/mailman/listinfo/masque
[2]
https://mailarchive.ietf.org/arch/msg/webtransport/NIiRl91X3151ppT0lQZvTY0wJ8w/
[3] https://datatracker.ietf.org/doc/html/draft-ietf-masque-h3-datagram-03