The problem I see with the MIME-Version as it presently exists is that there
is no clear procedure for an implementation to take to use it. The problems
include:
o Content-* headers may occur before the MIME-Version. If MIME-Version
changes the semantics of Content-*, then you have to have a two-pass process
or at least a lookahead when you encounter a Content-* before getting any
version information.
o No clear indication or understanding of what to do if you get more than one
version type header (this bug also exists with Content-*).
o No clear indication or understanding of how you are supposed to compare the
given MIME-Version with the list of versions you understand. Dave Crocker's
proposal makes the problem even more horrendous. Having 1*token as the BNF
is, quite frankly, frightening.
By the way, I suppose you all know that certain cretinous MTA's which are in
common use on the net love to rewrite headers and mangle case. As a result,
you must do a case-independent comparison with all sorts of possibilities of
what differences are differences and what are not.
o No clear indication or understanding of what you are supposed to do when you
get a MIME-Version mismatch. WHAT DOES IT MEAN???
1) Does it mean you can't parse it so don't even try?
2) Does it mean you should try parsing it anyway?
3) Does it mean that the version is bogued in some way and you should just
ignore the mismatch?
All in all, it is not a very robust mechanism.
I discovered that an October draft UA cannot reasonably handle December draft
messages and vice versa (although one could write a December draft UA to
handle October draft format). This is what MIME-Version was supposed to do.
All fine and good. The problem is that the versioning mechanism does less to
help you figure this out than the actual syntax you see. If you see
parameters that are not in attribute/value form you can make a guess as to
what it means if the type is multipart... and similar heuristics which are
illegal to discuss in several states under local obscenity laws.
I've reluctantly (honest, Nathaniel!!) come to the conclusion that the version
is not going to rescue us from flag days, and if anything it makes things
nastier. All this comes about because we are insisting upon recycling header
names that had different, but vaguely similar, semantics.
There is a different possibility. One that guarantees interoperability. One
that is simple to implement. One that is not vulnerable to a fragile version
mechanism that is just one more thing to go wrong.
That possibility is this: new header names. If you want a new syntax, invent
a new header for that syntax. If a syntax is to be obsoleted or retired,
retire its header with it.
If Content-* is renamed to Body-*, then there is no mailer that knows about
prior syntax of Body-* (let's ignore Body-Version for now). The implementor
of a mail UA can implement the older headers, or ignore them, depending upon
his needs. He does not have to worry about different versions of syntax for a
header. There is only one valid syntax.
Computer scientists love versioning as they keep on evolving their mechanisms,
and they have no idea of the non-interoperable protocol carnage they leave
behind. I'm not accusing you of this, Nathaniel, rather the environment in
which you work. We still have to keep the lowest common denominator in mind.
I'm really sorry to bring this up so late. I don't really expect much to come
out of it. I didn't realize that my vague queasy feelings were founded in
grim reality until I had to deal with October/December draft interoperability.
[I ended up punting on that, since not many people are using that code yet.
The October draft software will do a lot of extra work searching for multipart
boundaries in a December draft message that don't exist and end up returning
an empty body; December draft software will consider October draft messages to
be unstructured. Hopefully both October draft software and October draft
messages will be extinct soon.]
I do, however, promise to fight tooth and nail against any change to the
version once this thing becomes a standard.
Regards,
-- Mark --