Re: [hybi] Serf support for BWTP

[Greg Wilkins <[e-mail]>]

Ian Hickson wrote:

> I've tried to address some of this feedback in the spec, in particular
> rewriting some sections to be more straight-forward about what needs
> implementing.


Ian,

you have indeed reacted to this feedback and improved sections of the
document.   Section 1.2 has the ABNF form of the framing and is a very
welcome addition.  Thanks.


> [1] I'm convinced, based on experience with a number of other
> specifications for Web standards, that the abstract style leads to
> significantly more implementation bugs and interoperability problems than
> the more imperative style the spec currently uses. I'm not convinced it's
> possible to sanely define all the error handling rules needed to get good
> interop on the Web without having explicit sections for clients and
> servers.


I believe that the algorithmic specifications that remain in the document
actually introduce a significant lack of clarity and ambiguity.

The algorithms if implemented as described, would have measurable
external artefacts.

For example, when section 4.1 - 5 says "send the following bytes to the
remote server 47 45 54 20", do I actually have to send them?  Or can
I buffer them with the following bytes. Would a server be justified in
rejecting the handshake (on security grounds?) because those bytes
are not sent in their own TCP/IP packet?        The specification relies
on assumed common practise and understanding that "send" can actually
mean "buffer and flush sometime later, perhaps aggregated with previous
and/or following sends".   Relying on assumed interpretation is not
a good thing for a spec.


Another issue is that only the client-side sentinel framing algorithm
says:
              "If the client
              runs out of resources for buffering the incoming data, or
              hits an artificial resource limit intended to avoid
              resource starvation, then it must fail the Web Socket
              connection and abort these steps."

Does this mean that the serverside or client length framing cannot
reject a connection based on resource limits?  Must this sentence be
put into every step of the algorithm that says "read a byte"?

Surely it would be better just to express this error handling
non-algorithmicaly?  In which case your point about "sanely define
all the error handling rules" does not stand up well to this example.

There are numerous error handling cases not handled in your
algorithms:

 + int or long  overflow if a very very large number is sent as a
   frame length.

 + what to do if a client sends for the length 0x80, 0x80, 0x80, ....
   do we read and multiply forever or can we conclude that somebody
   is messing with us?

In the client framing, we are allowed to abort "If no byte could be
read because the Web Socket connection is closed".    But the server
is not granted that permission.   What can we do if a read times out
but the websocket is not closed?


In fact I can see no sanely defined error handling in these
algorithms at all.  Can you point me to one example in section 4.2 or 5.3
that is both complete, un-reliant on common sense interpretation and
could not be better and less verbosely defined in imperative style?


regards