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

[Vadim Goncharov <[e-mail]>]

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
(which isn't explainable why it is used at all in 2020's for new RFCs instead
of CBOR, but that's another topic). 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