On Fri, Feb 19, 2021 at 10:32:34PM +0100, Carsten Bormann wrote:
>
>
> > On 2021-02-19, at 19:18, Juergen Schoenwaelder
> > <j.schoenwael...@jacobs-university.de> wrote:
> >
> > I think the CBOR encoding picks different tags depending on the
> > signedness of the base type and this is why things are not that simple
> > anymore.
>
> (This is not the CBOR encoding, but the COMI encoding of keys in URIs.)
OK. The CBOR document indeed says:
6.1. The unsigned integer Types
Leafs of type uint8, uint16, uint32 and uint64 MUST be encoded using
a CBOR unsigned integer data item (major type 0).
6.2. The integer Types
Leafs of type int8, int16, int32 and int64 MUST be encoded using
either CBOR unsigned integer (major type 0) or CBOR negative integer
(major type 1), depending on the actual value.
This means the type 'int8 { range 0..10; }' leads to the same
encodings as the type 'uint8 { range 0..10; }'.
> > For the XML and JSON encodings, all definitions lead to the
> > same on-the-wire representation, hence the difference is more an
> > implementation detail. I have no clue what the gnmi people do. The
> > more diverse encodings we add, the more complex things get.
>
> Well, if the equivalence expectation that I was trying to describe actually
> is ingrained, then whoever designs an encoding (COMI for its URI encoding
> included) needs to respect it. That would be important to know.
>
Exactly. I think we never defined this. And of course, this can get
even more fun if you consider string based encodings. The type
type string { pattern "1|2|3|4"; }
yields the same _XML encoded_ value space as
type int32 { range "1..4"; }
but as far as I recall the JSON/CBOR encodings will treat these two
differently. So yes, ideally the YANG language would have clear rules
what YANG's type equivalences are.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
