Re: Giving the Framing Layer a real name

On 27/02/2013, at 7:49 PM, Mike Belshe <mike@belshe.com> 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,


> 
> Mike
> 
> 
> 
> On Tue, Feb 26, 2013 at 9:12 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 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/
> 
> 
> 
> 
> 

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

Received on Wednesday, 27 February 2013 08:53:53 UTC