Re: [Cbor] Private tag numbers

Carsten Bormann <cabo@tzi.org> Sat, 22 April 2023 08:34 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 D5BD2C152D9C for <cbor@ietfa.amsl.com>; Sat, 22 Apr 2023 01:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXAoyP-Kgo-q for <cbor@ietfa.amsl.com>; Sat, 22 Apr 2023 01:34:21 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F38C152D94 for <cbor@ietf.org>; Sat, 22 Apr 2023 01:34:19 -0700 (PDT)
Received: from smtpclient.apple (p548dc9a4.dip0.t-ipconnect.de [84.141.201.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Q3Pnh4YgXzDCc3; Sat, 22 Apr 2023 10:34:16 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <AS2PR09MB6342AB1E5DFF19EDFB65F25F8C609@AS2PR09MB6342.eurprd09.prod.outlook.com>
Date: Sat, 22 Apr 2023 10:34:05 +0200
Cc: "cbor@ietf.org" <cbor@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8AD1E3E6-A474-4D4D-B404-66172DF8C481@tzi.org>
References: <AS2PR09MB6342AB1E5DFF19EDFB65F25F8C609@AS2PR09MB6342.eurprd09.prod.outlook.com>
To: Tony Putman <Anthony.Putman@dyson.com>
X-Mailer: Apple Mail (2.3731.500.231)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/NJlskB63pjXFt5a6S37tiwJBbCM>
Subject: Re: [Cbor] Private tag numbers
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 22 Apr 2023 08:34:24 -0000

Hi Tony,

thank you for asking this question.
CBOR has a somewhat evolved view of the tag namespace (number space), and it may not be obvious.

On 21. Apr 2023, at 18:53, Tony Putman <Anthony.Putman@dyson.com> wrote:
> 
> Hi all,
>  I'm defining a data schema for purely internal use (no interoperability needed)

This is known as “famous last words” :-)
A lot of organizations have learned that they do need to connect their “private” net 10 IP addresses once they purchase or merge with other organizations.
I think the same applies to tag numbers, even more so because sharing data is more loosely coupled than sharing networks, and you may find a need to integrate your data with data from other sources that have tags “for purely internal use".

> and encoding it in CBOR. There are points where we may want to vary/extend the contents with new data, and I thought the natural way to do this would be to define different tags to hold the data. I expected to find a set of tag numbers defined in IANA for private use, but there don't appear to be any.

Indeed, because “private use” may be an illusion for the above reason.

(Note that we have a different kind of tags, for contextual use [1].  I’m not talking about those.)

[1]: https://www.ietf.org/archive/id/draft-bormann-cbor-notable-tags-07.html#name-enumerated-alternative-data

>  - Is this a misuse of tags?  And if so, what would be the more natural way to specify this?

You didn’t say much, but what you said leads me to believe that tags are a good way to address your requirement.

> - Is this a general problem that people face and would it be worth defining a set of private tags which are known to be context-sensitive and not interoperable?

Why share a set of (then not so) “private” tags when you can have your own, *actually* private ones?

My recommendation would be:

Make a good guess at how many tags you’ll need, and get a block of tags registered from the FCFS space for your needs.
(You don’t need to be overly large with that number because you can always go back for more.)
Call them Dyson-0 to Dyson-4711 if you want.

Run your own internal tag registry assigning your private meanings to your IANA-assigned private tags.
And, of course, once you are surprised by noticing that your “private” use is no longer really so private, update the IANA registry with some information about some of the tags (e.g., specifications) at your leisure.

We would like you to use the space from 65536 up (1+4 space) unless you need a humungous number (for which we have the 1+8 space).
There also is a limited FCFS space from 32768 to 65535 (in 1+2 space), but you don’t want to take an out-of-proportion chunk of those (and only if the size of the tag representation matters a lot for your application).

Today’s tag usage report:
range  used     %                 free                total
0 1+0    13 54.17                   11                   24
1 1+1    70 30.17                  162                  232
2 1+2   438  0.67                64842                65280
3 1+4 65284  0.00           4294836476           4294901760
4 1+8     2  0.00 18446744069414584318 18446744069414584320

(Remember that this reflects the first ~ 10 years of allocation, which also might ramp up a bit over time — this space needs to hold for many more decades.)

Grüße, Carsten