Re: [hybi] WS framing alternative

[Greg Wilkins <[e-mail]>]

Ian Hickson wrote:

> I'm proposing making the protocol so simple that dedicated frameworks are 
> superfluous.

You are proposing a revolution in server infrastructure.

There is just no way that any of the organizations that I work
with are going to allow a server side application developer
access to a raw socket exposed on the internet!

No matter how much you think it a bad idea, there will be frameworks
that implement websocket on the server side - and they will have
little or no idea of the type of application that might be run
on top of them.



>> If a ws client connects to a ws server, and neither knows if the other 
>> supports some layered protocol - how do they discover that?
> 
> If a TCP client connects to a TCP server, and neither knows if the other 
> supports some layered protocol - how do they discover that?
> 
> The answer is the same.

No it's not.

You run an *extensible* protocol like HTTP over TCP, so that
new protocols can be layered on top without breaking clients,
servers or intermediaries.



> That is, I do not see how our goals could ever be met by the same 
> protocol, if I understand your goals correctly.

I don't see how allocating 1 bit of 7 unused can render
the protocol unsuitable for your goals.

You are being a tad melodramatic I think.



>> I'm asking for 1 bit to be allocated to indicate that a frame
>> contains mime-encoded data.    That is mostly sufficient
>> for layered protocols to be built on.
> 
> Do you mean a third framing mechanism? Or would it reuse the text or 
> binary framing mechanism?

I would reuse the text and binary framing mechanism.

I would suggest that for meta-data packets if the framing
type was utf-8 then the packet would contain just headers (which
layered protocols could define to applying to the connection, the next
frame or whatever).

If the framing type was binary, then the packet can contain standard
mime encoded content.


[ I would also advocate that the high bit be just a selection
between utf-8/binary and that all frames be length encoded,
but that's a different debate ]


> If the latter, then it's unnecessary -- you just have to define that all 
> frames a MIME encoded, or all frames are MIME encoded if their first 
> byte/character is 0x01/U+0001, or some such. It doesn't have to be at the 
> WebSocket protocol level.

but how do you know if the other end supports mime encoding at all.
you end up needing to do all sorts of discovery and other complexities.

Browser vendors and server vendors might want to collaborate
on a multiplexing protocol built on top ws.  They could use the
the mime frames to do this - but they would be able to continue
to work with browsers and servers that did not implement the
extension - as they would ignore meta data they didn't understand
that was used to try to negotiate a multi-channel connection.


> The WebSocket protocol level basically is just a reflection of the API. 
> Just like the API doesn't have a sendDataMimeEncoded() method, and doesn't 
> have a message-mime-encoded event, the protocol doesn't have anything 
> special for sending or receiving MIME-encoded data. It's purely an 
> application-layer concern. Why would we add a sendDataMimeEncoded() 
> method? What problem would it solve for scripts?

I'm not asking you to add a sendDataMimeEncoded method for the
application developers to use.

The extra capabilities could be used by the browser, intermediaries
and/or servers.   They need not be exposed to application developers,
you could even argue that they shouldn't be exposed to application
developers.


> I think overgeneralisation is one 
> of the biggest mistakes one can make in protocol and language design. My 
> experience has led me to be a firm believer in picking specific problems
> and addressing them directly, rather than trying to solve everything at 
> once (especially when one might not know all the problems one is trying to 
> solve -- a common problem when discussing extensibility mechanisms).


You have already generalized the protocol by allowing for other
frame types.    The only difference is who controls the use
of that generalization.

You obviously want to control how people extend WS and will only
allocate new frame byte values to what you think is worthy cause.

If there was a meta data frames, then anybody could extend
the protocol without the need to ask permission ( even if it was
to support evil monolithic servers and their unholy load balancing
companions).


What authority do you plan to manage the allocation of frame types
into the future?  IANA?


>> So browsers could add on their origin security model for example.
> 
> Security is not a feature you bolt on. It's an architecture that has to 
> be designed in from the beginning.

RUBBISH!

If this was the case we would have to put the same origin policy
into TCP... no wait into IP... no wait into ethernet..

You can design a good protocol for the security needs of
browser that is built on a more general transport protocol.
It also helps if that transport protocol was designed to
allows such extensions.


> Browsers are the only reason for WebSocket existing. If it wasn't for the 
> needs of scripts in Web pages, TCP would be a perfectly adequate solution 
> for bidirectional communication for me, and I wouldn't be here. 

Well browsers don't do you much good without servers
and other network infrastructure.  So you have to consider
their needs as well.

Plus there are plenty of others here that do care about clients
other than scripts in web pages.

It is my understanding of IETF policy that if you want to
get this protocol approved you need to get a rough consensus
of people with more concerns than just your own.


> Could I ask you to more concretely describe your problem so that I could 
> more concretely (maybe with actual code examples) describe the alternative 
> solution that I am describing?

sticky load balancer with SSL offload that works with any ws app.

multiplexing protocol implemented in browser/server (not in application).

orderly closing a ws connection implemented in an application
independent way.

regards