Re: [Cbor] Packed CBOR review

Carsten Bormann <> Wed, 16 June 2021 13:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91EBC3A1662 for <>; Wed, 16 Jun 2021 06:08:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9JE0AIY4TJex for <>; Wed, 16 Jun 2021 06:08:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF7483A165E for <>; Wed, 16 Jun 2021 06:07:58 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4G4lq01r6rz2xHY; Wed, 16 Jun 2021 15:07:56 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Wed, 16 Jun 2021 15:07:55 +0200
Cc: "" <>
X-Mao-Original-Outgoing-Id: 645541675.888483-3e43b80755d770455d735fd6d8b23310
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Brendan Moran <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Cbor] Packed CBOR review
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: Wed, 16 Jun 2021 13:08:05 -0000

On 2021-06-16, at 11:21, Brendan Moran <> wrote:
> I would also propose adding another element to the table: an identifier for a pre-shared reference table:

I’m wondering what the allocation mechanics for such an identifier would be.

Let me go through a few cases and explain how I would handle it.


Pro: can be very compact.  
Con (pro as well): high threshold, limited set.

Solution: allocate a tag for the identifier, either wrapping a tag 51 or replacing it (in particular if not all tables need to be advanced).

Task: We probably should define how to define such a tag.

* Context

Pro: can be embedded nicely.
Con: Wherever the context comes from (e.g., referencing standard) needs to make sure the reference is unambiguous.

Task: Not sure what we can do here, except maybe giving an example.


Pro: Free for all.
Con: Hard to control.

There will need to be some security and assurance of non-mutability on the data that URI describes.
Preferred URI scheme would be ni:, but see next.

Task: Define URI import tag; shape of data structure that should be used (almost, but not entirely, like tag 51).

* Hash

Pro: No-brainer
Con: Can’t find the dictionary unless I already know it.
Hashes are large (at least when secure).

Define Hash import tag, shape of data structure that is being hashed (see above).

Apparently, in all cases it would be good to have a single data structure shape pre-defined for pre-populating the tables (“dictionary”).

Grüße, Carsten