I'd like to second (or third, or whatever) Nathaniel's observation that
debating MIME-Version at this point is entirely out of order. In the
absence of clear, strong evidence that MIME-Version is creating fundamental
technical problems, debating its existence is certain to be unproductive.
To the extent that it distracts us from considering other issues, it is
in fact counter-productive.
Maybe I'm missing something, but it doesn't sound like anyone is arguing
about the need for clearing up what it means to have a version number that
is/is not 1.0. What I have seen is the argument that it cannot be changed
because it will break existing vendor code.
If a vendor walked in with a complete RFC and said "You can't change this
RFC because I've got 3 independently written and interoperating
implementations of the code" would you say "Gee, you're right, we have to
accept this as is"? My guess is you wouldn't do that.
Yes, it means someone has to correct some code, but the current description
doesn't do the job it should. As one example of an existing problem caused
by the current description there are "Mime" mail messages using a version id
of 1.0 which are entirely in EBCDIC. That should be ruled out by the RFC
(i.e. any differences from the RFC should require that the version number
not be 1.0). It is clear from the discussion that some folks have not read
the current wording in this way.
There is obviously an RFC that needs to be developed that describes how to
do "Mime" correctly on a network that is not ASCII based. And a companion
RFC (or subsection) that defines how to translate between the two. And
these should not be part of the current discussion. But you will make their
future development (assuming it ever occurs) more difficult if current tools
are not required to respect the version numbers in reasonable ways.