More Control Operators for CDDL

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This specification uses terminology from [RFC8610]. In particular, with respect to control operators, "target" refers to the left-hand side operand, and "controller" to the right-hand side operand. "Tool" refers to tools along the lines of that described in Appendix F of [RFC8610]. Note also that the data model underlying CDDL provides for text strings as well as byte strings as two separate types, which are then collectively referred to as "strings".¶

2.1. Byte Strings: Base16 (Hex), Base32, Base64

A CDDL model often defines data that are byte strings in essence but need to be transported in various encoded forms, such as base64 or hex. This section defines a number of control operators to model these conversions.¶

The control operators generally are of a form that could be used like this:¶

signature-for-json = text .b64u signature
signature = bytes .cbor COSE_Sign1

The specification of these control operators is complicated by the large number of transformations in use. Inspired by Section 8 of [STD94], we use representations defined in [RFC4648] with the following names:¶

Note that this specification is somewhat opinionated here: It does not provide base64url, base32 or base32hex encoding with padding, or base64 classic without padding. Experience indicates that these combinations only ever occur in error, so the usability of CDDL is increased by not providing them in the first place. Also, adding "c" makes sure that any decision for classic base64 is actively taken.¶

The additional designation "sloppy" indicates that the text string is not validated for any additional bits being zero, in variance to what is specified in the paragraph behind table 1 in Section 4 of [RFC4648]. Note that the present specification is opinionated again in not specifying a sloppy variant of base32 or base32/hex, as no legacy use of sloppy base32(/hex) was known at the time of writing. Base45 is known to be suboptimal for use in environments with limited data transparency (such as URLs), but is included because of its close relationship to QR codes and its wide use in health informatics (note that base45 is at least strongly specified not to allow sloppy forms of encoding).¶

2.2. Numbers

This allows the modeling of text strings that carry numeric information, such as in the uint64/int64 formats of YANG-JSON [RFC7951].¶

yang-json-sid = text .decimal (0..9223372036854775807)

Again, the specification is opinionated by only providing numbers without leading zeros, i.e., the decimal numbers match the regular expression "0|-?[1-9][0-9]*" (of course, further restricted by the control type). Future specifications can provide octal, hexadecimal, or binary conversions.¶

2.3. JSON Values

Some applications store complete JSON texts into text strings, the JSON value for which can easily be defined in CDDL. This is supported by a control operator similar to .cbor in Section 3.8.4 of [RFC8610].¶

embedded-claims = text .json claims
claims = {iss: issuer, exp: expiry}

Note that a .jsonseq is not provided, as no use case is known yet. There is no way to constrain the use of blank space in data items to be validated; variants (e.g, not providing for any blank space) could be defined.¶

3.1. Join

Often, text strings need to be constructed out of parts that can best be modeled as an array.¶

In general, this control operator is hard to validate as it would require full parser functionality. It is therefore recommended to only use it in simple cases, and leave full parsing to ABNF Section 3 of [RFC9165] or similar.¶

legacy-ip-address = text .join [digits<1>, ".", digits<2>,
                           ".", digits<3>, ".", digits<4>]
digits<N> = text .decimal byte<n>