I don't think we want to "forbid" any extensions. The whole point of extensions is to allow people to do something that doesn't necessarily have consensus by a broad enough group to be in the base protocol. That said, I think a lot of people would be happier if deflate-stream were an independent document as opposed to being the only extension included in the core specification as a "known extension".
-Ian 2011/7/27 James Robinson <jam...@google.com> > On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) > <ife...@google.com>wrote: > >> We are talking about it at IETF81 this week. >> >> That said, I think either way browsers should not require deflate-stream. >> I am hoping we can make forward progress on deflate-application-data ( >> http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01). >> If we can get that through the process I could live with Chrome being >> required to support that. As for the protocol doc, the protocol lists >> deflate-stream as an example, not a requirement, so the mere fact that I >> don't want to support that particular extension isn't necessarily the >> strongest argument for taking it out of the protocol as the protocol doesn't >> require that it be supported. The API should not require the support of that >> particular extension either, as that extension is particularly bad. >> > > Sounds like the consensus is to forbid this extension at the API layer, > then. > > - James > > >> -Ian >> >> On Wed, Jul 27, 2011 at 11:11 AM, Anne van Kesteren <ann...@opera.com>wrote: >> >>> On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino <tyosh...@google.com> >>> wrote: >>> >>>> So, let me correct my text by s/XHR/HTML5 <http://www.w3.org/TR/html5/ >>>> >/**. >>>> >>> >>> HTML5 is mostly transport-layer agnostic. >>> >>> I am not sure why we are going through this theoretical side-quest on >>> where we should state what browsers are required to implement from HTTP to >>> function. The HTTP protocol has its own set of problems and this is all >>> largely orthogonal to what we should do with the WebSocket protocol and API. >>> >>> If you do not think this particular extension makes sense raise it as a >>> last call issue with the WebSocket protocol and ask for the API to require >>> implementations to not support it. Lets not meta-argue about this. >>> >>> >>> >>> -- >>> Anne van Kesteren >>> http://annevankesteren.nl/ >>> >> >> >