Zusammenfassung

  • RFC 3073 registrierte application/font-tdpfr und veröffentlichte Identifikationsdaten, verwies für die vollständigen technischen Einzelheiten von Portable Font Resource aber auf Bitstreams ursprüngliche Spezifikation.
  • Ein Registername kann Software zur Auswahl eines Handlers anleiten. Er belegt weder die Verwahrung der Spezifikation noch kompatiblen Code, erfolgreiche Verarbeitung oder originalgetreue Darstellung.

Im März 2001 veröffentlichte John Collins von Bitstream RFC 3073 zur Registrierung eines MIME-Subtyps für Portable-Font-Resource-Dateien. Der Eintrag war konkret. application/font-tdpfr verlangte keine obligatorischen und erlaubte keine optionalen Parameter, sah binary oder base64 für die Übertragung vor, nannte die hexadezimalen Magic Bytes 50 46 52 30, die Dateiendung PFR und den vorgesehenen Gebrauch common. Sender und Empfänger konnten damit dasselbe öffentliche Zeichen für den behaupteten Inhalt eines Körpers verwenden.

Das Zeichen enthielt nicht das Format. RFC 3073 beschrieb PFR in ausreichender Entfernung: eine kompakte, plattformunabhängige Sammlung von Glyphenformen, die Zeichencodes zugeordnet sind; Konturen unabhängig von der Ausgabeauflösung, beliebige Skalierbarkeit und optional eingebettete Bitmap-Glyphen. Für den vollständigen Funktionsumfang und die technischen Details führte der Weg jedoch zur ursprünglichen PFR-Spezifikation. Das Dokument sagte, Bitstream habe sie definiert, stelle sie auf Anfrage bereit und biete eine Kopie an einer Bitstream-Webadresse an.

Collins, ebenfalls bei Bitstream, war Kontakt und Autor beziehungsweise Change Controller.

Diese Trennung war keine verdeckte Auslassung, sondern die institutionelle Architektur des Eintrags. Die öffentliche Koordinationsschicht bewahrte Namen, Registrierungsvorlage und identifizierende Kurzbeschreibung. Der vollständige beschreibende Vertrag blieb in der Obhut einer anderen Organisation. Das RFC dokumentierte auch den früheren Namen: Zunächst war der Typ als application/vnd.truedoc registriert. Nach der berichteten Übernahme durch DAVIC, DVB und DTG wurde er unter dem neuen Namen erneut eingetragen. Ein Wechsel aus dem Herstellerbaum in den damals für breiten Internetgebrauch stehenden ungegliederten Baum kopierte aber nicht jede Formatregel in das RFC und installierte keinen Renderer auf jedem Zielsystem.

Ein Medientyp ist zunächst ein Hinweis für die Weiterleitung. Eine Anwendung kann Content-Type lesen, eine Zuordnung nachschlagen, einen Handler auswählen und ihm die Bytes übergeben. Jedes Verb erzeugt einen anderen Beleg. Das Erkennen der Zeichenfolge beweist die Übereinstimmung des Namens. Die Auswahl des Handlers beweist eine lokale Konfiguration. Die Annahme der Bytes beweist, was ein konkreter Parser zurückgab. Eine sichtbare Seite beweist nur, dass irgendeine Ausgabe entstand. Kein einzelner Schritt zeigt, dass der Handler dieselbe PFR-Revision wie der Erzeuger implementierte, jede Zeichenabbildung und Metrik erhielt oder dem Leser genau die beabsichtigte Form zeigte.

Auch der Sicherheitstext von RFC 3073 gehört in seinen erklärten Geltungsbereich. Die damals definierten Felder seien beschreibend und dienten nicht dazu, beim Empfänger bestimmtes Verhalten auszulösen. Zugleich erkannte das Dokument, dass die erweiterbare Struktur künftig handlungsauslösende Felder erhalten und dadurch neue Risiken schaffen könnte; solche Anweisungen würden von der referenzierten Spezifikation nicht unterstützt und ihren Zielen widersprechen. Das ist eine Grenze des Formatentwurfs.

Es ist weder eine Speichersicherheitsprüfung aller Parser noch ein Echtheitsmechanismus, ein Vertrauensbeweis für die dargestellten Formen oder eine Berechtigung für nachgelagerte Aktionen.

Die Angabe „Interoperability considerations: none“ darf ebenfalls nicht als Interoperabilitätsnachweis gelesen werden. Das RFC enthält keine Konformitätssuite, keinen Bericht unabhängiger Implementierungen, keinen Testkorpus und keinen gemessenen Vergleich gerenderter Ergebnisse. Es nennt Netscape Communicator, Bitstream WebFont Maker und Hexmac Typograph als Anwendungen des Typs. Eine Produktliste belegt jedoch nicht, dass jedes Paar sämtliche gültigen Dateien verlustfrei austauschte.

Die historisch belastbare Aussage ist enger: Die Registrierung schuf einen gemeinsamen Namen und öffentliche Metadaten zu einer Zeit, als der Gebrauch durch mehrere Programme und Normungsorganisationen angegeben wurde.

Spätere institutionelle Regeln beseitigten diese Grenze nicht. RFC 6838 ordnete die Medientypregistrierung als öffentliches Namenssystem mit Bäumen, Publikationspflichten, Prüfwegen und Verantwortlichkeiten für Änderungskontrolle. RFC 8081 schuf danach font als Top-Level-Typ und registrierte font/ttf, font/otf, font/sfnt, font/woff und font/woff2. Das heutige IANA-Register kennzeichnet die älteren Namen application/font-sfnt und application/font-woff zugunsten entsprechender font/*-Namen als überholt. application/font-tdpfr steht weiterhin mit RFC 3073 im Register und trägt diese Anmerkung nicht. Das beweist den aktuellen Registerstand, nicht Migration, Rückzug, gegenwärtige Nutzung oder Interoperabilität.

RFC 2045 macht den ursprünglichen betrieblichen Tausch verständlich. MIME brauchte eine gemeinsame Grammatik, um Körper zu kennzeichnen und zu transportieren, die ein Empfänger verstehen konnte oder auch nicht. Ein Label verringerte die Mehrdeutigkeit der Selbstauskunft, schuf aber keine universelle Decodierfähigkeit. Das Registrierungsverfahren aus RFC 2048 sollte neue Bezeichnungen prüfbar und dokumentiert machen. So betrachtet war RFC 3073 eine reale Verbesserung der Koordination, ohne dass die öffentliche Registrierung Eigentümerin der darunterliegenden Implementierungskette wurde.

Running-Code Primacy bietet dafür eine spätere analytische Linse. Die relevante Kette beginnt beim registrierten Namen, führt über eine verfügbare, versionierte Spezifikation, einen gepflegten Decoder, die Handler-Zuordnung und eine bestimmte Eingabe bis zur erfolgreichen Analyse und beobachteten Darstellung. Reality Layers stellt ergänzend die Frage, ob die symbolische Autorität eines öffentlichen Namens dort eine ausführbare Grundlage besitzt, wo die Behauptung wirksam werden soll. Beides sind spätere Deutungsrahmen; sie dürfen Collins, Bitstream, IANA oder IETF nicht zugeschrieben werden.

Die Lehre lautet nicht, dass extern gepflegte Formate nicht über öffentliche Register koordiniert werden dürfen. Häufig ist genau das notwendig. Der Befund zeigt auch nicht, die PFR-Spezifikation sei geheim oder unzugänglich gewesen: RFC 3073 nannte ausdrücklich die Bereitstellung auf Anfrage und eine Webadresse. Entscheidend ist die genaue Trennung. Öffentliche Auffindbarkeit des Namens, Zugänglichkeit des Eintrags, Besitz des vollständigen Formats, Verfügbarkeit kompatiblen Codes und ein korrektes Ausgabeergebnis sind verschiedene Bedingungen. Das Fortbestehen einer Bedingung konserviert die anderen nicht automatisch.

RFC 3073 machte den Namen dauerhaft genug, damit Sender und Empfänger auf denselben behaupteten Inhaltstyp verweisen konnten. Das war echte Infrastruktur. Ebenso real war ihre Grenze: Das Register konnte sagen, wie die Kapsel hieß und wo die Dokumentation nach damaliger Angabe lag. Was ein bestimmter Empfänger mit den Bytes tatsächlich tun konnte, zeigten erst Spezifikation, Implementierung und beobachtete Ausgabe gemeinsam.

Quellen