Re: Content-Transfer-Encoding "packet"

>        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"?

No, there will be only one packetized 8bit-clean CTE that will be
required for HTTP/1.1 compliance.  That is why we are having this
discussion now, instead of after a full draft is produced.

>>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.

Folks, I am getting a little tired of this line of response
without any thought behind it.  There is absolutely nothing
platform-specific about preferring 1 read over two reads.
If you have a technical disagreement, fine, but the next person
who cries "platform specific" better damn well include at least
one concrete example wherein the protocol prefers one platform over
another, and not just because of differring TCP implementation bugs.


 ....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)

Received on Monday, 24 July 1995 19:13:17 UTC