W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: #603: Frame layout

From: Nicholas Hurley <hurley@todesschaf.org>
Date: Mon, 29 Sep 2014 17:05:36 -0700
Message-Id: <1412035536.2900227.173212669.7E81EC9C@webmail.messagingengine.com>
To: Michaela LaVan <mlavan@google.com>, Daniel Stenberg <daniel@haxx.se>
Cc: "Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com>, "Poul-Henning Kamp" <phk@phk.freebsd.dk>, "Nottingham, Mark" <mnotting@akamai.com>, HTTP Working Group <ietf-http-wg@w3.org>
Yet another implementer not interested in changing the frame
layout. Not only will it slow down our timeline, and break
interop (again), but I'm not convinced there are any benefits
to the change, and there may in fact be drawbacks.

On Mon, Sep 29, 2014, at 13:31, Michaela LaVan wrote:

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

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
<[1]daniel@haxx.se> wrote:

  On Mon, 29 Sep 2014, Simpson, Robby (GE Energy Management)

  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
  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.
   / [2]daniel.haxx.se



1. mailto:daniel@haxx.se
2. http://daniel.haxx.se/
Received on Tuesday, 30 September 2014 00:06:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC