Summary

  • RFC 1357 proposed a plain-text email format for announcing computer-science technical reports in July 1992. Four fields were mandatory: format version, publisher/report ID, record-entry date and a matching end marker. Title, author, abstract and retrieval instructions were optional.
  • A higher-numbered, complete revision could replace an earlier record or withdraw it. The retrieval field could describe anonymous FTP, a postal request or payment; the memo left automatic file retrieval and recipient database handling to other systems.

The envelope was faster than the report

Universities already knew how to announce a new technical report: print a bibliographic notice and send it through the post. Danny Cohen's RFC 1357 opened with the cost and delay of that routine. A paper notice also arrived in a form that a recipient could not conveniently file and search on a computer. The proposal was modest and sharp. Email the bibliographic record as ordinary text, readable by a person with a text editor and regular enough for software to ingest.

The word record did the heavy lifting. The memo specified how an announcement should travel. It left each recipient free to decide what to do with it. A library might file it; a researcher might read and discard it; a program might index it. None of those actions was part of the transport format. The Internet could move the announcement without deciding how the recipient's library worked.

The required fields reveal what the designers needed to keep that announcement stable. BIB-VERSION came first, ID second, ENTRY third, and END last. The ID combined a controlled publisher symbol with a report identifier chosen by that publisher, separated by //. The end field repeated the same ID. This made a record recognizable at both ends and gave later copies a durable target. The title sat among the optional fields. So did the author's name, abstract and instructions for obtaining the report.

That ordering sounds upside down to a reader hunting for a paper. It made sense to an institution trying to issue records over time. The publisher decided what counted as a publication and assigned the report number. The format could then carry a notice even when the human-facing description changed. It also had to carry a withdrawal: RFC 1357 allowed a higher-numbered revision to replace the whole earlier record, omit the title and remove retrieval details. In the memo's illustrative withdrawal, the title disappears while the ID remains. The number survives the announcement it once identified.

A correction had to carry the whole record

RFC 1357 refused the tempting shortcut of emailing only the changed line. A revision was supposed to be a complete record, with a revision number and a reason. A recipient could replace the prior version without reconstructing it from a chain of partial edits. That choice spent more bytes on each correction to save the reader and the database from guessing which earlier fields still applied. In 1992, that was a practical bargain: the example record occupied roughly 1,750 characters, including a short abstract.

The format was equally plain about the limits of machine handling. Its lines were limited to 79 characters; printable ASCII was the common alphabet. A repeated field, such as AUTHOR, kept its order. Experimental version strings and publisher symbols reserved for tests were supposed to stay out of permanent recipient databases. These are small controls, but they show where the proposal put authority: the publisher creates the identity and the revision; the recipient decides whether to retain the record.

Even that publisher symbol needed coordination. Cohen offered to coordinate symbols and organization names by email, while discussion about possible IANA registration remained open in the memo. The proposed identifier began with an institution's own report number, but two institutions using the same publisher symbol would spoil the namespace. The records needed a bookkeeper. The memo did not appoint that bookkeeper as the owner of the reports or the judge of their contents.

The file could still cost $4.50

The optional RETRIEVAL field is the best antidote to a tidy story about instant digital libraries. The RFC's example offers two routes for one report: send a stamped envelope to obtain a full-text copy with colour pictures, or fetch an ASCII version by anonymous FTP. The specification also allows a price or an email request as retrieval text. It had no defined machine-readable instruction for automatic file retrieval. A searchable announcement could therefore point to a file, a mailbox, a postal address or a bill.

Rights followed the same split. The bibliographic record could circulate freely under the proposal; limits on distributing the underlying report needed separate protection. A record in a mailbox did not put the full report in that mailbox. The institution controlled the text and revision of its notice. A server or postal desk still controlled the route to the work. A reader needed the route to succeed.

RFC 1357's optional title is funny until the withdrawal rule makes it serious. The format made a technical report administratively visible before it made the report conveniently obtainable. It gave institutions a cheap way to say, correct and retract what they had published. That was a useful piece of Internet history: a tiny record could cross the network at once, while the real object remained on a shelf, behind an FTP login or inside an envelope waiting for a stamp.

Sources