rfc-2159

A MIME Body Part for FAX

H. Alvestrand
date1998-01 streamIETF areaapp wgmixer statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc2159 doi10.17487/RFC2159
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. [STANDARDS-TRACK]

Extracted elements (19)

design-rationale §2.1

T.30 and X.400 use opposite bit numbering schemes within an octet: X.400 counts bits from MSB down to LSB, while T.30 uses the opposite. This explains why the same parameter maps to different bit numbers in each system.

email

design-rationale §1

This MIME type exists solely to carry information already in G3 Fax format for interworking purposes, and is not intended as a general-purpose Internet image format. The note explicitly cautions against treating it as such.

email

interoperability-note §2.2

Base64 content-transfer-encoding is the appropriate transfer encoding for carrying the image/g3fax content-type over MIME.

email

interoperability-note §3

If fineResolution is not specified, pixels will be twice as tall as they are wide. If any bit not corresponding to a specially named option is set in the G3Fax NonBasicParameters, the 'DCS' parameter must be used. Interworking is not guaranteed if any bit apart from those specially named are used in NonBasicParameters.

email

interoperability-note §4

Some fax machines have trouble if scan lines do not contain exactly the declared number of pixels, so omitting right-hand white space is likely to cause interoperability problems.

email

interoperability-note §4

The DCS bitstring can be up to 79 bits long (as of 1995 extensions). Messages with unusual DCS bits set (e.g., bit 68 for JPEG coding, bit 27 for error correcting mode) may arrive through X.400 without negotiation, so implementations must handle or ignore unknown DCS bits gracefully.

email

interoperability-note §4

The ISO P2 profile (1995) mandates support for reception of two-dimensional and fine-resolution G3 fax if g3-facsimile is supported at all. Fine resolution, unlimited length, and B4 length are easy for access units to support; B4 width is nearly impossible and A3 width is hard.

email

normative-requirement §2.2 MUST

Each page of the message MUST be 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.

email

normative-requirement §3 MUST NOT

When converting from G3Fax to X.400, 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.

email

protocol-element §3

Conversion from MIME image/g3fax to X.400: (1) body is split into bitstrings at each occurrence of six consecutive EOL markers, with trailing EOLs NOT removed (per X.400 Implementor Guide recommendation that each page end with six EOLs); (2) each bitstring becomes an ASN.1 BITSTRING with reversed bit order within bytes; (3) the SEQUENCE of BITSTRINGs forms the ASN.1 body.

email

protocol-element §3

Conversion from X.400 to MIME image/g3fax: (1) trailing EOL markers on each bitstring are removed, bit order is changed so highest bit of first byte is first G3Fax bit, and bitstring is padded to byte boundary; (2) six consecutive EOL markers are appended to each bitstring; (3) padded bitstrings are concatenated.

email

protocol-element §2.1

Default parameter settings when none are specified: page-length=A4, page-width=A4, encoding=1-dimensional, resolution=Coarse.

email

protocol-element §2.1

The image/g3fax content-type defines six parameters: page-length (A4, B4, Unlimited), page-width (A3, A4, B4), encoding (1-dimensional, 2-dimensional, Uncompressed), resolution (Fine, Coarse), DCS (a Base64-encoded bit string from T.30), and pages (integer count of pages in the document).

email

protocol-element §2

The image/g3fax MIME content-type carries G3 Facsimile byte streams. It encodes three pieces of information: a set of flags indicating the coding scheme (carried as MIME content-type parameters), a page-break structure using T.4 'return to command mode' strings, and per-page T.4 bit image data with the highest bit of the first byte being the first bit of the T.4 bitstream.

email

protocol-element §3

The X.400 g3-facsimile body part maps to MIME image/g3fax with nearly byte-copy conversion. X.400 G3Fax NonBasicParameters map directly to MIME image/g3fax parameters and vice versa.

email

security-consideration §5

There are no known security issues specific to the FAX body part (image/g3fax).

security, email

wire-format §2.2

An EOL (End-of-Line) marker is defined as the bit sequence 000000000001 (eleven zeroes and a one), as specified by T.4. Each page boundary is delimited by exactly six consecutive EOLs that MUST start on a byte boundary; the image bit stream is zero-padded as needed to achieve byte alignment.

email

wire-format §2.1

G3Fax parameters map to T.30 and X.400 bit positions: page-length=B4 is T.30 bit 19 / X.400 bit 21; page-length=Unlimited is T.30 bit 20 / X.400 bit 20; page-width=A3 is T.30 bit 18 / X.400 bit 22; page-width=B4 is T.30 bit 17 / X.400 bit 23; encoding=2-dimensional is T.30 bit 16 / X.400 bit 8; encoding=Uncompressed is T.30 bit 26 / X.400 bit 30; resolution=Fine is T.30 bit 15 / X.400 bit 9. No-bit-set values represent the default (A4, 1-dimensional, Coarse).

email

wire-format §2.2

The byte boundary page-break sequence is the hex pattern 00 10 01 00 10 01 00 10 01, which cannot occur inside a valid T.4 image. Implementations can search for this byte sequence to locate page boundaries.

email