[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/