Re: Some bugs for balsa 2.0.2

[Peter Bloomfield <PeterBloomfield MindSpring com>]

On 2002.09.19 06:30 M. Thielker wrote:
> Hi,
> 
> On 2002.09.19 12:21 Peter Bloomfield wrote:
>> Iirc, it's suggested that an MUA show the first version it's
Oops--*last* version!
>> capable of, in the order specified by the sender, but it isn't 
>> a MUST or even a SHOULD, so doing something different doesn't 
>> break the rfc, nor even bend
> 
> If that's really true, why isn't there an option to "Prefer 
> text/plain over text/html"? I'd really like that, it gives my a 
> chance to decide if I want to even look at rendered html 
> beforehand.

RFC 2046 (http://www.ietf.org/rfc/rfc2046.txt) is the final word. 
In part, it reads:

    In general, user agents that compose "multipart/alternative"
    entities must place the body parts in increasing order of
    preference, that is, with the preferred format last.  For 
fancy
    text, the sending user agent should put the plainest format
    first and the richest format last.  Receiving user agents
    should pick and display the last format they are capable of
    displaying.  In the case where one of the alternatives is
    itself of type "multipart" and contains unrecognized
    sub-parts, the user agent may choose either to show that
    alternative, an earlier alternative, or both.

    NOTE: From an implementor's perspective, it might seem more
    sensible to reverse this ordering, and have the plainest
    alternative last. However, placing the plainest alternative
    first is the friendliest possible option when
    "multipart/alternative" entities are viewed using a
    non-MIME-conformant viewer.  While this approach does impose
    some burden on conformant MIME viewers, interoperability with
    older mail readers was deemed to be more important in this
    case.

    It may be the case that some user agents, if they can
    recognize more than one of the formats, will prefer to offer
    the user the choice of which format to view.  This makes
    sense, for example, if a message includes both a nicely-
    formatted image version and an easily-edited text version
    What is most critical, however, is that the user not
    automatically be shown multiple versions of the same data.
    Either the user should be shown the last recognized version or
    should be given the choice.

Now Balsa shows the icon list, so the user is `given the choice', 
which makes Balsa compliant. As I read that last sentence, that 
gives us a lot of flexibility about what other options the user 
is given.

To handle an instant-crash message that's only html, not 
multipart/alternative, I believe we'd need an option to render 
html only on request--preferring text/plain over text/html 
wouldn't help in that case.

Comments?

Peter