I agree we shouldn't require deflate-stream it in the API. I don't agree the API should specify an exact set of extensions, as that would prevent any future versions/developments. A minimum baseline would be reasonable though, once we have that minimum baseline in place (e.g. a stable set of extensions that are well tested, such as compression and multiplexing). I don't think we should put the cart before the horse.
-Ian 2011/7/27 James Robinson <[email protected]> > On Wed, Jul 27, 2011 at 3:14 PM, Ian Fette (イアンフェッティ) > <[email protected]>wrote: > >> I don't think we want to "forbid" any extensions. > > > At the protocol level, sure. At the API level we have to pick which > functionality user agents are required to support and which they are > required not to support, having 'optional' stuff is not an option. It > sounds like you are saying that deflate-stream is bad, so we should not have > it in the API. > > - James > > >> 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 <[email protected]> >> >>> On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) <[email protected] >>> > 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 >>>> <[email protected]>wrote: >>>> >>>>> On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino < >>>>> [email protected]> 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/ >>>>> >>>> >>>> >>> >> >
