headers
Bruce Lilly | 19 Apr 2003 02:00
Picon

MIME-Version (Was Re: gzip-8bit)


ned+ietf-822 <at> mrochek.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.

In retrospect, a simple integer version number would have been preferable.

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
(Continue reading)

Permalink | Reply | 5 comments |
headers
Keith Moore | 19 Apr 2003 02:22
Picon

Re: MIME-Version (Was Re: gzip-8bit)


The problem with a version number change is that existing clients won't know
how to handle a message with version != 1.0.  So yes, you could change the
version number, but only if you're willing to completely abandon compatibility
with the installed base (and we weren't willing to do that even when we
introduced MIME).  

The value of the version number would be in allowing new clients (that
understood the both the old and new version of MIME) to be able to distinguish
version x messages from version y messages.  

To take an example from a slightly different field:  IPv4 and IPv6 both have
the IP version number in the first four bits of the packet, so if you have a
situation where IPv4 and IPv6 can both appear in the same context, then you
can tell the two apart.  (I don't think this actually happens in practice
unless you're tunneling IP over IP; for instance, both Ethernet and PPP have 
separate packet types for IPv4 and IPv6.)
Permalink | Reply | 1 comment |
headers
Bruce Lilly | 19 Apr 2003 03:16
Picon

Re: MIME-Version (Was Re: gzip-8bit)


Keith Moore wrote:
> The problem with a version number change is that existing clients won't know
> how to handle a message with version != 1.0.  So yes, you could change the
> version number, but only if you're willing to completely abandon compatibility
> with the installed base
[...]
> To take an example from a slightly different field:  IPv4 and IPv6
[...]

Same situation; IPv4 software has no way to deal with IPv6 packets. That hasn't
made all IPv4 software obsolete overnight, nor has it prevented IPv6 software
from being developed and deployed.

It's a matter of benefit vs. cost.  In the case of the original subject, there
were a number of issues related to the overloading of compression (and potentially
signing, encryption, etc.) onto Content-Transfer-Encoding in addition to
encoding, leading to a combinatorial explosion of potential CTE types, along
with problems for composing MUAs' attempting to automatically select an
appropriate CTE, potential DoS attacks, gateway issues, etc.
Permalink | Reply | 0 comments |
headers
ned+ietf-822 | 19 Apr 2003 20:54

Re: MIME-Version (Was Re: gzip-8bit)


> ned+ietf-822 <at> mrochek.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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Keith Moore | 19 Apr 2003 21:15
Picon

Re: MIME-Version (Was Re: gzip-8bit)


> 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.

it's not clear that the effect is limited to clients.  too many
intermediaries peek into (or modify) MIME structure.

Keith
Permalink | Reply | 1 comment |
headers
ned+ietf-822 | 19 Apr 2003 21:36

Re: MIME-Version (Was Re: gzip-8bit)


> > 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.

> it's not clear that the effect is limited to clients.  too many
> intermediaries peek into (or modify) MIME structure.

And some even do it legitimately... Regardless, very good point, sorry for
the omission.

				Ned
Permalink | Reply | 0 comments |

Gmane