W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: Make HTTP 2.0 message/transport format agnostic

From: Mike Belshe <mike@belshe.com>
Date: Sat, 31 Mar 2012 06:23:32 +0200
Message-ID: <CABaLYCtiGRARo34icmhqt-Vx1eK2iBPKKrGHqcJu1Adt4wFxeQ@mail.gmail.com>
To: tom <zs68j2ee@gmail.com>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Kevin Cathcart <kevincathcart@gmail.com>, ietf-http-wg@w3.org
On Sat, Mar 31, 2012 at 5:08 AM, tom <zs68j2ee@gmail.com> wrote:

> Separate HTTP message format and under-hood transport as two specs should
> earn expansibility and portability.

The SPDY Spec is here:

>From the spec:
    Section 2: SPDY Framing
    Section 3: HTTP Layering over

The reason we didn't separate them so far is because we didn't have any
alternate messaging layers in mind.  Further, it wasn't a goal to make the
framing layer generic.  That could be done.  I'm personally not a supporter
of designing for things you don't know, which is why I vote to keep them
together.  If someone has a specific purpose in mind for the framing layer,
we could talk about this.

But hopefully the current separation allows you to accomplish what you want
until we have some other specific purpose in mind.


> Actually, Web app runs above HTTP and don't care what's transport to use.
> And, the different transport can provide the specific benefits.
> For example, UDP is easy to setup P2P communication, TCP is for
> client/server communication and SPDY for multiplexing connection.
> Best regards
>   Tom
> On Sat, Mar 31, 2012 at 6:55 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:
>> In message <
>> CAKZH0EuSWjgbM6No6hDv7wLSy_ZvFQJjgR4z7CMtAd3H9HG2tA@mail.gmail.com>
>> , Kevin Cathcart writes:
>> >The correct thing to do is pretty obvious
>> >to me. Document the core HTTP protocol in a message format agnostic
>> >way.
>> >
>> >[...]
>> >
>> >Separate specifications would define message/transport formats.
>> Seconded.
>> --
>> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>> phk@FreeBSD.ORG         | TCP/IP since RFC 956
>> FreeBSD committer       | BSD since 4.3-tahoe
>> Never attribute to malice what can adequately be explained by
>> incompetence.
Received on Saturday, 31 March 2012 04:24:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:57 GMT