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 <jamesr@google.com>
> On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) <ifette@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 <annevk@opera.com>wrote:
>>
>>> On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino <tyoshino@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/
>>>
>>
>>
>