Zusammenfassung

  • RFC 3391 zerlegte MIME-Nachrichten in nummerierte, längenbegrenzte Chunks und verschachtelte sie, sodass ein Bild unmittelbar vor oder nach seinem Verweis in der Wurzelnachricht eintreffen konnte.
  • Die Nähe war ein Sendeplan, keine Rückmeldung des Empfängers: Korrekte Chunks bewiesen weder ausreichenden Speicher noch passende Darstellung oder den späteren Abschluss aller begonnenen Nachrichten.

Ein Scanner kennt das nächste Bild erst, wenn er die entsprechende Seite erreicht. Ein Drucker möchte dieselbe Seite möglichst sofort ausgeben. Werden sämtliche Bilder vor dem Hauptdokument übertragen, muss die eine Seite sie vorab kennen und die andere sie lange speichern. Folgen sämtliche Bilder erst nach dem Hauptdokument, wartet der Drucker selbst auf Material für die erste Seite.

multipart/related konnte die Bestandteile als zusammengehörig darstellen, ordnete seine Body Parts jedoch nacheinander. Zwischen einem Verweis im Wurzeldokument und dem referenzierten Teil konnten viele Oktette liegen. Für stapelweise Verarbeitung war das ordentlich; für fortlaufende Verarbeitung konnte die Reihenfolge zum Engpass werden.

RFC 3391 erschien im Dezember 2002 als Informational RFC und definierte application/vnd.pwg-multiplexed. Statt nur ganze Teile aneinanderzureihen, durfte ein Erzeuger mehrere MIME-Nachrichten in Chunks zerlegen und deren Chunks verschachteln. Er konnte die Wurzelnachricht anhalten, das benötigte Bild einschieben und die Wurzel danach fortsetzen.

Das Dokument unterschied sorgfältig zwischen dem zusammengesetzten Objekt und seiner Darstellung. Wurzel und Komponenten waren Abstraktionen; Entität und Nachrichten waren deren Oktette auf Leitung oder Speicher. Eine wieder zusammengesetzte Nachricht sollte Oktett für Oktett dem Body Part entsprechen, der dieselbe Komponente in multipart/related dargestellt hätte. Neu war der Zeitplan, nicht die Bedeutung des Bildes.

Ein Chunk begann mit CHK, Nachrichtennummer, Nutzlastlänge und MORE oder LAST. Die Länge ersetzte die Suche nach einer Multipart-Grenze. MORE hielt die Nachricht offen, LAST schloss ihren letzten Teil. Chunks anderer Nachrichten durften dazwischenliegen, innerhalb einer Nachricht musste die Reihenfolge der Teile erhalten bleiben.

Der erste Chunk enthielt die Wurzelnachricht ganz oder teilweise. Selbst eine leere Nutzlast war erlaubt; reale Wurzeloktette konnten also später beginnen. Die gesamte Entität endete mit CHK 0 0 LAST. Nachrichtennummer null war für diesen abschließenden Wächter reserviert.

Der Wächter heilte keine zuvor offenen Versprechen. Erschien er vor dem letzten Chunk jeder Nachricht, war das Verhalten des Empfängers undefiniert. Nachrichtennummern waren gewöhnlich eindeutig, durften aber entgegen der Empfehlung wiederverwendet werden. Dann musste die ältere Nachricht mit LAST abgeschlossen sein, bevor die nächste unter derselben Nummer begann.

Der erforderliche Parameter type nannte den Medientyp der Wurzelnachricht. So konnte der Empfänger die Art des zusammengesetzten Objekts vor dem Lesen der eingeschlossenen Wurzel erkennen. Widersprach die Angabe dem tatsächlichen Content-Type, war wiederum kein Verhalten festgelegt. Content-ID und Content-Location konnten die aus MHTML bekannten Bezugsmuster nutzen; RFC 3391 definierte die Beziehungen nicht neu.

Im Druckbeispiel erzeugte die Quelle einen langen Strom von Seitenbeschreibungen und entdeckte Bilder erst währenddessen. Sie konnte jedes Bild kurz vor seinem ersten Verweis senden. Wenn der Drucker den Verweis las, war das Bild bereits vorhanden, ohne dass er alle künftigen Bilder halten oder die vollständige Wurzel abwarten musste.

Im Scanbeispiel durfte ein Bild auch direkt hinter seinem Verweis folgen. Der Empfänger erfuhr zunächst, wohin es gehörte, und erhielt anschließend die Daten. Der messbare Vorteil war eine geringe Oktettdistanz zwischen Name und Gegenstand.

Sobald der Empfänger das Layout bestimmte, reichte diese Sicht jedoch nicht mehr. Mehrere Bilder konnten nebeneinanderstehen, Text konnte um ein Bild laufen. Der Erzeuger kannte die Stelle des Verweises, aber weder Seitenbreite und Schriftmetriken noch den Puffer und die Ausgabestrategie auf der Gegenseite.

Wer Bänder mehrerer nebeneinanderliegender Bilder verschachtelte, erhielt bei genügend Speicher einen fließenden Strom. Ging der Speicher aus, blieben abwechselnde, unvollständige Bildteile zurück. RFC 3391 riet deshalb in diesem Fall vom Verschachteln der Bilder ab. Eine erlaubte Operation war noch keine vernünftige Strategie.

Beim umlaufenden Text war auch die Schnittstelle der Wurzel ungewiss. Ein zu früher Schnitt zwang den Empfänger vielleicht, das vollständige Bild zu puffern oder den Textumlauf vorzeitig zu beenden. Ein zu später Schnitt ließ ihn zu viel Text speichern oder das Bild versetzen. Weil Text meist weniger Speicher als Bilddaten benötigt, empfahl das RFC eher zu viel als zu wenig Text vor dem Bild. Das war eine begründete Heuristik, keine Kenntnis des Empfängers.

Die IESG Note stellte diese Bedingung an den Anfang. Der Medientyp sei nur angemessen, wenn der Erzeuger Fähigkeiten und Grenzen des Verbrauchers vollständig kenne. Verschiedene Verbraucher könnten zu verschiedenen Zeitpunkten Verschiedenes benötigen, während die Darstellung keinerlei Rückkanal besaß. Bei unbekannten Fähigkeiten sollte eine bidirektionale Alternative wie BEEP erwogen werden.

Damit standen zwei Kontrollmodelle gegenüber. Die multiplexte Entität ließ den Erzeuger Bedarf voraussagen und Daten vorwegschieben. Ein bidirektionales Protokoll ließ den Empfänger ein Bild oder passende Bänder anfordern. Eine Anforderung konnte Wartezeit erzeugen; ein Vorgriff konnte falsch liegen. Geschwindigkeit und Beobachtbarkeit waren unterschiedliche Güter.

Auch die Darstellung blieb beim Verbraucher. Verstand er Container und Wurzeltyp, stellte er die Komponenten im Kontext des Gesamtobjekts dar. Content-Disposition konnte dort redundant oder irreführend sein und war für die Anzeige zu ignorieren. Verstand er nur den Container, konnte er alles unterdrücken oder die Nachrichten als gemischte Anhänge zeigen. Ohne Kenntnis des Containers blieb die Entität undurchsichtig.

Die Sicherheitsbetrachtung folgte derselben Informationslücke. Ein fehlerhafter oder böswilliger Erzeuger konnte Chunks einer Nachricht durch riesige Datenmengen trennen oder den Abschluss nie liefern. Er konnte viele Nachrichten zugleich eröffnen, nie eintreffende Komponenten referenzieren oder so viele referenzierte Nachrichten vorab senden, dass der Verbraucher nicht wusste, welche er freigeben durfte.

Ein einzelner Chunk konnte dabei völlig korrekt sein. Nummer, Länge und Fortsetzungszustand bestanden die lokale Prüfung, während die Gesamtheit offener Zusagen den Speicherbedarf immer weiter erhöhte. Gültige Rahmung war kein Nachweis begrenzter Ressourcen.

Lu Hengs Prinzip der Minimum Initial Specification erklärt die bewusst schmale gemeinsame Ebene. Nummern, Längen, Fortsetzung, Wurzel und Abschluss mussten übereinstimmen. Layout und Speicherpolitik blieben bei den Endpunkten und konnten ohne zentrale Freigabe verbessert werden.

Running-Code Primacy setzt die Beweisgrenze. Die Registrierung eines Medientyps belegt nicht, dass ein realer Drucker ohne Pause lief. Ein empfangenes LAST belegt nicht, dass das richtige Bild erschien. Ursprünglicher Strom, Referenzgraph, Speichertelemetrie und gerendertes Ergebnis sind getrennte Belege.

RFC 3391 machte Nähe programmierbar, nicht den Leser durchsichtig. Das Bild konnte neben seinem Verweis eintreffen. Ob dieser Ort für den Empfänger der richtige Zeitpunkt war, ließ sich aus derselben Einbahnstraße nicht erfahren.

Quellen