We had some past 2022 discussions on using a simple CBOR uint timestamp value (in seconds) in the constrained Voucher. The conclusion of this discussion was that such timestamp needed to be in a new field, not in "created-on", because that field is already defined by YANG/YANG-cbor as a date-time string. Most of the discussion was then about how it could be modeled in YANG such that consistent translations between string format and uint/float format can be done. But, that's complex as it turns out.
Sorry to bring this topic up again! The new idea here is to just define an additional field in the Voucher, that allows encoding a CBOR timestamp per RFC 9581 format. This timestamp could be nicely used by the IoT device as a "floor" for its internal clock i.e. it knows that time is at least greater than this timestamp. This can be easily added into the CBOR voucher. And we avoid the YANG redefinition problem or multiple-encodings problem. If we would like to correctly represent this in YANG as well: I learnt from the 2022 discussion that YANG allows easy definition of such format by the "description" field, so we could just add a new field with a description pointing to RFC 9581. No need to define a detailed pattern/structure or so in YANG. If needed I can repost a pointer to this discussion in ANIMA/CoRE. (Question is still what the JSON serialization of the Voucher would contain, since JSON cannot have numbers as map keys. But I'm mainly interested in the CBOR serialization here!) For the CBOR Voucher, one more general idea here is to reserve a space for "any tagged CBOR" as a map where standard CBOR tags plus content can be included. RFC 9581 uses such tag + content. There might be more useful tags defined in the future also. This info can be used by the consumer(s) of the Voucher. Regards Esko IoTconsultancy.nl | Email/Teams: esko.d...@iotconsultancy.nl
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
