[Cbor] Re: Rebooting the naming discussion (Re: EDN file extension (Re: registrations before WGLC Re: I-D Action: draft-ietf-cbor-edn-literals-23.txt))

[Carsten Bormann <[e-mail]>]

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

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

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.