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

[Anders Rundgren <[e-mail]>]

A diagnostic notation parser/decoder would generate 0x23 for -4.0.

On Fri, May 5, 2023, 09:43 Carsten Bormann <[e-mail]> wrote:

> On 2023-05-05, at 09:27, Anders Rundgren <[e-mail]>
> wrote:
> >
> > 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
>
> I think that for any application, you can find things that you can type
> into cbor.me that this application will reject.
>
> > Still both solutions claim to be RFC compliant.
>
> The RFC does not cover applications.  Not encoding integral floating point
> numbers is, from a CBOR point of view, an application rule.
>
> > 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?
>
> Now you are starting to make thinly vailed threats.
> I will not respond to those.
>
> I have been quite receptive for picking up the application rules in
> draft-mcnally-deterministic-cbor as a CBOR work item.
> You just need to stop thinking of them as changing CBOR.
>
> > 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.
>
> The point here is “an interoperability profile”.
> You could define many, and defining one for fintech etc. is fine — it just
> isn’t a “CBOR interoperability profile”, but a “how is our specific set of
> applications going to use CBOR” profile.
>
> Grüße, Carsten
>
>