Zusammenfassung

  • RFC 3017 standardisierte ein XML-Telefonbuch, das nicht nur POPs aufführte, sondern Wählskript, DNS, Proxies, Gateway, Tunnel und die Bildung des Benutzernamens an den Client übergeben konnte.
  • Buch- und Eintragszähler signalisierten Änderungen innerhalb eines bekannten Namensraums. Das Aktualisierungsprotokoll, Herausgeberauthentisierung, Ergebnisprüfung, Aktivierung und reale Dienstverfügbarkeit lagen außerhalb ihrer Beweiskraft.

Auf dem Rechner lag Version 41, auf dem Server Version 73. Die einfache Regel „größer gewinnt“ führte trotzdem zum falschen Anschluss.

Das war möglich, ohne dass ein Zähler gebrochen war. Ein Roaming-Konsortium durfte Ausgaben für verschiedene Nutzergruppen erzeugen; ein Nutzer konnte daraus Länder- oder Mediensubsets bilden. Der Buchname war eine beliebige Zeichenkette. Erst Herausgeber, Ausgabe, Zielgruppe und Basis machten den Integer vergleichbar.

RFC 3017 erschien im Dezember 2000. Das Internet erreichte Reisende damals oft über lokale Einwahlnummern fremder Provider. Eine gemeinsame DTD sollte Daten zwischen Providern, Konsortien, Clients und kleinen Geräten transportabel machen.

Das Ergebnis hieß Telefonbuch, enthielt aber Steuerdaten: Adresse, Übertragungsart, Datenrate, Tunnel, Eigenschaften, dialScript, Preis, Standort, DNS, Mailserver, Web- und FTP-Proxy, Standardgateway sowie Präfix und Suffix für den Nutzernamen.

Ein maschinenlesbarer Eintrag konnte unmittelbar Verhalten ändern.

Der gemeinsame Bestand blieb eine Kompilation

Mitgliedsprovider lieferten ihre POP-Angaben; das Konsortium baute daraus eine vereinheitlichte Ausgabe. Anpassungen für Kundengruppen waren vorgesehen. Damit entstand kein einzelner allwissender Ursprung, sondern eine Kette aus Behauptung, Zusammenstellung, Auswahl und lokaler Aktivierung.

RFC 2194 beschrieb diesen Hintergrund an realen Roamingdiensten. Beim GRIC-Beispiel meldeten Mitglieder ihre POPs an ein Sekretariat, das Nummern manuell zusammenstellte und Aktualisierungen über FTP, Web und Client ausgab. Dazu gehörten auch Proxy- und Dialer-Konfiguration. Das beweist keine RFC-3017-Einführung, aber den operativen Bedarf, den der Standard adressierte.

Eine syntaktisch einheitliche Ausgabe blieb eine Sicht des Konsortiums. Sie war nicht automatisch die momentane Sicht jedes Providers.

Monoton steigend bedeutete nicht atomar angekommen

phoneBook@version sollte bei jeder Änderung steigen. Der Server konnte die Clientversion vergleichen und etwa eine URL mit Differenzen anbieten.

Die Differenzen selbst waren nicht definiert. Ebenso fehlten Request, Transport, Base-Bindung, Commit, Rollback und Löschsemantik. Das Dokument erklärte Update- und Transferprotokolle ausdrücklich für außerhalb seines Umfangs.

RFC 2477 nannte die fehlenden Pflichten: Serverauthentizität, Aktualisierung von jeder beliebigen Altversion zur neuesten, Integritätsprüfung vor Anwendung, Prüfung des erzeugten Buchs, leichter Transfer sowie Auswahl von Sprache und Zeichensatz.

Ein höherer Wert war deshalb ein Hinweis des Servers. Er war keine Quittung, dass der richtige Client die richtigen Bytes gegen die richtige Basis geprüft und aktiviert hatte.

Auch pop@entryVersion war nur ein Baustein. Ein POP besaß kein XML-ID, während setup, support und provider IDs und Referenzen verwenden konnten. Ändert sich die Telefonnummer, muss das äußere Verfahren erkennen, ob dasselbe POP geändert, ersetzt oder ergänzt wurde. Verschwindet ein Eintrag, kann dies Löschung, Zielgruppenfilter, Teiltransfer oder Fehler bedeuten.

Der Zähler half beim Mergen, definierte aber keine vollständige Merge-Transaktion.

DTD-Gültigkeit prüfte keine Telefonnummer

Viele Inhalte waren #PCDATA. Notationen für FQDN, IP-Adresse oder Bild erklärten die beabsichtigte Form. Sie riefen den Anschluss nicht an und fragten den Proxy nicht ab.

Eine stillgelegte Nummer konnte XML-gültig bleiben. Ein veralteter Preis konnte vorhanden sein. Ein angegebenes Maximum war keine Messung dieser Sitzung. Ein registrierter Extensionwert bewies nicht, dass ein älterer Client seine Semantik verstand.

Das war wichtig, weil die Daten ausgeführt werden konnten. Das Wählskript leitete den Verbindungsaufbau; Prefix und Suffix veränderten automatisch die Identität; Setupwerte lenkten DNS, Mail, Proxy und Gateway. Ein falscher Eintrag konnte Ziel, Credentialsdarstellung und Trafficpfad zugleich verändern.

Eine Signatur konservierte Bytes, nicht den Betrieb

RFC 3017 verlangte eine zuverlässige Herausgeberauthentisierung und Integrität, legte diese aber außerhalb der DTD und erwähnte PGP-Signierung als Beispiel.

Eine verifizierte Signatur kann Herkunft und Unverändertheit unter einer Trust Policy zeigen. Sie testet nicht, ob die Nummer nach der Signatur abgeschaltet, ein Tunnel entfernt oder die Ausgabe für diesen Kunden bestimmt wurde. Sie beweist auch nicht den Commit im Client.

Nach der Einwahl folgte eine weitere Grenze. RFC 2486 setzte den Network Access Identifier in die PPP-Authentisierung und half damit, die Anfrage zum Heimatbereich zu leiten. Träger oder Link konnten bestehen, während die Identität scheiterte. Authentisierung konnte gelingen, während Adresse, Tunnel, DNS oder Proxy unbrauchbar blieben.

Jede Stufe brauchte eine eigene Beobachtung.

Konfiguration konnte aus konkurrierenden Quellen kommen

RFC 3017 bemerkte, dass manche Setupwerte auch über DHCP verfügbar sein könnten. Lieferten Telefonbuch und DHCP verschiedene DNS-Server, entschied die DTD keine Priorität. Client- und Betreiberpolitik mussten wählen; Telemetrie musste festhalten, welcher Wert tatsächlich aktiv war.

Für eine belastbare Analyse brauchte man Herausgeber, Buchname, Zielgruppe, Digest, Buchversion, POP, Adresse, entryVersion, Signaturergebnis, Parser/DTD-Stand, Extensions, Updatebasis und Commitresultat. Danach folgten getrennte Ereignisse für Wählen, Link, PPP, NAI, Authentisierung, Adresse, Tunnel, DNS, Proxy und Anwendung.

Nur so ließ sich veralteter Bestand von Mergefehler, Leitungsstörung, Identitätsablehnung oder nachgelagertem Ausfall unterscheiden.

Die Begrenzung des Standards war Teil seiner Disziplin

RFC 3017 behauptete nicht, eine DTD sei das ganze Roamingsystem. Es definierte die gemeinsame Form und ließ den Zustandsübergang bewusst anderswo. Problematisch würde erst eine Implementierung, die aus diesem begrenzten Artefakt einen universellen Wahrheitsbeweis machte.

Lu Hengs Running-Code Primacy verlangt, publizierte Konfiguration an laufenden Systemen zu prüfen. Reality Layers trennt gültiges Dokument, authentisierten Herausgeber, installierten Zustand und Dienstresultat. Minimum Initial Specification erklärt, warum die gemeinsame Schicht schmal bleiben durfte und warum Transition, Kompatibilität und lokale Prüfung dennoch explizit sein mussten.

Das sind analytische Perspektiven, keine Behauptung einer Beteiligung Lu Hengs an RFC 3017.

Das Telefonbuch war ein notwendiges Werkzeug. Doch seine höhere Zahl konnte nur eine Änderung anzeigen.

Ob die Einwahlwelt dahinter noch existierte, entschied der Betrieb.

Quellen