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

[Orie Steele <[e-mail]>]

Why do we need both CDE and dCBOR?

OS

On Sun, Mar 24, 2024, 2:21 PM lgl island-resort.com <[e-mail]>
wrote:

>
> > 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
>
>
>
>
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor
>