rfc-2301

File Format for Internet Fax

L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty
date1998-03 streamIETF areaapp wgfax statusPROPOSED STANDARD pages77 canonicalhttps://www.rfc-editor.org/rfc/rfc2301 doi10.17487/RFC2301
This document describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. [STANDARDS-TRACK]

obsoleted by

Extracted elements (32)

design-rationale §2.1.2

Compression parameters are stored in the compressed data stream rather than in TIFF fields, making the container format and the compression format specification independent of each other. This design allows TIFF to gracefully add new compression schemes as they become available.

design-rationale §2.2.2

FillOrder=2 (LSB-first) dominates in fax implementations because facsimile data appears on the telephone line in bit-reversed order relative to its ITU-T T.4 description, making LSB-first the natural storage order for devices that store data directly from the modem.

design-rationale §3.5

Profile S mandates little-endian byte order and strict IFD-before-image-data page ordering to enable streaming implementations (processing a file as it is received before the entire file arrives) and to reduce memory requirements in low-resource fax devices.

design-rationale §4.4.4

TIFF-F uses Compression=3 rather than Compression=2 for Modified Huffman encoding because T.4-compatible fax data requires EOL codes in the stream, whereas TIFF's Compression=2 (also MH) stores data without EOLs.

design-rationale §1.2

TIFF was chosen as the base format for Internet fax because it bridges legacy fax machines and host-based applications, builds on an established user and implementor base, and ensures backward compatibility with existing TIFF-based IETF proposals. TIFF constructs for pages, images, and strips also preserve the fax data stream structure.

interoperability-note §3.2.1

Baseline TIFF readers are only required to support FillOrder=1 (MSB-first), but because most fax products use FillOrder=2 (LSB-first), Profile S mandates FillOrder=2 for the minimal mode while Profile F requires readers to support both values.

interoperability-note §2.2.2

Per ITU-T T.4, the following resolution values may be treated as equivalent: XResolution 200↔204 and 400↔408 pixels/inch; YResolution 98↔100, 196↔200, and 391↔400 pixels/inch. These equivalencies exist to permit conversions between inch-based and metric-based fax terminals.

interoperability-note §2.1.2

When an attribute is specified both in the compressed data stream and in a TIFF field, the data stream value takes precedence for values required to interpret the stream. TIFF field values take precedence for informational attributes not required for decoding (e.g., author name).

normative-requirement §1 MUST

All color implementations of TIFF for facsimile MUST implement Profile C (lossy color and grayscale using JPEG compression). Profile C is the required baseline for all color-capable implementations.

normative-requirement §1 MUST

All implementations of TIFF for facsimile MUST implement Profile S (minimal black-and-white mode using MH compression). Profile S is the required baseline and root node for all conformant TIFF-FX implementations.

normative-requirement §2.1.1 REQUIRED

An implementation that reads files complying with this specification SHALL read multiple IFDs, enabling multi-page fax document support. A standard Baseline TIFF reader is not required to read beyond the first IFD, but a TIFF-FX reader must.

normative-requirement §4.2.2 MUST

Each MMR (T.6, Compression=4) encoded strip MUST include an end-of-facsimile-block (EOFB) code at the end. The T6Options field must be present with value 0; uncompressed mode is not allowed for FAX.

normative-requirement §4.4.5 MUST NOT

Facsimile hardware that does not provide page-quality information MUST NOT write page-quality fields (BadFaxLines, CleanFaxData, ConsecutiveBadFaxLines). Computer-generated or error-corrected files SHOULD NOT write these fields.

normative-requirement §3.5 REQUIRED

For the minimal black-and-white mode (Profile S), the two header byte-order bytes SHALL have the value 'II' (0x4949), mandating little-endian byte ordering throughout the entire file.

normative-requirement §2.2.4 SHOULD

If a GlobalParametersIFD exists in a TIFF file, it SHOULD be located in the first IFD. When a conflict exists between fields in the GlobalParametersIFD and in an image IFD, the data in the image IFD shall prevail.

normative-requirement §3.5 REQUIRED

Profile S imposes a strict file ordering: IFDs SHALL appear in page order; each IFD SHALL precede the image data it references; image data SHALL appear in page order; and each page SHALL be contained in a single strip. XResolution and YResolution long values SHALL be placed immediately after their IFD and before that page's image data.

normative-requirement §3.4.1 MUST

Profile S readers MUST be able to process files that do not include RTC sequences and SHOULD be able to process files that do include RTCs (which is allowed only when T4Options bit 2=0, indicating non-byte-aligned EOLs).

normative-requirement §1 MUST

The implementation of a particular profile MUST also implement all profiles on the path connecting it to the root node (Profile S). For example, an implementation of Profile M must also implement Profiles C and S.

normative-requirement §4.4.2 MUST

TIFF-F (Profile F) readers MUST be able to read data in both FillOrder=1 (MSB-first) and FillOrder=2 (LSB-first) bit orderings. Writers typically use FillOrder=2 since fax data arrives on the telephone line in LSB-first order.

normative-requirement §2.2.2 SHOULD

TIFF for Facsimile writers SHOULD express XResolution and YResolution in inch-based units (ResolutionUnit=2) for consistency with historical practice and to maximize interoperability.

protocol-element §2.2.4

CodingMethods (tag 403, type LONG) is a bitmask indicating which compression methods are used in the file: bit 1=MH (T.4), bit 2=MR (T.4), bit 3=MMR (T.6), bit 4=JBIG (T.82/T.85), bit 5=Baseline JPEG (T.81), bit 6=JBIG color (T.82/T.43). Bits 7–31 are reserved.

protocol-element §2.2.4

FaxProfile (tag 402, type BYTE) identifies the TIFF-FX profile of the file: 0=unspecified, 1=Profile S, 2=Profile F, 3=Profile J, 4=Profile C, 5=Profile L, 6=Profile M.

protocol-element §2.2.4

GlobalParametersIFD (tag 400, type IFD) is an optional new field containing global fax session parameters. It is intended to make session-level attributes available in one place without scanning the entire file.

protocol-element §2.2.1

PageNumber (tag 297, type SHORT, count=2) is required for all fax modes. The first value is the 0-based page number; the second value is the total page count (0 if unknown). Defined as a TIFF extension field.

protocol-element §3.2.2

T4Options (tag 292, type LONG) is required when Compression=3. Bit 0 selects MH (0) or MR (1) encoding; bit 1 must be 0; bit 2 indicates byte-aligned EOLs (1) or non-byte-aligned (0). Default is 0 (MH, non-byte-aligned).

protocol-element §1

TIFF-FX defines six facsimile profiles: S (minimal B&W, MH/T.4), F (extended B&W, MH/MR/MMR per T.4/T.6), J (lossless B&W JBIG per T.85/T.82), C (lossy color JPEG per T.42/T.81), L (lossless color JBIG per T.43/T.82), and M (Mixed Raster Content per T.44). Profile hierarchy has S as root, C branching from S for color.

registry §9

Annex B provides an IANA registration for Application parameter values used with the image/tiff MIME content type for facsimile applications (as referenced in Section 9). The Application parameter identifies the TIFF-FX profile or class of fax content to enable capability negotiation over Internet fax.

registry

security-consideration §10

Security considerations for the TIFF-FX file format are addressed in Section 10. As a file format specification for image data, implementors should apply standard defensive parsing practices against malformed or malicious TIFF files, particularly given the complexity of multi-strip, multi-IFD structures.

security

wire-format §2.1.1

Each IFD field entry is 12 bytes: Tag (2 bytes), field type (2 bytes: SHORT, LONG, RATIONAL, ASCII, etc.), count of values (4 bytes), and value or file offset (4 bytes). IFD entries are sorted in ascending tag order; the IFD is preceded by a 2-byte field count and followed by a 4-byte next-IFD offset.

wire-format §4.2.1

Profile F (extended B&W) supports ImageWidth values 1728/2048/2432 (A4/Letter), 2592/3072/3648 (B4), 3456/4096/4864 (A3), with XResolution in {200,204,300,400,408} and YResolution in {98,100,196,200,300,391,400} pixels/inch. Not all combinations are legal; valid pairs are tabulated against paper size.

wire-format §3.2

Profile S (minimal B&W) fixes: ImageWidth=1728, BitsPerSample=1, Compression=3, FillOrder=2 (LSB-first), PhotometricInterpretation=0 (1=black), ResolutionUnit=2 (inch), XResolution in {200,204} pixels/inch, YResolution in {98,100,196,200} pixels/inch, single strip per page.

wire-format §2.1.1

The TIFF file header is 8 bytes: byte order indicator (2 bytes: 0x4949 'II'=little-endian or 0x4D4D 'MM'=big-endian), TIFF magic number 42 (2 bytes, ordered per byte-order field), and offset to first IFD (4 bytes). Profile S requires 'II' with IFD offset=8.