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. 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.
/js
On Fri, Feb 19, 2021 at 06:24:02PM +0100, Carsten Bormann wrote:
> On 2021-02-19, at 17:55, Juergen Schoenwaelder
> <j.schoenwael...@jacobs-university.de> wrote:
> >
> > Hi,
> >
> > can I safely replace
> >
> > leaf foo {
> > type int8 { range "0..100"; };
> > }
> >
> > with
> >
> > leaf foo {
> > type uint8 { range "0..100"; };
> > }
> >
> > or with
> >
> > leaf foo {
> > type int32 { range "0..100"; };
> > }
> >
> > or are these a non-backwards compatible changes?
>
> I don’t have an answer to that, but would like to point you to the table at
> the top of page 14 in draft-ietf-core-comi-11.txt [1], which would make the
> first replacement a non-backwards compatible change in the way we build URIs
> from that.
>
> [1]: https://tools.ietf.org/html/draft-ietf-core-comi-11#page-14
>
> > Note that the value
> > set is always the same, however the underlying base type changes. Did
> > we ever define type equivalence?
>
> The way unions are handled in YANG gives me the impression that as long as
> the sets of XML representations generated by the two types are the same, they
> are equivalent.
>
> Grüße, Carsten
>
--
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
