Re: [Cbor] Private tag numbers
Anders Rundgren <anders.rundgren.net@gmail.com> Sat, 22 April 2023 09:06 UTC
Return-Path: <anders.rundgren.net@gmail.com>
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 B1C9EC152DA6 for <cbor@ietfa.amsl.com>; Sat, 22 Apr 2023 02:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 lhw_zYFhdaFo for <cbor@ietfa.amsl.com>; Sat, 22 Apr 2023 02:06:41 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 3E55EC152DA4 for <cbor@ietf.org>; Sat, 22 Apr 2023 02:06:41 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-2fbb99cb297so2359587f8f.1 for <cbor@ietf.org>; Sat, 22 Apr 2023 02:06:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682154400; x=1684746400; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=OfCuQS+RpxvxHrM/xG38PH3q6Chx2Qb9sXTshDbfFr4=; b=f1JtCpb88EvoHdxL+1bjXeuF2V2ZGid6FJOyDJ9gv+8OCjMfzc/yK7sUKh2d5Sp64h CCgC0z1nqNJWyIk2v1/1jAZvCpFeaQ6cIF2y2PgXZDeHwP84qIvcI08mLOqO8EF45C/D 7Uk+jr7CIZ13kKdeDOymIr7pGkx+wLmNw4JrEV0L6gVKRFfE95CnUUMU18JkYlXKtIZN WkUf9/giB5pidJpmZA3t0cliwEIpUZMpUgZAPX3dd7g6RH02lDQOveilnVyn2h8K32ul 6xiL5ik5DikK6GHDmI3gBdFuMgOD8aD308zkZuiVL54u2kDpjNw9EtqhuJ0SWsKz/rFV o7OA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682154400; x=1684746400; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OfCuQS+RpxvxHrM/xG38PH3q6Chx2Qb9sXTshDbfFr4=; b=Z3kmIrkNkM8+LhmWaQVNlJ42FYk444mVJsNqSOq2oHqdYkwV+7/xgrVUGVAfrUJXKl W3+uh7mLROjW6Im4u4Uh+ZroKtzzwF7sagVjDpd7vAutNLG67qzz0HlgAxNb0xNL7KSh 0Cz+XBX6Inwou9Z2ZjC7BTQFORRU7FEeaVPUb/zCr33gnQm0DkdtC+XjBjBxO3dm017r +FQ4iz49LBfEYvVnxBDLePkiBVzyYUTYVBlw7HIQbM+GT2nHbbzFgRqM8SWk7rzrinwo AK1k++X6bW0nkFwcH9ILjkS9tsBb4Sjhj2NceUbpI7Gbl8/bCSZluDvE0mPQ+h5zLF0k Cfmw==
X-Gm-Message-State: AAQBX9e8qXAX24lK2Cjc7O2HtV1V19yP3IGqFoAPx8REFkaR11dkQ+gk r08RV9bH4m32USrP+cBNt+6zbhS46p4=
X-Google-Smtp-Source: AKy350Z+ba7OhAmMxdehig4t6FEVYR0zLRweyDy3sTrzWYp1mwWxWQSa15B7nKl6LAq2Mpe8hc8rOg==
X-Received: by 2002:adf:efca:0:b0:2f5:5538:2589 with SMTP id i10-20020adfefca000000b002f555382589mr5925624wrp.31.1682154399598; Sat, 22 Apr 2023 02:06:39 -0700 (PDT)
Received: from ?IPV6:2a01:e34:ec4e:5670:2143:ff7b:5d6f:d97c? ([2a01:e34:ec4e:5670:2143:ff7b:5d6f:d97c]) by smtp.googlemail.com with ESMTPSA id d14-20020a5d538e000000b002efac42ff35sm6170160wrv.37.2023.04.22.02.06.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Apr 2023 02:06:39 -0700 (PDT)
Message-ID: <f27e5b19-c263-7c1b-9627-b3f05d6a33ab@gmail.com>
Date: Sat, 22 Apr 2023 11:06:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: Tony Putman <Anthony.Putman@dyson.com>, "cbor@ietf.org" <cbor@ietf.org>
References: <AS2PR09MB6342AB1E5DFF19EDFB65F25F8C609@AS2PR09MB6342.eurprd09.prod.outlook.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
In-Reply-To: <AS2PR09MB6342AB1E5DFF19EDFB65F25F8C609@AS2PR09MB6342.eurprd09.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/aM-SYjCeScbypzgdZFSnXDga4jw>
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 09:06:44 -0000
On 2023-04-21 18:53, Tony Putman wrote:
> Hi all,
>
> I'm defining a data schema for purely internal use (no interoperability needed) 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.
>
> - Is this a misuse of tags? And if so, what would be the more natural way to specify this?
>
> - 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?
>
Hi Tony,
Personally I find the tag system less useful if you have a large bunch of ever changing objects. Obviously reusing tag numbers for revised objects isn't a good idea.
One way to address this issue would be to register a *single* master tag, and then use locally defined sub-tags to specify the actual object id:
78564([2, {
"hi": "there"
}])
Where 78564 would be your master (registered) tag, and 2 the locally defined id. The overhead in the sample is just two bytes compared to specifying a unique tag for each object.
If saving bytes is not your main concern, you may find a concept borrowed from the XML world useful:
https://www.ietf.org/archive/id/draft-rundgren-cotx-04.html
With public repositories like GitHub, anybody can enjoy a robust and project specific namespace.
Example: https://fido-web-pay.github.io/specification/crypto.html#5
Anders
> Thoughts/comments on this will be gratefully received.
>
> Tony
>
>
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
- Re: [Cbor] [EXTERNAL EMAIL] Re: Private tag numbe… Tony Putman
- Re: [Cbor] Private tag numbers Carsten Bormann
- [Cbor] Private tag numbers Tony Putman
- Re: [Cbor] Private tag numbers Vadim Goncharov
- Re: [Cbor] Private tag numbers Anders Rundgren
- Re: [Cbor] Private tag numbers Carsten Bormann
- Re: [Cbor] Private tag numbers Anders Rundgren
- [Cbor] Re: Private tag numbers / 1010 Vadim Goncharov
- Re: [Cbor] [EXTERNAL EMAIL] Re: Private tag numbe… Tony Putman
- [Cbor] Re: Private tag numbers / 1010 Anders Rundgren
- [Cbor] Re: Private tag numbers / 1010 Carsten Bormann
- [Cbor] Re: Private tag numbers / 1010 Anders Rundgren
- [Cbor] Re: Private tag numbers / 1010 Carsten Bormann
- [Cbor] Re: Private tag numbers / 1010 Anders Rundgren
- Re: [Cbor] [EXTERNAL EMAIL] Re: Private tag numbe… Carsten Bormann
- [Cbor] Re: Private tag numbers / 1010 Vadim Goncharov
- [Cbor] Re: Private tag numbers / 1010 Carsten Bormann
- [Cbor] Re: Private tag numbers / 1010 Vadim Goncharov
- Re: [Cbor] Private tag numbers Anders Rundgren