Re: [Cbor] Combining CBOR protocol libraries

Laurence Lundblade <lgl@island-resort.com> Thu, 20 May 2021 22:26 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 52E0E3A0BF3 for <cbor@ietfa.amsl.com>; Thu, 20 May 2021 15:26:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 pcDyldN2gunx for <cbor@ietfa.amsl.com>; Thu, 20 May 2021 15:26:00 -0700 (PDT)
Received: from p3plsmtpa08-02.prod.phx3.secureserver.net (p3plsmtpa08-02.prod.phx3.secureserver.net [173.201.193.103]) (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 445FE3A0BF1 for <cbor@ietf.org>; Thu, 20 May 2021 15:26:00 -0700 (PDT)
Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id jr79lgf5ENBMajr79lwSo3; Thu, 20 May 2021 15:25:59 -0700
X-CMAE-Analysis: v=2.4 cv=VK8YI/DX c=1 sm=1 tr=0 ts=60a6e1f7 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=pGLkceISAAAA:8 a=xFd-KHJ-cMaQ07nlEIQA:9 a=QEXdDO2ut3YA:10
X-SECURESERVER-ACCT: lgl@island-resort.com
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <dfb5ecc6-ba34-9fc4-2ae3-2ed998196508@gmail.com>
Date: Thu, 20 May 2021 15:25:58 -0700
Cc: cbor@ietf.org, rats@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F0AC7DDA-5F11-45FA-94F5-C50631575110@island-resort.com>
References: <2AE5612D-B305-4F2C-BC1A-F36F0093F0C0@island-resort.com> <dfb5ecc6-ba34-9fc4-2ae3-2ed998196508@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3445.104.17)
X-CMAE-Envelope: MS4xfFkiQvQhcmu4eyaOI7FNjPFJMXXMB0IrVT7b7lHip2CL7B3og0N3jiuX+U94LI5d5nJDVGlEzAXsiO1LmoP1Ok3eTmEXUvLavjW7/ReweoXExWuxglUW PzKI5QbsVTSAd4hrNeXD8GPhfKNH7CyaI0+wpHOcmT3O0SqtXyn6g9BpNZDe1fp3FWJWYUCwIvhOnTDqEzPirCrdvXeL4xhKI1eE2dCKzW9IV2v/pmuCYJuZ 3wZj0FYrj5fbafD/CfkmAg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/MmdL-m8_7c64LGXOK8Nkbd1l6r4>
Subject: Re: [Cbor] 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 22:26:03 -0000

> On May 20, 2021, at 2:45 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 21-May-21 07:37, Laurence Lundblade wrote:
> ...
>> 
>> So which is the better practice, byte-string wrapping for protocols or a requirement on your better CBOR decoders?
> 
> I don't see how having a class of "better" decoders works with interoperability. If we require that both ends have a "better" decoder, we've effectively forked CBOR, haven't we?

There’s always half-way implementations of protocols kicking around in GitHub and some of them may be useful in limited contexts. A CBOR decoder might also not implement preferred serialization, indefinite length string decoding and such and that is usually OK.


> 
> We wrote this problem into the GRASP API (whose RFC, I understand, is less than 24 hours away):

> A requirement for all language mappings and all API implementations is 
> that, regardless of what other options exist for a language-specific representation of the value, there is always an option to use a raw CBOR data 
> item as the value. The API will then wrap this with CBOR Tag 24 as an encoded CBOR data item for transmission via GRASP, and unwrap it after reception. By this means, ASAs will be able to communicate regardless of programming language.
> 
> I have some "interesting" code for this in my Python GRASP implementation, which decides on the fly whether to build a Tag24 or not, and if necessary de-tags an incoming Tag24 item. In other words, I had to write a nano 
> encoder/decoder into my own code.

So I take it you prefer byte-string wrapping as a best practice?

LL