Zusammenfassung

  • RFC 3459 setzte Handling=REQUIRED|OPTIONAL an einzelne MIME-Teile: Konnte ein REQUIRED-Teil nicht passieren, scheiterte die ganze Nachricht; ein OPTIONAL-Teil durfte still verschwinden.
  • Unmarkierte Teile und unbekannte Werte galten als REQUIRED; bei Signatur und Verschlüsselung entschied der Ort der Markierung über Transformation oder Ablehnung.

Teilzustellung brauchte einen Verlustvertrag

Allgemeine Internet-Mail erwartete, dass ein MIME-Empfänger jeden Teil bewahrte oder zugänglich machte, auch ohne Betrachter. Ein Sprachsystem konnte Audio und Fax speichern, aber kein Video oder Binärdokument. Ein Gateway kannte die Zielkapazität und musste gelegentlich Unverarbeitbares entfernen.

RFC 3459 machte diese Transformation im Januar 2003 sichtbar. Text, RFC-Editor-Eintrag, Datatracker, Historie, Referenzen, Zitate und Errata bilden die Akte. Es aktualisierte RFC 3204 und löste Handling vom ISUP/QSIG-Transport.

Als Parameter von Content-Disposition bedeutete REQUIRED, dass der Absender ohne diesen Teil keine Zustellung anerkannte. Ein Fehlschlag ließ alles scheitern. OPTIONAL erlaubte stille Löschung und verbot eine Fehlermeldung, solange kein REQUIRED-Teil ebenfalls ausfiel. Das war keine Wichtigkeitsskala, sondern eine Zuweisung von Transformationsrecht und Folge.

Löschen, Scheitern und Benachrichtigen waren getrennt

Ohne Markierung galt REQUIRED; unbekannte künftige Werte ebenfalls. Damit löschte ein Gateway nicht still eine Semantik, die es nicht verstand. RFC 2045 lieferte MIME, RFC 2421 den Sprachsystemkontext.

Kritikalität verlangte nicht automatisch einen Beleg. DSN folgte RFC 3461, MDN RFC 3798, nicht unterstützte Medien konnten 5.6.1 aus RFC 3463 verwenden. Vor endgültiger Zustellung erzeugte ein Gateway DSN, danach als Benutzeragent MDN; SIP nutzte Statusantworten wie 415. Rolle und Topologie bestimmten den Beleg.

Bei Kryptografie wurde der Markierungsort zur Politik

Nach RFC 1847 verlangte ein REQUIRED-multipart/signed unversehrte Passage und Ende-zu-Ende-Prüfung. Ein REQUIRED-Signaturkontrollobjekt erlaubte Gateway-Prüfung, doch eine ungültige Signatur erzwang Ablehnung. War Signatur OPTIONAL und Material REQUIRED, durfte das Gateway Signaturdaten entfernen, obwohl Prüfung und Manipulationshinweis empfohlen blieben. RFC 2480 gab verwandte Regeln.

Ein REQUIRED-Verschlüsselungskontrollobjekt verlangte Ende-zu-Ende-Verschlüsselung. OPTIONAL erlaubte einem fähigen Gateway, zu entschlüsseln und Klartext an ein unfähiges Ziel weiterzugeben. Eine Markierung innerhalb verschlüsselter Daten war ohne vorherige Entschlüsselung unsichtbar; unmarkierter Chiffretext blieb deshalb REQUIRED.

RFC 3238 stellte Zustimmung und Benachrichtigung in den OPES-Rahmen. Heng Lus spätere Realitätsschichten trennen Markierung, Fähigkeit, tatsächliche Transformation und Ergebnis. Vorrang laufenden Codes verlangt den Vergleich der MIME-Bäume. Das sind spätere redaktionelle Perspektiven.

RFC 3459 machte unsichtbaren Teilverlust zu einer erklärten Folgenverteilung. Ein optionaler Teil durfte verschwinden; ein winziger erforderlicher Teil konnte alles stoppen.

Quellen