Zusammenfassung

  • RFC 3367 definierte einen interoperablen Kern für die Abfrage von Diensten für gebräuchliche Namen, die Beschreibung ihrer Fähigkeiten, Ergebnisse und Verweise sowie die Herkunft aus Dienst und Datensatz.
  • Ermittlung und Auswahl des Anbieters, Registrierung, Eigentum und Eindeutigkeit blieben absichtlich außerhalb. Eine einheitliche Anfrage entschied nicht, welche Institution antworten durfte.

Ende der neunziger Jahre nahmen Adressfelder längst nicht nur URLs entgegen. Menschen tippten Firmen-, Personen-, Buch- oder Ortsnamen ein. Browser und Portale verwandelten solche Ausdrücke in Navigation oder Suche, doch spezialisierte Verzeichnisse hatten unterschiedliche Schnittstellen.

Das Common Name Resolution Protocol sollte diesen Integrationspunkt vereinheitlichen. RFC 3367 erschien 2002 als Proposed Standard und definierte XML-Nachrichten für bereits bestehende Zuordnungen zwischen menschlichen Ausdrücken und Internetressourcen. Es war weder ein zweites DNS noch ein Weltverzeichnis.

Ein gebräuchlicher Name besaß keine vorgeschriebene Syntax. Anders als ein URI trug er keine formale Identifikationsstruktur, anders als ein URN verlangte er weder Eindeutigkeit noch Dauerhaftigkeit. Mehrere Dienste durften denselben Ausdruck mit verschiedenen Datensätzen verbinden.

CNRP begann nach der Wahl des Dienstes. Der Client konnte eine Dienstbeschreibung abrufen, Eigenschaften und Datensätze kennenlernen und dann fragen. Antworten konnten Ressourcenbeschreibungen, Statusmeldungen und Verweise enthalten. Ein Aggregator durfte mehrere Anbieter abfragen und die Herkunft jedes Ergebnisses bewahren.

Der Pflichtkern war klein: Name, dienstlokale Kennung, Ressourcen-URI und Beschreibung. Sprache, Geografie und Kategorie halfen beim Eingrenzen, waren aber Hinweise nach bestem Bemühen. Wie stark ein Dienst sie berücksichtigte, war ein Unterscheidungsmerkmal und keine Garantie gleicher Rangfolgen.

Eine CNRP-Anfrage war deshalb kein SQL-Filter. Ein Anbieter konnte das liefern, was seinen Kriterien am nächsten kam, und ignorierte Eigenschaften als Teilerfolg melden. Das Protokoll vereinheitlichte Behälter und Zustände, nicht Abdeckung, Ranking oder sämtliche Klassifikationen.

RFC 2972 zog die institutionelle Grenze: Diensterkennung und -auswahl, Verwaltung, Namensregistrierung, Eigentum und die Sicherung eindeutiger Namen gehörten nicht zum anfänglichen Umfang. Ein Client konnte mit einem bereits ausgewählten Ziel sprechen. Der Standard wählte es nicht aus.

Genau dort trat Autorität ein. Ein Browser mit einem kommerziellen Verzeichnis und einer mit einem regionalen Dienst konnten dieselbe Wortfolge senden und verschiedene regelkonforme Bindungen empfangen. CNRP zeigte deren Herkunft, erklärte aber keine zur globalen Antwort.

Öffentliche Namensräume machten Mehrdeutigkeit unvermeidbar. Personen-, Orts- und Werknamen hatten keine zentrale Zuteilungsstelle. Anbieter konnten ähnliche Ressourcen in unterschiedlichen Taxonomien organisieren. RFC 2972 räumte selbst ein, dass freie Kategoriewörter vollständige Interoperabilität nicht bewiesen.

RFC 3368 machte die Grenze im go:-URI sichtbar. Eine Form nannte einen Server, eine andere nur die Anfrage, die an konfigurierte Dienste des Clients ging. Derselbe kopierte String konnte auf zwei Rechnern andere Institutionen erreichen. Die Frage reiste; die Auswahl des Antwortenden nicht zwingend.

Der Transportstart war konkreter. Generische Clients und Server mussten HTTP auf Port 1096 für den Erstkontakt unterstützen. Danach konnte ein Dienst Alternativen ankündigen. Das erklärte den Kontakt zu einem bekannten Ziel, nicht seine Entdeckung oder Vertrauenswürdigkeit.

Verweise verlängerten den Abhängigkeitsgraphen. Ein Dienst konnte Ergebnisse liefern und auf einen weiteren Anbieter zeigen. Der Client musste besuchte Paare aus Dienst und Datensatz speichern, um Schleifen zu erkennen. Ein nicht erreichbares Verweisziel bedeutete möglicherweise Teilerfolg statt Vollständigkeit.

Die Sicherheitsbetrachtung führte zur gleichen Grenze. RFC 3367 nannte Mittelsmannangriffe, gefälschte Service-Objekte und Denial of Service durch eine zusätzliche Indirektion. Eine Signatur half, benötigte aber einen maßgeblichen öffentlichen Schlüssel. Dessen Beschaffung blieb außerhalb, weil sie von der Diensterkennung abhing.

Kryptografie schützt eine Aussage, nachdem der Vertrauensanker gewählt wurde. Sie wählt den Anker nicht. Kryptografische Gültigkeit und institutionelle Autorität sind verschiedene Belege.

Heute führt das IANA-Register go als Permanent und verweist auf RFC 3368; RFC 3367 bleibt Proposed Standard. Das beweist normative Verwahrung, nicht Browserunterstützung, aktive Server, Verkehr oder Nutzer. Auch die in RFC 2972 erwartete Marktintegration ist keine Einsatzmessung.

RFC 2396 und später RFC 3986 liefern den allgemeinen URI-Rahmen. RFC 2276 und RFC 2483 behandeln Auflösung rund um URNs, RFC 3401 eine andere delegierte Ermittlungsfamilie. Sie zeigen die damalige Entwurfslandschaft, aber keinen nachgewiesenen betrieblichen Ersatz.

Zwei Essays von Lu Heng bilden den offengelegten Analyserahmen. „Minimum Initial Specification“ erklärt den kleinen gemeinsamen Kern und spätere lokale Entscheidungen. CNRP standardisierte Austausch, nicht Autorität. „On Reality Layers“ trennt Protokollkonformität, Dienstidentität, Datensatzherkunft, Bindung, erreichbare Ressource und Nutzerabsicht.

Der Entwurf verbarg mehrfache Antworten nicht. Er erhielt Herkunft, meldete Teilerfolg und verlangte Schleifenerkennung. Das beseitigte nicht die Verteilungsmacht desjenigen, der die erste Dienstliste kontrollierte und damit den möglichen Antwortbereich vor der Anfrage formte.

RFC 3367 markiert somit eine klare Grenze: Das Internet konnte die Frageform teilen. Wer antworten durfte, erforderte eine weitere Governance-Entscheidung, die das Protokoll bewusst nicht traf.

Quellen