I'd like to go a bit further.
If we decide that the "type" field of "Content-type" is as Greg has
defined it -- that is, it specifies one of 8 or 9 different resource
classes which is required for useful viewing/action on this message, and
has *no* correlation with the encoding used to transmit the message
safely -- then we should go a bit further and consider the case where
several of these types may be required for a single message, as with
various mixed-media formats.
This case is not handled properly by MULTIPART, because the document
does not come in "parts". There is only one part, the document itself.
It contains, in a format-specific encoding (Andrew, Slate, SGML with one
of *my* DTD's, FrameMaker), significant information of several different
"type"s -- say, text + image + audio. That is, the document requires
the resources of the "text" type, the "audio" type, and the "image"
type, to be reasonably comprehended.
Now, this problem can be addressed in various ways:
1) We could simply say that any document of this kind should be typed
as BINARY or APPLICATION or the as-yet-nonexistent UNKNOWN. But this
will lead to uselessness of the "type" field, in being able to say
useful things about the resources needed to read the message, for
messages that use the mixed-media format. This uselessness will cause
people who traffic in those formats to be less than careful about
setting the "type" field appropriately, possibly leading to general
uselessness of that field.
2) We could say that any messages of this form have to be rendered into
MULTIPART and then back again at the receiver's end. This stipulation
seems unrealistic, partly for technical reasons, and partly for
psychological reasons.
3) We allow multiple types to be specified in the "type" field, as in
Content-type: TEXT,AUDIO,IMAGE/ANDREW
There is still only a small set of types which can appear. The main
difference is that we can indicate more than one type. Since the type
is not used for transport encoding purposes, this should have no effect
on that set of issues.
Bill