Network Working Group C. Newman Internet Draft: MacBinary and Binhex 4.0 harmful Carnegie Mellon Document: draft-newman-macbin-binhex-harmful-00.txt July 1996 MacBinary and Binhex 4.0 considered harmful Status of this memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet andrewDrafts as reference material or to cite them other than as a ``working draft'' or ``work in progress``. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire six months after publication. Distribution of this draft is unlimited. 1. Introduction The two most popular formats for encoding Macintosh files are MacBinary and Macintosh Binhex 4.0 [RFC1741]. Both of these formats have serious flaws which hinder interoperability of email and file exchange over the Internet. This document recommends the use of AppleSingle or AppleDouble, encoded via MIME if necessary [RFC1740, APPL90]. 2. Interoperability problems with Binhex 4.0 Binhex 4.0 has five major flaws: 1) It is significantly more complex than any other Macintosh file Newman July 9, 1996 [Page 1]
Internet Draft MacBinary and Binhex 4.0 harmful July 1996 encoding. Specificly, it includes a four-layer encoding process (CRC error detection, inclusion of some file meta data, a simple run length encoder which is rarely implemented, and an 8-to-7 bit encoder) and in most cases only some of the layers are needed. 2) The inclusion of a mandatory 8-to-7 bit encoding makes it waste bandwidth when used over an 8-bit safe communications channel. 3) Some of the characters in the 7-bit character set are known to be corrupted by some email gateways, unlike MIME's base64 encoding. 4) The format does not allow inclusion of all the meta data associated with a Macintosh file (e.g. the finder comments and custom icons) and is not extensible. 5) The data fork is embedded in the rest of the file in such a way that it is difficult to extract on any non-Macintosh platform. For these reasons, this author recommends that Binhex 4.0 only be used when sending files through email to a Macintosh owner without an Internet connection. In all other cases, AppleSingle or MacMIME provide superior functionality. Some software vendors have ignored the following important statement in RFC 1741: "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." Any mailer which uses Binhex 4.0 as its default encoding for email interchange is violating this clause in RFC 1741 and is creating serious interoperability problems in the Internet. Users which receive such mis-encoded files and are unable to decode them should complain to the sender who can in turn complain to their software vendor and repair their default configuration to use standard MacMIME [RFC 1740]. 3. Interoperability problems with MacBinary MacBinary has four flaws which forced Apple Computer, Inc. [APPL90] to design a new file format: 1) It has no magic number (a fixed sequence of bytes at the beginning of the file which can be used to identify the file type) which makes it difficult to distinguish from other files. Newman July 9, 1996 [Page 2]
Internet Draft MacBinary and Binhex 4.0 harmful July 1996 2) The format does not allow inclusion of all the meta data associated with a Macintosh file and is not extensible. 3) The data fork is embedded in the rest of the file in such a way that it is difficult to extract on any non-Macintosh platform. 4) The common extension ".bin" is easily confused with generic binary files. 4. Advantages of AppleSingle/AppleDouble AppleSingle and AppleDouble are simple file formats. Both have magic numbers allowing quick identification by programs such as Fetch. Both include all current Macintosh file meta data and are extensible for the future. Both are simple formats. The AppleDouble format allows trivial extraction of the data fork, while it is simple to extract it from AppleSingle. When AppleDouble is encoded in MIME via MacMIME, cross-platform file interchange works without any special Macintosh knowledge and other MIME services may be used for transport encoding and integrity verification. In short, AppleSingle/AppleDouble correct all the flaws in Binhex 4.0 and MacBinary. 5. Adoption of AppleSingle for FTP archives While MacMIME has been actively gaining support in the Internet, use of AppleSingle for ftp archives has languished, even though the most popular Macintosh ftp client (Fetch) automatically detects and decodes AppleSingle. This author believes the problem is simply that no common extension has been adopted for AppleSingle files. This document proposes that the extension ".asf" (AppleSingle File) be used to visually distinguish AppleSingle files from other files when necesssary. 6. Conclusion Binhex 4.0 and MacBinary are seriously flawed encodings of Macintosh files which should be avoided for use on the Internet. Adoption of AppleSingle and MacMIME for exchange of Macintosh files over the Internet will improve efficiency and interoperability. In addition, because AppleSingle can encode all Macintosh file meta- data, including custom icons and finder comments it will improve the Macintosh user experience on the Internet. Newman July 9, 1996 [Page 3]
Internet Draft MacBinary and Binhex 4.0 harmful July 1996 7. References [RFC1740] Faltstrom P., Crocker, D., and E. Fair, "MIME Encapsulation of Macintosh Files - MacMIME", RFC 1740, KTH, Brandenburg Consulting, Apple Computer Inc., December 1994. [RFC1741] Faltstrom P., Crocker, D., and E. Fair, "MIME Content Type for BinHex Encoded Files", RFC 1741, KTH, Brandenburg Consulting, Apple Computer Inc., December 1994. [APPL90] AppleSingle/AppleDouble Formats for Foreign Files Developer's Note, Apple Computer, Inc., 1990 8. Security Considerations There are no known security issues in this memo. 9. Author's Address Chris Newman Carnegie Mellon University 5000 Forbes Ave. Pittsburgh, PA 15213-3890 Email: chrisn+@cmu.edu Newman July 9, 1996 [Page 4]