Zusammenfassung

  • RFC 1927 wollte mit elektronischen Heft- und Büroklammern den Bindungsgrad mehrteiliger Dokumente zeigen, lud dasselbe Symbol aber zusätzlich mit Hierarchie, Aussehen, Workflow, Abrechnung, Wiederverwendung und Textmarken auf.
  • Spätere MIME-Dokumente regelten einige benachbarte Rollen getrennt: Content-Disposition gibt Darstellungsratschläge, multipart/related definiert ein Verbundobjekt samt Wurzel, und cid: sowie mid: liefern kontextgebundene Referenzen; Workflow-Autorisierung, Abrechnung und der gesamte Lebenszyklus gehören nicht zu ihrer gemeinsamen Aussage.
  • Ein Symbol kann eine Beziehung erklären. Speicherung, Ausführung, Löschung und Integrität benötigen explizite Semantik, die der Empfänger lokal prüfen kann.

Auf Papier ergänzte der Mensch, was dem Protokoll fehlte

RFC 1927 beginnt mit einer unmittelbar verständlichen Unterscheidung. Geheftete Dokumente sollen auf dem Desktop zusammenbleiben; mit einer Büroklammer verbundene Blätter sollen sich leicht ausbreiten lassen. Körperliche Erfahrung ersetzt zunächst die Definition.

Dann wächst der Gegenstand über sich hinaus. Große und kleine Klammern könnten Dokumentgröße oder hierarchische Montage bedeuten. Ein Zertifikat an jeder Klammer diene Abrechnung und Patentkontrolle. Beim Löschen eines Ordners solle ein Recycler wiederverwendbare Teile finden. color= und shape= bestimmen die Erscheinung, src= lädt ein Bild, Silber und Gold starten verschiedene Workflow-Komponenten. Klammern werden zu Seitenmarken, Absatzankern und Skulpturen; sie zählen sogar Biegungen bis zum Materialversagen.

Das sind unterschiedliche Beziehungstypen: Einschluss, Reihenfolge, Präsentation, Identität, Autorisierung, Kosten, Lebenszyklus, Position und veränderlicher Zustand. Im Büro liefert der Kontext die fehlende Bedeutung. Software muss beim Kopieren, Weiterleiten, Speichern oder Löschen dagegen wissen, welche Zusage erhalten bleiben soll.

Der Text warnt scherzhaft, elektronische Klammern könnten schnelle Kopierprogramme beschädigen, und erklärt Sicherheitsfragen für unbehandelt. Sobald eine Farbe einen Prozess auslöst, ist die Sicherheitsfrage jedoch da: Hat der Absender gestaltet oder befohlen?

Der Informationsstatus begrenzte den Anspruch

RFC 1927 wurde am 1. April 1996 in der historischen RFC-Kategorie Informational veröffentlicht; seine ursprüngliche Statusnotiz erklärt ausdrücklich, dass es keinen Internetstandard spezifiziert. Der heutige RFC-Editor-Eintrag führt das Dokument im Independent Stream und verzeichnet eine Errata. Datum, Kinderwarnung, Diskettenmagnetismus und virtuelle Skulpturen lassen am 1.-April-Charakter keinen Zweifel.

Als Designkritik bleibt der Text dennoch nützlich. „Anhang“ klingt eindeutig, bis ein Programm entscheiden muss, ob es gemeinsam anzeigen, gemeinsam speichern, Trennung verhindern, Reihenfolge erhalten, Identität prüfen oder eine Aktion starten soll.

Die verifizierte Errata repariert „data flines“ zu „data files“ und präzisiert den Kinderwitz. Redaktion lässt sich damit überprüfen. Eine nie definierte Betriebssemantik entsteht dadurch nicht. Dokumentpflege und Systemvertrag sind verschiedene Ebenen.

MIME-Parameter erhielten eine begrenzte Aufgabe

Die folgende Gegenüberstellung ist architektonisch, nicht genealogisch: Die spätere Chronologie beweist weder, dass RFC 1927 diese MIME-Spezifikationen verursachte, noch dass es sie beeinflusste.

RFC 2046 beschreibt Content-Type als Angabe der Natur eines MIME-Inhalts. Parameter modifizieren den Subtyp, verändern aber nicht grundsätzlich die Natur des Inhalts; unbekannte Parameter sind zu ignorieren. Verbundformate gehören in multipart- oder application-Typen.

Damit dürfen imaginäre Felder wie color=, shape= und src= nicht zugleich Dekoration, Bindungsnachweis und Ausführungsbefehl sein. Ein unbekanntes Darstellungsmerkmal kann folgenlos entfallen. Eine für Korrektheit notwendige Beziehung darf nicht in einem Feld stecken, das ein konformer Empfänger übergehen muss.

Auch multipart/mixed verspricht nur eine geordnete Sammlung unabhängiger Teile. Ein gemeinsamer Umschlag beweist gemeinsamen Transport, nicht die Existenz eines unteilbaren Objekts.

Darstellung blieb ein Vorschlag

RFC 2183 definiert Content-Disposition als Präsentationsinformation. inline schlägt unmittelbare Anzeige vor, attachment eine zusätzliche Benutzerhandlung. Ein Dateiname kann als Ausgangspunkt beim Speichern dienen, nicht als fernbestimmter Pfad.

Die Sicherheitsregeln ziehen die Grenze praktisch. Das empfangende Programm soll Pfadangaben nicht blind übernehmen, keine vorhandenen Dateien überschreiben und ausführbare Inhalte nicht ohne ausdrückliche Handlung in Suchpfade legen. Der Sender darf vorschlagen; die lokale Umgebung entscheidet.

Eine goldene Klammer kann innerhalb eines Teams einen Arbeitskorb gut markieren. Soll sie organisationsübergreifend etwas auslösen, braucht sie authentisierte Befehle, Berechtigungsprüfung, Versionierung und Fehlerregeln. Farbe liefert keine dieser Garantien.

Ein starkes Verbundobjekt brauchte eine Wurzel

RFC 2387 führt multipart/related für Teile ein, die so zusammenhängen, dass ihre getrennte Anzeige das Objekt nicht korrekt wiedergibt. type nennt den Medientyp der Wurzel; start kann sie per Content-ID bezeichnen, sonst gilt der erste Teil als Wurzel. Interne Links bilden Beziehungen zu weiteren Komponenten.

Damit lautet die Frage nicht mehr nur, welche Dateien zusammen ankamen, sondern welche Komponente das Objekt organisiert und welche Ressourcen sie benötigt. Die verarbeitende Anwendung interpretiert den Verbund. Erkennt sie multipart/related, hat diese Semantik Vorrang vor Content-Disposition, dessen Anzeigehinweis redundant oder irreführend sein kann.

Ein unbekannter Subtyp degradiert ehrlich zu multipart/mixed. Der Client zeigt die Teile, behauptet aber nicht, die unbekannte Bindung verstanden zu haben.

Referenzen benötigten Identität im richtigen Kontext

RFC 2392 definiert cid: für MIME-Inhaltsteile und mid: für Nachrichten oder einen Teil innerhalb einer benannten Nachricht. Content-IDs sollen global eindeutig sein, doch viele Speicher indexieren Teile nicht unabhängig von ihrer Nachricht. Die lange mid:-Form trägt deshalb den nötigen Kontext mit.

Eine Markierung „dritter Absatz“ kann nach einer Bearbeitung wandern; eine externe URL kann verschwinden. Ein kontextgebundener Bezeichner sagt wenigstens, was gemeint war und wo es aufzulösen ist. Er beweist weder Vertrauenswürdigkeit noch Integrität und erteilt keine Ausführungsbefugnis. Diese Eigenschaften bleiben getrennt.

Das Aggregat musste seine Bezüge unverändert mitnehmen

RFC 2557 löst mit dieser Architektur ein konkretes Problem: eine vollständige HTML-Seite samt Bildern und Hilfsressourcen in einer Nachricht übertragen. multipart/related enthält eine text/html-Wurzel und referenzierte Teile, die über Content-ID oder Content-Location angesprochen werden.

Die URI des Aggregats ist nicht zwingend die URI der Wurzel. Content-Location kann einen Teil benennen, ohne ihn weltweit abrufbar zu machen. Vorhandene HTML-Referenzen sollen nicht unnötig umgeschrieben werden, weil dadurch Integritätsprüfungen ungültig werden können. Verpackung, Ort und unveränderter Inhalt sind unterschiedliche Aussagen.

Der Mechanismus ist weniger anschaulich als eine gezeichnete Klammer, aber ausführbar: Wurzel, Ressourcen, Referenzen und zuständige Anwendung sind bekannt. Beim Kopieren bleibt eine definierte Struktur erhalten statt bloß eines Bildes.

In die gemeinsame Schicht gehört Semantik, nicht Dekor

Heng Lus Running-Code Primacy macht Implementierung, Prüfung, Betrieb und Adoption zum Wirklichkeitstest. Eine veröffentlichte Heftklammer hält keine Dateien zusammen, wenn Empfänger ihre Bedeutung nicht ausführen und über Operationen erhalten.

Die Minimum Initial Specification verlangt nicht wenig Präzision, sondern einen kleinen präzisen gemeinsamen Kern: Wurzel, Identitätsbereich, Beziehungsregeln, Integritätsgrenzen und sicheres Verhalten bei Unbekanntem. Farben und lokale Abläufe dürfen lokal bleiben.

Die Trennung von symbolischer und ausführbarer Ebene erklärt den Machtwechsel. Das Symbol überzeugt Menschen von Zusammengehörigkeit. Ausführbare Macht beginnt, wenn Software Trennung verhindert, Prozesse startet oder Ressourcen löscht. Wer beides verwechselt, verwandelt eine freundliche Oberfläche in eine ungeprüfte Steuerung.

RFC 1927 zeigt daher nicht, dass Computern Büromaterial fehlte. Es zeigt, wie ein vertrautes Bild die Definitionsarbeit scheinbar verschwinden lässt. Das Bild darf erklären. Entscheiden muss überprüfbare Semantik.

Quellen

  1. RFC 1927 — Suggested Additional MIME Types for Associating Documents
  2. RFC Editor — aktueller Eintrag zu RFC 1927
  3. RFC Editor — Errata zu RFC 1927
  4. RFC 2046 — MIME Part Two: Media Types
  5. RFC 2183 — Content-Disposition
  6. RFC 2387 — MIME Multipart/Related
  7. RFC 2392 — Content-ID- und Message-ID-URLs
  8. RFC 2557 — MIME Encapsulation of Aggregate Documents
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — Minimum Initial Specification
  11. Heng Lu — On Reality Layers