[Cbor] Re: draft-ietf-cbor-serialization update

[Anders Rundgren <[e-mail]>]

On 2025-12-05 23:47, Vadim Goncharov wrote:
> On Fri, 5 Dec 2025 13:25:59 -0800
> Laurence Lundblade <[e-mail]> wrote:
> 
>> Here’s an update for draft-left-cbor-serialization [01]. The work remaining
>> is tracked in GitHub issues [issues].
>>
>> — The section on CDDL operators for serialization types is filled in. IANA
>> section too. This also captures the scope issues that Ken brought up (will
>> credit Ken in next revision; missed it for this one)
>>
>> — An appendix on byte-string wrapping is added to capture much of what we
>> clarified about them on the mailing list. It is not normative, so it is in
>> an appendix to keep the normative shortest and clearest
>>
>> — The deterministic encoding of tag 1, epoch dates, is clarified; thank you
>> Wolf and Carsten for comments
>>
>> — Add an appendix on checking decoders; thanks Rohan
>>
>> — Substantial clarification of NaN appendix; the objective is to capture
>> quite a lot of the last few years of discussion; thanks Anders for reviewing
> 
> Curious why "The original intent	
> 	   was for vendor-specific diagnostic information explaining why a
> 	   computation failed"
> 
> sentence was removed? Also, what about NaN bstr tag?

AFAIK, non-trivial NaNs depend on FP hardware, OS, and are not standardized.

Returning a non-trivial NaN as a result of a failed FP operation is therefore not very attractive for software platforms.

One could imagine math libraries providing additional information.  However, the established methods either return a custom error code or throw an equally custom exception.

There are also thorny threading issues for maintaining additional information.


Unfortunately, decoders MUST still recognize non-trivial NaNs and do something with them.  In the CBOR::Core cross-platform specification, this action is standardized, including an option to support 1+52 bit non-trivial NaNs at the application level (without needing any additional object or special serialization methods).

Anders

> 
>> — Add paragraph that says map sorting for determinism is NOT for the
>> application layer; thanks Vadim and Carsten
>>
>> LL
>>
>> [01] https://www.ietf.org/archive/id/draft-ietf-cbor-serialization-01.html
>> [issues] https://github.com/cbor-wg/draft-ietf-cbor-serialization/issues
> 
>