Zusammenfassung

  • RFC 1277 codierte die Angaben, mit denen eine OSI-Verbindung über TCP/IP oder bestimmte X.25-Netze versucht werden konnte, wenn kein OSI-Netzwerkdienst verfügbar war.
  • Das weltweit eindeutige Format konnte ein Netz identifizieren und Transportparameter mitführen; die Zuweisung bewies weder Routingfähigkeit noch eine Antwort des Dienstes.

Das OSI-Verzeichnis konnte eine Präsentationsadresse zurückgeben, doch das Modell setzte voraus, dass Netzwerkadressen aus einem OSI-Netzwerkdienst stammten. In manchen Pilotumgebungen traf das nicht zu. OSI-Anwendungen liefen auch im Internet, über öffentliche oder private X.25-Netze und in isolierten Netzen. Hätte jedes Experiment auf einen globalen OSI-Netzwerkdienst warten müssen, wäre das Verzeichnis ausgerechnet dort unbrauchbar gewesen, wo man es erprobte.

RFC 1277 behandelte nur einen Schritt der Verbindungskette. Eine Anwendung fragte eine Präsentationsadresse ab. Danach musste der Client jede Netzwerkadresse extrahieren, ihre Verwendbarkeit und das passende Verfahren bestimmen, die Kandidaten ordnen und eine Verbindung versuchen. Das Memo konzentrierte sich auf die Extraktion. Es definierte Codierungen, aus denen der Client die unteren Schichtinformationen ableiten konnte, die das Verzeichnis nicht separat lieferte. Den gesamten Verbindungsablauf, die Routenermittlung oder einen erfolgreichen Anwendungsaustausch regelte es nicht.

Diese Grenze war wichtig, weil eine Adresse mehrere Aufgaben erfüllte. Im internationalen X.25 konnte eine Adresse der Form X.121 ein DTE identifizieren und unter passenden Bedingungen eine Route durch das öffentliche X.25-Netz ermöglichen. Ein Zuweisungskennzeichen war jedoch nicht automatisch topologisch: Ein Endsystem durfte nicht annehmen, dass jeder weltweit vergebene Adressteil einen Weg beschrieb. RFC 1277 erklärt, der IDP diene in erster Linie der Zuweisung; grundsätzlich lasse sich daraus kein Routing ableiten.

Die Empfehlung, bestimmte X.121-Formen als Route zu interpretieren, hing vom genutzten Dienst und Format ab; private Verfahren konnten bessere Alternativen liefern.

Für TCP/IP-Netze, die den in RFC 1006 definierten OSI-Transportdienst trugen, verwendete RFC 1277 eine andere Codierung. Der netzspezifische Teil begann mit einer zwölfstelligen IPv4-Adresse, gefolgt von einem optionalen fünfstelligen Port und einem ebenfalls fünfstelligen Transport-Set-Wert. Letzterer war ein 16-Bit-Flagwort: Werte standen für TCP und UDP; fehlte der Wert oder war er null, galt TCP als Standard. Das RFC-Beispiel codierte 10.0.0.6, Port 9 und UDP. Das ist eine Auslegungsregel für einen Verbindungsversuch, kein Beweis dafür, dass die Adresse aktuell, erreichbar oder lauschend war oder dass der Zugriff erlaubt war.

Das neue Format musste außerdem von Adressen unterscheidbar sein, die ein echter OSI-Netzwerkdienst verwendete. RFC 1277 wählte die Telex-AFI, weil sie einen größeren domainspezifischen Teil ließ und weniger leicht mit anderen Adressverwendungen verwechselt wurde. Ein kurzes Präfix trennte Teilnetze, der Rest enthielt netzspezifische Angaben. Der Entwurf tauschte eine kompakte, selbsterklärende Struktur gegen eine lange Dezimaldarstellung. Das Memo merkt an, eine binäre ASN.1-Form wäre attraktiv gewesen, habe aber nicht in den verfügbaren Adressraum gepasst.

Dieser Kompromiss gehörte zu einer Übergangsphase der Technik, nicht zu einem zeitlosen Adressgesetz. Der historische Hinweis des Memos besagt, dass der Ansatz in den Projekten THORN und ISODE/QUIPU implementiert und seine Machbarkeit gezeigt wurde. Das belegt ein funktionierendes Konzept in diesen Projekten, keine breite Einführung. RFC 1278 beschrieb später eine menschenlesbare Zeichenform für Präsentationsadressen, ausdrücklich zur Anzeige und nicht zur internen Speicherung; sie liegt auf einer anderen Ebene als Zuweisung und Codierung der unteren Schichten in RFC 1277.

Die NSAP-Leitlinien von RFC 1237 wiederum betreffen den verbindungslosen OSI-Netzwerkdienst, nicht den Nicht-OSI-Fall, den RFC 1277 adressierte.

Die bleibende Lehre aus RFC 1277 ist enger als „eine Adresse sagt, wie man sich verbindet“. Ein Verzeichniseintrag kann genug Struktur enthalten, damit ein Client eine Interpretation der unteren Schichten auswählt. Trotzdem braucht es eine aktuelle Route, einen kompatiblen lauschenden Endpunkt, einen erfolgreichen Transportaustausch und eine Anwendungsantwort. Den codierten Wert als Beleg für alle vier zu behandeln, würde Zuweisung, Interpretation, Erreichbarkeit und Dienst zu einer Behauptung verschmelzen, die das Memo nie aufstellte.

Quellen: RFC 1277; RFC 1006; RFC 1278; RFC 1237.