No it isn't. It's merely almost useless.
This was discussed at the last IETF meeting. If we had been smart and
specified how a UA should handle MIME-Versions other than 1.0 -- for
example, to say that the "1" was critical and the "0" was informational
-- it could have been useful. But we didn't, and there are already
implementations out there that won't decode the MIME data if any variant
on "1.0" is used. This is too bad, but it's done. However, it still
give you one very useful bit of information, namely that the message was
indeed composed with MIME in mind.
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.
This is where you're wrong, my friend. I know of very very large
company that prefers not to be mentioned in this context. They run a
large commercial mail service with an SMTP gateway. They've been using
"Content-type: text" and some less common values for years, and they
told me they found "MIME-Version" critical in deciding whether or not to
do MIME translations. I don't remember all the details, but I think
the main thing is that their native transport is 8-bit, and thus they've
had different transport encoding requirements. This means that
MIME-Version helps them tell whether or not they might need to do an
encoding without scanning the whole message. In particular, if there is
MIME-Version but no Content-Transfer-Encoding of "8bit" or "binary", it
is 7-bit safe.
In fact, RFC
1341 does not permit MIME readers to ignore Content-* headers in the
absence of a MIME-Version: header.
How do you come to thatt reading of it?
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.
Umm, not quite right. I believe MIME makes it clear -- as did RFC 822
-- that even in the ABSENCE of MIME-Version, you've got plain ascii
text. So this is actually not a need for MIME-Version.
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:
header.
Alas, the lack of semantics guarantees that you are right. Actually,
this level of stability is probably a good thing anyway, but I do wish
the consequences had been forseen.....
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.
We wanted to change it. That's when we found we couldn't do so without
breaking some existing implementations!
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".
Sigh. These are weasel words, but they can't really do anything to
close this barn door because the horse has already escaped. The truth
is that we couldn't come up with any meaningful guidance for this case,
in the presence of widely-varying existing implementations. There's at
least one MIME implementation that will consider the following to be a
non-MIME message:
MIME-Version: 1.0 (as interreted by jgm)
Comments such as this are definitely legal, and the main point of that
note in my mind was to point this out to future implementors.
This header should be buried. All references to MIME-Version: should
be removed from the standard prior to its publication.
I disagree. It is a wart, but still serves two useful purposes. One,
as I said above, is in distinguishing MIME messages from pre-MIME uses
of Content-type. The other is that its presence in a message you send
advertises, to your recipients, that it is safe to send you MIME. All
in all, it isn't what we hoped it would be, but that may be for the
best, and it is still useful. -- Nathaniel