> On Feb 23, 2022, at 1:08 PM, Carsten Bormann <[email protected]> wrote: > > Hi Laurence, > >> >> I know in reality most decoders will handle non-preferred serialization, but >> I don’t see anything in section 5.2 that says that they must. (non-preferred >> is still well formed). > > What part of the first sentence of section 5.2: > >>> A generic CBOR decoder can decode all well-formed encoded CBOR data items >>> and present the data items to an application. > > ...could we have phrased better?
Well, um, maybe. :-) It’s a small sentence with potentially big implications. If your generic decoder is like the pseudo code the implications aren’t big, but for decoders like QCBOR that do a lot more work for you, the implications are large — deep combined nesting of interleaved definite length and indefinite lengths maps and arrays, huge indefinite length strings, multiple levels of tag nesting for a data item that is a map label, a nested set of maps that is used as a map label,… I haven’t checked, but there might not be very many truly conformant generic decoders. QCBOR definitely isn’t, because it has limits like a max of 4GB for encoded input, max levels of map, array and tag nesting and such to be efficient with code size and memory. That said, probably most decoders can handle non-preferred integers, the topic at hand, just fine because it is trivial. Yes you are of course right that 5.2 that defines generic decoders says non-preferred serialization must be supported. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
