[Cbor] Re: Illogical handling of CBOR keys

[Anders Rundgren <[e-mail]>]

On 2024-07-24 22:41, Carsten Bormann wrote:
> Hi Anders,
> 
> thanks for the detailed feedback.
> 
> On 24. Jul 2024, at 21:39, Anders Rundgren <[e-mail]> wrote:
>>
>> Related to CDE.
>>
>> https://www.rfc-editor.org/rfc/rfc8949#section-5.6
>>
>> According to this section 0.0 and -0.0 are equivalent but only when used as keys.
> 
> In CBOR, 0.0 and -0.0 cannot be both used as keys in a single valid map item.
> This reacts to the fact that many map implementations provided by platforms do not provide ways to do this, and requiring a CBOR implementation to provide their own map implementation sounded unreasonable.
> 
>> This does not make sense in a high-level encoder/decoder design where keys are just CBOR data items:
>> https://cyberphone.github.io/javaapi/org/webpki/cbor/CBORMap.html#set(org.webpki.cbor.CBORObject,org.webpki.cbor.CBORObject)
>> Question: does CDE compliance require you to follow this rule?
> 
> No, CBOR compliance requires you to follow this rule.
> A map with both keys -0.0 and 0.0 is not valid CBOR (we decided to make this compromise as, if it were valid, it wouldn’t be very interoperable).

Thanx.  Good to know.  Since this clash seems highly unlikely and also is the result of a compromise, I don't feel overly tempted breaking the [pretty sleek] symmetry of my implementations. :-|


> 
>> According to the same section, JavaScript values 1 and 1.0 are equivalent which either imply numeric reduction or some special handling of keys.
> 
> What you are alluding to here is a statement of fact about JavaScript, not about CBOR.
> It alerts the protocol designer to consider that implementations would likely need to do something unnatural (e.g., mapping all integers to Bigint) to support a protocol that relies on the ability to use both integer and floating point values in the same place.

Right.  However, in a typical high-level implementation, keys are just standard CBOR data items, making potential platform issues universal.


>> In the TC 39 proposal,
> 
> Do you have a TC 39 link?

It has not yet gone into a TC 39 process, I have only posted it on their discourse:
https://es.discourse.group/t/cbor-js-and-the-cbor-object/1759


>> keys are just CBOR data items:
>> https://cyberphone.github.io/CBOR.js/doc/#cbor.map.set
> 
> (Wrapper objects, as you seem to call them.)
> That is certainly one way to handle JavaScript’s number system.

Although the wrapper concept may appear a bit awkward, the additional control it offers, also makes it a suitable companion to the "builder" pattern (https://github.com/cyberphone/CBOR.js/blob/main/test/xyz-encoder.js#L38) shielding application developers from wrappers, JavaScript number quirks, and [any] knowledge of CBOR.


> Using encoded CBOR data items (byte strings) as keys in a map can also help.

That would be an excellent solution for constrained systems!  Reduced run-time processing + No constraints on key values and types.


> I’m sure Joe has a few more in mind...

Yes, his current solution is based on making special arrangements for floating point numbers.


> 
>> Since CDE compliance requires integer and floating point values to be separated, I assume that this is not really applicable.
> 
> I can’t parse this.  What is “this”?

I only meant that CDE requirements are platform independent.  CDE compliance obviously requires a bit more work on certain platforms like JavaScript.  Although 2^53-1 integers surely sucks, I'm "reasonably" happy with my solution anyway:
https://cyberphone.github.io/CBOR.js/doc/#jsnumbers.int
It is not clear to me how you can achieve this kind of flexibility without some kind of wrapper scheme.

Anders

> 
> Grüße, Carsten
>