Re: [Cbor] Unusual map labels, dCBOR and interop

[Anders Rundgren <[e-mail]>]

On 2024-03-24 20:21, lgl island-resort.com wrote:
> 
<snip>
> 
> For dCBOR, I’d like to see map labels very restricted. I’m not a JSON user/expert, but it is a Jupiter-sized data point for me. It has massive use with only string labels.

What's the motive for bringing in constrains that are specific to the Blockchain Commons implementations into something intended as a multi-purpose IETF encoding profile/standard?  Lots of CBOR applications (probably the majority) already have this and other constraints but did not require a separate encoding standard to specify these.  Why can't Wolf et al do the same?

The only thing dCBOR needs to specify is the Numeric Reduction scheme.

> 
> I’ll propose integers and strings (major types 0-3) to start discussion. Maps and arrays seem too much. Only strings might be OK.
> 
> We’ll need Wolf and Christopher to weigh in. I haven’t heard from them lately.
> 
> I can imagine many use cases other than the Gordian Envelope finding dCBOR highly desirable because it eliminates all the CBOR stuff that is variable and a lot of stuff that is hard to understand. Most people aren’t as smart or as into this stuff as we are. Simple map labels line up with this.

Numeric Reduction will keep the use-cases to an absolute minimum.

Anders


> 
> 
>> (One of the things I wrote cn-cbor for in 2013 was to make sure one could do CBOR in a limited amount of code, as in some 768 bytes (not megabytes, not kilobytes); it did not need a restriction on map keys for that.  But of course the application code that is dealing with the data items once decoded is more complex when the data items are more complex, and that is not included in those 3/4 KiB.)
> 
> (It’s cool that you can build a tiny CBOR decoder and make object code size claims, but such may not be as easy to use or code-size efficient for larger stacks like SUIT and EAT. If a CBOR library does more of the work for you, then you have to write less code, not think as hard and test less. The code-size efficiency comes because there’s only one chunk of object code for common functions like map lookup by label and bstr wrapping/unwrapping. If the CBOR library is shared, then sharing is across all CBOR apps on the device.
> 
> As I’ve built out a stack for COSE and EAT, I’ve moved common functions into QCBOR. It makes QCBOR bigger, but the overall stack smaller.)
> 
> LL
> 
> 
> 
> 
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor