On Thu, 18 Feb 1993 06:49:14 GMT, David Gelhar
<davidg(_at_)polvadera(_dot_)dartmouth(_dot_)edu> said:
David> Unfortunately, it appears there's a conflict between
compatibility with
David> existing mailers and imperviousness to mauling by evil gateways
-- some
David> of the BinHex characters are outside the list of always-safe
chars in
David> RFC 1341. Perhaps this could be addressed by defining a BinHex
content-type
David> that's compatible with current practice and leaving it up to the
implementor
David> (and/or the user) to choose whether 7bit or quoted-printable
David> content-transfer-encoding is more appropriate, depending on
whether
David> compatibility or reliable transport is of greater concern.
I cannot agreee; this yields the spectre of messages circulating
claiming to be MIME but in fact being garbage. This would be very bad
indeed.
But on the question of encoding, type, and Macs; I think that the
problem is more sticky than it seems at first. If macintosh MUAs just
wrap up binary files as binhex/QP or B64ed 'application/mac-file', you
lose interoperability with other platforms. At the very least you
should distinguish between files that have and empty resource fork
(plain data files) and others.
Even this may not be a sure guide, though, as I have seen apps that
keep all the important info in their data files data fork, but also
put some hints or even just timestamp/ID in the resource fork. The nub
of the problem; if I have a GIF on a mac, and I want to send it to my
friend who uses a 8088 box running OS/9, I want it to arrive as
image/gif, not application/mac-file.
Perhaps well-defined parameters to the mac-file content type might be
appropriate? They would have to be defined to be useful to
non-mac MUAs.
Another possibility is to make a subtype of multipart - for example,
multipart/macintosh-file. This would imply two sub-parts, and parameters to
the parent type could identify the resource and data forks. e.g.:
Content-Type: multipart/macintosh-file; boundary="foo";
resource-fork=p1; data-fork=p2;
--foo
Content-Id: p1
Content-Type: image/GIF
Content-Transfer-Encoding: quoted-printable
....
--foo
Content-Id: p1
Content-Type: application/opaque-mac-resource-file; macapp=macscribble
Content-Transfer-Encoding: quoted-printable
...
--foo
Of course, this does not address the issue of compatibility with
existing Macintosh mailers.
I volunteer to work on a solution to this quandary. Would anyone like
to help out? We had best involve some authors of Macintosh mailers...
-Rens