UCL -> EDN? | Was: rcd(8) - new service manager daemon

On Wed, 17 Jun 2026 13:01:09 +0100
David Chisnall <[email protected]> wrote:

[...]
> I’d also like a bit of clarity on the future of UCL before it’s adopted more
> in the base system. I wrote some tooling to generate C++ headers from UCL
> schemas that expose typed UCL data structures a while ago, but the code in
> UCL did not inspire confidence. There were a number of security
> vulnerabilities found around then and there were a number of issues, the
> ones I remember were:
> 
>  - It supports SI suffixes, but uses a b suffix for the binary ones not the
> standard i.
>  - It doesn’t support things like times or durations as first-class types.
>  - Similarly, paths and URLs are just strings.
>  - The grammar does not have a formal definition.
>  - There is no test suite independent of the implementation.
> 
> The attempts at interoperable parsers for the format have failed due to the
> last two. It’s possible to fall back to using JSON for interoperability, but
> JSON requires more high-level types to be encoded as strings and that just
> pushes the interoperability problem elsewhere. In contrast, TOML, which
> systemd uses, has multiple interoperable implementations. Apple’s PKL has
> first-class support for durations and bindings to several languages. UCL
> doesn’t seem to be more widely adopted than when we discussed it almost 15
> years ago and the one implementation is a big pile of C that is optimised
> for parsing performance, not security (or readability).

If an alternatives like JSON or YAML are considered, then I must tell about
CBOR. Concise Binary Object Representation, RFC 8949, is more than just
RFC, it's STD 94. In two words, it is "binary JSON with tags", which differs
it from most other "binary jsons" for extensibility - tags are just
numbers and usually mean data type, but sometimes are used for extension of
the format itself. FreeBSD has CBOR library (-lprivatecbor) for several major
branches now. One can see tags already registered at [1], amongst them are
tags for URLs, time, duration, IP addresses, etc.

What's relevant here in context is that CBOR has so called Diagnostic Notation,
a text version for humans (because main format is binary), and it is superset
of JSON, for example:

  ["foo", h'12 34 ABCD /binary in hex/', true,
   {"time":  0("2013-03-21T20:04:00Z"),
    "place": 103([51.0625, 3.732421875]), /* lat, lon */
    "uri": 32("http://www.example.com")
  }]

Being first an auxiliary thing, it is for last years being standardized as
Extended Diagnostic Notation, adding so called application-oriented extension
literals: a string or even sequence of items has a prefix, with it's own rules
and often even a syntax, which is processed from human-friendly representation
to form which could be much more tedious to write, for example

   dt'1969-07-21T02:56:16Z' corresponds to  -14159024 (it's a Unix time)
   ip'192.0.2.42' 	                to  h'c000022a' /* binary string */
   IP'192.0.2.0/24' 	                to  52([24,h'c00002'])

Raw strings (no escaping) are provided in fashion simlar to Markdown, and
there are other features making it much more suitable for configurations files
than JSON. Document is largely settled and is at WGLC stage, with debates
going on some minor things and future directions, including bikeshed on name:
it is "CDN" in -26 draft as it was pointed out the format could be used also
without CBOR, with e.g. YAML or others.

So, as it will be IETF standard, it is guaranteed it will have many
implementations, and as superset of JSON, it will be relatively
straightforward to convert UCL files, if chosen. I had a quick AI
implementation of one of earlier versions of document to see if it is
implementable solely by tools from FreeBSD base system (lex/yacc/libcbor), it
did.

It is not even late to change some things in it, so I, as participant of
IETF CBOR Working Group, will be glad to pass any feedback (current version is
at [2]) back to WG mail list!

[1] https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml
[2] https://www.ietf.org/archive/id/draft-ietf-cbor-edn-literals-26.html

-- 
WBR, @nuclight