As far as additional IMAGE subtypes, I currently need GIF, PICT and
PostScript for my Fax gateway.
The PostScript type already exists -- it is a subtype of text-plus, I
believe.
The type/subtype identifier still bothers me a lot. In the Altanta meeting
I thought that we were moving away from the type/subtype identifier.
I did not get this impression. We moved character set information out of the
type/subtype hierarchy, that's all. I think the hierarchy is still useful and
I don't want to give it up.
If we still keep this type/subtype identifier, can someone provide me a
guideline how one should pick a proper type for a subtype? Postscript is
a very "tricky" subtype. It is text-plus in general sense, but it can be
image (e.g. Encapsulated Postscript is treated as image on NeXT), or it
can be executable (e.g. NeWS.)
PostScript is indeed a tricky case. It is a language for describing images. It
even has a binary form (level II) that does not encode well as text. I could
go either way on PostScript.
This applies to any composite format. DEC's CDA is another good example -- it
has three representational forms, one is the extracted text content, another is
a text dump of the entire content, and the third is pure binary, and it also
can contain plain text data, image data, binary numeric data (essentially
tables akin to spreadsheets), audio, or a mixture of the three.
But rather than scrap a useful mechanism just because there are a few tricky
cases, I'd prefer to keep the mechanism and fit the cases in as best we can.
We could invent a new top-level type that is used to represent things that
are composites, like PostScript, CDA, ODA, and Interleaf. However, I prefer
not to do this, but simply group each of these entities under the type that
it is most likely to be associated with. This is a personal preference; if
others feel that a type for these composite formats is useful, I'm
willing to go along.
Here is another example for consideration. Interleaf (a software publisher
vendor) can store its document in 2 formats: ASCII (7-bit mailable) format
and binary format. Assume that "interleaf" is a registered subtype, should
this vendor provide 2 different type/subtypes: "text-plus/interleaf" and
"application/interleaf"? Or simply only 1 type: "application/interleaf".
Not being an Interleaf user, I don't have strong feelings about this.
Another example is "script" language. In Unix environment, shell script
can be either executed or editable. What type should this document
belong to? To complicate the situation, if the sender's intention of the
script is for execution, but the receiver's implementation is for viewing.
Then there is an interoperability problem. The RFC-XXXX is not clear
how this "type/subtype" should be handled.
This seems to me to be some kind of subtype under application (identification
of the relevant script language and version is going to be tricky...). I don't
see that this one is very difficult to deal with. I don't see what intentions
have to do with it -- the intended use of a script is to be executed, not
viewed. The receiver can, of course, view it (I hope the UA does not execute it
automatically!!!) I can also look at the bits in an image or an audio document,
for that matter, but its intended use is as image or audio or whatever.
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.
Ned