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

[Rohan Mahy <[e-mail]>]

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
>
> I don't understand the whole goal of this draft. How this is supposed to be
> used?




> 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.

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).

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.

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).

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??

[1] https://github.com/protocolbuffers/protoscope



> (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).

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.

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!").

Thanks,
-rohan


> 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...
>
> > 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
>