Summary

  • RFC 1590, published in March 1994, moved the discussion from mail-only “MIME Types” to “Media Types” usable across applications. A proposal went to a public ietf-types mailing list; after two weeks it could be submitted to IANA for registration and an OID.
  • The procedure separated a broad common registry from each application's supported formats. Mail readers could still recommend a small familiar set, while new media acquired publicly reviewed names instead of colliding in separate local registries.

Take a ticket; bring a description of the object

Imagine an audio object, an image format and a software-specific document arriving at the same counter. An email reader, a file archive and a network service might all encounter them. If each application invents its own name, one object gathers aliases and two different objects can fight over a label. If one mail program's limited vocabulary controls the entire counter, useful new formats wait outside. In 1994, Jon Postel's RFC 1590 offered a practical middle path: one shared register, with room for individual applications to make their own support choices.

The earlier RFC 1521 had defined MIME's way to describe message bodies. Its registration process arose in asynchronous mail, where a sender usually could not discover what the recipient's software would understand. Keeping to a small set of common content types improved the odds of a readable message. Then media labels began to travel beyond mail. A registry designed only around the caution of an unknown mail reader could become a bottleneck for other uses. RFC 1590 deliberately called the entries Media Types and broadened their intended reach.

The first stop was public review. A proposer sent the type and subtype to ietf-types, a mailing list established for this purpose. While the name was still a proposal, its subtype used the x- form. Other participants could question the name, the precision of a version or profile reference, any related object identifier and the known security issues. A format intended for one narrow use could say so. This was a place to discover naming collisions before they became software habits.

After two weeks, the proposer could submit the media type and supporting material to IANA. The procedure described an administrative review, followed by registration, an OID under the IANA branch and public availability of the entry. It gave the proposal a route from a list discussion to a durable shared name. The appendix's form asked for type, subtype, required and optional parameters, encoding considerations, security considerations, a specification and a person to contact. Bureaucracy looks especially sensible when the alternative is ten incompatible spellings for the same bytes.

RFC 1590 also addressed the awkward formats that people exchanged before a full public specification existed. A registration could identify a particular software package and version clearly enough to distinguish its data stream. That was a pragmatic way to give such objects a name. It put specificity in the record: which package, which version, which expected interpretation. The actual reader still needed code able to handle that stream, and the registration form recorded where further information could be found.

The memo kept a higher bar for a new top-level media type. A proposer who wanted a new fundamental category had to bring an RFC or a draft suitable for one and enter the standards process. The ordinary addition of a subtype used the lighter administrative route. It also assigned a separate job to application-specific guidance: a mail environment could recommend a small set of widely implemented types through an applicability statement. The central filing cabinet could accept many names while a particular reader stocked only the tools it used.

The distinction mattered because names are shared infrastructure. A media-type label tells software what kind of object has arrived and points toward its format. A broad, public register reduces collisions across mail, archives and future services. Whether a given program renders an image, plays a recording or refuses a package is decided by that program's installed capabilities. RFC 1590 put these two decisions in different hands. It made the queue for names light enough to use, and left the work of opening the objects with running software.