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

Re: Intelligence in standards-based software

From: Pete Resnick <presnick@qualcomm.com>
Date: Thu, 3 May 2001 23:52:33 -0500
Message-Id: <a05100301b717e143f975@[216.43.25.67]>
To: <ned.freed@mrochek.com>
Cc: Keith Moore <moore@cs.utk.edu>, Jacob Palme <jpalme@dsv.su.se>, discuss@apps.ietf.org
On 5/3/01 at 4:16 PM -0700, <ned.freed@mrochek.com> wrote:

>  > > The problem is that if I send a message in the format
>>  > "multipart/alternative" with different languages in the
>>  > different body parts, then most major mailers will
>  > > only show the recipient one of the body parts
>
>  > right.  but this is a problem inherent in any new feature - you can
>  > hardly expect existing user agents to do something reasonable with
>  > a construct that has never been tried before.

Nonsense. This is not a problem with a "new feature". The spec said 
something very specific about implementation (which I'll get to 
below) and unfortunately that ended up pushing clients toward a poor 
implementation choice for this particular use.

>  > defining a new content-type doesn't help this problem much, if at
>  > all - either the recipient's mailer *still* refuses to show the
>  > text, or the mailer treats as multipart/mixed and displays all of the
>  > parts (which can be quite annoying).  neither is satisfactory.

Or the new content-type definition gives specific text about what it 
is to be used for and implementors will have better guidance to 
address the problem at hand.

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

Perhaps before going to full standard, such text could be explicitly 
put into the text.

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Received on Friday, 4 May 2001 00:53:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 March 2006 20:11:28 GMT