ietf-822
[Top] [All Lists]

Re: Internet Message Bodies DRAFT revisions

1991-06-25 04:39:00
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.

Whoa. Let's discuss this some first...

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

Frankly, this is a fairly compelling argument. Even if the costs were roughly
equal, I expect to see lots more 8-bit UAs than 8/7 MTAs. Therefore the cost
associated with unwrapping an entire message is much more important than the
cost associated with what a gateway does or doesn't have to do.

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.

Damn, you caught me ;-) This is exactly how my gateway code works. And yes,
you're right, it does not handle nested encodings in a manner that would apply 
to something that's not a gateway. I undo the nestings during the enqueue 
operation. Of course, I'm talking about a gateway and I can get away with such 
things... (When you're headed off into Message-Router-X.400-land, it all
reads like a fairy tale anyway...)

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

I did not notice the problem because I was also involved in handling all
sorts of other encodings in my gateway. This point gets lost in the shuffle
if you're also trying to support RFC1154 and RFC934 encodings (and worse,
combinations of all three) plus UUENCODE, and a bunch of other stuff. The
result is that I've overlooked the implications and limitations imposed on
simpler software that doesn't care about these extras.

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.

Caught again. You're absolutely right. I cannot believe that I forgot the
evening I spent worrying at this bone in St. Louis, but there you are -- I did.

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

Well, they'd be awfully stupid if this did happen, but the point is
well taken. I could see such things occurring if, for example, some
boundary marker ended up containing some funky character.

I think Mark has encapsulated all my misgivings nicely here (including the ones 
I'd blanked out of my mind). I'm pretty sure that I agree with him up and down 
the line. The next question, then, is how hard is it to encode a multipart
message by scanning through the message and doing it part by part. I don't 
think it is really that hard to do. We should probably cut a couple of test 
implementation to see. Anyone want to give it a try besides me?

Thanks Mark for keeping me honest in this.

                                        Ned