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

[Anders Rundgren <[e-mail]>]

https://cbor.me produces CBOR data items like 0xf9c400 that are rejected by applications building on https://www.ietf.org/archive/id/draft-mcnally-deterministic-cbor-01.html#name-reduction-of-floating-point

Still both solutions claim to be RFC compliant.

So the question is simply: is a CBOR interoperability profile a suitable work item for the CBOR WG, or should it preferably be taken to OASIS, ETSI, or the W3C?

The target for an interoperability profile are the 80-90% of all developers working with enterprise systems as well as open standards for banking and similar.

thanx,
Anders

On 2023-05-05 8:
52, Carsten Bormann wrote:
>> 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
> 
>