Re: Make HTTP 2.0 message/transport format agnostic

On Sat, Mar 31, 2012 at 05:53, Mark Nottingham <mnot@mnot.net> wrote:
> Kevin (et al),
>
> On 30/03/2012, at 2:46 AM, Kevin Cathcart wrote:
>> 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.

Good. Lets just make sure that p2-p7 truly have no hacks
or cruft remaining from the current synchronous textual
Internet Message over TCP message-format/transport.

>> Separate specifications would define message/transport formats.
>
> We're chartered to come up with one of these and call it "HTTP/2.0".
>

If the idea is that with HTTP/2.0 we are simply writing a replacement
for part 1, and perhaps one or more additional parts that may specify
new features that rely on framing/message format of the new part 1,
then that is great!

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

Except that by my understanding there will inherently be two
serializations, the old HTTP/1.1 serialization, and the new
HTTP/2.0 one.

I think you mean that we should not consider multiple new
implementations. That is fine to me if my understanding
is correct, and that even once HTTP/2.0 is out it
remains possible for new methods/headers to be defined
in a way that both HTTP/1.1 and HTTP/2.0
(along with any other non-standard serialization that
is built on p2-p7) are supported.

Received on Saturday, 31 March 2012 19:22:43 UTC