Re: Make HTTP 2.0 message/transport format agnostic

Personally, Keep HTTP less dependence on transport is not bad idea at
least. A middle framing/session layer can glue HTTP message format and
transport layer well, just like what SPDY to do. But, SPDY don't abstract
what transport it rely on. if SPDY defines more portable under-hood
transport to rely on, it is better.

Best regards
  Tom

On Sat, Mar 31, 2012 at 12:23 PM, Mike Belshe <mike@belshe.com> wrote:

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