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

Re: [websockets] Getting WebSockets API to Last Call

From: Arthur Barstow <art.barstow@nokia.com>
Date: Fri, 08 Jul 2011 09:02:20 -0400
Message-ID: <4E16FFDC.2010307@nokia.com>
To: ext Adrian Bateman <adrianba@microsoft.com>
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>, Brian Raymor <Brian.Raymor@microsoft.com>
On 7/7/11 6:00 PM, ext Adrian Bateman wrote:
> We're keen to resolve the remaining issues with the WebSockets API and have a timetable
> to get to Candidate Recommendation. From informal conversations we've had, we believe
> other browser vendors share this goal. I think the current WebSocket API is feature
> complete and meets the requirements for publishing a Last Call working draft to
> encourage wider review and feedback. There are no tracker issues for WebSockets. Here
> is my analysis of the outstanding bugs (not closed, where resolution not Fixed).
> I believe the outstanding issues could be resolved as Last Call comments and would like
> to see a CfC to publish a LCWD shortly.

I think the spirit of the publication process is that all bugs that 
affect an implementation should be resolved before going to LC. As such, 
it would be helpful if others would do as Jonas did and provide feedback 
on the bugs and/or Adrian's general proposal to move to LC "as is". If 
there is consensus within the group to go to LC with these bugs open, we 
can do so, but it may be preferable to do some extra work now if it can 
prevent the overhead of additional LCs.

> 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.

The bug only includes comments from IanH and Adrian. It does seem like a 
mismatch in requirements for deflate-stream to be optional in the 
protocol and mandatory in the API. What do others think about this bug?

-AB
Received on Friday, 8 July 2011 13:03:16 GMT

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