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 MIME-Version: header presumably has two purposes. One, its
presence is an indication that a message was composed in compliance
with some MIME standard. Two, some theoretical future standard may
change the value of the header, making the header indicate which of
several competing message format standards the composer is in
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.
The only semantic that RFC1341 gives to the presence of a
MIME-Version: header involves the case where there is no Content-Type:
header. In the presence of a MIME-Version: header one may presuume
that the contents of a message lacking a Content-Type: header are
really "text/plain; charset=us-ascii", as opposed to the contents
being indeterminate but still having to be interpreted as "text/plain;
charset=us-ascii". Were the MIME-Version: header not required, the
composer could have more directly stated its intent by writing a
"Content-Type: text" header instead of the MIME-Version: header.
As for the possiblilty that some future standard will change the value
of the MIME-Version, I maintain that either this will never happen or
that should it happen, there will be no difference in interpretation
of messages which is based soely on the value of the MIME-Version:
The MIME and RFC-822 standards supply ample alternate mechanisms for
extension. It would be silly to assign a semantic meaning to
MIME-Version when that meaning can be more cleanly assigned to a new
header, content type, or parameter. The fact that the April Internet
Draft relys solely on these mechanisms and doesn't change the value of
the MIME-Version: header is a strong indication that these mechanisms
are sufficient and the MIME-Version value will never change.
Nor can there be an incompatable change for the MIME-Version header to
signal. Due to the fairly substantial installed base of RFC 1341
readers, any future standard is constrained to specify a message format
that can be reasonably handled by an RFC 1341 reader. Were it to do
otherwise, it would have great difficulty getting through the IETF
In RFC 1341, the MIME-Version: header is a useless, but harmless
appendage. An RFC 1341 composer is required to generate the header,
but a reader is free to ignore it when reading.
The April Internet Draft adds two warts related to the MIME-Version
header. The lesser of which is to require interpretation of
message/partial to handle MIME-Version: as a special case.
The more serious of which is the section describing what happens if
the MIME-Version: header exists, but has a value other than "1.0".
The standard states that the message "cannot be assumed to conform
with this specification", giving the implementation all sorts of
leeway as to what to do when this happens. Furthermore, it encourages
the reader to "check the version number and at least warn the user if
an unrecognized MIME-version is encountered".
Should the MIME-Version: acutally change, software conforming to the
April Internet Draft will start behaving in all sorts of unpredictable
manners when encountering messages with the newer MIME-Version. At
the very least, they will continually spitting out incomprehensible
warning messages. (I challenge anyone to devise a warning message
suitable for a non-technical user.)
This header should be buried. All references to MIME-Version: should
be removed from the standard prior to its publication.
_.John G. Myers Internet: jgm+(_at_)CMU(_dot_)EDU