The specification should say what happens when WebSocket.postMessage(data) is called where data is not structurally correct UTF-16 -- lone surrogates, backwards surrogates, and any similar structural errors I might have forgotten. The IETF protocol specification implicitly assumes the data can be encoded as UTF-8 when this may not be the case. I mentioned similar issues in #whatwg recently for DOM APIs in general[0], possibly to be handled by WebIDL. Since this instance of that problem explicitly requires interpretation of a bogus DOMString and can't be described as storing a sequence of opaque 16-bit numbers for later retrieval, I think it's worth raising this concern specially, and I would like precise behavior specified before this proceeds to a finalized state.
Jeff 0. http://krijnhoetmer.nl/irc-logs/whatwg/20090530#l-236
