Excerpts from ext.ietf-822: 17-Sep-91 Re: POINT OF ORDER - multip..
Nathaniel Borenstein(_at_)thu (3186+0)
Knowing that there is "image" embedded somewhere in Andrew mail, for
example -- even knowing WHERE the image data is -- won't help you at all
unless you know about Andrew's idiosyncratic image format.
Idiosyncratic compound document types will have idiosyncratic structure
and idiosyncratic components; its fairly inevitable.
Nathaniel, that's missing the point. The information that we want to
convey in the "type" field of "Content-type" is independent of the
idiosyncratic format. It tells us what kind of resources are necessary
to look at this message, independent of the software needed to
comprehend it. If we know that the message has an important image in
it, we can understand that a VT-100 is an inappropriate display device,
*independent* of knowing what Andrew format may or may not be. Thus
some filtering of messages can be done without understanding the format.
You then say:
I think it [MULTIPART] is the way to go.
Here is where we differ. I feel that people are going to grab some
output file from their FrameMaker or MS-Word or ATK editor that shows up
as an icon in their file browser, and drop it onto their OpenWindows[1]
mailtool, setting the Content-type to "SOMETHING/FRAMEMAKER-TEXT" or
whatever. And as editors become generally powerful, every format is
going to be mixed-media -- thus every document will be. If we want that
SOMETHING to be useful, we have to be able to address mixed-media
documents in it.
In fact, I expect to modify Andrew this fall to both receive and
generate multipart format instead of the idiosyncratic Andrew data
stream -- such translations are generally easy and straightforward
technically, especially since richtext was designed for the kind of
flexibility required. Psychologically, I think that there's a big
motivation to do it if there's the promise of wider interoperability.
I find this kind of scheme to place an unacceptable burden either on the
UA (to understand the particular format, and be able to break it up into
parts, or reconstitute it), or on the editor/document-system (to be able
to create/read what is essentially Internet-mail-message-format).
Because of the behaviour cited above, I tend to think the burden would
be on the UA. I also find it difficult to believe that people will
want/trust this kind of partitioning/reconstitution scheme. Consider
Jim Knowles' reaction to it (I think I'm quoting accurately, if
ignorantly :-):
Excerpts from ext.ietf-822: 17-Sep-91 Re: POINT OF ORDER - multip.. Jim
Knowles(_at_)trident(_dot_)arc(_dot_) (1970)
This could be an option, but I wouldn't want it specified as the default
behaviour.
Finally,
3) We allow multiple types to be specified in the "type" field, as in
Content-type: TEXT,AUDIO,IMAGE/ANDREW
I have a lot of trouble making sense of this proposal. If the format is
Andrew format, this content-type line doesn't tell us where inter-part
boundaries are or how to recognize them. If the boundaries follow some
particular rules of structure, then they might as well be in multipart
format. I don't see what a line like the one you propose would mean, or
how it would be used or useful. -- Nathaniel
It would mean that the format of the message body is "ANDREW", and that
you need text display facilities, image display facilities, and audio
facilities to present the message. But of course, this won't seem
particularly exciting if you aren't convinced that MULTIPART is a fairly
specialized and limited-use type.
Bill
[1] I regret it's even necessary to say this, but: No mention by me of
things like FrameMaker or OpenWindows should be construed indicate a
desire or preference for one commercial product over another. They were
simply mentioned as instances of generic classes of systems.