- From: Brian Raymor <Brian.Raymor@microsoft.com>
- Date: Fri, 9 Sep 2011 22:05:42 +0000
- To: "Web Applications Working Group WG (public-webapps@w3.org) (public-webapps@w3.org)" <public-webapps@w3.org>
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.
Received on Friday, 9 September 2011 22:06:19 UTC