Summary

  • RFC 1314 specified a TIFF-B exchange profile for fax-like black-and-white images: multi-page files, one TIFF strip per page, MMR where possible, and defined alternatives for compression and resolution.
  • The RFC explicitly separated the image-file format from the way a file is communicated. FTP or SMTP could carry it, but neither protocol was a property of the file itself.
  • It also separated a host’s local storage, scanning, file manipulation, printing, display and fax output. A conforming exchange file therefore did not prove a transfer, a rendered page, a paper copy, a successful fax, or a reader’s result.

A page that could wait

The word “fax” once compressed an entire chain into one everyday verb. A sheet was scanned from paper, encoded, negotiated across a telephone call, decoded at the far end and put onto another sheet of paper. A failure somewhere in that chain was inconvenient precisely because the chain was so tightly coupled. The document did not become an object that could wait between stages; the live connection was part of what “sending” meant.

RFC 1314 looked at a different environment. Its introduction described images that could originate with scanners, software or facsimile machines and then be manipulated, communicated, shared, duplicated, displayed, printed or faxed. The list is important because it is not a list of synonyms. Each verb points to a different operation, a different system boundary and potentially a different record of evidence.

The RFC’s proposed model is almost deliberately prosaic: first scan an image into a file, or create it in software. Next, store it, manipulate it or communicate it. Only later print or display it. A fax machine could be treated as an input/output device between paper and files rather than as the network itself. That model made a document less dependent on a continuous conversation between two specific machines.

It also made the word “sent” less complete. A stored file is not a transmitted file. A transmitted file is not necessarily a decoded file. A decoded image is not necessarily a displayed page. A displayed page is not a paper copy, and none of those records identifies a reader. RFC 1314 did not need to solve every one of those questions. Its achievement was to leave them visible instead of burying them under a single successful-looking event.

What TIFF-B standardized

The standard did not attempt to invent an image language from scratch. It chose TIFF as the framework and constrained it into an Internet exchange profile. The headline profile was TIFF-B, with support for multi-page files and one strip per page. For compression, Modified Modified READ—MMR—was the preferred choice when possible. Modified Huffman, Modified READ and no compression were also permitted; when MH or MR was used, scan lines were to be byte-aligned. The text also recommended a limited set of resolutions for maximum interoperability: 600, 400 or 300 dots per inch, or the stated Group 3 fax families.

Those constraints matter as a contract between implementations. They narrow the set of files a recipient should be prepared to exchange. But they are not an outcome certificate. A TIFF-B file does not reveal which transport carried it. It does not identify the source scanner, prove a sender controlled an address, show that a receiver supported the selected compression, or certify that every page survived conversion. Even its number of pages is a fact about the file, not a fact about a conversation, a printer tray or a person’s attention.

RFC 1314 was careful on this point. TIFF is a framework that can hold different encoding techniques. The document set an exchange profile without declaring that every host must keep its local images in that form. A host could store an image in its own local representation and convert it for exchange. If a recipient could not handle the compression in a file, conversion might be needed. The RFC declined to say who must perform that conversion or which algorithm must be used.

That unresolved responsibility is not a defect to be papered over. It is a boundary. A file-format specification can define the form offered at an interface. It cannot, merely by doing so, assign custody for every conversion or demonstrate that a conversion was faithful. To claim otherwise would turn a representation rule into an unobserved operational history.

The carrier was deliberately elsewhere

The RFC states plainly that the file format for images is separate from how files are communicated. FTP or SMTP were examples of possible ways to move a file from one host to another. The examples make the distinction sharper, not weaker. A system may carry the same exchange file by more than one mechanism; the carrier can change while the representation remains the same.

At the time, the text also noted practical complications for SMTP, including file size and binary material. That observation is historical evidence about a constraint discussed by the authors; it is not a license to write a universal story about all later email attachments. Nor does the fact that FTP or SMTP might be used establish that either was used for a particular file. A format header cannot replace a transfer log, a receiving acknowledgment or an integrity check.

The same separation applies to storage. RFC 1314 says that the exchange format does not require a host to store its images in the specified format. A compliant host may translate between local storage and the exchange file when it participates in an exchange. This is easy to overlook because a file on disk feels like a settled fact. Yet an image’s local representation, its advertised interchange representation and the bytes placed on a wire can be related without being identical.

That is why the standard’s scope has a useful evidentiary lesson. Knowing that an organization supports TIFF-B says something about a potential interface. It says neither that it retained every original image, nor that it used one transport, nor that it completed a conversion for a particular destination. Compatibility is a capability claim at a boundary, not a history of every transaction that could cross it.

Unbundling the fax

RFC 1314’s comparison with conventional fax makes the architecture legible. It names four separate issues that traditional fax bundled together: data presentation and compression; data transmission; image input from paper; and image output to paper. Once those become independent, new combinations become possible. A page created by software may be stored before it travels. A scanned file may be duplicated to more than one destination. A receiving system may display it, print it or prepare it for a later fax call.

The standard does not make any of those paths mandatory. It does not promise that a Group 4 image will print correctly on a given device, or that an ordinary fax machine will accept the chosen compression. It notes that a fax board or modem might negotiate with a receiving fax machine, and that conversion can be necessary if the receiver cannot handle the file’s compression. Negotiation and conversion are later events with their own conditions. They should not be retrospectively inserted into a TIFF-B file as though the file carried proof of them.

This is more than a caution about vocabulary. Bundled systems tempt institutions to keep only one status field: sent, completed, successful. The RFC’s model suggests a more honest chain: file created; file selected for exchange; file placed on a particular transport; bytes accepted or rejected; file decoded; file rendered; output device acted; a human or downstream process responded. Some of those records may be unavailable. When they are unavailable, the right conclusion is not to promote the nearest surviving file record into all of them.

A common container, not a universal witness

The Internet’s early document systems often had to negotiate between existing machines and software rather than wait for a perfect universal medium. RFC 1314 chose a bounded common container and a narrow interoperability profile. It also anticipated that the covered class of images might later be subsumed by broader Office Document Architecture standards, while observing that the then-current installed base and standards maturity did not make that future form ready for the immediate need.

That is not a prediction to judge from the present. It is a reminder that an interchange standard can have a transition purpose without claiming permanence. The profile can be useful because it gives systems a shared minimum at one boundary, even if each system retains different local formats and later standards appear. A common file does not dissolve those differences; it makes the handoff more explicit.

The distinction still travels well. File names, MIME types, hashes and storage locations are often treated as if they narrate whole workflows. They do not. A hash can identify bytes, not a recipient’s experience. A transfer record can show a transport event, not a displayed image. A print spool entry can show a device submission, not a readable sheet. RFC 1314 is not a modern digital-evidence standard, but its separation of operations is a durable antidote to conflating these records.

What an exchange file can honestly say

An RFC 1314-compliant exchange file can support specific, limited statements: it was formed according to a defined profile; it has a particular encoding and page arrangement; it was suitable to offer at a specified interchange boundary. With additional, independent records, an operator may establish more: that a named transfer service accepted bytes, that a conversion program ran, that a device reported a job, or that a recipient system emitted a response.

Each extra statement needs the record that belongs to it. Nothing in the TIFF-B profile makes a sender into an authenticated person, a receiver into a confirmed destination, a displayed window into attention, or an output report into a human result. The absence of a claim is part of the standard’s discipline.

RFC 1314’s quiet historical contribution was to make a page movable without pretending that movement was the whole story. The image file became a durable object that could pass between stages. In exchange, every stage had to answer for itself.

Sources and evidence limits

This article relies on RFC 1314, A File Format for the Exchange of Images in the Internet (April 1992). The RFC supports the TIFF-B profile, compression and resolution guidance, the separation of exchange format from communication and storage, the four-part fax distinction, and the scan/store-or-manipulate-or-communicate/print-or-display model. It does not evidence any individual transfer, sender, receiver, display, print, fax, conversion, recipient action, current deployment or commercial result.