Re: [hybi] Extensibility mechanisms?

[Greg Wilkins <[e-mail]>]

All,

the issue that I have with the current subprotocol field allowed
in the handshake is that it is a) singled valued and b) exposed
in the application API.

So we have to assume that applications and frameworks are going
to invent all sorts of subprotocols and put all sorts
of values into this field... probably frequently for usages
that have nothing to do with sub protocols.

So if a browser, server and/or intermediary wish to negotiate
other extensions (eg for compression, multiplexing, etc. etc.),
then the protocol field is effectively unavailable for that
purpose.

Note that I don't think this is a bad thing.  I think it is
good that the application is able to effectively send arbitrary
meta data along with a handshake (I can imagine B64 encoded json
and/or XML being sent).   I think the protocol field is great
for that purpose (even if calling it "protocol" is probably
not exactly right).

We just need another field, so that entities below the
level of the API can negotiate and apply extensions.
This field needs to be multi valued, so that multiple
extensions can be applied.  However, I expect that some
extensions will be mutually incompatible.

cheers