Re: [Cbor] Paywalled IEEE standards referenced in draft-bormann-cbor-time-tag

[Emile Cormier <[e-mail]>]

On Sat, Apr 3, 2021 at 4:11 AM Carsten Bormann <[e-mail]> wrote:

> On 2021-04-03, at 01:49, Emile Cormier <[e-mail]> wrote:
> >
> > The IETF draft for cbor tags 1001 thru 1003 reference the IEEE1588-2008
> standard for the clock quality keys.
> > Are there no other public domain or open-source standards that would
> serve the same purpose as IEEE1588-2008 for the clock quality keys?
>
> I’m not aware of any other places where this material has been written up
> (note that RFC 8575 also simply references IEEE1588).
>
> > I ask that without any expertise on the subject, but merely as a C++
> CBOR library implementer who wants to support these CBOR tags (they are
> better for transmitting std::chrono::time_point values losslessly).
> >
> > At the very least, can the descriptions be more explicit about the data
> types needed for the clock quality keys? ClockClass and ClockAccuracy
> specify "one-byte integer", but it's not clear if it's signed or unsigned.
>
> Well, it is clear from the CDDL above, but I have fixed the textual
> description of the rationale to include “unsigned” in the editor copy [1].
>

Thanks! It did not occur to me to check the CDDL. I'll pay more attention
to that the next time the data type is not clear in the descriptive text.


>
> [1]: https://github.com/cbor-wg/time-tag/commit/8ce40c3
>
> > Also, "octet" would be a better word than "byte", since there are
> architectures (such as DSPs) where a byte is 16 bits.
>
> (See previous mail.)
>

If "byte" is already well understood to be 8 bits in these sorts of
internet standards, then I don't want to belabor the point.


>
> > The OffsetScaledLogVariance key does not mention the value's data
> type(s) or its physical units.
>
> That is because it is really weird, and you won’t be able to make heads or
> tails of it unless you read IEEE1588.  Maybe we can have a summary of it in
> the next version, but rephrasing all the details won’t work.
>

I don't really need to understand it. I just need to pass it on to the
application if requested. I now see it defined as a 16-bit unsigned integer
in the CDDL.


>
> > My motivation is to create an intermediate extended_time struct in my
> C++ library that contains all the possible fields of a CBOR extended time.
> If an application wants to deserialize it into a std::chrono::time_point,
> my library would discard the clock quality stuff. If some sort of
> scientific application really wants the clock quality information, then
> they just deserialize into an extended_time destination object and my
> library copies all the available information.
> >
> > It would be preferable if the numeric clock quality fields in my
> extended_time struct were of a known static type, such as a double. But
> since I don't have access to IEEE1588, I don't know if double is of
> sufficient accuracy. I would appreciate it if an expert could illuminate me
> on the required numeric precision, or point me in the right direction for
> my own research on the subject.
>
> If you are talking about uncertainty (-7) and guarantee (-8), it is
> unclear to me what your precision requirements would be.  If the
> uncertainty is 1e-8 s, you could represent this in a double, but there of
> course is no exact representation of 1e-8 in IEEE 754 binary floating
> point.  The uncertainty of the uncertainty is going to be large enough that
> this is entirely inconsequential.  (The range of double is definitely
> sufficient.)
>

Thank you, this helps. I'll probably just pass those items to the
application (if requested) as double-precision floats, then.

Thank you for your time and patience.


>
> Grüße, Carsten
>
>