I feel pretty concerned about the lack of precision in the registered
data types in MIME mail -- it will come to haunt us VERY SOON. How
hard would it be at this point to change "ps" to "ps;1" and "gif" to
"gif;89a" and "tiff" to "tiff;5.0"?
I read thru a lot of the archived mail of this mailing list, and while
the topic was skirted, it didn't seem like it was taken very
seriously. Mark Crispin argued by analogy that "FTP only had one
version number", "TCP has only one version number", but I don't think
the analogy applies very well.
Perhaps you think you've pushed off this issue to the IANA, but I
don't think so, in that the types that are not IANA-registered and
built in don't have version numbers.
(I fear we will never get all of the little nits out of MIME.)
Your point is well taken, and we would do well to put version numbers in
content-type headers. However I don't want to delay MIME going to proposed
standard for this reason, especially if we have to define a mechanism for
defining content-type versions before we can proceed. When MIME goes up for
draft standard status we can fix this and other problems that will
undoubtedly crop up. For instance, I think we could safely add a "version="
parameter to all body part types at a later date without breaking existing
MIME readers.
I also think you are correct that the PostScript spec as currently in MIME
is not sufficient to ensure interoperability. (other concerns have to
do with how ends of lines are represented (since we haven't defined an
end-of-line convention for application bodyparts) and line lengths (since
some systems can't store very long lines). However, it is probably good
enough for now. Some of these things can't be determined without some
operational experience. That's what proposed standard status is for.
Someone should be making a list of MIME problems, though, so we can discuss
them at that time.
Keith