Re: HTTP/2 Expression of luke-warm interest: Varnish

On 16/07/2012, at 4:43 PM, Poul-Henning Kamp wrote:

> In message <4C9C45EE-57B6-49FE-A475-B46BE192A221@mnot.net>, Mark Nottingham wri
> tes:
> 
>> Much of your commentary seems to assume that we're now deciding what 
>> HTTP/2.0 will be; in fact, we're choosing a starting point for further 
>> work. 
> 
> No, my commentary is based on the experience that if you pick
> a starting point, without first defining the problem(s) you are
> trying to solve and the goal(s) you are trying to reach, then
> that starting point is where you are going to end up. 

The goals were defined in our current charter:
  http://datatracker.ietf.org/wg/httpbis/charter/

In particular:

"""
To do this, the Working Group will solicit candidates for this work from 
the community, to be submitted as Internet-Drafts. Expected focus areas 
for candidates include: 

* Significantly improved perceived performance in common use cases 
(e.g., browsers, mobile) 
* More efficient use of network resources; in particular, reducing the 
need to use multiple TCP connections 
* Ability to be deployed on today's Internet, using IPv4 and IPv6, in the 
presence of NATs 
* Maintaining HTTP's ease of deployment 
* Reflecting modern security requirements and practices 
"""

and

"""
The Working Group will then select a starting point for the new work 
based upon the following criteria: 

* Compatibility with HTTP/1.1 semantics; i.e., it must be possible to 
pass through a HTTP/1.1 message with reasonable fidelity 
* Broad implementer interest (e.g., from Web browsers, "back-end" 
or "web api" uses of HTTP, servers, intermediaries, CDNs, etc.) 
"""

This was based upon discussion earlier this year. The time and place to argue our process was several months ago, not now.


>> You advocate (here and elsewhere) going back to the drawing board and 
>> doing things from scratch.
> 
> No, I advocate starting out deciding what problems and goals HTTP/2.0
> should address, what HTTP/1 did right and what it did wrong.
> 
> Only once we have a consensus about that, can we judge the
> proposals fairly.

Again, we're already there. You're complaining about a decision that, effectively, the rest of the industry made months ago.


> What the WG is engaged in right now is a popularity contest, it is
> not engineering, and because of the inertia of popularity, it will
> be impossible to change anything dramatically, no matter how wrong
> it turns out to be.

That's a lot of assumptions to make in one paragraph. 


> That alone, in my mind, is reason to not chose SPDY as the starting
> point:  The installed volume will deprive the WG of any real
> influence.
> 
> Yes, I belive in rough consensus and all that, but I don't belive
> you should always say yes to the first boy who invites you to the
> dance.

And that's why we're going through this process.


>> Finally, HTTP versioning is NOT like software versioning (where the 
>> driver is often marketing).
> 
> I wish you good luck with keeping marketing and numerological
> expectations away from the very head-line inviting "HTTP/2.0"
> monicker.
> 
> lf I were you, I'd start to think about how I can explain HTTP/2.0
> to journalists from the Daily Mail in a way that doesn't result in
> "Boffins to close the web for upgrade" or "Web doesn't work says
> head boffin" headlines.

Poul-Henning, you've waved your hands about regarding the press more than once now; it's getting old. Please tone down the rhetoric.


> I don't know if you have considered it, but it might be a much
> better idea to standardize SPDY as "SPDY", and not roll out the
> "HTTP/2.0" headline, until you have something real to show for it.

Indeed, this was considered. However, it was felt that having SPDY become a de facto HTTP/2.0 outside the IETF process would be a worse outcome than having everyone at the table here, discussing it and other proposals, because it'll be a lot harder to change in the few years that would take -- to the point where it probably wouldn't be worth the effort.

Will HTTP/2.0 be perfect? I very much doubt it, and that's fine. What it will be is something that is better for HTTP/1.1 for most uses, for most people, in most situations -- or we won't do it. The process we're using now gives you -- a gateway / intermediary / "HTTP router" implementer -- a certain amount of influence over the outcome; influence that you wouldn't necessarily have over a separate effort. It doesn't give you the ability to stop the entire effort, nor to railroad everyone else down the path you've chosen (just as these aren't options open for any other single entity).

So, we need as many implementers and deployers constructively working together. So far, the folks who have made the proposals have taken pains to point out that they're willing to change, willing to negotiate, etc., as long as the changes are backed up by solid engineering. I'd ask you to work with us as well; the points you've made are good, and will be discussed, but the frustration you express so often isn't constructive, and indeed I don't think it's really necessary. 


> Given the total lack of interoperability between SPDY and HTTP/1,
> that would also make a lot more technical sense.

Please substantiate that claim, because it's apt to be taken out of context by the press whom you're so concerned about.


Kind regards,

--
Mark Nottingham
http://www.mnot.net/

Received on Monday, 16 July 2012 07:59:38 UTC