Zusammenfassung

  • Die gemeinsamen ARPANET- und DCNET-Tabellen enthielten 1981 schon mehr als 400 Namen und Spitznamen. Mills schlug Namensdomänen vor, damit nicht jeder Host ein flaches Verzeichnis aller künftigen Hosts mitführen musste.
  • Ein Rechner konnte Mail für COMSAT und INTELPOST weiterleiten. Mills@HOST durfte in beiden Domänen verschiedene Postfächer meinen; die Rechneradresse allein wählte für eine Antwort keines davon. Vollständige Postfachnamen und der Rückweg mussten den Domänenkontext erhalten.

Zwei Abteilungen schicken Briefe an Mills@HOST. Im Haus steht nur ein gemeinsamer Sortiertisch. Wer die Abteilungsnamen von den Umschlägen streicht, hat die Arbeit des Sortierers auf ein Ratespiel reduziert. D. L. Mills beschrieb diese Mehrdeutigkeit in technischer Form in seiner RFC 799 vom September 1981. Die zusammengeführten Namens- und Adresstabellen von ARPANET und DCNET waren bereits auf mehr als vierhundert Namen und Spitznamen angewachsen. Eine Aufteilung in Domänen versprach Entlastung. Ob eine Antwort danach noch das richtige Postfach fand, war die eigentliche Prüfung.

Mills' Domänen konnten Einrichtungen wie ARPA, UCL oder COMSAT entsprechen, sich überschneiden und Adressen auch auslassen. Seine Untersuchung ging von einer Ebene aus, obwohl die vollständige Postfachform <user>.<host>@<domain> von rechts gelesen drei Ebenen andeutete. Innerhalb von COMSAT konnte Mills@COMSAT-DLM eindeutig sein. Außerhalb benannte Mills.COMSAT-DLM@COMSAT auch das Verzeichnis, in dem dieser lokale Name galt. Spitznamen mussten zwischen Domänen nicht eindeutig sein. Das Domänenstück war der Schlüssel zum richtigen Adressbuch.

Für jede Domäne sah der Vorschlag einen oder mehrere Mail-Weiterleitungsprozesse vor. Ein solcher Weiterleiter kannte alle Hosts seiner eigenen Domäne und mindestens einen Weiterleiter für jede andere. Gewöhnliche Hosts brauchten nur die Weiterleiter und weitere Namen nach Bedarf zu speichern. Ein Rechner konnte mehreren Domänen angehören, mehrere Internetadressen besitzen und verschiedene Weiterleitungsprozesse betreiben. Mills erwähnte die Möglichkeit, Weiterleiter für Robustheit zu vervielfachen, ließ die daraus folgenden Wegprobleme aber offen.

Lokale Freiheiten waren gewollt; an der Grenze musste klar bleiben, wessen lokaler Name gerade gelesen wurde.

Die Weiterleiter waren keine Pflichtstation für jede Nachricht. Mills erwartete, dass der größte Teil der Post direkt vom Absenderhost zum Empfängerhost gehen würde. Eine Zwischenstation half, wenn beide nicht gleichzeitig erreichbar waren, der Absender nicht alle Namen auflösen konnte, ein direkter Weg regulatorisch, wirtschaftlich oder aus Sicherheitsgründen unpraktisch war, oder die Enden unterschiedliche Transporte wie TCP und NCP nutzten. Ein einfacher Mail-Relay konnte eine Nachricht speichern und später weitergeben, ohne das vollständige domänenübergreifende Verzeichnis eines Weiterleiters zu besitzen.

Die Aufgaben waren verwandt, aber nicht identisch.

Im Mittelpunkt stehen zwei Routen: MRCP to:<@COMSAT,Mills@HOST> und MRCP to:<@INTELPOST,Mills@HOST>. Sie konnten verschiedene Postfächer erreichen, selbst wenn beide Prozesse auf einem Rechner liefen. Hieß dieser Rechner in beiden Domänen FORWARDER, löschte die verkürzte Route MRCP to:<@FORWARDER,Mills@HOST> die nötige Unterscheidung. Seine Internetadresse half nicht weiter. Sie identifizierte den Rechner, aber nicht seine COMSAT- oder INTELPOST-Rolle für diese Nachricht.

Beim Rückweg konnte derselbe Verlust auftreten. Das von Mills betrachtete Verfahren aus RFC 780 ließ den Empfänger einen Namen für die Absenderroute aus der Internetadresse des vorherigen Hosts bilden. Bei einem gemeinsamen Weiterleiter blieb damit die Domäne unsichtbar. Nach Mills musste der sendende Host deshalb Empfänger- und Absenderroute aktualisieren und den ersten Eintrag der empfangenen Empfängerroute an den Anfang der Rückroute übernehmen. Eine Quittung braucht die Angabe, an welchem Schalter sie abgegeben wurde, nicht bloß die Hausnummer.

Ältere Mailsysteme verwendeten dennoch kurze Namen. Mills wollte RFC-733-Kopfzeilen nicht unterwegs wiederholt bearbeiten; das erforderte aufwendige Eingriffe. Neue Systeme konnten die vollständige Form von Anfang an benutzen. Bei bestehender ARPANET-Post sollte ein lokales <anything>@<host> beim ersten Eintritt in das Internet-Mailsystem zu <anything>.<host>@ARPA werden. Ein bereits erkannter Name der Form <anything>@<domain> blieb erhalten. An diesem Eingang war die Herkunft der Abkürzung noch bekannt.

RFC 799 endete ausdrücklich als Einladung zur Diskussion. Es war ein Vorschlag, keine Meldung über eine spätere DNS-Inbetriebnahme. Der eine Rechner mit zwei Postrollen zeigte dennoch ein präzises Problem: Eine eindeutige 32-Bit-Rechneradresse kann offenlassen, welches Postfach ein Prozess in ihrem Namen vertritt. Mehr als 400 Einträge ließen die flache Liste knarren; eine Antwort an den gemeinsamen Sortiertisch brachte den tieferen Fehler ans Licht.