CRI vs array literal serialization

[chrysn]

I think that when we switched over to using CRIs everywhere (and decided that CRIs are not arrays but byte strings for CBOR sequences), we lost the ability to distinguish between CRIs and byte literals. (And similarly lost null as a possible literal value when picking the properties literal model).

Fixing this is probably not immediately practical; I think there was something in the pre-packed dictionary encoding.

We'll come back to the serialization anyway, and when we do we can have a closer look.

[chrysn]

Small update during cleanups: The mitigation we had was tag TBD6 to distinguish dictionary references from numeric literals. That is being removed as it doesn't do anything since we switched to Packed; we may need to reintroduce something like depending on how the binary format develops.

[chrysn]

The current literal = bool / int / float / time / bytes / text rule allows only a precise (very small) set of tags, rather than generic tagged values.

@cabo, can we put a #6 in there to indicate that there can be arbitrary literals, or would that be bad practice in terms of CDDL? (I suppose none of that matters to the topic of packed CBOR, as the CDDL applies is matched to the unpacked form, or do we need to pull the packing in?)

Over all, we might consider just splitting the link serialization into, say, [2, relation-type, link-target, ?[*element]] and [22, relation-type, literal-target] and thus have the whole thing cleared up in advance.

[cabo]

Well, the old cddl tool just crashes when you do that :-)
cddlc accepts this, but then I haven't completed validator/generator for that yet.
I do think #6 (or #6(any)) is valid RFC 8610.
Now also cabo/cddlc#1

[chrysn]

We've resolved since that CRIs are typically arrays (and, once core-wg/href#62 is through, trivial to skip). Still needs text, but should be easier.