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

[Anders Rundgren <[e-mail]>]

On 2023-11-05 20:38, Wolf McNally wrote:
> Anders,
> 
>> On Nov 5, 2023, at 10:23 AM, Anders Rundgren <[e-mail]> wrote:
>>
>> On 2023-11-05 18:19, Wolf McNally wrote:
>>> As long as you continue to insist that this is all about *API* and refuse to acknowledge that this is about *determinism* throughout the entire stack, then you’re simply never going to understand our motivations.
>>>
>>
>> Wolf, that's correct.  I don't understand why dCBOR's determinism scheme must span over "the entire stack".  Reading draft-05 didn't make me much wiser either :(
> 
> The purpose of the present draft is not to justify the need for determinism any more than it needs to justify the need for structured data: this is generally accepted among many people for certain applications, and you yourself are one of the authors of the JSON Canonicalization Scheme, an actual RFC. So I should hardly have to justify determinism in general to you, nor should I have to justify determinism at the encoding level.
> 
> https://www.rfc-editor.org/rfc/rfc8785
> 
> Our desire to facilitate determinism across the stack, starting with CBOR at the lowest level, has also been explained numerous times: for applications that require determinism (which is *not* most applications) facilitating it as much as possible at each semantic layer relieves protocol designers and implementers of cognitive burden by enforcing single-encoding-for-single-semantic. Doing that makes it easier to avoid errors in both specification and implementation, and hence facilitates separate agents converging on the same encoding (and hence the same hashes) for the same semantic content.
> 
> You could absolutely make a byte buffer and write out every single byte, one by one, by hand, of a correct CBOR stream, or JSON document, or XML document: but why would you? Now include the requirement that multiple encoders should converge on outputs that produce the same hash. Why *wouldn’t* you facilitate this at every level, and in fact *bake it in* at the lowest levels? dCBOR does so, and all dCBOR is valid CBOR, so it is completely compatible with all CBOR implementations.

Wolf, this was a lot!  However, in what way (modulo the API issue for weakly typed languages), doesn't the above also apply to CDE?


> A little more argumentum ad absurdum: Why would you have a data encoding standard that you’d promote as “deterministic" where the concept of “two” could be expressed by 2, 2.0, or “two”?

According to CDE, integer 2, float 2.0, and string "two" represent distinct CBOR data items.  As long as this convention is adhered to, determinism is achieved.  Bi-directionality comes as a (wanted) side-effect.


> I see you've made an appointment with me for a Zoom meeting on the 16th, so I look forward to discussing this with you further then.

CU!

Anders

> 
> ~ Wolf