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

[Laurence Lundblade <[e-mail]>]

Us humans can indicate the value in question in many ways, “negative four”, “X subtract XIV" (a stretch since Roman’s didn’t have negative numbers), “-4” or “-4.0”.  My understanding is that diagnostic notation is just another way to express a value and does NOT require any particular serialization. There’s not any normative requirement that diagnostic notation encode / decode in any particular way (and that is OK).

It’s up to individual applications to say whether a particular data item is to be encoded as a float or an integer, just like a particular application says whether to use an array or a map, a bstr or a tstr.

DCBOR changes this by removing this flexibility. It always requires “negative four”, “-4.000000000” or how ever us humans denote it to be encoded as a preferred encoded CBOR integer 0x23. This is a good thing and if you want that behavior use DCBOR. DCBOR will not work for everyone though, so we can’t make it the rule. Some will still want to specify a particular value is always encoded as a float.

If an application says that an item must be encoded as an integer, then there is the question of 0x23 (preferred) or 0x38 0x03 (not preferred) or a few others. In practice there’s no profile needed here as every widely used encoder will do preferred and also be able to decode non-preferred, but if you want to be super tight in a spec, you should say only preferred encoding. DCCBOR covers this too.

To summarize:
 - int vs float encoding of a number is an application layer decision
 - Serialization of CBOR int type 0 and 1 might be a profile issue for some, but isn’t really in practice
 - DCBOR gives specific behavior for the two above for those that want it

LL


To give an example from QCBOR. An application calls QCBOREncode_AddInt64() if it wants CBOR integer encoding or QCBOREncode_AddDouble() if it wants float encoding. QCBOREncode_AddDouble() will never produce CBOR integer encoding. There will probably be a new method, QCBOREncode_AddDCBORNumDouble() that will implement the behavior of outputting -4.0000 as a CBOR  integer.

> On May 5, 2023, at 12:27 AM, 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
> 
> 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
> 
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor