NaN appendix

[laurencelundblade]

It takes week or so to implement basic CBOR integer and float encoding. I’m not as smart as some here, but I get by… It took me many many months to figure out NaN payloads. I’ve put what I learned in a NaN Appendix to the CDE draft to save others these months.

It’s a fairly long addition, but it seems worthwhile to me to cover the details explicitly. It’s an appendix, not the main document, which signals to the reader that they don’t have to read it.

It makes a recommendation that protocol designers not use NaN payloads because there are better ways to accomplish the same.

[cabo]

Thanks! I think the most valuable part here is the table at the end.
The explanation probably should first explain that CBOR supports IEEE 754, what a NaN is, that a NaN always has a payload, and which payload values aren't available because they would mean something different than a NaN. A quick discussion of the quiet/signaling bit, the fact that IEEE 754 doesn't define it, but there is a de facto standard needs to follow, and then we can introduce the "basic" NaN with sign 0, quiet bit 1, all other payload bits zero. The reason why some applications are not using foo = float / null or foo = float / payload where payload can be anything but float. Then a quick discussion of implementation considerations for preferred serialization, including the weirdness that two NaNs do not compare equal in most platforms, even if they are equal wrt to their payloads.

I'm not sure this shouldn't be a separate draft, to which CDE could refer for information.
It's night here already, but I could turn your input and the above outline into a draft about NaN and CBOR.

[cabo]

https://mailarchive.ietf.org/arch/msg/cbor/KA7ma_UIESnM11SODvmoium9Uqc

[cabo]

Now became part of https://datatracker.ietf.org/doc/draft-bormann-cbor-numbers/
Still needs to be referenced properly; ran out of time.