On Mon, 24 Jun 1991 21:06:25 -0400 (EDT), John C Klensin wrote:
As the partial keeper of the "what happens when something floats around
in an 8 bit world and is 'fixed' to 7-bit land" materials, I think there
is a fairly strong case to be made for keeping the "encode the whole
message" option (which I have referred to elsewhere as "encapsulating"
it, following what I understand of the X.400 terminology) available.
The more diddling (e.g., part-parsing) with the message body gateways
have to do, the more likely a few of them are to get it wrong, which
makes finely-tuned delegation of UA responsibilities much more
In other words, please don't change this.
If this is what is adopted by the IETF, I fear that I will have no choice but
to consider it a SHOW STOPPER and seek some other standard for multi-part and
typed mail. This is a fatal flaw that would return me to RFC-1154.
The minor convenience that it buys 8/7 gateways is overshadowed by the MAJOR
cost inflicted upon every UA. It will force a UA to decode and copy an
encoded high level segment as part of the process of parsing the body. The UA
must also choose whether to keep the decoded copy around (a potentially huge
storage cost) or to re-decode the upper level every time it needs a segment
from a lower level (a potentially huge processing cost).
With encodings only at the lowest level, it is possible for a UA to keep an
offset pointer to the origin of a message segment and a size. No decoding or
copying is necessary until the segment is actually needed. What's more, there
is even some chance of implementing this on smaller machines.
I understand the problem because I've just finished writing the code to parse
these bodies and determined that the only sane thing to do was assume that
only the lowest level could have an encoding (actually, that only the lowest
level could have a BASE64 or QUOTED-PRINTABLE encoding -- the others don't
Please think for a minute what you are advocating, and what the actual result
is going to look like in a message. What you advocate is no different than
the "wretched solution" that was quashed at the St. Louis IETF. It was
quashed for an excellent reason. It sounds nice and pretty on paper, but in
fact it has a horrible cost.
I feel too that by allowing gateways to wrap an encoding without understanding
what it is encoding, you are opening a Pandora's box. I can imagine a message
going through a few hops of stupid gateways ending up with a BASE64 of a
QUOTED-PRINTABLE of a BASE64 of a BINARY segment because each gateway put its
own wrapping around the mess rather than understanding what the hell it was
-- Mark --