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

From: Emile Cormier <[email-masked]>
Date: Fri, 2 Apr 2021 20:49:05 -0300

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 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.
Also, "octet" would be a better word than "byte", since there are
architectures (such as DSPs) where a byte is 16 bits.

The OffsetScaledLogVariance key does not mention the value's data type(s)
or its physical units.

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.

Cheers,
Emile Cormier

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 3 Apr 2021 08:21:19 +0200

Hi Emile,

I’ll get to your very useful input later, as it requires some study, but I can react to this editorial one now:

> On 3. Apr 2021, at 01:49, Emile Cormier <[email-masked]> wrote:
> 
> Also, "octet" would be a better word than "byte", since there are architectures (such as DSPs) where a byte is 16 bits.

Actually, no.  
The term “octet” stopped to be useful approximately 1983, when the last architectures that had non-8-bit bytes ran out of steam.

Its continued usage over the decades is a symptom of a stilted style that values the superficial appearance of precision over the usefulness of the resulting documents.
It may be a small instance of the many symptoms of this kind in standards documents, but it is worth stamping out with a vengeance.

(Note that this is about the English language — octet of course is the right word in French and other languages.)

If a technical document today uses the term “byte” for something else than 8 bits, somebody is trying to appear very smart by regressing to the time when that actually still was an option.  Technical documentation should never be made misleading just to appear that kind of smart.  I actually haven’t run into misuse of the term “byte” for a long, long time — can you point to an example from this century?

Oh, and to get rid of the residual argument that “byte” might be perceived to be less accurate: since RFC 7049, many documents’ terminology sections include the sentence:

   The term "byte" is used in its now-customary sense as a synonym for
   "octet".

Just checked the time-tag document: 
It does so explicitly as well (many other documents just include the terminology of RFC 7049/8949 and so do that only implicitly).

But now back to your excellent technical input...

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 3 Apr 2021 09:11:13 +0200

On 2021-04-03, at 01:49, Emile Cormier <[email-masked]> 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].

[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.)

> 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.

> 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.)

Grüße, Carsten

---

From: Emile Cormier <[email-masked]>
Date: Sat, 3 Apr 2021 15:34:38 -0300

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

> > 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).
> >
> 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.

> architectures (such as DSPs) where a byte is 16 bits.

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.

> 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.
> >
> 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.