Are there additional "Fail the WebSocket Connection" cases from the protocol specification that should surface in an error event?

The current client-related list includes:
 
 
4.2.  Base Framing Protocol
 
  RSV1, RSV2, RSV3:  1 bit each
 
      MUST be 0 unless an extension is negotiated which defines meanings
      for non-zero values.  If a nonzero value is received and none of
      the negotiated extensions defines the meaning of such a nonzero
      value, the receiving endpoint MUST _Fail the WebSocket
      Connection_.
 
   Opcode:  4 bits
 
      Defines the interpretation of the payload data.  If an unknown
      opcode is received, the receiving endpoint MUST _Fail the
      WebSocket Connection_. 

5.1.  Client Requirements
 
  1.  The components of the WebSocket URI passed into this algorithm
       (/host/, /port/, /resource name/ and /secure/ flag) MUST be valid
       according to the specification of WebSocket URIs specified in
       Section 3.  If any of the components are invalid, the client MUST
       _Fail the WebSocket Connection_ and abort these steps.
 
   4.  If the connection could not be opened, either because a direct
       connection failed or because any proxy used returned an error,
       then the client MUST _Fail the WebSocket Connection_ and abort
       the connection attempt.
 
   5.  If /secure/ is true, the client MUST perform a TLS handshake over
       the connection after opening the connection and before sending
       the handshake data [RFC2818].  If this fails (e.g. the server's
       certificate could not be verified), then the client MUST _Fail
       the WebSocket Connection_ and abort the connection.
 
Server Responses:
 
   2.  If the response lacks an "Upgrade" header or the "Upgrade" header
       contains a value that is not an ASCII case-insensitive match for
       the value "websocket", the client MUST _Fail the WebSocket
       Connection _.
 
   3.  If the response lacks a "Connection" header or the "Connection"
       header contains a value that is not an ASCII case-insensitive
       match for the value "Upgrade", the client MUST _Fail the
       WebSocket Connection_.
 
   4.  If the response lacks a "Sec-WebSocket-Accept" header or the
       "Sec-WebSocket-Accept" contains a value other than the base64-
       encoded SHA-1 of the concatenation of the "Sec-WebSocket-Key" (as
       a string, not base64-decoded) with the string "258EAFA5-E914-
       47DA-95CA-C5AB0DC85B11", but ignoring any leading and trailing
       whitespace, the client MUST _Fail the WebSocket Connection_
 
   5.  If the response includes a "Sec-WebSocket-Extensions" header, and
       this header indicates the use of an extension that was not
       present in the client' handshake (the server has indicated an
       extension not requested by the client), the client MUST _Fail the
       WebSocket Connection_.  (The parsing of this header to determine
       which extensions are requested is discussed in Section 9.1.)
 
 
   If the server's response does not conform to the requirements for the
   server's handshake as defined in this section and in Section 5.2.2,
   the client MUST _Fail the WebSocket Connection_.
 

7.2.1.  Client-Initiated Closure
 
   Certain algorithms, namely during the opening handshake, require the
   client to _Fail the WebSocket Connection_.  To do so, the client MUST
   _Fail the WebSocket Connection_ as defined in Section 7.1.7.
 
   If at any point the underlying transport layer connection is
   unexpectedly lost, the client MUST _Fail the WebSocket Connection_.
 
   Except as indicated above or as specified by the application layer
   (e.g. a script using the WebSocket API), clients SHOULD NOT close the
   connection.
 
8.1.  Handling Errors in UTF-8 Encoded Data
 
   When an endpoint is to interpret a byte stream as UTF-8 but finds
   that the byte stream is not in fact a valid UTF-8 stream, that
   endpoint MUST _Fail the WebSocket Connection_.
 
9.1.  Negotiating Extensions
 
   A client requests extensions by including a "Sec-WebSocket-
   Extensions" header, which follows the normal rules for HTTP headers
   (see [RFC2616] section 4.2) and the value of the header is defined by
   the following ABNF.  Note that unlike other section of the document
   this section is using ABNF syntax/rules from [RFC2616].  If a value
   is received by either the client or the server during negotiation
   that does not conform to the ABNF below, the recipient of such
   malformed data MUST immediately _Fail the WebSocket Connection_.

Assuming you mean the references to "fail the WebSocket connection", all those references are of things that happen on the protocol side, I believe. I don't really know how we could do anything in the API spec here. I recommend bringing this up with the hybi group.

We're basically requesting minor editorial changes to help clarify the set of errors and how they're handled:

1. It would be helpful to organize the current set of "fail the websocket connection" (error) cases into one section for easier reference. Currently, the cases are scattered through the text.

2. Be more specific about whether these cases trigger onError since "fail the websocket connection" in the protocol draft indicates that onError behavior is a MAY:


   Certain algorithms and specifications require an endpoint to _Fail
   the WebSocket Connection_.  To do so, the client MUST _Close the
   WebSocket Connection_, and MAY report the problem to the user (which
   would be especially useful for developers) in an appropriate manner.

3. What is the behavior for the other "fail the websocket connection cases related to the client in the protocol draft? For example, if a client receives an invalid UTF-8 byte stream and "fails the websocket connection" as required, does this also trigger onError?