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

[Carsten Bormann <[e-mail]>]

On 2024-08-21, at 12:44, Anders Rundgren <[e-mail]> wrote:
> 
> 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

The point of identifying your work as an application profile is that we know a few things about application profiles now and can look at your work based on that knowledge.

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

There is no limitation on who can develop a CDE application profile and where.
The important thing here is recognizing that you are doing that and make use of the above mentioned knowledge.

>>> 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.

Good.

>>> 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.

Optional = a set of related, but separate application profiles (which you can also think as an application profile with options).

>> 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.

That may very well be, but I still think that paragraph applies here.

> 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.

That is a widely implemented restriction, so I think this is a good choice.

>>> 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" :)

Ah.  Certainly adding direct support (i.e., outside of other libraries that already need it) for CBOR to JavaScript would make a lot of sense.
BTW, I don’t think adding a ton of booleans to a constructor is a great way to handle different application requirements here (and describing the normal, non-CDE case by the “marketing” word “lenient” also doesn’t help).

Grüße, Carsten