Excerpts from internet.ietf-822: 12-Nov-91 Re: audio, checksums, and t..
jknowles(_at_)binky(_dot_)arc(_dot_)nasa(_dot_) (1971)
B. 3: /alternative - someone must have a good reason for this to be
mandatory. This is not a SHOW-STOPPER, but I'd like to hear it.
OK, here's the rationale:
Imagine that you're a company that wants to sell a really fancy
multimedia mail product. (Call it "Andrew-done-right" or something
equally inflammatory, if you like.) You've designed a fancy interactive
display-oriented multimedia language in which to represent your
messages. (Call it "Display-PostScript-Done-Right" to offend a
different set of people.) Now you want to send around mail in this
format.
In the past, such products were (in my opinion) essentially killed by
the lack of interoperability. You could only send mail to other users
of the same system. So most users ended up sending around plain text.
(Ask any Andrew, Slate, or NextMail user, and you'll find out that the
vast majority of their mail is plain text for this reason.) But now we
have the beginnings of standard data formats. So this forces a horrible
choice on the developers of the new amazingly-great system: either use
a proprietary format and suffer the same problems as in the past, or
limit yourself to the less-powerful but more-ubiquitous capabilities
that are defined by the standard (e.g. rich text, still images, etc.).
Enter multipart/alternative. If you can count on people having the
capability to handle this, there's a GREAT new option for such mail
readers. (In fact, it's the option I've already begun to implement for
Andrew.) That is to represent the data in TWO formats -- first, the
idiosyncratic but powerful one, and second the standard but perhaps
boring one. You end up with something like this, in the Andrew case:
Content-type: multipart/alternative; boundary=foobar
--foobar
Content-type: application/andrew
...andrew data goes here, including all sorts of fancy embedded objects...
--foobar
Content-type: multipart/mixed; boundary=crumbcake
--crumbcake
Content-type: text/richtext
...some rich text goes here...
--crumbcake
Content-type: image/gif
... Andrew objects that have imaging capability are translated to a
common image format, possibly losing interactivity, animation, etc., but
at least preserving the basic picture...
--crumbcake
Content-type: text/richtext
...rich text continues, surrounding the objects....
--crumbcake
Content-type: application/andrew-inset
...untranslatable andrew objects will be marked as such, but leave the
rest of the message comprehensible to other mail readers...
--crumbcake--
--foobar--
I believe this is an excellent way to implement advanced mailers in a
standards-compatible way. Mail from one user of an advanced system to
another user of the same system will preserve the complete semantics of
the message at the high level by choosing the first of the
multipart/alternative parts. If the mail is received by a user of a
different system, the second part will be chosen, and a big chunk of the
semantics will be preserved, as will basic readability. The KEY to
making this scheme work, however, is the assumption that all
standards-compliant mail readers will understand the
multipart/alternative semantics and only show the user the second
version if the first one is not in a recognized format.
Does this make the rationale clearer here? The reason I want it to be
mandatory is that the whole point is to facilitate "graceful
degradation" from the world's fanciest mail reader to other
standards-compliant ones. If it isn't mandatory, I don't think it can
fly at all -- the user will still have to explicitly know whether or not
a recipient uses his high-end mail reader before he feels safe sending
the fanciest forms of mail. -- Nathaniel