W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: 6455 Websockets and the relationship to HTTP

From: Patrick McManus <mcmanus@ducksong.com>
Date: Thu, 1 Dec 2016 22:14:34 -0500
Message-ID: <CAOdDvNqShPUdu6zt-dPDpXm31eP2xX_dahrTr8JEbOOGQFFNSw@mail.gmail.com>
To: Andy Green <andy@warmcat.com>
Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Dec 1, 2016 at 9:33 PM, Andy Green <andy@warmcat.com> wrote:

> The actual game here is "provide a transport for JS WS API on h2".  It


indeed - but what I'm trying to get to the root of in this thread is what
motivates that. If the game is to get it into somebody's charter. that is
going to need to be crisp. So far I've really only heard 2 strong
motivators (along with a few complementary smaller ones)

1] it is inherently a problem that 6455 can only be done on h1 because it
is left behind the h2 curve. To be honest, this is generally stated as a
given but it isn't obviously true to me. I haven't heard this fleshed out
very convincingly - I tried to give some seeds to help build that argument
in the first message of this thread.. but to my mind there hasn't been a
convincing case made yet that this is a problem (which isn't to say I think
the case can't be made).

2] ws needs mux (and priority and flow control that go with it)  and h2 has
already solved that thorny problem. I buy this if ws needs mux. I supported
mux with Roberto in the hybi days and the wg decided against doing it in
the base version as part of 6455. This seems to be a stronger argument  But
has the lack of mux been a problem in practice for ws? anecdotes or data to
support that?

-P
Received on Friday, 2 December 2016 03:15:09 UTC

This archive was generated by hypermail 2.3.1 : Friday, 2 December 2016 03:15:12 UTC