Re: [Cbor] Interactions of packed CBOR and tags

Carsten Bormann <cabo@tzi.org> Fri, 04 September 2020 04:53 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 84AB63A0C9D for <cbor@ietfa.amsl.com>; Thu, 3 Sep 2020 21:53:12 -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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 PMU8bVPjneyC for <cbor@ietfa.amsl.com>; Thu, 3 Sep 2020 21:53:10 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6835B3A0C95 for <cbor@ietf.org>; Thu, 3 Sep 2020 21:53:10 -0700 (PDT)
Received: from [192.168.217.102] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BjQKc46BxzyT3; Fri, 4 Sep 2020 06:53:08 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <6ED2C94E-CA4D-4D11-87FA-0E8010690A69@arm.com>
Date: Fri, 4 Sep 2020 06:53:08 +0200
Cc: "cbor@ietf.org" <cbor@ietf.org>, Jim Schaad <ietf@augustcellars.com>
X-Mao-Original-Outgoing-Id: 620887988.116006-5dd21ded567bb9a5247952656e4febb8
Content-Transfer-Encoding: quoted-printable
Message-Id: <313AA38B-7501-42C4-AD1A-0CA302AB8A23@tzi.org>
References: <00c101d67cb5$2588b790$709a26b0$@augustcellars.com> <E30F54B6-1A63-48AC-89AE-61983654B5A9@tzi.org> <00cc01d67cc9$766c7b60$63457220$@augustcellars.com> <4AE9B2FA-EEB3-4B45-96E4-9DC85118567D@arm.com> <016f01d6820b$bc7d7cc0$35787640$@augustcellars.com> <62FEE35D-75F3-422E-A6C0-FFE86ACBD9A5@tzi.org> <6ED2C94E-CA4D-4D11-87FA-0E8010690A69@arm.com>
To: Brendan Moran <Brendan.Moran@arm.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/LSL_EIYk-b0pUpyGHZw7X2x3fkM>
Subject: Re: [Cbor] Interactions of packed CBOR and tags
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: Fri, 04 Sep 2020 04:53:13 -0000

On 2020-09-03, at 19:05, Brendan Moran <Brendan.Moran@arm.com> wrote:
> 
>> Adding suffix packing, we could have a third table and a third set of referents (also with content).  We also could have just separate referents, sharing the table/number space, if that makes sense.
> 
> [BJM] Unless we have a way to obtain a whole new referent space with small values, I think that sharing the table is optimal. This also allows reuse of individual values as either prefixes or postfixes, which should yield some additional compression opportunities. This will be even more interesting in the array space.

Yes, but how do you know that a referent asks you to do prepend/append?

(1) encode prefix vs. suffix in the referent — but that does mean that we use more code points for the referents
(2) encode prefix vs. suffix in the table entry — but that means such an entry cannot be used for both (ok, minor problem), and it also requires to represent another bit in the table (which in the end might cost two bytes per entry).
(3) encode prefix vs. suffix in the position of the table entry — but that is exactly equivalent to (1) on the referent side but does create the need to manage holes.

So I think we need to bite the bullet and provide more referent space (1).

Grüße, Carsten