W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

From: Takeshi Yoshino <tyoshino@google.com>
Date: Fri, 22 Jul 2011 19:49:22 +0900
Message-ID: <CAH9hSJZpT8riAyjorAOPXjdQ=UnemNxi2GdWeR9iu_zixT8x+Q@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Greg Wilkins <gregw@intalio.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, Maciej Stachowiak <mjs@apple.com>, Arthur Barstow <art.barstow@nokia.com>, Adrian Bateman <adrianba@microsoft.com>, Ian Hickson <ian@hixie.ch>, "ifette@google.com" <ifette@google.com>, "jonas@sicking.cc" <jonas@sicking.cc>, "simonp@opera.com" <simonp@opera.com>, Brian Raymor <Brian.Raymor@microsoft.com>
Resending. I've made mistake in processing public-webapps@w3.org confirmation
page.

On Fri, Jul 22, 2011 at 19:45, Takeshi Yoshino <tyoshino@google.com> wrote:

> On Fri, Jul 22, 2011 at 18:54, Anne van Kesteren <annevk@opera.com> wrote:
>
>> On Fri, 22 Jul 2011 07:03:34 +0200, Takeshi Yoshino <tyoshino@google.com>
>> wrote:
>>
>>> Think of these facts, the only "dominant implementation" concern I can
>>> come up with for WebSocket compression is that big service provides may take
>>> an aggressive policy that they require users to use only WebSocket client
>>> with compression capability to reduce bandwidth. As a result clients with no
>>> compression capability may, in effect, be kicked out of WebSocket world.
>>>
>>> I can understand that concern. Is this true for the HTTP world? I.e.
>>> clients that send "Accept-Encoding: \r\n" cannot live?
>>>
>>
>> Yes. Optional features for browsers do not work. For servers it is fine if
>> they do not support compression or whatnot, but browsers pretty much need to
>> align on feature set.
>
>
> In summary, your point seems to be that we must choose feature set that is
> considered to be taken by majority as optimal like HTTP/gzip, and ask
> browsers to support that by specifying it the W3C spec (*). I see that. It
> might make sense. However deflate-stream is not yet considered as the
> optimal choice in the HyBi WG and we're trying to introduce better one. Even
> some are doubting if it's worth using deflate-stream compared to identity
> stream.
>
> Requiring all browsers request (== implement) deflate-stream can be asking
> everyone to do thrown-away work as a result. Is this acceptable?
>
> Based on W3C's stance (*) and IETF's stance, the only landing point is
> initially enforcing browsers to use identify encoding except for
> experimenting new compression, and when IETF provides new compression
> extension good enough to recommend, update the API spec to switch to that.
>
> Takeshi
>
>
Received on Saturday, 23 July 2011 15:01:43 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:46 GMT