rfc1740.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 900 行 · 第 1/3 页

Network Working Group                                   Patrik Faltstrom
Request for Comments: 1740                 Royal Institute of Technology
Category: Standards Track                                   Dave Crocker
                                                  Brandenburg Consulting
                                                            Erik E. Fair
                                                     Apple Computer Inc.
                                                           December 1994


            MIME Encapsulation of Macintosh files - MacMIME

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This memo describes the format to use when sending Apple Macintosh
   files via MIME [BORE93].  The format is compatible with existing
   mechanisms for distributing Macintosh files, while allowing non-
   Macintosh systems access to data in standardized formats.

2.  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 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 1740                  MIME-based Mac files             December 1994


   The two styles of use are [APPL90]:

   AppleSingle:   Apple's standard format for encoding Macintosh files
                  as one byte stream.
   AppleDouble:   Similar to AppleSingle except that the Data fork is
                  separated from the Macintosh-specific parts by the
                  AppleDouble encoding.

   AppleDouble 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) as it is separated
   from the AppleDouble encoding.

2.  MIME format for Apple/Macintosh-specific file information

   2a.  APPLICATION/APPLEFILE

      MIME type-name:            APPLICATION
      MIME subtype name:         APPLEFILE
      Required parameters:       none
      Optional parameters:       NAME, which must be a "value" as
                                 defined in RFC-1521 [BORE93].
      Encoding considerations:   The presence of binary data will
                                 typically require use of
                                 Content-Transfer-Encoding: BASE64
      Security considerations:   See separate section in the document
      Published specification:   Apple-single & Apple-double [APPL90]
      Rationale:                 Permits MIME-based transmission of
                                 data with Apple/Macintosh specific
                                 information, while allowing general
                                 access to non-specific user data.

   2b.  MULTIPART/APPLEDOUBLE

      MIME type-name:            MULTIPART
      MIME subtype name:         APPLEDOUBLE
      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:   Apple-single & Apple-double [APPL90]
      Rationale:                 Permits MIME-based transmission of
                                 data with Apple/Macintosh specific
                                 information, while allowing general
                                 access to non-specific user data.



Faltstrom, Crocker & Fair                                       [Page 2]

RFC 1740                  MIME-based Mac files             December 1994


   2c.  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 or AppleDouble.

      Documents which lack a data fork must be sent as AppleSingle.

      Unless there are strong reasons not to, all other documents
      should normally be sent as AppleDouble.  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.

3.  AppleSingle

   An AppleSingle, version 2 file, is sent as one consecutive stream of
   bytes.  The format is described in [APPL90] with a brief summary in
   Appendix A. The one and only part of the file is sent in an
   application/applefile message.

   The first four bytes of an AppleSingle header are, in hexadecimal:
   00, 05, 16, 00.

   The AppleSingle file is binary data.  Hence, it may be necessary to
   perform a Content-Transfer-Encoding for transmission, depending on
   the underlying email transport environment.  The safest encoding is
   Base64, since it permits transfer over the most restricted channels.

   Even though an AppleSingle 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.  AppleSingle example

      Content-Type: application/applefile; name="Computers-1/2-93"

          [The AppleSingle file goes here]

4.  AppleDouble



Faltstrom, Crocker & Fair                                       [Page 3]

RFC 1740                  MIME-based Mac files             December 1994


   An AppleDouble, version 2, file is divided in two parts:

   Header:      including the Macintosh resource fork and desktop
                information and
   Data fork:   containing the Macintosh data fork.

   The AppleDouble format is described in [APPL90] with a brief summary
   in Appendix B.

   The AppleDouble file itself is sent as a multipart/appledouble MIME
   body-part, which may have only two sub-parts.  The header is sent as
   application/applefile and the data fork as whatever best describes
   it.  For example, is the data for is actually a GIF image, it should
   be sent as image/gif.  If no appropriate Content-Type has been
   registered for the data type, it should be sent as an
   application/octet-stream.

   The first four bytes of an AppleDouble header are, in hexadecimal:
   00, 05, 16, 07.

   The AppleDouble header is binary data.  Hence, it may be necessary to
   perform a Content-Transfer-Encoding for transmission, depending on
   the underlying email transport environment.  The safest encoding is
   Base64, since it permits transfer over the most restrictive channels.

   Even though an AppleDouble file includes the original Macintosh
   filename, it is recommended that a name parameter be included on the
   Content-Type header of both the header and data parts of the
   AppleDouble file 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.

   4a.  AppleDouble example

      Content-Type: multipart/appledouble; boundary=mac-part

      --mac-part
      Content-Type: application/applefile; name="My-new-car"

          [The AppleDouble header goes here]

      --mac-part
      Content-Type: image/gif;

          [The data fork goes here]

      --mac-part--



Faltstrom, Crocker & Fair                                       [Page 4]

RFC 1740                  MIME-based Mac files             December 1994


5.  References

   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.

   APPL90   AppleSingle/AppleDouble Formats for Foreign Files
            Developer's Note, Apple Computer, Inc., 1990

6.  Security Considerations

   To the extent that application/applefile 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.

7.  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 with
   a very nice and interesting debate:

      Johan Berglund, Steve Dorner, David Gelhar, David Herron, Lee
      Jones, Raymond Lau, Jamey Maze, John B. Melby, Jan Michael
      Rynning, Rens Troost and Peter Svanberg.

10.  Authors' Addresses

   Patrik Faltstrom
   Department of Numerical Analysis and Computing Science
   Royal Institute of Technology
   S-100 44 Stockholm
   Sweden

   EMail: [e-mail]


   Dave Crocker
   Brandenburg Consulting
   675 Spruce Dr.
   Sunnyvale, CA  94086

   EMail: [e-mail]


   Erik E. Fair



Faltstrom, Crocker & Fair                                       [Page 5]

RFC 1740                  MIME-based Mac files             December 1994


   Engineering Computer Operations
   Apple Computer Inc.

   EMail: [e-mail]