Zusammenfassung

  • RFC 1874 sah text/sgml für Inhalte vor, deren allgemeiner Sinn ohne SGML-Software erkennbar blieb. Für die übrigen Entitäten galt application/sgml.
  • charset, SGML-bctf und SGML-boot bezeichneten unterschiedliche Schritte: Textdarstellung, Umwandlung logischer Bitkombinationen in Oktette und einen Verweis auf eine gesonderte Boot-Komponente.
  • SGML-Systeme konnten laut RFC Befehle auf Systemebene zulassen. Lesbarkeit war daher kein Sicherheitsurteil; die spätere Abtrennung von XML zeigte zusätzlich, dass gemeinsame Syntax keine austauschbaren Prozessoren schafft.

Die Typwahl regelte zuerst den Ausfall

RFC 1874 begann nicht mit dem vollständig ausgestatteten Empfänger. Es plante den Fall ein, dass MIME vorhanden war, SGML aber nicht. Der RFC 1874 empfahl text/sgml, wenn ein Mensch den Inhalt ohne SGML-Anzeige leicht erkennen konnte. Jeder durch SGML-Start und -Ende begrenzte Datensatz musste einer Zeile im MIME-Teil entsprechen.

Damit blieb eine einfache Ansicht möglich. Sie versprach nicht, dass Hierarchie, Entitätsverweise oder Präsentationsanweisungen erhalten blieben. Der Leser konnte die Aussage verstehen und dennoch eine andere Darstellung sehen als vom Autor vorgesehen.

Für Entitäten, deren Sinn an spezialisierter Verarbeitung hing, war application/sgml vorgesehen. Die Grenze bewertete nicht die Wichtigkeit des Dokuments, sondern die vertretbare Degradation bei fehlender Fähigkeit.

RFC 2046 erklärte das allgemeine MIME-Prinzip. Ein Haupttyp liefert selbst bei unbekanntem Subtyp Hinweise. Unbekannter Text kann als Rohtext angezeigt werden; bei Bild oder Audio wäre das nicht sinnvoll. Text-Subtypen sollten deshalb eine allgemeine Vorstellung ohne Spezialsoftware zulassen.

Der Haupttyp war eine Regel für Unwissen. Er war kein Freibrief für bekannte Parser.

Drei Metadatenfelder führten zu drei Entscheidungen

Der charset-Parameter half dem einfachen Textpfad. SGML-bctf beschrieb dagegen, wie die konstant breiten Bitkombinationen des SGML-Modells in den übertragenen Oktettstrom verwandelt worden waren. Neben identity nannte RFC 1874 feste und variable Formate.

Ein Empfänger konnte den Medientyp kennen und das angekündigte BCTF nicht implementieren. Er konnte plausible Zeichen zeigen, ohne die Zeichennummern der SGML-Deklaration richtig wiederherzustellen. Die Parameterangabe dokumentierte die Behauptung des Senders, nicht den Ablauf beim Empfänger.

SGML-boot enthielt überhaupt keine Boot-Daten. Der Wert war die Content-ID eines anderen MIME-Teils vom Typ application/octet-stream. Dort lagen Zahlentripel, die die für die SGML-Deklaration nötige Zeichenzuordnung beschrieben. Das galt nur für Dokumententitäten.

Ein Verweis belegte nicht, dass das Ziel vorhanden war. Der Teil konnte fehlen, eine ID konnte doppelt vorkommen, oder ein Gateway konnte die Multipart-Beziehung beschädigen. Nach dem Auffinden blieben das Lesen der Tripel und das Parsen der Deklaration offen.

Der RFC 1590 schuf ein öffentliches Registrierungsverfahren für Medientypen. Es machte Namen und Spezifikation auffindbar. Es prüfte weder die einzelne Übertragung noch die installierte Implementierung.

Das Parsen öffnete eine neue Berechtigungsfläche

Der Sicherheitshinweis von RFC 1874 passte nicht zur Vorstellung von passivem Text. SGML-Entitäten wurden vom Empfängersystem geparst und verarbeitet. Manche Systeme konnten explizite Befehlsfolgen auf Systemebene zulassen; Verarbeitungsanweisungen für Satz und Präsentation brachten Risiken ähnlich PostScript.

Eine Zeile zu sehen und dieselbe Zeile einem SGML-System zu übergeben waren deshalb verschiedene Handlungen. Der erste Weg konnte mit geringen Rechten auskommen. Der zweite aktivierte Struktur, Referenzen und möglicherweise ausführbare Funktionen.

Ein korrekt erzeugter Syntaxbaum bewies noch keine Erlaubnis für Befehle. Ein blockierter Befehl machte die Textansicht nicht wertlos. Ein Fehler vor dem Parsing sagte nichts über die semantische Qualität. Der Status „geöffnet“ wäre für alle drei Fälle zu grob.

MIME verlangte zugleich, unbekannte Parameter zu ignorieren. Das half älteren Programmen, neue Umschläge zu tolerieren. Für ein Dokument, das SGML-boot benötigte, konnte dieses Ignorieren aber eine getreue Verarbeitung verhindern. Umschlagkompatibilität war nicht Anwendungsinteroperabilität.

XML erbte die Grammatik, nicht den Implementierungsbeleg

XML war als Teilmenge von SGML beschrieben. Trotzdem führte der RFC 2376 text/xml und application/xml ein. Viele XML-Anwendungen verstanden den größeren SGML-Funktionsumfang nicht. SGML-Anwendungen verstanden nicht zwingend die von XML genutzten Korrekturen. Die SGML-Parameter BCTF und boot waren für XML bedeutungslos und hätten Mehrdeutigkeit geschaffen.

Die Teilmengenbeziehung gehörte zur Spezifikation. Sie war keine Messung laufender Programme.

Der RFC 3023 entwickelte für anwendungsspezifische XML-Formate das Suffix +xml. Der vollständige Typ behielt die Fachsemantik, während das Suffix eine gemeinsame Syntax für generische Werkzeuge sichtbar machte.

RFC 6838 regelte später die Registrierung strukturierter Syntaxsuffixe und verlangte Angaben zu Kodierung, Interoperabilität, Fragmenten und Sicherheit. Die Registrierung schuf überprüfbare Dokumentation, aber keine installierte Unterstützung.

RFC 7303 ließ Software +xml erkennen, die Annahme mit einem XML-Prozessor prüfen und erst danach typspezifisch weiterarbeiten. Wenn generische XML-Verarbeitung unpassend war, konnte ein Format auf das Suffix verzichten. Ein Hinweis eröffnete eine Prüfung; er befahl keine Verarbeitung.

Auch Dokumente, externe DTD-Teilmengen, externe geparste Entitäten und externe Parameterentitäten blieben getrennte Rollen. Gemeinsame XML-Syntax machte sie nicht austauschbar.

Ein Registereintrag war kein Laufzeitprotokoll

Die Kette begann mit der Typwahl und endete erst beim nützlichen Ergebnis. Dazwischen lagen Empfang, Header-Parsing, BCTF, Boot-Auflösung, Deklaration, Sicherheitsentscheidung und Anwendung. Für jede Stufe konnte ein anderer Beleg existieren.

RFC 1874 beweist die veröffentlichte Konstruktion und ihre Warnung. Es beweist keine Verbreitung, kein Verhalten eines genannten Produkts, keinen ausgeführten Befehl und keinen Schaden. Gerade diese Begrenzung macht die Lektion belastbar: Lesbarkeit minimierte den Ausfall, ohne die Macht des Interpreters zu verkleinern.

Quellen und Grenzen

RFC 1590, 1874 und 2046 dokumentieren Registrierung, SGML-Typen und MIME-Fallback. RFC 2376, 3023, 6838 und 7303 dokumentieren die XML-Abtrennung und Syntaxsuffixe. Sie belegen weder heutige Nutzung noch Produktkonformität, erfolgreiche Ausführung, Angriff oder wirtschaftliches Ergebnis.