We are talking about it at IETF81 this week.
That said, I think either way browsers should not require deflate-stream. I
am hoping we can make forward progress on deflate-application-data (
http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01).
If we can get that through the process I could live with Chrome being
required to support that. As for the protocol doc, the protocol lists
deflate-stream as an example, not a requirement, so the mere fact that I
don't want to support that particular extension isn't necessarily the
strongest argument for taking it out of the protocol as the protocol doesn't
require that it be supported. The API should not require the support of that
particular extension either, as that extension is particularly bad.
-Ian
On Wed, Jul 27, 2011 at 11:11 AM, Anne van Kesteren <annevk@opera.com>wrote:
> On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino <tyoshino@google.com>
> wrote:
>
>> So, let me correct my text by s/XHR/HTML5 <http://www.w3.org/TR/html5/>/*
>> *.
>>
>
> HTML5 is mostly transport-layer agnostic.
>
> I am not sure why we are going through this theoretical side-quest on where
> we should state what browsers are required to implement from HTTP to
> function. The HTTP protocol has its own set of problems and this is all
> largely orthogonal to what we should do with the WebSocket protocol and API.
>
> If you do not think this particular extension makes sense raise it as a
> last call issue with the WebSocket protocol and ask for the API to require
> implementations to not support it. Lets not meta-argue about this.
>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>