Summary

  • RFC 1049 proposed a Content-Type field for structured mail bodies such as PostScript, TeX and TROFF. A reader could use the field to choose a display processor while the mail body remained within the ASCII limits of RFC 822.
  • The proposal also exposed the unsolved guest-list problem: with no capability exchange, senders kept their own knowledge of which recipients could render which formats. Its version and resource-reference slots made the label more specific, while later RFC 2045 generalized the field for MIME.

A document can travel flawlessly and still be unreadable. Picture a 1988 inbox receiving PostScript. Every character survives the trip. The ordinary mail screen dutifully displays printer instructions, which is rather like greeting a dinner guest by reading the recipe aloud. The sender intended a page with symbols and layout; the recipient sees the machinery that would draw it. Martin Sirbu's March 1988 RFC 1049 proposed that the message say what kind of machinery it needed.

Internet mail already had a defined header and an ASCII body under RFC 822. People were putting structured documents in that body: TROFF commands, TeX, Scribe, SGML, device-independent output and PostScript. Each could fit the mail character set while demanding more than a plain character display. A clever reader could inspect a new Content-Type field and pass the body to the right processor. The transport could carry the same ASCII material; the work of recognition sat at the reading end.

The proposed field was a compact instruction to the reading system, rather than a vague attachment sticker. Its first value named the type: POSTSCRIPT, SCRIBE, SGML, TEX, TROFF, DVI, or a private X- type. Capitalization did not matter. An optional second value identified a version; a third could name a resource needed to interpret the document; a comment could follow. Sirbu gave concrete resources: LaserPrep versions for PostScript and eqn, tbl and me for TROFF. In other words, the reader might need both a cook and a particular pantry. A format name alone would leave the pantry question unanswered.

That resource slot is the proposal's revealing detail. Two machines can both claim to understand PostScript while one lacks the font or macro resource a particular document expects. Naming the external resource moved the dependency from a private hunch into the message. The sender and recipient still had to share a definition of what the name meant. RFC 1049 left room for private techniques between cooperating correspondents, while suggesting a registered vocabulary for broader exchange. It was trying to turn “I know what this file is” into a usable operating instruction.

Then the guest list appeared. A recipient who lacked the processor could still receive the ASCII mail, but the view could be a screenful of raw PostScript or TROFF. Sirbu examined three ways to learn capabilities. Every sending system could maintain a database of remote readers, an administrative chore with an expiration date. SMTP could negotiate and transform a message before delivery, demanding changes across existing mailers and failing to cover routes through other networks. A directory could publish host capabilities, drawing mail sending and the naming service into the job.

Each route bought information by changing another part of the system.

For immediate experimentation, RFC 1049 chose the humbler arrangement: senders would keep private lists of recipients' capabilities. Standardize the label today, remember which friends own the right reader yourself. It is a wonderfully human piece of infrastructure design. The header could identify the dinner; the host still made the guest list. The memo also left the reading program free to decide how to respond to a valid field. A recognizable label made automatic display possible; installation, invocation and user experience remained local work.

That distinction explains why the proposal belongs in mail history. RFC 2045 later explicitly described MIME's Content-Type as a generalization of RFC 1049. MIME gave the field media type and subtype, structured parameters and companions such as MIME-Version and Content-Transfer-Encoding. The 1996 specification called the older syntax simpler and largely compatible. The family resemblance is real, but the 1988 bargain is worth seeing on its own: an ASCII letter gained a declared interpretation while the social problem of capability remained with the sender.

The little label changed the conversation at the receiving desk. Instead of asking a person to stare at commands and guess the formatter, software had a name to act on. The expensive question moved one step outward: who has the program, the right version, and the right resources? RFC 1049 put that question on the table before the mail system had a machine-readable answer. For a while, the most advanced capability database was the address book in somebody's head.