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

IMO, the core problem is the idea with "application profiles".  There are many reasons to why applications and tools only use respectively support subsets of CBOR.

Making map labels generic is a no-issue in high-level, object-oriented, memory-hungry tools like my Java and JavaScript CBOR implementations.  Such tools BTW, have no reason to ever encode anything but EDN in the same way as the Blockchain Commons tools only encode dCBOR.

QCBOR was obviously designed for memory-constrained embedded systems. This comes with certain limitations that are perfectly valid for the intended targets.  However, adding support for dCBOR in QCBOR seems a bit problematic since Gordian Envelopes require CBOR data items to be represented as discrete objects that can be added, moved, deleted, and replaced.

Anders

On 2024-03-19 19:19, lgl island-resort.com wrote:
> Henk, No worries for QCBOR users. There has been a warning in the documentation since its early beginnings.
> 
> Don’t want to make this about QCBOR, but a comment. QCBOR has explicit support to make maps easier to work with. It automatically decodes into one item with label and value and you can search a decoded map by label. Would be hard to have a clean/small design and support arbitrarily complex labels. Never a complaint.
> 
> It also has a mode that can handle arbitrary labels at the cost of the nicer map handling features.
> 
> LL
> 
> 
>> On Mar 17, 2024, at 5:35 PM, Henk Birkholz <henk.birkholz@ietf.contact> wrote:
>>
>> Hi Laurence,
>>
>> Why are map labels special here?
>> Or does your comment imply that dCBOR relies on a "symmetric" dJSON?
>>
>> More comments in-line.
>>
>> On 17.03.24 19:41, lgl island-resort.com wrote:
>>> A CBOR map label (aka map key) can be any data type including perverse things like an array or a map. Here’s a sample I made for dCBOR testing:
>>
>> "perverse"
>>
>>>      {[]: 7, 1(88): 2, "text": 3, 1: 1, {}: 4, h'7878': 5, true: 6, 8.77: 7}
>>> It has a map label of each major data type.
>>> Probably dCBOR should disallow map labels that are not strings or numbers because they don’t translate to JSON. Same reason simple type undef is disallowed.
>>> Probably we should state a general CBOR preference that map labels only be strings and integers.  QCBOR only supports text/byte strings and integers for map labels.
>>
>> It is not an implementation of RFC9254 then. Maybe that should be noted somewhere.
>>
>>> It’s been like this for years now and I’ve had no comment or request. Probably any use case that considers unusual labels can be redesigned to avoid them.  We only state a preference, not a prohibition, just like with indefinite lengths.
>>
>> For a while, arrays where (considered and tested) as map keys in suit-manifests. Again, if you do not want to implement RFC9254, please set up some warning signs.
>>
>>> LL
>>
>> Viele Grüße,
>>
>> Henk
>>
>>> _______________________________________________
>>> CBOR mailing list
>>> CBOR@ietf.org
>>> https://www.ietf.org/mailman/listinfo/cbor
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor