4 ms·

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

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.

unmole 4y ago
> 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?
- deleted 4y ago
  [deleted]
simmervigor 4y ago
> 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-19.html 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.

unmole 4y ago

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

deleted 4y ago
[deleted]

simmervigor 4y ago

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