- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 25 Jul 95 10:35:23 MDT
- To: Roy Fielding <fielding@beach.w3.org>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Hmmm, fixed hex sounds reasonable, but 6 digits is a bit overboard.
Well, I was assuming that 4-byte or 8-byte alignment is a Good Thing
for fast processing, and that we would use CRLF. With 2 bytes taken
up by CRLF, that leaves either 2 hex digits or 6 hex digits.
To quote Gordon Bell and Bill Strecker, "There is only one mistake that
can be made in computer design that is difficult to recover from -- not
having enough address bits for memory addressing and memory
management."[1] That seems to apply to network protocols, too: look
at the problems with TCP sequence number space and window size, and
with NFS request size and file offset size.
4 hex digits *might* be enough, but since (as you've observed several
times) we won't have a chance to fix this once it is widely
implemented, I'd vote for 6 or 8 hex digits, just to be safe.
And why would we need the CRLF if the size is fixed? It does not
improve readability (aside from the first chunk).
I suppose that's open to interpretation. Anyway, if you buy the
argument that 6 hex digits are worth having, and you buy the argument
that the fields should 4-byte aligned, then the CRLF doesn't really
cost anything.
-Jeff
[1] C. G. Bell and W. D. Strecker, "Computer structures: What have we
learned from the PDP-11?", Proc. Third Annual Symposium on Computer
Architecture, Pittsburgh, PA, pp 1-14. January, 1976.
Received on Tuesday, 25 July 1995 10:42:25 UTC