Zusammenfassung

  • RFC 1197 beschrieb ODA als abstrakte Architektur für zusammengesetzte Dokumente. Praktischer Austausch verlangte zusätzlich ein Document Application Profile und eine Abbildung auf das native Modell jedes Systems.
  • Das NSF-finanzierte EXPRES-Projekt arbeitete mit einem NIST-Profil sowie den Funktionen von Andrew, Diamond und Interleaf. Der kurze RFC berichtet weder gemessene Wiedergabetreue noch Round Trips oder Verbreitung.
  • Spätere MIME/X.400-Regeln behandelten ODA-Daten, profile und Dokumentklasse getrennt. Eine Byte-Kopie bewies unveränderte Daten, nicht gleiche Interpretation, Darstellung oder Editierbarkeit.

Die größte Spezifikation war nicht automatisch der gemeinsame Nenner

Ein umfangreicher Standard kann viele Systeme beschreiben und gerade deshalb mehr Optionen enthalten, als zwei konkrete Implementierungen gemeinsam beherrschen. Die RFC 1197 machte aus dieser Spannung kein Randproblem. Sie erklärte ein Profil zur Voraussetzung für wirksamen Austausch.

Das Document Application Profile, DAP, definierte gemeinsame Entitäten innerhalb von ODA. Anschließend benötigte jedes System eine Abbildung zwischen diesen Profilentitäten und seinen eigenen Entitäten. Das Profil bestimmte die transportable Zusage; der lokale Adapter bestimmte deren Ausführung.

Damit wurde „ODA-kompatibel“ zu einer unvollständigen Behauptung. Zwei Programme konnten dieselbe Formatfamilie erkennen und verschiedene Profile einsetzen. Sie konnten dasselbe Profil nennen und optionale Eigenschaften oder Erweiterungen unterschiedlich behandeln. Die belastbare Schnittmenge musste Profil, Version, Klasse, Erweiterungen und beide lokalen Abbildungen einschließen.

Ein schmaleres Profil war keine schwächere Architektur. Es verwandelte einen großen Möglichkeitsraum in einen prüfbaren Vertrag. Produktinterne Funktionen durften reicher bleiben, ohne stillschweigend zu portablen Funktionen erklärt zu werden.

ODA lag eine Abstraktionsstufe über dem Absatz

Mark Sherman veröffentlichte RFC 1197 im Dezember 1990 über Erfahrungen mit ISO 8613 Office Document Architecture. Der RFC-Editor-Eintrag und der IETF-Datatracker-Eintrag führen das Dokument als Informational. Es definierte keinen Internet Standard.

ODA konnte laut Memo mehrschriftigen Text, Rasterbilder und geometrische Grafik darstellen und war für verwandte Standards wie X.400 vorgesehen. Die Architektur sollte zusammengesetzte Dokumente offen repräsentieren, nicht die Speicherstruktur eines Herstellers kopieren.

Der RFC nennt ODA jedoch sehr abstrakt. Es definierte etwa „composite logical object classes“, nicht gewöhnliche Anwendungsentitäten wie Absätze. Das ist keine Aussage, dass ODA niemals eine absatzähnliche Struktur tragen konnte. Die engere Aussage lautet: Die allgemeine Architektur hatte noch nicht die gemeinsame Anwendungsentität und ihre erwartete Bedeutung gewählt.

Die Neutralität war ein Vorteil des Kerns. Sie verhinderte, dass ein lokales Modell automatisch zur Verfassung aller anderen wurde. Gleichzeitig verschob sie konkrete Entscheidungen an Profile und Randimplementierungen.

EXPRES machte aus drei Editoren keine identischen Maschinen

Die National Science Foundation finanzierte EXPRES, um Forschungsanträge als ODA-Dokumente per E-Mail einzureichen. Gruppen der Carnegie Mellon University und der University of Michigan arbeiteten mit McDonnell-Douglas Aerospace Information Systems, NIST und Interleaf zusammen.

Die Strategien beruhten auf dem NIST DAP und den Funktionen von Andrew, Diamond und Interleaf. Schon diese Formulierung zeigt die praktische Oberfläche: Ein gemeinsames Profil traf auf drei verschiedene lokale Funktionsmodelle.

Der RFC umfasst nur zwei Seiten. Die vollständigen Strategien verweist er in ein Buch von 1991, das diesem Quellenpaket nicht vorliegt. Es gibt im Memo keine Konversionsquote, keinen visuellen Vergleich, keinen Round-Trip-Test, keine Laufzeitmessung und keine Aussage über die Annahme eines bestimmten Antrags.

Die beteiligten Namen belegen die Herkunft der beschriebenen Untersuchung. Sie sind keine dauerhaften Konformitätszeichen. Zudem ordnet der Disclaimer den ausführlicheren Bericht den Ansichten seiner Autoren zu, nicht der Politik der Institutionen.

MIME schrieb das Profil neben den Medientyp

Die RFC 1341 definierte 1992 im frühen MIME den Subtype application/oda. Er kennzeichnete einen nach ODA in ODIF repräsentierten Body. Der Content-Type sollte außerdem mit profile das DAP benennen; das Beispiel lautete profile=Q112.

Die zwei Felder beantworteten zwei Fragen. Der Subtype identifizierte die Repräsentationsfamilie. Das Profil begrenzte den Anwendungsvertrag innerhalb dieser Familie. Wäre „ODA“ semantisch vollständig gewesen, hätte der zusätzliche Parameter keine Aufgabe gehabt.

Ein Header blieb eine Behauptung. Er konnte bei der Auswahl eines Handlers helfen. Er bewies weder, dass der Empfänger Q112 richtig implementierte, noch dass alle verwendeten Entitäten bekannt waren oder Layout und editierbare Struktur erhalten blieben.

RFC 1341 ist inzwischen obsolet. Sie dient hier als historisches Protokoll dieser Trennung, nicht als aktuelle MIME-Anleitung.

Die Byte-Kopie ließ Metadaten und Auslegung sichtbar

Die RFC 1494 regelte 1993 Äquivalenzen zwischen X.400- und MIME-Body-Parts. Für ODA bezeichnete sie die Body-Konversion als „Byte copy“. Die ODA-Daten mussten beim Übergang nicht umcodiert werden.

Separat wurde der X.400-Object-Identifier für das Document Application Profile in den MIME-Parameter profile übersetzt. Die Document Architecture Class wurde auf formatted, processable oder formatted-processable abgebildet.

Damit hatten Daten, Profil und Klasse getrennte Belege. Unveränderte Body-Bytes sagten nichts über die Fähigkeiten des Empfängers oder seine lokale Abbildung. Eine processable-Struktur konnte intakt übertragen und anschließend dennoch in ein ärmeres natives Modell fallen.

Fehlten bei MIME-zu-X.400 Profil oder Klasse, setzte RFC 1494 Q112 und formatted-processable als Defaults. Der Gateway-Implementierer durfte die Werte im Dokument suchen, musste es aber nicht, weil die internen Merkmale optional waren.

Ein Default macht Verhalten deterministisch, nicht die Absicht des Absenders sichtbar. Ein späterer Nachweis muss daher deklarierte, extrahierte und durch Regel ergänzte Werte unterscheiden.

„Conversion: None“ war keine Aussage über das Ergebnis

Die RFC 2161 zog die ODA-Regeln 1998 in ein eigenes Experimental-Dokument. Sie erklärte ausdrücklich, kein Internet Standard irgendeiner Art zu sein. profile, class, Q112 und die drei Klassen blieben erhalten.

In ihrer Tabelle stand für die ODA-Daten „Conversion: None“. Gemeint war, dass der Body ODA blieb. Profil- und Klassenabbildung, Defaults, Envelope-Identifier und Auslegung durch den Empfänger blieben notwendig.

Der Sicherheitsabschnitt warnte vor komplexen Strukturen, deren Fähigkeiten schwer zu ermitteln seien. Durch Erweiterbarkeit könnten neue Inhaltsteile die Bedrohung im Laufe der Zeit verändern. Zugleich waren damals keine ODA-spezifischen Risiken bekannt. Das begründet Inventarisierung und erneute Prüfung, nicht die Behauptung eines historischen Exploits.

Ein stabiler Medientyp überlebt oft wechselnde Profile, Parser und Adapter. Unterstützung ist deshalb an Artefakt, Version und beobachtetes Ergebnis gebunden.

Dekodieren war nur eine Zwischenstufe

Die Beweiskette beginnt mit ODIF-Bytes. Danach folgen Typ, Herkunft des Profils, Klasse, Gateway-Aktion, Empfängerfähigkeit und lokale Abbildung. Erst dann kommen Darstellung, erhaltene Struktur, Editierbarkeit, Round Trip und institutionelles Ergebnis.

Ein Hash belegt Byte-Identität. Ein Profil benennt den beanspruchten Teilvertrag. Eine Adapterversion nennt die ausgeführten Regeln. Der Vergleich der Ausgabe zeigt erst, was mit Seite und Struktur geschah. Keine Stufe darf die Autorität der nächsten übernehmen.

Der Absatz in RFC 1197 ist daher kein Urteil gegen Abstraktion. Er zeigt ihre Arbeitsteilung. Eine dünne gemeinsame Mitte erlaubt unabhängige Systeme. Das Profil wählt die gemeinsame Sprache, die Ränder übernehmen die Übersetzung, und der Empfänger entscheidet anhand des Resultats.

Quellen und Grenzen

Die Quellen belegen keine heutige Nutzung, keinen Marktanteil, keine Produktqualität, keine gemessene EXPRES-Treue, keinen bekannten Sicherheitsvorfall und keinen erfolgreichen Einzelantrag.