[Top] [All Lists]

Re: yet another way to indicate related MIME body parts

1993-10-25 18:43:52
Actually, I'm not sure I understand the difference between having 
a start parameter that can indicate any body part, and always 
having "start" be the first body part (as in header-set).  In 
either case the mail reader has to look at the headers for that 
body part before processing the mail. 

(but either one of these should be easier to deal with than 

I disagree; multipart/foo is certainly easier for metamail than any of
these proposals, because you can do the top-level switching (decide what
application to run) while processing the enclosing multipart.  This is 
a big win for metamail, which wants to be able to do everything in one
pipe-like pass through a MIME message.   This is not at all possible
with header-set.  It is closer to possible with multipart/related,
though it would be better if the actual content-type were visible at the
enclosing level. 

The implementation I have in mind is as follows:  The mail reader simply
extracts each of the components on-the-fly and stores them in appropriately
named files (remembering which one is the start body part).  Then the start
body part is evaluated.  

You have to store the messages anyway to allow arbitrary cross-referencing.

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.

If the "start" object can't be displayed, sometimes it makes sense to 
have the mail reader present the individual objects, sometimes not.  
If the sender wants the fallback behavior he should use 
multipart/alternative for the start object. 

Geez, if we're going to have a generic thing like multipart/related, it
should at least be able to specify this sort of behavior.  How about a
parameter, something like 

multipart/related; displaypiecesifmainunrecognized={yes,no} 

Seems like this kind of functionality is basic enough to warrant a
parameter, though probably one with a better name... :-)  -- Nathaniel 

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.