Re: [Cbor] my (WGLC re-)views on error processing in RFC7049bis and future-proofing

[Carsten Bormann <[e-mail]>]

> On 2020-05-22, at 21:22, Laurence Lundblade <[e-mail]> wrote:
> 
>> On May 21, 2020, at 4:10 PM, Michael Richardson <[e-mail]> wrote:
>> 
>>>> Why can't we use decimal fractions, or bigfloats for time?
>> 
>>> That may have been a mistake (which is one reason we have tag 1001
>>> now).  The WG has generally taken a dim view on extending the domain
>>> (allowable syntax for tag content) for a tag, so we can’t “fix” that —
>>> note that for the date tag, we have taken the decision not to reuse one
>>> tag for two different tag content syntaxes either.
>> 
>> okay.
> 
> I think the main time type should have solely been an integer.

With hindsight, I almost agree.

> You can express +/- 500 billion years to 1 second accuracy with 64 bits. The earth is only 4.5 billions years old so it is even good enough for most science. It’s only really odd scientific use cases that would need anything else as far as I can imagine.

There is range (of which an integer has plenty for seconds-based time), and there is precision.
Unfortunately, precision isn’t that great with floating point(*) either, which led to the alternative time tag 1001.

> I would disallow float dates in the main time type. Floats only enable microsecond accuracy. They give no greater range that is of much use. Also, they have less precision and the precision varies by year.

Your CBOR-based protocol is welcome to do that.

> This is about code size and HW support. You don’t want to have to implement decoding of a variety of time formats for 0.0001% of the use cases. It is also a pain for every protocol to say “use the time tag, but disallow floats”. The CDDL type for time has this problem. Maybe should probably have a new CDDL type “simple_time” or that is tag 1, but disallows float.

Your CDDL definition of the data interchanged by your protocol could usefully say:

itime = #6.1(int)

For many applications, I’d actually go so far as

uitime = #6.1(uint)

(This is most useful for all protocols that describe point in time that lie after the creation of the protocols, such as claims issuance dates etc.)

I think that the notable tags document is a good place to make this discussion accessible as well as CDDL fragments like the above that can be copied (so people don’t invent thousands of names for the same thing).

> Then I’d create a second Swiss army knife time format that can use floats, bignums, decimal fractions and so on. I’ve been playing with implementations of conversions of these types and so far it takes 500-1000 bytes of code to convert all of them in some form or other.

That’s tag 1001.  But, again, your protocol can restrict that tag to the times you actually need.

> I’m kind of in favor of defining yet another time tag that just allows integers, but the current epoch time tag has been around for a long time now so it seems ugly to do so.

And it is not needed: The tag content is plainly visible, so it is easy to find out if someone sent you a floating point time (which you may not want) or an integer time; as seen above, it is also easy to write the CDDL for restricting this to what you want.

> In reality, probably everyone will just implement 64-bit only time as sort of an unstated best practice and it will be OK.

Hah.  Since (unsigned) 32-bit time takes us to 2106-02-07 06:28:15 UTC, I’m sure lots of people will go for that in their constrained implementations.  Make sure you tell your grandkids not to fly (or otherwise rely on product safety) on that date and time :-)
But note that 32-bit seconds also are already not useful any more for taking out 99-year leases on your neighbor’s garage.

TL;DR: It probably wasn’t too bright to define tag 1 as #6.1(int/float) in RFC 7049, but that’s where we are, and we know how to mitigate any ugliness.

Grüße, Carsten

(Insert discussion of epochs, eras, GPS 1024 week rollovers, and everything else.)

(*) We could have embraced 128-bit numbers (including floating point) earlier.  Seemed preposterous for CBOR in 2013.  But they have entered the picture in RFC 8746 (tags 83 and 87), and there are even CPU architectures for 128-bit processors now.