Bill Janssen writes:
... 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.
...
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.
This (APPLICATION) seems like the right header to me, at least for Andrew
and Slate. It says (to me), take the following body part and hand it to
the application named in /sub-type. The application will take care of
splitting out the text, audio and image content. I don't see the
Content-type as useless at all. It names the type of the most vital
resource needed to present the body part, i.e., the application.
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.
This could be an option, but I wouldn't want it specified as the default
behaviour.
3) We allow multiple types to be specified in the "type" field, as in
Content-type: TEXT,AUDIO,IMAGE/ANDREW
This I don't like. It seems to put an extra burden on the parser just
to handle this case. Are you expecting some application other than
Andrew to handle this body part? Then why not Application/Andrew_handler?
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.
I still don't see the advantage. Any multi-media application should take
care of checking out the necessary resources. What are you buying here?
I really would like to simplify the possible states resulting from
top-level parsing of the Content-type line.
Jim