W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

From: James Robinson <jamesr@google.com>
Date: Wed, 27 Jul 2011 15:22:18 -0700
Message-ID: <CAD73md+vxwcQGPAM2hTTHTOo8KLhqzwRGcAUTLnyu8g6BVgkTA@mail.gmail.com>
To: ifette@google.com
Cc: Anne van Kesteren <annevk@opera.com>, Takeshi Yoshino <tyoshino@google.com>, Aryeh Gregor <Simetrical+w3c@gmail.com>, Adrian Bateman <adrianba@microsoft.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, Maciej Stachowiak <mjs@apple.com>, Arthur Barstow <art.barstow@nokia.com>, Ian Hickson <ian@hixie.ch>, "jonas@sicking.cc" <jonas@sicking.cc>, "simonp@opera.com" <simonp@opera.com>, Brian Raymor <Brian.Raymor@microsoft.com>, Greg Wilkins <gregw@intalio.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/
>>>>
>>>
>>>
>>
>
Received on Wednesday, 27 July 2011 22:22:53 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:46 GMT