A MIME Body Part for FAX
How to carry a Group 3 fax inside a MIME email message, and map it to and from X.400.
Alvestrand, H., "A MIME Body Part for FAX", RFC 2159, DOI 10.17487/RFC2159, January 1998, <https://www.rfc-editor.org/info/rfc2159>.
@misc{rfc2159,
series = {Request for Comments},
number = 2159,
howpublished = {RFC 2159},
publisher = {RFC Editor},
doi = {10.17487/RFC2159},
url = {https://www.rfc-editor.org/info/rfc2159},
author = {H. Alvestrand},
title = {{A MIME Body Part for FAX}},
pagetotal = 7,
year = 1998,
month = jan,
} RFC text
Contents
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.
(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
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.
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).
(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.
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
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.
AI ELI5
On this page
§1Why a Fax Body Part
RFC 2159 holds the definitions, originally in RFC 1494, on how to carry CCITT G3Fax in MIME and how to translate it to its X.400 representation.
The author adds a warning. The format does not seem appropriate as a general purpose image format for the Internet. It exists only to carry information that is already in G3 Fax format, which may be usefully converted to other formats in specific contexts.
This is a way to mail a fax as it is, not a new picture format. If you want a normal picture, convert it afterwards.
§2The image/g3fax Content-Type
The image/g3fax content-type carries G3 Facsimile byte streams. A G3Fax image holds three pieces of information.
- Flags that say which coding scheme is used. T.30 defines how they are sent over telephones; here they are parameters in the MIME content-type header field.
- A structure that divides the bits into pages. The T.4 "return to command mode" string marks page breaks.
- For each page, the bits that encode the image. T.4 defines this bit image format and it is used without change. The highest bit of the first byte is the first bit of the T.4 bitstream.
A fax in an email has three parts: a list of settings, a mark between pages, and the dots that make up each page.
§2.1G3Fax Parameters
Six parameters are defined.
page-length: A4, B4 or Unlimited.page-width: A3, A4 or B4.encoding: 1-dimensional, 2-dimensional or Uncompressed.resolution: Fine or Coarse.DCS: a bit string, represented in Base64.pages: an integer giving the number of pages in the document.
If nothing is specified, the defaults are page-length A4, page-width A4, 1-dimensional encoding and Coarse resolution.
The values can be viewed as single-bit flags, which the RFC calls possible but misleading. They map to bits of the T.30 control string and of the X.400 G3FacsimileParameters. X.400 counts bits in an octet from the most significant bit down, while T.30 uses the opposite numbering, so the numbers differ. If any other bit is set in the Device Control String, the DCS parameter should be supplied.
The settings say how big the paper is, how the dots are squeezed, and how sharp the picture is. If nothing is said, plain defaults are used.
- page-length=B4T.30 bit 19, X.400 bit 21 — A4 sets no bit.
- page-length=UnlimitedT.30 bit 20, X.400 bit 20 — Page length is unlimited.
- page-width=A3T.30 bit 18, X.400 bit 22 — A4 sets no bit.
- page-width=B4T.30 bit 17, X.400 bit 23 — B4 page width.
- encoding=2-dimensionalT.30 bit 16, X.400 bit 8 — 1-dimensional sets no bit.
- encoding=UncompressedT.30 bit 26, X.400 bit 30 — No compression.
- resolution=FineT.30 bit 15, X.400 bit 9 — Coarse sets no bit.
§2.2Content Encoding and Page Breaks
X.400 defines the g3-facsimile data stream as a SEQUENCE of BIT STRINGs, one per page. The MIME encoding is reversible with it and makes sure page breaks are honored.
An EOL is the bit sequence 000000000001 (eleven zeroes and a one). Each page is delimited by a sequence of six EOLs that MUST start on a byte boundary. The image bit stream is padded with zeroes as needed to achieve that alignment.
To find a page boundary, search for the byte sequence (hex) 00 10 01 00 10 01 00 10 01, which cannot occur inside the image. The Base64 content-transfer-encoding is appropriate for carrying this content-type.
Between pages there is a special row of six marker beeps. The padding makes sure the marker starts at a clean spot, so it is easy to find.
§3Converting To and From X.400
The X.400 body part is g3-facsimile and the MIME type is image/g3fax. The conversion type is nearly a byte copy, and the X.400 parameters map to the MIME parameters and back.
Going from X.400 to G3Fax: trailing EOL markers on each bitstring are removed, the bit order is changed so the highest bit of the first byte is the first bit, and the bitstring is padded to a byte boundary. Six consecutive EOL markers are appended to each one, and the padded strings are concatenated.
Going from G3Fax to X.400: the body is split at each occurrence of six consecutive EOL markers. Trailing EOLs must NOT be removed, because the X.400 Implementor Guide recommends that each page end with six EOLs, a change from RFC 1494. Each piece becomes an ASN.1 BITSTRING with the bit order within each byte reversed, and the pieces form an ASN.1 SEQUENCE.
Two cautions apply. If fineResolution is not specified, pixels will be twice as tall as they are wide. If any bit without a specially named option is set in the NonBasicParameters, the DCS parameter must be used, and interworking is not guaranteed.
Turning a mailed fax into the other mail system's kind means cutting it at the six-marker spots, flipping the order of the dots in each byte, and stacking the pages in a list. Going back is the reverse.
§4Practical Guidance on Usability
This section is not part of the proposed standard. It is guidance for implementors.
The DCS bit string is long. 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. No sane implementor will send such things without being able to negotiate them down, but messages with such bits set could still arrive through X.400.
The ISO P2 profile from 1995 makes reception of two-dimensional and fine-resolution mandatory if g3-facsimile is supported at all. Research by Andrew Gordon of Net-Tel indicates that fine resolution, unlimited length and B4 length are easy for an access unit to support, B4 width is nearly impossible, and A3 width is hard. Some fax machines also have trouble if scan lines do not contain exactly the declared number of pixels, so omitting right-hand white space is likely to cause trouble.
Some fax settings are easy for a machine to handle and some are very hard. Machines should not skip the blank space at the end of a line, because some fax machines get confused.
§5Security Considerations
The RFC states only that there are no known security issues specific to the FAX body part. It adds no other security guidance.
The authors did not know of any special danger in mailing faxes this way.