[whatwg] BWTP for WebSocket transfer protocol

[Greg Wilkins]

Jonas,



Jonas Sicking wrote:
> Can you suggest changes to the WS protocol that would make it a better
> general-purpose protocol? 

There were several threads on the IETF HYBI mailing list with some such
proposals:

  http://www.ietf.org/mail-archive/web/hybi/current/maillist.html

An example of such a message is at the bottom of this email.
However, the response to such proposals was pretty much that
they were too complex and not needed for the ws API.

It was the result of those interactions that suggested to me
that a bidirectional web protocol would be best developed
at arms length to the websocket API, and thus the BWTP
effort was born.

So far the feedback I have received on BWTP is suggesting
that it has perhaps gone a little too far the other way
and that there are probably some significant simplifications
that can be achieved without greatly restricting the feature
set.


> You've suggested multiplexing, segmentation,
> per-frame mime-type and per-frame meta-data so far. Is there anything
> else that is needed? It would also be good to know what use cases you
> have in mind for all of these features in order to evaluate them.

Predicting the future is always hard, but using the present
as an indicator is good start.

Currently the majority of the web traffic is carried over HTTP
which is capable of multiplexing, segmentation, per-frame mime-type
and per-frame meta-data.

I don't see why adding bidirectional capability should result in any
significant reduction in these capabilities of web transports.


For example, HTTP can well transport a vast array of content types
with meta data support to negotiate accepted languages, types and
encodings.

The ws API can only handle UTF-8 text datagrams, so as a result
the ws protocol has special case handling for UTF-8 text datagrams.


So I think that our starting point should be to develop a
bidirectional protocol that can well support the current web
transport capabilities.   I would say that anybody
who wishes to advocate a less capable transport should
be ask to make the case of why capabilities should be
lost with bidirectional protocols.


regards



Example proposal to improve websocket protocol that
was rejected:

Greg Wilkins wrote:
>> It would be great if the websocket proposal could include
>> standard definitions for mime encoded datagrams.
>>
>> Current frame types are:
>>
>>   0x00  - sentinel framed UTF-8 message
>>   0x80  - length framed binary data.
>>
>> I'd like to see two additional frame types supported
>> by default:
>>
>>   0x01  - sentinel framed UTF-8 encoded MIME message
>>   0x81  - length framed MIME message.
>>
>> Both these data types would contain a data that commenced
>> with a standard mime header (RFC 2045).   The header is optional
>> and terminated by CR LF CR LF.  Thus these types have a minimal
>> overhead of 4 bytes.
>>
>> For both these types, any Content-Length header will be
>> ignored and the length indicated by the websocket framing
>> minus the header length will be used.
>>
>> For 0x01 types the content type is assumed to be "text/plain; charset=utf-8"
>> If a content type header is specified, it must be "text/????; charset=utf-8"
>>
>> For 0x81 the content type is assumed to be application/octet-stream unless
>> otherwise indicated.
>>
>> The websocket API would need to be slightly extended to support some
>> common types of message.
>>
>> I would suggest that onmessage always be called for all text
>> mime types, but with some additional parameters: eg.
>>
>>   onmessage(text,mimetype,headers)
>>
>> The browser would be responsible for converting the transported
>> charset to the charset of javascript. If the conversion could not
>> be done, then the message would be discarded.
>>
>> Additional events could be supported if you want the browser/server
>> to do the parsing for your.   For text/xml & text/html:
>>
>>   ondocument(dom,headers)
>>
>> and for text/json
>>
>>   onobject(object,headers)
>>
>>
>> To send such messages, the API would also need to support
>>
>> void postMessage(data,headers);
>>
>>
>>
>> I think this is a minimal change to websocket and would go a long
>> way to address many of the concerns raised here.    With the ability
>> to send standardized meta data, then the job of coming up with
>> standardized multiplexing is much much simpler.