Summary

  • RFC 2157 defined a mapping as one directional transformation, but reserved equivalence for two mappings that together provided a lossless conversion.
  • Encapsulation could preserve an original format for a later gateway while leaving the intermediate mail system unable to interpret it.
  • A copied octet stream, a plausible filename or one successful conversion was therefore only one receipt; the reverse rule, restored metadata, usable representation and recipient outcome remained separate facts.

The standard drew two arrows before it drew an equals sign

In January 1998, the IETF published RFC 2157 as the body-part companion to MIXER. RFC 2156 handled the wider interworking of X.400 and RFC 822/MIME mail. RFC 2157 addressed the content inside: text, files, multipart structures, forwarded messages, signed and encrypted material, and the problem of types one side did not understand.

Its glossary did more than settle vocabulary. A mapping was a description of how to transform one X.400 body part into one MIME body part, or the reverse. Equivalence was a set of two mappings that, taken together, provided a lossless conversion between the two. The first claim could be demonstrated by producing an output. The second required composition: start with an identified body part, apply the outward rule, apply the specified return rule, and compare what came back.

That difference disciplines a familiar interoperability demonstration. A gateway accepts a MIME entity and emits a valid X.400 body part. The parser on the far side accepts it. Nothing in those two observations proves that a return gateway will choose the counterpart mapping, recover every parameter or reconstruct the original object. The demonstration has shown one arrow.

Encapsulation preserved custody, not local understanding

RFC 2157 defined a third relation. Encapsulation wrapped content from one mail system so it could travel inside the other. The intermediate system was not expected to make reasonable sense of the body part; a gateway back into the first system was expected to restore the original format without loss.

That is not a failed mapping. It is a different service. An encapsulated MIME object could retain its headers, parameters and canonical octets in an X.400 FTBP or BP15 container. An application/x400-bp entity could carry an X.400 extended body part through MIME. In each case, preservation served a later decapsulator. It did not promise that the user agent at the intermediate destination could display, edit or safely execute the object.

The RFC also described a BP14 “content passing” route that looked like encapsulation but was expressly lossy. It stripped MIME headers, undid transfer encoding and retained the octet stream; no reverse translation restored the original MIME type. On return, the part became application/octet-stream. Bytes survived. Type information did not. That is precisely why preservation has to name what was preserved.

A filename could choose a rule without proving the type

The specification allowed gateways considerable latitude. A decision could reflect the recipient’s known capabilities, a sender’s requested representation, the next hop’s limitations, content inspection or a filename heuristic. For a loosely typed BP14, a generic FTAM file or MIME application/octet-stream, the gateway might inspect content or a filename to decide what conversion to try.

That was operationally pragmatic. It was not an elevation of the filename into truth. The same RFC mapped a Content-Disposition filename into an FTBP pathname and warned that normal local-filesystem precautions still applied, illustrating the point with /etc/passwd. The transmitted string neither authorized a path nor authenticated a media type. It supplied an input to a local decision.

The distinction becomes sharper in the two mandatory application/octet-stream mappings. MIXER-conformant products had to implement both the deprecated X.400 BilaterallyDefined body part and FTBP Unknown Attachment, plus a configurable choice between them. The BP14 mapping removed MIME parameters. The FTBP route could retain more file metadata and copied body bytes in both directions. The same incoming generic type could therefore enter different representation paths under different configurations.

One path’s output can be syntactically valid while the pair still fails the equivalence test. A missing padding parameter can change how the last byte is interpreted. An ignored disposition token can return as attachment. A new MIME field may be discarded when the selected X.400 body type has nowhere to carry it. A gateway can make a defensible local choice without producing a globally interchangeable result.

The registry standardized pairs, not outcomes

RFC 2157’s equivalence registry required more than a type-name pairing. A registration had to identify the MIME type and X.400 body part, specify object identifiers and ASN.1 details where needed, state conversion algorithms, and explain the effect of “conversion prohibited” and “conversion with loss prohibited.” The description had to be detailed enough for independent implementation.

Registration aimed at uniformity, but the RFC explicitly denied two stronger inferences: a gateway did not have to support every registered translation, and every conversion it supported did not have to be registered. A row in a registry therefore described a public agreement. It did not prove that a particular product implemented the row, that a deployed gateway selected it, or that the recipient used the resulting representation.

The core table itself exposed the boundary. Some types had defined pairs: IA5 text, GeneralText, images, forwarded messages and the two generic-file routes. Others, including several audio, video or X.400 body types, pointed to encapsulation rather than direct mapping. Multipart signatures and encryption required special preservation because transforming their internal structure could destroy the property the object was meant to carry.

A round trip needs named evidence at both boundaries

An honest test begins with an exact input: body bytes, content headers, type parameters and nesting position. It records the configuration and the inputs that selected a rule. It captures the first output, including fields retained, discarded or moved. Then it applies the named reverse mapping—not merely whatever rule another gateway happens to prefer—and compares the restored object against the original.

Even a perfect representation round trip is not the end of the service claim. The target user agent may lack a handler. A filename may be unsafe in the local namespace. An encrypted body may remain intentionally opaque. Delivery, rendering, safe local action and human comprehension are downstream observations.

Lu Heng’s Running-Code Primacy supplies a useful editorial lens: the table and algorithm describe an available path; executed mappings and captured results establish the operational record. Minimum Initial Specification argues for keeping the common layer narrow, which here means specifying the reversible pair without converting recipient policy into a universal rule. Reality Layers explains why the registry row, implemented routine, selected mapping, restored bytes, usable object and observed outcome must not borrow one another’s authority.

RFC 2157 did not promise that every body part would become meaningful everywhere. Its more durable achievement was to make the claim testable. A mapping said what one arrow did. Equivalence required the second arrow and a lossless return. Encapsulation admitted that preservation and understanding could be separated on purpose.

Sources