Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9165.¶

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1.Introduction

The Concise Data Definition Language (CDDL), standardized in[RFC8610],provides "control operators" as its main language extension point(Section 3.8 of [RFC8610]).¶

The present document defines a number of control operators that werenot yet ready at the time[RFC8610] was completed:¶

2.Computed Literals

CDDL as defined in[RFC8610] does not have any mechanisms to computeliterals. To cover a large part of the use cases, this specification adds three controloperators:.plus for numeric addition,.cat for stringconcatenation, and.det for string concatenation with dedenting ofboth sides (target and controller).¶

For these operators, as with all control operators, targets andcontrollers are types. The resulting type is therefore formally afunction of the elements of the cross-product of the two types.Not all tools may be able to work with non-unique targets orcontrollers.¶

interval<BASE> = (  BASE => int             ; lower bound  (BASE .plus 1) => int   ; upper bound  ? (BASE .plus 2) => int ; tolerance)X = 0Y = 3rect = {  interval<X>  interval<Y>}

c = "foo" .cat '  bar  baz'; on a system where the newline is \n, is the same string as:b = "foo\n  bar\n  baz\n"

oid = bytes .abnfb ("oid" .det cbor-tags-oid)roid = bytes .abnfb ("roid" .det cbor-tags-oid)cbor-tags-oid = '  oid = 1*arc  roid = *arc  arc = [nlsb] %x00-7f  nlsb = %x81-ff *%x80-ff'

oid = bytes .abnfb 'oidoid = 1*arcroid = *arcarc = [nlsb] %x00-7fnlsb = %x81-ff *%x80-ff'

3.Embedded ABNF

Many IETF protocols define allowable values for their text strings inABNF[RFC5234][RFC7405].It is often desirable to define a text string type in CDDL byemploying existing ABNF embedded into the CDDL specification.Without specific ABNF support in CDDL, that ABNF would usually need tobe translated into a regular expression (if that is even possible).¶

ABNF is added to CDDL in the same way that regularexpressions were added: by defining a.abnf control operator.The target is usuallytext or some restriction on it, and the controlleris the text of an ABNF specification.¶

There are several small issues; the solutions are given here:¶

• ABNF can be used to define byte sequences as well as UTF-8 textstrings interpreted as Unicode scalar sequences. This means thisspecification defines two control operators:.abnfb for ABNFdenoting byte sequences and.abnf for denoting sequences ofUnicode scalar values (code points) represented as UTF-8 text strings.Both control operators can be applied to targets of either stringtype; the ABNF is applied to the sequence of bytes in the stringand interprets it as a sequence of bytes (.abnfb) or as a sequenceof code points represented as an UTF-8 text string (.abnf). The controller stringMUST be a string. When a byte string, itMUST be valid UTF-8 and is interpreted as the text string that has the same sequence of bytes.¶
• ABNF defines a list of rules, not a single expression (called"elements" in[RFC5234]). This is resolved by requiring thecontroller string to be one valid "element", followed by zero ormore valid "rules" separated from the element by a newline; thus, thecontroller string can be built by preceding a pieceof valid ABNF by an "element" that selects from that ABNF and a newline.¶
• For the same reason, ABNF requires newlines; specifying newlines inCDDL text strings is tedious (and leads to essentially unreadableABNF). The workaround employs the.cat operator introduced inSection 2.2 and the syntax for text in byte strings.As is customary for ABNF, the syntax of ABNF itself (not the syntaxexpressed in ABNF!) is relaxed to allow a single line feed as anewline:¶

   CRLF = %x0A / %x0D.0A

• One set of rules provided in an ABNF specification is often used inmultiple positions, particularly staples such as DIGIT and ALPHA.(Note that all rules referenced need to be defined in each ABNFoperator controller string --there is no implicit import of core ABNF rules from[RFC5234] or other rules.)The composition this calls for can be provided by the.catoperator and/or by.det if there is indentation to be disposed of.¶

These points are combined into an example inFigure 5, which usesABNF from[RFC3339] to specify one of each of the Concise Binary Object Representation (CBOR) tags defined in[RFC8943] and[RFC8949].¶

; for RFC 8943Tag1004 = #6.1004(text .abnf full-date); for RFC 8949Tag0 = #6.0(text .abnf date-time)full-date = "full-date" .cat rfc3339date-time = "date-time" .cat rfc3339; Note the trick of idiomatically starting with a newline, separating;   off the element in the concatenations above from the rule-listrfc3339 = '   date-fullyear   = 4DIGIT   date-month      = 2DIGIT  ; 01-12   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on                             ; month/year   time-hour       = 2DIGIT  ; 00-23   time-minute     = 2DIGIT  ; 00-59   time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap sec                             ; rules   time-secfrac    = "." 1*DIGIT   time-numoffset  = ("+" / "-") time-hour ":" time-minute   time-offset     = "Z" / time-numoffset   partial-time    = time-hour ":" time-minute ":" time-second                     [time-secfrac]   full-date       = date-fullyear "-" date-month "-" date-mday   full-time       = partial-time time-offset   date-time       = full-date "T" full-time' .det rfc5234-corerfc5234-core = '   DIGIT          =  %x30-39 ; 0-9   ; abbreviated here'

4.Features

Commonly, the kind of validation enabled by languages such asCDDL provides a Boolean result: valid or invalid.¶

In rapidly evolving environments, this is too simplistic. The datamodels described by a CDDL specification may continually be enhancedby additional features, and it would be useful even for aspecification that does not yet describe a specific future feature toidentify the extension point the feature can use and accept suchextensions while marking them as extensions.¶

The.feature control annotates the target as making use of thefeature named by the controller. The latter will usually be a string.A tool that validates an instance against that specification may markthe instance as using a feature that is annotated by thespecification.¶

More specifically, the tool's diagnostic output might containthe controller (right-hand side) as a feature name and the target(left-hand side) as a feature detail. However, in some cases, the target hastoo much detail, and the specification might want to hint to the toolthat more limited detail is appropriate. In this case, the controllershould be an array, with the first element being the feature name(that would otherwise be the entire controller) and the secondelement being the detail (usually another string), as illustrated inFigure 6.¶

foo = {  kind: bar / baz .feature (["foo-extensions", "bazify"])}bar = ...baz = ... ; complex stuff that doesn't all need to be in the detail

Figure 7 shows what could be the definition of a person, withpotential extensions beyondname andorganization being markedfurther-person-extension.Extensions that are known at the time this definition is written can becollected into$$person-extensions. However, future extensionswould be deemed invalid unless the wildcard at the end of the map isadded.These extensions could then be specifically examined by a user or atool that makes use of the validation result; the label (map key)actually used makes a fine feature detail for the tool's diagnosticoutput.¶

Leaving out the entire extension point would mean that instances thatmake use of an extension would be marked as wholesale invalid, makingthe entire validation approach much less useful.Leaving the extension point in but not marking its use as specialwould render mistakes (such as using the label "organisation" instead of"organization") invisible.¶

person = {  ? name: text  ? organization: text  $$person-extensions  * (text .feature "further-person-extension") => any}$$person-extensions //= (? bloodgroup: text)

Figure 8 shows another example where.feature provides fortype extensibility.¶

allowed-types = number / text / bool / null              / [* number] / [* text] / [* bool]              / (any .feature "allowed-type-extension")

A CDDL tool may simply report the set of features being used; thecontrol then only provides information to the process requesting thevalidation.One could also imagine a tool that takes arguments, allowing the tool to acceptcertain features and reject others (enable/disable). The latter approachcould, for instance, be used for a JSON/CBOR switch, as illustrated inFigure 9, using Sensor Measurement Lists (SenML)[RFC8428] as the example data modelused with both JSON and CBOR.¶

SenML-Record = {; ...  ? v => number; ...}v = JC<"v", 2>JC<J,C> = J .feature "json" / C .feature "cbor"

It remains to be seen if the enable/disable approach can lead to newidioms of using CDDL. The language currently has no way to enforcemutually exclusive use of features, as would be needed in this example.¶

5.IANA Considerations

IANA has registered the contents ofTable 2 into the "CDDL Control Operators" registry of[IANA.cddl]:¶

6.Security Considerations

The security considerations of[RFC8610] apply.¶

While both[RFC5234] and[RFC7405] state that security is trulybelieved to be irrelevant to the respective document, the use offormal description techniques cannot only simplify but sometimes alsocomplicate a specification.This can lead to security problems in implementations and in thespecification itself.As with CDDL itself, ABNF should be judiciously applied, and overlycomplex (or "cute") constructions should be avoided.¶

Acknowledgements

Jim Schaad suggested several improvements.The.feature feature was developed out of a discussion withHenk Birkholz.Paul Kyzivat helped isolate the need for.det.¶

.det is an abbreviation for "dedenting cat", but Det is also the nameof a German TV cartoon character created in the 1960s.¶

Author's Address