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

On 2023-05-05 19:29, Laurence Lundblade wrote:
> 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).

According to Carsten, Appendix A is normative.

> 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 <anders.rundgren.net@gmail.com> 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
>> CBOR@ietf.org
>> https://www.ietf.org/mailman/listinfo/cbor
> 