doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc1741.txt b/doc/rfc/rfc1741.txt
new file mode 100644
index 0000000..46276b2
--- /dev/null
+++ b/doc/rfc/rfc1741.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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]
+