Re: [hybi] WS ABNF

[Dave Cridland <[e-mail]>]

On Mon Feb 15 01:12:53 2010, Thomson, Martin wrote:
>      frame         = text-frame / binary-frame
>      binary-frame  = %x80 length *%x00-FF
>      length        = %x00 / %x01-7f / ( %x81-FF *%x80-FF %x00-7F )
> 
> This is a canonical length encoding in that it doesn't allow for  
> leading zeroes.

Am I alone in seeing two design errors here?

Firstly, I see no benefit in having two different framing types. I do  
see a marginal benefit in having multiple frame types, but the idea  
of distinct framing just strikes me as a bad idea, and prone to  
error. I think the correct design decision here is that "bytes is  
bytes", and to the wire, all frames are binary and octet counted. I'm  
not against an end marker, incidentally, although I'm not convinced  
it's needed except in early stages of implementation.

Secondly, is that really a bespoke new method for integer  
representation on the wire? What is the overriding benefit over a  
network byte order 32-bit integer? I see that it can be 1-N octets,  
and therefore will typically save 1-3 octets - I'm assuming we're not  
expecting to ship more than 256M in a frame, where the trade off is.

But the chances of this making a measurable difference are very slim,  
whereas the perils of decoding a new integer representation seem  
extraordinarily high, especially given that it's a nicely unbounded  
integer. IMAP implementations used to have enough trouble when asked  
to allocate 4G for a literal, after all, but at least I'm unaware of  
them having decoding difficulty. OTOH, with 5 octets, I can now setup  
a frame length of 32G, and I can't see anything suggesting that this  
is even a bad idea, let alone illegal protocol.

I have other comments - I'm bewildered that a server responding with  
"HTTP/1.1 101 Web Socket Protocol Handshake." will fail to interop  
with compliant clients, for instance - but I'm intending to leave  
these for a later mail - just be warned these are coming.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade