Re: [Cbor] Combining CBOR protocol libraries

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 20 May 2021 21:45 UTC

Return-Path: <brian.e.carpenter@gmail.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 6FE433A0857; Thu, 20 May 2021 14:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 9ZqoTY6bp0vO; Thu, 20 May 2021 14:45:35 -0700 (PDT)
Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B59633A084E; Thu, 20 May 2021 14:45:35 -0700 (PDT)
Received: by mail-pj1-x1035.google.com with SMTP id g6-20020a17090adac6b029015d1a9a6f1aso5965450pjx.1; Thu, 20 May 2021 14:45:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9UnldNdi5re/WAQMHHPaGSIEKgDZTpbTdGJa1O6b2vo=; b=pLatS4AgFXT4+uAJAS3eIPXU7RevO+RYk/Q75KXZq4nsA8FfQGKm4QS7CBJW84s4sR gJHdDBeTnvTu+IuvbRLn8UJTDISUb9pxwAuMljo5d0JyASCkmqkNIVIdmEN0berJgti0 kNZbCbfnSO6Pq/s/jiRACHgjrX1PQ0N/h+PPU/qQ+G1oarlyhbjQTaCLk2v1ESwo8Kw9 Vim8t1bVPsOFQVcrvw4NViBwvx1nVH4wlqBhG22NkVlqUVLpfqgnYi3LdDa9M/MBUMbo VHvWP9nxftB4myvxN+M03R9HK20fJW95+IJseKxdGimzWHZNsPp62kAEuUob2hBnxKNC BVXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=9UnldNdi5re/WAQMHHPaGSIEKgDZTpbTdGJa1O6b2vo=; b=oWVqC7SnOf9qLRJO+BOw3u+Ypic5JhILZQZ8NlC2s08yVNPuQeJXsX9kmpZxuHj2xQ 8or3ehx8wiLHMtRagdQEkgq1tSJGKtKwe4o3Nh6pa50aTmhnpHqQQy8MuqgUKEjGsw0L ZY5+D2OrU9czu/sr9i43YZjhuIG3HswIzI42wlPWWEhTbzRm3aOqPbLc0MM2Hh8FuPBn qDRHKoxKAyPni8rb3yMJ4djbtAycsd+jQrJihfGe1a4guSfmOJ2W9KqnMlOermnX3cpb ntAlmITJhdtG6EE1Oth5YvZikJbVl7scHq9/dNFaHyoNbY9bMcDgvAqRuAmCFYk/g9SD Dr1g==
X-Gm-Message-State: AOAM533UAHw4Yq8DVRJhpcZslGObfspKiJZEnS5BDk8Nf1Ksy6hSXWt0 zB5jVhahPD2MpWINxoHFt7ejqidzG7PjbA==
X-Google-Smtp-Source: ABdhPJye9KEgPOFiGIsI+wjKKIg5MJPHZgaEQwwJ/jK9XOhrONLHKLJBMcuqaepue4JbBa66K3qKyw==
X-Received: by 2002:a17:90a:117:: with SMTP id b23mr6026436pjb.183.1621547134710; Thu, 20 May 2021 14:45:34 -0700 (PDT)
Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id a26sm2630638pff.149.2021.05.20.14.45.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 May 2021 14:45:34 -0700 (PDT)
To: Laurence Lundblade <lgl@island-resort.com>, cbor@ietf.org
Cc: rats@ietf.org
References: <2AE5612D-B305-4F2C-BC1A-F36F0093F0C0@island-resort.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <dfb5ecc6-ba34-9fc4-2ae3-2ed998196508@gmail.com>
Date: Fri, 21 May 2021 09:45:29 +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: <2AE5612D-B305-4F2C-BC1A-F36F0093F0C0@island-resort.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/ElHsSVrUHgZAxvAzaH6YJkQWiTE>
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 21:45:39 -0000

On 21-May-21 07:37, Laurence Lundblade wrote:
...
> I think this generalizes to just about every CBOR protocol that includes another CBOR protocol. Every time you put a CBOR protocol message inside another different CBOR protocol message is MUST be byte string wrapped!
> 
> OK, well maybe there can be some exceptions, but I don’t think they are universal enough that they can be assumed in CBOR protocol design.

...

> So the up shot for me here is that best practice for a CBOR protocol that is embedded in another CBOR protocol is byte-string wrapping.

On 21-May-21 09:10, Laurence Lundblade wrote:
...
> 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?

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?

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.

    Brian