Zusammenfassung

  • Revision 28 der Concise Diagnostic Notation ordnet die menschenlesbare Darstellung von CBOR und registrierte App-Erweiterungen, macht den Quelltext aber nicht zum vollständigen Ausführungsvertrag.
  • Für geschützte Abläufe braucht es einen Interpretationsbeleg mit Entwurfsrevision, Registry-Snapshot, Erweiterung, Implementierung, Version, Allowlist, Warnungen, Ergebniswert und gegebenenfalls Byte-Hash.

Lesbarkeit ist eine Eigenschaft der Darstellung, nicht automatisch eine vollständige Beschreibung der Ausführung. Genau diese Verwechslung wird riskant, wenn Diagnose-Text in Automatisierung gelangt.

Der Internet-Draft Concise Diagnostic Notation der IETF-CBOR-Arbeitsgruppe konsolidiert die Textdarstellung des CBOR-Datenmodells. Ein String mit Präfix ruft Anwendungslogik auf. h und b64 können Text in Bytes umwandeln, dt verarbeitet Zeitdarstellungen, ip Adressen und Präfixe. Eine präfixierte Sequenz kann Parameter übergeben und ein einzelnes Datenelement liefern.

Die Quelle nennt aber nur die gewünschte Erweiterung. Sie belegt nicht, welcher Registry-Stand den Namen aufgelöst hat, welche Spezifikation und Implementierung galten, welche Version installiert war und ob der Betreiber den Aufruf zugelassen hatte. Optionen, Plugin-Pakete, Allowlist und Warnungsverarbeitung liegen außerhalb des Textes.

Revision 28 benennt diese Grenze. CDN ist für Menschen gedacht und keine deterministische Darstellung. Ein Rundweg vom Wert zum Text und zurück muss weder dieselbe Schreibweise noch dieselben codierten Bytes ergeben. Ein Codierungsindikator am Argument einer Erweiterung kann verarbeitet oder ignoriert werden, wenn die Erweiterung keine Sonderbehandlung definiert; beim Ignorieren wird eine Warnung empfohlen. „Parsing erfolgreich“ beweist deshalb nicht, dass jedes sichtbare Zeichen wirksam wurde.

Die Sicherheitsbetrachtung verlangt außerdem, dass Werkzeuge unbeabsichtigte Erweiterungsaufrufe durch Angreifer verhindern. Explizite Aktivierung und Allowlisting sind vorgesehene Grenzen; Verarbeitung kann außerhalb des Dokuments aktiviert werden. Zwei Interpreter dürfen denselben Text unterschiedlich behandeln, weil ihre Betreiber unterschiedliche Fähigkeiten freigegeben haben.

Registry, Code und Politik bleiben getrennt

Der Entwurf richtet eine Registry für App-Erweiterungskennungen ein und verlangt die Implementierung von h, b64, t1, b1, dt und ip. Das vermeidet Namenskollisionen. Es vereinigt jedoch Registry-Eintrag, Erweiterungsspezifikation, Laufzeitcode und Einsatzpolitik nicht zu einer Garantie.

Die Vergaberegel lautet Expert Review. Der Text berücksichtigt, dass eine vollständige Spezifikation noch fehlen kann und eine bereits eingesetzte Kennung registriert wird, um Kollisionen zu verhindern. „Registriert“ ist damit ein Beleg für Namenskoordinierung, nicht automatisch für vollständige Semantik, einheitliche Implementierung, sichere Aktivierung oder Handlungsbefugnis.

In einer hypothetischen Lieferkette lädt die Entwicklungsumgebung alle installierten Erweiterungen. Produktion erlaubt nur ein minimales Profil. Dieselbe Datei wird einmal umgesetzt und einmal abgelehnt. Hash und Name stimmen überein; die lokale Kontrollentscheidung ist verschieden. Ohne die Allowlist im Prüfbeleg bleibt der Unterschied unerklärlich.

Selbst zwei Erfolge können abweichen. Ein Werkzeug verarbeitet einen Indikator, das andere ignoriert ihn regelkonform und erzeugt eine Warnung, die das Dashboard verwirft. Beide zeigen Grün. Erst Ergebniswert und Warnungsstrom zeigen, was wirklich geschah.

Der aktuelle Entwurf warnt vor Übergewissheit

Datatracker führt Revision 28 als aktiven Internet-Draft der CBOR-Arbeitsgruppe im Working Group Last Call mit IESG-Status „I-D Exists“. Sie ist kein RFC und kein verabschiedeter Standard.

Auch der Zielstatus ist widersprüchlich: Der Dokumentkopf nennt „Standards Track“, die Datatracker-API „Informational“. Dieser Beitrag entscheidet den Widerspruch nicht und macht aus keinem Feld ein Endergebnis.

Die Editionsnotiz sagt, Revision 28 solle diskutierte Funktionsstreichungen als Delta zu 27 abbilden. Der Text sei dadurch teilweise inkonsistent; erklärende Abschnitte könnten irreführend sein; zur Benennung von CDN sowie b1/t1 fehle noch WG-Input. Der Vergleich entfernt unter anderem die CRI-Erweiterung, eine Registry für Codierungsindikatoren und binäre Tag-Darstellungen von CDN-Eingaben.

Eine Herstellerangabe „Revision 28 unterstützt“ reicht deshalb nicht. Zu klären ist, ob entfernte Funktionen wirklich verschwanden, hinter Kompatibilitätsoptionen weiterleben, welcher Registry-Stand benutzt wurde und welches Verhalten aus dem aktuellen technischen Kern stammt.

Sieben Nachweise hinter einem grünen Status

Ein belastbarer Bericht trennt: exakte Quellbytes und Hash; akzeptierte Grammatikrevision; Registry-Snapshot; Erweiterungsspezifikation, Implementierung und Version; Parameter und Allowlist; Indikatorbehandlung und Warnungen; erzeugten Datenmodellwert sowie bei Byte-Relevanz Codierungsprofil und Hash.

Diese Ebenen ändern sich unabhängig. Der Quelltext bleibt gleich, während das Erweiterungspaket aktualisiert wird. Die Registry bleibt gleich, während die lokale Politik wechselt. Der Wert bleibt gleich, während die Bytes variieren. Exakte Bytes schaffen noch keine Befugnis, ein Netz oder Gerät zu verändern.

Darum sollte ein hochwirksamer Ablauf einen Interpretationsbeleg erzeugen. Das ist Daniel Kades operative Empfehlung, keine Forderung der Revision 28. Er hält Quelle, Revision, Registry, Kennung, Spezifikation, konkrete Implementierung und Version, Parameter, externe Einstellungen, Allowlist, Indikatorpolitik, Warnungen, Ergebniswert und nötigenfalls Byte-Hash fest.

Der Beleg endet am Interpreter. Schema, Signatur, Autorisierung, Netzänderung und Geschäftswirkung benötigen nachgelagerte Nachweise. Ein einziges „gültig“ verwischt die Fehlerstelle.

Die Quellen beweisen keine Verbreitung, gemessene Interoperabilität, Produktfunktion, Sicherheitslücke, Störung oder Performance. Das Argument benötigt solche Behauptungen nicht. Erweiterungsmodell, Ignorieren von Indikatoren, Registry-Regeln, externe Aktivierung und Nichtdeterminismus zeigen die Abhängigkeit bereits.

RFC 8949, 8610, 4648 und 3339 ordnen CBOR, CDDL, Basis-Codierungen und Zeit. Sie beweisen keine identischen Laufzeiten. RFC 9741 betrifft die deterministische Codierung eines bereits bestimmten Werts, nicht die vorgelagerte Wahl des Erweiterungswerts.