Re: [hybi] Requirement: extensions and sub protocols

[Jamie Lokier <[e-mail]>]

Salvatore Loreto wrote:
>    another aspect of the WebSocket protocol we have to discuss is
>    extensibility.
>    As usual here a strawman proposal just to start the discussion...
> 
>      Req. The WebSocket Protocol MUST be designed to easily support
>      extensions.
>      Req. The WebSocket Protocol MUST have a way to declare/negotiate
>      extensions.
>      Req. The WebSocket Protocol MUST be designed to easily support sub
>      protocols
>      Req. It SHOULD be easy for sub protocols implementing features like
>              channels, multiplexing, (what else?)
> 
>    please discuss extensions and subprotocols requirements (and feel free
>    to suggest better text)
>    as usual we need to measure the level of the consensus on them
>    all thoughts or comments are very well welcome and appreciated.

I would like to see a MUST-level placeholder for transport-level
options, where the agents (including proxies) can do things like
opportunistic multiplexing, keepalive merging and negotiation, and so
on without the application having to know about these things at all.

There may still be room for the application to explicitly disable
transaport-level things it doesn't want used, and to be informed about
what does get used if it cares.  But applications which don't care and
use just the basic API should not prevent transport optimisations from
being used automatically by future agents.

We don't necessarily need any actual options to be standardised, only
a mechanism by which they can be negotiated without breaking communications
with agents that don't support them.

To do this requires:

    - The client can send at least one additional request header (or
      something equivalent) which will be recognised by an aware
      server or proxy, and is guaranteed not to impede processing by
      unaware ones.

    - Same for the response.

    - That a client adding the additional header (or something else)
      does not interfere with application-level protocol negotiation.
      This is why it cannot be part of the application-specified
      protocol field.

    - That a server responding to the additional header (or something
      else) does not have false positivies due to matching something
      which could be sent by the application.  This is a second reason
      why it cannot be part of the application-specified protocol
      field.

    - Ideally it would be subject to many of the same validations
      constraints as the main WebSocket handshake:

       + That it's likely to be modified by unaware proxies, or even
         better, some options likely to be modified, some not, so that
         hop-by-hop transport techniques can be negotiated separate
         from end-to-end techniques.  The "Connection" header may be
         useful, if it works.  Perhaps there is a role for "Expect",
         but I vaguely recall reports (on ietf-http-wg list, I think)
         that Expect is not reliably acted upon despite being a MUST
         level requirement in RFC2616.

       + That a "dumb" HTTP server which is not a WebSocket server is
         unlikely to appear, to the client, to understand these
         options by simply reflecting them back.

       + That "dumb" WebSocket servers ;-) must not appear to understand
         these options by simply reflecting them back or similar.

I don't know if that is every detail required.  Hopefully the general
principle is conveyed, and maybe the general principle is enough for
the Requirements document.

-- Jamie