Re: [Cbor] extensible enumerations, ignoring unknown values in CDDL

[Carsten Bormann <[e-mail]>]

Hi Rohan,

CDDL does have an enum-like feature [1].

[1]: https://www.rfc-editor.org/rfc/rfc8610.html#section-2.2.2.2

> One of the enums we are using, "Disposition" should have a valid range from 0 to 255, but only the values from 0 to 8 have known values. The intent is that new values between 9 and 255 inclusive will be valid, and if unknown they will be treated as if they had the default disposition (render).
> enum Disposition {
>     unspecified = 0,
>     render = 1,
>     reaction = 2,
>     profile = 3,
>     inline = 4,
>     icon = 5,
>     attachment = 6,
>     session = 7,
>     preview = 8
> };

[1] has this example (abbreviated)

              terminal-color = &basecolors
              basecolors = (
                black: 0,  red: 1,  green: 2,  yellow: 3,
                blue: 4,  magenta: 5,  cyan: 6,  white: 7,
              )

This could be extended to include 8..255:

              terminal-color = &basecolors
              basecolors = (
                black: 0,  red: 1,  green: 2,  yellow: 3,
                blue: 4,  magenta: 5,  cyan: 6,  white: 7,
                reserved: 8..255
              )

Using the .feature mechanism, the validator could show that an extension was used:

              terminal-color = &basecolors
              basecolors = (
                black: 0,  red: 1,  green: 2,  yellow: 3,
                blue: 4,  magenta: 5,  cyan: 6,  white: 7,
                reserved: (8..255) .feature "extension"
              )

(Use a better name than “extension”.)

This works great for a single document that is designed to be extensible.
(It can also be done without using »&« by creating a simple choice.)

Now, the question is, how to enable further documents to write their own CDDL about the extensions they define.

This can be done with a socket [2]:

[2]: https://www.rfc-editor.org/rfc/rfc8610.html#section-3.9

terminal-color = $terminal-color / (0..255) .feature “extension"
$terminal-color /= &basecolors
basecolors = (
                black: 0,  red: 1,  green: 2,  yellow: 3,
                blue: 4,  magenta: 5,  cyan: 6,  white: 7,
              )

The extending spec then says:

pastelcolors = ( pink: 9, mauve: 10, peach: 11, lavender: 12 )
$terminal-color /= &pastelcolors

Note how the prioritized choice semantics of CDDL [3] make sure that, with these rules added, lavender is always matched for 12 instead of any extension feature.  Prioritized choice is also the reason why the example puts its catch-all 0..255 not as part of the socket, but adds it as a choice with a lower priority than the socket.

[3]: https://www.rfc-editor.org/rfc/rfc8610.html#appendix-A

I should probably mention that another CDDL mechanism that can come in handy for structural extensibility is .within [4]; I don’t think we’d need it here.

[4]: https://www.rfc-editor.org/rfc/rfc8610.html#section-3.8.5

Grüße, Carsten