Nathaniel,
In regard to your comments:
1. There are already MIME implementations out there from MAJOR vendors
(I won't point fingers) that will apparently die horribly if they get
anything other than "1.0". One could certainly argue that they
shouldn't do this, but RFC 1341 didn't offer them any clear guidance on
this score, so they're not really out of spec, and it is RUDE to break
specs in people's faces. Sometimes you have to, but I really don't
think this case is important enough to do that.
2. Making this change *might* be enough to set the clock back a few
months on MIME's soon-to-be-achieved (I hope) status as a Draft Internet
Standard. Is it really worth it if that's the case?
I sympathize with your goals, but I think this train has already left
the station.... -- Nathaniel
I *really* think that we should try to carry forward the proposed
clarifications of the MIME-Version: header (i.e. put them in the spec),
even in the face of the concerns you raise.
I don't agree that item #1 poses a serious constraint, because IF the
spec changes NOW to specify what should be done in the presence of a
non "1.0" value, then these vendors will have PLENTY of time to
incorporate the necessary revisions in future releases of their
products BEFORE there would actually be a non "1.0" value. So when
a non "1.0" MIME-Version does get defined and start to be used, only
those who bought the earliest versions of the products you allude to,
and who *still* use them at that time in the future (and have never
upgraded, nor switched to something different, etc) would be affected.
(And I don't feel we bear much responsibility for *any* vendor who
would release a product that really "dies horribly" in the face of
something that, at the worst, their software should regard as a
syntactically ill-formed message.) So clarifying the meaning of the
MIME-Version: header wouldn't break anyone's code in any immediate
sense - we would be specifying what their products should do in the
*future* when some new MIME version is specified.
As for point #2, I would hope it doesn't set the clock back at all,
but even if it did, I would say that yes, providing for a means of
evolving the protocol IS that important. A lot of us are aiming for
an awful lot of the entire WORLD's e-mail infrastructure to ride on
MIME, and the lack of a mechanism for managing the evolution of that
infrastructure could seriously impair MIME's ability to fulfill
that role and/or cost the industry a lot in having to struggle
with the less efficient work-arounds that would be devised.
Paul Lustgarten
AT&T EasyLink Services