Summary

  • RFC 2160 mapped application/postscript to both an older X.400 Extended Body Part and a recommended FTAM Body Part. The payload in either case was a single octet stream copied without content conversion, while the carrier identifiers remained different.
  • A matching hash could prove payload integrity across the gateway. It could not prove support for the selected X.400 representation, adoption of the FTAM recommendation, correct PostScript interpretation, safe execution, or a usable result.

Imagine two sealed cases arriving at the same archive. Their contents have the same hash. One case uses an old fitting; the other uses the fitting the new handling manual recommends. If the archive can open only one, the equality of the contents does not make the cases interchangeable.

That was the quiet boundary inside RFC 2160. Published in January 1998, the memo connected PostScript in MIME and X.400. Its payload rule was admirably simple. Its carrier rule was not singular.

One stream, two X.400 identities

The first representation came from RFC 1494. It was an Extended Body Part with no parameters: the data was an OCTET STRING, identified by mime-postscript-body, assigned under { mixer-bp-data 2 }. RFC 1494 had called its mapping to application/postscript a byte copy.

The second representation used the File Transfer Body Part. Its identity lived in FileTransferParameters.environment.application-reference, which had to contain id-mime-ftbp-postscript, assigned under { mixer-bp-data 6 }.

These were not two spellings of the same label. An X.400 implementation distinguished them at different structural surfaces. One recipient could know the legacy Extended Body Part and not the FTAM profile; another could be built around FTAM handling. RFC 2160 therefore did two things at once: it carried the old mechanism forward after RFC 1494 had been superseded by the newer body-mapping work, and it said the FTAM method was recommended.

A recommendation is a direction, not a deployment receipt. The continued definition of the old path acknowledged an installed base. The new OID expressed a preferred carrier. Neither statement reported what a particular gateway emitted or what a particular user agent accepted.

“No conversion” answered only the payload question

For both X.400 representations, RFC 2160 mapped the body to MIME application/postscript and wrote “Conversion Type: No conversion.” Its explanation was precise: both sides contained a single stream of octets, so that stream could be copied and no other data needed conversion.

This is strong evidence for a narrow claim. If an operator hashes the extracted X.400 stream and the resulting MIME entity and the hashes match, the gateway did not alter those payload bytes. It is not evidence that the outer representation stayed the same; the purpose of the mapping was to move between representations.

RFC 2157, the body-mapping framework cited by RFC 2160, makes this separation visible. Extended Body Parts and FTAM body parts are distinct types, with different identification rules. RFC 2156 places such work inside a broader gateway goal: consistent service, minimal information loss and reversibility where practical. Those are design principles. They are not observations of a particular delivery.

This is why “unchanged bytes” and “unchanged carrier identity” cannot be collapsed into one green status. The first is a comparison over a payload. The second is a statement about the object that carried it.

The MIME label did not promise a successful page

RFC 2160 pointed to the then-current MIME definition in RFC 1521. The later consolidated media-type specification, RFC 2046, explains what application/postscript means: the body is a PostScript program. It also explains why the label is not an outcome.

RFC 2046 strongly recommends PostScript Document Structuring Conventions because an unstructured document cannot be tested in advance for compatibility with a given environment. A receiver may prudently refuse it. Language level, fonts, extensions, device features and resource limits can determine whether intact code produces the intended page.

Then comes the safety boundary. General-purpose PostScript interpreters can expose file operations, persistent interpreter state, system parameters, nonstandard machine-code extensions and unbounded resource consumption. A secure reader may disable operators or decline interactive display. That refusal can be the correct outcome even when the payload hash, X.400 OID and MIME type are all correct.

RFC 2160 did not ignore this; it referred security questions to RFC 2046 and identified no additional ones. The RFC Editor record and Datatracker record establish the memo’s status and history, while the errata search currently lists no matching errata. None of those records can report the behavior of an absent implementation.

A better evidence ladder

The operational record should keep at least five findings apart.

First, payload integrity: hash the PostScript stream before and after the gateway. Second, carrier identity: record whether the X.400 body was the Extended Body Part or FTAM Body Part, and capture the actual identifier field. Third, capability: test whether each supported recipient recognizes that representation. Fourth, interpretation: record the MIME classification, interpreter policy, language features and rejection reason. Fifth, outcome: capture whether the intended page rendered, printed or remained safely quarantined.

This ladder follows Heng Lu’s argument for a minimum initial specification: keep common rules narrow and verifiable, while deployment choices remain with participants. Running-Code Primacy then asks which representation systems actually accepted, not which migration a document preferred. The distinction among reality layers prevents a type label or hash from being promoted into proof of a user-visible result.

The lesson is not that byte preservation was unimportant. It was the cleanest part of the design. The lesson is that clean evidence remains clean only when it is not asked to answer a larger question. RFC 2160 preserved a PostScript stream while changing its carrying grammar. The rest—support, adoption, interpretation, safety and usefulness—still needed its own receipts.

Sources