Subject: Re: Giving the Framing Layer a real name

From: David Kendal <[email-masked]>
Date: Thu, 7 Mar 2013 00:29:39 +0000

On 27 Feb 2013, at 05:12, Mark Nottingham <[email-masked]> wrote:

> Suggestions for a name?

How about "PIFL", for "Protocol-Independent Framing Layer"?

> Regards,
> 
> --
> Mark Nottingham   http://www.mnot.net/

— dpk.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Mar 2013 07:04:53 +0000

> How about "PIFL", for "Protocol-Independent Framing Layer"?

FLOW = Framing Layer Of the Web

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 7 Mar 2013 08:19:54 +0100

On Wed, Feb 27, 2013 at 11:15:30AM -0800, Roberto Peon wrote:
> On Wed, Feb 27, 2013 at 11:03 AM, Martin Thomson
> <[email-masked]>wrote:
> 
> > On 27 February 2013 10:51, Roberto Peon <[email-masked]> wrote:
> > > 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.
> >
> > 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.
> >
> 
> We have enough to do here without worrying about it, but there you go.
> https://docs.google.com/document/d/1zUEFzz7NCls3Yms8hXxY4wGXJ3EEvoZc3GihrqPQcM0/edit

Did not see this one, it goes exactly in the direction I proposed for
having SPDY being the framing layer and HTTP the semantics layer :-)

Willy

---

From: Karl Dubost <[email-masked]>
Date: Mon, 11 Mar 2013 13:39:05 -0400

Le 27 févr. 2013 à 17:11, Mark Nottingham a écrit :
> 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...

FWIW, +1 and not only for the discussions of this group, but for the future and people having to discuss different parts of the specifications when fixing/implementing libraries.

I would keep HTTP/2.0 for the semantics.
and something-else for the connection parts.

-- 
Karl Dubost
http://www.la-grange.net/karl/