- From: Adrian Bateman <adrianba@microsoft.com>
- Date: Thu, 7 Jul 2011 22:00:27 +0000
- To: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
- CC: "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>
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. 9973 - If the entry's name is "sec-websocket-protocol" 0 please don't put normative requirements in parenthesis Resolved, NeedsInfo MICROSOFT PROPOSAL: close the bug - this bug is a year old, likely out of date now, and from an anonymous contributor 10213 - The definition of "absolute url" makes https:foo not an absolute url Open, Assigned to Adam Barth MICROSOFT PROPOSAL: Section 3 of the protocol spec (http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-3) shows the valid syntax for a ws-URI. We believe the API should throw a SYNTAX_ERR if the address supplied does not match this format. 12180 - give the name of url to download the Jetty server Resolved, NeedsInfo - this bug is from an anonymous contributor from 4 months ago MICROSOFT PROPOSAL: close the bug - the API spec doesn't need to link to server implementations 12510 - Specs split off from HTML5 (like WebSockets) need to have xrefs linked, otherwise they're ambiguous Reopened, Assigned to Ian Hickson MICROSOFT PROPOSAL: this is an editorial bug that should not block Last Call 12816 - Make second argument in constructor an object for future extensibility Resolved, WontFix MICROSOFT PROPOSAL: We think the second argument should be an object, not only for future extensibility but to allow binaryType to be set now. 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. 13104 - 1) ping(msg); //allow client to send server ping as per websocket spec 2) onpong(); //allow client to receive response of ping Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: We don't think this is necessary. 13162 - The notes really do need to be cleaned up to be made explicit. Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial bug and should not block Last Call 13178 - binaryType should be immutable after connection is established Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug. 13180 - [Editorial] Causes that lead to failing the WebSocket connection, which results in an error event, should be more clearly specified Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial issue and should not block Last Call.
Received on Thursday, 7 July 2011 22:00:55 UTC