[whatwg] BWTP for WebSocket transfer protocol

[Greg Wilkins]

Jonas Sicking wrote:

> I agree we should use the experiences from HTTP. However it seems like
> we have different experiences.
> 
> For example mime-types in HTTP have a very troubled record. Look at
> Adam Barth's draft [1] for what browsers are forced to do to stay
> compatible with the web. 

Indeed.  However I would argue that a lot of that problem is probably
the result of the initial HTTP protocol not supporting content types,
so that browsers started infering type from URL extensions etc.
So when a proper mime-mechanism was finally provided, it was too
late as bad practises were entrenched and remain so to this day.

I would hate to see a new protocol repeat this mistake and
start without support for content-types.

> And the problem keeps persisting, for example
> the newly deployed downloadable fonts support in firefox completely
> ignores mimetypes for fonts since no mime type exists for fonts. And
> with video the mimetype situation is very complicated since there's
> both a type of container, as well as type of encoding for video and
> audio inside that needs to be described. And potentially all three
> types can be independent.

There are indeed problems with mime, but I don't think the solution
will be found in not attempting to communicate metadata and thus
forcing sniffing or an assumption based systems as the only
solution.


> Similarly content negotiation is something I would say is even more
> doubtful that it has provided any value. 

I think I'm +1 on it's value and I certainly would not want to
propose something that would enforce any negotiate overheads.
However, having a protocol that allows meta-data does allow
simple negotiation if client/server choose to participate.


> So while I agree that we should look towards existing protocols, we do
> need to be honest about what has been successful and what hasn't, and
> not just assume that of existing protocols do something, it's a good
> idea.

I totally agree.

I think we should start with existing protocols, slice away the
capabilities that are not used and then build from there.

>> 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.
>>>> ....
> 
> If we want mime-support this seems like a good proposal. Except I
> don't understand the point of having the mime header optional? If
> someone wants to send something without a mimetype it seems like the
> other frame types cover that.

The mime head was not optional, it was just proposed that an empty
header (CRLFCRLF) would be legal.    You don't really want to have to
be forced to change framing type just because you don't have any metadata

> I'm curious to hear what you consider the advantages of this over
> simply transmitting for example JSON over a "sentinel framed UTF-8
> message" frame? I.e. can you describe an application that would send
> JSON using the above proposal.

It would be difficult to transport some media types over
JSON on a sentinel framed UTF-8 message.   For example image/jpeg
would not be efficiently sent in JSON.

The meta-data is called meta because it is not part of the payload,
but is about the payload and thus different encodings and framing
are applied to meta data and data by protocols like HTTP (iso8859
CRLFCRLF terminated meta data then arbitrary length/close/chunk
terminated data).

Of course the 0x80 length framed binary data type could be
used to send mime encoded messages, but then there would need
to be other standards to work out what style of meta-data was
used - if at all.

But from a protocol point of view, I simply do not like the
favoured-son status given to UTF-8 messages.  What good is
knowing the character encoding if you don't know if the content
is XML or JSON?  Are we going to have to write sniffers to
look for XML, JSON, HTML content?

Why is utf-8 given it's own framing type (sentinels), when
the length framed binary framing is capable of carry the
messages just as efficiently and the sentinel framing fails
to support common transports such as gzipping etc.

I really think that the ws protocol started from some
assumptions that are just too special case for the javascript
API usage and that it will be easier to come up with new
clean protocols rather than push websocket protocol away
from the assumptions that underlay is basic design.


cheers