Summary

  • RFC 769 beschrieb ein Dateiformat für den Rapicom 450. Organisationen mit kompatiblen Faxgeräten konnten gespeicherte Seiten per Dateiübertragung oder über andere Protokolle austauschen.
  • Die Datei trennte Vorbereitung, Daten und Ende. Ihre 585-Bit-Blöcke blieben im geräteeigenen Code; zum Bild wurde daraus erst mit dem passenden Decodierverfahren.

Ein Faxblatt als Computerdatei: Im September 1980 war das eine konkrete technische Möglichkeit für einige Organisationen der ARPA-Internet-Gemeinschaft. Dort standen Rapicom-450-Geräte, die mit Computern verbunden waren. Sie konnten Seiten erfassen, als Daten aufbewahren und aus gespeicherten Daten wieder Papier erzeugen. Jon Postels RFC 769 hielt die Dateiregeln fest, damit weitere Einrichtungen mit geeigneter Hardware an diesem Austausch teilnehmen konnten.

Die Reise der Datei war nur ein Teil der Geschichte. Der Rapicom 450 verwendete eine eingebaute Codierung und erzeugte Blöcke von 585 Bit. Ein Computer konnte sie speichern, ein Übertragungsprotokoll konnte sie versenden. Ein beliebiges Programm erhielt damit jedoch noch kein Bild. Postel schrieb ausdrücklich, dass die Blöcke erst mit Kenntnis und Anwendung des Gerätecoder- und Decoderverfahrens als Bitmap nutzbar wurden. Das Netz beförderte den Umschlag; im Brief steckte noch die Handschrift des Apparats.

Die RFC regelte, was Teilnehmer gemeinsam lesen mussten: die äußere Grammatik. Jeder Datensatz begann mit einem Längenbyte und einem Befehlsbyte; danach kamen die Daten. Die Länge zählte beide Anfangsbytes mit. Befehl 56 bezeichnete SET-UP, 57 DATA und 58 END. Der Schlussdatensatz konnte aus den beiden Anfangsbytes allein bestehen. So ließ sich die Datei zuverlässig zerlegen, bevor jemand die darin enthaltene Seite decodierte.

Besonders hübsch ist der Umgang mit der Vorbereitung. Beim Betrieb sendete oder empfing das Faxgerät mehrere identische Exemplare des SET-UP-Blocks. In der Datei wurde nur eines abgelegt. Die gespeicherte Fassung war also kein Protokoll jeder Gerätebewegung. Sie bewahrte eine ausgewählte Darstellung, die ein anderes kompatibles Gerät weiterverwenden konnte. Wiederholung auf dem Geräteweg und dauerhafte Information in der Datei hatten unterschiedliche Zwecke.

Dann kam die Ein-Bit-Rechnung. 73 Bytes enthalten 584 Bit, der Rapicom-Block hatte 585. Für das Datenfeld wurden deshalb 74 Bytes vorgesehen. Mit Länge und Befehl maß der normale Datensatz 76 Bytes. In den bis dahin ausgetauschten Dateien, so die RFC, enthielt jeder Datensatz genau einen Block: vorne SET-UP, dazwischen DATA, hinten END. Eine Verschiebung um ein Bit hätte die nachfolgenden Grenzen ruiniert. Pionierarbeit bestand eben auch darin, bis 76 zählen zu können.

Postel dokumentierte außerdem eine 24-Bit-Synchronisationsmarke am Blockanfang und eine zweibittige Folgenummer, die in DATA-Blöcken vier Werte durchlief. Diese Merkmale halfen, die vom Gerät kommende Struktur zu erkennen. Den Bildinhalt lieferten sie erst nach der gerätespezifischen Decodierung. Dateitransport, Datensatzanalyse und Bildwiedergabe waren drei eigene Arbeitsschritte. Wer den zweiten beherrschte, hatte den dritten noch nicht erledigt.

Die Zielgruppe von 1980 war ausdrücklich mit kompatiblen Geräten ausgestattet. Eine spätere Aufgabe bekam einen größeren Zuschnitt: RFC 1314 von 1992 beschrieb TIFF-B als eigenständiges Austauschformat für faxartige Bilder. Der Vergleich macht die ältere Leistung genauer. RFC 769 ermöglichte den Austausch innerhalb einer Gerätefamilie; RFC 1314 wollte die Bilddarstellung selbst allgemeiner festlegen.

Aus einem Blatt wurden codierte Geräteblöcke, aus ihnen eine Datei, aus der Datei ein Netzwerktransport und beim Empfänger wieder eine Seite. An jeder Station wechselte die Zuständigkeit. Dass die Seite als Daten reisen konnte, war der Fortschritt. Dass sie am Ziel die richtige Maschine erwartete, war der Preis der damaligen Bequemlichkeit.