Subject: [Cbor] Representation of High Precision Timestamps with CBOR

From: <[email-masked]>
Date: Tue, 20 Dec 2016 22:41:59 +0000

We have implementations of IEEE1588 Precision Time Protocol which utilize 96 bit timestamps to provide sub-nanosecond resolution.  In the case of IEEE1588, they define a binary timestamp structure as 48 bits of seconds, 32 bits of nanoseconds, and 16 bits of sub-nanoseconds.  These timestamps are relative to the conventional Jan 1, 1970 date.  This cannot be represented by a 64 bit floating point number as it only has 48 bits of mantissa.  We use these timestamps to mark measurement data and schedule hardware related actions among cooperating nodes in a network.

CBOR defines tag 1 to represent numerical representation of date and time and mentions specifically integer and floating point types.  Is it permissible to utilize a decimal fraction that uses a Tag 2 bignum in conjunction with tag 1?  I imagine using this to encode a 64 or 96 bit integer with a 10**-9 or 10**-14 scale factor.

The encoding might be as follows:

C1           -- Tag 1 Date/Time
  C4         -- Tag 4 Decimal Fraction
    82       -- Array of length 2
      2d     -- -14 exponent
      C2     -- Tag 2 Bignum
         2C  -- Byte string of length 12 (96 bits)
            0102030405060708090a0b0c0d0e  -- Bytes content

The text for Date and Time says the tagged item can be major types 0, 1 or 7 but does not say 'MUST'.

Is use of Tag 4 allowed with Tag 1 Date/Time?  Is there a better way of representing this?  Alternatively, I suppose proposing a new IEEE1588 timestamp tag would be an option to reduce the tag overhead.

Feedback appreciated,

Glenn

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Dec 2016 14:23:43 +1300

I'm wondering whether you need the tags at all, if you know from context that you are
expecting this format.

Then [-14,0x0102030405060708090a0b0c0d0e] would be
822dc24e0102030405060708090a0b0c0d0e
according to my handy Python->CBOR converter.

Incidentally, your example C1C4822dC22C0102030405060708090a0b0c0d0e
blows up Python's cbor.loads() with a type error.

Regards
   Brian Carpenter

On 21/12/2016 11:41, [email-masked] wrote:
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 21 Dec 2016 07:15:59 +0100

On 20 Dec 2016, at 23:41, <[email-masked]> <[email-masked]> wrote:
> 
> The text for Date and Time says the tagged item can be major types 0, 1 or 7 but does not say ‘MUST’.

Hi Glenn,

I think we made a mistake by not allowing number formats other than int or float with Tag 1.
Clearly both decimal and big float (binary exponent) make a lot of sense here.

Can we fix that mistake?

As Brian notes, some implementers are relying on the “can be” being the normative, complete set of possibilities.  So allowing new number types in Tag 1 would be a change affecting implementations.  We could still decide that making this change is justified.

This is not the only place where we got the type embedded in a tag wrong.  Tag 36 only allows UTF-8 structured MIME messages; but those can be byte strings as well.  This was worked around by registering Tag 257 for the byte string case.

Is it better to have a new tag when we need to extend the types allowed inside a tag?  Old implementations can’t make a lot of use of that new tag either, but at least they won’t “blow up” with data they don’t expect in an existing tag.

(I don’t think that having a two-byte tag representation for a hypothetical “time with decimal” tag would be a problem given its natural size.  That tag also could [or could not] imply the Decimal tag, gaining back one byte.)

Brian is of course right that a tag is not strictly needed at all.  When defining CBOR-YANG, we first went that way (not using the tag) with representing RFC 6020’s Decimal type.  But then we went back to using the tag because we may need it to disambiguate unions.

In summary, I’m not sure there is a single best way forward here (at least I haven’t made up my mind yet).  That is exactly why I look forward to having a CBOR working group soon — we can make decisions like this as a working group decision, taking input from a variety of perspectives.

Grüße, Carsten

---

From: <[email-masked]>
Date: Thu, 22 Dec 2016 01:45:00 +0000

> I'm wondering whether you need the tags at all, if you know from context that you are expecting this format.

Since we store this as a meta data map we could certainly infer from context that a Decimal Fraction or big float represents time but on the other hand it's preferable to convert CBOR raw streams into a native type (e.g. Date) when building a map of meta data for example.

I think a bigger concern is that by precluding use of big float or decimal fraction we cannot even express a timestamp in microsecond resolution using float64.   While milliseconds is sufficient for most applications, a growing number need all available resolution.  Tools like wireshark capture in uSec resolution (albeit relative to the start).  A companion need when using time is the concept of duration which I haven't seen a tag for.

As for making a new tag or opening up the existing tag to a wider interpretation it doesn't matter much to me.  Not having a working implementation (yet) I'd prefer using the existing tag but I see the benefit of not breaking anything in the wild either.

--
Glenn