Hixie, Brian, Jonas, All,
Since Brian sent the original e-mail [1], there has been some Bugzilla
activity and there are now 5 open bugs for Web Sockets. It appears to me
(and please correct me if I'm wrong) the ".binaryType" issue Jonas
raised on the list [2] will not result in any spec changes.
I agree 12510 and 13700 are editorial bugs and as such do not need to
block LC.
Re the other open bugs, Brian suggests: 13104 and 13984 should be
closed; 13777 be addressed "as outlined in the bug"; 13990 (which is now
marked as Resolved Invalid) also be addressed as indicated in the bug.
Ideally, all open bugs should be closed before a LC is published.
However, we can also use an LC now to gather input on the open bugs.
Brian proposes an LC be published now with the spec as is. What do
others think?
-AB
[1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1365.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1182.html
On 9/9/11 6:05 PM, ext Brian Raymor wrote:
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.
