Re: [Masque] Capsules

[Ben Schwartz <[e-mail]>]

It seems like a lot of these concerns are about document refactoring.  For
example, the special behaviors for HTTP 2<->3 intermediaries could be
extracted into a separate document and described as an optimization, but
that's not functionally different from the current text.

However, you also identified some technical issues that we should explore.

On Tue, Nov 2, 2021 at 2:25 AM Martin Thomson <[e-mail]> wrote:
...

> This forwarding behaviour depends on the intermediary understanding that
> the protocol in use is a capsule-based protocol.  This is done by looking
> at the :protocol pseudo header field on the extended CONNECT and looking
> that up in a list of known capsule-based protocols.  This is necessary
> because not all protocols that use extended CONNECT use capsules.  After
> all, the only use of extended CONNECT that currently exists, websockets,
> doesn't.
>

This is a good observation, and we can correct it.  We can define an
additional request header to indicate that the datagram+capsule system is
in use (like the old Transfer-Encoding header), to decouple this from the
:protocol.

The editors of the WebTransport over HTTP/2 draft are currently debating
> whether to propose the use of capsules there.  There, we have some
> interesting design constraints that might be cause to use a different
> format.  One option that is being considered is reusing design elements
> from QUIC to make the protocol easier to implement.  I don't think that we
> should feel constrained to use capsules, except to the extent that it might
> be nice to make implementation in intermediaries easier.
>

I think the purpose of a standards body is to avoid producing multiple
similar but incompatible systems if it can be avoided.  If WebTransport has
additional requirements, MASQUE might be able to adopt a subset of its
framing.