Re: [core] Last Call: <draft-ietf-core-senml-more-units-02.txt> (Additional Units for SenML) to Proposed Standard

"Pete Resnick" <> Tue, 22 October 2019 15:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3462C120073; Tue, 22 Oct 2019 08:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EasgfWidBWsd; Tue, 22 Oct 2019 08:33:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 46A7E120043; Tue, 22 Oct 2019 08:33:15 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DFF1916E43E; Tue, 22 Oct 2019 10:33:11 -0500 (CDT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r8knrQPo3L6A; Tue, 22 Oct 2019 10:33:09 -0500 (CDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 2414F916E434; Tue, 22 Oct 2019 10:33:09 -0500 (CDT)
From: "Pete Resnick" <>
To: "Cullen Jennings" <>
Cc: IETF <>,,, core <>,
Date: Wed, 23 Oct 2019 00:33:01 +0900
X-Mailer: MailMate (1.13r5655)
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [core] Last Call: <draft-ietf-core-senml-more-units-02.txt> (Additional Units for SenML) to Proposed Standard
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Oct 2019 15:33:18 -0000

[Cc'ing last-call.]

I have to agree with Cullen. In fact, the paragraph at the bottom of 
section 4 shows the confusion and harm:

    SenML packs MAY, but SHOULD NOT, use secondary units in place of
    SenML units, where the exception of the "SHOULD NOT" lies in the
    context of specific existing data models that are based on these
    secondary units.

You can't "MAY" do something and "SHOULD NOT" do it. Those are 
contradictory terms.

Either register these (and all SI prefixes) in the existing registry, or 
don't register these at all. Implementations are perfectly capable of 
multiplying and adding.


On 22 Oct 2019, at 23:05, Cullen Jennings wrote:

> I am strongly opposed to the secondary registry - it will 
> significantly harm interoperability. This could be resolved by not 
> adding the items in the secondary repository or by adding them to the 
> main repository.
> Having a registry of stuff that may or may not work simply means that 
> we will have less interoperability because what you can not decide 
> what is valid SenML or not.  Sure some of the device vendors making 
> things that produce SenML have thought this was a good idea in the 
> past but I’d like to hear from a bunch of the people that have to 
> process the SenML data that is produced and see if they think it is a 
> good idea.
> The working group discussed this for a long time and was against the 
> items that are being added to the secondary repository.
> If there is a large group of people that agree the consensus has 
> changed, then this should simply be put in the main registry. Many 
> people believe that since SenML is not meant to be human readable, 
> having a canonical form of just meters with a floating point number is 
> better than having both km, mm, and god only knows what else.
> I note the secondary repository add mm but not cm. How is this 
> insanity going to work out? How will analytics code trying to process 
> this data know what it can use or not use. If we are going down this 
> path, this is the wrong way to do it. The right way is to define a set 
> of all SI prefixes and say they can be used with any unit.
>> On Oct 16, 2019, at 11:42 AM, The IESG <> 
>> wrote:
>> The IESG has received a request from the Constrained RESTful 
>> Environments WG
>> (core) to consider the following document: - 'Additional Units for 
>> SenML'
>>  <draft-ietf-core-senml-more-units-02.txt> as Proposed Standard
>> The IESG plans to make a decision in the next few weeks, and solicits 
>> final
>> comments on this action. Please send substantive comments to the
>> mailing lists by 2019-10-30. Exceptionally, comments 
>> may be
>> sent to instead. In either case, please retain the 
>> beginning of
>> the Subject line to allow automated sorting.
>> Abstract
>>   The Sensor Measurement Lists (SenML) media type supports the
>>   indication of units for a quantity represented.  This short 
>> document
>>   registers a number of additional unit names in the IANA registry 
>> for
>>   Units in SenML.  It also defines a registry for secondary units 
>> that
>>   cannot be in SenML's main registry as they are derived by linear
>>   transformation from units already in that registry; RFC 8428 is
>>   updated to also accept these units.
>> The file can be obtained via
>> IESG discussion can be tracked via
>> No IPR declarations have been submitted directly on this I-D.
>> _______________________________________________
>> core mailing list

Pete Resnick
All connections to the world are tenuous at best