Re: [Cbor] Reminder and call for agenda: CBOR WG Virtual Meeting on 2023-05-31

[Anders Rundgren <[e-mail]>]

Thanx Emile,
I have also come up with similar wishes. However, that would not be CBOR.
"CBOR everywhere" is only about establishing (through some kind of standards document), what I consider industry best practices regarding serialization.

Deterministic encoding + bidirectional diagnostic notation make CBOR a serious contender for most enterprise applications as well as for more specific applications like Gordian Envelopes and digital wallets.  The latter is BTW now mandated by the EU.

My hands-on experience with deterministic encoding (using Java, C++, and JavaScript), indicates that it comes practically free of cost.   It only gets slightly more complex if provided as an option.

Regarding C/C++: https://mailarchive.ietf.org/arch/msg/cbor/1CQvLGqkvpkBvj2uYxnrZvLN96k/

Cheers,
Anders


On 2023-05-26 23:38, Emile Cormier wrote:
> On Fri, May 26, 2023 at 1:35 AM Anders Rundgren <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Based on recent postings on the mailing list, the CBOR WG seems to rather be drifting towards the opposite goal; creating sector- or/and application-specific encoding profiles like dCBOR, "fintech", or breaking away from the crippling past (C/C++). Since I have no interests in such ventures, I won't attend the meeting.
> 
> 
> I'm curious to know how C/C++ has anything to do with CBOR and the direction you think it's going. Except perhaps for a few example code snippets, CBOR seems pretty language-agnostic to me.
> 
> While implementing C++ encoders for "important" CBOR tags, I found that some of them were fighting against the C++ way of doing things. In particular, the extended time tags want base 10 exponents that are multiples of 3, whereas C++ std::chrono allows any arbitrary ratio for its time unit. Another one is CBOR bignums that are not signed magnitude like how most C++ bignum libraries are implemented.
> 
> I've come to accept that CBOR cannot please everyone. It has to contend with competing pressures: encoding size vs ease of decoding, determinism vs ease decoding, the ease in which competing programming languages can generate/consume CBOR, etc.
> 
> As much as I've grown attached to CBOR, I would like to see a binary serialization format that sits somewhere between CBOR and Protocol Buffers, where bytes could be directly copied to the programming language variables (as much as possible), yet there is no fixed schema requiring an IDL. This would be my wish list for such a hypothetical format:
> 
> - Little endian!
> - Two's complement signed integers instead of separate types for positive/negative. Rules provided for determinism if an application requires it (e.g. signed vs unsigned positive integers).
> - Tags are purely for semantics and don't encode a portion of the data item (I'm looking at you, positive/negative bignum!). It should be possible to strip away the tag while transcoding to JSON, with the receiver being able to reconstitute the item if they know what type to expect.
> - Tags are only for items that have a general purpose and are not application/protocol/vendor-specific
> 
> Cheers,
> Emile Cormier