Summary

  • RFC 3073 registered application/font-tdpfr and published identification metadata, but directed implementers to Bitstream for the complete Portable Font Resource specification.
  • A registry name can coordinate dispatch to a handler. It cannot prove specification custody, compatible code, successful parsing, faithful rendering, authorization or downstream effect.

In March 2001, John Collins of Bitstream published RFC 3073 to register a MIME subtype for Portable Font Resource files. The record was concrete. application/font-tdpfr required no parameters, allowed none optionally, called for binary or base64 transfer, identified the magic bytes 50 46 52 30 in hexadecimal, named the file extension PFR and marked intended use as common. A sender and receiver could now share a public token for what the body claimed to contain.

The token did not contain the format. RFC 3073 described PFR at a useful distance: a compact, platform-independent collection of glyph shapes associated with character codes; outlines independent of output resolution; scaling to arbitrary size; optional bitmap glyphs. For complete features and technical details, however, it sent the reader to the original PFR specification. The document said Bitstream defined that specification, made it available on request and hosted a copy at a Bitstream address. Collins, also at Bitstream, appeared as both contact and author/change controller.

That division was not concealed. It was the architecture of the registration. The RFC placed the name and a template in the public coordination layer while leaving the complete descriptive contract in another institution's custody. It even recorded an earlier identity: the media type had previously been registered as application/vnd.truedoc. The new name followed reported adoption by DAVIC, DVB and DTG and moved the type into the unfaceted tree then associated with broad Internet use. Yet changing the public label did not copy every rule of the format into the RFC or install a renderer on any receiving machine.

The distinction matters because a media type is a dispatch clue. An application can inspect a Content-Type field, select a candidate handler and pass the bytes onward. Each verb produces different evidence. Recognizing the string proves that the token matched. Selecting a handler proves that configuration mapped the token to code. Accepting the bytes proves only what that code's parser returned. Rendering proves that some output was produced. None of those steps alone proves that the handler implemented the same PFR revision intended by the producer, preserved every glyph mapping, used the right metrics or showed the recipient what the author expected.

RFC 3073's security text also belongs inside its stated scope. It said the then-defined fields were descriptive and were not used to induce particular recipient behavior. It acknowledged that an extensible structure could later acquire fields that induced actions and therefore new risks, while saying such instructions were unsupported and contrary to the referenced format's goals. This was a statement about the format's design boundary.

It was not a memory-safety audit of every parser, an authenticity mechanism for every file, a promise that decoded shapes were trustworthy, or an authorization for an application to act on what it displayed.

The registration's “Interoperability considerations: none” field is similarly easy to overread. It did not attach a test corpus, independent implementation report, conformance suite or measured rendering comparison. The same RFC named Netscape Communicator, Bitstream WebFont Maker and Hexmac Typograph as applications using the type, but a list of products is not proof that every pair exchanged every valid file faithfully. The careful historical claim is narrower: the registration supplied a shared name and public metadata at a time when several applications and standards bodies were said to use the format.

The institutional context changed later without erasing that boundary. RFC 6838 formalized media-type registration as a public naming system with different trees, publication rules, review paths and change-control expectations. RFC 8081 later created the font top-level type and registered font/ttf, font/otf, font/sfnt, font/woff and font/woff2. The current IANA registry marks older application/font-sfnt and application/font-woff names deprecated in favor of their font/* forms. It still lists application/font-tdpfr with RFC 3073 and no such annotation. That ledger state establishes the current registry entry; it does not establish migration, withdrawal, present deployment or interoperability.

RFC 2045 helps explain the original operational bargain. MIME needed a common grammar for labeling and transferring bodies that recipients might or might not understand. A label reduced ambiguity about how content advertised itself, but it did not create universal decoding capability. RFC 2048's registration procedure tried to make new labels reviewable and documented. RFC 3073's record can therefore be understood as a coordination improvement without turning registration into ownership of the underlying implementation chain.

This is where Running-Code Primacy supplies a useful later lens. The relevant chain begins with a registered name, continues through an obtainable and versioned specification, a maintained decoder, a handler mapping, a particular input, a successful parse and a rendered result. Reality Layers asks a parallel question: does the symbolic prestige of a public name have an executable basis at the point where the claim matters? These lenses are not Collins's argument and should not be attributed to Bitstream, IANA or the IETF. They help us resist substituting one receipt for another.

The lesson is not that externally maintained formats cannot be coordinated through public registries. They often must be. Nor does the record show that the PFR specification was secret: RFC 3073 explicitly said it was available on request and supplied a web address. The lesson is about precision. Public discoverability of a name, public availability of a registration, custody of the complete format, access to compatible code and successful rendering are separate conditions. When one survives, it does not automatically preserve the others.

RFC 3073 made a name durable enough for senders and receivers to refer to the same claimed content type. That was real infrastructure. Its limit was equally real. The registry could say what the capsule called itself and where the documentation was said to live. Only the specification, implementation and observed output could show what a particular recipient was actually able to do with the bytes.

Sources