[Cbor] Re: draft-edn-for-tls (was: Rebooting the naming discussion)

[Rohan Mahy <[e-mail]>]

I already largely replied in the other thread, but briefly.

Wireshark decodes the TLS *PROTOCOL*. A *library* decodes *instances* of a
protocol encoded using TLS Presentation Language definitions. Because the
data types used in TLS PL are a strict subset of those defined in CBOR, a
TLS PL decoder library can trivially generate EDN in debug logs. Nobody
needs to get permission to do this anymore than they need permission to use
printf.

For test vectors, the advantage of EDN over JSON is that it expresses
binary data in a more human friendly format.

Thanks,
-rohan

On Wed, May 20, 2026 at 11:56 PM Vadim Goncharov <[e-mail]>
wrote:

> On Sat, 9 May 2026 09:13:57 +0200
> Rohan Mahy <[e-mail]> wrote:
>
> > Hi Vadim,
> >
> > On Sat, May 9, 2026 at 1:12 AM Vadim Goncharov <[e-mail]>
> > wrote:
> >
> > > On Tue, 5 May 2026 19:54:28 +0200
> > > Carsten Bormann <[e-mail]> wrote:
> > >
> > > > On May 5, 2026, at 19:20, Rohan Mahy <[e-mail]> wrote:
> > > > >
> > > > > Another reason to not restrict EDN to CBOR:
> > > > >
> https://www.ietf.org/archive/id/draft-mahy-cbor-edn-for-tls-00.html
> > >
> > > Is this a EDN-to-TLS converter, or vice
> > > versa? Please explain how it is to be used in tooling - what accepts
> it,
> > > what
> > > produces, etc. Why EDN at all for the alien format, let the dead bury
> > > their dead...
> > >
> > > I don't understand the whole goal of this draft. How this is supposed
> to be
> > > used?
>
> BTW, you still did not show how this is assumed to be used in practice. At
> least e.g. possible shell commands, for, probably not existing in
> implementation yet, but still showing usable interface. Answer to this
> question may reveal insights crucial for discussion below.
>
> > > Examples in EDN describe something in CBOR, not TLS' binary format
> > >
> > Why?  EDN is a diagnostic notation that describes common data types like
> > text strings, byte strings, arrays, and maps; plus tags and simple
> values.
>
> Nope, EDN is *the* diagnostic notation specifically tailored to CBOR and
> it's
> data model. One probably can reuse EDN for some other binary serialization
> which is compatible with CBOR in it's data model, e.g. notorious "CBOR
> 2.0",
> but not for *arbitrary* another binary format. In other words, EDN is not
> an
> Abstract Diagnostic Notation, for which, well, to some degree ASN.1 could
> pretend, as not being tied to particular serialization (even XER emerged).
> ASN.1 is more like to CDDL though.
>
> See, EDN even has features like [_number ] which are too CBOR-ish and
> usually just not exist in other formats. Similarly, other binary formats
> often
> can have quirks which are inexpressible in EDN - you'll have to invent some
> kludges to workaround.
>
> > We can use EDN to add comments to JSON instances. We can use it to
> > represent instance data in YAML (which is particularly nice if your YAML
> > contains tags).
>
> ...except cases when we can't. EDN, JSON and YAML are all intersecting
> sets,
> but not exactly the same set.
>
> > There is currently no standard notation for TLS struct *instances*.
> > Likewise, the defacto way of human-notating Protobuf instances
> (Protoscope
> > [1]) is non-standard and pretty ugly.
> >
> > [1] https://github.com/protocolbuffers/protoscope
> >
> > Certainly there is no harm in generating EDN from a TLS instance or
> > Protobuf instance for humans to read. It is much more readable than hex
> > dumps (and IMO Protoscope).
>
> Yeah, because Google did not have such intent from the beginning, they had
> another goal. They have human notation baked into schema (as if EDN
> combined
> with CDDL, but not quite), so *any* try to do this against their will and
> goal (outside of scope) - will be ugly to some degree, more or less. So
> your
> try to make it less ugly still won't make totally non-ugly, because entire
> Protobuf approach is flawed :-) [well, they have benefits, of course, but
> it
> is just too easy to fall out of scope when you start to get drawbacks]
>
> > What about taking EDN instances for test vectors and using it to generate
> > binary formats other than CBOR?  Surely that is OK too as long as the
> > processor knows to generate the target format. If it is OK to have
> > bazaar-style extensibility which allows all kinds of extensions in EDN,
> why
> > wouldn't it be ok to use EDN to generate other formats??
>
> Because EDN generates CBOR and is currently defined for CBOR only, see
> above.
> What can be OK in practice is if you define *converter* to (and from) other
> binary format, which can e.g. utilize some CBOR tags to help with
> conversion
> and then such tags could be reflected in EDN, may be as extensions. So that
>
> $ cat foo.edn | edn2cbor | cbor2protobuf > file.bin
> $ cat file.bin | tls2cbor | cbor2edn
>
> could succeed.
>
> > > (which isn't explainable why it is used at all in 2020's for new RFCs
> > > instead
> > > of CBOR, but that's another topic).
> >
> > TLS Presentation Language and Protobuf start with what most programmers
> > would casually call schema definitions (Carsten would likely prefer "data
> > definitions"). They define rules about the structure of data like CDDL
> > does, but the binary instances that are generated from TLS PL and
> Protobuf
> > are useless without knowing the structure. However, they are very
> > appropriate where the validation of these structures is essential (ex: as
> > in security protocols and APIs).
>
> This a source of confusion here. They don't start with "schema"
> definitions as
> it would be in "JSON Schema" or "CDDL" sense of word. They do with together
> with serialization. Still ASN.1 as example from the past with it's DER and
> XER
> is more appropriate here. Therefore, they don't have a *single validation
> step*
> as it could be with CDDL or JSON Schema, because without schema you simply
> can't (de)serialize it, and thus part of "validation" is done here as
> simply
> by deserialization process, in which it is just impossible to create "too
> invalid" instance which will need additional validation. The only step
> which
> is left to validate after deserialization is usually about forbidden
> combinations of field values, not about structure. And CDDL/JSON Schema are
> primarily focused on *structure* and don't cope well with those complex
> security checks like "if A is in range 2..10, then B must be in 100..400"
> (so you'll need to hardcode these anyway after CDDL validation step).
>
> > Sadly, the CBOR community is still lacking robust, CDDL-validating CBOR
> > decoders across a range of languages (especially compiled ones) that
> > provide the same level of functionality available off-the-shelf with
> > Protobuf.
>
> Agree here, but partially this is because of lack CBOR "marketing": there
> are
> not too many of us writing tools, compared to e.g. Google PR-ed Protobuf;
> still googling says that e.g. `zcbor` exist which can generate C code from
> CDDL (actually not all supported) in a manner like Protobuf.
>
> And partially this is because CDDL had it's main goal in documentation
> rather
> than production industry needs.
>
> > However, having a standard, human-readable format for communicating
> > instance data for those formats is quite valuable. If you really want
> more
> > CBOR in the world, having other communities already familiar with EDN
> makes
> > it relatively easy to transition to CBOR+CDDL. ("Hey, our test vectors
> are
> > already done!").
>
> Well, but in absolutely the same way you could tell to them "hey, we have
> test
> vectors for you in JSON already done!" and this could be even usable in
> test
> framework in some projects. And probably some projects already do this. But
> nobody tries to standardize this just because the formats are too
> different.
> At least, just think, why for more than two decades nobody yet tried to do
> this? This fact suggests the demand for such thing will be little. Like,
> for
> example, Wireshark already decodes TLS.
>
>
> > > > Nice!
> > > >
> > > > The document’s text does position our diagnostic notation as a CBOR
> > > format,
> > > > which it indeed is. Maybe having CBOR in the docname (file name) and
> in
> > > the
> > > > introductory text doesn’t actually hurt that much? (If you do a
> > > > s/extended/CBOR/g the text still makes a lot of sense!)
> > > >
> > > > (Of course, TLS should never have been called TLS because that
> > > abbreviation
> > > > meant thread-local storage for anyone active in making platforms
> exploit
> > > > multicore CPUs at the time.  That separate meaning doesn’t seem to
> have
> > > hurt
> > > > either, even if it *still* is called “SSL” in a lot of places.)
> > >
> > > In fact TLS should just die, together with all ASN.1 and X.509, but the
> > > latter
> > > will live longer, even in CBOR-based alternative... Still to be
> considered
> > > as
> > > legacy, hope we will be still alive when it's phased out..
> > >
> > > > Grüße, Carsten
> > > >
> > > > PS.: The convention
> > > > # ~~~ tls followed by the struct name
> > > > is quite related to (if less formal than) the mapkey proposal; great
> food
> > > > for thought! BTW, tls<<“structname”, …>> would work without the need
> to
> > > > extract information from comments.
> > >
> > > +100500: comments syntax looks as quite ugly crutch given that we
> > > app-literals.
> > > The first example actually should like like:
> > >
> > > tls-pl<<
> > >   tls-definition`
> > > enum {
> > >   false(0),
> > >   true(1),
> > >   (255)
> > > } Bool;
> > >
> > > enum {
> > >   red(1),
> > >   yellow(2),
> > >   green(3)
> > >   (255)
> > > } Color;
> > >
> > > struct {
> > >   uint16 id;
> > >   uint8[16] nonce;
> > >   Bool active;
> > >   Color traffic_light_color;
> > >   uint32 divisible_by<V>;
> > >   opaque reason;
> > > } FooBar;
> > >   `,
> > > {
> > >   "id": 16798,
> > >   "nonce": h'f6bafb33a535d1fd05bef225d2ac8f35',
> > >   "active": true,
> > >   "traffic_light_color": 3,   # Color green
> > >   "divisible_by": [3, 5, 11],
> > >   "reason": 'server down'
> > > }>>
> > >
> > > for inline definition, and your suggested
> > >
> > > tls-pl<<“structname”, …>>
> > >
> > > when definition was seen earlier. This then would correspond to CBOR
> binary
> > > string which has h'that serialized instance'
> > >
> > > The only thing we should care here at the comment/pragma level is an
> > > "include" for file with struct definitions or something other type of
> > > reference
> > > here (CDDL?). May be also an "unwrap" from h'' to raw binary string,
> but
> > > this
> > > is just a guess which may be wrong depending to answers in first part
> of
> > > message.
> > >
> > > --
> > > WBR, @nuclight
> > >
>
> --
> WBR, @nuclight
>