DRISL: undefined

[makew0rld]

(This issue was extracted from hyphacoop/dasl-testing#10)

A potential spec change for DRISL would be to mandate that decoders convert CBOR's undefined to their programming language's representation of null.

For

• Most decoders in the ecosystem already do this, across languages like JS and Go (ref)
• It's required to decode historical objects (ref)
• Decoders outside of the ecosystem (general CBOR) do this, not just in dag-cbor (ref)

Against

• It makes decoders less strict
• It makes decoding and encoding asymmetric (since emitting undefined is banned)
• It's not in the original dag-cbor spec

[bumblefudge]

easy for me to say, and call me King Solomon, but i think this legacy-safe decoding asymmetry is best specified as an OPTIONAL behavior in the DRISL spec, and ideally implemented as a CONFIGURABLE behavior in general-purpose libraries, because some people might prefer an error upon decoding unspecified and some people might need to support legacy data. i know everyone hates variability but for me the top priority is getting the maximum number of maintained DRISL libraries in the maximum number of languages, even if some of them barf on legacy DAG-CBOR 😺

[bumblefudge]

(and i'm fine with barfing being the default/baseline requiring extra work to sidestep)

[vmx]

I would forbid undefined. null should be enough. Keep things simple (and compatible to DAG-CBOR :).

[bumblefudge]

the internet-draft says this:

5. Simple values in CBOR and CBOR/c include the ranges 0-23 and
   32-255, all but three of which are invalid in CBOR/c-42; however,
   the capability to refer to boolean values (i.e. true and false)
   and null as major-type 7 simple values MUST be supported to
   guarantee interoperability with CBOR tooling generally.

But yeah, I'll put this in the DRISL spec too, which should be the more human-readable/scannable overview of the more precise RFC anyways.

[makew0rld]

IMO this is not complete because the spec does not mention decoder behaviour, only encoder.

[bumblefudge]

Decoders outside of the ecosystem (general CBOR) do this, not just in dag-cbor (hyphacoop/dasl-testing#4 (comment))

I take it from vmx's comment that DAG-CBOR decoders reject as invalid an object containing any undefined values, right?

Leaving decoding ambiguous/unspecified here has the advantage of breaking neither people using dag-cbor libraries NOR people using atproto-native libraries that error on the side of Postel's Law forgiveness of CBOR undefined. i'm personally leaning (like robin) towards leaving decoder behavior, well, undefined since undefined would only come up in cases of encoder error or legacy data, and the "SHOULD" feels kind of implicit...

but I also reopened the issue to make sure I'm not missing anything and no one has a good case for being more prescriptive on how decoders handle such data.

[makew0rld]

DAG-CBOR decoders reject as invalid an object containing any undefined values, right?

Not in practice, only in theory. See my first two bullet points.

I would rather decoder behaviour be explicitly specified one way or another, otherwise it will be impossible for implementers to know what to do.