I don't think that changing image/postscript to image/postscript-version-foo
will help the PostScript writers' problem a bit. For the case of
PostScript, we will certainly gain experience as to how to create messages
that are interoperable that we might want to document later, but it won't be
necessary to label the new messages any differently, since old postscript
interpreters will presumably read them just fine.
I agree it doesn't help the writer much. I believe it might help
readers. It might help a gateway decide how to deal most reasonably
with an old format vs a new one.
My argument is not that labelling is a bad idea. I think it is a great idea,
and I strong encourage all applications that produce PostScript to use the
appropriate document structuring conventions for their work. It makes all our
lives easier when applications do this.
Adobe certainly agrees with this attitude, since they've specified and endorsed
document structuring conventions from the beginning.
What I fail to see is why a second form of labelling is needed. PostScript has
a very powerful and complete labelling facility already. It is much more
powerful than anything we could put on the content-type line. Worse, the
PostScript standards specifically and categorically recommend AGAINST the
labelling of the language level:
"It is poor practice to use the [language level label] when an
[extensions label] would have been able to encompass the operators
used in the document."
-- PostScript Language Reference Manual, Second Edition
Thus, even if you can convince me that labelling PostScript on the Content-Type
line is a good idea (and you're a long way from convincing me of this), you'll
also have to convince me that labelling the level is a good idea. It seems
quite clear that the designers of the language didn't think it was a good idea!
This is the second time I've made this point on this list, by the way. Are you
sure you've really read the archives of this discussion?
That's the whole reason for labelling
body parts, anyway. I mean, if we take the arguments being made to the
logical conclusion, why label body parts at all? I certainly can tell
a GIF from a PS from a Rich Text, just by looking. What's the
content-type for, anyway?
This is twaddle. You cannot tell the difference between all forms of body parts
by automated examination. You cannot even distinguish even a tiny fraction of
them in this way.
I am not going to bother arguing this further unless I have to. It is a totally
preposterous assertion. If you like I'll present some examples and ask you what
format they're in -- I doubt if you can even spot PostScript if it is disguised
well enough!
If a few years down the road I send out a document written in
PostScript-1998 and (mis-)label it application/postscript, then the
difference is that the recipient gets an error from his PostScript
interpreter that says it doesn't support 3-D animation, instead of getting
an error from his mail reader that says it doesn't understand content-type
application/postscript-1998. This may be less than ideal, but does it
create a real problem? (Of course, it might cause the mail reader to use
the wrong part of a multipart/alternative, but a good mail reader would
allow the user to view any part of a multipart/alternative anyway.)
You have to believe that content-type is going to be used for more
than mail, by the way -- certainly WAIS needs content-types, Internet
Anonymous FTP Archives will want to indicate files by their type, as
are a number of other network information services. Unless you think
there should be separate IANA registration for WAIS content-type vs.
IAFA content-type vs. MIME content-type?
I would also throw in the ISO OID scheme for registering types of objects.
There are probably others as well.
It would be nice if we could use a general typing scheme somebody else came up
with. I'm always in favor of avoiding work someone else has done.
Unfortunately, as far as I know the OID stuff is the only other one that's far
enough along to have used, and there are sound reasons for not using it (mostly
political reasons, I grant, but nevertheless there are good reasons).
I certainly agree that we're making future work for ourselves by having more
than one mechanism. Is someone else would use the same namespace as we're using
that would be fine. But I don't seriously expect them to, since their
requirements are probably different, and I don't think it is very likely others
will decompose the space into the top-level types we've picked.
The end result is by doing this ourselves we're probably making it harder to
reconcile in the future. That's what happens when the pressure to reach closure
is strong, and we have to have something now, rather (probably for years) for
all the interested parties to do something that's collectively coherent.
Ned