- From: Anne van Kesteren <annevk@opera.com>
- Date: Fri, 22 Jul 2011 16:48:36 +0200
- To: "Takeshi Yoshino" <tyoshino@google.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>
On Fri, 22 Jul 2011 12:45:42 +0200, Takeshi Yoshino <tyoshino@google.com> wrote: > 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. I think like Ian I had not expected features you do no want to see implemented to make it into a final draft. The API can go either way. We could either say MUST NOT or MUST. Optional features is just not really an option. -- Anne van Kesteren http://annevankesteren.nl/
Received on Friday, 22 July 2011 14:49:34 UTC