Re: [Cbor] Combining CBOR protocol libraries

Brian E Carpenter <> Thu, 20 May 2021 23:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C851F3A1060; Thu, 20 May 2021 16:36:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HFZZmba1fVFU; Thu, 20 May 2021 16:35:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C050F3A105F; Thu, 20 May 2021 16:35:55 -0700 (PDT)
Received: by with SMTP id kr9so1918472pjb.5; Thu, 20 May 2021 16:35:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bE4CMApxyaeWnk342fdZHcv40l9hlU5CJBmBH3l+4t4=; b=CKkEo3rw1BkXOn0QXcPmotDv8fniEL5nUq6GXF69xhUfpeDVoIh6xU5HhxGxvXcxlk Hgr7aUtQH7eRCmYNdjCsuXDvRcauIV61FCiDQXUfEARHaYtB1FCzw9mFyjpmb/2aAcQY ymofFDfTrAhP0DMB5VlFURkikXFXVoFCW+ADCOgfTYsoHx9zEQTc6XZH+OHDjC2pHhBf 5bjJ32dth+KI+qv6Ljxc462kJf9ByH8J5yhv2c3aUNZFwA28BvlfhibgfflPeFxK6UEU 6TiehKOQXW0FdgEfQ8JFSDhs3RYykloRYUemuyFeXsyHz8kxUP+tNE02ifR1jvBPI9J9 bRlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bE4CMApxyaeWnk342fdZHcv40l9hlU5CJBmBH3l+4t4=; b=Blzx6L7zZNnDvkyj40J2k0/lSaYLZ0liWhWwAzwsloAv6Iyqk2EKf2DH0Ox1hOftbf JOqkrYWSCJ3xuXEhcxY7Y34bsr8tio0M+m/kxqmSM5ffpuzT7WSvy7XlpQAJEUuQ02mo W/q+4kEgORwbQgPYg4oYe2b91DXbtLGLJWcvV/dIVcIvQsfHkrm5ZLpZYUJTb1S4Z5xo mPKh0lxCK6rUI/paojiZslzvxrHdF6+1xhDqwQclnFQWVH59ehryJiVBbPAuz4E3lF+k UBa81X/4JUlhKVyyem9FSIl6E9wwqo+O3Xxr5doSdtaEOQU3DyMC8RwXSncEdbIUyLq7 44wg==
X-Gm-Message-State: AOAM532cET7haUKRkzR604dWnmArtDYkUC0QI/EtdYnQjZM5Wf5HEoqd 8havuNn1b+j6O83wcRVT/Nlm0lBJrnDaHg==
X-Google-Smtp-Source: ABdhPJyp7L4Kj0thWCidEI/S9PIxt3bRrFC2Ur+unPvAl/HossJSN7MZVgtngYkyicPfvwSIha8CpQ==
X-Received: by 2002:a17:90a:4608:: with SMTP id w8mr7371872pjg.132.1621553754701; Thu, 20 May 2021 16:35:54 -0700 (PDT)
Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by with ESMTPSA id s48sm2683759pfw.205.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 May 2021 16:35:54 -0700 (PDT)
To: Laurence Lundblade <>
References: <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Fri, 21 May 2021 11:35:49 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Cbor] Combining CBOR protocol libraries
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 May 2021 23:36:01 -0000

On 21-May-21 10:25, Laurence Lundblade wrote:
>> On May 20, 2021, at 2:45 PM, Brian E Carpenter <> 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?

I think so, for the reason in my quote from the GRASP API - it allows you 
to be reasonably certain of being language-independent.