On 23. Feb 2022, at 09:04, Anders Rundgren <[email protected]> wrote: > > Hi Folks, > > IMO, deterministic serialization makes no sense if decoders anyway are more > or less obliged to cope with anything that smells like CBOR.
The wording you use here indicates that you don’t really have a technical point. CBOR is a precisely defined format. We don’t have a “smells like” property; we do have “well-formed”. A generic decoder needs to handle well-formed CBOR. That is not complicated. (Deterministic serialization makes sense when you need deterministic serialization. It is *not* about reducing work for the decoder.) > As a comparison, JavaScript's JSON object offers zero serialization options > (*). This enables users to concentrate on their application. The same goes > for Google's Protocol Buffer. And for many generic CBOR encoders. Specifications that use CBOR but somehow restrict encodings for a data item to a subset can cause complexity in the encoder. Don’t do that, then, unless you really *need* to do it. (Please fix EAT; stop doing this.) What you think is a little tweak simply ensures that you can’t use generic encoders; this is a big loss. Deterministic serialization is such a subset, which does have specific use cases, and I would expect its use to be a decision that is made being conscious of the added complexity. > There is obviously (IMO of course...), room for a comparable (but potentially > better) solution for CBOR. I would be interested to hear how YOU would > design such a thing. It’s called STD94, and it is already done. I’ll ignore the comments about JSON — the details here are mind-boggling, which is why I-JSON was needed. (In the mind of Douglas Crockford, JSON is a “format” only, and the mapping between artifacts that conform to the grammar and application concepts is left as an exercise to the reader. This led to interesting different interpretations, which tend to get in the way of interoperability. Hence I-JSON.) Grüße, Carsten _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
