I've run across a compatibility issue between clients when trying to make use
of the multipart/alternative format. I was wondering whether anyone else has
run across this or has comments on the problem.
My mail client uses a custom format to represent rich text, embedded OLE and
extended attribute information. Under configuration control, we support two
different ways of encoding a message that contains this extended information:
1) Using multipart/alternative
multipart/mixed
multipart/alternative
text/plain
application/x-beyondmail
... other attachments ...
2) Using multipart/mixed alone
multipart/mixed
text/plain
application/x-beyondmail
... other attachments ...
Our client can accept either format and assumes that, even in the second case,
the data in the application/x-beyondmail object completely contains and
overrides the body of the text.
The multipart/alternative format clearly more correctly encodes the semantics
of the message. However, the problems we are encountering make it painful to
use this encoding, even with clients that support MIME. I've seen problems
with two clients, Sun's mailtool and NetManage's bundled mail client. I
assume other mail clients might also have problems.
In Sun's mailtool, a received message in format 1 comes in with an empty text
body. The user must then double-click on the icon in the attachment box
indicating the multipart/alternative object. That causes a second window to
appear with the text body showing and the x-beyondmail format appearing as an
attachment in that window's attachment box. No information is lost, but the
two-level interaction just to see a simple message is painful.
The NetManage client behaves even worse. It also shows the
multipart/alternative object as an attachment, but it only does a single level
of parsing, so opening this attachment results in a body that contains both
the text and x-beyondmail contents running together.
Neither behavior is acceptable. Anybody else run into problems like this?
Terry