ietf-822
[Top] [All Lists]

Re: yet another way to indicate related MIME body parts

1993-10-25 18:52:31
Excerpts from mail: 25-Oct-93 Re: yet another way to indi.. Keith
Moore(_at_)cs(_dot_)utk(_dot_)edu (2639) 

If you didn't want to wire this into metamail, you could just use metamail's 
normal program calling mechanism to handle the multipart/reference type; the 
program called could then call metamail recursively to process the "start" 
body part. 

The problem is the multiplying utilization of the temporary disk.  Most
mail readers write a temp file to call metamail.  To the extent that
metamail can do things in pipes from there, it is a big win; in cases
like this, it is more or less unavoidable to double that disk usage by
then copying each part to a separate file.  If the multipart/reference
is handled by a separate intermediate program instead of directly by
metamail, this could effectively TRIPLE the temporary disk usage.  (The
"could" is because when things are optimal, some of this can be done
with pipelines instead of temp files.)   No big deal, assuming you clean
it up, until you start getting messages that are bigger than a third the
size of the free space on your disk. 

Maybe I'm compulsive to think about such things, but I've recently been
sending messages around that are 1 or 2 megabytes in size.  Tripling the
temp space required is definitely suboptimal..... 

Okay, but that makes for two levels of fallback, since you can still have a 
multipart/alternative as the "start" component.  And having a boolean option 
requires the mail reader to display all of the components, not just the ones 
that make sense.  So it seems like a cleaner implementation to use the 
multipart/alternative containing a multipart/external-body (or possibly 
multiple external body parts) to indicate which pieces should be displayed 
for fallback purposes. 

Yes, my only fear is that this puts too much of the burden on the sender
to be realistic; pragmatically, the recipients are going to have to cope
with stuff that wasn't so nicely laid out, so it would be nice to at
least well-define the default semantics for the individual pieces. 

Actually, this suggests an idea:  The spec could say that if you don't
recognize the "start" part, you don't show anything.  This would
effectively FORCE composing software to use multipart/alternative if it
wants anything useful to happen for recipients who don't understand the
"ideal" semantics.