idnits 2.17.1 draft-newman-macbin-binhex-harmful-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1996) is 10147 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'FALT94' is mentioned on line 74, but not defined == Missing Reference: 'RFC 1740' is mentioned on line 82, but not defined ** Downref: Normative reference to an Informational RFC: RFC 1741 -- Possible downref: Non-RFC (?) normative reference: ref. 'APPL90' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft: MacBinary and Binhex 4.0 harmful Carnegie Mellon 4 Document: draft-newman-macbin-binhex-harmful-00.txt July 1996 6 MacBinary and Binhex 4.0 considered harmful 8 Status of this memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 andrewDrafts as reference material or to cite them other than as a 19 ``working draft'' or ``work in progress``. 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 A revised version of this draft document will be submitted to the 27 RFC editor as a Proposed Standard for the Internet Community. 28 Discussion and suggestions for improvement are requested. This 29 document will expire six months after publication. Distribution of 30 this draft is unlimited. 32 1. Introduction 34 The two most popular formats for encoding Macintosh files are 35 MacBinary and Macintosh Binhex 4.0 [RFC1741]. Both of these 36 formats have serious flaws which hinder interoperability of email 37 and file exchange over the Internet. This document recommends the 38 use of AppleSingle or AppleDouble, encoded via MIME if necessary 39 [RFC1740, APPL90]. 41 2. Interoperability problems with Binhex 4.0 43 Binhex 4.0 has five major flaws: 45 1) It is significantly more complex than any other Macintosh file 46 encoding. Specificly, it includes a four-layer encoding process 47 (CRC error detection, inclusion of some file meta data, a simple 48 run length encoder which is rarely implemented, and an 8-to-7 bit 49 encoder) and in most cases only some of the layers are needed. 51 2) The inclusion of a mandatory 8-to-7 bit encoding makes it waste 52 bandwidth when used over an 8-bit safe communications channel. 54 3) Some of the characters in the 7-bit character set are known to 55 be corrupted by some email gateways, unlike MIME's base64 encoding. 57 4) The format does not allow inclusion of all the meta data 58 associated with a Macintosh file (e.g. the finder comments and 59 custom icons) and is not extensible. 61 5) The data fork is embedded in the rest of the file in such a way 62 that it is difficult to extract on any non-Macintosh platform. 64 For these reasons, this author recommends that Binhex 4.0 only be 65 used when sending files through email to a Macintosh owner without 66 an Internet connection. In all other cases, AppleSingle or MacMIME 67 provide superior functionality. 69 Some software vendors have ignored the following important 70 statement in RFC 1741: 72 "Only when available software and/or user practice dictates, should 73 this method be employed. It is recommended to use 74 application/applefile [FALT94] for maximum interoperability." 76 Any mailer which uses Binhex 4.0 as its default encoding for email 77 interchange is violating this clause in RFC 1741 and is creating 78 serious interoperability problems in the Internet. Users which 79 receive such mis-encoded files and are unable to decode them should 80 complain to the sender who can in turn complain to their software 81 vendor and repair their default configuration to use standard 82 MacMIME [RFC 1740]. 84 3. Interoperability problems with MacBinary 86 MacBinary has four flaws which forced Apple Computer, Inc. [APPL90] 87 to design a new file format: 89 1) It has no magic number (a fixed sequence of bytes at the 90 beginning of the file which can be used to identify the file type) 91 which makes it difficult to distinguish from other files. 93 2) The format does not allow inclusion of all the meta data 94 associated with a Macintosh file and is not extensible. 96 3) The data fork is embedded in the rest of the file in such a way 97 that it is difficult to extract on any non-Macintosh platform. 99 4) The common extension ".bin" is easily confused with generic 100 binary files. 102 4. Advantages of AppleSingle/AppleDouble 104 AppleSingle and AppleDouble are simple file formats. Both have 105 magic numbers allowing quick identification by programs such as 106 Fetch. Both include all current Macintosh file meta data and are 107 extensible for the future. Both are simple formats. The 108 AppleDouble format allows trivial extraction of the data fork, 109 while it is simple to extract it from AppleSingle. When 110 AppleDouble is encoded in MIME via MacMIME, cross-platform file 111 interchange works without any special Macintosh knowledge and other 112 MIME services may be used for transport encoding and integrity 113 verification. In short, AppleSingle/AppleDouble correct all the 114 flaws in Binhex 4.0 and MacBinary. 116 5. Adoption of AppleSingle for FTP archives 118 While MacMIME has been actively gaining support in the Internet, 119 use of AppleSingle for ftp archives has languished, even though the 120 most popular Macintosh ftp client (Fetch) automatically detects and 121 decodes AppleSingle. This author believes the problem is simply 122 that no common extension has been adopted for AppleSingle files. 123 This document proposes that the extension ".asf" (AppleSingle File) 124 be used to visually distinguish AppleSingle files from other files 125 when necesssary. 127 6. Conclusion 129 Binhex 4.0 and MacBinary are seriously flawed encodings of 130 Macintosh files which should be avoided for use on the Internet. 131 Adoption of AppleSingle and MacMIME for exchange of Macintosh files 132 over the Internet will improve efficiency and interoperability. In 133 addition, because AppleSingle can encode all Macintosh file meta- 134 data, including custom icons and finder comments it will improve 135 the Macintosh user experience on the Internet. 137 7. References 139 [RFC1740] Faltstrom P., Crocker, D., and E. Fair, "MIME 140 Encapsulation of Macintosh Files - MacMIME", RFC 1740, 141 KTH, Brandenburg Consulting, Apple Computer Inc., 142 December 1994. 144 [RFC1741] Faltstrom P., Crocker, D., and E. Fair, "MIME Content 145 Type for BinHex Encoded Files", RFC 1741, KTH, 146 Brandenburg Consulting, Apple Computer Inc., December 147 1994. 149 [APPL90] AppleSingle/AppleDouble Formats for Foreign Files 150 Developer's Note, Apple Computer, Inc., 1990 152 8. Security Considerations 154 There are no known security issues in this memo. 156 9. Author's Address 158 Chris Newman 159 Carnegie Mellon University 160 5000 Forbes Ave. 161 Pittsburgh, PA 15213-3890 163 Email: chrisn+@cmu.edu