Re: [core] Designs to resolve streaming issues in SenML

Carsten Bormann <cabo@tzi.org> Tue, 26 January 2016 09:27 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A8E1A884E for <core@ietfa.amsl.com>; Tue, 26 Jan 2016 01:27:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.401
X-Spam-Level:
X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 rq37CdDvcXDR for <core@ietfa.amsl.com>; Tue, 26 Jan 2016 01:27:02 -0800 (PST)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689451A884B for <core@ietf.org>; Tue, 26 Jan 2016 01:27:02 -0800 (PST)
Received: from mfilter20-d.gandi.net (mfilter20-d.gandi.net [217.70.178.148]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 7E025FB8DD; Tue, 26 Jan 2016 10:27:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter20-d.gandi.net
Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter20-d.gandi.net (mfilter20-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Fn39Y8RWdm9b; Tue, 26 Jan 2016 10:26:58 +0100 (CET)
X-Originating-IP: 134.102.218.240
Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 9E56EFB930; Tue, 26 Jan 2016 10:26:56 +0100 (CET)
Message-ID: <56A73BE0.1050704@tzi.org>
Date: Tue, 26 Jan 2016 10:26:56 +0100
From: Carsten Bormann <cabo@tzi.org>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Christian Amsüss <c.amsuess@energyharvesting.at>
References: <175A1806-ACB0-4FC7-A318-2A58FF66CDD2@cisco.com> <56965F8D.9040309@tzi.org> <7B9B6160-3AD4-4637-8430-540B99E6BDA2@cisco.com> <20160126073516.GC7789@hephaistos.amsuess.com>
In-Reply-To: <20160126073516.GC7789@hephaistos.amsuess.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/evuv6DtCw507O4ikVJugds5Md80>
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, core <core@ietf.org>
Subject: Re: [core] Designs to resolve streaming issues in SenML
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Jan 2016 09:27:04 -0000

That would be a radical simplification, indeed:

senml = [header, * measurement]

header = {
      ? bn: tstr,    ; Base Name
      ? bt: number,  ; Base Time
      ? bu: tstr,    ; Base Units
      ? ver: number, ; Version
      * tstr => any, ; (Extension)
}

measurement = {
      ? n: tstr,     ; Name
      ? u: tstr,     ; Units
      ? v: float,    ; Value
      ? sv: tstr,    ; String Value
      ? bv: bool,    ; Boolean Value
      ? s: float,    ; Value Sum
      ? t: number,   ; Time
      ? ut: number,  ; Update Time
}

Grüße, Carsten


Christian Amsüss wrote:
> On Mon, Jan 25, 2016 at 10:14:44PM +0000, Cullen Jennings (fluffy) wrote:
>> Seems like a good argument for only the first record can have base
>> values. Any objections to making that change for next version ?
> 
> Not from my side; I'd suggest going as far as forbidding per-item
> members in the first record. (Extensions would be free to allow their
> members in both a (or the) base object and in item objects).
> 
> Best regards
> Christian
>