I think that you always have to differ between sending DATA in
a certain format, for example a GIF picture, and a special
file which contains the data, in this example a Macintosh
file wich includes the GIF data. If you want to send the
picture, you should ALWAYS send it as image/gif. If you
want to send the Macintsh file (with all the fancy icons),
send it as a Macintosh file. You will never be able to
find a format which suits every need in this matter.
I agree entirely.
So, the first problem is to store the Macintosh file
on a filesystem that can not handle to different forks
in the same file. There are several ways of doing that.
Apple do accept at least two (three?) of them in their
Apple UNIX (A/UX). The CAP (Columbia AppleTalk Package)
use a third one, and so on.
The simplest way to handle Mac files, one which I have
been using in a limited application, is to send as
application/octet-stream with conversions of either
AppleSingle or MacBinary and Base64 CTE. As a matter of
fact, I am thinking of writing up these 2 formats in a RFC
and registering them as conversions.
The appeal of this approach is that MIME aware UAs on any
platform can dump out either of these as binary files and
plenty of utilities on the Mac will convert them.
(Actually, MacBinary is particularly interoperable but doesn't
carry all the file info that AppleSingle does.)
The negatives are:
1. BinHex offers interoperability with non-MIME UAs which this
approach does not offer. But then again, the same argument
can be made for uuencode vs. application/octet-stream with
CTE of Base64 for UNIX files.
2. Certain files have data forks which are compatible across
platforms and it would be nice if this data were separated from
the resource data. (I am not referring to something like
GIF, but maybe Microsoft Excel files.) In those cases, it would
be nice to support an AppleDouble like scheme where the data fork
portion appears as an application/octet-stream and the resource
fork along with file info is perhaps placed in a different
application/octet-stream with some mechanism to link the
two.
Note that option 2 does not preclude but can supplement this
scheme.
-Ray