Zusammenfassung

  • RFC 9517 registriert ddi als formalen URN-Namensraum. Eine zugelassene Agentur, eine von ihr vergebene Ressourcenkennung und eine Version bilden den Namen.
  • Die Auflösung überführt die Agentur in ddi.urn.arpa, folgt DNS/DDDS und NAPTR, wählt einen Dienst und übergibt ihm den ursprünglichen URN.
  • Korrekte Syntax und ein dauerhafter Name belegen weder Zuteilung noch einen aktiven Dienst, legitime Verwahrung, Objektintegrität oder Erhaltung. Jede Ebene braucht einen eigenen Nachweis.

Im Katalog stand „persistenter Identifikator“. Die Zeichenfolge bestand jede Prüfung, und der Namensraum war bei IANA eingetragen. Trotzdem war ein gefundener Dienst nicht erreichbar; ein anderer lieferte nur Metadaten zu einer älteren Fassung. Der Name war stabil geblieben. Instabil waren die Infrastruktur und die Aussage, die man aus dem Namen abgeleitet hatte.

RFC 9517 erschien im Januar 2024 als Informational RFC im Independent Stream. Das Dokument registriert ddi für Ressourcen nach Standards der Data Documentation Initiative. Es ist kein IETF-Standard und kein Beleg für IETF-Konsens. Sein operativer Wert liegt in der sichtbaren Arbeitsteilung hinter einer scheinbar einfachen Kennung.

Wohlgeformt heißt nicht zugeteilt

Das Muster lautet urn:ddi:<Agentur>:<Ressource>:<Version>. Die DDI Alliance genehmigt die nach umgekehrten Domainregeln gebildete Agenturkennung. Die Agentur verwaltet anschließend Ressourcen, Versionen und gegebenenfalls Unteragenturen in ihrem Bereich.

Globale Eindeutigkeit entsteht durch zwei Pflichten. Die Alliance verhindert Kollisionen zwischen Agenturen; jede Agentur verhindert interne Kollisionen. Ein Parser sieht nur Zeichen und Trenner. RFC 8141 zieht die Grenze: Eine Zeichenfolge wird nicht allein durch urn: und passende Grammatik zu einem zugeteilten URN. NID-Registrierung und verwaltetes Zuteilungsverfahren gehören dazu.

Auch der Vergleich ist geteilt. urn, ddi und der Agenturteil sind nicht groß-/kleinschreibungssensitiv. Ressource und Version sind es. Vollständiges Kleinschreiben kann zwei Objekte verschmelzen; strikter Vergleich der Agentur kann dieselbe Autorität verdoppeln. Originalwert, Zerlegung und Normalisierung müssen erhalten bleiben.

Doppelpunkte konservieren keine Bestände

Die Spezifikation bindet Persistenz an fortbestehende Agenturzuteilung und geeignete Auflösungsdelegation. Für die referenzierte Ressource bleibt die Agentur verantwortlich. Ein URN kann in Publikationen überleben, während DNS, Katalog, Dateien oder Zugriffsregeln verschwinden.

Die Versionskennung trennt Revisionen nach Agenturregeln. Sie beweist nicht, dass ein Repository diese Revision ausgeliefert hat oder dass mehrere Kopien übereinstimmen. Dafür braucht es zurückgelieferte Kennung, Hash, Provenienz und Erhaltungsnachweis.

Unteragenturen erleichtern verteilte Verwaltung, schaffen aber eine weitere Zuständigkeitsgrenze. Die Hauptagentur kann registriert bleiben, obwohl sich Betreiber oder Server des Zweigs geändert haben. Der vollständige Autoritätspfad gehört in den Datensatz.

Auflösung ist eine Kette von Übergaben

Der Client extrahiert die Agentur, normalisiert deren Schreibung, dreht punktgetrennte Labels um und hängt .ddi.urn.arpa an. DNS dient als DDDS-Datenbank. Die Anfrage kann von urn.arpa über die DDI Alliance zum Server der Agentur delegiert werden.

NAPTR beschreibt Dienste. Ein terminales u kann eine URI liefern; s führt zu SRV. Der Client wählt einen passenden Dienst und sendet den ursprünglichen URN. Das erwartete Ergebnis sind Verbindungsdaten, nicht die Ressource und kein Beweis für einen aktiven oder weiterhin autorisierten Endpunkt.

Erfasst werden sollten Resolver, Zeit, TTL, Cachealter, Validierung, sämtliche NAPTR-Felder, SRV-Ergebnis, Auswahlgrund, TLS-Identität und Antwort. „Aufgelöst“ sagt ohne diese Daten nicht, welche Autorität gesprochen hat.

I2R kann eine Ressourceninstanz liefern, I2C eine Beschreibung, I2L einen Ort und I2Ls mehrere Orte. Eine korrekte Beschreibung kann ein verlorenes Objekt überdauern. Eine lebende URL kann eine andere Version liefern. Mehrere Orte können widersprechen. Ein gemeinsames gefunden vernichtet die Bedeutung des Diensttyps.

DoH authentifiziert nicht die Forschungsressource

RFC 9517 nennt das Sicherheitsprofil wegen öffentlicher Informationen niedrig, verweist aber auf allgemeine DNS-Risiken. DoH kann die Strecke vom Client zum gewählten Resolver schützen. Es authentifiziert nicht die Agentur, den Dienst oder das Objekt.

DNSSEC, verschlüsselter Transport, TLS, institutionelles Mandat und Objekthash oder -signatur sind getrennte Fakten. Die Belegkette führt von Registrierung und Syntax über Agentur und Zuteilung, Delegation und Diensttyp, Endpunktidentität und exakte Version bis zu Objektprüfung und verantworteter Nutzung.

Der dauerhafte Name hält die Frage während all dieser Veränderungen stabil. Er ersetzt keine Antwort und keine Verwahrung.

Quellen