Re: [Cbor] Interactions of packed CBOR and tags

Carsten Bormann <> Thu, 03 September 2020 19:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3691F3A1233 for <>; Thu, 3 Sep 2020 12:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 86kzpXm_m1um for <>; Thu, 3 Sep 2020 12:55:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C51F3A1231 for <>; Thu, 3 Sep 2020 12:55: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 4BjBPl0dyYzyws; Thu, 3 Sep 2020 21:55:55 +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: Thu, 3 Sep 2020 21:55:54 +0200
Cc: Jim Schaad <>, "" <>
X-Mao-Original-Outgoing-Id: 620855754.571545-55d5e331a94f847a7e75cf5972702f96
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <00c101d67cb5$2588b790$709a26b0$> <> <00cc01d67cc9$766c7b60$63457220$> <> <016f01d6820b$bc7d7cc0$35787640$> <>
To: Brendan Moran <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Cbor] Interactions of packed CBOR and tags
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, 03 Sep 2020 19:56:02 -0000

On 2020-09-03, at 18:57, Brendan Moran <> wrote:
> However it’s still going to be bigger than a cbor-encoded plain text URIs if you have more than a few > 23 byte path segments, which is a bit annoying.

It’s all in your head :-)

The point of CBOR (which also was the point of JSON) was to be a reasonably appropriate encoding for much of what an application wants to do (the difference between JSON and CBOR is in what is “reasonably appropriate” in the areas of application).

There is *always* a way to create a more compact bespoke encoding.  For anything.
For URIs: We haven’t even started Huffman-coding the string parts.  (Or LZ-coding with some smart predefined dictionary.  Whatever.)  So why worry about the length indicator for > 23 byte path segments, where the text itself could be so much more efficiently coded?

Engineers have a tendency to react to perceived optimization opportunities.  That is of course a good thing.  It turns bad when we start to tweak something and incur complexity costs just because it is slightly worse than something else.
(If it is much worse in some metric, and that particular metric matters, well then back to the drawing board.  But not here.)

Learning to use CBOR includes learning to tolerate the occasional bouts of cognitive dissonance that come from knowing “I could do this better” where the “better” is a few percent.

Grüße, Carsten