Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)

> HTTP/2 makes many of the pre-WebSocket solutions to this problem space
much cheaper.  QUIC will probably make it even more so.
> If there are people who feel strongly that WebSockets still meet a need
over a modern HTTP, I'm happy to read and occasionally comment,
> but I don't feel called to be integral to that work.

At this point I wonder if there is a need for a separate solution.  Making
websockets go over HTTP2 seems to bring up the bureaucratic problems of the
past.  If websocket can be its own thing, then have an implementation for
HTTP2 and another one for QUIC, I think it can see more success.  The
reason for this is both protocols (HTTP2 and QUIC) have their own way of
trammiting data frames.  Websocket in this case should become an
alternative frame type, basically one carrying a binary payload.  All the
previous baggage of websocket1 can be dropped like the distinction between
text/binary frames as well as ping/pong and close. So we end up with just 1
frame type.

Compression would be left up to the client js / server code.  The
websocket2 would be a super simple two way binary stream.

This is pretty self explanatory, the major problem is how you do handle
authentication now.

On Wed, Nov 30, 2016 at 2:29 PM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

> QUIC's charter doesn't have anything directly to do with WebSockets.  But
> I agree that since WebSockets came from a different WG, it might be a
> reasonable question to the ADs whether that working group should be
> rechartered to do an HTTP/2 or HTTP/QUIC port.
>
> HTTP/2 makes many of the pre-WebSocket solutions to this problem space
> much cheaper.  QUIC will probably make it even more so.  If there are
> people who feel strongly that WebSockets still meet a need over a modern
> HTTP, I'm happy to read and occasionally comment, but I don't feel called
> to be integral to that work.
>
> -----Original Message-----
> From: Poul-Henning Kamp [mailto:phk@phk.freebsd.dk]
> Sent: Sunday, November 27, 2016 1:19 PM
> To: Van Catha <vans554@gmail.com>
> Cc: Mark Nottingham <mnot@mnot.net>; Takeshi Yoshino <tyoshino@google.com>;
> Willy Tarreau <w@1wt.eu>; Andy Green <andy@warmcat.com>;
> ietf-http-wg@w3.org Group <ietf-http-wg@w3.org>; Wenbo Zhu <
> wenboz@google.com>; Martin Thomson <martin.thomson@gmail.com>
> Subject: Re: WiSH: A General Purpose Message Framing over Byte-Stream
> Oriented Wire Protocols (HTTP)
>
> --------
> In message <CAG-EYCiVExcyHLoXB1ixQCKduxUPTVOnV
> X1XrmFJ3b72Y8AAFg@mail.gmail.com>
> , Van Catha writes:
>
> >So can we form a new WG then and focus on doing this right vs making
> >WebSocket2.  The focus earlier was to get the already coded clients and
> >API (websocket API) to be able to work with websockets layered on
> >HTTP2/QUIC, if we are in it for the long haul now we might as well form
> >a new group and create something more long term?
>
> Apologies for asking a stupid question, but isn't that exactly what QUIC
> is all about in the first place ?
>
> --
> 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.
>
>