I believe this debacle was one of the reasons why HTTP/1.0 came out with
very clear descriptions of how to behave when the version number changes,
but for MIME, it was too late - we agreed that it was a constant.
The problem with version numbers is that they assume a linear path of
feature upgrades - 1.0 < 1.1 < 2.0, in some sense.
If you have the "compressed CTE extension" and the "efficient multipart
extension" (example!), and some do one and some the other, we don't have
a linear path, but a tree, and numbers aren't too useful for labelling that.
An excellent example of where this was tried and failed is PostScript. The
label "level 2", which collects a large number of changes and extensions "under
one roof", has ended up being largely meaningless and causes all sorts of
interoperability problems in practice.
More generally, protocol extensions are fine when:
(0) You are willing to allow damage to the installed base in terms of loss of
backwards compatibility.
(1) You are dealing with a point to point protocol and have a way of negotiating
features.
(2) You have a means of discovering in a store-and-forward environment what the
final recipient's capabilities are.
We've long since agreed that (0) is a nonstarter for email. And (1) does not
apply and cannot be made to apply. Which leaves (2), which is what the
MAILCAP work is going to try and do.
Besides, you *still* don't know what the recipient supports before you
send the message.
Exactly.
Ned