RFC 1741

RFC 1741: MIME Content Type for BinHex Encoded Files 🎀

Okay bestie, let's get the vibes check done first 💖 This is Request for Comments: 1741, from the Network Working Group, and it's Category: Informational. It's dated December 1994. The authors are P. Faltstrom (Royal Institute of Technology), D. Crocker (Brandenburg Consulting), and E. Fair (Apple Computer Inc.) 🫶 The title block doesn't list anything this one obsoletes or updates, so no drama there ✨

Status of This Memo 📝

This memo just provides information for the Internet community 🌈 It does not specify an Internet standard of any kind, so it's not a rulebook. Distribution is unlimited, so you can share it with everyone 💅

Abstract ✨

So this memo explains the format to use when you send BinHex4.0 files through MIME [BORE93] 🦋 It's compatible with existing ways of distributing Macintosh files. Only when available software and/or user practice dictates, SHOULD this method be employed. It is RECOMMENDED to use application/applefile [FALT94] for maximum interoperability, because it's the iconic choice 👑

1. Introduction 🧚

Okay so Macintosh files are made of two parts, called forks 🍎

• DATA FORK: The actual data included in the file. The Data fork is typically the only meaningful part of a Macintosh file on a non-Macintosh computer system. For example, if a Macintosh user wants to send a file of data to a user on an IBM-PC, she would only send the Data fork 💀
• RESOURCE FORK: Contains a collection of arbitrary attribute/value pairs, including program segments, icon bitmaps, and parametric values ✨

Extra info about Macintosh files gets stored by the Finder in a hidden file called the "Desktop Database" 🙈

Here's the tea: non-Macintosh filesystems only handle consecutive data in one part, so storing the two forks is messy. That's why it's common to convert a Macintosh file into some other format before sending it over the network 📦

AppleDouble file format [APPL90], encoded in MIME as multipart/appledouble [FALT94] and application/applefile [FALT94], is the preferred format for a Macintosh file that's going into an Internet mail message 💖 It's the main character here, because Macintosh recipients get the entire document, including Icons and other Macintosh-specific info, while everyone else can easily pull out the Data fork (the actual data) 🌸

However, this spec also covers the currently popular BinHex4.0 encoding schemes, as a convenience for the installed base of users 🫶

2. MIME format for BinHex4.0 🎀

MIME-based Apple information is specified like this:

   MIME type-name:            APPLICATION
   MIME subtype name:         MAC-BINHEX40
   Required parameters:       none
   Optional parameters:       NAME, which MUST be a "value" as
                              defined in RFC-1521 [BORE93].
   Encoding considerations:   none
   Security considerations:   See separate section in the document
   Published specification:   Appendix A
   Rationale:                 Permits MIME-based transmission of data
                              with Apple Macintosh file system specific
                              information using a currently popular,
                              though platform specific, format.

2a. Detail specific to MIME-based usage 💅

Macintosh documents don't always need a special format 🌈 Documents with well-known MIME types and non-existent or trivial resource forks can be sent as regular MIME body parts, without AppleSingle, AppleDouble, or BinHex4.0.

Documents that lack a data fork MUST be sent as AppleSingle according to RFC 1740 [FALT94]. No exceptions, bestie 🙅‍♀️

Unless there are strong reasons not to, all other documents SHOULD be sent as AppleDouble according to RFC 1740 [FALT94]. That includes documents with non-trivial resource forks, and documents without corresponding well-known MIME types 🔥

It MAY be valuable in some cases to let the user choose one format over another, either because they disagree with the implementor's definition of "trivial" resource forks, or for reasons of their own 🦋

Only when available software and/or user practice dictates, SHOULD BinHex 4.0 be employed 🙈

3. BinHex 🦋

BinHex 4.0 is a popular way of encoding Macintosh files for archiving on non-Macintosh file systems and for sending through Internet mail 💖 (See Appendix A for a brief description of the BinHex 4.0 format.)

The content-type application/mac-binhex40 tells you the body of the mail is a BinHex4.0 file ✨ Even though BinHex characters aren't the same as the ones used in Base64 (the ones regarded as safe according to RFC-1521 [BORE93]), a transportation encoding SHOULD NOT be done. Ngl, that's a plot twist 💀

Even though a BinHex file already includes the original Macintosh filename, it is RECOMMENDED that a name parameter be included on the Content-Type header. It gives the recipient a hint about what file is attached 🫶 The value of the name parameter MUST be a "value" as defined by RFC-1521 [BORE93]. Note that this limits the value to seven-bit US-ASCII characters 🌸

3a. BinHex example 🧚

Content-Type: application/mac-binhex40; name="car.hqx"

    [The BinHex4.0 file goes here]

4. References 📚

• [APPL90] AppleSingle/AppleDouble Formats for Foreign Files, Developer's Note, Apple Computer, Inc., 1990.
• [FALT94] Faltstrom P., Crocker, D., and E. Fair, "MIME Encapsulation of Macintosh Files - MacMIME", RFC 1740, KTH, Brandenburg Consulting, Apple Computer Inc., December 1994.
• [BORE93] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993.

5. Security Considerations 🔐

This part is serious, bestie 😭 To the extent that application/mac-binhex40 makes it easier to transmit operating-system sensitive data, it may open a door to looser security rules than the sender or the administrator of the sender's system intends. Please keep this in mind 🚨

6. Acknowledgements 🫶

Huge thanks to everyone on the ietf-822 list who gave so much meaningful input for this document 💜 A few people have to be named, because they practically crushed the author's mailbox over the last few weeks with a very nice and interesting debate 😭

Johan Berglund, Steve Dorner, David Gelhar, David Herron, Raymond Lau, Jamey Maze, John B. Melby, Jan Michael Rynning, Rens Troost, and Peter Svanberg.

7. Authors' Addresses 💌

   Patrik Faltstrom
   Department of Numerical Analysis and Computing Science
   Royal Institute of Technology
   S-100 44 Stockholm
   Sweden

   EMail: paf@nada.kth.se


   Dave Crocker
   Brandenburg Consulting
   675 Spruce Dr.
   Sunnyvale, CA  94086

   EMail: dcrocker@mordor.stanford.edu


   Erik E. Fair
   Engineering Computer Operations
   Apple Computer Inc.

   EMail: fair@apple.com

---

Appendix A. The BinHex format 🧚‍♀️

Here's a description of the Hqx7 (7 bit format as implemented in BinHex 4.0) formats for Macintosh Application and File transfers 🍓

The main features of the format are:

1. Error checking even using ASCII download
2. Compression of repetitive characters
3. 7 bit encoding for ASCII download

The format is processed at three different levels:

1. 8 bit encoding of the file:

   Byte:    Length of FileName (1->63)
   Bytes:   FileName ("Length" bytes)
   Byte:    Version
   Long:    Type
   Long:    Creator
   Word:    Flags (And $F800)
   Long:    Length of Data Fork
   Long:    Length of Resource Fork
   Word:    CRC
   Bytes:   Data Fork ("Data Length" bytes)
   Word:    CRC
   Bytes:   Resource Fork ("Rsrc Length" bytes)
   Word:    CRC

2. Compression of repetitive characters.

$90 is the marker, and encoding is made for 3->255 characters 🌸

   00 11 22 33 44 55 66 77   -> 00 11 22 33 44 55 66 77
   11 22 22 22 22 22 22 33   -> 11 22 90 06 33
   11 22 90 33 44            -> 11 22 90 00 33 44

The whole file is considered as a stream of bits. That stream gets divided into blocks of 6 bits, and each block is converted to one of 64 characters in a table. The characters in this table were chosen for maximum noise protection 🛡️ The format starts with a ":" (first character on a line) and ends with a ":". There's a maximum of 64 characters on a line. The file MUST be preceded, by this comment, starting in column 1 (it does not start in column 1 in this document):

    (This file must be converted with BinHex 4.0)

Any text before this comment is to be ignored 🙈

The characters used are:

    !"#$%&'()*+,- 012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr