Re: Moving forward with HTTP/2.0: proposed charter

That makes it easier to require, and say, the first message of any new HTTP
pipeline always has ASCII headers.

On Friday, August 3, 2012, Poul-Henning Kamp wrote:

> In message <
> CABP7RbcS-yOuxUG2u-OB3rGK+s1MTp-TXa9ts4xwnp-o7Pchjw@mail.gmail.com<javascript:;>
> >
> , James M Snell writes:
>
> >I want to just clarify that the proposed language does leave the room open
> >for potentially non-backwards compatible changes to be made within HTTP
> >2.0.
>
> Where does 2.0<-->1.1 conversion _realistically_ come into play ?
>
> Given the premise that we will not get rid of 1.1 for a looong time
> under any circumstances, we can either make the answer "everywhere"
> (to get as much traffic upgraded as possible) or "nowhere" (leaving
> 1.1 traffic alone and using it as fallback, as long as needed.)
>
> This is a question we should decide in the abstract, because it
> greatly influences protocol design with respect to 1.1/2.0 interop
> and upgrades.
>
> For reasons of simplicity I'm partial to "nowhere", since it saves
> a lot of verbiage about the conversions, and would give us more
> free hands to make HTTP/2.0 actually be better.
>
> If the consensus is "everywhere", we should bite the bullet up front,
> and decide to do both "HTTP/2.0-reduced" which can be mapped to
> 1.1, and "HTTP/2.0-full" which cannot, so that we have a path to
> eventually get rid of HTTP/1.1.
>
> If we have that modality in our vocabulary, it becomes very easy
> to explain things like:
>
>         In HTTP/2.0-reduced headers are in ASCII
>         In HTTP/2.0-full headers are in UTF8
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>