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

Re: [websockets] Making optional extensions mandatory in the API

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>
Message-ID: <op.vy0zfau964w2qv@annevk-macbookpro.local>
On Fri, 22 Jul 2011 12:45:42 +0200, Takeshi Yoshino <tyoshino@google.com>  
> 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  

Anne van Kesteren
Received on Friday, 22 July 2011 14:49:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:43 UTC