Re: [Cbor] CBOR tag range IANA allocation policy

Carsten Bormann <cabo@tzi.org> Fri, 26 July 2019 01:58 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 25E87120295 for <cbor@ietfa.amsl.com>; Thu, 25 Jul 2019 18:58:02 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 bkeG6FqYTztd for <cbor@ietfa.amsl.com>; Thu, 25 Jul 2019 18:58:00 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B3D1202B3 for <cbor@ietf.org>; Thu, 25 Jul 2019 18:57:59 -0700 (PDT)
Received: from client-0001.vpn.uni-bremen.de (client-0001.vpn.uni-bremen.de [134.102.107.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45vsfs485zzyvb; Fri, 26 Jul 2019 03:57:57 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <15044986.HgQyyibD5o@tjmaciei-mobl1>
Date: Thu, 25 Jul 2019 21:57:55 -0400
Cc: cbor@ietf.org
X-Mao-Original-Outgoing-Id: 585799073.9781801-1c038b4b868527043a937fa5210fbd71
Content-Transfer-Encoding: quoted-printable
Message-Id: <D4FEEED2-02CD-4EDD-8781-820897623026@tzi.org>
References: <07D48905-77B6-447B-8CEB-971CD0568FB9@seantek.com> <584C141B-9704-4BA2-BD30-21E2FE4D6F90@seantek.com> <1A8A7E20-A92C-4242-92EB-950CD1F93B27@tzi.org> <15044986.HgQyyibD5o@tjmaciei-mobl1>
To: Thiago Macieira <thiago.macieira@intel.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/OoD-IxzCLn2N6l6_XurU4qtrpos>
Subject: Re: [Cbor] CBOR tag range IANA allocation policy
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: Fri, 26 Jul 2019 01:58:06 -0000

Hi Thiago,

there was a bit of a logjam as the old charter of CBOR WG limited us to two specific tags documents specified in the charter.  Rechartering is imminent, and I’d sure like the WG to look at your documents.  Maybe I can help you a bit to progress them to RFC, or maybe we want to work together on a slightly wider “common tags” document.  Let’s talk about that after the IETF.

Grüße, Carsten

PS.: RFC 8610 has been published last month and the data definition language is now called Concise Data Definition Language (CDDL); after all, it also covers JSON, and implicitly most of YAML, TOML, etc.


> On Jul 25, 2019, at 20:06, Thiago Macieira <thiago.macieira@intel.com>; wrote:
> 
> On Thursday, 25 July 2019 15:25:23 PDT Carsten Bormann wrote:
>> On Jul 25, 2019, at 18:19, Sean Leonard <dev+ietf@seantek.com>; wrote:
>>> 24-255 = RFC Required
>> 
>> I like that.
>> (That includes the independent stream.  But there is a level of quality
>> checking in publishing an RFC, so only high quality specifications will get
>> these.  Of course, the designated expert *could* do the same quality
>> checking, but there may be a slightly higher tendency to just give in among
>> us weaker DEs.)
> 
> The problem is less the quality checking and more the time required to write 
> an RFC, with the overhead required of it.
> 
> For example, I am sitting on a bunch of simple types I wanted to recommend, 
> but never had the time to review, much less write RFCs for.
> 
> https://gitlab.com/thiagomacieira/qtbase/blob/master/src/corelib/
> serialization/cbor-tags-geometry.rst
> https://gitlab.com/thiagomacieira/qtbase/blob/master/src/corelib/
> serialization/cbor-tag-bitarray.rst
> 
> As you can see from the tag numbers, I wrote them a while ago but never told 
> anyone about them. I find that those are generically useful types that 
> probably should exist in the 32-255 range, but I'd like the community to agree 
> with me.
> 
> And if we conclude that the range is correct, then I probably won't find the 
> time. Nor do I think that an RFC is required to define a couple of tags for 2D 
> and 3D geometry types.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel System Software Products
> 
> 
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
>