Zusammenfassung

  • RFC 1278 definierte einen menschenlesbaren String für Selector und eine oder mehrere Network Addresses, schloss diese Form aber ausdrücklich von der internen Speicherung aus.
  • Ein DNS-Name erleichterte die RFC-1006-Eingabe. Mehrere IP-Antworten mussten mehrere Network Addresses erzeugen; die Rückdarstellung einer codierten Adresse sollte die IP-Form verwenden.
  • Makros durften rekursiv expandieren und die längste Darstellung liefern, aber keine Abhängigkeit werden. Token, Wörterbuch, DNS-Beobachtung, ausgeschriebene Menge und Verbindung blieben getrennte Nachweise.

Eine Oberfläche hat andere Voraussetzungen als ein Archiv

RFC 1278 erschien im November 1991 als Informational-Dokument. Es gab einer OSI Presentation Address eine Stringdarstellung.

Der Gegenstand bestand aus Presentation Selector, Session Selector, Transport Selector und einer Menge von Network Addresses. Die Selector waren Octet Strings mit unterschiedlichen lesbaren oder numerischen Codierungen. Eine Application Entity konnte mehrere Netzwerkkandidaten unter den Treffpunkten der oberen Schichten führen.

Im OSI Directory lag die ASN.1-Repräsentation. Der neue String war für Menschen gedacht, gewöhnlich für Systemverantwortliche, und ausdrücklich nicht für interne Speicherung.

Anzeige und Archiv brauchen nicht dieselbe Lebensdauer. Die Anzeige kann lokale Abkürzungen, vertraute Namen und eine aktuelle Auflösung benutzen. Der gespeicherte Datensatz muss noch erklärbar sein, wenn diese Hilfen fehlen. Wer nur die Oberfläche speichert, lagert die Bedeutung an eine nicht protokollierte Umgebung aus.

Die Anforderungen hielten die schwierigen Fälle fest. Jede legale Ausprägung musste darstellbar sein; der häufige Fall ohne Selector sollte sauber bleiben; mehrere Selector-Codierungen, TCP/IP, X.25(80), Erweiterbarkeit und Kompaktheit mussten zusammenpassen.

Die Adressmenge war noch keine Entscheidung

Die Grammatik stellte optionale Selector vor eine Network-Address-Liste. Diese durfte mehrere Einträge enthalten. Ein gemeinsamer String machte daraus nicht einen einzigen tatsächlichen Pfad.

Die Menge belegt Kandidaten, nicht gleichzeitige Erreichbarkeit, identische Priorität oder authentifizierte Identität.

RFC 1277 trennt die folgenden Schritte. Zuerst wird die Application Entity im OSI Directory gesucht und ihre Presentation Address gelesen. Dann werden die Network Addresses extrahiert und auf Nutzbarkeit geprüft. Danach entsteht eine Präferenz. Erst anschließend werden Verbindungen versucht.

RFC 1278 machte den zusammengesetzten Ausgangsdatensatz bedienbar. Es prüfte keine Route und bestätigte keine Sitzung. Ein parsbarer String war kein Netzbeleg.

Der DNS-Name gehörte zur Eingabe

Die RFC-1006-Form erlaubte eine IP-Adresse oder einen DNS-Domainnamen. Der Name diente hauptsächlich der einfacheren Eingabe.

Ergab die Auflösung mehrere IPs, sollten mehrere Network Addresses erzeugt werden. Wurde eine codierte Adresse später als String ausgegeben, sollte stets die IP-Form erscheinen.

Damit bleiben drei Zeitpunkte unterscheidbar: die Eingabe des Operators, die DNS-Antwort und die daraus gebildete Adressmenge. Eine spätere Anzeige durfte nicht durch neue Auflösung die heutige Antwort als historischen Zustand ausgeben.

Nur den Namen zu speichern, würde alte Datensätze mit DNS wandern lassen. Nur eine IP zu behalten, würde die beobachtete Mehrzahl löschen. Das Ausschreiben konservierte die Transformation.

Sie authentifizierte keinen Endpoint. DNS ist keine Verbindungsquittung und ein IP-Literal keine Identitätsurkunde. Normalisierung macht die Ableitung nachvollziehbar, nicht den Empfänger vertrauenswürdig.

Das Wörterbuch durfte nicht zum unsichtbaren Protokoll werden

Strukturierte Adressen waren lang. RFC 1278 erlaubte deshalb ein Makro vor =, das einen gemeinsamen Präfix ersetzte. Makros konnten andere Makros enthalten. Für Menschen sollte die längste verfügbare Substitution erscheinen.

Die Kürzung verschob Bedeutung in ein Wörterbuch. Ändert sich eine Definition, fehlt sie auf einem anderen Host oder weicht ein Zwischenschritt ab, kann dasselbe sichtbare Token eine andere Adresse rekonstruieren.

Obwohl der RFC Standardmakros vorschlug, warnte er, dass man sich auf keines verlassen dürfe. Die Liste war Bedienkomfort, kein dauerhafter Registry-Vertrag.

Makroverwendung, Definition, Rekursionskette und Volladresse sind vier verbundene Datensätze. Nur das Token zu speichern, macht das Wörterbuch zu verborgenem Zustand. Expansion vor der Persistenz hält den Entstehungskontext fest.

Gemeinsame Syntax über ungleichen Netzen

RFC 1277 nennt internationale und private X.25-Netze, isolierte OSI-Netze, einen CLNP-Piloten, TCP/IP-LANs mit RFC 1006 und das DARPA/NSF Internet. Ein allgegenwärtiger OSI Network Service war keine praktische Voraussetzung.

Sein Zwischenformat codierte die für das untere Netz nötigen Informationen in der Network Address. RFC 1278 gab den heterogenen Formen eine lesbare Grammatik. Gemeinsame Darstellung bedeutete weder gemeinsame Infrastruktur noch garantierte Nutzbarkeit.

Eine korrekte Adresse konnte für einen Aufrufer ungeeignet sein. Ein nutzbarer Kandidat konnte nachrangig sein. Ein Versuch konnte scheitern. Auch globale Eindeutigkeit der Codierung war keine Authentifizierung.

Quellen und Grenzen

RFC 1278 belegt Anzeigezweck, Selector, Adressliste, DNS-Eingabe, Mehrfacherzeugung, IP-Ausgabe, rekursive Makros und das Abhängigkeitsverbot. RFC 1277 liefert nur den Hintergrund der unteren Netze und die Abfolge aus Lookup, Extraktion, Präferenz und Versuch.

Beide Texte erklären, Sicherheitsfragen nicht zu behandeln. Sie beweisen weder vertrauenswürdige Makros noch stabile DNS-Antworten, autorisierte Routen, authentifizierte Endpoints oder erfolgreiche Verbindungen. Eine heutige Verbreitung messen sie nicht.

RFC 1278 machte eine komplexe Adresse lesbar und verweigerte der Lesbarkeit zugleich die Rolle der Autorität. Das Kürzel durfte verschwinden; die ausgeschriebene Adresse musste es überleben.