[Cbor] Simple values in CDDL (draft-ietf-cbor-update-8610-grammar)

[Carsten Bormann <[e-mail]>]

I just wanted to write a test for simple values in the cddl tool and noticed that we are missing something here.

In the prelude, we say:

                  float16 = #7.25
                  float32 = #7.26
                  float64 = #7.27

                  false = #7.20
                  true = #7.21
                  nil = #7.22
                  undefined = #7.23

This works fine: #7.0 to #7.23 are simple values, and #7.25/26/27 are floating point values.  The number after the dot (I’ll call it the additional number) is an ai (additional information) as for other major types except 6.

However, what we are missing is a way to specify simple values 32 to 255.  We haven’t registered one of these yet, so nobody needed this, which led to the situation that nobody noticed the omission in practice.

I propose to fill this in by enabling the notation #7.32 to #7.255; this is similar to how the number behind the dot works in #6.
I have implemented this in the cddl tool in 0.10.7, in case you want to play with this (gem update cddl).

This whole thing is a bit weird: In #0..#5, the additional number always is an ai, and in #6 it is always the argument.  With #7, the difference does not matter for 0 to 23, *needs* to be ai for at least 25 to 27 (I’d make that 24 to 31), and is an argument for 32 to 255.

Luckily, we punched a hole into simple values from 24 to 31 in Section 3.3 of RFC 8949 (beyond 0..23, we say “(To minimize confusion, only the values 32 to 255 are used.)”), so this back-and-forth jumping actually works.

It *is* weird, but then the whole #N construct is a bit weird (and the exception we already have for #6 already is not much less bad than the new one would be for #7); the whole thing is normally hidden in the prelude except for registered values (tag numbers and simple values), which would now look the same for #6 and #7.

In draft-ietf-cbor-update-8610-grammar, we don’t need to change the ABNF grammar, just to add a sentence that explains the way the number is interpreted for #7.

Unless we want to allow something like

simple-packed-reference-value = 0..15
simple-packed-reference = #7.<simple-packed-reference>

like we now do for #6 (“non-literal tag numbers”); then we need to add something like

      / "#” "7" ["." simple-number]

to type2 and add

simple-number = uint / ("<" type ">")

(or merge this rule with tag-number, which looks the same).

Do we want to allow #7.<type>?

Grüße, Carsten