draft-ietf-cbor-cddl-control-00.txt   draft-ietf-cbor-cddl-control-01.txt 
Network Working Group C. Bormann Network Working Group C. Bormann
Internet-Draft Universität Bremen TZI Internet-Draft Universität Bremen TZI
Intended status: Informational 29 September 2020 Intended status: Informational 17 November 2020
Expires: 2 April 2021 Expires: 21 May 2021
Additional Control Operators for CDDL Additional Control Operators for CDDL
draft-ietf-cbor-cddl-control-00 draft-ietf-cbor-cddl-control-01
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 did The present document defines a number of control operators that did
not make it into RFC 8610: ".cat"/".plus" for the construction of not make it into RFC 8610: ".cat"/".plus" for the construction of
constants, ".abnf"/".abnfb" for including ABNF (RFC 5234/RFC 7405) in constants, ".abnf"/".abnfb" for including ABNF (RFC 5234/RFC 7405) in
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 April 2021. This Internet-Draft will expire on 21 May 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Computed Literals . . . . . . . . . . . . . . . . . . . . . . 3 2. Computed Literals . . . . . . . . . . . . . . . . . . . . . . 3
2.1. String Concatenation . . . . . . . . . . . . . . . . . . 3 2.1. String Concatenation . . . . . . . . . . . . . . . . . . 3
2.2. Numeric Addition . . . . . . . . . . . . . . . . . . . . 4 2.2. Numeric Addition . . . . . . . . . . . . . . . . . . . . 4
3. Embedded ABNF . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Embedded ABNF . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Features . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Features . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
7. Security considerations . . . . . . . . . . . . . . . . . . . 9 7. Security considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
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 did The present document defines a number of control operators that did
skipping to change at page 7, line 18 skipping to change at page 7, line 18
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, accepting such
extensions while marking them as such. extensions while marking them as such.
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
controller (right hand side) as a feature name, and the target (left
hand side) as a feature detail. However, in some cases, the target
has too much detail, and the specification might want to hint the
tool that more limited detail is appropriate. In this case, the
controller should be an array, with the first element being the
feature name (that would otherwise be the entire controller), and the
second element being the detail (usually another string).
foo = {
kind: bar / baz .feature (["foo-extensions", "bazify"])
}
bar = ...
baz = ... ; complex stuff that doesn't all need to be in the detail
Figure 4 shows what could be the definition of a person, with Figure 4 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 "further-person-extension". Extensions that are known at the time
this definition is written can be collected into "$$person- this definition is written can be collected into "$$person-
extensions". However, future extensions would be deemed invalid extensions". However, future extensions would be deemed invalid
unless the wildcard at the end of the map is added. These extensions unless the wildcard at the end of the map is added. These extensions
could then be specifically examined by a user or a tool that makes could then be specifically examined by a user or a tool that makes
use of the validation result. use of the validation result; the label (map key) actually used makes
a fine 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 whole-sale invalid,
making the entire validation approach much less useful. Leaving the making 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
 End of changes. 7 change blocks. 
7 lines changed or deleted 23 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/