Re: [Cbor] Record proposal

Kris Zyp <> Wed, 17 November 2021 15:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC5E23A0594 for <>; Wed, 17 Nov 2021 07:16:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fv9sDMKQZnGv for <>; Wed, 17 Nov 2021 07:16:20 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 909C53A0163 for <>; Wed, 17 Nov 2021 07:16:19 -0800 (PST)
Received: by with SMTP id z5so12749126edd.3 for <>; Wed, 17 Nov 2021 07:16:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oHaTTu95xSbsJOHBccvJCT760LH761NT/YeTCbskwsM=; b=WtIpq2wxYIVUli1Kgv6e3YC5luJzKSjwOwba1Ld1MdAtybIYL6JJyTEo3IAzRUjbkM nk9iAWy07rLnSkQbVVZvGe32iwF2RqmfJu+vT4jPnCRzA/Pn5iB79En6C7K9Smw5UsWS nJGsHWVWsvWLbeVdnYx3554vwhhqAwgba/s6z8EsFepkXwDYEOJOB+DsurP46wb2GRr6 PHiaNXhN+lRskbB67xh8DucXGeCTiD0b9qKwdroayty9NuT1MzjXJqDxsQGIIm+pSdRR +7nca3W2vMkpEcDJ4JufrfOh3SR+Y/koiCgCRmjEkDlgNDf+dUhgYhBwxy1SeiTiH7Io A4Rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oHaTTu95xSbsJOHBccvJCT760LH761NT/YeTCbskwsM=; b=C4ecaAY+W69iooFqymkNPckAfSBS68qltcaZ26jxV30HlXSZowWWML4vy+Nd0H0lgV IGzEeKOnwCjB30Rxt6+X4QOrOLGPHCPQ5qVU9jHljMTWA462SCf/itdLUFbGQE7r5aMr OrHogD6Qpfxt2tfIYCA9pjWEAX7V0vq2B6EtX/OPV4NzDh26CWKfHltPEs334qaAyqiQ 4yjScQfrXv7WVndj0xTK/yE/Amkzv8tGbpPqdWuo8CnR+ReQe6szPJLnZTD/lgnc7623 9VdOeVxS8Bw6ZH5c06eqfWv3xy9mpWQP4ig+lq74ph673DkWJLGXBzkUCAml+BsP/HIb 1VgQ==
X-Gm-Message-State: AOAM533/YXekjcdejM7cilSomRYsq5IfFPWEbQe6Tj8Iwq/U1wNhNYSq 53WKyh2V6HOZdZAsB+0PmSSsgVLv32rSi7F3lpJqK6SJ2mo=
X-Google-Smtp-Source: ABdhPJz2GUv0fkPiqnjkE4XSfVkGb7JlIBnNDFSVTIAA5H0tnJzMnZJEkgFKfcZpjVnHkBn5lsayg1zV8LbDg3F9vOk=
X-Received: by 2002:a50:da48:: with SMTP id a8mr22891254edk.146.1637162174556; Wed, 17 Nov 2021 07:16:14 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Kris Zyp <>
Date: Wed, 17 Nov 2021 08:16:04 -0700
Message-ID: <>
To: Carsten Bormann <>
Cc: Christian Amsüss <>,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Cbor] Record proposal
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, 17 Nov 2021 15:16:23 -0000

I have updated my tag registration proposal/submission at to use 1+2 tag entries, which
hopefully makes this a much less intrusive registry entry. I have also
updated the proposed tag definitions to also support up-front
declaration of a set of record structure definitions for a data item
("around" that data item, like the packed approach, as you suggested),
in addition to the current inline record definitions (which can be
scoped with record definitions and should follow a well-specified
order for when they can be referenced by subsequent references). I
hope this offers flexibility for encoders that have all structures
known a-priori and streaming encoders (that do not), while still
maintaining nearly the same mechanics for decoders. Let me know if you
think this looks reasonable.
Thank you!

On Thu, Nov 11, 2021 at 9:15 PM Kris Zyp <> wrote:
> > Actually, stats would be very interesting.
> > I was assuming that the 1+1 setup comes with a number of 1+2 referencing records, the hit from going to 1+2 there as well would be relatively insignificant.
> > Number are better than assumptions!
> You are definitely right, using 1+2 tag for defining records is pretty
> insignificant (around a quarter of percent in my tests). Anyway, I put
> together some tests comparing CBOR packed, record structures, and
> combinations with a couple test data structures, with my library, for
> the sake of further comparisons:
> Anyway, seeing this, I am happy to go ahead and update my proposal to
> use a 1+2 tag for defining records. And thinking about this, I don't
> think my proposal necessarily even needs to mandate the tag ids used
> for referencing records since those are dynamically assigned and
> explicitly specified by the encoder itself (encoder obviously must not
> conflict and use tag ids that will be used for other purposes), albeit
> can encourage a certain range (presumably from the first-come
> first-serve range).
> Do you have any preference for a tag id to use? It looks like 279 is
> the next in the contiguous block, but sounds like choosing aesthetic
> characters is the new preference (29299/"rs" perhaps).
> Anyway, thanks again for the helpful feedback, really appreciate it!
> Thanks,
> Kris