RfC: Is Web Sockets API ready for LC publication? [Was: Re: [websockets] Getting WebSockets API to Last Call]

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.
>
>
>
>
>
>
>
>

Received on Wednesday, 14 September 2011 16:21:52 UTC