On Tue, Jun 28, 2022 at 1:50 PM Carsten Bormann <[email protected]> wrote:
> On 2022-06-28, at 22:22, Andy Bierman <[email protected]> wrote: > > > > During operation, the optimized encoding is used for any objects with the > > data type. E.g., tag X for date-and-time, tag Y for ipv4-address, tag Z > for ipv6-address. > > The receiver is responsible for converting the special encoding to the > correct format > > for the YANG data type. Storage and exposure of the optimized format > are possible, > > but (perhaps) not required. > > Do I actually know that a yang item “has” that data type (*)? > It actually could “have” multiple of them (and usually has both a base > type and at least one typedef). > Just wondering. > The sender needs some information from the YANG module to implement the draft, but not usually the YANG type names. There are other reasons the server may already be aware of the type names (e.g., xpath:1.0 data type requires special handling). > The alternative would be to trigger on the data, so any string that looks > like 2022-06-28T20:48:15Z would turn into 1(1656449295). That has some > interesting security considerations, though. > > This would require scanning the data being sent and received. IMO the best part of CBOR is that this is never done. Unlike XML and JSON, where the sender must scrub the output to avoid any special characters (and the reverse on the receiver), CBOR uses proper framing so the string content never has to be touched. Grüße, Carsten > Andy > > (*) I.e., name equivalence as opposed to structural equivalence. > Many YANG types are defined via a regexp (pattern)… > >
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
