Zusammenfassung

  • Der alte Weg nutzte einen parameterlosen Extended Body Part mit OCTET STRING und der OID mime-postscript-body; der empfohlene Weg identifizierte einen FTAM Body Part über id-mime-ftbp-postscript in dessen application-reference.
  • „No conversion“ bezog sich auf den kopierten Oktettstrom. Es bestätigte weder die Trägerfähigkeit des Empfängers noch FTAM-Einführung, korrekte PostScript-Auswertung, sichere Ausführung oder sichtbaren Erfolg.

Ein unversehrter Inhalt kann in der falschen Kassette ankommen. Die Prüfsumme sagt dann die Wahrheit und reicht trotzdem nicht aus. Genau diese Lage machte RFC 2160 in einer kurzen Spezifikation sichtbar.

Das Dokument erschien im Januar 1998 für die Verbindung von PostScript in X.400 und MIME. Es tilgte den alten Mechanismus nicht, sondern trug ihn weiter und empfahl zugleich FTAM. Damit beschrieb es keinen abgeschlossenen Wechsel, sondern eine reale Übergangsphase.

Zwei Stellen, an denen Identität entstand

Der Extended Body Part stammte aus RFC 1494. Seine Daten waren ein OCTET STRING; Parameter gab es nicht. mime-postscript-body lag unter { mixer-bp-data 2 }. RFC 1494 hatte die Abbildung auf application/postscript als Byte Copy bezeichnet.

Beim FTAM Body Part stand die Identität in FileTransferParameters.environment.application-reference. Dort musste id-mime-ftbp-postscript mit der OID { mixer-bp-data 6 } erscheinen.

Die Unterschiede waren für Implementierungen sichtbar. Ein System konnte EBP kennen, ohne das FTAM-Profil zu unterstützen. Die Empfehlung schuf keine automatische Fähigkeit. Umgekehrt bewies die fortdauernde Definition des alten Weges nicht, dass er vorzuziehen war; sie hielt den Übergang interoperabel.

RFC 2157 behandelt Extended Body Parts und FTAM als getrennte Typen. RFC 2156 formuliert für MIXER Ziele wie konsistentes Gateway-Verhalten, Informationsbewahrung und möglichst reversible Abbildung. Solche Ziele sind Vorgaben für die Konstruktion, keine Messwerte einer konkreten Zustellung.

Was „keine Konvertierung“ tatsächlich bewies

Für beide Wege schrieb RFC 2160 Conversion Type: No conversion. Auf beiden Seiten lag ein einzelner Oktettstrom vor; er konnte ohne weitere Datenumformung kopiert werden.

Stimmen Prüfsummen vor und nach dem Gateway überein, ist die Integrität der Nutzlast gut belegt. Die äußere Darstellung war dennoch nicht gleich: Ein X.400-Body-Part wurde als MIME-Medientyp ausgedrückt, und innerhalb von X.400 musste seine konkrete Klasse erkannt werden.

Wer nur den extrahierten PostScript-Strom archiviert, bewahrt den Inhalt und vernichtet zugleich die Transportaussage. Später lässt sich weder der empfangene Trägertyp noch ein mögliches Fallback beweisen.

Der richtige Typ kann zu einer richtigen Ablehnung führen

RFC 2160 verwies für application/postscript auf RFC 1521. RFC 2046 beschreibt den Inhalt als PostScript-Programm und empfiehlt die Document Structuring Conventions. Ohne brauchbare Struktur kann ein System nicht zuverlässig vorhersagen, ob das Dokument in seiner Umgebung funktioniert, und darf es zurückweisen.

PostScript-Ausführung besitzt zudem erhebliche Sicherheitsflächen: Dateioperationen, dauerhafter Interpreterzustand, Systemparameter, nicht standardisierte Erweiterungen und unbegrenzter Ressourcenverbrauch. Ein sicherer Client kann Operatoren sperren oder die Darstellung ablehnen. Unveränderte Bytes und keine Ausgabe widersprechen sich dann nicht.

Der RFC-Editor-Eintrag und der Datatracker-Eintrag bestätigen Herkunft und Status. Die Errata-Suche liefert derzeit keinen Treffer. Keine dieser Quellen bestätigt eine bestimmte Produktfähigkeit.

Belege in der richtigen Reihenfolge

Erstens ist die Nutzlast zu hashen. Zweitens sind X.400-Klasse und OID festzuhalten. Drittens braucht es eine Empfängermatrix für beide Träger. Viertens müssen MIME-Einstufung und Interpreterrichtlinie protokolliert werden. Fünftens ist das Ergebnis zu erfassen: Darstellung, Druck, Quarantäne oder Fehler.

Heng Lus Minimum Initial Specification hält gemeinsame Regeln eng und überprüfbar. Running-Code Primacy fragt nach tatsächlich gesendeten und akzeptierten Formen. Die Trennung der Reality Layers verhindert, dass Kennzeichnung, OID, Hash und Nutzerausgabe als ein und derselbe Befund gelten.

RFC 2160 machte den Inhaltstransport bewusst einfach. Die spätere Beweisführung darf deshalb nicht alles andere vereinfachen. Gleiche Bytes sind ein sauberer Befund, aber kein universelles Interoperabilitätszertifikat.

Quellen