Re: Make HTTP 2.0 message/transport format agnostic

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:
http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00

>From the spec:
    Section 2: SPDY Framing
Layer<http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-2>
    Section 3: HTTP Layering over
SPDY<http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-3>

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.

Mike



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