Re: [Cbor] Implementing float->int numeric reduction

["lgl island-resort.com" <[e-mail]>]

> On Aug 16, 2023, at 3:19 PM, Wolf McNally <[e-mail]> wrote:
> 
> Anders,
> 
>> On Aug 16, 2023, at 2:38 PM, Anders Rundgren <[e-mail]> wrote:
>> 
>> On 2023-08-16 22:21, Wolf McNally wrote:
>>> LL,
>>> I absolutely agree with your approach, and I appreciate the rigor you’re bringing to the conversation. This is exemplary of the sort of support we’d hoped to receive from the community. Thank you.
>> 
>> Wolf and Laurence,
>> 
>> Pardon me for not joining the choir.  Multiple deterministic encoding schemes will likely only confuse developers and the market.
>> 
>> That is, this may very well *reduce* the CBOR "Value Proposition".
> 
> I think you’re making a valid point. Should the community wish to go with a single official deterministic encoding  scheme for something like a CBOR 2025 version, I’d be happy to nominate dCBOR for that.

When I think if the millions of coders that will put CBOR to use :-), most will not really have any time or patience for the details we are debating now. Their supervisors want work done quickly.

So, yes, I think we should be aiming for one official deterministic encoding standard. I think that will serve CBOR adoption best.

It will probably be a compromise for some of us. Won’t be possible for everyone to get what they want.

dCBOR is pretty much what I’d pick. I would call it dCBOR, not CBOR 2025 though. It is an option for people that need determinism. Determinism is only for a minority of use cases. For example, the payload of a COSE_Sign does not require determinism. I also think we should expect people to specify/require determinism in a lot of places where it is not needed out of FUD, but that’s OK.

I don’t think the numeric reduction of float->int is very costly or burdensome to implement widely. I think it nicely extends the usefulness of a single deterministic standard.

LL