Re: [Cbor] (d)CBOR session at IETF 118

Anders,

dCBOR is not stuck: our current I-D doesn’t expire until February and we are taking time to ensure there is no further constructive feedback or necessary refinements to the draft as we decide how to move forward.

Vague criticisms like “deviates from the CDE core” without stating exactly how or exactly why it’s relevant aren’t helpful, and I don’t feel it necessary to re-litigate the arguments justifying numeric reduction on this list. I do think you understand them, even if you don’t like them. As you know, the IETF only requires *rough* consensus, not *complete* consensus, and I think a number of participants here do see dCBOR’s value, even if it isn’t the right solution to every CBOR problem.

I remind you that the dCBOR draft has already benefitted in a number of ways from feedback from this group, so we have demonstrated that we accept constructive criticism. I have also repeatedly invited you to reach out to me personally so we can directly discuss points that might need revision or clarification, but so far you have not.

And as always, anyone is welcome to submit pull requests to the draft itself:
https://github.com/BlockchainCommons/WIPs-IETF-draft-deterministic-cbor

In the meantime we are developing solutions using dCBOR and it is serving our needs and the needs of our customers well.

~ Wolf

> On Nov 5, 2023, at 1:12 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> CBOR session at IETF 118
> 
> - Brief mention of deterministic encoding profiles
> 
> This topic seems to be stuck for no obvious reason.  How about trying to come to a conclusion if we need two IETF standard profiles or not?
> Personally, I would consider two IETF standard profiles as a failure.  dCBOR is essentially a subset of CDE and subset implementations of standards are very common.  Well, then we have "Numeric Reduction" which is a deviation from the CDE core.
> 
> However, there is nothing in the current dCBOR 05-draft that elaborates on this deviation from CDE.  What is clear is that dCBOR decoding is at odds with CBOR's self-describing nature since an encountered integer may be denoting an integer although it could equally well be a floating point number.  It is true that this ambiguity is already present for integer/bignum but introducing more of that kind requires a good (and agreed upon) rationale.
> 
> Thanx,
> Anders
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor