GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2159

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2159.txt · Last modified: 1998/01/07 21:51 (external edit)