Zusammenfassung

  • RFC 1590 erweiterte im März 1994 die aus E-Mail bekannten „MIME-Typen“ zu „Medientypen“ für verschiedene Anwendungen. Ein Vorschlag kam auf die öffentliche Liste ietf-types; nach zwei Wochen konnte er bei IANA zur Eintragung und Vergabe einer OID eingereicht werden.
  • Ein gemeinsames Verzeichnis durfte viele Namen enthalten. Ein bestimmtes Mailprogramm konnte weiterhin eine kleine Menge verbreiteter Formate empfehlen, passend zu den Fähigkeiten unbekannter Empfänger. Gemeinsame Benennung und konkrete Unterstützung blieben getrennte Entscheidungen.

Ein Name reist weiter als sein erstes Programm

Eine Aufnahme wird per Mail verschickt und später in einem Archiv abgelegt. Wenn beide Programme ihre eigene Bezeichnung erfinden, trägt derselbe Datenstrom zwei Ausweise. Schlimmer noch: Zwei verschiedene Datenströme können denselben Namen erhalten, und ein Empfänger greift zum falschen Werkzeug. Ein öffentlicher Schalter für die Bezeichnung spart viel spätere Übersetzungsarbeit zwischen privaten Katalogen.

RFC 1521 hatte MIME-Mechanismen für den Inhalt von Nachrichten geschaffen. Bei asynchroner Mail weiß der Absender oft nichts über die Software des Empfängers. Wenige verbreitete Typen erhöhen die Chance, dass der Anhang verständlich ankommt. Doch dieselben Bezeichnungen wurden auch außerhalb der Mail gebraucht. Jon Postels RFC 1590 trennte deshalb die Größe des gemeinsamen Namensraums von der kleinen Formatpalette, die ein einzelnes Mailprogramm vielleicht empfiehlt.

Die Umbenennung von „MIME-Typen“ in „Medientypen“ war Programm. Ein Paar aus Typ und Subtyp sollte an mehreren Orten dasselbe Datenformat bezeichnen. Die IANA-Liste sagte, was der Name meinte. Ein einzelnes Programm entschied anhand seines Codes, ob es diese Daten auch verarbeiten konnte. Die Registrierung einer Videobezeichnung machte aus einer alten Mailsoftware noch keinen Videoplayer.

Der Vorschlag ging zunächst an ietf-types. Solange der Subtyp nur vorgeschlagen war, verwendete er die x--Form. Die Öffentlichkeit konnte über den Namen, genaue Versions- oder Profilangaben, Objektkennungen und bekannte Sicherheitsprobleme sprechen. Ein Typ für einen begrenzten Gebrauch konnte seinen Anwendungsbereich benennen. Diese Diskussion fand statt, bevor viele Programme die Bezeichnung als feste Gewohnheit übernahmen.

Nach zwei Wochen durfte der Antrag an IANA gehen. RFC 1590 beschrieb eine angemessene administrative Prüfung, die Eintragung, eine OID unter dem IANA-Zweig und eine öffentlich verfügbare Beschreibung. Das Formular verlangte Typ, Subtyp, erforderliche und optionale Parameter, Kodierungsangaben, Risiken, Spezifikation und Kontaktperson. Die Bürokratie hatte eine klare Funktion: Eine spätere Anwendung konnte nachschlagen, welches Objekt der Name ursprünglich bezeichnete.

Manche verbreiteten Objekte besaßen damals keine vollständig veröffentlichte Formatspezifikation. Das RFC erlaubte die genaue Benennung eines Softwarepakets und seiner Version. „Datei dieses Programms in dieser Ausgabe“ identifiziert einen Datenstrom erheblich besser als ein frei erfundener Oberbegriff. Der Empfänger brauchte weiterhin Implementierungscode für die betreffende Ausgabe. Das Register konnte den Schrank beschriften; seine Schublade öffnen musste die Software.

Für einen neuen grundlegenden obersten Typ war ein RFC oder ein dafür geeigneter Entwurf mit anschließendem Standardsprozess nötig. Ein zusätzlicher Subtyp unter einer vorhandenen Kategorie durchlief den leichteren administrativen Weg. Für Mail konnte eine eigene Anwendungsempfehlung die besonders nützlichen, verbreiteten Typen auswählen. So durfte das Verzeichnis wachsen, während jedes Programm eine vernünftige Auswahl traf.

Zwei Wochen klingt nach einer kurzen Warteschlange. Für einen Namen, der jahrelang in Nachrichten und Programmen auftauchen konnte, waren sie eine Chance, Missverständnisse vor der Eintragung offenzulegen. RFC 1590 gab der gemeinsamen Koordination eine kleine Aufgabe und ließ den Umgang mit den tatsächlichen Bytes bei den Anwendungen.