Excerpts from ext.ietf-822: 28-Aug-91 Re: Content Types Ned
Freed(_at_)hmcvax(_dot_)claremo (4488)
Vincent writes:
For terminal-based mail reader, "TEXT" class and "BINARY" class are more
important than "type". But for sophiscated mail reader, the "class" does
not
provide enough information. It is merely a hint. The real information is
provided by "type."
Actually, it's not. The "type"/"sub-type" pair now form a "format"
field, and it is not (always) possible to determine the document class
from the format, and thus determine if your mail-reader can use it.
Given that the "type" field of the `Content-type' header is now used to
establish a format encoding partitioning, so that gateways can decide
what kinds of massaging a particular message needs (by consulting the
"type"), and that the "type"/"sub-type" pair now forms a format
descriptor, how should we pass the actual information about what kind of
document is in the message? Given that a number of modern formats can
contain various kinds of objects?
Would everything break if we included an optional "Msg-Medium" header,
that would identify the type of document being sent from a short list of
document classes, say (off the top of my head)
"text" (character terminals will work, though with perhaps some
degradation),
"image" (bitmapped screens will work, twpsd),
"video" (you need video hardware),
"audio" (you need audio hardware),
"script" (something to be executed),
"unknown" (usually something with Content-type "application/foo"),
"composite" (several different media required)?
Or instead of composite, one could use a list of media as the value.
If `Msg-medium' was included, the UA could check it to see if the
resources specified are outside the scope of the UA, without having to
decode the particular document to find out. Similarly, it could be
passed to mailcap programs for use.
Bill