All,

Attached in a very very early draft of an alternative proposal for a
transfer protocol for HTML5 WebSockets.  For lack of a better
name (and not wanting to coopt the hybi name), I've called it

  BWTP - Bidirection Web Transfer Protocol

I wont explain the protocol here, as hopefully the proposal
document does that sufficiently well.

But I will explain why I think this proposal (or something
approximately similar) is superior to the current Websocket
protocol proposal:

 + The protocol is very much an IETF style application
   protocol.  In fact it is just RFC2616 with anything
   non bidirectional ripped out.
   It is not trying to be a revolution in web protocols,
   but simply to solve the problems at hand.

 + The protocol document is written very much in IETF style.
   In fact it is just RFC2616 with anything non bidirectional
   ripped out.   BNF is used to specify the protocol and the
   principal of "be strict in what you generate and forgiving
   in what your parse" is adhered to.

 + Because of it's similarity to HTTP, it is intended that
   existing HTTP clients, servers and intermediaries will be able
   to be minimally updated to support this protocol.
   This will not require entirely new protocol libraries
   to be developed.   Existing development and analysis
   tools will also be able to be easily updated, plus
   the protocol is mostly human readable.

 + It supports full mime encapsulated payloads, but has
   a default mechanism so that most values only need to
   be specified once per connection if they do not change.

   The minimal overhead per message is 11 bytes, which is
   a little more than the websocket proposal, but is hardly
   significant.

 + There is no formal channel mechanism like BEEP has,
   but each message may be to/from a different URI if
   need be.  This makes multiplexing easy to support.

 + There is no formal segmentation mechanism, but
   Content-Ranges are supported so that large content
   cna be sent in smaller bits if desired.

 + The protocol recognizes that intermediaries (proxies) may
   wish to be an active party on a bi direction connection.
   For example, this proposal allows an intermediary to
   initiate and orderly lossless close of the connection.
   I'm sure innovative proxy applications will be
   developed over time, just as they have been for HTTP.

 + it well supports the current HTML WebSocket API
   but is also flexible and extensible so that non
   browser clients may use it and future APIs will
   not need protocol changes.

I'd really appreciate any feedback, co-authors, review,
editing etc.   I don't consider anything in this proposal
to be fixed and all is open to change.

I have the draft in Google Docs and am happy to add
collaborators (there are a few already (who should add
themselves to the authors/acknowlegements)).


cheers