One historical note worth remembering:
The Content-type header, as defined by MIME, is a refinement and major
extension of the Content-type header as defined by RFC 1049. The 1049
version (and the early drafts of MIME) actually REQUIRED a version
number to be included in EVERY content-type header field. As one of the
people who pushed hardest for this, both in the original 1049 document
and in MIME, and who ended up yielding on that argument, let me try to
summarize why I was wrong.
Basically, it comes down to the issue of necessity and avoiding needless
complications. MANY formats contain internal verison-numbering schemes,
in which case the Content-type version field is at best useless, and at
worst extremely confusing. The idea, therefore, was that an optional
"version" parameter could be required for those subtypes that need them.
Now, I'm not an expert in PostScript or TIFF, but discussion on this
list suggests to me that these formats have sufficient
internal-identifiying mechanisms to make a content-type version field
superfluous. In the cases where there is a versioning mechanism but it
is optional (which includes PostScript, I guess) it might make sense
for MIME to strongly recommend or even require the use of this optional
mechanism, but I'm not convinced it makes sense for us to layer another
versioning mechanism on TOP of it. And where a good versioning
mechanism is already present & required, I think a MIME version field
is a needless and confusing complicaton. -- Nathaniel