Zusammenfassung

  • Der globale Namensraum in RFC 3650 war föderiert: Eine eindeutige Namensautorität und ein darunter eindeutiger lokaler Name ergaben ein im System eindeutiges Handle; bestehende lokale Namen und Wertbindungen konnten erhalten bleiben.
  • Die Global Handle Registry (GHR) lieferte vor allem Autoritäts- und Dienstinformationen, mit denen sich der zuständige Handle-Dienst finden ließ. Local Handle Services (LHS) lösten normalerweise Handles unter ihren jeweiligen Autoritäten auf.

Ein globaler Name verlangte keine globale Datenbank

Die historische Frage von RFC 3650 war mehr als die Schreibweise eines dauerhaften Bezeichners. Wie konnten getrennte Namensräume und Verwaltungsbereiche einen gemeinsamen Namensraum nutzen, ohne jeden Ressourceneintrag einem zentralen Betreiber zu überlassen? Die Antwort lag in der Trennung von Name, Autorität und Dienstsuche.

Ein Handle besteht aus einer Namensautorität – dem Präfix – und einem lokalen Namen, dem Suffix. Die Autorität ist im Handle System eindeutig; der lokale Name muss unter dieser Autorität eindeutig sein. Zusammen machen sie das Handle innerhalb des Systems eindeutig. Ein bestehender lokaler Namensraum konnte mit einer eigenen eindeutigen Autorität beitreten und seine lokalen Namen samt Wertbindungen beibehalten. „Global“ bezeichnete somit den gemeinsamen Eindeutigkeitsraum, keine einheitlich verwaltete Datenbank. RFC 3650

Auch die Dienstarchitektur folgte dieser Trennung. RFC 3650 platzierte die Global Handle Registry (GHR) an der Spitze und darunter die Local Handle Services (LHS). Das Handle einer Autorität enthielt Dienstinformationen – Standorte und Server-Schnittstellen –, über die ein Client den zuständigen „Heimatdienst“ erreichen konnte. Zuerst fragte er diese Informationen bei der GHR ab, danach wandte er sich an den für das angefragte Handle verantwortlichen Dienst. Das Register fungierte als Karte der Dienstzuständigkeit; es musste nicht alle lokalen Werte speichern. RFC 3650 · RFC 3651

„Lokal“ meinte hier Namensraum und Verwaltungsverantwortung, nicht geografische Nähe. Ein LHS konnte mehrere über das Internet verteilte Standorte und mehrere Server pro Standort haben. Replikation und mehrere Standorte waren Architekturvarianten, aber kein Nachweis gemessener Verfügbarkeit einer konkreten Installation.

Eine Registrierungs-Hierarchie war keine Befehlskette

Namensautoritäten konnten baumartig angeordnet sein. Eine übergeordnete Autorität musste registriert sein, bevor sie eine untergeordnete registrieren konnte. RFC 3650 stellt jedoch klar, dass diese Reihenfolge keine Verwaltungsbeziehung begründete: Eltern- und Kind-Namensräume konnten von verschiedenen Diensten bedient werden und mussten keine Verwaltungsrechte teilen. Aus dem Baum folgt nicht, wer Handles des Kind-Namensraums ändern, Streitfälle entscheiden oder den fortlaufenden Betrieb sichern kann. RFC 3650

Die GHR war allerdings auch kein reiner Index, der nie einzelne Handles verwaltete. Laut RFC 3650 konnte sie beliebige Handle-Namensräume verwalten; RFC 3651 lässt außerdem zu, dass sie manche Handles außerhalb von Namensautoritäten verwaltet, auflöst oder administriert. Präziser ist: Die besondere Rolle der GHR lag in der Verwaltung der Autoritäts-Handles und ihrer Dienstinformationen, während lokale Dienste normalerweise für die ihnen zugeordneten Namensräume zuständig waren. RFC 3651

Der einem Handle zugeordnete Wert konnte sich ändern, während der Bezeichner gleich blieb. So ließ sich etwa ein Standort aktualisieren. Die Syntax allein garantierte jedoch keine Dauerhaftigkeit: RFC 3650 machte sie von sorgfältiger Verwaltung abhängig. Eine stabile Zeichenfolge zwingt keine Institution, ihre Einträge, einen Resolver oder das Ziel weiter zu betreiben. RFC 3650

Benachbart zu anderen Bezeichnersystemen, aber nicht austauschbar

RFC 3650 vergleicht das Handle System mit bestehenden Benennungsdiensten, ohne sie gleichzusetzen. DNS organisiert Namen und Auflösung über eine eigene Zonen-Delegation. URN-Spezifikationen behandeln Namen, die Ressourcen unabhängig von ihrem Standort identifizieren sollen; die Suche nach einem Auflösungsdienst ist eine getrennte Aufgabe. Ein Handle kann Anwendungen mit Bedarf an stabilen Namen oder Auflösung dienen, ist aber nicht automatisch eine URN. Eine Handle-Antwort beweist auch nicht, dass die Ressource erreichbar ist. RFC 1034 · RFC 1737 · RFC 2276 · RFC 3406 · RFC 8141

Auch der Veröffentlichungsstatus ist wichtig. RFC 3650 ist Informational und kein Internetstandard. Der IESG-Hinweis besagt, dass Gruppen in IETF und IRTF das System diskutiert hatten, aber keinen IETF-Konsens über die beschriebene Architektur oder ihren Platz in der IETF-Bezeichnerarchitektur erzielt hatten. Das ist weder Zustimmung noch Ablehnung, sondern markiert die Grenze zwischen einem veröffentlichten Architekturvorschlag und institutionellem Konsens. RFC 3650

Der historische Kern war eine Verteilung von Funktionen: Ein Wurzelregister wies jeder Namensautorität einen Dienst zu, während getrennt verwaltete Dienste ihre lokalen Namensräume halten und auflösen konnten. Ob diese Zuordnung nützlich blieb, hing von den Einträgen, Betreibern und Dienstpfaden ab, die sie aktuell hielten. RFC 3650 beschreibt, wie diese Grenzen zusammenspielen können; es beweist weder weltweite Auflösung noch Dauerhaftigkeit, breite Einführung oder den erfolgreichen Zugriff auf eine bestimmte Ressource.

Quellen: RFC 3650; RFC 3651; RFC 3652; RFC 1737; RFC 2276; RFC 3406; RFC 8141; RFC 3986; RFC 1034.