doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc2159.txt b/doc/rfc/rfc2159.txt
new file mode 100644
index 0000000..148b188
--- /dev/null
+++ b/doc/rfc/rfc2159.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                  H. Alvestrand
+Request for Comments: 2159                                   UNINETT
+Category: Standards Track                               January 1998
+
+
+                        A MIME Body Part for FAX
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+1.  Introduction
+
+   This document contains the definitions, originally contained in RFC
+   1494, on how to carry CCITT G3Fax in MIME, and how to translate it to
+   its X.400 representation.
+
+   NOTE: At the moment, this format does not seem appropriate for a
+   "general purpose image format for the Internet", if such a beast can
+   exist. It exists only to carry information that is already in G3 Fax
+   format, and may be usefully converted to other formats when used in
+   specific contexts.
+
+2.  The image/g3fax content-type
+
+   This content-type is defined to carry G3 Facsimile byte streams.
+
+   In general, a G3Fax image contains 3 pieces of information:
+
+     (1)   A set of flags indicating the particular coding scheme.
+           CCITT Recommendation T.30 defines how the flags are
+           transmitted over telephones.  In this medium, the flags are
+           carried as parameters in the MIME content-type header
+           field.
+
+     (2)   A structure that divides the bits into pages.  CCITT
+           recommendation T.4 describes a "return to command mode"
+           string; this is used here to indicate page breaks.
+
+
+
+
+
+Alvestrand                  Standards Track                     [Page 1]
+
+RFC 2159                 MIME Body Part for FAX             January 1998
+
+
+     (3)   For each page, a sequence of bits that form the encoding of
+           the image.  CCITT recommendation T.4 defines the bit image
+           format.  This is used without change.  The highest bit of
+           the first byte is the first bit of the T.4 bitstream.
+
+2.1.  G3Fax Parameters
+
+   The following parameters are defined:
+
+      (1)   page-length - possible values: A4, B4 and Unlimited
+
+      (2)   page-width - possible values: A3, A4, B4
+
+      (3)   encoding - possible values: 1-dimensional, 2-dimensional,
+            Uncompressed
+
+      (4)   resolution - possible values: Fine, Coarse
+
+      (5)   DCS - a bit string, represented in Base64.
+
+      (6)   pages - an integer, giving the number of pages in the
+            document
+
+   If nothing is specified, the default parameter settings are:
+
+      page-length=A4
+      page-width=A4
+      encoding=1-dimensional
+      resolution=Coarse
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alvestrand                  Standards Track                     [Page 2]
+
+RFC 2159                 MIME Body Part for FAX             January 1998
+
+
+   It is possible (but misleading) to view the representation of these
+   values as single-bit flags. They correspond to the following bits of
+   the T.30 control string and X.400 G3FacsimileParameters:
+
+       Parameter               T.30 bit        X.400 bit
+
+       page-length=A4             no bit set
+       page-length=B4          19              21
+       page-length=Unlimited   20              20
+
+       page-width=A4              no bit set
+       page-width=A3           18              22
+       page-width=B4           17              23
+
+       encoding=1-dimensional     no bit set
+       encoding=2-dimensional  16              8
+       encoding=Uncompressed   26              30
+
+       resolution=Coarse          no bit set
+       resolution=Fine         15              9
+
+   The reason for the different bit numbers is that X.400 counts bits in
+   an octet from the MSB down to the LSB, while T.30 uses the opposite
+   numbering scheme.
+
+   If any bit but these are set in the Device Control String, the DCS
+   parameter should be supplied.
+
+2.2.  Content Encoding
+
+   X.400 defines the g3-facsimile data stream as a SEQUENCE of BIT
+   STRINGs. Each BIT STRING is a page of facsimile image data, encoded
+   as defined by Recommendation T.4.  The following content encoding is
+   reversible between MIME and X.400 and ensures that page breaks are
+   honored in the MIME representation.
+
+   An EOL is defined as a bit sequence of
+
+       000000000001 (eleven zeroes and a one).
+
+
+   Each page of the message is delimited by a sequence of six (6) EOLs
+   that MUST start on a byte boundary.  The image bit stream is padded
+   with zeroes as needed to achieve this alignment.
+
+   Searching for the boundary is a matter of searching for the byte
+   sequence (HEX) 00 10 01 00 10 01 00 10 01, which cannot occur inside
+   the image.
+
+
+
+Alvestrand                  Standards Track                     [Page 3]
+
+RFC 2159                 MIME Body Part for FAX             January 1998
+
+
+   See Section 7.5 for the algorithm on conversion between this encoding
+   and the X.400 encoding.
+
+   The Base64 content-transfer-encoding is appropriate for carrying this
+   content-type.
+
+3.  g3-facsimile - image/g3fax
+
+   X.400 Body part: g3-facsimile
+   MIME Content-Type: image/g3fax
+   Conversion Type: nearly Byte copy
+   Comments:
+
+   The Parameters of the X.400 G3Fax body part are mapped to the
+   corresponding Parameters on the MIME Image/G3Fax body part and vice
+   versa.  Note that:
+
+      (1)   If fineResolution is not specified, pixels will be twice as
+            tall as they are wide
+
+      (2)   If any bit not corresponding to a specially named option is
+            set in the G3Fax NonBasicParameters, the "DCS" parameter
+            must be used.
+
+      (3)   Interworking is not guaranteed if any bit apart from those
+            specially named are used in the NonBasicParameters
+
+   From X.400 to G3Fax, the body is created in the following way:
+
+      (1)   Any trailing EOL markers on each bitstring is removed. The
+            bit order is changed to conform to the most common Internet
+            encoding (highest bit of first byte = first bit of the
+            G3Fax). The bitstring is padded to a byte boundary.
+
+      (2)   6 consecutive EOL markers are appended to each bitstring.
+
+      (3)   The padded bitstrings are concatenated together
+
+   An EOL marker is the bit sequence 000000000001 (11 zeroes and a
+   one).
+
+   From G3Fax to X.400, the body is created in the following way:
+
+      (1)   The body is split into bitstrings at each occurrence of 6
+            consecutive EOL markers. Trailing EOLs must NOT be removed,
+            since the X.400 Implementor Guide recommends that each page
+            should end with 6 consecutive EOLs.  (This is a change from
+            RFC 1494).
+
+
+
+Alvestrand                  Standards Track                     [Page 4]
+
+RFC 2159                 MIME Body Part for FAX             January 1998
+
+
+      (2)   Each bitstring is made into an ASN.1 BITSTRING, reversing
+            the order of bits within each byte to conforom to the X.400
+            Implementors Guide recommendation for bit order in the
+            G3Fax body part.
+
+      (3)   The bitstrings are made into an ASN.1 SEQUENCE, which forms
+            the body of the G3Fax body part.
+
+4.  Usability of G3Fax body parts
+
+   This section is not part of the proposed standard, but is intended as
+   guidance for people implementing G3Fax handling, so that they know a
+   little about what to expect.
+
+   The DCS bitstring is a LONG thing; the T.30 Recommendation (1993)
+   gives 67 bits with specific functions, SG8 Report R33 extends this to
+   75 bits, and Report R41 (approved in 1995) extends it to 79 bits.
+   (For curiosity - bit 68 says that the coding is JPEG; bit 27 is
+   "error correcting mode). No sane implementor will send such things
+   without being able to negotiate them down if the recipient doesn't
+   support it, but there is no guarantee that messages with such bits
+   set in the DCS won't arrive through X.400.
+
+   The ISO P2 profile from 1995 [PROFILE] says that the profile makes
+   support for reception of two-dimensional and fine-resolution
+   mandatory if g3-facsimile is supported at all. Research by Andrew
+   Gordon of Net-Tel indicates that it is easy for an access unit to
+   support fine resolution, unlimited length and B4 length, while
+   support for B4 width is nearly impossible, and A3 width is hard.
+
+   Another interesting point is that some fax machines have trouble if
+   the scan lines do not contain exactly the declared number of pixels
+   on each scan line, so "omitting right-hand white space" is likely to
+   give trouble.
+
+5.  Security Considerations
+
+   There are no known security issues specific to the FAX body part.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alvestrand                  Standards Track                     [Page 5]
+
+RFC 2159                 MIME Body Part for FAX             January 1998
+
+
+6.  References
+
+   [MIME]
+       Freed, N., and N. Borenstein, "Multipurpose Internet Mail
+       Extensions (MIME) Part One: Format of Internet Message Bodies",
+       RFC 2045, November 1996.
+
+   [GUIDE]
+       X.400 Implementor's Guide, version 8.
+
+   [PROFILE]
+       ISO/IEC ISP 12062-2: 1995:
+
+   [T.30]
+       ITU-T Recommendation T.30 (1993): Procedures for document
+       facsimile transmission in the general switched telephone network.
+
+7. Author's Address
+
+   Harald Tveit Alvestrand
+   UNINETT
+   P.O.box 6883 Elgeseter
+   N-7002 Trondheim
+   NORWAY
+
+   EMail: Harald.T.Alvestrand@uninett.no
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alvestrand                  Standards Track                     [Page 6]
+
+RFC 2159                 MIME Body Part for FAX             January 1998
+
+
+8.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alvestrand                  Standards Track                     [Page 7]
+