I didn't say quic itself was -- if quic had been introduced completely independently of http then sure, that's fine. But it was introduced intermingled with making yet another drastic change to a backbone protocol of the internet.

Considering HTTP/1.1 stood for over 15 years before http/2 came along (and was a pretty modest improvement over http/1.0 compared to what we're talking about now, so I'm being generous by not saying over 20 years). http/2 had only been promoted to a proposed standard for 3 before http/3 was proposed. That, to me, is a very aggressive process. But again, it's the relationship to http that bothers me, not the standardization process for quic itself.

What's the point of having QUIC if there isn't a protocol that actually uses it? And what would be a better protocol than HTTP? HTTP/2 was a marginal improvement but HTTP/3 and QUIC significantly improve user experience. Especially if the users have jittery networks which is the case for the majority of the world. I don't understand why it would have been a better idea to sit on these improvements for a while before getting them into the hands of users.

I don't really see "is it beneficial in the long run" and "is it an aggressive standardization campaign by one interested party" as being the same question.

At any rate I also didn't say they shouldn't experiment with using it as an accelerated path for http. I didn't think they shouldn't with spdy either. But historically RFCs were built on practice, not the other way around.

If I were the Internet Dictator, I'd be a big fan of standardizing the semantics of http separate from the physical transport and then defining best practices for using alternative transports in the wild, and then eventually standardizing what comes out of that process.

To me it's an indictment of how all this shook out that we're so quickly looking to replace http/2. I think moving to quic is a good move but maybe we didn't need an official http/2 standard in the meantime.

> If I were the Internet Dictator, I'd be a big fan of standardizing the semantics of http separate from the physical transport and then defining best practices for using alternative transports in the wild, and then eventually standardizing what comes out of that process.

This is what the IETF has been doing for several years already as part of the core HTTP specification rewrite. Namely, see the HTTP Semantics document https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics...

Semantics are common, how those map to specific transport - how it looks on the wire - is then the job of each individual HTTP version.

It reads like you're overlooking the act of standardization in improving the definition of a protocol. Experimentation is good but often only focuses on a limited set of use cases, deployments, or implementations. Standardization is great for interoperability across a more diverse set of all those three. This typically yields protocols that are more generally applicable for a wider population of the Internet.

Google QUIC was focused on an HTTP use case and thatbran through the entire design. Through the IETF process, the design evolved to be a far more generic transport with rich extensibility and modularity.

> is it an aggressive standardization campaign by one interested party

Everyone from FB to Microsoft to even Huawei wanted QUIC. It's was not something that only Google was interested in. Hell, the primary author left Google well before the WG was done.

> But historically RFCs were built on practice, not the other way around.

Right from the early drafts, there have been multiple independent QUIC implementations constantly being tested. There was plenty of working code before there was rough consensus.

> standardizing the semantics of http separate from the physical transport

What actual semantics of HTTP changed with QUIC?

You've got it backwards. The final problem with HTTP/2 couldn't be solved by the application layer protocol alone, so "intermingling" is a "not-even-wrong" complaint -- if you transported a large JPEG and an HTML page over the network in an HTTP/2 stream, a lost packet in the jpeg file would cause the html stream to potentially stall until it was corrected and finished, even though you can load both concurrently. This effectively causes head-of-line blocking on what should be a concurrent system. So a primary attraction of HTTP/2 is effectively defeated and possibly even made worse; it is a behavior instituted by TCP, there's nothing you can solve it with.

QUIC was "intermingled" because it exactly solved this problem at the transport layer, the only place it can be solved. They couldn't just introduce any random thing, and no other protocol existed, so they ratified QUIC independently as its own protocol and applied it to HTTP/3 at the same time. They had to introduce a new standardized transport if the hope was to solve the HOL blocking issue. If you "dis-entangled" it you'd just have HTTP/2. The new transport protocol is the defining characteristic.

Furthermore it all would have been pointless to define QUIC as a standard without actually applying it in practice, in anger, to real workloads. Which is exactly what multiple stakeholders in the process did throughout the multi-year ratification process. What are they going to do, define QUIC, sit on their thumbs for 5 years and cross their fingers hoping someone else tries it?

There are other factors like most of the involved stakeholders had previous experience watching with other attempted standards in similar veins like TCP Fast Open die on the vine. That also influenced decisions like using UDP for QUIC's transport (and the ever present discussions about middleboxes.) Actual experience indicates most low-level protocols have ossified badly or are handled very poorly, including TCP and UDP except most things can handle those, so moving the transport layer into the application stack is seen as providing actual agility needed to respond to issues like the HOL blocking issue. That's how they revised the protocol several dozen times over the years; applications are actually fairly agile. Now you could argue these people should have discovered that issue when designing HTTP/2, but "Why didn't this thing get discovered and found out?" is always a weird complaint. Why would you expect everything to be found out early? I just can't answer that complaint honestly. Weirder things have happened than "Some engineers missed something."

Many people seem to hold some unwritten belief that if a protocol is defined as, say, an application layer protocol at one point, then it can never ever redefine its parameters to be anything beyond that. It can never become a transport protocol, for example, or have the two be mandated together, despite decades of experience suggesting that might be a fruitful path for many technical reasons. But there's no random rules of the universe defining what a network protocol looks like. It can be whatever we want it to be. Humans define this, there isn't like a book of 10 commandments out there written by God.

There is also no necessary indication that HTTP 1.1 sticking around for so long versus HTTP/2 necessarily meant it was the best among all options, by the way. We abused it a lot for many things. Being around for so long could also mean we were just bad at enacting change; certainly browser monocultures have made change easier for better and worse, on that note. But the whole HTTP/2 and HTTP/3 process has been about 13 years on its own if you count it as starting with SPDY. It's not like there's 200 years of precedent for how long it should take.

Most of this is just retreading the other thread so I'm largely going to just say you can read my replies there, but to explicitly reiterate:

> They had to introduce a new standardized transport if the hope was to solve the HOL blocking issue.

I take no issue with quic being standardized and I applaud that it was.

> Furthermore it all would have been pointless to define QUIC as a standard without actually applying it in practice, in anger, to real workloads.

Protocols are deployed on real workloads in anger in practice every day without even having an ietf rfc, let alone being blessed as the next official version of one of the most important protocols on the internet, and it works out fine. I never said, meant, or in any way advocated for anyone sitting on their ass.

So based on reading your other responses your complaint is that "I think RFCs are built on practice than the other way around" which doesn't mean much, considering that's what is happening! They are building on practice. Most if not all RFCs anywhere, including the IETF, actually see lots of revisions, and QUIC is hardly very different, and there is no hard rule about how standards are formed. This is how it works.

EDIT: I was too rude/curt and re-edited this. Sorry.