Subject: #603: Frame layout

From: "Nottingham, Mark" <[email-masked]>
Date: Fri, 26 Sep 2014 11:02:37 -0500

<https://github.com/http2/http2-spec/issues/603>

It doesn’t seem like there is consensus to adopt a change here; as many have pointed out, our protocol is not aligned anyway, and the other gains are marginal at best.

Anyone feel strongly about this still, or can we WONTFIX?

--
Mark Nottingham    [email-masked]   http://www.mnot.net/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 26 Sep 2014 16:00:49 -0700

> Anyone feel strongly about this still, or can we WONTFIX?

I still feel strongly about it, in the sense that the current protocol
design is rather hideous, in my opinion.  The effect is more complex
implementations, which will impact high-speed processing (particularly
when used for non-network communication).

However, this is a design choice.  If I want better design choices,
I can make them in my own protocols.

....Roy

---

From: Matthew Kerwin <[email-masked]>
Date: Sat, 27 Sep 2014 09:42:31 +1000

On 27 September 2014 02:02, Nottingham, Mark <[email-masked]> wrote:

> It doesn’t seem like there is consensus to adopt a change here; as many
> have pointed out, our protocol is not aligned anyway, and the other gains
> are marginal at best.
>
​If it were earlier in the process I'd push to move flags out of the common
header, but here and now I don't know that it's worth it. It's ugly,
potentially confusing, but it works.​

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 27 Sep 2014 10:06:40 +1000

I too feel strongly about the flawed framing layer. However I've huffed and
puffed and the house has not fallen down!

So I guess WONTFIX is appropriate (rather than RESOLVED).

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 27 Sep 2014 17:12:06 +1200

On 27/09/2014 12:06 p.m., Greg Wilkins wrote:
> I too feel strongly about the flawed framing layer. However I've
> huffed and puffed and the house has not fallen down!
> 

Ditto.

Amos

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 27 Sep 2014 05:41:45 +0000

--------
In message <[email-masked]>, "Roy T. Fielding" w
rites:
>>=20
>> It doesn=92t seem like there is consensus to adopt a change here; as =
>many have pointed out, our protocol is not aligned anyway, and the other =
>gains are marginal at best.
>>=20

I'm with Roy here.  I think the proposed change should be made.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: <[email-masked]>
Date: Mon, 29 Sep 2014 07:59:27 +0000

On Saturday,27 September 2014 07:42, [email-masked] wrote:
> In message <[email-masked]>, "Roy T. Fielding" writes:
>>many have pointed out, our protocol is not aligned anyway, and the
>>other = gains are marginal at best.
>>>=20

I'm with PHK and Roy. I think the proposed change should be made.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 29 Sep 2014 10:23:28 +0200 (CEST)

On Fri, 26 Sep 2014, Nottingham, Mark wrote:

> It doesn’t seem like there is consensus to adopt a change here; as many have 
> pointed out, our protocol is not aligned anyway, and the other gains are 
> marginal at best.
>

I think we should put this suggestion in the queue of things to do with the 
binary format if we for some reason are lead into changing the format for some 
other and more important reason. I don't think these stated motivations are 
enough to (yet again) break the binary format.

-- 

  / daniel.haxx.se

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 29 Sep 2014 08:46:00 +0000

--------
In message <[email-masked]>, Daniel Stenberg

>enough to (yet again) break the binary format.

I continually amazes me that backwards compatibility with a handful
of prototype implementations is used as an argument against improving
the successor to the worlds most widely used protocol.

History is littered with crappy decisions which could have been made
better for trivial cost at the right time and place, but because of
shortsightedness were not, causing almost unlimited grief later on.

The framing-layer of HTTP/2 should be given particular attention,
since it would be to everybodys huge advantage that it also be good
enough for HTTP/3 etc.

Roy and many others have repeatedly pointed out that the current
framing is a mess and that it should be cleaned up, formalized and
made future proof.

The fact that pretty much everybody is able to jot down a better,
cleaner and more orthogonal framing layer in a matter of minutes,
should be considered highly embarrasing.

Is that really the reception you want HTTP/2 to get ?

   "Huh ?  I could do that better in 30 seconds, here, let me show you..."

Just because five or ten random people have implemented the draft
at present is no excuse not to do the best job we can, before
hundreds or evne thousands of other people will have to implement
HTTP/2.0

---

From: Robert Collins <[email-masked]>
Date: Mon, 29 Sep 2014 21:53:23 +1300

On 29 September 2014 21:23, Daniel Stenberg <[email-masked]> wrote:
> binary format if we for some reason are lead into changing the format for
> some other and more important reason. I don't think these stated motivations
> are enough to (yet again) break the binary format.

If we are going to change it, can we make sure that the websockets
draft will have enough frame types available- I've only just started
reviewing it, but it would be tragic to shrink the number of frame
types just as one of the most obviously predictable additional users
of the transport layer starts to come onboard.

-Rob

-- 
Robert Collins <[email-masked]>
Distinguished Technologist
HP Converged Cloud

---

From: "Simpson, Robby (GE Energy Management)" <[email-masked]>
Date: Mon, 29 Sep 2014 15:09:44 +0000

>the successor to the worlds most widely used protocol.

+1

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.

Granted, I haven't been actively participating from the beginning and may
be missing out on the fatigue, but my experience thus far has been
resistance to any real change.  To me ironic, since I waited this long to
implement as I knew I only had so many cycles..

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 29 Sep 2014 20:48:50 +0200 (CEST)

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

> 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.
>
> 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

---

From: Michaela LaVan <[email-masked]>
Date: Mon, 29 Sep 2014 16:31:43 -0400

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 <[email-masked]> wrote:

> 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
>
>

---

From: Jason Greene <[email-masked]>
Date: Mon, 29 Sep 2014 16:56:26 -0500

I disagree that Roy’s changes are aesthetic; they do have tangible benefits. Even if they were though, minor changes to make a spec cleaner can still have large effect, by improving the quality of implementation (namely how long it takes to get right), which directly contributes to uptake and interoperability.

That said I think its reasonable to ship something thats not as ideal as it could be, and defer any sort of framing revamp to HTTP/3. The next time around, those of us that were late to the process will have learned our lesson and be early :) 

On Sep 29, 2014, at 3:31 PM, Michaela LaVan <[email-masked]> wrote:

> 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.
> 
> 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
> 
> 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Rob Trace <[email-masked]>
Date: Mon, 29 Sep 2014 23:51:41 +0000

As an implementer we are also not interested in changing the frame layout. This is not about taking the time to change code.  It is simply that we are not seeing enough benefit to make this change at this point and would rather continue working on interoperability and shipping the standard.

Thanks!!

-Rob

-----Original Message-----
From: Jason Greene [mailto:[email-masked]] 
Sent: Monday, September 29, 2014 2:56 PM
To: Michaela LaVan
Cc: Daniel Stenberg; Simpson, Robby (GE Energy Management); Poul-Henning Kamp; Nottingham, Mark; HTTP Working Group
Subject: Re: #603: Frame layout

I disagree that Roy's changes are aesthetic; they do have tangible benefits. Even if they were though, minor changes to make a spec cleaner can still have large effect, by improving the quality of implementation (namely how long it takes to get right), which directly contributes to uptake and interoperability.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

---

From: Nicholas Hurley <[email-masked]>
Date: Mon, 29 Sep 2014 17:05:36 -0700

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

--
Peace,
-Nick

References

1. mailto:[email-masked]
2. http://daniel.haxx.se/

---

From: "Simpson, Robby (GE Energy Management)" <[email-masked]>
Date: Tue, 30 Sep 2014 01:04:57 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 29, 2014 at 4:31 PM
To: Daniel Stenberg <[email-masked]<mailto:[email-masked]>>
Cc: Charles Simpson <[email-masked]<mailto:[email-masked]>>, Poul-Henning Kamp <[email-masked]<mailto:[email-masked]>>, "Nottingham, Mark" <[email-masked]<mailto:[email-masked]>>, HTTP Working Group <[email-masked]<mailto:[email-masked]>>
Subject: Re: #603: Frame layout

On Mon, Sep 29, 2014 at 2:48 PM, Daniel Stenberg <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, 29 Sep 2014, Simpson, Robby (GE Energy Management) wrote:

--

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