Re: [core] YANG-CBOR, Date formats

[Carsten Bormann <[e-mail]>]

> What SHOULD a compliant yang-cbor decoder *do* if it sees a representation
> node (I think that I used the right term), which is encoded using one of the
> standard RFC8949 tag types at:
>  https://www.rfc-editor.org/rfc/rfc8949#name-tagging-of-items

Answer: Croak.

There is a well-defined number of tags that can occur in YANG-CBOR.

Now, with the extension we are discussing, there would be a defined set of tags that have a translation: conceptually, these are translated into the equivalent YANG strings (1(1656449295) ➔ "2022-06-28T20:48:15Z"); in practice, they become the platform types that correspond to the tags.

You could define your own media type and simply specify that this transformation happens (conceptually, again) to turn the representation into the yang-data+cbor media type.

The breakage that could happen is that a generator misses converting a string into concise, or that a consumer breaks with non-concise form in a place that would allow a concise form.  That’s why it probably is a good idea to have something at the schema level — as a YANG extension (preferred) or hidden in the SID file.

                 .oOo.

The underlying problem is that you got what you wished for.

There is no need for YANG to define a security format.
Once it was decided to use YANG anyway, you had the baggage.

Now you are complaining that YANG-CBOR didn’t magically carry that baggage.

I think the learning is a different one:  
Don’t light your kitchen stove with a flame thrower.

Grüße, Carsten