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

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?

            Harald

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 
>sufficiently
>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
>extended.
>
>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 
>recycle
>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