Re: Make HTTP 2.0 message/transport format agnostic

Kevin (et al),

On 30/03/2012, at 2:46 AM, Kevin Cathcart wrote:

> I'm not really sure why everybody is getting so worked up about SPDY.
> The correct thing to do is pretty obvious
> to me. Document the core HTTP protocol in a message format agnostic
> way. This means not specifying
> the format of the messages or the transport.
> 
> Instead the core HTTP spec would be defined in terms of two types of
> abstract messages. One is a request
> message, which includes the following components: a version number, a
> resource URI, a method, headers,
> and an optional body. The other message is a response, which includes
> a version, a status code, a status
> phrase, headers, and an optional body. The core spec would then define
> the meaning of the methods and
> headers, the rules regarding proxies and caching, and the
> authentication rules, etc. Basically everything
> that would apply to all message/transport formats.

This is effectively what HTTPbis p2 - p7 already do.


> Separate specifications would define message/transport formats.

We're chartered to come up with one of these and call it "HTTP/2.0".


> Similarly we could define a S+M based message/transport format, or
> perhaps even a hybrid of the the two, whatever
> is deemed best.


Some people seem to be arguing for multiple serialisations of HTTP from the start. Since the value of a standard is largely in interop and market forces, I'd strongly suggest that we not assume this until we have proven and agreed to it being necessary. 

I.e., just because SPDY (or S+M, or any other proposal) isn't good as-is right now does not automatically mean that we need two (or more) serialisations. We need to discuss our requirements and the proposals that emerge, so we can choose an appropriate path forward forward. If we end up in a corner where we can't serve all of our requirements from one, *then* we can open this box.

Regards,


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

Received on Saturday, 31 March 2012 09:53:46 UTC