[Top] [All Lists]

Multipart/Alternative Compatibility Issue

1995-07-18 12:03:59
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

                        ... other attachments ...

2) Using multipart/mixed alone

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