Re: Intelligence in standards-based software

> > Exactly. We defined something in a standard that hasn't been implemented by
> > user agents to your satisfaction

> No, what was written in 2046 actually encouraged implementors to "do
> the wrong thing" (section 5.1.4):

>     As with "multipart/mixed", the order of body parts is
>     significant.  In this case, the alternatives appear in an order of
>     increasing faithfulness to the original content.  In general, the
>     best choice is the LAST part of a type supported by the recipient
>     system's local environment.

> and:

>     Receiving user agents should pick and display the last format
>     they are capable of displaying.

> The semantics of multipart/alternative are defined in such a way that
> they assume there is generally one "best choice" for it's
> "faithfulness to the original content." The definition given in 2046
> does not adequately address the case where the alternatives are
> completely equal in value from the perspective of the sender and
> recipient user agents, that the order of the parts is not significant
> at all, and that the alternatives only differ in their relative value
> to the *human recipient*. Had such an example been discussed
> explicitly, and explicit direction been given to implementors that
> user agents would do well to allow humans to choose to display any of
> the parts that they wished, less user agents would have gone for the
> "display the last alternative that you can display and throw away the
> rest" implementation.

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.

				Ned

Received on Friday, 4 May 2001 02:27:09 UTC