ok I didn't know that this was john nagle. that's intimidating.

i'm still highly alarmed, both by John & the general level of discourse going on all throughout this thread. i posted replies to a number of others too. there is wild unsubstantiated & mean-spirited speculation running rampant through this, imo, good news. no one talks to how or why they think this is going to help spy on us, or reduce our ability to block ads, yet it's a very popular & trendy opinion. it seems widely assumed that this is all for bad, and everyone seems to want to believe that mis-information.

i find it distressing that the world would be so paranoid & crazy as this. after years of IETF hard work & discussion, after countless engineers work tirelessly to maximize privacy & security, after countless points are raised & tackled, the world greets what we think is a real & significant improvement with disdain, distrust, & belittling. this feels like the kind of easy-to-spread paranoia & madness that is part & parcel to the disinformation that has grown a threat to civil order, a threat to reason. it's too easy to knock things down[1], done so casually, & people seem to want to hear it too much. i realize i haven't been helping, haven't been waging an effective campaign to try to promote a healthier course for us, better discourse, but i want to. i want to not be overwhelmed & saddened by unsupported unreason.

touching back to @animats' post:

> The real motivation is probably to merge ads into the same stream as the content,

i don't see any potential for how this would impact ad-blocking or other security measures on the web. HTTP3 offers no new features or capabilities over HTTP2. existing extensions & tools ought be unaffected.

> All that effort to get a tiny improvement.

imo QUIC+HTTP3 is a straightforward & sensible simplification over what we had, & was a natural route to enhancing the existing systems.

http2 wanted to share a connection, allow out of order serving of requests in a better way than the obsolete & complicated/painful & largely removed http1.1 pipelineing, so servers could start working on upcoming work before finishing the current request.

quic has been an attempt to take a lot of the good work already done on http2, & to drive it further down the stack, enabling a) others to use the transport/session layers now distilled into quic for their own uses, and b) radically simplifying the http specification's responsibilities by separating out quic transport/session concerns from http.

beyond making http3 much simpler, there are other benefits. a capable replacement for WebSockets is forming via WebTransport[2], and a lot of people are hoping the complex SCTP-based WebRTC stack can be re-designed to use WebTransport/quic, once webtransport advances[3].

overall, the greatest proof that this is a simpler, better, more natural path than what we had comes from a quick look a the QUIC active & related documents[4], where we can see a number of different frontiers of innovation for other ways QUIC might be improved & enhanced, including topics such as multicast, load balancing, unreliable connections, & more: quic is a flexible, interesting, compelling extraction of really neat & interesting http2 technology, & decoupled from http, we are seeing amazing innovation take root & allow all sorts of good frontiers to open. quic is itself a big improvement to what was available for transport & session protocols, and it is throwing open the doors to colossal levels of innovation that were not conceivable before.

[1] https://en.wikipedia.org/wiki/Brandolini%27s_law

[2] https://w3c.github.io/webtransport/

[3] https://bloggeek.me/who-needs-quic-in-webrtc/

[4] https://datatracker.ietf.org/wg/quic/documents/