Re: Content-Transfer-Encoding "packet"

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

        4 things:  1)  I do try to put some thought behind a response
before pressing the SEND key.   It is unfortunate that I *consistently*
remember/realize/recognize more pieces *after* pressing SEND for which
I find I have to follow-up.   Thus,  I remembered my real objection
after pressing SEND,  *and* realized that I really LIKE your proposal.

        2)  it is immensely convenient that MIME is "plain text".
It is unfortunate (but perhaps correctable) that this characteristic
is not documented, supported, and exploited.   CTE packet (as you've
proposed) would encourage yet more MIME streams that are valid MIME
and yet NOT "plain text".   Although I like your proposed mechanism
for CTE packet,  I do NOT like the idea of more non-plaintext
cluttering up MIME.   Would that the trend would reverse itself.

        If someone could propose a "packet" content transfer encoding
that fit well with a "MIME should be plain text" objective,  I'd very
much like to see it.   Since I cannot think of one  (Dan's was good),
I'll accept yours if the rest of the world does,  but I will ask for
some additional wording.   (see below)

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

        3)  There's nothing broken in the TCP stack I'm using.
But I'm not reading directly from TCP.   The TCP stream is being
fed to another stage,  another process,  in the pipeline of my HTTPD.
In this context,  I simply don't have a read(,,size) construct available.
To that extent,  "reading one byte beyond"  is a platform-specific
optimization.   THIS DOES NOT MAKE YOUR PROPOSAL A SHOW STOPPER,
it just means that I won't be able to do it as efficiently as others.
The *optimization* you recommend is what's platform specific,
not the CTE itself.

        Really,  this has nothing directly to do with the platform (VM)
but with the VHLL (REXX) and its supporting tools (CMS Pipelines).
I'm getting a lot of efficiency where I can hand-off the byte counting
to system level routines.   If the whole thing is plain text,  that
makes my work a complete cake walk.   Where things are binary,
I can still get it done,  it's just not as elegant.

        4)  I suggest (for the sake of argument) that we recommend
CTE packet explicitly for on-the-wire transfer and  INCLUDE WORDING
that as it is taken off-the-wire the CTE packet should be immediately
processed and removed.   Other than that,  this is a good idea.
I regret that I didn't recognize my pleasure in it at first,  but I
think I've outlined the reasons why it struck me wrong initially.

        Using just one byte clearly avoids the network byte order
problem.   Using a  "zero means end"  signal works just fine.
Excellent proposal,  Roy.

        So in summary:  I'd like to keep off-the-wire MIME in "plain
text" (ie: with local canonicalizations and all printable characters)
form whenever possible.   I'm willing to accept on-the-wire MIME in
"binary" forms if we can be clear about the difference,  can explain
the canonicalization issue,  and can encourage the use of the plain text
forms where feasible.

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

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

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