Re: Intelligence in standards-based software

On 5/3/01 at 11:06 PM -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'm perfectly willing to see the history the way you describe:

- RFC 1521 defined multipart/alternative in such a way that it 
assumed there is generally one "best choice" for it's "faithfulness 
to the original content" and did not adequately address the case 
where the alternatives are completely equal in value except in their 
value to the *human recipient*. This encouraged implementors to write 
code of the "display the last alternative that you can display and 
throw away the rest" variety.

- RFC 1766 tried to remedy that situation by significantly extending 
1521 for the specific case of language. The remedy did not catch on 
with implementors. (I take it this was the usual Catch 22, since no 
one would implement sending until their were receivers, and receivers 
wouldn't change their code because there were no senders.)

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

The old and crusty of us didn't do it because of the Catch 22 
involved; I wouldn't argue that was from lack of notice. However, my 
guess is that newer implementations didn't do it because there was no 
indication to do so in 2046.

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

I disagree that the reference would have necessarily been normative. 
I assume that 1766 had at least *one* implementation when it came 
out. When we have new implementation experience, certainly it 
wouldn't cause a recycle at proposed to include a "Note:" of warning 
indicating that the "best-is-last" approach doesn't work with some 
uses and that implementors would do well to account for this by 
providing user interaction.

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

This, on the other hand, might be true; I don't know if it's legit to 
make the change going to full standard. Hey, wait a minute....aren't 
you the one who decides this stuff? :-)

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Received on Friday, 4 May 2001 10:28:01 UTC