Re: [Cbor] cbor key allocations and IANA

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 10 May 2018 21:12 UTC

From: Michael Richardson <mcr+ietf@sandelman.ca>
To: cbor@ietf.org
In-Reply-To: <00f001d3e8a0$115c4f30$3414ed90$@augustcellars.com>
References: <13362.1525977902@localhost> <00f001d3e8a0$115c4f30$3414ed90$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Thu, 10 May 2018 17:12:35 -0400
Message-ID: <29933.1525986755@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/YwKdijvUxsEELmc3cnQQYmA6At4>
Subject: Re: [Cbor] cbor key allocations and IANA
Precedence: list

Jim Schaad <ietf@augustcellars.com> wrote:
    >> 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 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.

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.

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

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

Mike Jones <Michael.Jones@microsoft.com> 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.

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

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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

Attachment: signature.asc

[Cbor] cbor key allocations and IANA Michael Richardson
Re: [Cbor] cbor key allocations and IANA Jim Schaad
Re: [Cbor] cbor key allocations and IANA Mike Jones
Re: [Cbor] cbor key allocations and IANA Michael Richardson
Re: [Cbor] cbor key allocations and IANA Thiago Macieira
Re: [Cbor] cbor key allocations and IANA Michael Richardson

Re: [Cbor] cbor key allocations and IANA

Attachment: signature.asc