[Cbor] Re: registrations before WGLC Re: I-D Action: draft-ietf-cbor-edn-literals-23.txt

[Carsten Bormann <[e-mail]>]

On May 1, 2026, at 19:10, Rohan Mahy <[e-mail]> wrote:
> 
> If you don't want complexity, you should get rid of have backtick quotes altogether. They add a LOT of complexity,

I don’t think they do.
I usually implement improvements before I propose them, and raw strings (backquotes) wen’t in pretty surgically.
OK, there are 99 lines of new test cases, but these already are done and do not causes repeated work for every implementer.
I must admit that for the PoC I did a bit of copy/paste in the annotated ABNF, so there are 25 new lines.
There was zero impact on other parts of the system, and that would have been *real* complexity.
(Well, I also needed to write two new integrated parsers for those who want them, but even that was trivial given the simplicity of raw strings.)

> and they merely provide an additional way to do something that we can already do.

During the strong mission creep that the edn-literals project underwent, the WG at some point decided that we were going to address usability problems of the underlying JSON approaches.
I believe we were quite successful in that, even if we needed to make late updates to the comment syntax and in adding rawstrings.

At the time JSON was derived from JavaScript, JavaScript didn’t have raw strings, so JSON doesn’t have them either.
Since then, almost every long-lived language had to bolt on raw-ish strings; between the mainstream programming languages, only C remains in this class (not C++).
JavaScript has an interesting concept (also using backquotes) called templates that addresses some, but doesn’t solve all problems raw strings address, so there wasn’t anything we could simply copy over after the fact.

Note that the considerations here are different from CBOR itself, which needs to be minimal as it is intended to provide interchange for constrained systems; EDN is for capable systems (it is easy to do partial implementations for debugging output of systems between there on the spectrum; just don’t send rawstrings).

> Likewise, the whole tag 999 functionality could be left out and defined elsewhere if you wanted more simplicity. It's not at all obvious that having a CBOR document with these "unknown EDN" tags is useful.

Whether that is obvious depends a lot on the perspective.
EDN is used in quite different workflows, which may employ multiple processors; being able to run these workflows through processors that not all implement all the application-extensions needed provides significant deployment benefits.

> But adding one new array parameter to that tag (which can be described in a paragraph) that allows recovering the original EDN from such a document is "too complex". You certainly have an "interesting" way of calculating complexity.

The parameter is not the problem.
The problem is that by removing the level of abstraction provided by *not* having it you suddenly entangle all application-extensions in that complexity.  
For each extension separately, at a design level, at a usability level, at an implementation level.
It is really hard to argue this point because this is such a severe impact.

> I've noticed that when I have made arguments in favor of simplicity in EDN, those arguments have been dismissed.

Generally, we need to weigh things.
What kind of complexity?
What is the benefit?
Arriving at decision that includes arguments in both directions the decision could take is not always easy.
It doesn’t mean that the arguments that don’t win are “dismissed”.
(It may seem that way because typically we have already discussed many arguments and have already weighed them.)
Remember that we are *not* designing this just for the wire, but for humans to use.

> You are going to have to come up with a much more cohesive argument than that to convince me.

Thank you for this advice.

Grüße, Carsten