[Cbor] Re: Soliciting unresolved points around dCBOR

[Anders Rundgren <[e-mail]>]

On 2024-06-17 15:39, Christian Amsüss wrote:
> On Mon, Jun 17, 2024 at 02:48:34PM +0200, Anders Rundgren wrote:
>> To get any further, the dCBOR advocates should provide a simple
>> example showing a Gordian-like operation that fails using CDE "as is".
> 
> That may be a useful exercise indeed.
> 
> To my understanding, the goal of using deterministic CBOR encodings in
> the first place is to ensure that consumers can ingest Gordian data,
> store them in their native format by value, and re-encode Gordian to get
> bit-identical data for cryptographic purposes.
> 
> (Were there not the aspect of independent storage, we wouldn't need even
> deterministic encoding, but could just always reuse the original
> encoding for verification.)
> 
> Numeric reduction comes into play when different parties use different
> data types internally. No matter whether it is a database with a u64
> column or a database with a f32 column, if both receive the array [1, 1,
> 2, 3, 5], store it and re-serialize, they wind up with the same data.
> This is what I understand the desired benefit of numeric reduction to
> be.

Thanx! Now I finally understand why I never figured out the deeper intent with numeric reduction :)
Storing f64s in u64 fields or coercing i64s into f64 fields is not your average text book example.

If you separate ints and floats and store them in a appropriate fields, you should be able to recreate the proper CBOR binary regardless if you use dCBOR or CDE.

Anders


> 
> Now I still do not agree with the design of such a system: Since by
> design the semantics of array doesn't include typing information
> (otherwise the application could tell the serializer whether it's floats
> or ints), the collaboration of the u64 and the f32 tool will work until
> it fails when a value is produced that is not understood by one of them
> (at which point that party can't ingest the data any more). I'd prefer
> to have arrays (or other fields) with clear semantics that fail on
> general mismatch and then are guaranteed to succeed at runtime.
> 
> But to the best of my understanding, such a design is what (correctly,
> albeit on to me undesirable premises) motivates numeric reduction.
> 
> BR
> c (once more, chair hat off)
>