Re: [Cbor] [COSE] [Rats] RAM requirements for COSE/CWT

[Laurence Lundblade <[e-mail]>]

Got it. Made PR to remove half-precision exclusion <https://github.com/ietf-rats-wg/eat/pull/172> from location. Thanks for the discussion and foot notes!

Checked a few decoders and can see that half-precision decoding is often supported.

LL

> On Feb 23, 2022, at 1:08 PM, Carsten Bormann <[e-mail]> wrote:
> 
>>> 
>>> This discussion was more about lat/lon.  
>>> cti (label 7) is a byte string, so there is no such problem there.
>> 
>> Lat/long needs double precision float to be useful to beings the size of humans on a planet of earth's size. Half-precision has so little precision on a planet of earth's size that it is useless for location.
> 
> That is not what this is about.
> 
> Saying “You need 16 bits to express the unsigned integer weight of a street vehicle in kg” does not mean that I can’t encode the weight of my bike in 8 bits.
> What the current text in EAT says is equivalent to "you can’t ever use 8 bits because some vehicles need 16".  That is not smart.
> 
>> I mis-remembered “iat” as “cti”. Iat is a time stamp. A uint64 can represent everything needed for a time stamp, 1 second precision and +/- 500 million years. Float adds no value.
> 
> Right, but that is OK: It is a restriction at the data model level.  You are asking the application not to feed floats into the generic encoder.
> 
> (Note that we strengthened the little wall between integer and floating point for RFC 8949, after seeing that RFC 7049 was confusing people a lot.)
> 
>> 
>> So EAT
>> - disallows half-precision in location, but allows doubles to relieve a decoder from implementing half-precision
> 
> Bad.  Half-precision (binary16) is not a different type at the data model level, it is just an efficient way to represent certain numbers in your data model.
> Binary16 has a significand [sic] precision of 11 bits.  Binary32 has 24 bits.
> So if you feed random binary32 lat/lon (~ meter precision) to your generic encoder, every 8192th will be encoded in half-precision (*).
> 
> Since lat/lon values are probably approximately evenly distributed, that by itself is not a reason to implement half-precision.
> The fact that CBOR preferred encoding does employ half-precision is.
> Deviating from that by disallowing binary16 is expensive: You no longer can employ generic encoders.
> 
> Don’t do that.
> 
>> - disallows float for iat to relieve a decoder from implementing float, assuming it is not implementing location (many EAT implementations will not support location)
> 
> Good(**).  That selection of integer second timestamps is a part of your data model.  
> You can do that, and no generic encoder will suddenly turn your integer iat number into a float.
> (Again, with RFC 7049, it possibly could have, but we fixed that.)
> 
> Grüße, Carsten
> 
> (*) Note that a similar thing happens in JSON: numbers that happen to be whole numbers will be encoded without fractional parts (10.0 becomes 10).
> In certain decoder implementations, that makes them a different “type" than 10.0 or 1e1 or 0.1e2 etc., causing breakage.
> But the JSON data model only has numbers, not integers as a separate, incompatible type, so these decoders are broken with applications that simply expect numbers.
> (Find ISO 6093:1985 for some fascinating history in this space :-)
> 
> (**) ((I’m not making any representation on whether applications need to know with a precision of smaller than a second when your EAT was issued.  
> I really can’t imagine that, but that is proof by lack of imagination; I do assess that the cost of enabling that is higher than the benefits.  
> But that is true until someone has a convincing counterexample…  
> Consolation is that these people can introduce a float iat = “fiat” :-)))
>