[Cbor] Donation of short arcs 1.3.179.x Re: Prefix compression (Re: Review draft-bormann-cbor-tags-oid-07)

Sean Leonard <dev+ietf@seantek.com> Mon, 27 July 2020 14:49 UTC

Return-Path: <dev+ietf@seantek.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 ED7123A1A38 for <cbor@ietfa.amsl.com>; Mon, 27 Jul 2020 07:49:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mxes.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKuorU9TwfDR for <cbor@ietfa.amsl.com>; Mon, 27 Jul 2020 07:49:42 -0700 (PDT)
Received: from smtp-out-3.mxes.net (smtp-out-3.mxes.net [198.205.123.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C724F3A1BD3 for <cbor@ietf.org>; Mon, 27 Jul 2020 07:45:03 -0700 (PDT)
Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D365275968 for <cbor@ietf.org>; Mon, 27 Jul 2020 10:44:59 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mxes.net; s=mta; t=1595861102; bh=QsPqH3nV1E7DGHs8vnEi9aKNeIML7+uuDRDB3vq7MD4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=rONAqOMS/d1ztZSXYYMEgfG7BhvS1A8pLjau2hCpA1FD+mC7Zqoxhb5MCm5Vo+hmm 9J5VPGiXjeKQhnOSHUC+IaVGik/FRsVggvMl0cOIBxixVkUmFOlD/tloZ2BW6XsqTV uZMkU5lENomfiWEfp6ZsOVLP7M2+x9vzULx2JW0U=
To: cbor@ietf.org
References: <000801d65169$5915dfb0$0b419f10$@augustcellars.com> <5E9374BB-8893-4CB5-9548-672BC9556E55@tzi.org> <001701d651a5$ef08e6c0$cd1ab440$@augustcellars.com> <BF32663C-5B66-4DC7-ABF7-35FE47581DB8@tzi.org>
From: Sean Leonard <dev+ietf@seantek.com>
Message-ID: <bd10300e-0fe6-f784-3af2-0a5e5dcdb70c@seantek.com>
Date: Mon, 27 Jul 2020 07:43:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <BF32663C-5B66-4DC7-ABF7-35FE47581DB8@tzi.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Sent-To: <Y2JvckBpZXRmLm9yZw==>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/td8ax3GY1b-CdHvKTApwpWEYDs0>
Subject: [Cbor] Donation of short arcs 1.3.179.x Re: Prefix compression (Re: Review draft-bormann-cbor-tags-oid-07)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 27 Jul 2020 14:49:47 -0000

On 7/4/2020 4:48 AM, Carsten Bormann wrote:
> Hi Jim,
>
> On 2020-07-04, at 03:53, Jim Schaad <ietf@augustcellars.com> wrote:
>> An array of two hash functions which could be parsed into the two rooted OID values
> Prefix compression is applicable to other data than OIDs (most prominently URIs).
> I think we should handle that in a more generic way than specifically for OIDs.

I control a very short OID arc, 1.3.179 {iso(1) 
identified-organization(3) penango(179)} and would be happy to donate a 
block of 16 one-byte identifiers for CBOR/CBOR working group (or IETF) 
use. The binary encoding of this prefix is h'2B8133'.

If I assign the block of 96-111 to CBOR (h'60' through h'6F'), then that 
yields four bytes, 2048 unique numbers that are just five bytes long and 
16 unique numbers that are four bytes long as a bonus. I could probably 
donate 32 one-byte identifiers without losing sleep over it.

OIDs are just a way to generate globally unique, language-agnostic 
identifiers. A unique identifier that is five bytes long is clearly 
superior to a web URI (which depends on perpetual domain name 
registration) or even a UUID (fixed 16 bytes long), and obviates any 
need for compression. I think the reason why OIDs get such a bad wrap is 
because they are unnecessarily long when politics are laid over them, 
like 1.3.6.1.4.1.9.9.179.1.3.3.1.13. If you want a short and globally 
unique one, you can't get better than OIDs.

Notably, I am not the only one to figure out how to get a short OID: 
looks like Amazon picked up #187 in 2015: 
<http://oid-info.com/get/1.3.187>. If you can convince anybody who has 
registered OIDs 1-127 to slice off a piece of their namespace, you can 
make them one byte shorter. And I just discovered that IANA itself has a 
registration under 1.3.90: <http://oid-info.com/get/1.3.90> which is 
h'2B5A'--just two bytes! I'm surprised that nobody has made use of it.

While there are a lot of approaches to prefix compression, this assures 
that you can use OIDs instead of other identifiers in CBOR for *globally 
unique* identifiers. It has another modern advantage in that 
www.oid-info.com is a publicly accessible wiki-style list of all the 
OIDs ever minted, so you can write a tool to retrieve the human-readable 
meaning of any OID with a simple HTTP GET request.

Sean