Zusammenfassung

  • RFC 1394 ordnete Gebiets- und Ländernamen, Telefonvorwahlen, Telex-Ländercodes, Answerbacks und Internet-Domains in einer datierten Tabelle. Eine Zeile beschrieb eine Beziehung, keinen laufenden Dienst.
  • Das Dokument machte Unsicherheit sichtbar: zwei Arten von Fehlmarkierungen, ein ausdrücklicher Vorbehalt möglicher Fehler und drei Wege für Korrekturen.
  • Selbst ein richtiger Code bewies weder DNS-Delegierung noch erlaubte Verbindung, Identität, Zustellung oder politische Anerkennung.

Eine Zeile verband mehrere Systeme

Die RFC 1394 von Januar 1993 sollte eine praktische Sucharbeit verkürzen. Wer die Telefonvorwahl eines Gebiets kannte, wusste nicht zwingend dessen Telex-Answerback oder Internet-Domain. Umgekehrt konnte ein Domainkürzel bekannt sein, während der Zugang über ein öffentliches Nachrichtennetz unklar blieb.

Die Tabelle stellte Name, Telefoncode, Telex-Ländercode, Answerback und Internet-Domain nebeneinander. Hinzu kamen öffentliche Maildienste, historische Bezeichnungen, Territorien und Untergliederungen wie US-Bundesstaaten. Die gemeinsame Oberfläche überspannte verschiedene Betreiber und technische Ordnungen.

Die Spalten blieben dennoch verschieden. Eine Vorwahl steuerte Telefonvermittlung. Der Answerback gehörte zum Telexdienst. Eine Domain bezeichnete eine Stelle im Namensbaum. Der Name eines kommerziellen Maildienstes konnte einen Anbieter statt eines Territoriums meinen. Die gemeinsame Zeile war eine redaktionelle Zuordnung, kein ausführbares Übersetzungsprogramm.

Fehlendes blieb als Fehlendes erhalten

RFC 1394 nutzte vier Striche, wenn kein Telefoncode bekannt war, und drei Striche für sonstige fehlende oder unbekannte Angaben. Dadurch bekam eine Lücke nicht stillschweigend nur eine Ursache.

Auch die ausgefüllten Zeilen waren nicht eins zu eins. Ein Gebiet konnte mehrere Telexcodes haben. Alte und neue Namen konnten auf dieselbe Domain weisen. Mancher Eintrag hatte eine Internetkennung, aber keinen Answerback. Frühere Staaten, Regionen und private Netze standen aus Gründen der Auffindbarkeit beieinander, nicht weil sie denselben rechtlichen Status hätten.

Der Verfasser erklärte, die Angaben stammten aus mehreren Quellen und Ländern. Trotz angemessener Sorgfalt könne die Genauigkeit nicht garantiert werden; einzelne Codes könnten falsch sein. Korrekturen waren per Post, E-Mail oder Telex erwünscht. Der Katalog besaß also redaktionelle Obhut und einen Reparaturweg, aber keine Echtzeitsynchronisation mit allen Ursprungssystemen.

Für eine folgenreiche Entscheidung reichte die Druckzeile nicht. Nötig blieben Zeitpunkt, Herkunft und Bestätigung durch die im jeweiligen System zuständige Stelle.

Zwei Buchstaben führten keine Delegierung aus

RFC 920 hatte die englischen zweibuchstabigen ISO-3166-Codes als Grundlage für Länder-Toplevelnamen vorgesehen. Sie trennte aber die verfügbare Bezeichnung von der tatsächlichen Einrichtung einer Domain sowie von der Veröffentlichung ihres Administrators und Agenten.

RFC 1034 beschrieb die operative Grenze. DNS wird in Zonen geteilt. Ein Nameserver ist nur für einen begrenzten Teil des Baums autoritativ und kann zu anderen Teilen nichtautoritative Cache-Daten halten. Eine Delegierung braucht Records an der Grenze zwischen Eltern- und Kindzone sowie Angaben, mit denen die Kindserver erreicht werden.

Der Abdruck eines Kürzels in RFC 1394 erzeugte weder diese Grenze noch die Records. Er bestellte keinen Manager und bestätigte keinen Serverbetrieb. Delegierung ließ sich am autoritativen Elternteil beobachten; Verfügbarkeit erforderte eine zeitgebundene Abfrage.

Auch ein antwortendes ccTLD machte die Nachbarspalten nicht aktuell. Telefonie, Telex und DNS behielten verschiedene Verantwortliche und Änderungsrhythmen.

Domainförmige Namen konnten Gateway-Anweisungen sein

Die Erläuterungen zu BITNET und UUCP zeigten eine weitere Grenze. Namen wie System.BITNET und host.UUCP wurden in ihren Gemeinschaften verwendet, waren aber nicht im DNS registriert. Internet-Mail musste über ein Gateway geführt und mit der damaligen Prozentnotation umgeschrieben werden.

Die Zeichenfolge sah wie eine Domain aus, doch der nächste Schritt war keine Auflösung dieses Suffixes. Das Gateway besaß die Übersetzungsregel. Seine Annahme einer Nachricht belegte nur die Übergabe an einen Vermittler; das entfernte System, das Postfach und die menschliche Kenntnisnahme blieben spätere Zustände.

.ARPA beschrieb das Dokument dagegen als historischen DNS-Bereich für Rückwärtsabfragen von Hosts und Netzen. Ähnliche Syntax konnte somit autoritative Delegierung, Gemeinschaftsnotation oder Gateway-Konvention bedeuten. Die Form allein verriet nicht die zuständige Wahrheitsquelle.

Ein gültiger Code überwand keine Sperre

Vor der Tabelle warnte RFC 1394, dass die Erreichbarkeit eines Landes davon abhing, ob eine Verbindung bestand und ob sie erlaubt war. Politische Einschränkungen wurden ausdrücklich als mögliche Ursache genannt.

Damit blieben Zuordnung, Ausführung und Erlaubnis getrennt. Ein Code konnte richtig sein, während vom konkreten Ausgangspunkt kein Weg bestand. Ein physischer Weg konnte vorhanden, seine Nutzung aber durch Recht, Vertrag oder Betreiberpolitik gesperrt sein. Selbst ein erlaubter Weg konnte an einem nicht vorhandenen oder ablehnenden Empfänger enden.

Schweigen wählte keine dieser Ursachen aus. Veralteter Eintrag, gestörtes Gateway, fehlende Route, Verbot und Zielablehnung konnten gleich aussehen. Daraus ließ sich weder die Existenz eines Landes noch die Gültigkeit seiner Domain ableiten.

Ein Erfolg bewies ebenfalls nur wenig: Eine Verbindung funktionierte zu einem Zeitpunkt. Sie authentisierte nicht automatisch die entfernte Person und schuf kein dauerhaftes Recht auf Wiederholung.

Aufnahme in die Liste war keine Anerkennung

RFC 1394 erklärte ausdrücklich, keine Position zur Gültigkeit eines Ländernamens oder zur Existenz eines Landes einzunehmen. Alte und alternative Namen sollten das Auffinden erleichtern, nicht diplomatische Entscheidungen treffen.

Diese Zurückhaltung war bei einer Mischung aus früheren Staaten, Territorien, Regionen, privaten Netzen und Ländercodes notwendig. Ein Katalog muss historische Suchbegriffe abbilden können. Würde jede Aufnahme als Anerkennung gelesen, bekäme eine redaktionelle Korrektur eine politische Macht, die niemand übertragen hatte.

Die spätere RFC 1591 beschrieb Delegierung und Pflichten benannter Toplevel-Manager. Ein ccTLD-Manager brauchte funktionsfähigen Betrieb sowie administrative und technische Kontakte. Zugleich stellte sie fest, dass IANA nicht entscheide, was ein Land sei; ISO 3166 lieferte dafür ein getrenntes Verfahren.

Die Verantwortung blieb verteilt: Codepflege, Root-Koordination, Domainbetrieb, Nachrichtentransport und öffentliches Recht lagen bei verschiedenen Akteuren. Die Obhut über eine Schicht verlieh keine Souveränität über die übrigen.

Der dünne Katalog zeigte zur nächsten Prüfung

RFC 1394 erörterte keine Sicherheitsfragen. Sie authentisierte keine Tabellenzeile, belegte keine Zustimmung und garantierte keine Zustellung. Als Berechtigungsnachweis wäre sie daher falsch verwendet worden.

Ihre nützliche Leistung lag in einer Folge prüfbarer Fragen: Welcher Code ist zu bestätigen? Ist das Suffix tatsächlich delegiert? Welcher Server antwortet autoritativ? Gibt es Gateway und Route? Ist ihre Nutzung erlaubt? Hat das Ziel angenommen?

Eine dünne Koordinationsschicht kann wertvoll sein, wenn sie Referenzen verbindet und die Ausführung bei denen belässt, die sie tatsächlich kontrollieren.