< The MIME-Version: header serves no purpose. In RFC 1341 it was mostly a
< harmless appendix, but in the April Internet Draft, it has spread a number
< of special-case warts throughout the standard. It is becoming burdensome
< and should be removed from the MIME standard.
< ...
< The first purpose (indicating a message was composed in compliance with
< some MIME standard) is already served by the various Content-* headers.
< While some composers which existed prior to the MIME standard would
< generate Content-Type: headers, none of these would generate Content-Type:
< values which are at variance with the registered MIME content types. If a
< message has Content-* headers, it is safe to interpret them according to
< the MIME spec. In fact, RFC 1341 does not permit MIME readers to ignore
< Content-* headers in the absence of a MIME-Version: header.
I disagree strongly with this sentiment. If there is no MIME-Version:
header, the message is not in MIME format, and expecting the Content-*:
headers to be in comformance with the MIME format when there is no
MIME-Version: header is asking too much. The Content-Type: header has been
around for a LONG time, and many providers have done various things with it.
Unfortunately, these things are NOT necessarily compatible with MIME.
If it doesn't say it's MIME, then it's not MIME. Sorry, but it's true.
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
att!pegasus!hansen, attmail!tony