IETF Logo Mail Archive

Re: [T2TRG] [Asdf] [One Data Model Group] Representation issues and protocol bindings

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 31 August 2020 20:47 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: t2trg@ietfa.amsl.com
Delivered-To: t2trg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AF93A0522 for <t2trg@ietfa.amsl.com>; Mon, 31 Aug 2020 13:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 742vyaB2rOiE for <t2trg@ietfa.amsl.com>; Mon, 31 Aug 2020 13:47:27 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C833A046E for <t2trg@irtf.org>; Mon, 31 Aug 2020 13:47:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 030F3389DB; Mon, 31 Aug 2020 16:26:23 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BCI_AgcZ7L3x; Mon, 31 Aug 2020 16:26:12 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9F4D9389D5; Mon, 31 Aug 2020 16:26:12 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 56A26600; Mon, 31 Aug 2020 16:47:15 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "asdf@ietf.org" <asdf@ietf.org>, "t2trg@irtf.org" <t2trg@irtf.org>
In-Reply-To: <A4218763-14BE-44DF-BB13-C248911CE84C@tzi.org>
References: <2ED86F4F-2926-4FBB-91A7-39F32FE7A970@tzi.org> <MWHPR11MB1838A7BB2F9D868DBF59B962D2510@MWHPR11MB1838.namprd11.prod.outlook.com> <BYAPR18MB2536E401A07C0F5DFF3376B6CE510@BYAPR18MB2536.namprd18.prod.outlook.com> <CAE5tNmoYSNPjndwo12O+RE+BdYG2bpadM1L6fAb+KKgairxkcw@mail.gmail.com> <A4218763-14BE-44DF-BB13-C248911CE84C@tzi.org>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 31 Aug 2020 16:47:15 -0400
Message-ID: <25823.1598906835@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/t2trg/x_obFSKI0oY1Q8nYlnGXax8GyBY>
Subject: Re: [T2TRG] [Asdf] [One Data Model Group] Representation issues and protocol bindings
X-BeenThere: t2trg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Thing-to-Thing Research Group <t2trg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/t2trg>, <mailto:t2trg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/t2trg/>
List-Post: <mailto:t2trg@irtf.org>
List-Help: <mailto:t2trg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/t2trg>, <mailto:t2trg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2020 20:47:29 -0000

Carsten Bormann <cabo@tzi.org> wrote:
    > But the problem remains how the ecosystem specifications can relate to
    > the converged model if that had to abstract some more.  And that’s
    > where the binding comes in.  To make ecosystem experts feel at home, we
    > probably need to make this rather accessible.

    > For information that is a ratio to a reference value (e.g., a lamp an
    > undefined metric of which can be set to a value between 0 to 100 %),
    > SenML has “/”  (the dimensionless unit).  So we would normally not use
    > percentages (or permille, or ppm, …), but a number that is typically
    > clamped between 0 and 1.  Of course, most ecosystems will scale this to
    > get an integer representation, and that is probably the largest source
    > of variation (*).

So for a lamp, the alternative to "/" is that the brightness be specified in
lumens (or maybe candela in some cases).

    > (*) And that when it should have been plainly obvious that all IoT
    > devices should express temperatures as an integer value in centikelvin
    > (cK), so a 16-bit unsigned value from 0 to 65535 can express most
    > real-life sensor values (between absolute zero and 382.2 °C), and
    > simply subtracting 27315 and dividing by 100 gives you the value in °C
    > :-)

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email