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 13:20:36 -0700
Message-ID: <CAD73mdKF0w_MZHvp-33ny3NnOSS9YzabLiQV-X7O8c98AqmmLg@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 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,

- 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 20:21:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:23 UTC