ietf-822
[Top] [All Lists]

Re: yet another way to indicate related MIME body parts

1993-10-25 17:36:03
Excerpts from mail: 25-Oct-93 Re: yet another way to indi.. Keith
Moore(_at_)cs(_dot_)utk(_dot_)edu (2631) 

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 multipart/foo) 

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. 

Actually, the more I think about it, the more I realize that "start"
doesn't buy me much.  What I really want in the outer level is the
content-type of the "main" inner piece, but I realize it would be a poor
idea to include this information twice (because of the opportunity for
inconsistency).  So I guess I'm out of luck -- NONE of these proposals
really permits the one-pass implementation that metamail tries to have. 
(I say "tries" because multipart/alternative really broke this a long
time ago, at the cost of considerable complication in the metamail
code...)  Given this, I probably still prefer multipart/foo overall! 

At any rate, I guess I'd agree that you might as well make the first
part the "main" one and get rid of "start". 

After seeing the way multipart/alternative mucked up the code, I am
*very* unlikely ever to implement this kind of construct INSIDE
metamail; that means I'd end up with a separate handler program for
multipart/related.   That's not the end of the world, of course, and
would probably have been a smarter (though less efficient) way for me to
have handled multipart/alternative in the first place.  Live and learn. 

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