rfc-1740

MIME Encapsulation of Macintosh Files - MacMIME

P. Faltstrom, D. Crocker, E. Fair

date1994-12 streamLegacy statusPROPOSED STANDARD pages16 canonicalhttps://www.rfc-editor.org/rfc/rfc1740 doi10.17487/RFC1740

This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. [STANDARDS-TRACK]

Extracted elements (20)

design-rationale §2

AppleDouble is the preferred format for Internet mail because it separates the data fork from Macintosh-specific parts, allowing non-Macintosh recipients to easily extract and use the data fork while still providing Macintosh users with the complete document including icons and metadata.

design-rationale §Appendix B

The AppleDouble format places the resource fork entry last in the header file because the resource fork is the entry most commonly extended; this ordering recommendation facilitates sequential extension without rewriting the file.

design-rationale §2c

Users may be allowed to choose between AppleSingle and AppleDouble formats because implementors' definitions of 'trivial' resource forks may differ from users' needs, providing flexibility in encoding choice.

interoperability-note §Appendix A

Apple reserves AppleSingle/AppleDouble entry IDs 1–0x7FFFFFFF; the range 0x80000000–0xFFFFFFFF is available for application-defined entries with no arbitration by Apple.

interoperability-note §3

AppleSingle and AppleDouble are binary formats, so Content-Transfer-Encoding: BASE64 is the safest choice for transmission as it permits transfer over the most restricted email transport channels.

interoperability-note §3

The NAME parameter on Content-Type headers is restricted to seven-bit US-ASCII characters per RFC-1521's definition of 'value', which means non-ASCII Macintosh filenames cannot be faithfully represented in the parameter.

normative-requirement §2c MUST

Documents which lack a data fork MUST be sent as AppleSingle.

normative-requirement §4 SHOULD

For AppleDouble, the NAME parameter is recommended on the Content-Type header of both the header part (application/applefile) and the data fork part. If no appropriate Content-Type exists for the data fork, it should be sent as application/octet-stream.

normative-requirement §3 RECOMMENDED

It is recommended that a NAME parameter be included on the Content-Type header of AppleSingle and AppleDouble messages to give the recipient a hint about the attached file. The value must be a 'value' as defined by RFC-1521, restricting it to seven-bit US-ASCII characters.

normative-requirement §2c MAY

Macintosh documents with well-known MIME types and non-existent or trivial resource forks can be sent as regular MIME body parts, without AppleSingle or AppleDouble encapsulation.

normative-requirement §2c SHOULD

Unless there are strong reasons not to, all Macintosh documents with non-trivial resource forks or without corresponding well-known MIME types should normally be sent as AppleDouble.

protocol-element §Appendix A

AppleSingle defines 15 predefined entry IDs: Data Fork (1), Resource Fork (2), Real Name (3), Comment (4), B&W Icon (5), Color Icon (6), File Dates Info (8), Finder Info (9), Macintosh File Info (10), ProDOS File Info (11), MS-DOS File Info (12), AFP Short Name (13), AFP File Info (14), AFP Directory ID (15). Entry ID 7 is not used.

protocol-element §2a

APPLICATION/APPLEFILE is a MIME type for sending an AppleSingle file (both forks and Macintosh-specific metadata) as a single byte stream. Optional NAME parameter must be a RFC-1521 'value'. Binary content typically requires Content-Transfer-Encoding: BASE64.

protocol-element §2b

MULTIPART/APPLEDOUBLE is a MIME multipart type for sending AppleDouble files, which separate the Macintosh resource fork (sent as application/applefile) from the data fork (sent as an appropriate content type such as image/gif or application/octet-stream). May have only two sub-parts.

security-consideration §6

The application/applefile content type facilitates transmission of operating-system sensitive data (resource forks, Finder metadata, file attributes), potentially enabling easier relaxation of security rules than intended by the sender or the sender's system administrator.

security, email

wire-format §Appendix A

Each AppleSingle/AppleDouble entry descriptor is 12 bytes: Entry ID (4 bytes unsigned), Offset from file start (4 bytes unsigned), Length of data (4 bytes unsigned, may be 0). Entry ID 0 is invalid; Apple reserves IDs 1–0x7FFFFFFF.

wire-format §Appendix C

File dates (entry ID 8) are stored as signed 32-bit seconds relative to midnight January 1, 2000 GMT, covering create, modify, backup, and access times. Unknown values are set to 0x80000000.

wire-format §Appendix C

Finder Info (entry ID 9) contains FInfo (16 bytes: fdType 4 bytes, fdCreator 4 bytes, fdFlags 2 bytes, fdLocation 4 bytes, fdFldr 2 bytes) and FXInfo (16 bytes extended finder info). Macintosh File Info (entry ID 10) stores ioFlAttrib in the low byte of a 4-byte field with 3 filler bytes.

wire-format §Appendix B

The AppleDouble header file uses magic number 0x00051607 (vs. 0x00051600 for AppleSingle), has the same header structure as AppleSingle but omits the Data Fork entry. The AppleDouble data file contains only the raw data fork with no additional header.

wire-format §Appendix A

The AppleSingle file header contains: magic number (4 bytes, 0x00051600), version number (4 bytes, 0x00020000), filler (16 bytes of zeros), and number of entries (2 bytes, unsigned). Byte ordering follows MC68000 big-endian convention.