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

[websockets] Getting WebSockets API to Last Call

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>
Message-ID: <104E6B5B6535E849970CDFBB1C5216EB434F75A2@TK5EX14MBXC136.redmond.corp.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 GMT

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