Zusammenfassung

  • RFC 1740 legte im Dezember 1994 MIME-Formate für Macintosh-Dateien fest. AppleSingle bündelte Inhalt und Eigenschaften in einem Datenstrom; AppleDouble hielt Mac-spezifische Informationen und den Data Fork getrennt.
  • Für die meisten Dateien mit solchen Zusatzinformationen empfahl der RFC multipart/appledouble: einen application/applefile-Teil mit Ressourcen und Desktop-Informationen sowie einen separat typisierten Datenteil.

Ein Anhang, zwei Arten von Inhalt

Das klassische Macintosh-Dateisystem teilte eine Datei in Data Fork und Resource Fork. Im Data Fork lagen die Daten, die ein fremder Rechner gewöhnlich sinnvoll nutzen konnte. Im Resource Fork konnten Programmteile, Icons und andere Attribute stecken. Der Finder verwaltete weitere Angaben. Wer diese Datei auf einem System mit einem einzigen linearen Bytestrom ablegte, musste die Teile erst verpacken. Beim Versand per Internet-Mail wurde aus dieser Verpackung eine Frage der Verständlichkeit für den Empfänger.

Patrik Faltstrom, Dave Crocker und Erik E. Fair stützten ihre Lösung in RFC 1740 auf das MIME-System aus RFC 1521. MIME konnte mehreren Teilen einer Nachricht jeweils einen eigenen Inhaltstyp geben. Der sichtbare Datenteil einer Mac-Datei durfte also als gewöhnliches Bild oder als anderer bekannter Typ erscheinen. Die Besonderheiten des Mac konnten daneben reisen. Das war nützlich, weil beide Empfängergruppen etwas anderes aus derselben Sendung brauchten.

AppleSingle verfolgte die Methode „alles in eine Kiste“. Inhalt und Eigenschaften wurden zu einem fortlaufenden Bytestrom zusammengefasst und als application/applefile verschickt. Das machte die Kiste vollständig. Wer nur ein Bild oder einen Text darin suchte, brauchte dennoch das passende Werkzeug für die Kiste. Ein Nicht-Mac-Rechner konnte mit dem äußeren MIME-Typ noch nicht direkt erkennen, welchen gewöhnlichen Datentyp er im Inneren vorfand.

AppleDouble zerlegte die Kiste in zwei MIME-Fächer. Ein Header enthielt Resource Fork und Desktop-Informationen; der Data Fork lag getrennt. multipart/appledouble hatte genau zwei Unterteile: application/applefile für den Header und einen passenden MIME-Typ für die Daten. Das Beispiel im RFC nutzt image/gif; wenn kein registrierter Typ passte, blieb application/octet-stream. Ein Nicht-Mac-Empfänger konnte den Datenteil mit vertrauter Software öffnen. Ein Macintosh konnte zusätzlich den Header verwenden und die vollständigen Dateiinformationen zurückgewinnen.

Der RFC setzte die Teilung mit Augenmaß ein. Eine Datei mit bekanntem MIME-Typ und fehlendem oder belanglosem Resource Fork konnte ganz normal als MIME-Teil reisen. Fehlte der Data Fork, musste AppleSingle übernehmen. Für die übrigen Fälle, besonders bei wichtigen Ressourcen oder Daten ohne üblichen MIME-Typ, war AppleDouble die bevorzugte Mail-Verpackung. Diese Abstufung ersparte dem einfachen Bild eine unnötige Sonderbehandlung und dem komplizierteren Objekt einen Verlust seiner Eigenschaften.

Der Transport war freilich noch ein Stück 1994. Binäre AppleSingle-Daten und AppleDouble-Header konnten auf eingeschränkten Mailwegen eine Transferkodierung benötigen. Base64 nannte der RFC die sicherste Wahl für solche Wege. Auch der Dateiname bekam eine kleine Grenze: Der empfohlene name-Parameter musste nach der geerbten MIME-Syntax in siebenbittiges US-ASCII passen. Das Paket konnte zwei Dateizweige sicher tragen, während die Aufschrift auf dem Paket mit einem kleineren Alphabet auskommen musste.

Der Kern der Entscheidung lag beim Entpacken. Ein einziger undurchsichtiger Strom hätte allen Lesern dieselbe Spezialarbeit aufgegeben. Zwei beschriebene Teile gaben jedem Leser einen klaren Einstieg. Das Mac-Programm konnte das ganze Objekt wieder zusammensetzen; ein anderes Programm nahm die Daten, die es verstand. Kompatibilität bedeutete hier eine vernünftige Verteilung der Arbeit, nicht die Vereinheitlichung aller Dateisysteme.

So erzählt RFC 1740 eine kleine, ziemlich elegante Postgeschichte. Der Absender hatte einen Gegenstand mit zwei inneren Wegen, die Mail einen Umschlag mit mehreren Fächern. AppleDouble nutzte beide Eigenschaften. Das Bild wurde zugänglich, und seine Mac-spezifischen Begleiter bekamen einen eigenen Sitzplatz, statt im Papierkorb zu landen.