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

["lgl island-resort.com" <[e-mail]>]

> On Mar 20, 2024, at 1:34 PM, Carsten Bormann <[e-mail]> wrote:
> 
>> dCBOR disallows the simple value “undefined” and NaN payloads (both are restrictions on the CBOR data model).
> 
> Right.
> These are restrictions motivated by the application processing envisioned.
> 
>> I believe this is because JSON doesn’t support them.
> 
> I don’t think so.   I think JSON doesn’t support them because they didn’t want these data items at the application level.   I can’t speak for the dCBOR restrictions, but I can imagine similar considerations apply, but I don’t think dCBOR does this “because” JSON did this.
> 
>> Seems logical that dCBOR might want to disallow maps and arrays as map keys since they are not supported in JSON.
> 
> Non sequitur.

It is sequitur. If my first statement is true, then my second statement reasonably follows. 


>> CBOR has serialization variability that we must manage.
> 
> (For certain applications — most CBOR applications don’t need deterministic serialization.)
> 
>> The general acceptance of dCBOR here in the WG shows that sometimes we also manage the CBOR data model.
> 
> I’m not sure what that “general acceptance” is — I think there is a common perception that dCBOR is a valid example for an application profile, and that we should support the concept of application profiles, so having one instance under consideration is helpful.
> If the dCBOR people want to limit the map keys in some way, I’m fine with that; if they don’t, I’m fine with that, too.

Discussions here have been ended at times by asserting that the CBOR data model can’t be restricted. While dCBOR is not adopted yet, it seems that it will be. That shows me that the WG is willing to restrict the data model in some cases.

I fully agree with no restriction on the data model for CDE. We must have a deterministic encoding that covers the entire data model. 

(There’s no good description of serialization variation vs data model variation. It took me a while to fully understand these two (I’m roughly only average smart), but now I am a solid CDE implementor.)

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. 

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.


> (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