Zusammenfassung

  • Bei RFC 3402 wurde das Ergebnis einer nichtterminalen Regel zum Schlüssel für die nächste Abfrage; die folgende Regel wurde dennoch wieder auf die unveränderte Application Unique String vom Beginn angewandt.
  • Damit blieben Delegationsweg und Identität getrennt. Eine Instanz durfte bestimmen, wo als Nächstes gesucht wurde, aber nicht unbemerkt ersetzen, wonach das Verfahren suchte.

Der Ausdruck Umschreibregel legt ein Fließband nahe. Eine Regel verändert einen Text, die nächste übernimmt das Ergebnis, eine dritte setzt die Bearbeitung fort. Für eine verteilte Delegation ist dieses Bild gefährlich. Nach mehreren Stationen kann die letzte Instanz nicht mehr den ursprünglichen Gegenstand beurteilen, sondern nur noch ein zufälliges Produkt früherer Transformationen.

RFC 3402 wählte bewusst ein anderes Modell. Das im Oktober 2002 als Standards-Track-Dokument veröffentlichte Papier war Teil zwei des Dynamic Delegation Discovery System. Es beschrieb einen Algorithmus für späte Bindung. Eine Anwendung lieferte eine Application Unique String, kurz AUS; ein Client holte Regeln bei Bedarf, folgte deklarierten Datenbanken und endete bei einer terminalen Regel mit dem erwarteten Ergebnis.

Die Ausgabe einer nichtterminalen Regel erhielt genau eine Rolle: Sie wurde Schlüssel für die nächste Datenbanksuche. Sie wurde nicht zur neuen AUS. Auch die Regeln der nächsten Stufe wandten ihre Substitution wieder auf die ursprüngliche Zeichenfolge an. Das Dokument verbot ausdrücklich, eine Regel auf die Ausgabe der vorherigen anzuwenden, und machte diese Grenze zur Pflicht jeder Anwendungsspezifikation.

Der Einstieg kam aus einer First Well Known Rule. Sie wurde von der Anwendung definiert und nicht aus der Regeldatenbank geholt. Aus der AUS erzeugte sie den ersten gültigen Schlüssel. So blieb der Beginn an einen bekannten Vertrag gebunden. Dass eine beliebige Datenbank ein bestimmtes Format akzeptierte, verlieh ihr noch keine Zuständigkeit.

Eine Abfrage lieferte eine geordnete Regelmenge. Der Client prüfte die Substitutionen der Reihe nach gegen die AUS, bis ein nichtleeres Ergebnis entstand. Danach mussten Services, Flags und Priority bewertet werden. Textuelle Übereinstimmung, nutzbarer Dienst, Terminalität und Präferenz waren eigenständige Entscheidungen.

Lehnte der Client den Service einer passenden Regel ab, setzte er in derselben Liste hinter dieser Regel fort. Er startete nicht beliebig neu und sprang nicht in eine fremde Datenbank. Dadurch ließ sich ein belastbarer Beleg speichern: welche Regel passte, weshalb sie verworfen wurde und an welcher Position die Prüfung weiterging.

War eine angenommene Regel nichtterminal, musste ihr Ergebnis dem Schlüsselformat der nächsten Datenbank entsprechen. Fehlerhafte reguläre Ausdrücke konnten ungültige Schlüssel erzeugen. Selbst ein plausibel aussehendes Ergebnis durfte deshalb weder ungeprüft abgefragt noch zum neuen Gegenstand erhoben werden.

RFC 3402 bezeichnete kumulative, an sendmail erinnernde Umschreibketten als fragil und fehleranfällig. In einer solchen Kette verändert ein früher Fehler das Material aller späteren Regeln. Mit einer festen AUS kann dagegen jede Regel separat wiederholt und jede Ausgabe nach ihrer tatsächlichen Funktion als Schlüssel oder Endwert geprüft werden.

Ein erklärter Kontextwechsel blieb möglich. Flags konnten die aktuelle DDDS-Anwendung anhalten und an eine andere Anwendung oder einen protokollspezifischen Schritt übergeben. Das p-Flag aus RFC 3404 war das Beispiel. Der Wechsel war aber sichtbar; er erlaubte den alten Regeln nicht, mit einem heimlich ersetzten Subjekt weiterzuarbeiten.

Eine terminale Regel lieferte den von der Anwendung erwarteten Ergebnistyp samt Flags und Services. Terminal bedeutete nur, dass der Algorithmus beendet war. Es bewies weder die spätere Erreichbarkeit eines Dienstes noch die Berechtigung des Regelherausgebers oder die Annahme durch einen Verbraucher.

Auch Priority hatte einen engen Auftrag. Das Feld beschrieb die Präferenz zwischen ansonsten gleichwertigen Regeln, etwa eine bessere, schnellere oder günstigere Option. Es war ausdrücklich kein Lastverteilungsmechanismus. Verkehrsverteilung gehörte in eine andere Schicht, beispielsweise zu SRV, sofern die Anwendung dies vorsah.

Zeitliche Gültigkeit begrenzte Optimierungen. Clients durften frühere Schlüssel und Regeln merken, mussten aber deren Ablaufregeln beachten. War eine verwendete Regel abgelaufen, begann die Anwendung bei Schritt eins. Eine alte erste Hälfte mit einer neuen zweiten Hälfte zu verbinden, hätte einen Pfad erzeugt, der womöglich zu keinem Zeitpunkt existierte.

Der Algorithmus brauchte deshalb zwei ergänzende Verträge. Die Anwendungsspezifikation definierte AUS, erste Regel, erlaubte Datenbanken, Zeichensätze und Endausgabe. Die Datenbankspezifikation definierte Speicherung, Suche, Schlüssel- und Regelformate, Einfügung und Kollisionsvermeidung. RFC 3401 warnte davor, nur ein Dokument der Reihe zu lesen.

DDDS erkannte seine Wissensgrenze an. Uhrzeit, Zahlung, Rechte oder Transaktionen waren externe Tatsachen. Sie ließen sich nicht allein aus AUS und Regel ableiten. Auch Sicherheit wurde erst durch die konkrete Kombination aus Anwendung und Datenbank bestimmbar.

RFC 3403 beschrieb DNS und NAPTR, RFC 3404 URI Resolution und RFC 2916 eine frühe ENUM-Anwendung. Das waren Ausprägungen des Algorithmus, kein Beleg universeller Unterstützung. Das IANA-Register ENUM Service Registrations koordiniert Kennungen in einer späteren Anwendung; ein Eintrag beweist jedoch weder Ausführung, Frische, Autorität noch Diensterfolg.

Der RFC Editor führt für RFC 3402 gegenwärtig ein verifiziertes redaktionelles Erratum, Nummer 7049. Es korrigiert den Verweis auf die Erläuterung des p-Flags in RFC 3404 von Abschnitt 4.4 auf 4.3. Das algorithmische Prinzip bleibt unverändert.

Ein Betriebsbeleg muss die ursprüngliche AUS, Anwendung und Version, First Well Known Rule, Datenbanktyp, jeden Schlüssel, alle geordneten Regelmengen, Regelidentität und Ablauf, Übereinstimmung und Ausgabe, Serviceablehnung und Fortsetzungsposition, Priority-Entscheidung, Terminal-Flag, Ausgabeprüfung und Handlung des Verbrauchers bewahren.

Lu Hengs Prinzip der minimalen Anfangsspezifikation erklärt die Zurückhaltung: Standardisiert wurde nur die gemeinsame Grenze unabhängiger Implementierungen, während Anwendung und Datenbank ihre Semantik selbst festlegten. Vorrang des laufenden Codes verlangt den Nachweis dazu. Die AUS muss mit den beobachteten Regeln wiederholbar sein, ohne dass ein Zwischenschlüssel ihren Platz einnimmt.

RFC 3402 schützte somit Identität innerhalb der Delegation. Der Suchort durfte sich mehrfach ändern, ebenso jeder Schlüssel. Der Gegenstand, auf den jede Autorität antwortete, blieb derselbe.

Quellen