- From: Pete Resnick <presnick@qualcomm.com>
- Date: Thu, 3 May 2001 23:52:33 -0500
- 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 UTC