On Thu, 18 Mar 1993 02:48:25 +0000, Harald Tveit Alvestrand
<harald(_dot_)t(_dot_)alvestrand(_at_)delab(_dot_)sintef(_dot_)no> said:
Harald> Why not define an extendible mechanism for Multipart:
Harald> content-type=multipart/structured; control=first [or last]
Harald> where we then have the semantics that:
Harald> - A body part apart from the control has its normal meaning
Harald> - The control body part has content that is about other parts.
Harald> So, if you cannot parse the control, you can look at
Harald> the other parts, but if you can parse the control, but
Harald> not the other parts, you might as well junk the whole
Harald> thing.
...
Harald> (No, I did not suggest it for structuring Attachments.
Harald> Others should get their fingers burned.....)
Harald, Dave, y'all:
I have been dwelling on this for a few days while sharpening the
Content-Disposition stuff, and I am beginning to becom convinced that
this way may be better, or at least complementary. I originally put
forth content-disposition because it provided a cleaner way to
represent dispositional info than mucking about with the message
structure, and because it gave a good location for other dispositional
info (filename, content caching hints, etc.) which just did not
belong anywhere else. These are all good things, and I still think
they are necessary.
But it is more important, I think, to have a unified view of multipart
files. This is true with PEM, with Mac files, and with structured
documents. I like your proposal, Harald, except that instead of
'first' or 'last' I would use the Content-ID of the organizer.
When handling this sort of thing Content-ID is not really optional.
_so_
How do people feel about this? Amd what is to be done with
Content-Disposition? I still see the need to indicate filename
and cahceing policy on a per-part basis. I'm not so sure about the
'inline' vs 'attachment' vs 'hidden' dispositional types given that
the same could be done with a (very simple) application subtype
for the organizer (what Harald terms the "control") defined in the
same document. Something like:
::::::::::
Content-Type: application/basic-organizer
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="fubar";
cache=never;
Content-ID: <20026_1074_729552014_1(_at_)lorax>
Inline: <20026_1074_729552014_2(_at_)lorax>
Inline: <20026_1074_729552014_3(_at_)lorax>
Attachment: <20026_1074_729552014_4(_at_)lorax>
Attachment: <20026_1074_729552014_5(_at_)lorax>
Attachment: <20026_1074_729552014_6(_at_)lorax>
::::::::::
This way, my fingers won't be burned :)
Anyway, code is always better after it has been scrapped and
redesigned 3 or 4 times :( ++
-Rens
rens(_at_)cs(_dot_)columbia(_dot_)edu