Re: [Cbor] Packed CBOR review

Carsten Bormann <cabo@tzi.org> Thu, 17 June 2021 09:24 UTC

Return-Path: <cabo@tzi.org>
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 D702F3A1532 for <cbor@ietfa.amsl.com>; Thu, 17 Jun 2021 02:24:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, SPF_HELO_NONE=0.001] autolearn=no 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 awQodGhgWRUw for <cbor@ietfa.amsl.com>; Thu, 17 Jun 2021 02:24:07 -0700 (PDT)
Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8E53A1530 for <cbor@ietf.org>; Thu, 17 Jun 2021 02:24:07 -0700 (PDT)
Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4G5GpC6SYCz2xJ9; Thu, 17 Jun 2021 11:24:03 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <33C84949-0F9C-432C-9C94-DE2C9EE17976@arm.com>
Date: Thu, 17 Jun 2021 11:24:03 +0200
Cc: "cbor@ietf.org" <cbor@ietf.org>
X-Mao-Original-Outgoing-Id: 645614643.5580831-840c58ab0c7ba8074fe4984d76e23830
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F367A6D-5CAD-474F-AFEE-DF1AC9A34135@tzi.org>
References: <8713C3AB-71C0-4EC0-8977-15F80EC11309@arm.com> <212CE7EA-73BC-47BF-B192-D2D523F4A376@tzi.org> <33C84949-0F9C-432C-9C94-DE2C9EE17976@arm.com>
To: Brendan Moran <Brendan.Moran@arm.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/FLw3T53de-Ao8fQqBVAt4WrerBk>
Subject: Re: [Cbor] Packed CBOR review
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, 17 Jun 2021 09:24:10 -0000

> 
> We can have our cake and eat it too. I don’t see a reason not to support all of these choices.

Absolutely — we then just need to design how each of these choices should look like.

> If we simply use a different type in each case, the encoding is unambiguous:
> 
> Basic-Packed-CBOR = #6.51([ ?dictionary-reference, [*shared], [*prefix], [*suffix], rump])
> rump = any
> prefix = any
> suffix = any
> shared = any
> 
> dictionary-reference /= standard-reference
> dictionary-reference /= uri-reference
> dictionary-reference /= hash-reference
> dictionary-reference /= context-reference
> 
> standard-reference = uint
> uri-reference = tstr
> hash-reference = bstr
> context-reference = null

I think I’d rather have

Table-Setup-Uri = #6.52([Uri-reference, any])
Etc.
But stacking the tags (and spending another array) costs three more bytes.

But maybe that stacking is most useful for 
Spiffy-Standard-A-Table-Setup = #6.4711(any)
Where 4711 is a tag allocated by spiffy standard A.
(Otherwise we’d need a separate registry for that uint, and that makes me shudder.)

In any case, stacking would allow stacking a couple standard references.

How would the hash reference specify the algorithm?
(I think CFRG would tell us that collision resistance between algorithms isn’t a well-defined property.)

I’m also not sure that a context-reference always is null, maybe the context supplies alternate tables…

(I’m always a little put off by optional array elements in a sequence, that gets into actual parsing quickly, but this one here may be OK.)

>> Apparently, in all cases it would be good to have a single data structure shape pre-defined for pre-populating the tables (“dictionary”).
> 
> I can see two possibilities here:
> 
> 1) just use the existing structure:
> 
> Packed-CBOR-Dictionary = [ ?reference, [*shared], [*prefix], [*suffix]]

Probably.
Should that get a tag?

Grüße, Carsten