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

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

From: Adrian Bateman <adrianba@microsoft.com>
Date: Fri, 8 Jul 2011 21:44:03 +0000
To: Ian Hickson <ian@hixie.ch>
CC: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, "ifette@google.com" <ifette@google.com>, "jonas@sicking.cc" <jonas@sicking.cc>, "simonp@opera.com" <simonp@opera.com>, "art.barstow@nokia.com" <art.barstow@nokia.com>, Brian Raymor <Brian.Raymor@microsoft.com>
Message-ID: <104E6B5B6535E849970CDFBB1C5216EB434FE41D@TK5EX14MBXC136.redmond.corp.microsoft.com>
On Friday, July 08, 2011 1:12 PM, Ian Hickson wrote:
> > 12917 - "deflate-stream" should be an optional extension when
> establishing a connection
> > Resolved, WontFix
> > MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling
> the protocol spec
> > on what is optional in the protocol. The API spec should not
> normatively mention specific
> > extensions. References to "deflate-stream" should be informative and
> only provided as examples.
> I strongly disagree. We must have interoperability amongst browser user
> agents. Having some support compression and others not would lead to
> authoring mistakes and will force us into either having or not having
> compression based on how big sites first get this wrong.

It's fine to disagree, but you should disagree in the IETF working group where
this is made optional and not in the Web API. There will be other users of
WebSockets outside the browser and by implementing the protocol they won't be
required to implement this extension. In addition, there are still discussions
about whether this is an appropriate mechanism for compression since it requires
intermediaries to decompress the whole stream if they want to review messages.
There are still proposals to remove deflate-stream from the spec.

We think there are legitimate cases for implementing the protocol without
compression. That aside, however, we strongly disagree with one consumer of a
protocol, the Web API, making decisions to override the requirements of the
protocol spec.

Received on Friday, 8 July 2011 21:44:34 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:33 UTC