Re: [hybi] Framing take IV

[Greg Wilkins <[e-mail]>]

On 5 August 2010 13:24, Ian Hickson <[e-mail]> wrote:
> On Thu, 5 Aug 2010, Greg Wilkins wrote:
>>
>> the thing that stops people defining subprotocols is that the concept of
>> a subprotocol is entirely undefined.
>>
>> Currently it is exposed in the js API as a simple string.  There is no
>> indication how that string can be used, how capabilities can be
>> discovered, declared or negotiated.  There is no mechanism to allocate
>> op-codes in the first byte other than to come here and try to convince
>> you that my extension is a good idea.
>>
>> If we can clearly define an extension and/or subprotocol mechanism then
>> I think we would be able to answer the concerns of those that feel the
>> need for particular features but see no way of achieving them in the
>> current protocol.
>
> I'm not sure I follow. A subprotocol wouldn't use "opcodes".

I'm sure a subprotocol would not use opcodes as I'm pretty sure that a
subprotocol is an application concern and therefore nothing to do with
the infrastructure over which the connection passes.

However, things like multiplexing, compression, fragmentation, load
balancing, connection aggregation etc are all concerns of the
infrastructure that would be best implemented transparently to the
application.  That is why we have been talking about extensions as
distinct from sub protocols.

subprotocols are not sufficient for infrastructural extensions.  Let's
assume that somebody invented a multiplexed-ws subprotocol and that it
was widely implemented by browsers and servers.   It supports virtual
connections and the real application sub protocol is sent over the
virtual connections in a virtual handshake.

So the browser supporting this would always send a ws handshake to the
server with the multiplexed-ws subprotocol.   But what if the
application was deployed on a server that did not support that
subprotocol? The only choice if for the server to reject that
handshake (which at the moment also means closing the connection.   So
the browser then has to suffer 2 more RTT while it cracks open a
dedicated basic websocket connection for the application and sends the
real subprotocol this time.     So infrastructure that uses
subprotocols for extensions are heavily penalized.

There are also complications in terms of the subprotocol field is able
to be set by the user.  I want my server to be able to have some
confidence that the extensions that it is negotiating with are from
the browser and not from the user.  We could get into all sorts of
mess if the the application starts pretending to be a browser
extension.

So there is a desire to define an extension mechanism that is above
the base protocol, but below the application layer and sub protocols.
Many think that it would be entirely appropriate for such extensions
to be able to use op-codes without the need to go through a painful
standardization process first in order to get op-codes allocated that
will not clash.


> Is there an equivalent for Comet-style protocols? (That is, subprotocols
> that use HTTP as the transport?)

HTTP is rich with extension points.  You can add new methods,
arbitrary headers, new content types, new URLs etc.
Comet protocols make use of  1 or more of these.