Zusammenfassung

  • RFC 784 beschrieb einen TOPS20-Dispatcher, der je nach Fähigkeit des Zielrechners MTP über TCP, MTP über NCP, älteres FTP über NCP oder einen Sonderweg wählte.
  • RFC 785 definierte zwei Dateien: Der Nachrichtentext blieb in einer; die andere enthielt Absender, Empfängerwege und den Verweis auf den Text. An ihr ließ sich der Fortschritt für jeden Empfänger ändern.

Wer vier Menschen denselben Brief schreibt, braucht einen Text und vier Anschriften. Manche ältere Mailprogramme machten daraus vier Textdateien. Suzanne Sluizer und Jon Postel hatten im Juli 1981 eine bessere Verwendung für den Speicherplatz. Ihr RFC 784 über die MTP-Implementierung auf ISI-TOPS20 trennte den Brief vom Zustellzettel. Ein geänderter Weg bedeutete einen neuen Eintrag auf dem Zettel, keinen neuen Brief.

Der Zustellzettel hatte tatsächlich verschiedene Straßen zu verwalten. Die geplante Implementierung in BLISS-10 sollte über TCP und das ältere NCP senden und empfangen sowie andere Mailsysteme anbinden. Schreibprogramme und Netzempfänger legten Dateien in Benutzerverzeichnissen ab. Ein Hintergrundprogramm verteilte sie auf Ausgangskanäle; ein vom Benutzer gestarteter Dispatcher konnte es bei freiem Kanal sofort versuchen. Die Host-Fähigkeitstabelle hielt fest, ob ein Ziel MTP über TCP, MTP über NCP oder das alte FTP über NCP annahm.

Eine zweite Tabelle behandelte Sonderfälle, etwa Post an Rechner in England über ein von UCL geschaffenes System. Vier Empfänger konnten in verschiedene Richtungen abbiegen.

Die Kontrolldatei enthielt die Zustellinformationen und einen Verweis auf die zweite Datei mit Mailtext und RFC-733-Kopf. War ein Empfänger bedient, konnte der Dispatcher ihn dort markieren oder streichen. Blieb ein anderer Kanal unerreichbar, blieb dessen Empfänger auf der Liste. Der Text wurde für die Versuche gelesen und nach Abschluss der örtlichen Verarbeitung später umbenannt oder gelöscht. Arbeitsschritte verändern sich; die Sätze des Absenders brauchen deshalb nicht bei jeder Straßensperre eine neue Abschrift.

Das begleitende RFC 785 über Dateidefinitionen schrieb die Form nieder. FILE: nannte die vollständige Textdatei, FROM: den Absenderweg, und jede TO:-Zeile einen Zielweg. Die andere Datei enthielt Kopf und Inhalt. Sluizer und Postel verglichen das mit alten Schreibprogrammen, die für N Anschriften in To, Cc und Bcc gleich N Kopien des Textes erzeugten. Ihre Schnittstelle begann unabhängig von der Zahl der Empfänger mit zwei Dateien. Der sichtbare Briefkopf und die Arbeitsliste für die Zustellung erfüllten eben verschiedene Aufgaben.

Auch der Übergang in ein benachbartes Mailsystem bekam eine Beschreibung. RFC 786 erklärte den Dateiaustausch zwischen MTP und NIMAIL und zeigte, wie eine Adresse mit Prozentzeichen in einen MTP-Weg übersetzt wurde und zurück. Der Dispatcher musste den richtigen Kanal wählen und die Adresse so übergeben, wie der nächste Dienst sie lesen konnte. Die Landkarte allein half wenig, wenn das Nachbarpostamt die Anschrift anders schrieb.

Die Autoren sagten, welche Programme sie gerade bauten, welche Anpassungen sie von anderen Mailprogrammen erhofften und welche Tabellen noch anzulegen waren. RFC 784 ist ein konkreter Implementierungsplan, mit einer in RFC 785 detaillierten Dateischnittstelle. Seine scharfe Idee liegt in der getrennten Warteliste. Die Reise eines Empfängers konnte weiter sein als die eines anderen, obwohl beide denselben Text bekommen sollten.

Auf dem Schreibtisch liegt ein Brief. Daneben eine Karte mit Namen und Ausgängen. 1981 trugen die Türen Schilder wie TCP, NCP und FTP über NCP. War eine geschlossen, blieb der Name auf der Karte; die anderen Zustellungen konnten vorankommen. Der Brief blieb lesbar und der Karte überließ man das Durcheinander.