Summary

  • The December 1994 RFC 1740 specified MIME packaging for Macintosh files. Its central choice was between AppleSingle, which keeps the file together as one byte stream, and AppleDouble, which separates Mac-specific information from the data fork.
  • For most files needing special packaging, RFC 1740 preferred AppleDouble: a multipart/appledouble message with an application/applefile header part and a separately typed data part. A Mac recipient could recover the extra file information; another system could open the data fork on its own terms.

The file had a second suitcase

On many computers, a file looks like one long stream of bytes. A classic Macintosh file arrived with more baggage. Its data fork contained the material a non-Mac system would usually find useful. Its resource fork could carry program segments, icon bitmaps and other attributes; Finder information added another layer. Put that file onto a filesystem expecting one simple stream, or push it into an email message, and someone had to decide which pieces would travel and how the recipient would recognize them.

Patrik Faltstrom, Dave Crocker and Erik E. Fair set out the mail answer in RFC 1740. Their choice was shaped by the MIME framework of RFC 1521, which let a message carry separately described body parts. MIME had already made room for images, application data and multipart messages. The Macintosh problem asked for a particular arrangement inside that room: preserve the extra Mac information while keeping the ordinary data accessible to someone with a different machine.

The blunt approach was AppleSingle. It bundled file contents and attributes into one consecutive byte stream and sent that stream as application/applefile. The approach protected the complete package, but a recipient who wanted just the data had to understand the AppleSingle wrapping first. Imagine sending a sandwich sealed inside a toolbox. Everything is there; lunch now depends on finding the right screwdriver.

AppleDouble opened the toolbox. It divided the file into a header containing the resource fork and desktop information, and a data fork that could stand as its own MIME part. The resulting multipart/appledouble had exactly two subparts. The header traveled as application/applefile. The data could carry the type that best described it: the RFC's example used image/gif; where no registered type fit, application/octet-stream supplied the general container. A recipient on a non-Mac system could take the data part. A Macintosh recipient could put data and Mac-specific information back together.

RFC 1740 called AppleDouble the preferred format for a Macintosh file included in Internet mail. It also made two practical exceptions. A document with a well-known MIME type and no meaningful resource fork could travel as an ordinary MIME body part. A document without a data fork had to use AppleSingle, because there was no separate ordinary data part to offer. For the rest, especially a nontrivial resource fork or data without a standard content type, AppleDouble was the normal recommendation. Those details kept the scheme from turning every attachment into the same ceremonial two-part parcel.

The old mail channel still shaped the wrapping. AppleSingle's binary stream and AppleDouble's binary header might need a content-transfer encoding to pass through restrictive transport. RFC 1740 named Base64 as the safest option across such channels. It also recommended a name parameter to give the recipient a filename hint, while noting that the inherited MIME syntax restricted the value to seven-bit US-ASCII. A file could be preserved more faithfully than its name could be written. That small mismatch captured the period: richer attachments traveling inside a mail system whose oldest habits still occupied the address labels.

The specification assigned different jobs to the parts of a message. The data fork could announce itself in a standard MIME type; the resource and desktop details could ride alongside it without being thrown away. The trick was less glamorous than a new application icon, but much more useful to the person opening the attachment on the wrong kind of computer.

RFC 1740's story is the story of an interface made hospitable without flattening the thing it carried. The authors had a file with two forks and a mail envelope that could hold multiple parts. AppleDouble used the envelope's compartments rather than forcing every recipient to unpack an opaque Mac bundle. The photograph could be seen. Its frame still made the trip.