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
>
>