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 ...
This represents a collection of independent objects, where the first object is
available in two different formats: text/plain and application/x-beyondmail.
2) Using multipart/mixed alone
multipart/mixed
text/plain
application/x-beyondmail
... other attachments ...
This represents a collection of objects, where the first is text/plain and
the second is application/x-beyondmail.
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.
It shouldn't. The specifications are quite clear on this -- the parts in
a multipart/mixed are all independent and distinct entities that happen
to have been collected into a bundle.
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.
I use a couple of different MIME clients, none of which have any problems with
getting at the data in multipart/alternative. The worst I've seen is where
multipart/alternative is treated as multipart/mixed, and this just isn't that
bad.
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.
Frankly, this doesn't sound like much of a problem to me.
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.
This is a bug. Plain and simple. It needs to be fixed. Nothing more and
nothing less. Screwing around with structures and using constructs illegally is
not an acceptable alternative -- your proposed cure is much worse than the
disease.
Ned