Re: Content-Transfer-Encoding "packet"

        I very much prefer the design Dan originally posted

                Content-Transfer-Encoding: packet

                15
                fifteen bytes

        where the  1 5 CR LF  indicate  "read exactly fifteen octets"
(the example happening to have a CR and LF at the end of the printable
characters),  at which point the receiver (either client or server)
looks for another ASCII byte count,  always terminated by CR/LF.

        I do not see the problem with using ASCII numerals terminated
by CR/LF.   Though I expect quite a few real transfers using such a
method to be effectively unreadable,  it's likely that the "packets"
will often be large enough to hold the entire "file",  in which case
the transfers will again be humanly readable.   I expect this latter
to happen frequently in a development scenario,  and keeping the
protocol "eyeballable" to developers only helps.   Simplify life
for the developers and you get a more solid product and get it
to market quicker.   CPU time is less expensive than man hours.

>The last time I posted my notes regarding the format, I referred
>to it as being basically the same as that proposed by Dan Connolly
>way back in<9409271503.AA27488@austin2.hal.com> on www-talk.
>I'd like to change that now, before we get products out on the
>street that use the sucker.

        I disagree.   I see no justification for not using it.

>Also, I've been playing around with various formats and have
>found that the optimum for most transfers uses a simple one-byte
>prefix to encode the length of each packet, with a zero byte
>indicating end-of-packets.

        I like this idea;  just pick another name.   I hope that
Dan's "packet" CTE will see the light of day  (even though he may
himself have abandonned it by now),  and maybe reserving that name
will help.   Maybe call yours  "pack8bit"?

        Another variation might be to call all of them "packet",
and require a parameter for the prefix:  8bit, 16bit, or ASCII.

>In other words, the result looks like a normal message, with
>the Content-Length computed by the unpacketizer.  In actuality,
>it is often faster to read packet-size + 1 bytes, slurping in
>the next packet-size as part of the prior packet read.

        That's an optimization that works on some systems;
not on others.   Keep the protocol free from platform specifics.

> ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
>                      Visiting Scholar, MIT/LCS + World-Wide Web Consortium
>                      (fielding@w3.org)                (fielding@ics.uci.edu)

        Thanks for the contribution!

--
Rick Troth <troth@ua1vm.ua.edu>, Houston, Texas, USA
http://ua1vm.ua.edu/~troth/

Received on Monday, 24 July 1995 15:39:58 UTC