DRISL: underspecified handling of NaN

[dignifiedquire]

Floats from the DRISL spec

Floating-point numbers MUST always be encoded using the longest variant; completely avoiding floating-point numbers is RECOMMENDED to minimize interoperability and tooling issues.

• Valid encoding according to CBORc: f97e00
• Invalid encoding according to CBORc: fa7fc00000 (not in shortest form)

It is unclear which version should be used in DRISL given this

[bumblefudge]

for reference, dCBOR disallows ANY NaN other than f97e00-- there are LOTS of possible NaNs, and they get used to smuggle errors out of kernel or some such esoteric machine-assembly purpose.

i am fine following suit, but wanted to hear from implementers, thanks for the input!

[makew0rld]

Definitely agree NaNs should be banned.

This issue actually raises an important point however. DAG-CBOR bans "IEEE 754 special values NaN, Infinity and -Infinity". I implemented dasl-testing and go-dasl with assumption DRISL would continue with this, but actually looking at the specs, this is not stated anywhere.

IMO, DRISL should not refer to CBOR/C and just state all its requirements (including this one) up front in one document.