ned+ietf-822(_at_)mrochek(_dot_)com wrote:
[Tony Hansen wrote:]
>
>> I almost hate to ask, but could we do anything with:
>> MIME-Version: 2.0
>> ?
>
>
> Seems unnecessary to me, and in any case many believe this number can
> never be incremented.
>
> Ned
I can see a potential issue with 2.0[*], but what would be the problem
with 1.1, 1.2, etc. (assuming that the hypothetical version 1.1 specifies
either that leading zeros in the fractional part are forbidden or that
they are to be ignored, and that no extraneous trailing zeros are
permitted)? Checking the version then boils down to checking the value
of the part to the right of the dot as an integer.
Um, no. There used to be text in MIME that said that those were the semantics.
However, at the time there was one implementation that didn't use these
semantics -- the MIME-Version had to be literally 1.0 or it didn't handle the
content. There was some discussion and the upshot was that MIME-Version became
in effect a monolithic tag. RFC 2045 now explicitly states that ANY other value
in this field cannot be assumed to be in any way in compliance with the MIME
specification.
In hindsight this was a terrible decision. BUt it is also one that cannot
be undone now.
In retrospect, a simple integer version number would have been preferable.
It is in effect what we have now.
An alternative way to deal with the issue would be to permit version numbers
2.0, 3.0, etc., requiring (as of version 2.0) that the fractional part
always be zero.
* if 2.0 is valid, short of an exhaustive table of valid version
numbers maintained by every MIME program, it's not clear whether
1.9876543210 is or isn't valid.
None of this addresses the essential problem -- that existing clients won't
know how to handle a message with anything other than 1.0 in it.
Ned