Re: Moving forward with HTTP/2.0: proposed charter

In message <CABP7RbcS-yOuxUG2u-OB3rGK+s1MTp-TXa9ts4xwnp-o7Pchjw@mail.gmail.com>
, 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.

Received on Friday, 3 August 2012 21:11:02 UTC