Summary

  • RFC 2158 identified JPEG and GIF through body-part names, object identifiers, MIME Content-Types and copied octets; those fields were related but not interchangeable.
  • Its FTAM EMA GIF subsection prints image/jpeg even though the heading, body-part name and gif-image(4) OID all point to GIF.
  • The surrounding record makes a carry-over typo likely, but RFC Editor currently lists no RFC 2158 erratum; neither likely intent nor a published label proves what any deployed gateway emitted or decoded.

One row broke its own identity chain

RFC 2158, published in January 1998, is unusually short. It carried two image formats from MIME into X.400 by defining Extended Body Parts and by documenting two FTAM attachment identifiers assigned by the Electronic Messaging Association. The first path gave JPEG an OCTET STRING body named mime-jpeg-body under { mixer-bp-data 3 }. The second gave GIF mime-gif-body under { mixer-bp-data 4 }. Both had no parameters and referred the content definition back to MIME.

The equivalence list then presented four cases. JPEG’s Extended Body Part was paired with image/jpeg. FTAM EMA JPEG was also paired with image/jpeg, with an OID ending in jpeg-image(6). GIF’s Extended Body Part was paired with image/gif. The fourth subsection was headed image/gif - FTAM EMA GIF; it named the body part FTAM EMA GIF and printed an OID path ending in gif-image(4). Yet the intervening line read MIME Content-Type: image/jpeg, and the next sentence called the OID one assigned to JPEG.

This is not an ambiguous modern interpretation imposed on old prose. The contradiction sits inside one compact entry. Three identifiers say GIF; one label and one copied noun say JPEG. The standard therefore preserves evidence of what was printed, but the fields cannot all describe the same format at once.

“No conversion” raised the cost of a wrong label

Every RFC 2158 mapping says Conversion: None. The design was not asking a gateway to decode one raster format and encode another. It was associating an X.400 representation with a MIME type while carrying the image octets through unchanged. That makes the selected type especially important: the bytes do not become JPEG merely because a header says JPEG, and they do not become GIF merely because an OID branch contains the word GIF.

RFC 2046 states the relevant boundary plainly: within the image top-level type, the subtype names the specific image format. The current IANA media-type registry keeps image/gif and image/jpeg as separate registered entries. A receiving handler commonly uses that label to choose a decoder, but the label remains a claim about the octets. A successful parser invocation, an unchanged body hash and a correctly selected mapping are separate observations.

The companion RFC 2157 reinforces the surrounding pattern. Its mapping tables pair mime-jpeg-body with image/jpeg and mime-gif-body with image/gif; FTAM is listed more generally because its application identifier carries the specific attachment identity. RFC 2157 also required mapping descriptions detailed enough for independent implementation. None of that silently edits RFC 2158, but it shows why an implementer had more than one field to reconcile.

The obvious correction is still an inference

The strongest textual reading is that the FTAM EMA GIF subsection should have named image/gif and described an OID assigned to GIF. The heading, body-part name, OID leaf and neighbouring entries all support that conclusion. The earlier public MIXER images draft also pairs the Extended Body Part for GIF with image/gif, although that draft predates the FTAM EMA subsections and therefore does not contain a corrected version of the disputed row.

But an audit must stop where the record stops. The RFC Editor’s current RFC 2158 errata search returns no matching errata. There is no verified correction to cite, no reported correction awaiting review, and no rejected or held entry in that result. “Likely typo” is supported analysis. “Officially corrected” is false on the available record.

The distinction matters because published standards do not change in place. An operator may have followed the MIME line literally, followed the OID and heading, imported a private correction, consulted RFC 2157, inspected file signatures, or never implemented the FTAM mapping. The document alone does not tell us which branch became code.

A specification row cannot testify for a running gateway

The mistake is tempting to overread in both directions. One camp may treat the printed Content-Type as normative and dismiss the contradictory identifiers. Another may repair the line mentally and then speak as if every implementation did the same. Neither move produces deployment evidence.

To establish what a gateway did, an investigator needs the mapping-table version, selected X.400 body-part identifier, complete OID, input MIME field, input bytes, output MIME field, output bytes and the decoder result. If a body hash is unchanged, that proves byte continuity across the observed step. It does not prove the bytes matched the label. If a viewer displayed the image, that proves one handler accepted the result; it does not prove all recipients would choose the same handler or that the standard’s row was implemented as inferred.

Lu Heng’s Running-Code Primacy offers the appropriate editorial discipline: the published rule is a coordination artifact, while executable behavior must be shown in code and observations. Minimum Initial Specification argues for keeping the common layer narrow rather than making local repair choices universal. Reality Layers explains the final separation: document, implementation and observed outcome may align, but none may borrow the others’ receipt.

RFC 2158’s inconsistency is valuable precisely because it is small. It shows how easily a trustworthy publication can contain fields with unequal evidentiary weight. The honest conclusion is not that labels are useless. It is that format identity is a joined claim, and a contradiction must be resolved before the label is allowed to speak for the bytes, the code or the result.

Sources