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 <jamesr@google.com>
> On Wed, Jul 27, 2011 at 3:14 PM, Ian Fette (イアンフェッティ) <ifette@google.com>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 <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/
>>>>>
>>>>
>>>>
>>>
>>
>