Re: [core-parameters] Heads up for senml-versions

Esko Dijk <esko.dijk@iotconsultancy.nl> Wed, 07 April 2021 12:19 UTC

Return-Path: <esko.dijk@iotconsultancy.nl>
X-Original-To: core-parameters@ietfa.amsl.com
Delivered-To: core-parameters@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3933D3A4394 for <core-parameters@ietfa.amsl.com>; Wed, 7 Apr 2021 05:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level:
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl
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 exyHrTXffPyx for <core-parameters@ietfa.amsl.com>; Wed, 7 Apr 2021 05:19:43 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80114.outbound.protection.outlook.com [40.107.8.114]) (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 894773A4395 for <core-parameters@ietf.org>; Wed, 7 Apr 2021 05:19:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l+4s2tNNzd1F6enR17UA5U63tOygWIJmhjxCPO1Rr9saeYB26s2+ATU1szifWW2WrgRi3YyXGuW4R7DhcqY7MvMuHCxo9ZdISD554urbGLftnXoHoxT8+fivItNCglWQxwIqPyavaYBsSvGMVngxKAmc+mGrVged1F/0nEodvk0xzYtpSJbtXXFUpwh2txbh8GNkpH46E03TpjUq4027sToDX/z2vNOMet5EWPsjL9iRLaPSQ8FpFjjlf/aU+GLh28VRJotlYvICWtTDR+if65AGNguRs418PWHWRkp/vgZ+SPGUfNObsC9aBBGJJfhLl9NVQgect5V7IldoD/N4Vw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LwQangujEZiDj8rDjbNbePQqtNTCXf+5qrQru2tZP5s=; b=FauFLBSREobxbMUqSJdEcIgCH/ywS2uRvLIagLZ6rMaDwcKhShng+KNwWPBWE+aGe1DGEftNGz8mdLEkBr879z45yrTszmGsf/Mm5euHg3DQmjsGIHTQUL2ovgZccetyTYVncgWq6z5aBOg1aZtGqVzpBVyPd2AmzZAAFFTveJ8BieENz1w8cWqxi6IjgdJVVwGKoEznfWR1xe7naZZdTCcQZ/u/XcySgGDqX9AbE++KGOAwkUZsi0mYvrWlt+7NXS2vWtYlJBzIm7uCw5hgFu4qGvDvfohf7Mvms2vWMGW+vbKhi1a2FlPcA+Q/+Zd2NiiKI6OLA05KVRgzFrTJyg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LwQangujEZiDj8rDjbNbePQqtNTCXf+5qrQru2tZP5s=; b=nsvTld4lVcRZISI4xGVks7tQuYZco18ZgDFvocFUWIF4pd3IAc7SCzOi9d2A+8B47B0s5ZjI2+VfXMPZHsWxWX1DrtR4lnQ51JAeuc1gywSXtjNIPdQs/bISGVy607vv5grnoH4YM4zCMmCS6qI6Bxc3REFhc1wlhCfNHuT4MSA=
Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM0P190MB0657.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:1a1::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.17; Wed, 7 Apr 2021 12:19:38 +0000
Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::6415:492c:7afa:f296]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::6415:492c:7afa:f296%5]) with mapi id 15.20.3999.032; Wed, 7 Apr 2021 12:19:38 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: Carsten Bormann <cabo@tzi.org>
CC: Jaime Jiménez <jaime@iki.fi>, "core-parameters@ietf.org" <core-parameters@ietf.org>
Thread-Topic: [core-parameters] Heads up for senml-versions
Thread-Index: AQHXKhPJR+fasjocRE+W2L9gsneAk6qnIqzwgAGbhACAADkWAA==
Date: Wed, 07 Apr 2021 12:19:38 +0000
Message-ID: <AM8P190MB097976BA9FF1C3AEDED4BAD2FD759@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
References: <344256de-9aff-4677-ac6f-b214a9e954e1@www.fastmail.com> <AM8P190MB09798799F0D5CDBEE05A76B6FD769@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM> <1F39DA79-D2AC-48B4-8C86-BE3F8233F4AF@tzi.org>
In-Reply-To: <1F39DA79-D2AC-48B4-8C86-BE3F8233F4AF@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=iotconsultancy.nl;
x-originating-ip: [2001:1c02:3103:f500:300b:81:6124:4798]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f2e4d065-62f9-4699-8df0-08d8f9bf69e1
x-ms-traffictypediagnostic: AM0P190MB0657:
x-microsoft-antispam-prvs: <AM0P190MB0657D3FF41C4E34B3C69D693FD759@AM0P190MB0657.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: b0votiJqs4b3DBe1pnfDOungZsASmqCz45ooEJjTCzEgs/26oVzjH9qKxDkApO4pioDO+fvTRFYQNP1W+1f6llQxVq1AsdrY+8Q5KSol53RdV4rttliM0QZ2KBFJUbT/EF1HY1E+hbTpm1yeB2XDCA82cbtQ5Ln63ldJfeIVNbywbXW+CB0y0xyP068CGlTnRNAG//hJgyU8RT+LJajZ5wBSYVRu9Khe1q/1d8q57DqvxMaQChaa6bWwImDlbA0ixjsfSi4iE00eWyN9uJhiR6WRM5NRGE0I0N5did+ZogS8YK2xD6o60qtwFR2tQBxlruPTAm83sNEHU3TPRbTziuNqPMzxYF42/mIk5IUBwCtnekv/y6LVe5BHgjAh2godlRIE3In+re43CLGGqaY3bplmNRL8WhaAxA8GRW9fADVbGDhZXQRWldN02xS5Ahjb+loPBYH4UvrC9O44fiAUgZlaJFfU+yGAkHCsBbc0IMefAA5J9B64RbWWa/K1aYcL3XQCcIr2f95G+xD0UFMEPI3cXciRWvEfZ7intyh/piWxvla29YjBbaBish+AlEsKdWkL8rRKpH403zwB8fDaVQEQJM/Xq7p6dwczrg1EzS1VO+JRJuXcISpjhicCEGT0DgVq6OnqyCYjuX3yDVMCtFecnRZweI7FBU5JqSzR8oQ=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(366004)(346002)(136003)(396003)(39830400003)(64756008)(66556008)(66476007)(66946007)(76116006)(7696005)(2906002)(6916009)(83380400001)(33656002)(53546011)(186003)(44832011)(4326008)(6506007)(478600001)(38100700001)(316002)(71200400001)(54906003)(52536014)(5660300002)(66446008)(86362001)(9686003)(8676002)(8936002)(55016002)(66574015); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: n6z/VIC1Dv7VoZlmnq68MxK3jy15Gr55Yayc9ijBwe2aI4FCtWrXlvQaSrQdA6aFvGL9Aoohs/mvcl/esiMUyYCcK/5hHAjCj64li6jt3h1hmur1oSzKvzpUpoQ/YrqPC55Az6+i8y6LII/Zg5bbVV0N9ujKPc+LjK7wwV/UGuPJuZDenr/fxaA6v6ekOASImPqP5qXyLr5GhGSq9gvHyOx724NIu2H5eHGR/wLNL3HroJwKOfv6FYJVptV0GRnNNh3fW+TAX0qQO4dVNfSo0HQm37Xi1JERL7paFfd0UL8MKOdAD3bPJ1AYoL5tCzvUQIqzWlx37x2UZ0k95Y08VqfC4Dk0z0kzsCc1xnA4E18ym3JXR1s6YhqNpeDrbXjbP+EG7zn3UmtoFRNgAqZX68I491r2je2En+wOpdoNYVWODCUNiDV9WQkJdR3UFK9a0hO2MlvUBaSFHDjiLJiIDtz9hIfNfPg8doHx+Wt9fuPY3i2Ij1/qy1WMb65nd1IrXpgpJMVVu0hoxk4QbH3cm6gPC3i6FAhB+TyLek7vBztV46L3SLeOaAWyrXo/9L+QZkXXvNFt+Ji36vbT96Q1TZL1/1QpLuGqYdVIdwzcaUvwDU9CPncTpIar0dTrEg4g3LwMiFRsYni2f6DEUaQQOCM6tb2Nn/eQIUFCkAD0iLM2Lqanc/I5tMwrhyUrfYtYUGpBE5YD4ZvnEINazP2n7tGGOxB99YMljzF/RO9yEstl3RMX1o1QKqT4r+uYOAiJjMD6veXmQiPhhiFKv2AH2n0XfChaJwPckDKSbcooXhwJQ/acGR7keXYivwJWoyo2GX7XbyjaXnMxcFikD3+yvTcrU93VrWxDzbx7yAFkYkaLfvQOU2DnElhJpPLkTtNmZMP2Nm7X+T0ZIHUqz0+LyUTckrFbQs2hxq0ajWWu3PEbT1sIXVUfgZDcnGjSOq9ow7eT/YdCrXaQAcElvAl7nfRALAuL00rG5fPzy06UHMffTF1r+MFzxy21a3Kawc3XoF6mvf0u9ZnoWtwNAMwKlSTPZoS5nhNC9JsydajaL0hUX99z+7+AuaWCAUNWwMtT8pycyJN6kSd6Yelub/K3qzXwbYFrZp+/0KhQGzw759onRX6QFQ/Dvwu8UTYeRETGSDGtNMDDqitouUlzxhfKrvoZIRYbk8b2RQKvQZdeWvCYhJVSDmk/mpiNxoLIwwScbTUL0ZotZlxZAAlETyrAc12ebxekfSv49s4/26L7dCO3puTnL4GznV56dEaW+9SAYAW5f5p+8IjWawRFN3TjrNoCAZHTgUK94oMCYQMqvQlXKnGG8J4QpPumXzJDBEyUYkKu4SKWYm3iDYNTouT3eTyXCnpn722384CxdixXcs3+/Cfrnrlj7NcwrWwlNH+U
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: f2e4d065-62f9-4699-8df0-08d8f9bf69e1
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2021 12:19:38.2110 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 7nGZNka64jxkQ3leyNsH3aMOhEdvRG5mlEbFhBkUISWxARes2OC1i9K+4Me4D6JlcZOgu94zR/+ChfYOyUE+4fjXPqF04cN+XhcjCqlokpA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0657
Archived-At: <https://mailarchive.ietf.org/arch/msg/core-parameters/BQ5PRM22-wA4Uheotb8U16QoxDU>
Subject: Re: [core-parameters] Heads up for senml-versions
X-BeenThere: core-parameters@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Expert review of CoAP parameters." <core-parameters.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core-parameters>, <mailto:core-parameters-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core-parameters/>
List-Post: <mailto:core-parameters@ietf.org>
List-Help: <mailto:core-parameters-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core-parameters>, <mailto:core-parameters-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2021 12:19:48 -0000

Hi,

> Re being short as a rationale: See first paragraph of 2.1 (OK, it’s called “efficient” there).

I did see this rationale for efficient encoding of features; but to me (as an outsider) it only says that a bitmap to represent features is efficient and it does not say why the version field would need to be re-purposed for this. There must be some advantage w.r.t. leaving the version number field alone.   Maybe it's obvious that we cannot leave the version number to '10' in case some of the new features are included, but that it would need to be higher than 10, but to me that's not obvious. In case it is obvious to a user of RFC 8428 then of course we don't have to explain it.

By the way, I assume it is intentional that a SenML version 10 parser would never parse any SenML format object that uses a version > 10 ? See RFC 8428 4.4 requirement.
It seems a bit harsh that adding features would completely stop an older (v10) parser from processing the document. Again, there must be some reason here that I'm not understanding... 

> I’m not sure we should discuss all these potential alternative approaches.
Definitely not! I had assumed there would be one second-best alternative method only to consider, which was wrong. For me the most obvious choice of adding a feature bitmask is, well, to add a new feature bitmask field (which can encode features equally efficiently in principle) and not doing some wizardry with the version-number field. That's why I would expect a particular motivation for instead re-using the version field.

> Well, we do have must-understand fields, so we can switch some features over to them whenever we like
Ok so that removes the need to reserve any of the feature-codes, I think.

Best regards
Esko

-----Original Message-----
From: Carsten Bormann <cabo@tzi.org> 
Sent: Wednesday, April 7, 2021 10:37
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: Jaime Jiménez <jaime@iki.fi>; core-parameters@ietf.org
Subject: Re: [core-parameters] Heads up for senml-versions

Hi Esko,

> As an outsider to SenML I think the reason for doing this particular encoding in the version number is not yet well explained in the draft.  Somewhere it should state e.g. "re-purposing the version number is preferred to adding an additional feature-bitmask field in a version-11 format, because shorter to encode in average use cases”.

Re being short as a rationale: See first paragraph of 2.1 (OK, it’s called “efficient” there).

There is an infinite number of other approaches that solve this problem.
The specific one you mention really didn’t come to mind as it is inferior both to the one we chose and the introduction of a separate must-understand feature bit mask (no need to update the version number then).
I’m not sure we should discuss all these potential alternative approaches.

> The registry looks okay from what I can tell!
> For the sake of caution it could be useful to already reserve one feature code (e.g. the last one?) to indicate a far-future-version that doesn't encode a particular set of features but leaves open the door towards a completely different format (not using the feature codes) some day. 

Well, we do have must-understand fields, so we can switch some features over to them whenever we like (possibly earlier than exhaustion of the version number bits).  (See parenthesis in penultimate paragraph of 2.1., which I think also at least partially covers the previous point.)

Grüße, Carsten