Michael Richardson <[email protected]> wrote: > 2. The other thing we ran into was that the CBOR implementation I'm using, when given a > DateTime object naturally produces a RFC 8949 Section 3.4.2 compliant "tag 1" marked Epoch-Based > Date/Time. And demarshalls this. So I don't really notice.
> But, draft-ietf-core-yang-cbor doesn't say much about
"yang:date-and-time".
> The only reference seems to be at:
>
https://www.ietf.org/archive/id/draft-ietf-core-yang-cbor-20.html#name-the-container-and-other-nod
> where date-and-time is shown as part of a container object.
> The Content is defined to be string date pattern.
> Section 6, where I might expect to see info about encoding dates:
>
https://www.ietf.org/archive/id/draft-ietf-core-yang-cbor-20.html#name-representing-yang-data-type
> is silent about date and time formats.
> https://github.com/core-wg/yang-cbor/issues/144
lemikev wrote in the issue:
l> I'm just not sure this issue is in scope for this draft.
l> "draft-ietf-core-yang-cbor" define the encoding of the built-In types
l> listed in
l> [https://datatracker.ietf.org/doc/html/rfc7950#section-4.2.4](url), not
l> every typedef.
l> [RFC 6021] defines date-and-time as a string with a specific pattern, this
l> is the way these data nodes should be encoded.
l> A clean way to support Epoch-Based Date/Time is to update the
l> ietf-yang-types YANG module to add this option.
l> typedef date-and-time {
l> union {
l> type string {
l> pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
l> + '(Z|[\+\-]\d{2}:\d{2})';
l> }
l> type unit64;
l> }
l>
l> An alternate option is to use a different typedef in new IoT specific YANG
modules.
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
