Subject: Giving the Framing Layer a real name

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Feb 2013 16:12:32 +1100

I've been a bit uncomfortable with our current nomenclature for a little while.

Right now we have:
  - a spec called "Hypertext Transfer Protocol version 2.0"
  - ... that does " HTTP Layering over HTTP/2.0"
  - ... onto a framing layer that we also call "HTTP/2.0"

I'm very tempted to propose that we:
  - Give the framing layer a distinct name. I don't care what it is.
  - Section 4 becomes "Layering HTTP Semantics onto XXXX."
  - "HTTP/2.0" is the name of the package of doing so -- i.e., HTTP semantics on a new framing layer.

I think this would make our discussions somewhat less confusing, especially around things like the upgrade process, and make our documentation clearer. It would also help clarify when it's appropriate to put something in a header (HTTP stuff) vs. in the framing layer (connection-specific stuff).

However, I recognise that naming things is hard, and I don't want this to become the bikeshed that kills us all. I'm also aware that doing so may encourage people to treat the framing layer as a substrate, but I don't see any way to avoid that, and won't mind, as long as we don't exceed our charter.

Any concerns in doing so? Suggestions for a name?

Regards,

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 26 Feb 2013 21:17:15 -0800

I got the same feeling too just a few hours ago. I'm all for it. No naming
suggestion, I suck at names.

On Tue, Feb 26, 2013 at 9:12 PM, Mark Nottingham <[email-masked]> wrote:

> I think this would make our discussions somewhat less confusing,
> especially around things like the upgrade process, and make our
> documentation clearer. It would also help clarify when it's appropriate to
> put something in a header (HTTP stuff) vs. in the framing layer
> (connection-specific stuff).
>
> However, I recognise that naming things is hard, and I don't want this to
> become the bikeshed that kills us all. I'm also aware that doing so may
> encourage people to treat the framing layer as a substrate, but I don't see
> any way to avoid that, and won't mind, as long as we don't exceed our
> charter.
>

---

From: Robert Collins <[email-masked]>
Date: Wed, 27 Feb 2013 18:55:47 +1300

> Any concerns in doing so? Suggestions for a name?

Seems sensible to me.
HTTPT ? [Though the transport protocol transport at the end is a bit ick].
HTTPF?

-Rob

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 27 Feb 2013 07:23:24 +0100

On Wed, Feb 27, 2013 at 04:12:32PM +1100, Mark Nottingham wrote:
> I think this would make our discussions somewhat less confusing, especially
> around things like the upgrade process, and make our documentation clearer.
> It would also help clarify when it's appropriate to put something in a header
> (HTTP stuff) vs. in the framing layer (connection-specific stuff).
> 

It's not a problem if people see the two parts as distinct. After all, if
we come up with something which later can be reused to transport other
protocols (eg: WebSocket) without the need for HTTP semantics, it will
be a good thing.

> Any concerns in doing so? Suggestions for a name?

I'm wondering whether we don't already have such things : 
  - HTTP holds the semantics
  - SPDY is the framing layer.

And if would 1) emphasize the fact that we don't want to change semantics,
and 2) acknowledge the work done by the SPDY team.

Regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 27 Feb 2013 19:23:31 +1300

> HTTPT ? [Though the transport protocol transport at the end is a bit ick].

WFP ?  (Web Frames Protocol)

WTF ?  (Web Transport Framing / Frames)

Amos

---

From: Fred Akalin <[email-masked]>
Date: Tue, 26 Feb 2013 22:48:04 -0800

HTTP (Hypertext Transfer Protocol) over HTFP (Hypertext Framing Protocol)?

I think these two names are distinct and clear, but obviously related.

On Tue, Feb 26, 2013 at 10:23 PM, Amos Jeffries <[email-masked]>wrote:

>>> However, I recognise that naming things is hard, and I don't want this
>>> to become the bikeshed that kills us all. I'm also aware that doing so may

---

From: TZI <[email-masked]>
Date: Wed, 27 Feb 2013 08:27:44 +0100

Sent from my iPad

> However, I recognise that naming things is hard, and I don't want this to become the bikeshed that kills us all. I'm also aware that doing so may encourage people to treat the framing layer as a su…

There may be no way to avoid that, but giving it a separate name will actually encourage that.
Non-HTTP objectives will creep in increasingly in the minds of people if it is perceived as separate.

Don't do a BEEP.

Gruesse, Carsten

---

From: Yoav Nir <[email-masked]>
Date: Wed, 27 Feb 2013 07:48:52 +0000

> WTF ?  (Web Transport Framing / Frames)

FORT ? (Framing Over Reliable Transport)

---

From: Yehia El-khatib <[email-masked]>
Date: Wed, 27 Feb 2013 08:07:13 +0000

HTFL (Hypertext Framing Layer)
...to avoid protocol confusion?

/Yehia

On 27/02/2013 6.48 am, Fred Akalin wrote:
> On Tue, Feb 26, 2013 at 10:23 PM, Amos Jeffries <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         On 27 February 2013 18:12, Mark Nottingham <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Â  Â - a spec called "Hypertext Transfer Protocol version 2.0"
>             Â  Â - ... that does " HTTP Layering over HTTP/2.0"
>             Â  Â - ... onto a framing layer that we also call "HTTP/2.0"
>
>             Â  Â - Give the framing layer a distinct name. I don't care what it is.
>             Â  Â - Section 4 becomes "Layering HTTP Semantics onto XXXX."
>             Â  Â - "HTTP/2.0" is the name of the package of doing so -- i.e., HTTP semantics
>             on a new framing layer.
>
>             I think this would make our discussions somewhat less confusing, especially around
>             things like the upgrade process, and make our documentation clearer. It would also
>             help clarify when it's appropriate to put something in a header (HTTP stuff) vs.
>             in the framing layer (connection-specific stuff).
>
>             However, I recognise that naming things is hard, and I don't want this to become
>             the bikeshed that kills us all. I'm also aware that doing so may encourage people
>             to treat the framing layer as a substrate, but I don't see any way to avoid that,
>             and won't mind, as long as we don't exceed our charter.
>
>     WFP ? Â (Web Frames Protocol)
>
>     WTF ? Â (Web Transport Framing / Frames)
>
>
>     Amos
>
>

-- 
Yehia Elkhatib
School of Computing&  Communications
Lancaster University
Lancaster LA1 4WA, UK
http://www.comp.lancs.ac.uk/~elkhatib
Follow me: http://twitter.com/yelkhatib
http://lancaster.academia.edu/YehiaElkhatib

---

From: Mike Belshe <[email-masked]>
Date: Wed, 27 Feb 2013 00:49:07 -0800

Good point; this layering made sense when it was a protocol separate from
HTTP, but now it makes little sense.

Question - will the final HTTP/2.0 specification need to re-include all of
HTTP/1.1?  I assume not, and it will simply reference it?

My vote would be to nuke the layering and instead fold section 4 (the HTTP
Layering) into the appropriate sections of the framing layer.  Trying to
make these generic frames seems like a distraction, and it would be simpler
for folks to read if these were just the basics of HTTP framing.

Mike

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Feb 2013 19:53:26 +1100

On 27/02/2013, at 7:49 PM, Mike Belshe <[email-masked]> wrote:

> Good point; this layering made sense when it was a protocol separate from HTTP, but now it makes little sense.
> 
> Question - will the final HTTP/2.0 specification need to re-include all of HTTP/1.1?  I assume not, and it will simply reference it?

Yes.

> My vote would be to nuke the layering and instead fold section 4 (the HTTP Layering) into the appropriate sections of the framing layer.  Trying to make these generic frames seems like a distraction, and it would be simpler for folks to read if these were just the basics of HTTP framing.

I think one of the mistakes of HTTP/1.x is that the connection-level and semantic stuff is all mixed together, not only on the wire but also in the specification. Of course, that's unavoidable to a degree, given the nature of that protocol, but if possible, I'd like to avoid it here -- especially if we're thinking of doing things like putting WebSockets across the same protocol.

Again, I don't want us to rathole on this (unless it prevents us from rathole-ing on other things).

Cheers,

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 27 Feb 2013 10:08:21 +0100

Am 27.02.2013 um 09:49 schrieb Mike Belshe <[email-masked]>:

> [...]

That would be smart. Given the efforts necessary and spent for HTTPbis.

FragP?

Stefan

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Feb 2013 10:01:12 -0800

> for folks to read if these were just the basics of HTTP framing.

I said as much to mark in private: the framing layer is for HTTP.  A
name implies that it might stand alone.  That's not going to be true.
The work to make it true is not worthwhile either.

---

From: James M Snell <[email-masked]>
Date: Wed, 27 Feb 2013 10:13:03 -0800

+1

---

From: Roberto Peon <[email-masked]>
Date: Wed, 27 Feb 2013 10:51:39 -0800

Then you can't do websockets, etc or whatever other protocol (maybe video?,
who knows) the web platform decides to do in the future on the same
socket/session.

That would be a poor tradeoff.. and for what gain?
What is the additional complexity of having the framing allow for non HTTP
semantics?
-=R

---

From: James M Snell <[email-masked]>
Date: Wed, 27 Feb 2013 10:56:28 -0800

No one said that subprotocols would not still be possible on top of
the same framing mechanism. Mark's question was about naming only, not
design. There is still a good design separation between the HTTP
semantics and the framing layer, and the framing layer would still be
reusable beyond just carrying http semantics.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Feb 2013 11:03:16 -0800

> who knows) the web platform decides to do in the future on the same

Not true.  Write another RFC that says how you can share the
connection with websockets.  That might have to change some of the
rules, loosen some of the constraints, add some features.

> What is the additional complexity of having the framing allow for non HTTP

The cost is in building generality.  Generality in engineering is
never general enough to solve unforeseen problems, and it never ever
comes with a zero complexity cost.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Feb 2013 20:11:07 +0100

On Feb 27, 2013, at 19:51, Roberto Peon <[email-masked]> wrote:

> websockets

I don't get it.

Websockets is mostly an agreement protocol to avoid unwanted communication out of a sandbox.
(It also adds a quantum of addressing, and some middlebox massaging.)

What does that have in common with a framing layer for a transfer protocol?

For me stopping the urge to port websockets to it is the most important example for not wanting to factor out that layer.

(And, anyway, couldn't Websockets simply be left alone for a decade or so?
The process leading up to it was painful enough.)

Grüße, Carsten

---

From: Roberto Peon <[email-masked]>
Date: Wed, 27 Feb 2013 11:15:30 -0800

> rules, loosen some of the constraints, add some features.

We have enough to do here without worrying about it, but there you go.
https://docs.google.com/document/d/1zUEFzz7NCls3Yms8hXxY4wGXJ3EEvoZc3GihrqPQcM0/edit

> comes with a zero complexity cost.

When I have a session with a client, I'd like to minimize my resource use,
and provide maximal bandwidth/memory prioritization so that the client's
experience is the best that I can give.
This is neither a theoretical nor insubstantial problem.

-=R

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Feb 2013 08:59:05 +1100

To me, a distinct name of a major, separable part of a protocol is only good spec hygiene; in HTTP we already have "representations" (nee "entities"), "resources" and so forth. They allow people to talk about different things that are happening with clarity; right now, people are using the term "HTTP/2.0" very, very sloppily, and that's a concern. "It means what I mean" is not a great basis for communication.

I don't think that changing the name will add any more complexity unless we allow it in based upon assumptions that it therefore *has* to be completely separable, and I'm explicitly not bringing that to the table.

Cheers,

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Feb 2013 14:06:09 -0800

> To me, a distinct name of a major, separable part of a protocol is only good spec hygiene; in HTTP we already have "representations" (nee "entities"), "resources" and so forth. They allow people to…

I don't agree that it's separable in any real sense, which has been
the source of the contention.  However, I appreciate the value of a
handle by which we can identify important "things".  I always imagined
that in the few places it was necessary to refer to the concept,
"HTTP/2.0 framing" or "HTTP/2.0 framing layer" would suffice.

That depends on the scope of what you are referring to, which is - I
believe - an important part of what we need to clarify.  Does this
include the creation and use of streams as well as the use of frames
to convey data?

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Feb 2013 09:11:23 +1100

> include the creation and use of streams as well as the use of frames

Yes, good point. We're already seeing the effect of this blurriness in terms of what people consider the "framing layer."

To me, EVERYTHING about mapping HTTP-specific semantics is in the "HTTP" section; everything that's generic -- which includes streams and stream management -- is "below" on the framing "layer."

I'm OK if we choose to use "HTTP/2.0 Framing" and stick with it -- it's just that it's used inconsistently now. However, this may not be the best name, because it has "HTTP/2.0" in it, and then we go and talk about using HTTP/2.0 *on* it. OTOH I'm not thrilled about introducing Yet Another Acronym...

Cheers,

---

From: Roberto Peon <[email-masked]>
Date: Wed, 27 Feb 2013 14:14:16 -0800

In my mind, we have a framing layer and a semantic layer.
-=R

On Wed, Feb 27, 2013 at 2:11 PM, Mark Nottingham <[email-masked]> wrote:

> >> To me, a distinct name of a major, separable part of a protocol is only
> good spec hygiene; in HTTP we already have "representations" (nee
> "entities"), "resources" and so forth. They allow people to talk about
> different things that are happening with clarity; right now, people are
> using the term "HTTP/2.0" very, very sloppily, and that's a concern. "It
> means what I mean" is not a great basis for communication.
> >
> Yes, good point. We're already seeing the effect of this blurriness in
> terms of what people consider the "framing layer."
>
> To me, EVERYTHING about mapping HTTP-specific semantics is in the "HTTP"
> section; everything that's generic -- which includes streams and stream
> management -- is "below" on the framing "layer."
>
> I'm OK if we choose to use "HTTP/2.0 Framing" and stick with it -- it's
> just that it's used inconsistently now. However, this may not be the best
> name, because it has "HTTP/2.0" in it, and then we go and talk about using
> HTTP/2.0 *on* it. OTOH I'm not thrilled about introducing Yet Another
> Acronym...
>
> Cheers,
>
>
> --

---

From: James M Snell <[email-masked]>
Date: Wed, 27 Feb 2013 15:08:06 -0800

My vote is on: HFL4CAHMAAEWMSFTCA ..

Which, of course, is short for... HTTP Framing Layer for Carrying
Around HTTP Messages And Anything Else We May See Fit To Carry Around

Seems like a perfectly good color for the bike shed, in my humble opinion.

- James

---

From: Jeff Pinner <[email-masked]>
Date: Wed, 27 Feb 2013 21:53:38 -0800

aren't there three layers?

Framing Layer -- frames and their encodings
Session Layer -- stream lifecycle, flow control, shared compression context
Protocol* Layer -- request/response, pushed resources

i prefer tri-color bike sheds :)

*yes, by protocol here i mean the HTTP/1.* request/response protocol

---

From: Roberto Peon <[email-masked]>
Date: Wed, 27 Feb 2013 22:12:59 -0800

Hehe.
-=R