Subject: [hybi] Last Call Questions: Frame sizes, deflate, SRV records; Use of SHA-1

From: "Bob Gezelter" <[email-masked]>
Date: Fri, 05 Aug 2011 08:40:16 -0700

It would be useful if the WebSocket protocol contained a mechanism to
declare (and verify) the maximum sizes of the frames in a channel. It
should be noted that capping frame size is a function of all of the
parties in the protocol path, not just the protocol endpoints. As such,
it needs to be specified as the maximum that each link in the chain
(including proxies or other intermediaries that have visibility into the
WebSocket protocol) are willing and able to accommodate. 

That said, the large frame sizes are, IMHO, almost an irrelevancy. They
do not significantly contribute to the efficiency of the channel, and
increase latency for other data. The per-frame overhead is less than 16
bytes. For significant frame sizes (e.g., tens of Kbytes), frame
overhead is simply not statistically significant. There is already no
correlation between the packet size of the underlying network, and the
frame size. The WebSocket protocol is defined to run with an underlying
protocol that already provides an extremely low-error, sequence assured,
bi-directional communications path (Note: I state "low error", as the
TCP and IP checksums are known to be relatively weak).

I have already noted that "deflate" is of limited utility when applied
to already masked data, thus I support removing deflate from the
WebSocket protocol. IMHO, compression is properly a part of multiplexing
scheme, which I believe will be needed. Compression schemes work well
with correlated data, which would correspond to the individual
multiplexed sub-channels.

Identification of service endpoints is one of the weaker areas of the
Internet ecosystem. Requiring clients to make appropriate queries, and
leaving server managers the options and flexibility to utilize those
options is a low-impact choice in line with the "Generate strictly;
accept liberally" gestalt that has often been successful in the Internet
space. I see no great impact on requiring clients to check for relevant
SRV records, and thus support the inclusion of SRV records resolution in
the WebSocket protocol.

Finally, on the subject of SHA-1, I have no objections. I am not sure
that I with the reasoning behind the choice. My lack of agreement is
that in today's environment, I am not sure that the process is a gain.
On the subject of 16-bit implementations, speaking as a 30+ year systems
programmer with corresponding expertise in both high-level and
assembler-level languages, I frankly to not see an issue for all but the
smallest of embedded micro-controllers, with the exception of power
depletion on portable, wireless devices. If anyone feels that the
implementation of SHA-1 on less than a 32-bit processor is a significant
problem, I will invite them to contact me off list.

I previously discussed some issues relating to the above points a blog
article entitled ""The WebSocket Protocol: Past Travails Are To Be
Avoided" (see http://rlgsc.com/r/20110323.html).

- Bob Gezelter, http://www.rlgsc.com