Summary

  • Revision 28 of the Concise Diagnostic Notation draft gives CBOR a richer readable form, including registered application extensions, but it does not turn source text into a self-contained execution contract.
  • A serious workflow needs an interpretation receipt that pins the draft revision, registry snapshot, extension implementation, allowlist, ignored indicators, warnings, resulting value and encoded bytes before that value is trusted downstream.

The useful thing about diagnostic notation is that a human can read it. The dangerous inference is that readability makes the meaning self-contained.

Revision 28 of the IETF CBOR working group's Concise Diagnostic Notation draft tries to consolidate the textual notation that grew around CBOR. A prefixed string can express more than a quoted run of characters. The prefix selects application logic: hexadecimal or Base64 text can become bytes; a date string can become a time-related value; an address can become an IP-oriented value. A prefixed sequence can pass parameters and still yield one CBOR data-model item.

That is convenient because it moves recurring conversions into a recognizable notation. It is also a control boundary. The source says which extension name it wants. It does not, by itself, prove which registry snapshot resolved that name, which implementation ran, which version supplied the algorithm, whether the operator enabled it, which options were active, which visible indicators were ignored, or which warning reached the reviewer.

This is not a criticism of the draft. The draft is unusually direct about several of these limits. It says CDN is for humans and is not a deterministic representation. A trip from a data item to text and back need not preserve the same textual form or encoded bytes. It says an encoding indicator on an extension argument can be ignored unless that extension defines special handling. A consumer must accept the indicator, either by processing or ignoring it, and a warning is recommended when it is not processed. It also tells implementations to document diagnostic behavior and options.

The security text goes further. A tool must avoid letting an attacker invoke extensions the operator did not plan to expose. Explicit enablement or an allowlist is a legitimate boundary; processing can be switched on out of band only where it is wanted. In other words, the notation is not the whole program. Local policy participates in interpretation.

A name is not a runtime

The draft proposes a registry for app-extension identifiers and makes a core set—h, b64, t1, b1, dt and ip—mandatory to implement. That lowers collision risk and gives specifications a shared vocabulary. It does not collapse the registry entry, the specification, the implementation and the deployment into one fact.

The registry policy is Expert Review. The text anticipates that a complete specification may not always be available and permits experts to register an identifier already deployed so that later allocations do not collide with it. This is sensible registry stewardship. It also means “registered” cannot safely be read as “fully specified, uniformly implemented, enabled here and approved for this use.” Those are separate propositions.

Consider a hypothetical release pipeline. A configuration file contains a prefixed literal. A development tool accepts it because every installed extension is enabled. A production gate uses an explicit allowlist and rejects the same prefix. The file hash matches. The identifier is real. The syntax is valid. The result differs because the operational contract differs. Calling one side non-compliant before recording the exact revision, extension and policy would be premature.

Now change the scenario slightly. Both tools accept the source, but one ignores an encoding indicator that the other processes. The draft allows acceptance through processing or ignoring when the extension itself defines no special meaning, with a recommended warning for the ignored case. A green parser result therefore cannot stand in for evidence that every visible annotation affected the value. Review needs the warning stream and the actual result, not only “parse succeeded.”

Revision 28 is itself a warning against false certainty

The current state deserves precise language. Datatracker shows active CBOR working-group work in working-group last call and an IESG state of “I-D Exists.” The document is an Internet-Draft, not an RFC or an approved standard.

The frozen records also disagree about intended status. The draft header says “Standards Track”; the Datatracker API records “Informational.” This article does not choose between them. Neither field is a final publication outcome.

More importantly, the revision-28 note says the revision reflects feature removals discussed on the mailing list as a delta from revision 27. It calls the resulting text somewhat inconsistent, warns that explanatory sections may be misleading because they no longer fully reflect the technical content, and says the working group has not yet supplied input on the CDN or b1/t1 naming decisions. The 27-to-28 diff indeed removes significant machinery, including the prior CRI extension, an encoding-indicator registry and binary-tag representations of CDN input.

That disclosure should change how a decision-maker treats the document. Revision 28 is valuable primary evidence for a mechanism under active review. It is weak evidence for a claim that every surrounding explanation has stabilized. A parser badge that says “supports draft 28” is also incomplete unless it identifies which removed features disappeared, which old behaviors remain behind flags and which registry snapshot it uses.

The seven claims hidden inside “it parsed”

When a dashboard reports that a CDN file parsed successfully, it compresses several claims:

  1. The exact source bytes were the bytes the reviewer saw.
  2. A named grammar revision accepted those bytes.
  3. A particular registry snapshot resolved every prefix.
  4. A concrete extension implementation and version processed each argument.
  5. The operator's allowlist and out-of-band settings permitted that processing.
  6. Indicator handling and warnings matched the review policy.
  7. The produced CBOR value—and, where relevant, its later encoding—matched the object approved for use.

These claims fail independently. A source hash can be correct while the extension package changed. A registry snapshot can be pinned while a local allowlist changed. A value can be stable while its byte encoding changes. An encoded object can be exact while the application lacks authority to act on it. A downstream schema can accept a value without proving where it came from or whether the requested operation was permitted.

The distinction matters most in automation. Humans often use diagnostic notation precisely because it is easier to inspect than binary CBOR. Once that notation enters a build, policy engine, device-management path or signing process, its readability can create an undeserved sense that code review covered execution. It did not, unless the execution dependencies were part of the review package.

Build an interpretation receipt

The missing object is an interpretation receipt. This is an operational recommendation, not a requirement stated by revision 28.

The receipt should record the source hash and the exact draft revision. It should identify the registry snapshot and the resolved extension identifier. It should name the extension specification, implementation and version, not merely the host parser. It should capture the allowlist and other out-of-band settings, the supplied parameters, the policy for encoding indicators, and every warning. It should then record a canonical description or hash of the resulting CBOR data-model value and, when exact bytes matter, the encoder profile and byte hash.

The receipt should end where the interpreter's authority ends. Schema validation, signature checks, authorization, network mutation and business outcome belong to later receipts. Combining them into one “valid” flag destroys the ability to locate a failure.

This evidence model follows a broader rule: a symbolic object and the running system that acts on it are different reality layers. CDN can improve the symbolic layer. It can make an intended value portable and reviewable. The localized future decision—what code runs, what is allowed, what value results and what the organization does with it—remains local. Shared notation reduces coordination cost; it does not abolish operational ownership.

What the sources do not prove

The frozen evidence does not show adoption rates, deployed interoperability, a named product's behavior, a security incident, a parser vulnerability, performance, or an outage. No such claim is needed for the control problem to be real. The problem follows directly from the draft's extension model, warning language, allowlist guidance, registry policy and explicit non-determinism.

Nor do adjacent standards close the gap. RFC 8949 defines CBOR and the earlier diagnostic notation. RFC 8610 defines CDDL. RFC 4648 defines base encodings, and RFC 3339 defines a date/time format. Those documents clarify individual layers. They do not prove that two deployed CDN interpreters share extension code and configuration. Deterministic CBOR work, including RFC 9741, addresses how a value is encoded; it does not decide which extension-derived value an interpreter should construct.

The right conclusion is narrow. A registered prefix is useful coordination. A successful parse is useful evidence. Neither is an execution receipt.