It's so cool to have this split. QUIC is so capable, such a neat set of ideas for a transport. That HTTP can express itself in terms of another spec is one of the most compelling, longest-hardest won & best victories for "abstraction" that computing has seen. That we'll be able to iterate on HTTP in new ways, by having a common semantic base, keeps the future open & iterable. Huge wins.
Obligatory link to Mark Nottingham's "A New Definition of HTTP3"[1], which talks about the split of HTTP into a semantic definition in RFC9110[2] & the creation of HTTP2/RFC9113 and HTTP3 (over QUIC, this document).
> It's so cool to have this split. QUIC is so capable, such a neat set of ideas for a transport.
That's what I thought too. A while ago, I wanted to use it in an Android app. I thought this was going to be a no-brainer. After all, Google more or less invented QUIC as SPDY about a decade ago. To my understanding, since they just YOLO'd it they agreed to form a proper working group and create quic. So here we are, ten years later, Google is heavily using quic for all their web stuff, and I naively assumed that Android would've had a native quic implementation for a while now, either directly in the SDK/runtime, or some first party library from Google. Nada. There is cronet, the networking engine of chrome as a library, which does speak quic but only exposes classes and functions to speak http, so you cannot even use its quic implementation directly. I went on and had to use some C library and JNI to do it, which is just ridiculous.
Sorry for this tangentially related vent, I'm still in disbelief.
Note that even the previous draft specification (https://datatracker.ietf.org/doc/draft-ietf-quic-http/34/) was a mapping of HTTP semantics on top of QUIC. It didn't carry too many transport specific concerns - which e.g. HTTP/2 did, since it cared about flow control and other things.
I have yet to read RFC 9114, but I guess it's refinded to fit better on top of the new HTTP semantics spec (RFC 9110).
I'd be aghast to see a significant rewrite of a specification as it moves from draft to rfc. The draft, at it's end, should closely mirror the final spec.
Obligatory link to Mark Nottingham's "A New Definition of HTTP3"[1], which talks about the split of HTTP into a semantic definition in RFC9110[2] & the creation of HTTP2/RFC9113 and HTTP3 (over QUIC, this document).
[1] https://www.mnot.net/blog/2022/06/06/http-core https://news.ycombinator.com/item?id=31647149 (3 points, 26m ago, 0 comments)
[2] "HTTP Semantics" https://www.rfc-editor.org/rfc/rfc9110
[3] "HTTP2" https://www.rfc-editor.org/rfc/rfc9113