A MIME Body Part for FAX
RFC 2159

Document Type RFC - Proposed Standard (January 1998; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2159 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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]
Show full document text