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

On 2023-11-05 9:52, Wolf McNally wrote:
> Anders,

Hi Wolf et al,

> 
> 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.

With "stuck" I meant as an IETF-adopted work-item, with the goal creating an IETF standard based on consensus.

Please don't see me as an enemy.  You have put this topic on the IETF table.  Be proud of that!!!
I have never said that "dCBOR doesn't work" because that would obviously be incorrect.

That Carsten created a counter-proposal (CDE) which departs from dCBOR should not be seen as a "defeat" although I'm sure it might be felt like that.
I support Carsten's CDE profile because it is IMO "good enough" for any CBOR based system (be it depending on deterministic encoding or not).

I'm very well aware of the advantages with Numeric Reduction but they are IMO offset by having a COMMON encoding standard.  In your specific use case I believe that a "builder" API could more or less nullify the differences, and potentially even enhance functionality.

Best regards,
Anders

https://refactoring.guru/design-patterns/builder

> 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 <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
> 