Subject: [hybi] Layered sub-protocols and separate RFCs (was: Reliable message delivery (was Re: Technical feedback.))

From: Jamie Lokier <[email-masked]>
Date: Wed, 3 Feb 2010 00:10:11 +0000

Greg Wilkins wrote:
> 
> Francis,
> 
> I'm all for protocol layering and if features can be
> implemented in a subprotocol, then they probably should be.
> 
> However, we don't want to force subprotocols into having to
> re-implement TCP with timeouts, keep-alives, acks etc.
> if a few simple features in the base protocol can expose
> more of TCP/IP's capabilities to the layered protocol.

I do agree with Greg that, since certain features *should* be common
to all/most robust applications (otherwise they won't be robust), it
is useful for them to be provided by generic WebSocket implementations.

But there is an argument for keeping WebSocket itself simple, for
people who just don't want to have to implement a complex
specification.  Some applications don't run on the general internet,
after all, and don't need the same level of robustness.

With all the different views, and general desire for simplicity and
getting on with things, my thoughts go like this:

   - Let's layer most things into optional sub-protocols *on top of*
     WebSocket.  Yes, including timeouts, keepalives, orderly close, etc.

   - Let's *standardise* the sub-protocols we care about, but as
     *separate RFCs*.  Almost everything we've discussed works fine as
     a sub-protocol.  There is a certain amount of API implied with some.

   - Let's standardise a way to *negotiate* sub-protocols, and a method
     for the WebSocket implementation to participate in sub-protocols
     it knows about directly, while letting the application implement
     other sub-protocols unknown to the WebSocket implementation.

   - Let's *encourage* generic WebSocket implementations to handle a
     particular "core set" of sub-protocols, without *requiring* them to.

Then we can settle on WebSocket/1.0 more quickly.  Implementations can
roll out soon, and they can pick up additional sub-protocols over time
as proves beneficial.

Generic implementations (i.e. in browsers) would be encouraged to
track the "core set", especially any sub-protocols which improve
performance or robustness.  Custom clients and servers (not using a
generic WebSocket implementation) would implement only what they need,
but the "core set" would serve as a recommendation and, effectively,
explain why.

Standardised sub-protocols would be implemented in Javascript by
app authors who were keen to use them in older (by then) browsers.
That's the same as people do with XHR - those who care write
old-browser compatibilty code.

In that plan, the main things to get right for WebSocket/1.0 will be:

   - Generic negotiation.  I envisage both sides send a header
     containing a comma-separated list of sub-protocol names, in that
     part of the handshake where headers are flexible.  However, the
     textual protocol field we already have would do - if it's syntax
     for this purpose is standardised.

   - Mechanism for Javascript to tell browser WebSocket which
     sub-protocol names it is willing to implement itself (perhaps
     even insists on), which the browser handles itself, and to get
     back the names sent by the other end.

   - Discuss if we want mandatory sub-protocols, separate from
     optional ones.  (Think: HTTP Expect).  Because this must
     be done right, early on, to avoid future pain.

   - Discuss if proxy opt-in is something that can be left for later,
     or if a hook is needed from the beginning.

-- Jamie