Zusammenfassung

  • RFC 5385 beschrieb eine Word-Vorlage, deren Vorschau und Ausdruck dem RFC-konformen ASCII zeilen- und seitenweise entsprechen konnten; die Textausgabe entstand dennoch erst über definierte Styles, einen Textdruckertreiber und ein Perl-Nachbearbeitungsprogramm.
  • Visuelle Gleichheit ist deshalb ein Darstellungsnachweis, kein Nachweis der maßgeblichen Quelle. Die heutige RFC-Politik trennt die definitive RFCXML-Version von den daraus erzeugten Veröffentlichungsfassungen in HTML, Text und PDF.

Fünf Quittungen statt eines grünen Status

Die erste Quittung lautet: Diese Quelldatei enthält die freigegebene Aussage. Die zweite: Diese Vorlage und diese Werkzeuge haben sie verarbeitet. Die dritte: Diese Ausgabedatei ist daraus entstanden. Die vierte: Diese Stelle hat genau diesen Stand veröffentlicht. Die fünfte: Frühere Stände können weiterhin gefunden und geprüft werden.

Viele Systeme liefern nur die dritte Quittung. Ein PDF ist vorhanden, und seine Seiten sehen richtig aus. Daraus werden die übrigen Behauptungen abgeleitet, obwohl das PDF weder seine Quelle noch seine Befugnis mitbringt.

RFC 5385 zeigt die Lücke in einem historischen, gut dokumentierten Aufbau. Das 2010 als Informational Independent Submission veröffentlichte Dokument beschrieb Version 2.0 einer Microsoft-Word-Vorlage für Internet-Drafts und RFCs. Sie bot Outline-Funktionen und eine direkte Ansicht, die dem konformen ASCII bis auf kleinere typografische Ausnahmen Zeile für Zeile und Seite für Seite gleichen konnte.

Der Text entstand aber nicht durch bloßes Speichern. Word druckte über Generic/Text Only in eine .prn-Datei. Ein Perl-Programm entfernte Wagenrückläufe, normalisierte Anführungszeichen und Bindestriche, bereinigte Seitenübergänge, setzte Seitenvorschübe und prüfte unzulässige Zeichen.

Die Vorschau war also eine gute Annäherung an das Ergebnis. Sie war nicht das Ergebnis und erst recht nicht dessen Herkunftsnachweis.

Styles waren ausführbare Dokumentlogik

Die Vorlage definierte Normal, Heading1 bis Heading9, Header, Footer und Caption neu und ergänzte Styles für Abbildungen, Listen, Literatur und Anhänge. Andere Styles sollten nicht verwendet werden.

Das diente dem Outline-Modus. Ein Abschnitt konnte hoch- oder herabgestuft und neu nummeriert werden. Ein manuell fett gesetzter Absatz mochte wie eine Überschrift aussehen, ohne sich wie eine Überschrift zu verhalten.

Damit wird ein Grundfehler visueller Abnahmen sichtbar. Menschen erkennen Formen; Werkzeuge brauchen Struktur. Unterstrichener blauer Text ist nicht zwangsläufig ein Link. Abstände ergeben keine Tabelle. Eine Bilddatei mit Buchstaben ist kein zugänglicher Absatz.

Zur Abnahme gehört deshalb ein Strukturbericht: Überschriftenhierarchie, Lesereihenfolge, Verweisziele, Alternativtexte, Referenzen, Felder und Kennungen. Die Sichtprüfung bleibt wichtig, aber sie darf die maschinenlesbare Ebene nicht stellvertretend freigeben.

Der Konverter ist ein verantwortlicher Akteur

Ein Programm, das „nur“ typografische Zeichen ersetzt, trifft Entscheidungen. Bei gewöhnlichen englischen Anführungszeichen ist der Effekt banal. Bei Namen, Formeln oder Protokollkennungen kann eine Ersetzung Bedeutung vernichten. Das Entfernen vermeintlicher Kopf- oder Fußzeilen kann ebenfalls Inhalt treffen.

RFC 5385 legte das Perl-Programm im Anhang offen. Das machte seine Regeln prüfbar. Für einen konkreten Lauf waren trotzdem die tatsächlich eingesetzte Kopie, ihre Umgebung, die Eingabe, Warnungen, der Exit-Status und die Ausgabe nötig.

Heute sollte jeder wichtige Erzeugungsvorgang diese Daten automatisch liefern. Hash der freigegebenen Quelle, Identität von Vorlage und Renderer, Konfiguration, Zeit und Hash der Ausgaben. Bei absichtlich variablen Feldern muss feststehen, welche Unterschiede erwartet werden. Zusätzlich zum visuellen Vergleich braucht es einen semantischen: Anforderungen, Verweise, Links, Textreihenfolge, Beschreibungen und Unicode.

„Mit dem Standardwerkzeug erzeugt“ ist keine hinreichende Aussage. Standards haben Versionen, Werkzeuge haben Optionen, Läufe haben Ergebnisse. Verantwortung entsteht durch konkrete Zuordnung.

Ein stabiler Name bezeichnete ein veränderliches Artefakt

Die Sicherheitsbetrachtung von RFC 5385 hält fest, dass die Vorlage in der entwickelten und verteilten Form keine Makros enthielt. Der Autor erwog, MD5-Werte für .dot und .pl in das RFC aufzunehmen. Die Vorlage änderte sich jedoch, um aktuelle Boilerplate-Vorgaben abzubilden; ihr Prüfsummenwert wurde daher bei der externen Bereitstellung geführt.

MD5 ist hier historische Beschreibung, keine aktuelle Empfehlung. Entscheidend ist die Konfigurationsfrage: Ein unveränderlicher Erklärungstext verwies auf ein weiterentwickeltes Arbeitsmittel. Der Name allein identifizierte dessen Inhalt nicht.

Unternehmen betreiben solche beweglichen Zeiger als „Standardvertrag“, „freigegebene Berichtsvorlage“ oder „aktuelles Formular“. Ohne Versionsbindung können zwei Dokumente denselben Ursprung behaupten und unterschiedliche Klauseln enthalten.

Jede änderbare Vorlage braucht eine eigene Release-ID, einen Hash, Gültigkeitszeitraum, Verantwortlichen und Änderungsgrund. Das erzeugte Dokument muss diese Provenienz behalten. Automatisch eingefügter Pflichttext ist in expandierter Form zu prüfen; die Freigabe der Vorlage ist keine pauschale Freigabe jeder Ausgabe.

Das Referenzproblem war erst nach einer Änderung sichtbar

Die frühere Vorlage verwaltete Literatur als Endnoten. RFC 5385 erläutert, dass das Löschen der ersten Zitation die Referenz entfernen konnte, obwohl spätere Querverweise fortbestanden. Die Revision nutzte nummerierte Textabsätze und optional Bookmarks für Autor-Jahr-Bezeichnungen.

Vor dem Löschen konnten beide Seiten gleich aussehen. Danach verhielten sie sich anders. Eine statische Musterdatei hätte den Fehler nicht nachgewiesen.

Prüfungen müssen daher Veränderungen auslösen: erste Zitation löschen, Überschrift verschieben, Anhang ergänzen, Abbildung austauschen, Inhaltsverzeichnis und alle Ausgabeformate neu erzeugen. Ein Dokumentensystem ist dann robust, wenn seine zugesicherten Eigenschaften unter normalen Bearbeitungen bestehen.

Die heutige Serie weist Autorität einer semantischen Ebene zu

RFC 6949 beschrieb, warum reines ASCII für Zugänglichkeit, Metadaten, internationale Zeichen, Grafiken und unterschiedliche Geräte nicht mehr genügte. RFC 7990 entwarf einen Formatwechsel. RFC 9720 ersetzte diesen Rahmen 2025 und präzisierte die Begriffe.

RFCXML ist das definitive Format; das darin veröffentlichte RFC ist die definitive Version. HTML, Klartext und PDF sind Publikationsformate, die konkreten Dateien Publikationsversionen. Die definitive Version trägt alle beabsichtigten Informationen und beantwortet Streitfragen über den veröffentlichten Inhalt.

Diese spätere Ordnung macht eine Word-Datei von 2010 nicht rückwirkend definitiv. Sie formalisiert aber eine Grenze, die RFC 5385 praktisch sichtbar machte: Autorenoberfläche, Umwandlung und Verteilung sind verschiedene Ebenen.

Auch ein Unternehmen muss die maßgebliche Ebene benennen. Datenbank, strukturiertes Dokument, signiertes PDF und öffentliche Webseite dürfen nicht ungeklärt um Vorrang konkurrieren. Mehrere Fassungen können offiziell sein; für Abweichungen muss eine Regel bestehen.

Neu erzeugen heißt nicht, Vergangenheit ersetzen

RFC 9720 erlaubt eng begrenzte Neuausgaben, etwa nach Schema- oder Werkzeugänderungen. Die Semantik ist soweit wie möglich zu bewahren, Gründe werden dokumentiert, alte definitive und veröffentlichte Fassungen bleiben zugänglich.

Das ist realistischer als ein absolutes Änderungsverbot. Formate altern, Renderer enthalten Fehler, Zugänglichkeit verbessert sich. Gleichzeitig kann jede Neugenerierung unbeabsichtigt Protokollinformationen verändern.

Ein vollständiger Neuausgabe-Beleg enthält alte und neue Quellen, sämtliche Ausgaben, Hashes, Werkzeugversionen, semantischen Vergleich, Grund und Freigabe. Wer nur die neueste Datei aufbewahrt, hat nicht aktualisiert, sondern überschrieben.

RFC 9920 trennt zudem Politikbildung und -genehmigung von der Umsetzung durch das RFC Production Center und weist die Verantwortung für Publikationswerkzeuge ausdrücklich zu. Werkzeugverantwortung ist keine redaktionelle Vollmacht.

Ein Abnahmetest, der Zuständigkeiten beweist

Eine Testquelle sollte Nicht-ASCII-Namen, tiefe Überschriften, Verweise, Links, Code, Tabelle und eine Abbildung mit Beschreibung enthalten. Quelle und Vorlagenversion werden fixiert. Alle Ausgaben werden in einer sauberen Umgebung mit Protokollen und Hashes erzeugt.

Danach folgen zwei Vergleiche: visuelle Darstellung und extrahierte Semantik. Ein zweiter Rechner muss den Vorgang wiederholen. Eine einzelne Bedeutungsänderung soll erwartbar in allen Fassungen erscheinen; eine reine Layoutänderung darf die Semantik nicht verändern.

Schließlich wird eine Neuausgabe simuliert. Der alte Satz bleibt abrufbar. Eine unbeteiligte Person muss bestimmen können, welche Version maßgeblich ist und wie jede öffentliche Kopie entstand. Erst wenn alle fünf Quittungen zusammenpassen, ist nicht nur die Seite, sondern auch die Verantwortungskette abgenommen.

Quellen