Subject: [Cbor] cbor key allocations and IANA

From: Michael Richardson <[email-masked]>
Date: Thu, 10 May 2018 14:45:02 -0400

I'm about to write an IANA Considerations section for a document that says
essentially:

  *) that the 1-byte positive and negative integers may be allocated by IETF
     Standards action.
  *) that the 2-byte, 3-byte and 4-byte positive integers may be allocated by IANA
    First Come First Served (https://tools.ietf.org/html/rfc8126#section-4.4)
  *) that the 2-byte, 3-byte and 4-byte negative integers be reserved for as
    an experimental range.

The exact details of the could be adjusted slightly.  It seems that this kind
of pattern will be frequently repeated, and so I wonder if a document should
be written that updates RFC8126 to create some "macro" statement about CBOR
key values taht would say something like that.

(Or maybe, the decision about 1-byte reserved, or 1-byte + 2-byte reserved is
a bike shed, and every single group will re-argue this, and trying to write
one or two things down is a waste of time)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Jim Schaad <[email-masked]>
Date: Thu, 10 May 2018 13:47:07 -0700

> -----Original Message-----
> From: CBOR <[email-masked]> On Behalf Of Michael Richardson
> Sent: Thursday, May 10, 2018 11:45 AM
> To: [email-masked]
> Subject: [Cbor] cbor key allocations and IANA
> 
> 
>   *) that the 2-byte, 3-byte and 4-byte positive integers may be allocated
by
> IANA
>     First Come First Served
(https://tools.ietf.org/html/rfc8126#section-4.4)
>   *) that the 2-byte, 3-byte and 4-byte negative integers be reserved for
as

The first bike shed is what you mean by 1-byte and 2-byte.  Are you talking
about the integer value or the encoded CBOR integer value.  

> 
> The exact details of the could be adjusted slightly.  It seems that this
kind of
> pattern will be frequently repeated, and so I wonder if a document should
> be written that updates RFC8126 to create some "macro" statement about
> CBOR key values taht would say something like that.

I guess one question is could this be done for IANA by reference.  "Use the
same assignment policy as this registry" which might make things easier.  I
know that both of the cases where I have been involved there has ended up
being some terminology discussions about what is really meant.  Pointing to
a extant registry and say use that policy might be easier.

Jim

> 
> (Or maybe, the decision about 1-byte reserved, or 1-byte + 2-byte reserved
> is a bike shed, and every single group will re-argue this, and trying to
write

---

From: Mike Jones <[email-masked]>
Date: Thu, 10 May 2018 20:47:33 +0000

The shiny new CBOR Web Token (CWT) RFC - RFC uses similar language and rules, which were heavily discussed and vetted both by the IESG and IANA.  I suggest that you copy them verbatim.

In particular, the "Claim Key" allocation rules at https://tools.ietf.org/html/rfc8392#section-9.1.1 are:

   Claim Key:
      CBOR map key for the claim.  Different ranges of values use
      different registration policies [RFC8126].  Integer values from
      -256 to 255 and strings of length 1 are designated as Standards
      Action.  Integer values from -65536 to -257 and from 256 to 65535
      along with strings of length 2 are designated as Specification
      Required.  Integer values greater than 65535 and strings of length
      greater than 2 are designated as Expert Review.  Integer values
      less than -65536 are marked as Private Use.

These are also based on and similar the allocation rules in COSE, such as those in https://tools.ietf.org/html/rfc8152#section-16.2 for labels and in https://tools.ietf.org/html/rfc8152#section-16.8 for values.  However, I would use the CWT language over the COSE language, as the IESG and IANA suggested several changes to the (already clear) language in COSE.

				Best wishes,
				-- Mike

-----Original Message-----
From: CBOR <[email-masked]> On Behalf Of Michael Richardson
Sent: Thursday, May 10, 2018 11:45 AM
To: [email-masked]
Subject: [Cbor] cbor key allocations and IANA

The exact details of the could be adjusted slightly.  It seems that this kind of pattern will be frequently repeated, and so I wonder if a document should be written that updates RFC8126 to create some "macro" statement about CBOR key values taht would say something like that.

(Or maybe, the decision about 1-byte reserved, or 1-byte + 2-byte reserved is a bike shed, and every single group will re-argue this, and trying to write one or two things down is a waste of time)

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 May 2018 17:12:35 -0400

> about the integer value or the encoded CBOR integer value.

okay, this is a good reason why I'd like to have standardized text :-)
I mean, integers that when encoded, fit into 1 byte.  So, -31 to +31.

    > same assignment policy as this registry" which might make things

Yes, we could use that way, except if that registry changed in some way.

Mike Jones <[email-masked]> wrote:
    > The shiny new CBOR Web Token (CWT) RFC - RFC uses similar language and
    > rules, which were heavily discussed and vetted both by the IESG and
    > IANA.  I suggest that you copy them verbatim.

Yes, so this could for the above suggestion by Jim be the registry to point
to.  Do I really want to make IANA think so much? I'd rather just give it a
name.

    > less than -65536 are marked as Private Use.

So I guess there is no special category from -31 to +31.
Probably that's okay as we allocate those first and we are careful about
them.  I will do what you suggest and use your text for now.

Do you think I should say, "like the Claim Key"?
I think it's sufficiently well written that I'd still like to have an IANA
"macro" that indicates this.

    > These are also based on and similar the allocation rules in COSE, such
    > as those in https://tools.ietf.org/html/rfc8152#section-16.2 for labels
    > and in https://tools.ietf.org/html/rfc8152#section-16.8 for values.
    > However, I would use the CWT language over the COSE language, as the
    > IESG and IANA suggested several changes to the (already clear) language
    > in COSE.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Thiago Macieira <[email-masked]>
Date: Thu, 10 May 2018 14:25:31 -0700

On Thursday, 10 May 2018 14:12:35 PDT Michael Richardson wrote:
> okay, this is a good reason why I'd like to have standardized text 

Which is why you shouldn't write that, because it's -24 to +23.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 May 2018 10:59:29 -0400

> Which is why you shouldn't write that, because it's -24 to +23.

See, it's good to have a well-reviewed set of text to point to :-)