[Cbor] Re: Dealing with -0.0, NaN, and Infinity

[Anders Rundgren <[e-mail]>]

On 2024-08-21 11:59, Carsten Bormann wrote:
> On 2024-08-21, at 11:42, Anders Rundgren <[e-mail]> wrote:
>>
>> When trying to define a subset of CBOR CDE suitable as a JSON replacement
> 
> ➔ “a CDE application profile”  (fixed that for you)

Right but since the proposal is an API, there is no apparent need for a separate application profile:
https://cyberphone.github.io/CBOR.js/doc/#main.wrappers

In addition, given the lukewarm interest in this project and its objectives, where would such a profile be developed?

> 
>> Although -0.0, NaN, and Infinity probably have very limited relevance in the intended target market, they must still be dealt with in some way.  The easy way is of course to just ban them during decoding.
> 
> Which an application profile can do in its set of exclusions.

Sure.


>> FWIW, these are my current suggestions:
>>
>> Following IEEE 754 rules it seems that -0.0 does not interfere with normal operations including comparisons; it is still treated as 0.0. So it is currently supported "as is".
> 
> (The current text in CDE does not address decode-time reductions, as they don’t make sense for deterministic encoding — that must necessarily round-trip, so all reductions are encode-time.)

In this particular case there is no reduction.  -0.0 is supported as specified by CDE.


>> However, since mathematical operations using NaN and Infinity are somewhat less nice, and typically indicate that something is fundamentally wrong, their support is currently made optional: https://cyberphone.github.io/CBOR.js/doc/#decoder.cbor.initextended
> 
> I don’t know what “optional” means.

You probably did not look into the supplied link.


> Do you mean:
> 
> https://www.ietf.org/archive/id/draft-ietf-cbor-cde-05.html#appendix-A-7


Probably not.  For platform-wide solutions, run-time, per application options, is the only realistic way dealing with profiling of any kind.

If you take a peek into https://cyberphone.github.io/CBOR.js/doc/#decoder.cbor.initextended you will find other options that may be needed.  You'll find then in https://cbor.me as well :)


>> NaN with payloads are always rejected.  It is still a "strict subset" :)
> 
> All NaNs have payloads.
> I think you are talking about payloads that are non-zero.
> You should probably also exclude negative NaNs, then.

Yeah, the proposed API and associated encoding scheme only supports a single NaN variant. 0xfe00 to be more precise.

> 
>> Related: since the JavaScript "JSON" object never became compatible with Open API number requirements, this became a core priority for "CBOR": https://cyberphone.github.io/CBOR.js/doc/#cbor.int.getint64
> 
> With a (presumably model-guided) pull-parser it is of course much easier to deal with the JavaScript number system.  I don’t get the question here, though.

There is no question, it just emphasizes how an ES "CBOR" object could be a better mousetrap than the current ES "JSON" object.  It is called "marketing" :)

Anders

> 
> Grüße, Carsten
>