You can continue to come up with all sorts of examples that don't fit
the hierarchy very well. Such examples may even lead us to change the
hierarchy. However, the presence of a hierarchy remains useful -- if I
get something of type image/foo, where I have never heard of foo
before, it is nice to know that it is an image, and that trying to
display it on my VT100 is probably not going to work, no matter how
much software I FTP from archives to deal with the format. And there
are (and will continue to be) lots of subtypes that do fit cleanly
under a single already defined type.
It seems to me that "subtype" is more important than "type". And the
"type" is just a hint. Does it make sense to have "type [ / class]"
where type is a unique identifier (equivalent to the current subtype),
and the class is optional (pretty much equivalent to the current type)?
This is almost a reverse of what is defined in current RFC-XXXX.
I believe that by defining "type/class" may close some holes in RFC-XXXX.
Since RFC-XXXX states that type is mandatory, but subtype is optional.
Given that "Content-Type: IMAGE" is completely legal, but meaningless.
In this case, the UA can only inform the user that there is an image
document. This information is too vague.
If "type [ / class]" is used, the worst case scenario will be
"Content-Type: FOO". From the UI point of view, I would rather
to inform the user that he/she has a document whose type is FOO (unknown
to the UA), displaying it or not will be an optional action for the UA.
At least, this UA provides a little concrete information. When the user
gets "Content-Type: FOO/IMAGE", the UA has more information about the
type FOO and may not display the image on VT100 terminal. This is same
as your example.
Defining Content-Type as "type [ / class]" has another benefit. The
RFC-XXXX compliant UA's can read all the existing RFC-1049 messages
because they are sharing the same meaning of types.
Content-Type: PEM / MESSAGE (type is PEM, class is MESSAGE)
Content-Type: MESSAGE (MESSAGE can be a type without a class)
Content-Type: MUTLIPART (MULTIPART type does not need a class)
Content-Type: POSTSCRIPT / TEXT-PLUS
Content-Type: POSTSCRIPT (compatible with RFC 1049)
Content-Type: INTERLEAF / BINARY (an Interleaf document in binary format)
Content-Type: INTERLEAF (an Interleaf document; let Interleaf determine
if it is in ASCII or binary format)