ietf-822
[Top] [All Lists]

MacMIME

1993-02-18 16:02:55
I have been thinking about sending Macintosh files with MIME since
Nathaniel a couple of days ago asked anyone doing a simple RFC
describing how to do that. 

Now the discussion about sending Macintosh files in MIME has
been encapsulated in a discussion about a gateway between
a Macintosh mailer and MIME.

Here is what's just zooming around in my brain just now. I'm also
ready to take the responsibility of editing something that
this forthcoming discussion might end up to.

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 hereby only will talk about sending Macintosh files
to another Macintosh user. The other user (or myself)
might be running a mailer on a unix computer, or anything
which don't have the Apple filesystem, which have seperate
data- and resource forks, and also some special info which
I hereby call "finderinfo", which includes timestamps etc.

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.

One interesting method is then BinHex 4.0 which is supported
in several applications, both commercial, shareware and public
domain siftware.

The BinHex 4.0 works in a way where you bundle all of the forks
together in one file, and also some header stuff (no details in
this letter, it's midnight in sweden) and a checksum. That
mixture of data is then rewritten with exactly 64 different
characters, but unfortunately not the same as Base64.

What to do then?

There are at least four opportunities:

1) Just send BinHex 4.0, because it have been wroking for
   almost everyone so far.

   NOT recommended, because the 64 characters chosen for Base64
   is very well chosen (I do remember the discussions we had...).
   Just don't do this!

2) Encode the mail in Quoted Printable.

   Well, might be a solution. I will run some tests and 
   come back with statistical information what happens
   with the size of the file.

3) Encode with Base64

   See above

4) Remap the 64 characters in BinHex4.0 into the characters
   that Base64 is using.

   I think this might be the best idea.

   I'll be back with a translation table (it's only 5-7 characters
   that have to be remapped).

I have chosen to use BinHex4.0 as a representation of the file
before and after the MIME "transportation service". That is just because
BinHex4.0 is so well supported, and as I said earlier, it may happen
that a user is not able to unpack the file (from the MIME format)
onto a Macintosh. If that's the case, you have too many ways
of representing a Macintosh file.

This is my ideas which are working and working in my head. I'll
be back tomorrow with more info and a more strictly document
if you give me more input.

        Patrik

<Prev in Thread] Current Thread [Next in Thread>