Zusammenfassung

  • RFC 5328 registriert dvb als formalen URN-Namensraum. Einzelne Namen entstehen im DVB-Standardisierungsprozess; ihre Katalogmitgliedschaft belegt Zuweisung, aber weder Resolver-Erreichbarkeit noch Ressourcenherkunft.
  • RFC 7354 änderte nur Registrierungs- und Kontaktfelder. Resolverpfade bleiben geräteabhängig, und Authentisierung von Name oder Ressource muss als getrennte Information neben dem URN geführt werden.

Ein gepflegter Registereintrag sah wie Betriebsbereitschaft aus

Der Audit zeigte eine aktuelle Rollenadresse und einen benannten Registranten. Das Dashboard übernahm dieses Datum als Frischewert des Dienstes. Kein Empfänger hatte einen Resolver abgefragt, keine Broadcast-Aufzeichnung lag vor, und kein Resource Record war geprüft worden.

Der Registereintrag war richtig. Die Interpretation war es nicht. Er belegte, wer für den Namensraum administrativ erreichbar sein sollte. Er belegte nicht, welche Resolver Authority ein bestimmtes Gerät zu diesem Zeitpunkt fand oder ob deren Antwort autorisiert war.

Diese Verwechslung ist attraktiv, weil Governance-Daten dauerhaft und leicht abfragbar sind. Laufzeitbelege sind dagegen verteilt. Gerade deshalb müssen beide Oberflächen getrennt bleiben.

Das NID-Register weist keine Einzelressource zu

RFC 5328 deklariert urn:dvb:<NSS>. IANA registriert den Namespace Identifier dvb und seine Referenzen. DVB vergibt einzelne URNs über seinen Standardisierungsprozess und kann Teile des Namensraums an ausdrücklich benannte Stellen unter seinem Regime delegieren.

Ein syntaktisch korrektes Präfix belegt daher noch keine Zuweisung. RFC 8141 formuliert diese Grenze allgemein: Die korrekte Form einer mit urn: beginnenden Zeichenfolge genügt nicht; NID und assigned-name müssen den registrierten Regeln entsprechen.

Ein belastbarer Beleg enthält Eingabe, Vergleichsform, NID-Registerversion, DVB-Regelstand, Zuweiser, Delegation, Katalogidentität, Katalogversion und Mitgliedschaftsergebnis.

Wer nur valid=true speichert, entfernt genau die Autorität, die das Urteil getragen hat.

Der Katalog beantwortet die Zuweisungsfrage

RFC 5328 gibt keinen im Namen eingebauten Validierungsmechanismus an. DVB soll URN-Kataloge pflegen; die Präsenz eines URN in einem Katalog zeigt seine Gültigkeit.

Das ist ein klarer Geltungsbereich. Katalogmitgliedschaft beweist nicht, dass ein Receiver einen Einstiegspunkt entdeckt, dass der gefundene Resolver denselben Katalogstand verwendet, dass der Locator erreichbar oder die Ressource authentisch ist.

Ein neuer Katalog kann bereits veröffentlicht sein, während ein Broadcast-Pfad noch ältere Resolution Records zyklisch sendet. Ein IP-Resolver kann eine andere Cache-Epoche halten. Beide erkennen den Namen an und geben dennoch verschiedene Orte zurück.

Katalogpublisher, Authority, Version, Veröffentlichungszeit und Beobachtungszeit gehören in einen eigenen Receipt. Resolverauswahl und Antwort beginnen danach.

Persistenz fixiert nicht den Endpoint

DVB verpflichtet sich, vergebene Zeichenfolgen nicht neu zu vergeben, und erklärt die Zugänglichkeit und Persistenz offiziell benannter Ressourcen zum Ziel.

Das ist eine institutionelle Eigenschaft des Namenssystems, kein permanenter Uptime-Test. Ein ortsunabhängiger Name soll einen Locatorwechsel überstehen. Ein alter Server kann verschwinden, während der Name mit neuen Resolution-Daten fortbesteht.

Umgekehrt garantiert ein gültiger Name nicht, dass DNS, Multicast, HTTP oder der Broadcast-Kanal in jedem Moment funktionieren. Namensstatus, Katalogstatus, Pfadstatus und Ressourcenabruf benötigen eigene Zeitstempel.

Wer die Lebensdauer des URN an einen historischen Endpoint bindet, macht aus dem persistenten Namen wieder einen Locator.

Empfängerklassen haben verschiedene Startpunkte

RFC 5328 nennt bewusst keinen einzigen Resolution- oder Delegationsmechanismus. Die vorgesehenen Geräte haben unterschiedliche Zugangswege.

Eine nur empfangende Set-top-Box muss Resolution-Information aus den Service-Discovery-Daten des Broadcast-Streams beziehen. Ein Heimnetzgerät kann über ein Gateway IP verwenden. Ein erfolgreicher HTTP-Test im Rechenzentrum sagt nichts über den Broadcast-Carousel am Fernseher.

Das Dokument beschreibt wiederholt gesendete Resolution Authority Records und Resolution Records im Digital-TV-Stream, zyklische Multicast-RR über DVBSTP und Unicast-RR als Antwort auf GET /dvb/sdns.

Jeder Pfad hat eigene Ausfall- und Beobachtungsgrenzen: Zykluszeit und Empfangsbeginn, Multicast-Join und Routing, Endpoint-Discovery und Verbindung. Ein gemeinsames resolved löscht die Information, welcher Pfad tatsächlich funktionierte.

Bootstrap-Koordinaten sind noch kein Dienst

Vor der Resolution braucht der Client einen Service-Discovery-and-Selection-Einstieg. RFC 5328 beschreibt dvbservdsc, TCP oder UDP, Port 3937, registrierte Multicast-Adressen und DNS-SRV-basierte Discovery nicht standardmäßiger Einstiegspunkte unter services.dvb.org.

IANA-Zuweisung belegt die gemeinsame Bedeutung einer Koordinate, nicht einen Listener. Eine registrierte Multicast-Adresse belegt weder Route noch Gruppenmitgliedschaft oder Empfang. Eine SRV-Antwort nennt ein Ziel, aber nicht dessen Erreichbarkeit, Authority oder Datenfrische.

Der Bootstrap-Receipt endet bei Methode, Antwort, Ziel und Zeit. Danach folgen Verbindung, Auswahl der Resolution Authority, Resolution Record und Locator.

RFC 8553 brachte die in RFC 5328 und vielen anderen Dokumenten verwendeten unterstrichenen DNS-Namen in das integrierte IANA-Registrierungsmodell. Ein registriertes _dvbservdsc ist kein beobachteter SRV RR und kein laufender Dienst.

Groß-/Kleinschreibung schließt nur den Namensvergleich

Der NSS ist laut RFC 5328 nicht case-sensitiv. Zwei Schreibweisen können daher denselben Namen darstellen.

Das macht weder zwei Resolverantworten noch zwei Katalogprojektionen oder Inhalte gleich. Eine Untersuchung bewahrt Literalform und normalisierte Form und vergleicht danach Authority-Epoche, Locator-Menge, Cachealter und Content-Hash.

Wenn gleichwertige Namen verschiedene Ressourcen liefern, liegt die Abweichung hinter dem Vergleich. „Der URN war derselbe“ ist dann der Anfang der Analyse, nicht ihr Abschluss.

Authentisierung bleibt außerhalb des URN

RFC 5328 sagt ausdrücklich: Wird ein URN in einen Ort übersetzt und die Ressource verwendet, kann Authentisierung erforderlich sein. Information zur Authentisierung des Namens oder der referenzierten Ressource soll getrennt mit dem URN übertragen werden, nicht im URN selbst.

Weder dvb-Präfix, Katalogtreffer, SRV-Ziel, richtiger Port, HTTP-Erfolg noch darstellbare Bytes bilden automatisch eine Vertrauenskette. Der Receipt muss Objekt, Mechanismus, Trust Anchor, Policy und Zeitpunkt nennen.

Sicherheitsfolgen besonderer Bedeutungen, die DVB einzelnen NSS-Zeichen zuweist, liegen ebenfalls außerhalb des RFC. Ein generischer Parser darf aus einer scheinbaren Hierarchie keine Berechtigung ableiten.

Eine authentische Ressource kann inkompatibel oder nicht autorisiert sein. Eine nicht authentisierte Ressource kann technisch dargestellt werden. Herkunft, Kompatibilität und Nutzung sind getrennte Urteile.

RFC 7354 änderte genau zwei Verwaltungsfelder

Das spätere Dokument ersetzte Registration Information und Declared Registrant, nahm eine Rollenadresse auf und erklärte alle anderen Felder für unverändert.

Damit lässt sich eine präzise Aussage treffen: Der administrative Kontakt wurde gepflegt. Es lässt sich keine Aussage über Katalogpublication, Resolvermigration, DNS-Zustand, Multicast-Reichweite oder Empfängererfolg ableiten.

Ein aktueller Kontakt und ein ausgefallener Dienst können gleichzeitig wahr sein. Ein erreichbarer Dienst und veraltete Kontaktdaten ebenso. Die Maßnahmen, Verantwortlichen und Risiken sind verschieden.

Lehrbeispiele sind keine Inventarobjekte

RFC 5328 zeigt zwei URNs und warnt, dass sie nur pädagogisch sind und nicht real sein müssen. Ein Dokumentenparser, der sie in ein Asset-Inventar übernimmt, erzeugt aus Syntaxbeispielen operative Behauptungen.

Für Inventarstatus braucht es Zuweisung und Katalogbeleg. Für Monitoring zusätzlich Resolution Authority, Scope und Verantwortlichkeit. Ein echtes NID macht nicht jede konstruierbare Zeichenfolge darunter real.

Abruf ist nicht Anwendungserfolg

Resolution kann Locator, Metadaten oder eine Repräsentation liefern. Danach kommen Abruf, Authentisierung, Frische, Parsing, Transformation, Rendering, Anwendungsautorisierung und Outcome.

Die Gerätevielfalt des RFC macht diese Intervalle sichtbar. Eine Web-Repräsentation kann für ein anderes Endgerät eine Transformation benötigen. Richtige Metadaten können unerreichbaren Content beschreiben. Ein gerendertes Bild belegt keine abgeschlossene Interaktion.

Content-Hash, Parser- und Renderergebnis sowie Anwendungsresultat verhindern, dass eine Transportantwort zum Diensterfolg aufsteigt.

Entscheidungsreceipt

Speichern: literal und normalisiert dargestellten URN; NID-Register; DVB-Regel; Zuweiser und Delegation; Katalogidentität, Version und Mitgliedschaft; Empfängerklasse; Kanal; Bootstrap; RAR/RR/DVBSTP/HTTP/DNS-Beobachtung; gewählte Authority; Locator; externe Authentisierung; Content-Hash und Frische; Parser, Renderer, Autorisierung und Outcome.

Der URN verbindet diese Datensätze. Er bestätigt keinen davon stellvertretend.

Quellen