Resending. I've made mistake in processing [email protected] confirmation page.
On Fri, Jul 22, 2011 at 19:45, Takeshi Yoshino <[email protected]> wrote: > On Fri, Jul 22, 2011 at 18:54, Anne van Kesteren <[email protected]> wrote: > >> On Fri, 22 Jul 2011 07:03:34 +0200, Takeshi Yoshino <[email protected]> >> 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 > >
