Re: Working Group Last Call: draft-ietf-httpbis-http2-14 and draft-ietf-httpbis-header-compression-09

On Sep 1, 2014, at 10:42 PM, Eric J. Bowman wrote:

> "Roy T. Fielding" wrote:
>> 
>> I have been reading this over the past few weeks (on various planes
>> and now at home) and am frankly surprised by the number of
>> non-editorial comments I have amassed...
>> 
> 
> On the one hand, I'm surprised you're just noticing this; OTOH, you
> were working pretty hard on updating HTTP/1.1. I got so overwhelmed
> with all the ways caching was being deprecated, let alone anything else
> making me uncomfortable, that my arguments went meta about how this is
> no way to design a protocol. Followed by shutting up (mostly).
> 
> So, good on ya for trying to address these issues in last call. Can't
> say as I disagree with you on any of it, but hopefully you have the
> knowledge and credibility I (and others who aren't exactly happy) lack
> for doing anything about it other than throwing our hands up in the air
> in the face of those forces opposed to intermediary caching, or any
> notion of proper Web architecture, or fidelity to HTTP/1.1, etc.

I think there is some confusion.  I have noticed quite a lot of discussion
of h2, since I have been reading all of that email since the WG began.
All of it (quite annoying, at times, given what I was working on).
What I have not been tracking is the semi-private interim meetings and
the decisions being made off-list.  Minutes are never sufficient to
reflect the actual discussion.

I finally had time to very carefully read the carefully crafted result,
which is what we are supposed to do at WGLC.  My surprise is that I found
so many places where the protocol can be made substantially simpler and
more efficient by mere choices in the layout of fields and the trade-off
between frame types and frame flags.  I also found occurrences of invalid
HTTP/1.1 examples (something which I am ideally suited to uncover) and
bad requirements regarding proxies.

These are substantive changes, but not at all difficult to implement.
In fact, I'd estimate that most of the implementations can be changed
accordingly in less than an hour's work (by the person who wrote them),
since none of my suggestions change what the protocol is communicating.
Likewise, the spec changes are mostly deletes of redundant material.

Given how much intense work and argument was invested in making the
header field compression strategy efficient, I did not expect the frame
layout to be in such a shape.  Part of that is due to recent changes in
the payload length bits, so it should be no surprise to participants that
these exact suggestions were not made earlier.  Certainly, many folks
suggested larger and more substantial changes earlier in the process
that would have accomplished the same result, but my suggestions are
more limited in scope.

These are comments based on my judgement of where the spec is today in
relation to its intended purpose of supplanting HTTP/1.1 as the HTTP
standard.  I did not base my comments on past discussions (in fact, the
parts I focused on reviewing seem to have been long forgotten by most
of the group).  I cannot be expected to reduce my comments just because
some people are tired of hearing comments.  I do not think it would be
better for me to remain silent so that folks can hear the same comments
at IESG last call, or after an RFC has been published.

Nevertheless, I do understand the desire to just get something done.
The question folks have to ask themselves is whether that desire is
greater than the benefit of making the suggested changes, given the
protocol is supposed to last for decades.  Don't tell me that there
is going to be an HTTP/3 around the corner -- people said the same thing
in 1996 when I *finished* HTTP/1.1.

More importantly, if there is a valid justification for the protocol
having those inefficiencies, other than the fact that they have already been
implemented in some version of some auto-updating browser, then I would
like to hear what that is and have it on record for later reference.


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <http://www.adobe.com/>

Received on Tuesday, 2 September 2014 20:02:45 UTC