GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1741

Network Working Group P. Faltstrom Request for Comments: 1741 Royal Institute of Technology Category: Informational D. Crocker

                                                Brandenburg Consulting
                                                               E. Fair
                                                   Apple Computer Inc.
                                                         December 1994
             MIME Content Type for BinHex Encoded Files

Status of this Memo

 This memo provides information for the Internet community.  This memo
 does not specify an Internet standard of any kind.  Distribution of
 this memo is unlimited.

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 [FALT94] for maximum
 interoperability.

1. 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] RFC 1741 Content Type for BinHex Files December 1994

 AppleDouble file format [APPL90], encoded in MIME as
 multipart/appledouble [FALT94] and application/applefile [FALT94] 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.

2. 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.
 2a.  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 [FALT94].
    Unless there are strong reasons not to, all other documents should
    be sent as AppleDouble according to RFC 1740 [FALT94].  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] RFC 1741 Content Type for BinHex Files December 1994

    Only when available software and/or user practice dictates, should
    BinHex 4.0 be employed.

3. 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.
 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.

Faltstrom, Crocker & Fair [Page 3] RFC 1741 Content Type for BinHex Files December 1994

5. 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
 the sender of the administrator of the sender's system.

6. 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,
    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

Faltstrom, Crocker & Fair [Page 4] RFC 1741 Content Type for BinHex Files December 1994

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):

Faltstrom, Crocker & Fair [Page 5] RFC 1741 Content Type for BinHex Files December 1994

  (This file must be converted with BinHex 4.0)
 Any text before this comment is to be ignored.
 The characters used is:
  !"#$%&'()*+,- 012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr

Faltstrom, Crocker & Fair [Page 6]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1741.txt · Last modified: 1994/12/20 23:41 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki