Zusammenfassung

  • RFC 3458 definierte Message-Context als optionalen Hinweis auf die erwartete Interaktion mit der gesamten Nachricht, nicht als verbindliche Aussage über vorhandene MIME-Teile.
  • Ein falscher, unbekannter oder veralteter Kontext durfte lokale Bedienung beeinflussen, aber weder die Übertragung scheitern lassen noch eine schlechtere Darstellung verursachen als ohne das Feld.

Ein Medientyp erklärte nicht die ganze Nutzung

Im Jahr 2003 konnte ein Postfach gewöhnliche Mail, Pager-Hinweise, Fax, aufgezeichnete Sprache und Multimedia zusammenführen. Text war einmal Brief, einmal SMS, einmal Transkript. Eine große zusammengesetzte Nachricht vollständig zu untersuchen, nur um Symbol oder Betrachter auszuwählen, war ebenfalls teuer.

RFC 3458 ergänzte deshalb ein höchstens einmal vorkommendes Kopffeld. Zu den ersten Werten gehörten voice-message, fax-message, pager-message, multimedia-message, text-message und none; ein fehlendes Feld entsprach none. Der Klartext, der RFC-Editor-Eintrag, die Datatracker-Akte, ihre Geschichte, Referenzen, spätere Zitate und die Errata-Suche bilden den belegbaren Normenstand.

Ein Empfänger durfte damit einen Betrachter oder ein Symbol wählen, Nachrichten gruppieren, die Liste ordnen, bei knapper Verbindung reduzieren oder eine Antwortform vorschlagen. Keine dieser Funktionen bewies, dass Audio, Faxbild oder Programm wirklich im Körper lag.

Ein Gateway konnte Medium und Geschichte trennen

Das prägnante Beispiel war eine Sprachnachricht, deren Audio ein Gateway entfernte, während ein Transkript erhalten blieb. Ihr Ursprung lag weiter im Sprachdienst, doch der Empfänger hatte nichts mehr abzuspielen. Kam umgekehrt ein Sprachkontext nur mit Faxinhalt an, musste der Client den vorhandenen Faxteil zeigen.

RFC 2822 regelte die Nachrichtensyntax, RFC 2183 die Disposition eines Körperteils. RFC 2387 und RFC 2557 beschrieben zusammengesetzte Strukturen; RFC 2423 lieferte VPIM-Kontext. Message-Context setzte diese Schichten nicht außer Kraft.

Eine ungültige Klassifikation war darum kein Grund, Transport oder Darstellung abzubrechen. Der Inhalt musste mindestens so sinnvoll erscheinen wie ohne das Feld. Regeln für Weiterleitung jenseits bloßer Bewahrung blieben offen. Ein mitgeschleppter alter Wert war zu beobachten, nicht durchzusetzen.

Der Hinweis blieb unterhalb der Vertrauensgrenze

Der Sicherheitsabschnitt warnte ausdrücklich davor, ein Programm auszuführen, nur weil der Kontext dazu zu passen schien. Ein Angreifer konnte Ressourcen binden, Routing fehlleiten oder Aufmerksamkeit gewinnen. Das Feld authentifizierte weder Absender noch Körper, erlaubte keine Aktion, bestätigte keine Zustellung und sagte nichts Sicheres über Dringlichkeit oder menschliche Wahrnehmung.

RFC 3459 behandelte kritische MIME-Körperteile getrennt. RFC 3938 änderte später die Registrierungspolitik; RFC 3864 stellte den allgemeinen Rahmen bereit. Das IANA-Register belegt die Zuteilung, nicht das Verhalten eines konkreten Programms.

Heng Lus spätere Lehre von Realitätsschichten hilft, Behauptung und empfangenen Körper zu trennen. Vorrang laufenden Codes lenkt den Blick auf MIME-Baum, Transformation und Ausweichdarstellung. Die minimale Anfangsspezifikation erklärt den Wert eines kleinen Feldes, das weder MIME noch Sicherheitspolitik vereinnahmt. Dies sind spätere redaktionelle Perspektiven, keine Aussagen über private Absichten der Autoren.

RFC 3458 machte Kontext brauchbar, indem es ihn nicht zum Befehl erhob. Der Header konnte vorbereiten; der verbliebene Körper entschied, was lesbar war.

Quellen