Subject: [hybi] Informal survey: "Non Request-Response Communication over the Web, and What's Missing"

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 16 Jan 2015 17:42:19 +0900

Hi all,

I and Wenbo did an informal survey of protocol gaps. We hope this would
help moving forward the discussions about protocol/API design to some
extent.

https://github.com/bidiweb/bidiweb-semantics/blob/master/SurveyOfProtocolGaps.md

---

From: Joakim Erdfelt <[email-masked]>
Date: Fri, 16 Jan 2015 05:49:50 -0700

Some commentary ...

Be careful with "reliable data delivery".
This has many different meanings to different people.

Bayeux and Cometd (for example) have acknowledgement extensions
specifically for unreliable data networks (mobile) that allow the server or
client to know if the opposite side has received the complete message or
not.

This level of reliable message delivery could probably exist as a WebSocket
extension. a message-ack extension with exposure at the various WebSocket
APIs.

WebSocket Gaps:

1. Half-Closed

half-closed connections are currently supported by the WebSocket protocol
spec.
and many existing implementations do it correctly today (thanks autobahn!)
several libraries already rely on this behavior (bayeux, cometd)

however, other layers, apis, and non-websocket bugs can cause problems here.
eg: its impossible with Android 5.x to do half-closed via SSL, on any
protocol, mostly due to many horrid bugs in their SSLEngine.

2. Flow-Control

For standard http/1.1 (not http/2) this is handled at the tcp/ip level.
For http/2 this is handled by its flow-control parts of that spec.
What else do you mean here?
Is this section about how to expose this on the Javascript WebSocket API?

3. Message-level metadata

Let this be part of an application specific protocol layer, or an extension
handling it (with Javascript WebSocket API changes to expose extension
manipulation. see below)
Note: This is quite a passionate topic on the ietf-http-wg mailing list
also, with more people against it than for it.

4. Keep-Alive

Most existing applications are happy with a combination of tcp/ip
keep-alive and websocket ping/pong so far.
With http/2 there's other keep-alive strategies.
Is is really a WebSocket protocol gap?
Or just another Javascript WebSocket API gap?

5. Multiplexing and session priority

One concern with the common response: WebSocket over HTTP/2 will address
this.
It seems that the folks running the http2 spec track (ietf-http-wg) have
punted and want hybi to define it, and the folks here at hybi seem to think
that the ietf-http-wg folks will define it.  Have there been some
discussion between these 2 groups yet? (even offline / face to face?)

The Layering Concern:

Don't forget, the websocket extensions are a layer too.

Other thoughts:

If this is an effort to get baseline of effort for the Javascript WebSocket
in the browser, then you also have the following often asked questions ...

* Handling authentication / authorization credentials.  submitting them,
and getting reasonable error messages out of the API for when problems
occur.
* Controlling extensions, both at the initial handshake, and ongoing in the
write/send apis (think compress / dont compress flags as a real world
usecase for today)
* Better error messages when use of the API results in failure to
open/connect due to violation of WebSocket spec rules

--
Joakim Erdfelt <[email-masked]>
webtide.com <http://www.webtide.com/> - intalio.com/jetty
Expert advice, services and support from from the Jetty & CometD experts
eclipse.org/jetty - cometd.org

On Fri, Jan 16, 2015 at 1:42 AM, Takeshi Yoshino <[email-masked]>
wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: Roberto Peon <[email-masked]>
Date: Fri, 16 Jan 2015 10:18:55 -0800

My impression is that we need working code before we worry about the spec.
I hadn't been able to make that happen in my time, and as a result it
didn't get into the HTTP2 spec.

-=R

On Fri, Jan 16, 2015 at 4:49 AM, Joakim Erdfelt <[email-masked]> wrote:

> This level of reliable message delivery could probably exist as a
> WebSocket extension. a message-ack extension with exposure at the various
> WebSocket APIs.
>
> WebSocket Gaps:
>
> 1. Half-Closed
>
> Let this be part of an application specific protocol layer, or an
> extension handling it (with Javascript WebSocket API changes to expose
> extension manipulation. see below)
> If this is an effort to get baseline of effort for the Javascript
> WebSocket in the browser, then you also have the following often asked
> questions ...
>
> * Controlling extensions, both at the initial handshake, and ongoing in
> the write/send apis (think compress / dont compress flags as a real world
> usecase for today)

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 27 Jan 2015 21:54:28 +0900

Thanks for the comments, Joakim.

> WebSocket extension. a message-ack extension with exposure at the various
Good point. We cut the details but it might have just led to confusion.
I'll fix it.

> several libraries already rely on this behavior (bayeux, cometd)

Right. It's missing on the WebSocket API.

> Is this section about how to expose this on the Javascript WebSocket API?
Yes. Flow control is not exposed to the API level. A script cannot pose any
backpressure on a WebSocket without blocking the main thread.

> Or just another Javascript WebSocket API gap?

Yes. It's about the API. Sorry that it's unclear.

> discussion between these 2 groups yet? (even offline / face to face?)
No decision is made officially yet, I think.

> Don't forget, the websocket extensions are a layer too.
Yes!

> open/connect due to violation of WebSocket spec rules
Thanks for the list. Yeah, there're lots of overdue things.

The doc is not only for WebSocket API refinement. More general discussion
about what's the best messaging API/protocol we should build for better web
ecosystem.