Subject: [Cbor] CBOR tag range IANA allocation policy

From: Sean Leonard <[email-masked]>
Date: Thu, 25 Jul 2019 16:38:41 -0400

Hi WG, what is the current stance on changing the IANA Considerations for tag registration?

I find the RFC 7049 tag registration scheme (0-31 = standards action, 32-255 = specification required, 256+ = FCFS) to be acceptable.

However, I think that maybe we want to encourage more tag registration, while also having a bigger space for more review and publication. I read the minutes and am not sure if there is a current stance or a group sense on the matter, at least within the past 12 months.

Thanks,

Sean

---

From: Thiago Macieira <[email-masked]>
Date: Thu, 25 Jul 2019 14:19:47 -0700

On Thursday, 25 July 2019 13:38:41 PDT Sean Leonard wrote:
> I find the RFC 7049 tag registration scheme (0-31 = standards action, 32-255
> = specification required, 256+ = FCFS) to be acceptable.
> 
> However, I think that maybe we want to encourage more tag registration,
> while also having a bigger space for more review and publication. I read
> the minutes and am not sure if there is a current stance or a group sense
> on the matter, at least within the past 12 months.

Could we get 32-255 to be slightly stricter but not to the level of standards 
action? I was thinking of publication of a draft to this WG and allow for a 2-
week comment period. This could both spur ideas from other passive watchers 
and ensure high quality of the ones that do get published.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products

---

From: Ira McDonald <[email-masked]>
Date: Thu, 25 Jul 2019 17:25:48 -0400

Hi,

(possibly putting foot in mouth)

I think it's a bad practice to lower a previous IANA requirement for any
number
range in a registry (especially from specification required to one instance
of
Internet-Draft and two weeks of silent approval).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, Jul 25, 2019 at 5:19 PM Thiago Macieira <[email-masked]>
wrote:

> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Sean Leonard <[email-masked]>
Date: Thu, 25 Jul 2019 18:19:09 -0400

Okay so it sounds like there are more than crickets on the topic, so we can discuss it…

My intuition is as follows:

0-23 = standards action = no change
24-255 = RFC Required
256-65535 OR 256-32767 = specification required
65536+ OR 32767+ = FCFS = no change

This was my intuition based on tags being proposed, and the relative value of smaller tag numbers. However, I would want to make it more rigorous than just a feeling.

RFC 8126 “Guidelines for Writing an IANA Considerations Section in RFCs” defines the levels of review. RFC Required is one notch higher than Specification Required. Hence it is the smallest incremental bump. It would provide no difference in outcome to *most* stuff in 32-255 at present, but I checked and there are about 10 allocations in 24-255 (including about 5 in the low range, 24-29) that would have been excluded because the specs are not RFCs. The space 32-255 is already nearly half exhausted.

Specification required should be in place for the 1+2 byte range, since, well, we want public specs. In my mind, it is hard to justify restricting anything in the 1+4 byte space (32 bits) since they have equal performance characteristics.

There has been a good amount of discussion about constrained CBOR platforms that do not natively do 64-bit integers. However, is it fair to say that even the most resource-constrained devices these days are 32-bit capable without a lot of hassle?

Splitting the baby in half at the 16th bit allows half of the space to have more review, while the upper half can still be FCFS and get the same performance. “32,768 numbers is enough for everybody!” — or is it?

I wonder if we should bump 256-4095 or so to a higher level of review than specification required. It still leaves 28,000 values that have the same performance characteristics.

Sean

> On Jul 25, 2019, at 5:25 PM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> I think it's a bad practice to lower a previous IANA requirement for any number
> range in a registry (especially from specification required to one instance of
> http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: [email-masked] <mailto:[email-masked]>
> On Thu, Jul 25, 2019 at 5:19 PM Thiago Macieira <[email-masked] <mailto:[email-masked]>> wrote:
> Thiago Macieira - thiago.macieira (AT) intel.com <http://intel.com/>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cbor <https://www.ietf.org/mailman/listinfo/cbor>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Jul 2019 18:25:23 -0400

> 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.)

Grüße, Carsten

---

From: Thiago Macieira <[email-masked]>
Date: Thu, 25 Jul 2019 17:06:21 -0700

On Thursday, 25 July 2019 15:25:23 PDT Carsten Bormann wrote:
> (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.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Jul 2019 21:57:55 -0400

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 <[email-masked]> wrote:
>

---

From: Jim Schaad <[email-masked]>
Date: Fri, 26 Jul 2019 08:21:53 -0400

I think that RFC Required might be overkill.  As this is a specification required, there is already a requirement for Expert Review as well.  The easier thing might be to add language to the reviewer instructions along the lines of:

Reviewers should be reluctant to assign code points in the 24-255 range to specifications that are not RFC documents.  In the event that it is deemed wise to assign such a point anyway the CBOR working group mailing list should be advised of this and allowed to give input over a short period of time (in the order of 3-5 days).

Jim

-----Original Message-----
From: CBOR <[email-masked]> On Behalf Of Carsten Bormann
Sent: Thursday, July 25, 2019 6:25 PM
To: Sean Leonard <[email-masked]>
Cc: Thiago Macieira <[email-masked]>; Ira McDonald <[email-masked]>; [email-masked]
Subject: Re: [Cbor] CBOR tag range IANA allocation policy

I like that.

Grüße, Carsten