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

Emile Cormier <> Sat, 03 April 2021 18:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D4DB3A0AB2 for <>; Sat, 3 Apr 2021 11:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hgi_PuOhi0rt for <>; Sat, 3 Apr 2021 11:34:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A70443A0AB4 for <>; Sat, 3 Apr 2021 11:34:51 -0700 (PDT)
Received: by with SMTP id nh5so1914423pjb.5 for <>; Sat, 03 Apr 2021 11:34:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rNBDV5UHBK338hdb1pNW8tlLdBu5JCV2EpbGoLBXE4o=; b=jExAizCVfteSZm2SlzEanPFHmmf+JIqKvviBqhWIgx6k8W9SCdF68GHX98HH7mxUyb IXSU4hdQ1lmLT+sn8sqEMQ41BXfogVyXyJ815hCvbWPOwEQC7Yfwiv5/schl4suHe8Bi fIOcIEimFG8xdLXJKX5rijEz0KkAT9u9p6MP1hzvETuIKFdDEloK43o2pjStRXiDuonE xZ2gK/Uww7frhqaKtxBOKaSjWvND9um1jZ91zVbWfKZpoobHY+UB7JSjRFHJYB5WHlnx eUYerAG+nRFygXYgpIpMzSYEgX/qQn5/WWHEUX6V3FeTdQqrV9xcIyoyMWhcDziIHb8W kCpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rNBDV5UHBK338hdb1pNW8tlLdBu5JCV2EpbGoLBXE4o=; b=nRu84mvF03Bda7Or98siOYkqK/iEFV0VopCARAb5QWiHvMPTqO4vAA4AFqnvQJNTa5 BRX1XWlLbcRteRDsNfXS01CJvROT8sq84nfdBfCme0N+h9RG6izTC5V4jHh1DYjIqwei O6k1RuA6+vi6ILlaC0HfwOVD75u1pq2sJbfeOVe67BzppOmWv5v0qsogIGj2Yy4rHpyz h1pTLzbx/Cvo6fDUlcLH+ggIGhGtaqB5ZstaEl3JPDe4FdJ6cIhuxDZ0F9GJxg+zkyOi M0mnojsI3NJzanT/Qo3HguBXq33/Myc3a1Aygh1jub9m98uzbNz/MS1V9oNSP2xo7Us4 Vzzw==
X-Gm-Message-State: AOAM531ZHOvfSyMcCT8ghAzkJ7ZGYt4W+4FSUAygEL4lkh+60zbYm5f1 E8ZQPaczKeLmHg5lsF6Ju1FrHxvsgEW2WIlvUsI=
X-Google-Smtp-Source: ABdhPJykJz4DPT43sLi77WC60i76DzpaTDxE4wHjXItjw4TUXlaQPy2gcSWcyuChCegJhnrhM1xZh/QJ/3Glug46ZFY=
X-Received: by 2002:a17:90b:16cd:: with SMTP id iy13mr19677331pjb.46.1617474889540; Sat, 03 Apr 2021 11:34:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Emile Cormier <>
Date: Sat, 03 Apr 2021 15:34:38 -0300
Message-ID: <>
To: Carsten Bormann <>
Content-Type: multipart/alternative; boundary="00000000000039685605bf15b8aa"
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 18:34:56 -0000

On Sat, Apr 3, 2021 at 4:11 AM Carsten Bormann <> wrote:

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

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]:
> > 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