Zusammenfassung

  • RFC 2157 nannte eine gerichtete Transformation Abbildung; Äquivalenz erforderte zwei Abbildungen, die zusammen eine verlustfreie Hin- und Rückumwandlung ergaben.
  • Eine Kapselung konnte das Ursprungsformat für ein späteres Gateway bewahren, ohne dem Zwischensystem verständlichen oder nutzbaren Inhalt zu versprechen.
  • Gleiche Bytes, ein überzeugender Dateiname oder eine erfolgreiche erste Umwandlung waren daher Teilbelege; Rückregel, Metadaten, Nutzbarkeit und Empfängergebnis blieben getrennt.

Das Gleichheitszeichen stand hinter zwei Pfeilen

RFC 2157 erschien im Januar 1998 als Body-Part-Ergänzung zu MIXER. RFC 2156 behandelte die umfassende Kopplung von X.400 und RFC-822/MIME-Mail; das Begleitdokument regelte Text, Anhänge, weitergeleitete Nachrichten, Multipart-Strukturen sowie signierte und verschlüsselte Inhalte.

Das Glossar legte zugleich den Test fest. Eine mapping rule beschreibt die Transformation eines X.400 Body Part in einen MIME Body Part oder den umgekehrten Weg. Eine equivalence besteht aus zwei solchen Regeln, die gemeinsam eine verlustfreie Umwandlung zwischen den Darstellungen liefern.

Damit endet ein Beleg nicht bei einem syntaktisch gültigen X.400-Ergebnis. Das Rück-Gateway kann eine andere Regel wählen, die inverse Regel nicht implementiert haben oder verworfene Parameter nicht wieder einsetzen können. Parsererfolg beweist eine erreichbare Ausgabe. Er beweist nicht, dass die Verkettung zum Eingang zurückführt.

Kapselung sicherte Verwahrung, nicht Verständnis

Die dritte Beziehung war die Kapselung. Ein Objekt aus einem Mailsystem wurde so verpackt, dass es im anderen transportiert werden konnte. Das Zwischensystem musste daraus keinen sinnvollen Inhalt gewinnen; ein Gateway zurück ins Ausgangssystem sollte das ursprüngliche Format verlustfrei rekonstruieren können.

FTBP- und BP15-Behälter konnten MIME-Typ, Parameter, Header und kanonische Oktette aufnehmen. Umgekehrt transportierte application/x400-bp einen erweiterten X.400 Body Part durch MIME. Der Dienst galt einem späteren Entkapsler, nicht dem Anzeige- oder Bearbeitungsprogramm des Zwischenziels.

Der Text beschrieb außerdem BP14 content passing auf derselben begrifflichen Ebene, nannte es aber ausdrücklich verlustbehaftet. Header wurden entfernt, das Transfer-Encoding aufgehoben und nur der Oktettstrom behalten. Eine Rückübersetzung des MIME-Typs war nicht definiert; zurück kam application/octet-stream. Die Datenmasse blieb, ihr Typnachweis nicht.

Ein Dateiname durfte auswählen, aber nicht entscheiden

Weil sich beide Mailwelten bei Nicht-Text-Inhalten bewegten, räumte RFC 2157 den Gateways Auswahlfreiheit ein. Sie konnten Empfängerfähigkeiten, den Darstellungswunsch des Absenders, Grenzen des nächsten Hops oder Heuristiken aus Inhalt und Dateinamen berücksichtigen. Bei BP14, einer allgemeinen FTAM-Datei oder application/octet-stream durfte eine Endung die Wahl unterstützen.

Doch der Hinweis erhielt keine Autorität. Die Abbildung des filename aus Content-Disposition in einen FTBP pathname behandelte Schrägstriche als gewöhnliche Zeichen im Transport und verlangte normale Sicherheitsmaßnahmen im lokalen Dateisystem. Das Beispiel /etc/passwd zeigte, dass ein übermittelter Name weder einen Speicherort genehmigt noch den Medientyp authentifiziert.

Die zwei vorgeschriebenen Wege für application/octet-stream machen die Trennung greifbar. Ein MIXER-konformes Produkt musste sowohl BilaterallyDefined als auch FTBP Unknown Attachment und eine konfigurierbare Auswahl anbieten. BP14 entfernte MIME-Parameter. FTBP erhielt mehr Dateimetadaten und kopierte die Body-Bytes in beide Richtungen.

Beide Wege konnten gültige Ausgaben erzeugen, schützten aber nicht dieselben Invarianten. Der Verlust von padding konnte die Deutung des letzten Bytes verändern. Die disposition wurde verworfen und beim Rückweg als attachment neu erzeugt. Für ein neues MIME-Feld konnte im gewählten X.400-Typ jeder Platz fehlen. Lokale Gültigkeit machte unterschiedliche Pfade nicht austauschbar äquivalent.

Das Register beschrieb ein reproduzierbares Regelpaar

Eine Registrierung musste MIME-Typ und X.400 Body Part, erforderliche OIDs und ASN.1-Syntax, Algorithmen sowie die Wirkung von conversion prohibited und conversion with loss prohibited nennen. Die Beschreibung sollte eine unabhängige Implementierung ermöglichen.

Das Register zielte auf einheitlicheres Verhalten, nicht auf universelle Pflicht. Ein Gateway musste nicht jede registrierte Übersetzung unterstützen, und nicht jede lokale Umwandlung musste registriert sein. Ein Eintrag belegte eine veröffentlichte technische Vereinbarung. Er belegte weder Produktunterstützung noch Auswahl durch die laufende Konfiguration oder Nutzung am Ziel.

Die Tabellen zeigten definierte Paare für Text, Bilder, weitergeleitete Nachrichten und generische Anhänge; andere Typen führten zur Kapselung. Signierte und verschlüsselte Multiparts benötigten einen schonenden Weg, weil eine Umwandlung zum vermeintlich nativen Format gerade die kryptografische Eigenschaft zerstören konnte.

Der Rückweg muss die Auswahl mitbelegen

Ein belastbarer Test fixiert Eingangsbytes, Header, Parameter und Verschachtelungsposition. Er hält Tabellenversion und Selektionsdaten fest: Empfängerfähigkeit, Absenderwunsch, Heuristik und nächster Hop. Danach dokumentiert er Ausgabe, verschobene Felder und Verluste, führt die benannte Rückabbildung aus und vergleicht mit dem Original.

Selbst ein perfekter Darstellungs-Roundtrip beweist keine Nutzung. Dem Empfänger kann ein Handler fehlen. Der Name kann gegen lokale Regeln verstoßen. Verschlüsselter Inhalt kann absichtlich undurchsichtig bleiben. Zustellung, sicheres Öffnen, Darstellung und menschliches Verständnis sind spätere Beobachtungen.

Lu Hengs Primat des laufenden Codes liefert eine redaktionelle Lesart: Tabelle und Algorithmus beschreiben eine Möglichkeit; ausgeführtes Regelpaar und Vergleich bilden den Betriebsbeleg. Die minimale Anfangsspezifikation begrenzt die gemeinsame Schicht auf das reversible Paar, ohne Empfängerpolitik zu zentralisieren. Die Realitätsebenen trennen Register, Implementierung, Auswahl, erhaltene Bytes, nutzbares Objekt und beobachtetes Ergebnis.

RFC 2157 versprach nicht, dass jeder Body Part überall verständlich wird. Das Dokument machte die Aussage prüfbar: ein Pfeil war eine Abbildung, zwei verlustfrei schließende Pfeile waren Äquivalenz, und Kapselung durfte Bewahrung und Verständnis absichtlich auseinanderhalten.

Quellen