The IETF HyBi WG has moved beyond Last Call and has presented the WebSockets
protocol to the IESG for approval:
http://www.ietf.org/mail-archive/web/hybi/current/msg08640.html
Now that the protocol is more stable, I think that the current WebSockets API
is feature complete and meets the requirements for publishing a Last Call
working draft to encourage broader review and feedback.
Here is my review of the outstanding bugs (not closed, where resolution not
Fixed). I recommend that the outstanding issues 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
12180 - give the name of url to download the Jetty server
Resolved, NeedsInfo
MICROSOFT PROPOSAL: Close the bug - This bug is from an anonymous contributor
from 6 months ago. 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
13104 - 1) ping(msg); //allow client to send server ping as per websocket spec
2) onpong();//allow client to receive response of ping
Resolved, NeedsInfo
MICROSOFT PROPOSAL: Close the bug - It's not necessary to include API support
for ping/pong. In addition, this bug has been inactive for two months.
13172 - The definition for [MessageEvent] is missing
Resolved, NeedsInfo
MICROSOFT PROPOSAL: Close the bug - It's been inactive for a month and
MessageEvent is defined in the HTML5 Web Messaging specification.
13700 - W3C SotD of this document still mentions whatwg.org version of the
WebSocket protocol which is out of date.
New, Assigned to Ian Hickson
MICROSOFT PROPOSAL: This is an editorial bug that should not block Last Call
13777 - The WebSocket protocol draft (hybi-10) restricts the value of
subprotocols as follows: The elements that comprise this value MUST be non-
empty strings with characters in the range U+0021 to U+007E not including
separator characters as defined
New, Assigned to Ian Hickson
MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug.
13984 - Need a way to object detect which binary formats are supported before
connecting
New, Assigned to Ian Hickson
MICROSOFT PROPOSAL: Close the bug. The original issue (binary support detection
in Chrome) should be addressed in WebKit. The additional scenario (querying
which binary types are supported) is not required in V1.
13990 - Need a spec for CloseEvent constructor
New, Assigned to Ian Hickson
MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug.
14057 - In section "The WebSocket interface" when describing the operation of
the WebSocket constructor, the following statement is made: "Return a new
WebSocket object, and continue these steps in the background (without blocking
scripts). ...
New, Assigned to Ian Hickson
MICROSOFT PROPOSAL: Resolve the bug as duplicate (12510) and close.
In addition, there is a new discussion on design changes for binary message
support related to the original discussions in 12102 - WebSocket protocol
update time:
1-Sep-2011 ; [WebSocket API] .binaryType ; by Jonas, reply by Hixie
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1182.html
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1199.html
MICROSOFT PROPOSAL:
We do not support the proposed changes. Our implementation experience has not
indicated this requirement. We find that most developers use blobs when there
is a need to consume data as resources addressed by a URI or to store data in
Indexed DB. We have haven't heard of a need to send a text message but then
treat it as a blob. It also seems simple enough to convert text to blobs upon
receipt?
While limiting binaryType updates to onopen and onmessage appears to be more
deterministic, it also implicitly suggests that network operations are then
blocked on the completion of onopen or onmessage. For example, if the goal is
to set the binaryType for the next message, then the next message cannot be
received and the next onMessage event queued until the current onmessage
completes. This may result in performance impacts on implementations that
"pipeline" incoming messages.
