Define capsule protocol over WebSocket to enable use where HTTP/2 is not supported

[martenrichter]

That is kind of a cross posting of the issue from the other webtransport working group (ekinnear suggested posting it here):
w3c/webtransport#518
Main idea is to add to the capsule protocol a specification for capsule over websocket, in order to support it in browser, that not yet support the http/2 protocol.

The benefits are as follows:

The protocol's way of working would be very similar to the actual http/2, so one could easily test ideas without waiting for the browser implementation.

1. It will not be hard to implement it in a shim/polyfill (or I think it comes naturally out from my node webtransport plugins work)
2. Having it specified ensures, that one shim/polyfill is enough for all future servers deployed that comply to the spec.
3. And it will automatically address points older browsers, that do not support http2 over webtransport (or even webtransport) and one can even with the newer browser work in environments, where UDP is blocked.

My proposal would be as follows, the normal capsule protoco isl:

Capsule {
     Capsule Type (i),
     Capsule Length (i),
     Capsule Value (..),
   }

The idea would be to transport it as binary frame/payload of length Length + 4 , and the payload will start with capsule type and continue with capsule value. Maybe an initial text frame indicates, that it is a capsule over websocket connection.
The rest of the http/2 capsule protocol will remain unchanged. So besides a little bit extra overload, the mechanics of most of the protocol will remain unchanged.

[ekinnear]

Thanks @martenrichter!

Also linking #80, where there was a little bit of discussion about both HTTP/1 and WebSockets.

[martenrichter]

Also another comment. For example the node.js or the underlying lib implementation has hardcoded http2 settings, so that actually the settings in the http2 webtransport proposal are kind of a blocker:
nodejs/node#49025
nodejs/node#48962
So that initial implementation probably will ignore them.....

[DavidSchinazi]

Chair: discussed in editor's meeting. We might provide guidance on this in the PR that resolves #80, but we're not going to take on this additional scope unless there's demonstrated interest in this new feature.

[ekinnear]

That would fit, thanks @martenrichter. I think when this came up previously, we were much in the same place as we are now: this seems reasonably additive, to the point that if we had clear interest and use cases, it would be possible to write up a spec that would enable some of these uses. Until that happens, we can mention it editorially in the PR mentioned above.

[DavidSchinazi]

Chair: as discussed in #90 (comment) , this sounds like a good topic for a separate spec. We'll mention that it's possible in the PR that closes #80. If the proponents write up a draft that describes this, we'll happily discuss it in the WebTransport WG - though this might only happen after we're done with the h2 and h3 versions. Closing.

[martenrichter]

Thanks, for the feedback. The interest in the feature will really depend, on how fast webtransport over http/2 (and webtransport in general) is implemented in major browsers, and interest in webtransport in general.
I have now implemented a working base http2 implementation of the capsule protocol and webtransport. (Not all of the spec as settings are missing in node)
Next would be to try to do the WebSocket wrapper, after this one can see if it makes sense to write it down.

[DavidSchinazi]

That's a solid plan, thanks Marten!

[martenrichter]

Ok, my implementation is ready:
https://github.com/fails-components/webtransport
and tested using the unit tests against also three major engines (and my app for the two major engines available in Windows)
and I spent a couple hours of writing it down:

https://martenrichter.github.io/draft-ietf-webtransport-websocket/draft-richter-webtransport-websocket.html
https://github.com/martenrichter/draft-ietf-webtransport-websocket

I hope I hit the tone and style correctly, especially as it is different from the publications in latex I usually write.

I have also submitted a patch to node, to get full support of http settings, which is crucial for the http/2 implementation.

[martinthomson]

@martenrichter, I'd encourage you to submit that draft, even though it might not be ready for discussion. Sometimes, publishing a draft is a good way to start some discussion.

[martenrichter]

Thanks for the feedback, I just followed your suggestion:
https://datatracker.ietf.org/doc/draft-richter-webtransport-websocket/
.