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

[Rohan Mahy <[e-mail]>]

Thanks Carsten,
How about the following:

disposition = ( std_dispos // $$ext_dispos // unknown_dispos )

std-dispos = &(
    unspecified: 0,
    render: 1,
    reaction: 2,
    profile: 3,
    inline: 4,
    icon: 5,
    attachment: 6,
    session: 7,
    preview: 8
)
unknown_dispos = &( unknown: 8..255 ) ; Note: any ext_dispos take precedence

Then later document 1 could add

$$ext_dispos //= &(
    background: 9,
    mood: 10
)

And later document 2 could add

$$ext_dispos //= &(
    playlist: 11,
    game: 10
)

Did I get the syntax and precedence correct?

Cheers,
-rohan

On Sun, Apr 14, 2024 at 1:23 AM Carsten Bormann <[e-mail]> wrote:

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