[core] CORECONF k parameter encoding
Koen Zandberg <koen.zandberg@inria.fr> Thu, 15 September 2022 14:34 UTC
Return-Path: <koen.zandberg@inria.fr>
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 D6199C1526E2 for <core@ietfa.amsl.com>; Thu, 15 Sep 2022 07:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=inria.fr
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPwiA3fkDSZv for <core@ietfa.amsl.com>; Thu, 15 Sep 2022 07:34:24 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 49C51C1526E1 for <core@ietf.org>; Thu, 15 Sep 2022 07:34:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=message-id:date:mime-version:to:from:subject; bh=EcTQSIdp9ksSSTBvm1S8Yj4QaJmI9qpdZcnD23+XB+E=; b=oJ1GmFgJV8knHwaKsUW8azp04rXQ9zlcT1yZkdzdUnAaxyZUEE1qLxNa OSMcSMHr5S/mOrIL8QKkbN5oyUAu9WDcyytlZXoesWLb+wMiaEsJqyyBq UscCkVm5/3WBASzfJaX3Q8vQYqImIRUhpiXki3Dp7bq6T6J2zQnBHfnHo 4=;
Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=koen.zandberg@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr
X-IronPort-AV: E=Sophos;i="5.93,318,1654552800"; d="scan'208";a="52984624"
Received: from 185-227-75-229.dsl.cambrium.nl (HELO [10.1.7.20]) ([185.227.75.229]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Sep 2022 16:34:22 +0200
Message-ID: <4e9673fa-f1cb-a36a-50d2-b2583f144164@inria.fr>
Date: Thu, 15 Sep 2022 16:34:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0
Content-Language: en-US
To: core@ietf.org
From: Koen Zandberg <koen.zandberg@inria.fr>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------DzDKmb6hsFp0Vj1fFuhgCX99"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/iIglJzch9FwcaFJxxLyiAnhoepo>
Subject: [core] CORECONF k parameter encoding
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 15 Sep 2022 14:34:28 -0000
Dear all, I'm working on an open source implementation of draft-ietf-core-comi-11 for RIOT[1]. The implementation is still very minimal, gluing a couple of YANG modules to RIOT internals and expose them via CORECONF. So far there is support to configure IPv6 addresses, get the system information and the sensors available over CORECONF. One thing I'm running into, where I'm wondering if there has been previous discussion on this, is the encoding of YANG datatypes in the 'k' query parameter. There is a large variety of different encoding methods for the content, increasing the decoding complexity on the constrained device. Has it been consider of encoding all query params as a CBOR array and urlSafeBase64 as key value. The upside to this approach is that decoding the query parameter for a GET and DELETE requests closely matches the decoding of the payload with FETCH and iPATCH requests. Encoding the 'k' parameter also as CBOR array results in that for both a FETCH and a GET, the YANG list keys can in both cases be retrieved by iterating over a CBOR array. Has this way of encoding been considered? Or am I missing a potential issue with encoding the query parameter as CBOR? From what I get from the current status of the document is that I'm a bit late to the party here in terms of feedback, please let me know if I'm too late with the feedback here. Best regards, Koen Zandberg [1]: https://github.com/bergzand/RIOT/tree/wip/coreconf/sys/net/coreconf
- [core] CORECONF k parameter encoding Koen Zandberg
- Re: [core] CORECONF k parameter encoding Carsten Bormann
- Re: [core] CORECONF k parameter encoding Koen Zandberg