Subject: Re: [hybi] Serf support for BWTP

From: Ian Hickson <[email-masked]>
Date: Sun, 31 Jan 2010 08:34:29 +0000 (UTC)

On Fri, 18 Dec 2009, Justin Erenkrantz wrote:
> 
> If ya'll haven't followed the Twitter conversation between me and Hixie 
> over the last few days, I've pretty much come to the same conclusions 
> regarding "Web Sockets" RFC that Greg Wilkins did much earlier.  (Kudos 
> to Greg!)  I guess that Hixie has tried to write his RFC drafts in a way 
> that stresses one particular way of writing a client - but for a pure 
> async client library like Serf, the description in the RFC is pretty 
> impenetrable...and, in my mind, not very helpful when it comes to 
> writing an independent implementation.

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. While it is still very specific about normative conformance 
criteria, rather than being an abstract description of an idealised 
protocol [1], it should at least be more readable now. If you have any 
specific feedback about specific sections that need changing, it would be 
great if you could send it to this list.

(I'm going through feedback received in the past month now, and have 
reached feedback sent up to mid-December; if you send feedback after then, 
I should reply to it soon.)

[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. The HTTP specs, the URI specs, HTML4, and CSS1 are the four 
examples I'm most familiar with that demostrate this most clearly.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 01 Feb 2010 09:09:21 +1100

Ian Hickson wrote:

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

> 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

---

From: Justin Erenkrantz <[email-masked]>
Date: Sun, 31 Jan 2010 21:23:49 -0800

> examples I'm most familiar with that demostrate this most clearly.

Like Greg, I will just note that I strongly disagree with most of the above.

There is simply no way that I could translate the current draft to an
implementation without introducing serious bugs, flaws, or
interoperability issues.

As a concrete example, let's look at Section 5.3:

---
5.3.  Data framing

   The server must run through the following steps to process the bytes
   sent by the client:

   1.  _Frame_: Read a byte from the client.  Let /type/ be that byte.

   2.  If /type/ is not a 0x00 byte, then the server may disconnect from
       the client.

   3.  If the most significant bit of /type/ is not set, then run the
       following steps:

   ....
--

If I read this, what is the rationale behind the if clause of step 3?
We're guaranteed that /type/ is 0x00 at this point because the server
has just been told it's okay to disconnect in step 2.  But, if I step
back and think, I think that it is step 2 that is bogus because, in
other parts of the draft, you mention other frame types.  In fact, the
data framing rules for the client are different than the server.

Oops.

The confusion that was attempted to be prevented by this radically
different editorial style is exactly what was created.  In my mind,
there's a reason that most drafts are written in the same style - they
actually reduce ambiguities rather than introduce them.  -- justin