Re: [apps-discuss] SenML

"Kaebisch, Sebastian" <sebastian.kaebisch.ext@siemens.com> Wed, 14 March 2012 09:51 UTC

Return-Path: <sebastian.kaebisch.ext@siemens.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE86921F8574 for <apps-discuss@ietfa.amsl.com>; Wed, 14 Mar 2012 02:51:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.166
X-Spam-Level:
X-Spam-Status: No, score=-9.166 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8OdsiTthGlZ for <apps-discuss@ietfa.amsl.com>; Wed, 14 Mar 2012 02:51:08 -0700 (PDT)
Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by ietfa.amsl.com (Postfix) with ESMTP id EA79A21F8566 for <apps-discuss@ietf.org>; Wed, 14 Mar 2012 02:51:07 -0700 (PDT)
Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.13.6/8.13.6) with ESMTP id q2E9p55p009907; Wed, 14 Mar 2012 10:51:05 +0100
Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail3.siemens.de (8.13.6/8.13.6) with ESMTP id q2E9p3EF031513 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 14 Mar 2012 10:51:05 +0100
Received: from DEMCHP99E55MSX.ww902.siemens.net ([169.254.2.75]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Wed, 14 Mar 2012 10:50:58 +0100
From: "Kaebisch, Sebastian" <sebastian.kaebisch.ext@siemens.com>
To: Yusuke DOI <yusuke.doi@toshiba.co.jp>
Date: Wed, 14 Mar 2012 10:50:57 +0100
Thread-Topic: [apps-discuss] SenML
Thread-Index: Acz+HC0RMmoGe7GERxGeL1x16rBa7gDp0Cgg
Message-ID: <1CE2FB42E90B614C98BC172FAB12D4C002D5098E63@DEMCHP99E55MSX.ww902.siemens.net>
References: <1CE2FB42E90B614C98BC172FAB12D4C002D3FCFF8A@DEMCHP99E55MSX.ww902.siemens.net> <52B10DF8-11D1-44FE-8A8B-184BB0AE12F2@sensinode.com> <1CE2FB42E90B614C98BC172FAB12D4C002D50989C3@DEMCHP99E55MSX.ww902.siemens.net> <201203091742.q29HglnN008664@toshiba.co.jp>
In-Reply-To: <201203091742.q29HglnN008664@toshiba.co.jp>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] SenML
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2012 09:51:08 -0000

Dear Yusuke,

thank you for your mail.

> > 2) instead of using a "float" value, I would recommend to use the
> "mantissa" and "exponend" representation. A floating value is always a
> challenge for constrained devices because of its inefficent processing.
> 
> I think float values in EXI is already mantissa and exponend (base 10).

That's right, however, EXI has to convert the float value into the mantissa and exponent representation (encoding) and vice versa (decoding) respectively. This processing overhead can be avoided if we working already on data model level only with the mantissa and exponent representation.


> > 3) use restriction definitions of strings (define maxLength or list all
> possible values as enumeration). Especially using enumerations results in
> a smaller message size and avoids string comparison.
> 
> Enumeration is good idea but I think strict enumeration allows no
> addition in future without breaking backword compatibility. I recommend
> some 'dummy entries' to make room (and show the limit to keep the same
> bitwidth clearly) for future.
> 

If there a need of flexibility, then we should do that. In my understanding, the unit symbol table in 10.1 will be standardized and will be fixed then. 


Best regards
Sebastian Käbisch