Re: [core] SENML proposal: Allow base attributes in any Record

Cullen Jennings <fluffy@iii.ca> Tue, 23 May 2017 17:27 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038B0129C37 for <core@ietfa.amsl.com>; Tue, 23 May 2017 10:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.779
X-Spam-Level:
X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 YCDSiGZqpNaf for <core@ietfa.amsl.com>; Tue, 23 May 2017 10:27:03 -0700 (PDT)
Received: from smtp101.ord1c.emailsrvr.com (smtp101.ord1c.emailsrvr.com [108.166.43.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693A4129C32 for <core@ietf.org>; Tue, 23 May 2017 10:27:03 -0700 (PDT)
Received: from smtp13.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 36DF7A01A5; Tue, 23 May 2017 13:26:59 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp13.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id BE650A0144; Tue, 23 May 2017 13:26:58 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.67] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 23 May 2017 13:26:59 -0400
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <06D60C67-7B3F-4A7B-A683-763B28F8620B@iii.ca>
Date: Tue, 23 May 2017 11:26:57 -0600
Cc: Christian Amsüss <c.amsuess@energyharvesting.at>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F16152F6-1567-4326-83A3-F79A446616DB@iii.ca>
References: <06D60C67-7B3F-4A7B-A683-763B28F8620B@iii.ca>
To: core <core@ietf.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Mr439rvBURDIJOiNQ1BoBmwVicE>
Subject: Re: [core] SENML proposal: Allow base attributes in any Record
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 May 2017 17:27:05 -0000

> On May 13, 2017, at 10:15 AM, Cullen Jennings <fluffy@iii.ca> wrote:
> 
> 
> We had a good call about URI , URL, and how this all links together but one of the discussion made us realize that for aggregated collections, the current spec is less than ideal and that problem reflected up in multiple ways. So here is the proposal ... 
> 
> We got back to allowing base attributes to occur in any record and be the base value any record after that up to the point where the base attribute gets set to something else. Take the example of a sensor with IP 2001:db8::2 that is an indoor temperature and humidity sensor that also aggregates in the reading from a similar outdoor device at IP 2001:db8::1. You could represent this wth 
> 
>   [
>     {"bt":1.320078429e+09,
>      "n":"2001:db8::2-temperature","u":"Cel","v":25.2},
>     {"n":"2001:db8::2-humidity","u":"%RH","v":30},
>     {"n":"2001:db8::1-temperature","u":"Cel","v":12.3},
>     {"n":"2001:db8::1-humidity","u":"%RH","v":67}
> ]
> 
> Note the IP part of the name is different in the last two records because that is the unique sensor they came from.
> 
> But it would be nicer to be able to say 
> 
> 
> [
>     {"bn":"2001:db8::2","bt":1.320078429e+09,
>      "n":"temperature","u":"Cel","v":25.2},
>     {"n":"humidity","u":"%RH","v":30},
>     {"bn":"2001:db8::1",
>      "n":"temperature","u":"Cel","v":12.3},
>     {"n":"humidity","u":"%RH","v":67}
> ]
> 
> This gives us better compression because we can use a base name for the common IP part of the sensor name. 
> 
> A very common use case for core is aggregating measurements into one pack so I think this is an important use case. It also resolves the issue we were having with lining up with names and URL which is how we realized we had this issue. 
> 
> So my proposal is go back to how we used to have it and allow base attributes in Records other than than the first Record. I realize this is flip flopping on a previous decision but I think we forgot about this use case when we went to base values only in the first Record. 
> 
> Let me know if you see any problems with this. 
> 
> Thanks, 
> Cullen
> 
> 
> 

I got a few looks good from folks so I have updated this into the latest draft at https://www.ietf.org/id/draft-ietf-core-senml-08.txt