Re: [Cbor] Status of Appendix A in RFC 8949

[Carsten Bormann <[e-mail]>]

> In
> https://www.rfc-editor.org/rfc/rfc8949.html#name-examples-of-encoded-cbor-da
> there is a table with some example values given in Diagnostic Notation and how they are to be encoded in CBOR.
> 
> A problem with this is that the appendix is not marked as "non-normative" although it it is (apparently…)

It is not marked as informative because it is normative.
As far as examples can be normative, of course.
But if your CBOR diagnostic notation implementation does not handle these examples as given, it is not a CBOR diagnostic notation implementation.

> based on Rule 2 in section 4.2.2.

CBOR diagnostic notation is a readable representation for what is actually being interchanged.
If your  are changing a 4.0 to a 4, this becomes visible at this level.

> Why is that a problem? Well, in
> https://www.ietf.org/archive/id/draft-mcnally-deterministic-cbor-01.html#name-reduction-of-floating-point
> Rule 1 is (apparently...) applied, which means that "-4.0" would return 0x23 rather than 0xf9c400 proposed in Appendix A as well as by Carsten's CBOR playground (https://cbor.me/)

Again, diagnostic notation for 0x23 is “-4”.
Both “-4” and “-4.0” actually have multiple encodings each, with a defined preferred encoding.

> Taking CBOR to the world of shrink-wrapped software comparable to Open API will undoubtedly require a CBOR interoperability profile.

You keep saying that.

> In such a profile, deterministic encoding is a side effect.

Not at all, as deterministic encoding also does things like determining map ordering, which many applications (and thus their “profiles”) do not need.

Grüße, Carsten