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

Bug 12917 [1] has been discussed in at least bugzilla as well as e-mail 
including this thread started by Adrian (Hixie's follow-up is [2]) and 
Adrian's general Web Sockets LC thread [3].

This bug is currently resolved as WontFix and this resolution is 
supported by at least Hixie and Jonas. Adrian, Takeshi and Greg have 
argued against this resolution (i.e. they do not support deflate-stream 
being a mandatory extension in the API).

What do others (Anne?, Maciej?, ...) think about this issue?

Given the Protocol is now in LC review, it seems relatively important to 
align the API and Protocol.

-Art Barstow

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917
[2] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0242.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0193.html

On 7/8/11 5:44 PM, ext Adrian Bateman wrote:
> 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.
>
> Adrian.
>

Received on Thursday, 21 July 2011 15:27:25 UTC