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

[Carsten Bormann <[e-mail]>]

>> When an application uses a dCBOR library to encode a -4.0, the CBOR generic data model will see a -4, which is shown as -4 in diagnostic notation and as 0x23 in the encoded data item.
> 
> For a "normal" developer (I think I am one), it is not very obvious how Appendix A can be normative if a compliant DN *parser* implementation may also encode -4.0 as 0x23, while the Appendix' 0xf90c400 is flagged as an invalid data item by decoders.

If a “normal” developer for you is somebody who doesn’t try to understand the terminology, then it’s hard to help.

It may be somewhat surprising use of terminology, but CBOR diagnostic notation is intended as a *diagnostic notation*.
It represents fairly exactly what is/will be in the CBOR encoded data item.

So you can write things like {“z”: 1, “a”: 2}, which aren’t going to be deterministic encoding.  And if your application has rules like “no floating point representation of integral numbers”, you can write something that violates that, too.

Of course, you can combine a CBOR diagnostic notation processor (parser + something that operates on the resulting parse tree) that reprocesses the parse tree based on some application rules, which appears what you want to do.

It is just very confusing to call this a “CBOR diagnostic notation parser”, because it not only parses, but also processes based on some application rules.  You may want to condense these application rules into a “profile” to be able to share such a processor between applications, and that is what I think dCBOR is about.

>> You can write an application that takes CBOR diagnostic notation for -4.0, ingests this to a CBOR generic data model, applies dCBOR rules to that, and then encodes it using CBOR deterministic encoding rules.  The diagnostic notation for the latter will show -4, not -4.0.
> 
> For the use-cases I'm thinking of, data models are a part of applications.  Application developers should be able to focus on how data models can be expressed in terms of available core data types (*), where CBOR gives you a pretty decent selection. Serialization issues should be invisible to the extent possible.

Of course you can do an application library that does just that.
You just need to keep in mind that this incorporates some CBOR processing plus some translation from an application data model to how your profiles likes to represent that in the CBOR generic data model.

Grüße, Carsten