Summary
- RFC 2159 described the X.400-to-MIME G3Fax conversion as “nearly Byte copy”, but the algorithm also mapped parameters, reversed bit order within every byte, padded pages and inserted a six-EOL page delimiter.
- A reversible return depended on keeping page boundaries, trailing EOLs and otherwise unnamed DCS bits; a matching payload hash alone could not prove that the same fax object came back.
- Even a structurally correct round trip did not establish decoder support, exact scan-line geometry, faithful display or a usable page for the recipient.
“Nearly” was the specification
Published in January 1998, RFC 2159 defined a MIME body part for data already encoded as Group 3 facsimile and explained how to map it to and from X.400. It expressly declined to present image/g3fax as a general-purpose Internet image format. The task was narrower: carry an existing fax representation across two messaging systems without losing the information needed to recover it.
The document split that representation into three parts. First came flags describing the coding scheme. Second came the structure that divided the bitstream into pages. Third came the T.4 image bits for each page. Those parts travelled differently. Coding choices became MIME parameters; page membership moved between an X.400 sequence and an in-band delimiter; page data was carried with a different convention for the order of bits inside each byte.
That is why the conversion entry’s phrase “nearly Byte copy” is more exact than it first appears. RFC 1494, the earlier source for the mapping, defined a true Byte Copy as the trivial case in which the byte stream was copied without conversion. G3Fax did not meet that definition. Much of the compressed image information could pass through without being decoded and re-encoded, but the object around those bits had to be rebuilt.
One fax body contained three kinds of state
The MIME header could name page length, page width, one- or two-dimensional encoding, uncompressed mode, coarse or fine resolution, the page count and a Base64 Device Control String. Defaults mattered: absent parameters meant A4 length, A4 width, one-dimensional encoding and coarse resolution. Silence was therefore a value, not proof that the sender had no preference.
The named choices also occupied different numbered positions in T.30 and X.400. RFC 2159 warned that it was misleading to see them as a simple set of identical one-bit flags. X.400 numbered bits from the most significant end of an octet; T.30 used the opposite numbering convention. A gateway had to map meaning, not copy a printed bit number.
Then came the options that did not have names in the MIME parameter set. If any other Device Control String bit was set, the RFC said the DCS parameter should be supplied. It simultaneously warned that interworking was not guaranteed when such non-basic bits were used. Carrying the unknown bits preserved evidence. It did not create support for what they requested.
This is the first limit on a byte-based audit. A page payload may be unchanged while a default is applied differently, an option bit disappears, or the recipient lacks the mode described by that bit. The compressed image and the capability contract are related records, not the same record.
Page boundaries had to be manufactured
X.400 held a fax as a sequence of ASN.1 BIT STRING values, one per page. MIME needed one continuous body. RFC 2159 therefore used a return-to-command marker as an in-band page delimiter: six consecutive EOL patterns, each EOL consisting of eleven zeroes followed by one. The six markers had to begin on a byte boundary, so the image stream was padded with zero bits when necessary.
The RFC gave the boundary’s byte sequence as 00 10 01 00 10 01 00 10 01 and said it could not occur inside the image. That made page splitting searchable without decoding the entire fax image. But it also made the delimiter, its alignment and the padding length part of the evidence. Lose the boundary and the same run of image bits no longer proves the same page sequence.
On the X.400-to-MIME path, a gateway removed trailing EOL markers from each page BIT STRING, changed the bit order to the Internet convention, padded the page to a whole byte, appended six EOLs and concatenated the pages. None of those actions was a fax-image transcode. None was a literal copy either.
On the return path, the gateway split the MIME body at every six-EOL marker, retained the trailing EOLs, reversed the order of bits within each byte, turned each result into an ASN.1 BIT STRING and assembled the sequence. RFC 2159 explicitly marked the instruction to retain trailing EOLs as a change from RFC 1494, whose return algorithm had removed the EOLs and padding. A later specification could preserve the broad label “nearly Byte copy” while changing the bytes required at one boundary.
A payload hash cannot testify for a bit-order rule
Suppose an operator hashes the MIME body before and after a mail hop and gets the same value. That is useful evidence that the MIME octets survived that hop. It says nothing about whether the gateway used the right bit order when creating those octets from X.400. Hashing the X.400 BIT STRING’s packed bytes against the MIME bytes may produce a mismatch even when the conversion is correct, because RFC 2159 deliberately reverses the bits within each byte.
The comparison must be made at the right layer. Record the ASN.1 page bit length and unused-bit count. Apply the named bit-order rule. Record how many zero bits were added for byte alignment. Record where each six-EOL delimiter begins. On return, verify that the delimiter count restores the page count, that the per-page bit lengths are recovered under the specified padding rule and that the X.400 parameters and DCS bits match the starting object.
The companion RFC 2157 supplied the governing term: equivalence was a pair of mappings that together provided a lossless conversion. One direction producing a valid body was a mapping. The second direction, applied to the same identified object under a named rule set, was what made the stronger claim testable.
Structural reversibility still stopped before usability
RFC 2159’s implementation guidance refused to turn a reversible container into a promise of a usable fax. If fine resolution was absent, pixels were twice as tall as they were wide. Contemporary option spaces extended beyond the small set of named MIME parameters. The document reported that fine resolution and some page lengths were easier for access units to support than B4 or A3 widths. It also warned that some fax machines had trouble when a scan line omitted white space and failed to contain exactly the declared number of pixels.
Those observations identify a downstream boundary. A gateway can preserve page membership and option bits perfectly, yet deliver a mode the viewer does not implement. A decoder can accept the data while displaying the wrong geometry. A page can render while clipping the right edge or stretching the vertical scale. The output may look plausible while still failing a pixel-level comparison.
The registry record is equally bounded. The current IANA media-type registry still lists image/g3fax; the historical MIME/X.400 tables pair it with g3-facsimile. Registration establishes a public identifier and mapping reference. It does not prove that a product implemented the 1998 return rule, that a deployed gateway selected it, or that a recipient could display every permitted option.
The useful receipt is a joined record
A defensible test starts with the exact X.400 parameters, DCS bytes, page count, each BIT STRING’s meaningful bit length and a fingerprint of its meaningful bits. It records the gateway version and mapping-table identity. It then captures the MIME parameters, page-body bytes, padding count and delimiter offsets. The return run must name the reverse implementation and compare the restored sequence, page lengths, parameters and DCS field with the original.
Only after that structural test should a decoder test begin. It should identify supported encoding, resolution, width and length; count pixels per scan line; measure page geometry; and compare the rendered output with an agreed reference. Delivery, display and human reading remain later events.
Lu Heng’s Running-Code Primacy provides the appropriate editorial discipline: the algorithm describes a coordination path, while an executed transformation and captured output establish operational behavior. Minimum Initial Specification helps keep the shared rule separate from local decoder capability. Reality Layers explains why a type label, a reversible representation, a rendered image and a usable document cannot borrow one another’s receipts.
RFC 2159’s phrase was not an apology for an imprecise mapping. It was a compact inventory of what remained outside a copy. The image bits mattered. So did the options, the page boundaries, the bit order, the padding and the receiver. Remove any one of them and “nearly” can become the distance between an intact byte stream and a fax that cannot be faithfully reconstructed.
Sources
- RFC 2159, A MIME Body Part for FAX
- RFC Editor record for RFC 2159
- IETF Datatracker record for RFC 2159
- RFC 2159 errata search
- RFC 1494, the earlier X.400/MIME equivalence table
- RFC 2157, Mapping between X.400 and RFC-822/MIME Message Bodies
- RFC 2045, MIME Part One
- IANA Media Types registry
- IANA historical MIME/X.400 mapping tables
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance

