W3C home > Mailing lists > Public > ietf-discuss@w3.org > May 2001

multipart/alternative extension (Re: Intelligence in standards-based software)

From: Harald Tveit Alvestrand <harald@alvestrand.no>
Date: Fri, 04 May 2001 13:59:02 +0200
Message-Id: <>
To: <ned.freed@mrochek.com>
Cc: Pete Resnick <presnick@qualcomm.com>, ned.freed@mrochek.com, Keith Moore <moore@cs.utk.edu>, Jacob Palme <jpalme@dsv.su.se>, discuss@apps.ietf.org
given the vehemence of this debate, would there be interest in pursuing an 
idea of making a more complete multipart/alternative specification 
(including the RFC 1766 stuff, discussion of various scenarios including 
our by-now long experience with Outlook's use of the feature) and pushing 
it onto the standards track as an update to MIME?


At 23:06 03.05.2001 -0700, ned.freed@mrochek.com wrote:
>This argument might wash if it was the only thing written about the semantics
>of multipart/alternative. But it isn't. In fact we're not talking about what
>RFC 2046 says here at all, we're talking about RFC 1766, where the
>functionality of multipart/alternative was significantly extended past what's
>covered in RFC 2046. (I think the addition of a new parameter that entirely
>changes how you're supposed to interpret multipart/alternative qualifies as a
>significant extension.)
>In fact the effect of section 4 of RFC 1766 on the semantics of
>multipart/alternative is to extend it in exactly the way you describe: You can
>now have a situation where there's no "best" part per se and the differences
>parameter tells you how to choose the right one for a given user.
>Now, maybe you would like to argue that the text in RFC 1766 isn't 
>clear to understand what needs to be done to handle generalized alternatives
>correctly. And I might even agree with that assessment. But I don't think you
>can claim that you received no indication whatsoever that the simplistic
>"last one you can display" approach described in RFC 2046 had been
>Incidentially, it would have been nice to include the RFC 1766 text in RFC
>2046, however, RFC 2046 is a revision of a draft standard (RFC 1521) and 
>at the
>time RFC 1766 was only proposed. So I couldn't add it without forcing a 
>at proposed. Heck, it could not even be referenced, since such a reference
>would obviously be normative.
>>Perhaps before going to full standard, such text could be explicitly
>>put into the text.
>Given that the text in RFC 1766 about this approach has been dropped in RFC
>3066 due to lack of interest on the part of implementors, I see no chance
>of adding it to MIME itself during a move from draft to full standard.
Received on Friday, 4 May 2001 17:14:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:01 UTC