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

Carsten Bormann <> Sat, 03 April 2021 07:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59B293A0FF1 for <>; Sat, 3 Apr 2021 00:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XJxTh9t5Nis0 for <>; Sat, 3 Apr 2021 00:11:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 74F763A0FEF for <>; Sat, 3 Apr 2021 00:11:16 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4FC7PZ19fSzyPY; Sat, 3 Apr 2021 09:11:14 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Sat, 03 Apr 2021 09:11:13 +0200
X-Mao-Original-Outgoing-Id: 639126673.3501281-f4f5e493810fdd372949b644777715f2
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Emile Cormier <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Cbor] Paywalled IEEE standards referenced in draft-bormann-cbor-time-tag
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Apr 2021 07:11:20 -0000

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


> 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