Re: [Cbor] [Rats] Combining CBOR protocol libraries

Laurence Lundblade <lgl@island-resort.com> Thu, 20 May 2021 21:10 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492703A25ED for <cbor@ietfa.amsl.com>; Thu, 20 May 2021 14:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 rZdD6AvdZztb for <cbor@ietfa.amsl.com>; Thu, 20 May 2021 14:10:39 -0700 (PDT)
Received: from p3plsmtpa12-01.prod.phx3.secureserver.net (p3plsmtpa12-01.prod.phx3.secureserver.net [68.178.252.230]) (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 BAE623A25E3 for <cbor@ietf.org>; Thu, 20 May 2021 14:10:39 -0700 (PDT)
Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id jpwDlloAdNQlKjpwElQBjv; Thu, 20 May 2021 14:10:38 -0700
X-CMAE-Analysis: v=2.4 cv=VOMYI/DX c=1 sm=1 tr=0 ts=60a6d04e a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=7CQSdrXTAAAA:8 a=6mruz7Rm3Mx_Hty0Pf8A:9 a=QEXdDO2ut3YA:10 a=n6RA51mxin08yaQ_90wA:9 a=Syi6It9LAEdlcVuo:21 a=_W_S_7VecoQA:10 a=a-qgeE7W1pNrGK8U0ZQC:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <445B2798-B484-4106-9D8B-2B6A4CC35D99@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7261DF2A-FDA3-4412-BFF0-55839BC64224"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Thu, 20 May 2021 14:10:37 -0700
In-Reply-To: <3382F797-49C8-4ECC-AA86-08AD53240D73@arm.com>
Cc: "cbor@ietf.org" <cbor@ietf.org>, "rats@ietf.org" <rats@ietf.org>
To: Thomas Fossati <Thomas.Fossati@arm.com>
References: <2AE5612D-B305-4F2C-BC1A-F36F0093F0C0@island-resort.com> <3382F797-49C8-4ECC-AA86-08AD53240D73@arm.com>
X-Mailer: Apple Mail (2.3445.104.17)
X-CMAE-Envelope: MS4xfPKt5D6n5wTqSZgkGaaO8jU/pHo9qUMWsUElb/QKH+MdO60R42cpo+dTPKUvMhyBRQRK0pMv14GHHzicAk+4xhV0qS57N1h46Cvh40JYnv8YsMTduX/o a70Xfq9+jVWI8cuGU2uxZQXCR6pQjNGsiGbOKjrjde02SQxz0B8Yr6xuZ2AxfLEkQTJNWDSKiE+BH4U4FIQ7Lefukv4Hn/JBPG2V1dV/pNyIQOPTrlFrYJ3T 8ij5bpd9rLrJq7EBeyFvnw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/vKRza6j3qnaEYGXAjTQq8UN1omQ>
Subject: Re: [Cbor] [Rats] Combining CBOR protocol libraries
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 May 2021 21:10:44 -0000


> On May 20, 2021, at 1:14 PM, Thomas Fossati <Thomas.Fossati@arm.com> wrote:
> 
> Maybe the C libraries could be extended to do something similar?

Yes, I could do that in QCBOR and probably others could too. It would require traversal of the CoSWID twice, once to find the end of it in the EAT decode and then once to actually decode it. Generally, CPUs are so fast these days, even little ones, that CPU consumption doesn’t seem like a problem to me. It would definitely be more code to do this than byte-string wrapping, but not a huge amount.

This has to be for all flavors of CBOR decoder, C, Rust, Python… 

This would be come a requirement on all your better CBOR decoders as I expect embedding some CBOR in other will be common as we build-up the CBOR-based protocol infrastructure.

So which is the better practice, byte-string wrapping for protocols or a requirement on your better CBOR decoders?

LL