W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: Content-Transfer-Encoding "packet"

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 25 Jul 95 10:35:23 MDT
Message-Id: <9507251735.AA16846@acetes.pa.dec.com>
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.


[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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC