Re: #603: Frame layout

I do not see these changes as aesthetic.  To me, having flags as part of the frame header when they are very much dependent on the frame type is problematic.  Flags in the frame header should be type-agnostic.  This then allows the individual frames (and extensions) to define flags however they may need them in their own payloads.  This also allows future type-agnostic flags to be defined (should we need them) without having to worry that flags have already been claimed by extensions.

And then you get the aesthetics (and alignment) for free!  :-)

From: Michaela LaVan <mlavan@google.com<mailto:mlavan@google.com>>
Date: Monday, September 29, 2014 at 4:31 PM
To: Daniel Stenberg <daniel@haxx.se<mailto:daniel@haxx.se>>
Cc: Charles Simpson <Robby.Simpson@GE.com<mailto:Robby.Simpson@GE.com>>, Poul-Henning Kamp <phk@phk.freebsd.dk<mailto:phk@phk.freebsd.dk>>, "Nottingham, Mark" <mnotting@akamai.com<mailto:mnotting@akamai.com>>, HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: Re: #603: Frame layout

Came here to say something similar, but Daniel beat me to the punch.

As an implementer I am strongly disinclined to make what are essentially aesthetic changes to the frame layout at this point.  Even seemingly minor changes in the most recent draft cost the working group weeks of interop data while we ironed out the bugs and got everyone on the same page. To me, the changes Roy is proposing are not worth the setbacks to our timeline that they would incur.

Like everyone else here I believe in the potential of HTTP/2 and want it to succeed. Right now the biggest threat to our goal of widespread adoption is not frame header field order or byte misalignment. It's getting to the end of 2014 and not having a protocol to ship.

On Mon, Sep 29, 2014 at 2:48 PM, Daniel Stenberg <daniel@haxx.se<mailto:daniel@haxx.se>> wrote:
On Mon, 29 Sep 2014, Simpson, Robby (GE Energy Management) wrote:

I'm implementing HTTP/2 because I believe it will be successful, widely used, efficient, and long-lasting.  At this stage, if there are changes that can be made to increase those qualities, I will _gladly_ update my implementation.

If someone is implementing a draft, they should be willing to update that implementation until the standard is finalized.  Otherwise, they should wait to implement.

I don't mind changing my (or others) code to adapt to changes in the protocol spec. I've been on this journey from the start and I'm one of those who have adapted code many times already and I have the feeling I will do more of that. I'm not afraid of changing code when it's necessary.

I want a protocol to implement so I want the HTTP/2 spec to settle down, and therefore I object aginst nit-picking details that in my mind don't have any particular impact in the protocol's ability to succeeed and that aren't very important to make the protocol easier to implement. I just don't consider that minor polish worth the extra time, effort and interop work that will follow.

But if there's any other actual - REAL - change that will go in that changes the format anyway, then I won't mind seeing these framing changes as well as then we've already broken the seal anyway and can just as well do that change too.

--

 / daniel.haxx.se<http://daniel.haxx.se>

Received on Tuesday, 30 September 2014 01:05:23 UTC