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