Internet DRAFT - draft-falstrom-macmime2-v2
draft-falstrom-macmime2-v2
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:50:45 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Thu, 23 Nov 1995 23:00:00 GMT
ETag: "2e9920-297b-30b4fcf0"
Accept-Ranges: bytes
Content-Length: 10619
Connection: close
Content-Type: text/plain
Network Working Group Patrik Faltstrom
Internet Draft: draft-faltstrom-macmime2-v2 Bunyip Information Systems Inc.
Category: Informational Dave Crocker
Expires in six months Brandenburg Consulting
Erik E. Fair
Apple Computer Inc.
November 22, 1995
MIME Content Type for BinHex encoded files
1. 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 at any timne. It is not appropriate to use
Internet Drafts as reference material or to cite them other than as
a "working draft" or "work in progress". Please check the
1idabstracts.txt listing contained in the internet-drafts Shadow
Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
ftp.nisc.sri.com, or munnari.oz.au to learn the current status of
any Internet Draft.
2. Abstract
This memo describes the format to use when sending BinHex4.0 files
via MIME [BORE93]. The format is compatible with existing
mechanisms for distributing Macintosh files. Only when available
software and/or user practice dictates, should this method be
employed. It is recommended to use application/applefile [FALT95]
for maximum interoperability.
3. Introduction
Files on the Macintosh consists 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.
Additional information regarding Macintosh files is stored by the
Finder has in a hidden file, called the "Desktop Database".
Because of the complications in storing different parts of a
Macintosh file in a non-Macintosh filesystem that only handles
consecutive data in one part, it is common to convert the Macintosh
file into some other format before transferring it over the network.
Faltstrom, Crocker & Fair [Page 1]
Internet Draft Content Type for BinHex files November 22, 1995
AppleDouble file format [APPL90], encoded in MIME as
multipart/appledouble [FALT95] and application/applefile [FALT95] is
the preferred format for a Macintosh file that is to be included in
an Internet mail message, because it provides recipients with
Macintosh computers the entire document, including Icons and other
Macintosh specific information, while other users easily can extract
the Data fork (the actual data).
However, this specification provides for use of the currently
popular BinHex4.0 encoding schemes, as a convinience to the
installed base of users.
4. MIME format for BinHex4.0
MIME-base Apple information is specified by:
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.
4a. Detail specific to MIME-based usage
Macintosh documents do not always need to be sent in a special
format. Those documents with well-known MIME types and
non-existent or trivial resource forks can be sent as regular
MIME body parts, without use of AppleSingle, AppleDouble or
BinHex4.0.
Documents which lack a data fork must be sent as AppleSingle
according to RFC 1740 [FALT95].
Unless there are strong reasons not to, all other documents
should be sent as AppleDouble according to RFC 1740 [FALT95].
This includes documents with non-trivial resource forks, and
documents without corresponding well-known MIME types.
It may be valuable in some cases to allow the user to choose one
format over another, either because he disagrees with the
implementor's definition of "trivial" resource forks, or for
reasons of his own.
Faltstrom, Crocker & Fair [Page 2]
Internet Draft Content Type for BinHex files November 22, 1995
Only when available software and/or user practice dictates,
should BinHex 4.0 be employed.
5. BinHex
BinHex 4.0 is a propular means of encoding Macintosh files for
archiving on non-Macintosh file systems and for transmission via
Internet mail. (See Appendix A for a brief description of the
BinHex 4.0 format.)
The content-type application/mac-binhex40 indicates that the body of
the mail is a BinHex4.0 file. Even though the BinHex encoding
consists of characters which are not the same as those used in
Base64 (those regarded as safe according to RFC-1521 [BORE93]) a
transportation encoding should not be done.
Even though a BinHex file includes the original Macintosh filename,
it is recommended that a name parameter be included on the
Content-Type header to give the recipient a hint as to what file is
attached. The value of the name parameter must be a "value" as
defined by RFC-1521 [BORE93]. Note that this restricts the value to
seven-bit US-ASCII characters.
5a. BinHex example
Content-Type: application/mac-binhex40; name="car.hqx"
[The BinHex4.0 file goes here]
6. References
APPL90 AppleSingle/AppleDouble Formats for Foreign Files
Developer's Note, Apple Computer, Inc., 1990
FALT95 Faltstrom P., D. Crocker, and E. Fair, MacMIME: Description
of the format to use when sending Macintosh files with MIME
[BORE93], RFC 1740, Bunyip, UDEL, Apple, November 1995.
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.
7. Security Considerations
To the extent that application/mac-binhex40 facilitates the
transmission of operating-system sensitive data, it may open a door
for easier relaxation of security rules than is intended either by
Faltstrom, Crocker & Fair [Page 3]
Internet Draft Content Type for BinHex files November 22, 1995
the sender of the administrator of the sender's system.
8. Acknowledgements
Thanks to all of the people on the ietf-822 list who have provided
much meaningful input for this document. Some of them must though
be remembered by name, because they have almost crushed my mailbox
the last 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, Peter Svanberg
9. Authors Addresses
Patrik Faltstrom
Bunyip Information Systems inc.
Suite 300
310 Ste-Catherine St. West Montreal, Quebec
CANADA H2X 2A1
Email: paf@bunyip.com
Dave Crocker
Brandenburg Consulting
675 Spruce. Dr.
Sunnyvale, CA 94086
USA
Email: dcrocker@mordor.stanford.edu
Erik E. Fair
Engineering Computer Operations
Apple Computer Inc.
Email: fair@apple.com
Faltstrom, Crocker & Fair [Page 4]
Internet Draft Content Type for BinHex files November 22, 1995
Appendix A. The BinHex format
Here is 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, 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. This stream will
be divided in blocks of 6 bits and then converted to one of 64
characters contained in a table. The characters in this table have
been chosen for maximum noise protection. The format will start
with a ":" (first character on a line) and end with a ":".
There will be a maximum of 64 characters on a line. It 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)
Faltstrom, Crocker & Fair [Page 5]
Internet Draft Content Type for BinHex files November 22, 1995
Any text before this comment is to be ignored.
The characters used is:
!"#$%&'()*+,- 012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr
Faltstrom, Crocker & Fair [Page 6]
