ietf-822
[Top] [All Lists]

Re: MacMIME

1993-02-18 18:21:37
Few of you have probably heard of me; I'm the author of Eudora, a
relatively popular Macintosh POP3/SMTP mailer.  Patrik F{str|m's note was
forwarded to me, and I would like to add my $.02.

Patrik F{ltstr|m <paf(_at_)nada(_dot_)kth(_dot_)se> writes:
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. 

I know one person who said he wanted to do just that.  Anybody who has a
burning ambition to write an RFC about this, please write me, and I'll
forward your name to the person in question.  (Sorry about being coy, but I
was specifically asked not to mention who it is.)

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 important ones are:

AppleSingle - Apple's own representation
AppleDouble - Another Apple standard, but one using two files; one for the
file's data, and the other for the resource fork and sundry
BinHex - The standard Internet representation; it includes a printable encoding
MacBinaryII - Another file representation, used by many existing utilities

We need at least two, and possibly three, methods.

1. Base64 && AppleSingle - I have spoken to several implementors who are
admant about doing things this way.

2. Base64 && AppleDouble - This is what I favor for native Macintosh MIME
mailers.  The data could be sent in one part (this would be legible by any
platform that could understand the data itself), and the resource fork and
sundry in the second part (which Macintoshes could understand and use, but
others could safely ignore).

3. Base64 && MacBinaryII - Some people think this is more convenient than
AppleSingle.  I'm not so sure, but it's a possibility.

Using AppleSingle is simplest for the Macintosh implementor.  However, I'm
concerned that non-Macintosh mailers won't be willing to support it.  That
makes AppleDouble a better choice, since such non-Mac mailers will not have
to decode the Macintosh-specific parts.

1) Just send BinHex 4.0, because it have been wroking for
  almost everyone so far.
2) Encode the mail in Quoted Printable.
3) Encode with Base64
4) Remap the 64 characters in BinHex4.0 into the characters
  that Base64 is using.

I don't see any reason to continue to use the BinHex representation with or
without nested or changed encodings, in a native Mac mailer.  In a MIME
gateway, perhaps.
--
Steve Dorner, Qualcomm Inc.


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