rfc9165.original   rfc9165.txt 
Network Working Group C. Bormann Internet Engineering Task Force (IETF) C. Bormann
Internet-Draft Universität Bremen TZI Request for Comments: 9165 Universität Bremen TZI
Intended status: Standards Track 22 October 2021 Category: Standards Track December 2021
Expires: 25 April 2022 ISSN: 2070-1721
Additional Control Operators for CDDL Additional Control Operators for the Concise Data Definition Language
draft-ietf-cbor-cddl-control-07 (CDDL)
Abstract Abstract
The Concise Data Definition Language (CDDL), standardized in RFC The Concise Data Definition Language (CDDL), standardized in RFC
8610, provides "control operators" as its main language extension 8610, provides "control operators" as its main language extension
point. point.
The present document defines a number of control operators that were The present document defines a number of control operators that were
not yet ready at the time RFC 8610 was completed: .plus, .cat and not yet ready at the time RFC 8610 was completed: .plus, .cat, and
.det for the construction of constants, .abnf/.abnfb for including .det for the construction of constants; .abnf/.abnfb for including
ABNF (RFC 5234/RFC 7405) in CDDL specifications, and .feature for ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and .feature for
indicating the use of a non-basic feature in an instance. indicating the use of a non-basic feature in an instance.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 25 April 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9165.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Simplified BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
2. Computed Literals . . . . . . . . . . . . . . . . . . . . . . 3 2. Computed Literals
2.1. Numeric Addition . . . . . . . . . . . . . . . . . . . . 4 2.1. Numeric Addition
2.2. String Concatenation . . . . . . . . . . . . . . . . . . 4 2.2. String Concatenation
2.3. String Concatenation with Dedenting . . . . . . . . . . . 5 2.3. String Concatenation with Dedenting
3. Embedded ABNF . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Embedded ABNF
4. Features . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Features
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations
7. Security considerations . . . . . . . . . . . . . . . . . . . 11 7. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 12 Acknowledgements
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Concise Data Definition Language (CDDL), standardized in The Concise Data Definition Language (CDDL), standardized in
[RFC8610], provides "control operators" as its main language [RFC8610], provides "control operators" as its main language
extension point (Section 3.8 of [RFC8610]). extension point (Section 3.8 of [RFC8610]).
The present document defines a number of control operators that were The present document defines a number of control operators that were
not yet ready at the time RFC 8610 was completed: not yet ready at the time [RFC8610] was completed:
+==========+=================================================+ +==========+==================================================+
| Name | Purpose | | Name | Purpose |
+==========+=================================================+ +==========+==================================================+
| .plus | Numeric addition | | .plus | Numeric addition |
+----------+-------------------------------------------------+ +----------+--------------------------------------------------+
| .cat | String Concatenation | | .cat | String concatenation |
+----------+-------------------------------------------------+ +----------+--------------------------------------------------+
| .det | String Concatenation, pre-dedenting | | .det | String concatenation, pre-dedenting |
+----------+-------------------------------------------------+ +----------+--------------------------------------------------+
| .abnf | ABNF in CDDL (text strings) | | .abnf | ABNF in CDDL (text strings) |
+----------+-------------------------------------------------+ +----------+--------------------------------------------------+
| .abnfb | ABNF in CDDL (byte strings) | | .abnfb | ABNF in CDDL (byte strings) |
+----------+-------------------------------------------------+ +----------+--------------------------------------------------+
| .feature | Indicate name of feature used (extension point) | | .feature | Indicates name of feature used (extension point) |
+----------+-------------------------------------------------+ +----------+--------------------------------------------------+
Table 1: New control operators in this document Table 1: New Control Operators in this Document
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification uses terminology from [RFC8610]. In particular, This specification uses terminology from [RFC8610]. In particular,
with respect to control operators, "target" refers to the left-hand with respect to control operators, "target" refers to the left-hand
side operand, and "controller" to the right-hand side operand. side operand and "controller" to the right-hand side operand. "Tool"
"Tool" refers to tools along the lines of that described in refers to tools along the lines of that described in Appendix F of
Appendix F of [RFC8610]. Note also that the data model underlying [RFC8610]. Note also that the data model underlying CDDL provides
CDDL provides for text strings as well as byte strings as two for text strings as well as byte strings as two separate types, which
separate types, which are then collectively referred to as "strings". are then collectively referred to as "strings".
The term ABNF in this specification stands for the combination of The term "ABNF" in this specification stands for the combination of
[RFC5234] and [RFC7405], i.e., the ABNF control operators defined by [RFC5234] and [RFC7405]; i.e., the ABNF control operators defined by
this document allow use of the case-sensitive extensions defined in this document allow use of the case-sensitive extensions defined in
[RFC7405]. [RFC7405].
2. Computed Literals 2. Computed Literals
CDDL as defined in [RFC8610] does not have any mechanisms to compute CDDL as defined in [RFC8610] does not have any mechanisms to compute
literals. To cover a large part of the use cases, this specification literals. To cover a large part of the use cases, this specification
adds three control operators: .plus for numeric addition, .cat for adds three control operators: .plus for numeric addition, .cat for
string concatenation, and .det for string concatenation with string concatenation, and .det for string concatenation with
dedenting of both sides (target and controller). dedenting of both sides (target and controller).
For these operators, as with all control operators, targets and For these operators, as with all control operators, targets and
controllers are types. The resulting type is therefore formally a controllers are types. The resulting type is therefore formally a
function of the elements of the cross-product of the two types. Not function of the elements of the cross-product of the two types. Not
all tools may be able to work with non-unique targets or controllers. all tools may be able to work with non-unique targets or controllers.
2.1. Numeric Addition 2.1. Numeric Addition
In many cases in a specification, numbers are needed relative to a In many cases, numbers are needed relative to a base number in a
base number. The .plus control identifies a number that is specification. The .plus control identifies a number that is
constructed by adding the numeric values of the target and of the constructed by adding the numeric values of the target and the
controller. controller.
Target and controller MUST be numeric. If the target is a floating The target and controller both MUST be numeric. If the target is a
point number and the controller an integer number, or vice versa, the floating point number and the controller an integer number, or vice
sum is converted into the type of the target; converting from a versa, the sum is converted into the type of the target; converting
floating point number to an integer selects its floor (the largest from a floating point number to an integer selects its floor (the
integer less than or equal to the floating point number, i.e., largest integer less than or equal to the floating point number,
rounding towards negative infinity). i.e., rounding towards negative infinity).
interval<BASE> = ( interval<BASE> = (
BASE => int ; lower bound BASE => int ; lower bound
(BASE .plus 1) => int ; upper bound (BASE .plus 1) => int ; upper bound
? (BASE .plus 2) => int ; tolerance ? (BASE .plus 2) => int ; tolerance
) )
X = 0 X = 0
Y = 3 Y = 3
rect = { rect = {
interval<X> interval<X>
interval<Y> interval<Y>
} }
Figure 1: Example: addition to a base value Figure 1: An Example of Addition to a Base Value
The example in Figure 1 contains the generic definition of a CDDL The example in Figure 1 contains the generic definition of a CDDL
group interval that gives a lower and an upper bound and optionally a group interval that gives a lower and upper bound and, optionally, a
tolerance. The parameter BASE allows the non-conflicting use of tolerance. The parameter BASE allows the non-conflicting use of a
multiple of these interval groups in one map, by assigning different multiple of these interval groups in one map by assigning different
labels to the entries of the interval. rect combines two of these labels to the entries of the interval. The rule rect combines two of
interval groups into a map, one group for the X dimension (using 0, these interval groups into a map, one group for the X dimension
1, and 2 as labels) and one for Y dimension (using 3, 4, and 5 as (using 0, 1, and 2 as labels) and one for the Y dimension (using 3,
labels). 4, and 5 as labels).
2.2. String Concatenation 2.2. String Concatenation
It is often useful to be able to compose string literals out of It is often useful to be able to compose string literals out of
component literals defined in different places in the specification. component literals defined in different places in the specification.
The .cat control identifies a string that is built from a The .cat control identifies a string that is built from a
concatenation of the target and the controller. Target and concatenation of the target and the controller. The target and
controller MUST be strings. The result of the operation has the type controller both MUST be strings. The result of the operation has the
of the target. The concatenation is performed on the bytes in both same type as the target. The concatenation is performed on the bytes
strings. If the target is a text string, the result of that in both strings. If the target is a text string, the result of that
concatenation MUST be valid UTF-8. concatenation MUST be valid UTF-8.
a = "foo" .cat ' c = "foo" .cat '
bar bar
baz baz
' '
; on a system where the newline is \n, is the same string as: ; on a system where the newline is \n, is the same string as:
b = "foo\n bar\n baz\n" b = "foo\n bar\n baz\n"
Figure 2: Example: concatenation of text and byte string Figure 2: An Example of Concatenation of Text and Byte Strings
The example in Figure 2 builds a text string named a out of The example in Figure 2 builds a text string named c from
concatenating the target text string "foo" and the controller byte concatenating the target text string "foo" and the controller byte
string entered in a text form byte string literal. (This particular string entered in a text form byte string literal. (This particular
idiom is useful when the text string contains newlines, which, as idiom is useful when the text string contains newlines, which, as
shown in the example for b, may be harder to read when entered in the shown in the example for b, may be harder to read when entered in the
format that the pure CDDL text string notation inherits from JSON.) format that the pure CDDL text string notation inherits from JSON.)
2.3. String Concatenation with Dedenting 2.3. String Concatenation with Dedenting
Multi-line string literals for various applications, including Multi-line string literals for various applications, including
embedded ABNF (Section 3), need to be set flush left, at least embedded ABNF (Section 3), need to be set flush left, at least
skipping to change at page 5, line 45 skipping to change at line 213
oid = bytes .abnfb ("oid" .det cbor-tags-oid) oid = bytes .abnfb ("oid" .det cbor-tags-oid)
roid = bytes .abnfb ("roid" .det cbor-tags-oid) roid = bytes .abnfb ("roid" .det cbor-tags-oid)
cbor-tags-oid = ' cbor-tags-oid = '
oid = 1*arc oid = 1*arc
roid = *arc roid = *arc
arc = [nlsb] %x00-7f arc = [nlsb] %x00-7f
nlsb = %x81-ff *%x80-ff nlsb = %x81-ff *%x80-ff
' '
Figure 3: Example: dedenting concatenation Figure 3: An Example of Dedenting Concatenation
The control operator .det works like .cat, except that both arguments The control operator .det works like .cat, except that both arguments
(target and controller) are independently _dedented_ before the (target and controller) are independently _dedented_ before the
concatenation takes place. concatenation takes place.
For the first rule in Figure 3, the result is equivalent to Figure 4. For the first rule in Figure 3, the result is equivalent to Figure 4.
oid = bytes .abnfb 'oid oid = bytes .abnfb 'oid
oid = 1*arc oid = 1*arc
roid = *arc roid = *arc
arc = [nlsb] %x00-7f arc = [nlsb] %x00-7f
nlsb = %x81-ff *%x80-ff nlsb = %x81-ff *%x80-ff
' '
Figure 4: Dedenting example: result of first .det Figure 4: Dedenting Example: Result of First .det
For the purposes of this specification, we define dedenting as: For the purposes of this specification, we define "dedenting" as:
1. determining the smallest amount of left-most blank space (number 1. determining the smallest amount of leftmost blank space (number
of leading space characters) present in all the non-blank lines, of leading space characters) present in all the non-blank lines,
and and
2. removing exactly that number of leading space characters from 2. removing exactly that number of leading space characters from
each line. For blank (blank space only or empty) lines, there each line. For blank (blank space only or empty) lines, there
may be less (or no) leading space characters than this amount, in may be fewer (or no) leading space characters than this amount,
which case all leading space is removed. in which case all leading space is removed.
(The name .det is a shortcut for "dedenting cat". The maybe more (The name .det is a shortcut for "dedenting cat". The maybe more
obvious name .dedcat has not been chosen as it is longer and may obvious name .dedcat has not been chosen as it is longer and may
invoke unpleasant images.) invoke unpleasant images.)
Occasionally, dedenting of only a single item is needed. This can be Occasionally, dedenting of only a single item is needed. This can be
achieved by using this operator with an empty string, e.g., "" .det achieved by using this operator with an empty string, e.g., "" .det
rhs or lhs .det "", which can in turn be combined with a .cat: in the rhs or lhs .det "", which can in turn be combined with a .cat: in the
construct lhs .cat ("" .det rhs), only rhs is dedented. construct lhs .cat ("" .det rhs), only rhs is dedented.
skipping to change at page 6, line 45 skipping to change at line 261
Many IETF protocols define allowable values for their text strings in Many IETF protocols define allowable values for their text strings in
ABNF [RFC5234] [RFC7405]. It is often desirable to define a text ABNF [RFC5234] [RFC7405]. It is often desirable to define a text
string type in CDDL by employing existing ABNF embedded into the CDDL string type in CDDL by employing existing ABNF embedded into the CDDL
specification. Without specific ABNF support in CDDL, that ABNF specification. Without specific ABNF support in CDDL, that ABNF
would usually need to be translated into a regular expression (if would usually need to be translated into a regular expression (if
that is even possible). that is even possible).
ABNF is added to CDDL in the same way that regular expressions were ABNF is added to CDDL in the same way that regular expressions were
added: by defining a .abnf control operator. The target is usually added: by defining a .abnf control operator. The target is usually
text or some restriction on it, the controller is the text of an ABNF text or some restriction on it, and the controller is the text of an
specification. ABNF specification.
There are several small issues, with solutions given here: There are several small issues; the solutions are given here:
* ABNF can be used to define byte sequences as well as UTF-8 text * ABNF can be used to define byte sequences as well as UTF-8 text
strings interpreted as Unicode scalar sequences. This means this strings interpreted as Unicode scalar sequences. This means this
specification defines two control operators: .abnfb for ABNF specification defines two control operators: .abnfb for ABNF
denoting byte sequences and .abnf for denoting sequences of denoting byte sequences and .abnf for denoting sequences of
Unicode scalar values (codepoint) represented as UTF-8 text Unicode scalar values (code points) represented as UTF-8 text
strings. Both control operators can be applied to targets of strings. Both control operators can be applied to targets of
either string type; the ABNF is applied to sequence of bytes in either string type; the ABNF is applied to the sequence of bytes
the string interpreting that as a sequence of bytes (.abnfb) or as in the string and interprets it as a sequence of bytes (.abnfb) or
a sequence of code points represented as an UTF-8 text string as a sequence of code points represented as an UTF-8 text string
(.abnf). The controller string MUST be a text string. (.abnf). The controller string MUST be a string. When a byte
string, it MUST 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 * ABNF defines a list of rules, not a single expression (called
"elements" in [RFC5234]). This is resolved by requiring the "elements" in [RFC5234]). This is resolved by requiring the
controller string to be one valid "element", followed by zero or controller string to be one valid "element", followed by zero or
more valid "rule" separated from the element by a newline; so the more valid "rules" separated from the element by a newline; thus,
controller string can be built by preceding a piece of valid ABNF the controller string can be built by preceding a piece of valid
by an "element" that selects from that ABNF and a newline. ABNF by an "element" that selects from that ABNF and a newline.
* For the same reason, ABNF requires newlines; specifying newlines * For the same reason, ABNF requires newlines; specifying newlines
in CDDL text strings is tedious (and leads to essentially in CDDL text strings is tedious (and leads to essentially
unreadable ABNF). The workaround employs the .cat operator unreadable ABNF). The workaround employs the .cat operator
introduced in Section 2.2 and the syntax for text in byte strings. introduced in Section 2.2 and the syntax for text in byte strings.
As is customary for ABNF, the syntax of ABNF itself (NOT the As is customary for ABNF, the syntax of ABNF itself (_not_ the
syntax expressed in ABNF!) is relaxed to allow a single linefeed syntax expressed in ABNF!) is relaxed to allow a single line feed
as a newline: as a newline:
CRLF = %x0A / %x0D.0A CRLF = %x0A / %x0D.0A
* One set of rules provided in an ABNF specification is often used * One set of rules provided in an ABNF specification is often used
in multiple positions, in particular staples such as DIGIT and in multiple positions, particularly staples such as DIGIT and
ALPHA. (Note that all rules referenced need to be defined in each ALPHA. (Note that all rules referenced need to be defined in each
ABNF operator controller string -- there is no implicit import of ABNF operator controller string -- there is no implicit import of
[RFC5234] Core ABNF or other rules.) The composition this calls core ABNF rules from [RFC5234] or other rules.) The composition
for can be provided by the .cat operator, and/or by .det if there this calls for can be provided by the .cat operator and/or by .det
is indentation to be disposed of. if there is indentation to be disposed of.
These points are combined into an example in Figure 5, which uses These points are combined into an example in Figure 5, which uses
ABNF from [RFC3339] to specify one each of the CBOR tags defined in ABNF from [RFC3339] to specify one of each of the Concise Binary
[RFC8943] and [RFC8949]. Object Representation (CBOR) tags defined in [RFC8943] and [RFC8949].
; for RFC 8943 ; for RFC 8943
Tag1004 = #6.1004(text .abnf full-date) Tag1004 = #6.1004(text .abnf full-date)
; for RFC 8949 ; for RFC 8949
Tag0 = #6.0(text .abnf date-time) Tag0 = #6.0(text .abnf date-time)
full-date = "full-date" .cat rfc3339 full-date = "full-date" .cat rfc3339
date-time = "date-time" .cat rfc3339 date-time = "date-time" .cat rfc3339
; Note the trick of idiomatically starting with a newline, separating ; Note the trick of idiomatically starting with a newline, separating
skipping to change at page 8, line 41 skipping to change at line 344
full-time = partial-time time-offset full-time = partial-time time-offset
date-time = full-date "T" full-time date-time = full-date "T" full-time
' .det rfc5234-core ' .det rfc5234-core
rfc5234-core = ' rfc5234-core = '
DIGIT = %x30-39 ; 0-9 DIGIT = %x30-39 ; 0-9
; abbreviated here ; abbreviated here
' '
Figure 5: Example: employing RFC 3339 ABNF for defining CBOR Tags Figure 5: An Example of Employing ABNF from RFC 3339 for Defining
CBOR Tags
4. Features 4. Features
Commonly, the kind of validation enabled by languages such as CDDL Commonly, the kind of validation enabled by languages such as CDDL
provides a Boolean result: valid, or invalid. provides a Boolean result: valid or invalid.
In rapidly evolving environments, this is too simplistic. The data In rapidly evolving environments, this is too simplistic. The data
models described by a CDDL specification may continually be enhanced models described by a CDDL specification may continually be enhanced
by additional features, and it would be useful even for a by additional features, and it would be useful even for a
specification that does not yet describe a specific future feature to specification that does not yet describe a specific future feature to
identify the extension point the feature can use, accepting such identify the extension point the feature can use and accept such
extensions while marking them as such. extensions while marking them as extensions.
The .feature control annotates the target as making use of the The .feature control annotates the target as making use of the
feature named by the controller. The latter will usually be a feature named by the controller. The latter will usually be a
string. A tool that validates an instance against that specification string. A tool that validates an instance against that specification
may mark the instance as using a feature that is annotated by the may mark the instance as using a feature that is annotated by the
specification. specification.
More specifically, the tool's diagnostic output might contain the More specifically, the tool's diagnostic output might contain the
controller (right-hand side) as a feature name, and the target (left- controller (right-hand side) as a feature name and the target (left-
hand side) as a feature detail. However, in some cases, the target hand side) as a feature detail. However, in some cases, the target
has too much detail, and the specification might want to hint the has too much detail, and the specification might want to hint to the
tool that more limited detail is appropriate. In this case, the tool that more limited detail is appropriate. In this case, the
controller should be an array, with the first element being the controller should be an array, with the first element being the
feature name (that would otherwise be the entire controller), and the feature name (that would otherwise be the entire controller) and the
second element being the detail (usually another string), as second element being the detail (usually another string), as
illustrated in Figure 6. illustrated in Figure 6.
foo = { foo = {
kind: bar / baz .feature (["foo-extensions", "bazify"]) kind: bar / baz .feature (["foo-extensions", "bazify"])
} }
bar = ... bar = ...
baz = ... ; complex stuff that doesn't all need to be in the detail baz = ... ; complex stuff that doesn't all need to be in the detail
Figure 6: Providing explicit detail with .feature Figure 6: Providing Explicit Detail with .feature
Figure 7 shows what could be the definition of a person, with Figure 7 shows what could be the definition of a person, with
potential extensions beyond name and organization being marked potential extensions beyond name and organization being marked
further-person-extension. Extensions that are known at the time this further-person-extension. Extensions that are known at the time this
definition is written can be collected into $$person-extensions. definition is written can be collected into $$person-extensions.
However, future extensions would be deemed invalid unless the However, future extensions would be deemed invalid unless the
wildcard at the end of the map is added. These extensions could then wildcard at the end of the map is added. These extensions could then
be specifically examined by a user or a tool that makes use of the be specifically examined by a user or a tool that makes use of the
validation result; the label (map key) actually used makes a fine validation result; the label (map key) actually used makes a fine
feature detail for the tool's diagnostic output. feature detail for the tool's diagnostic output.
Leaving out the entire extension point would mean that instances that Leaving out the entire extension point would mean that instances that
make use of an extension would be marked as whole-sale invalid, make use of an extension would be marked as wholesale invalid, making
making the entire validation approach much less useful. Leaving the the entire validation approach much less useful. Leaving the
extension point in, but not marking its use as special, would render extension point in but not marking its use as special would render
mistakes such as using the label "organisation" instead of mistakes (such as using the label "organisation" instead of
"organization" invisible. "organization") invisible.
person = { person = {
? name: text ? name: text
? organization: text ? organization: text
$$person-extensions $$person-extensions
* (text .feature "further-person-extension") => any * (text .feature "further-person-extension") => any
} }
$$person-extensions //= (? bloodgroup: text) $$person-extensions //= (? bloodgroup: text)
Figure 7: Map extensibility with .feature Figure 7: Map Extensibility with .feature
Figure 8 shows another example where .feature provides for type Figure 8 shows another example where .feature provides for type
extensibility. extensibility.
allowed-types = number / text / bool / null allowed-types = number / text / bool / null
/ [* number] / [* text] / [* bool] / [* number] / [* text] / [* bool]
/ (any .feature "allowed-type-extension") / (any .feature "allowed-type-extension")
Figure 8: Type extensibility with .feature Figure 8: Type Extensibility with .feature
A CDDL tool may simply report the set of features being used; the A CDDL tool may simply report the set of features being used; the
control then only provides information to the process requesting the control then only provides information to the process requesting the
validation. One could also imagine a tool that takes arguments validation. One could also imagine a tool that takes arguments,
allowing the tool to accept certain features and reject others allowing the tool to accept certain features and reject others
(enable/disable). The latter approach could for instance be used for (enable/disable). The latter approach could, for instance, be used
a JSON/CBOR switch, as illustrated in Figure 9, using SenML [RFC8428] for a JSON/CBOR switch, as illustrated in Figure 9, using Sensor
as the example data model used with both JSON and CBOR. Measurement Lists (SenML) [RFC8428] as the example data model used
with both JSON and CBOR.
SenML-Record = { SenML-Record = {
; ... ; ...
? v => number ? v => number
; ... ; ...
} }
v = JC<"v", 2> v = JC<"v", 2>
JC<J,C> = J .feature "json" / C .feature "cbor" JC<J,C> = J .feature "json" / C .feature "cbor"
Figure 9: Describing variants with .feature Figure 9: Describing Variants with .feature
It remains to be seen if the enable/disable approach can lead to new It remains to be seen if the enable/disable approach can lead to new
idioms of using CDDL. The language currently has no way to enforce idioms of using CDDL. The language currently has no way to enforce
mutually exclusive use of features, as would be needed in this mutually exclusive use of features, as would be needed in this
example. example.
5. IANA Considerations 5. IANA Considerations
This document requests IANA to register the contents of Table 2 into IANA has registered the contents of Table 2 into the "CDDL Control
the registry "CDDL Control Operators" of [IANA.cddl]: Operators" registry of [IANA.cddl]:
+==========+===========+ +==========+===========+
| Name | Reference | | Name | Reference |
+==========+===========+ +==========+===========+
| .plus | [RFCthis] | | .plus | RFC 9165 |
+----------+-----------+ +----------+-----------+
| .cat | [RFCthis] | | .cat | RFC 9165 |
+----------+-----------+ +----------+-----------+
| .det | [RFCthis] | | .det | RFC 9165 |
+----------+-----------+ +----------+-----------+
| .abnf | [RFCthis] | | .abnf | RFC 9165 |
+----------+-----------+ +----------+-----------+
| .abnfb | [RFCthis] | | .abnfb | RFC 9165 |
+----------+-----------+ +----------+-----------+
| .feature | [RFCthis] | | .feature | RFC 9165 |
+----------+-----------+ +----------+-----------+
Table 2: New control Table 2: New Control
operators to be Operators
registered
6. Implementation Status
This section is to be removed before publishing as an RFC.
An early implementation of the control operator .feature has been
available in the CDDL tool described in Appendix F of [RFC8610] since
version 0.8.11. The validator warns about each feature being used
and provides the set of target values used with the feature. The
other control operators defined in this specification are also
implemented as of version 0.8.21 and 0.8.26 (double-handed .det).
Andrew Weiss' [CDDL-RS] has an ongoing implementation of this draft
which is feature-complete except for the ABNF and dedenting support
(https://github.com/anweiss/cddl/pull/79
(https://github.com/anweiss/cddl/pull/79)).
7. Security considerations 6. Security Considerations
The security considerations of [RFC8610] apply. The security considerations of [RFC8610] apply.
While both [RFC5234] and [RFC7405] state that security is truly While both [RFC5234] and [RFC7405] state that security is truly
believed to be irrelevant to the respective document, the use of believed to be irrelevant to the respective document, the use of
formal description techniques cannot only simplify, but sometimes formal description techniques cannot only simplify but sometimes also
also complicate a specification. This can lead to security problems complicate a specification. This can lead to security problems in
in implementations and in the specification itself. As with CDDL implementations and in the specification itself. As with CDDL
itself, ABNF should be judiciously applied, and overly complex (or itself, ABNF should be judiciously applied, and overly complex (or
"cute") constructions should be avoided. "cute") constructions should be avoided.
8. References 7. References
8.1. Normative References 7.1. Normative References
[IANA.cddl] [IANA.cddl]
IANA, "Concise Data Definition Language (CDDL)", IANA, "Concise Data Definition Language (CDDL)",
<https://www.iana.org/assignments/cddl>. <https://www.iana.org/assignments/cddl>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 12, line 37 skipping to change at line 512
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
8.2. Informative References 7.2. Informative References
[CDDL-RS] Weiss, A., "cddl-rs", n.d.,
<https://github.com/anweiss/cddl>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,
DOI 10.17487/RFC8428, August 2018, DOI 10.17487/RFC8428, August 2018,
<https://www.rfc-editor.org/info/rfc8428>. <https://www.rfc-editor.org/info/rfc8428>.
skipping to change at page 13, line 22 skipping to change at line 540
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
Acknowledgements Acknowledgements
Jim Schaad suggested several improvements. The .feature feature was Jim Schaad suggested several improvements. The .feature feature was
developed out of a discussion with Henk Birkholz. Paul Kyzivat developed out of a discussion with Henk Birkholz. Paul Kyzivat
helped isolate the need for .det. helped isolate the need for .det.
.det is an abbreviation for "dedenting cat", but Det is also the name .det is an abbreviation for "dedenting cat", but Det is also the name
of a German TV Cartoon character created in the 1960s. of a German TV cartoon character created in the 1960s.
Author's Address Author's Address
Carsten Bormann Carsten Bormann
Universität Bremen TZI Universität Bremen TZI
Postfach 330440 Postfach 330440
D-28359 Bremen D-28359 Bremen
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
 End of changes. 62 change blocks. 
175 lines changed or deleted 156 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/