[Mew-dist 09613] multipart/alternative viewed as Binary?
Brad Allen
Ulmo at example.com
1999年 7月 14日 (水) 05:12:20 JST
Bug report:
This is Mew version 1.94b36 on XEmacs 21.1 (Acadia).
Here is Multipart/Alternative message (included part 1), with result
screen showing below when I tried to view it, and a summary above it
as I saw it:
16 *M1999-04-23 To:ulmo at example.com Resume for ulmo at example.com stored at http://w
17 1999-04-23 Brad Allen please forward to webmaster of world4.hire.co
CText--%%-Mew: +inbox (Summary)----[249 more]------------------------------
Subject: Resume for ulmo at example.com stored at http://world14.hire.com/IBM
From: ulmo at example.com
To: ulmo at example.com
Date: Fri, 23 Apr 1999 09:16:29 -0500
###### ### # # # ###### # #
# # # ## # # # # # # #
# # # # # # # # # # # #
###### # # # # # # ###### #
# # # # # # ####### # # #
# # # # ## # # # # #
###### ### # # # # # # #
Content-Type: Application/Octet-Stream
Encoding: quoted-printable
Size: 13125 bytes
To save this part, type y.
To display this part in Message mode, type C-c tab.
[End of messsage]
* * *
Ok, here are the problems:
1. It is not an application/octet-stream. (See included message
body.) Alternatives should make it easier (not harder) for MUA
(Mew) to display message ... ?
2. When I type C-c TAB, nothing happens.
The big problem is #1 (#2 I'll not worry about for now.)
Ok, I just composed, sent and read myself a multipart/alternative
message all in Mew and it seems to be ok the way Mew handles it: it
gives me a choice of viewing whatever I want just as in
multipart/mixed, which means the display is manual rather than
automatic but that is OK with us since we do that anyway from Summary
mode. Then, I composed a message more structured like the below
message (multipart/alternative inside multipart/mixed), and it didn't
have the same behavoir, although it did work better, I was a little
upset that I could not obviously see as a user that it was
multipart/alternative so I knew to chose only one. So I include it
also so you can mail it to yourself as well (I think all these need
remailing using ``mew-summary-reedit'' to really test them).
In case it is of interest, I include excerpt from RFC 2046 for those
who are curious exactly what multipart/alternative is, but it seems to
be unnecessary.
--
5.1.4. Alternative Subtype
The "multipart/alternative" type is syntactically identical to
"multipart/mixed", but the semantics are different. In particular,
each of the body parts is an "alternative" version of the same
information.
Systems should recognize that the content of the various parts are
interchangeable. Systems should choose the "best" type based on the
local environment and references, in some cases even through user
interaction. 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.
"Multipart/alternative" may be used, for example, to send a message
in a fancy text format in such a way that it can easily be displayed
anywhere:
From: Nathaniel Borenstein <nsb at example.com>
To: Ned Freed <ned at example.com>
Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42
--boundary42
Content-Type: text/plain; charset=us-ascii
... plain text version of message goes here ...
--boundary42
Content-Type: text/enriched
... RFC 1896 text/enriched version of same message
goes here ...
--boundary42
Content-Type: application/x-whatever
... fanciest version of same message goes here ...
--boundary42--
In this example, users whose mail systems understood the
"application/x-whatever" format would see only the fancy version,
while other users would see only the enriched or plain text version,
depending on the capabilities of their system.
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.
THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each part of a
"multipart/alternative" entity represents the same data, but the
mappings between the two are not necessarily without information
loss. For example, information is lost when translating ODA to
PostScript or plain text. It is recommended that each part should
have a different Content-ID value in the case where the information
content of the two parts is not identical. And when the information
content is identical -- for example, where several parts of type
"message/external-body" specify alternate ways to access the
identical data -- the same Content-ID field value should be used, to
optimize any caching mechanisms that might be present on the
recipient's end. However, the Content-ID values used by the parts
should NOT be the same Content-ID value that describes the
"multipart/alternative" as a whole, if there is any such Content-ID
field. That is, one Content-ID value will refer to the
"multipart/alternative" entity, while one or more other Content-ID
values will refer to the parts inside it.
---
Thank you, take care,
Brad Allen <Ulmo at example.com>
P.S. Expect a swamp of emails from me soon once I get it more presentable.
-------------- next part --------------
添付メールを保管しました...
送信者: ulmo at example.com
件名: Resume for ulmo at example.com stored at http://world14.hire.com/IBM
日付: Fri, 23 Apr 1999 09:16:29 -0500
サイズ: 14150 バイト
URL: <http://www.mew.org/pipermail/mew-dist/attachments/19990714/d5192822/attachment.mht>
-------------- next part --------------
添付メールを保管しました...
送信者: Brad Allen <Ulmo at example.com>
件名: test
日付: Tue, 13 Jul 1999 15:59:09 -0400
サイズ: 1769 バイト
URL: <http://www.mew.org/pipermail/mew-dist/attachments/19990714/d5192822/attachment-0001.mht>
-------------- next part --------------
添付メールを保管しました...
送信者: Brad Allen <Ulmo at example.com>
件名: test of multipart alternative
日付: Tue, 13 Jul 1999 15:52:37 -0400
サイズ: 22300 バイト
URL: <http://www.mew.org/pipermail/mew-dist/attachments/19990714/d5192822/attachment-0002.mht>
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: 無し
型: application/pgp-signature
サイズ: 460 バイト
説明: 無し
URL: <http://www.mew.org/pipermail/mew-dist/attachments/19990714/d5192822/attachment.bin>
Mew-dist メーリングリストの案内