On the one hand, any HTTP 2.0 spec that still has cookies is a travesty.
On the other hand, I think we need to get some input from dissenters other than PHK (not that I don't agree with him).
On the other hand, I think we need to get some input from dissenters other than PHK (not that I don't agree with him).
From the charter:
> It is expected that HTTP/2.0 will:
> * Retain the semantics of HTTP/1.1, leveraging existing documentation (see above), including (but not limited to) HTTP methods, status codes, URIs, and where appropriate, header fields.
> * Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in intermediaries (both 2->1 and 1->2).
Quite probably a more radical, new version of HTTP, that drops message compatibility would be a good idea — but that's a lot harder to design and harder to deploy. As the old adage goes, "we believe in rough consensus and running code" — we have running code for a new message serialisation, and rough consensus for it. We should accept just that as done.
Which goes back to PHK's argument about the IETF getting caught with their pants down.
I think it will come and I think PHK's ideas a really interesting just that it's a step too far right now.