Re: [Masque] Capsules

[Martin Thomson <[e-mail]>]

> 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.

It's good to know that we disagree.  You seem to think that the addition of another protocol layer is desirable.  I do not.  That shouldn't be a surprise: I asked if we could simplify things; your response was to propose making them more complex.

What I'm saying is that it would be better to NOT have a generic framework that exists to serve the intermediation use case.  Instead, intermediaries can understand all the protocols if they want to interact with the protocol more extensively.  That is the purpose of using settings to negotiate support (a decision already made).  Of course, that negotiation is only necessary if the protocol wants to escape the confines of a single stream.

Document factoring is secondary to that, of course.

>> 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.

I don't agree that that is the purpose of a standards body at all.  We're here so that different parties can agree in their (and hopefully everybody's) shared interest.  What you might be looking for here is good engineering practice, which says that you don't want too much diversity in how the same problem is solved in different contexts.

For this example, we have overlapping contexts.  HTTP/2 puts length fields ahead of type fields (fixed LTVs), Capsules have varint TLVs, QUIC has TVs.  These are not naturally compatible and so we have to decide how to align the format with these existing things.  Of course, this is an easy thing to answer if you are predisposed toward the addition of another protocol layer.