Zusammenfassung

  • RFC 3981 machte den IRIS-Kern bewusst unvollständig: Erst Schemas der Registertypen definierten sinnvolle Abfragen, Ergebnisse und Entitätsklassen; ein gesonderter Transport regelte Authentisierung und Sitzungen.
  • Der gemeinsame Rahmen war keine universelle Registersemantik. Gültigkeit, Serverfähigkeit, Ressourcenpolitik, Berechtigung, Verweis und endgültiges Ergebnis blieben voneinander getrennte Aussagen.

Drei Schichten können dasselbe Paket berühren, ohne dieselbe Entscheidung zu besitzen. Ein Registertyp entscheidet, was eine Abfrage bedeutet. Der gemeinsame Rahmen entscheidet, wie sie verpackt und wie auf weitere Stellen verwiesen wird. Ein Anwendungstransport entscheidet, wie Nachricht, Authentisierung und Sitzung befördert werden. Wer diese Zuständigkeiten zusammenzieht, schreibt einer technischen Schicht Autorität zu, die sie nie erhalten hat.

Genau diese Trennung bildet RFC 3981 ab. Das im Januar 2005 veröffentlichte Standards-Track-Dokument spezifizierte den XML-basierten Kern des Internet Registry Information Service, IRIS. Statusseite, Errata und Datatracker-Akte belegen auch die spätere Aktualisierung durch RFC 4992. Sie belegen weder Verbreitung noch einen heute erreichbaren Dienst.

Auf der ersten Ebene definierten registerspezifische Spezifikationen Abfragen, Ergebnisse und Entitätsklassen. Die gemeinsame IRIS-Registerebene lieferte Such- und Ergebnismengen, Referenzen, Fortsetzungen sowie die Kennzeichnung von Registertypen. Die Anwendungstransportebene kümmerte sich um Authentisierung, Nachrichtenübertragung, Verbindungs- und Sitzungsverwaltung und transportspezifische URI-Syntax. Der gemeinsame Teil verband die Ebenen, ersetzte sie aber nicht.

RFC 3981 bezeichnete das Basisschema selbst als allein nur begrenzt nützlich. Es enthielt einen abstrakten Abfragetyp, zwei eigenständig auftretende Ergebnistypen und keine Registerstruktur. Jeder Registertyp erhielt eine URN, die zugleich XML-Namensraum und Schema bezeichnete. Ein Dienst konnte mehrere Typen anbieten; daraus entstand jedoch weder ein weltweites Register noch ein vorgeschriebener gemeinsamer Baum.

Die Spezialisierungen waren folglich Teil des Plans. RFC 3982 samt Statusnachweis definierte den Domain-Registertyp. RFC 4698 definierte den Adress-Registertyp. Ihre getrennten Modelle zeigen nicht, dass der Kern etwas vergessen hatte, sondern wo die jeweilige Bedeutung hingehörte.

Auch Lookup und Suche waren nicht austauschbar. Ein Lookup gleicht einen diskreten Wert mit einem Index ab. lookupEntity nennt Registertyp, Entitätsklasse und Entitätsnamen. Teilwerte, mehrere Indizes oder mehrere Abfragen gegen einen Index bilden dagegen eine weitergehende Suche. Für alle IRIS-Typen gab es keine einheitliche Standardsuchsprache. Jeder Typ sollte genau die Sucharten festlegen, die zu Daten und Betrieb passten.

Der Anhang nannte die Gegenidee die „Verlockung eines universellen Clients“. Ein generischer Client konnte einen Lookup ausführen und das Ergebnis grob darstellen. Für eine brauchbare Suche und eine verständliche Präsentation benötigte er weiterhin Wissen über die Daten. Eine gemeinsame Abfragesprache beseitigte dieses Wissen nicht; sie zwang die Absicht des Nutzers lediglich durch einen kleinsten gemeinsamen Nenner.

Für öffentliche Register kam der Ressourcenkonflikt hinzu. Eine flexible Kombination partieller Werte über mehrere Indizes hilft fachkundigen Nutzern, kann aber ebenso Missbrauch erleichtern. Betreiber würden teure Funktionen abschalten, um den Dienst zu schützen. Dann verspräche die gemeinsame Sprache Fähigkeiten, die gerade nicht überall verfügbar wären. RFC 3707 und der zugehörige Status dokumentieren die früheren CRISP-Anforderungen zu Suche, verteilten Verweisen, Versionierung und missbräuchlichen Nutzern. Das erklärt den Entwurfsrahmen, misst aber weder Angriffe noch Leistung.

Selbst Verweise trugen unterschiedliche Evidenz. Eine Entitätsreferenz bedeutete konkretes Wissen über eine andere Entität. Eine Suchfortsetzung bedeutete nur, dass eine andere Stelle vielleicht zum Gesuchten, zu anderem Material oder zu nichts führen würde. Um Schleifen zu vermeiden, sollte ein Client jede Antwort nur einmal verfolgen. Ein empfangener Verweis bewies deshalb weder Erreichbarkeit noch endgültige Zuständigkeit oder Ergebnis.

Die Fehlerarten hielten weitere Grenzen offen: invalidName betraf die Syntax, invalidSearch die Bedeutung, queryNotSupported die Fähigkeit des Servers, limitExceeded die Ressourcenpolitik, nameNotFound den gewählten Index und permissionDenied die Berechtigung des authentisierten Gegenübers. Ein gültiges XML-Dokument konnte immer noch eine unsinnige, nicht unterstützte, zu teure oder nicht berechtigte Abfrage enthalten.

Auch der Transport blieb austauschbar. RFC 3983 und seine Statusseite bildeten IRIS auf BEEP ab. Später aktualisierte RFC 4992 RFC 3981 mit XPC, einem TCP-Transport für segmentiertes und gepipeltes XML; Status, Errata und Datatracker dokumentieren diesen Schritt. Andere Rahmen oder Sitzungen verleihen dem Transport keine registerspezifische Deutungshoheit.

Im heutigen IANA-Verzeichnis der URI-Schemata stehen iris und verwandte Transportschemata; das IETF XML Registry führt den Namensraum iris1. Das sind Registrierungsnachweise, keine Belege für laufende Server, breite Einführung oder erfolgreiche Abfragen.

RFC 3981 setzte damit eine Grenze gegen scheinbar bequeme Zentralisierung. Gemeinsame Gelenke konnten Interoperabilität schaffen, ohne den beteiligten Registern ein gemeinsames Innenleben anzudichten. Die Unvollständigkeit des Kerns war kein Defekt, sondern eine lesbare Verteilung von Verantwortung.

Sources