draft-ietf-cbor-cddl-00.txt   draft-ietf-cbor-cddl-01.txt 
Network Working Group H. Birkholz Network Working Group H. Birkholz
Internet-Draft Fraunhofer SIT Internet-Draft Fraunhofer SIT
Intended status: Standards Track C. Vigano Intended status: Standards Track C. Vigano
Expires: January 28, 2018 Universitaet Bremen Expires: July 31, 2018 Universitaet Bremen
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
July 27, 2017 January 27, 2018
Concise data definition language (CDDL): a notational convention to Concise data definition language (CDDL): a notational convention to
express CBOR data structures express CBOR data structures
draft-ietf-cbor-cddl-00 draft-ietf-cbor-cddl-01
Abstract Abstract
This document proposes a notational convention to express CBOR data This document proposes a notational convention to express CBOR data
structures (RFC 7049). Its main goal is to provide an easy and structures (RFC 7049). Its main goal is to provide an easy and
unambiguous way to express structures for protocol messages and data unambiguous way to express structures for protocol messages and data
formats that use CBOR. formats that use CBOR.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 January 28, 2018. This Internet-Draft will expire on July 31, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Style of Data Structure Specification . . . . . . . . . . 4 2. The Style of Data Structure Specification . . . . . . . . . . 4
2.1. Groups and Composition in CDDL . . . . . . . . . . . . . 6 2.1. Groups and Composition in CDDL . . . . . . . . . . . . . 6
2.1.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Types . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Types . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Values . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1. Values . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2. Choices . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.2. Choices . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3. Representation Types . . . . . . . . . . . . . . . . 10 2.2.3. Representation Types . . . . . . . . . . . . . . . . 11
2.2.4. Root type . . . . . . . . . . . . . . . . . . . . . . 11 2.2.4. Root type . . . . . . . . . . . . . . . . . . . . . . 11
3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. General conventions . . . . . . . . . . . . . . . . . . . 11 3.1. General conventions . . . . . . . . . . . . . . . . . . . 12
3.2. Occurrence . . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Occurrence . . . . . . . . . . . . . . . . . . . . . . . 13
3.3. Predefined names for types . . . . . . . . . . . . . . . 14 3.3. Predefined names for types . . . . . . . . . . . . . . . 14
3.4. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Maps . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5. Maps . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5.1. Structs . . . . . . . . . . . . . . . . . . . . . . . 15 3.5.1. Structs . . . . . . . . . . . . . . . . . . . . . . . 16
3.5.2. Tables . . . . . . . . . . . . . . . . . . . . . . . 18 3.5.2. Tables . . . . . . . . . . . . . . . . . . . . . . . 19
3.6. Tags . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.5.3. Cuts in Maps . . . . . . . . . . . . . . . . . . . . 19
3.7. Unwrapping . . . . . . . . . . . . . . . . . . . . . . . 19 3.6. Tags . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.8. Controls . . . . . . . . . . . . . . . . . . . . . . . . 20 3.7. Unwrapping . . . . . . . . . . . . . . . . . . . . . . . 21
3.8.1. Control operator .size . . . . . . . . . . . . . . . 21 3.8. Controls . . . . . . . . . . . . . . . . . . . . . . . . 22
3.8.2. Control operator .bits . . . . . . . . . . . . . . . 21 3.8.1. Control operator .size . . . . . . . . . . . . . . . 22
3.8.3. Control operator .regexp . . . . . . . . . . . . . . 22 3.8.2. Control operator .bits . . . . . . . . . . . . . . . 23
3.8.4. Control operators .cbor and .cborseq . . . . . . . . 23 3.8.3. Control operator .regexp . . . . . . . . . . . . . . 24
3.8.5. Control operators .within and .and . . . . . . . . . 23 3.8.4. Control operators .cbor and .cborseq . . . . . . . . 25
3.8.5. Control operators .within and .and . . . . . . . . . 25
3.8.6. Control operators .lt, .le, .gt, .ge, .eq, .ne, and 3.8.6. Control operators .lt, .le, .gt, .ge, .eq, .ne, and
.default . . . . . . . . . . . . . . . . . . . . . . 24 .default . . . . . . . . . . . . . . . . . . . . . . 26
3.9. Socket/Plug . . . . . . . . . . . . . . . . . . . . . . . 24 3.9. Socket/Plug . . . . . . . . . . . . . . . . . . . . . . . 27
3.10. Generics . . . . . . . . . . . . . . . . . . . . . . . . 26 3.10. Generics . . . . . . . . . . . . . . . . . . . . . . . . 28
3.11. Operator Precedence . . . . . . . . . . . . . . . . . . . 26 3.11. Operator Precedence . . . . . . . . . . . . . . . . . . . 28
4. Making Use of CDDL . . . . . . . . . . . . . . . . . . . . . 28 4. Making Use of CDDL . . . . . . . . . . . . . . . . . . . . . 30
4.1. As a guide to a human user . . . . . . . . . . . . . . . 28 4.1. As a guide to a human user . . . . . . . . . . . . . . . 30
4.2. For automated checking of CBOR data structure . . . . . . 28 4.2. For automated checking of CBOR data structure . . . . . . 30
4.3. For data analysis tools . . . . . . . . . . . . . . . . . 29 4.3. For data analysis tools . . . . . . . . . . . . . . . . . 31
5. Security considerations . . . . . . . . . . . . . . . . . . . 29 5. Security considerations . . . . . . . . . . . . . . . . . . . 31
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 29 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.1. Normative References . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . 30 7.2. Informative References . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . 31 Appendix A. (Not used.) . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Cemetery . . . . . . . . . . . . . . . . . . . . . . 31 Appendix B. ABNF grammar . . . . . . . . . . . . . . . . . . . . 33
A.1. Resolved Issues . . . . . . . . . . . . . . . . . . . . . 32 Appendix C. Matching rules . . . . . . . . . . . . . . . . . . . 36
Appendix B. (Not used.) . . . . . . . . . . . . . . . . . . . . 32 Appendix D. (Not used.) . . . . . . . . . . . . . . . . . . . . 40
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 32 Appendix E. Standard Prelude . . . . . . . . . . . . . . . . . . 40
Appendix D. ABNF grammar . . . . . . . . . . . . . . . . . . . . 35 E.1. Use with JSON . . . . . . . . . . . . . . . . . . . . . . 42
Appendix E. Standard Prelude . . . . . . . . . . . . . . . . . . 37 Appendix F. The CDDL tool . . . . . . . . . . . . . . . . . . . 44
E.1. Use with JSON . . . . . . . . . . . . . . . . . . . . . . 39 Appendix G. Extended Diagnostic Notation . . . . . . . . . . . . 44
Appendix F. The CDDL tool . . . . . . . . . . . . . . . . . . . 41 G.1. White space in byte string notation . . . . . . . . . . . 45
Appendix G. Extended Diagnostic Notation . . . . . . . . . . . . 41 G.2. Text in byte string notation . . . . . . . . . . . . . . 45
G.1. White space in byte string notation . . . . . . . . . . . 42 G.3. Embedded CBOR and CBOR sequences in byte strings . . . . 45
G.2. Text in byte string notation . . . . . . . . . . . . . . 42 G.4. Concatenated Strings . . . . . . . . . . . . . . . . . . 46
G.3. Embedded CBOR and CBOR sequences in byte strings . . . . 42 G.5. Hexadecimal, octal, and binary numbers . . . . . . . . . 46
G.4. Concatenated Strings . . . . . . . . . . . . . . . . . . 43 G.6. Comments . . . . . . . . . . . . . . . . . . . . . . . . 47
G.5. Hexadecimal, octal, and binary numbers . . . . . . . . . 43 Appendix H. Examples . . . . . . . . . . . . . . . . . . . . . . 47
G.6. Comments . . . . . . . . . . . . . . . . . . . . . . . . 44 H.1. RFC 7071 . . . . . . . . . . . . . . . . . . . . . . . . 48
Appendix H. Examples . . . . . . . . . . . . . . . . . . . . . . 44 H.1.1. Examples from JSON Content Rules . . . . . . . . . . 52
H.1. RFC 7071 . . . . . . . . . . . . . . . . . . . . . . . . 45 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 54
H.1.1. Examples from JSON Content Rules . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
In this document, a notational convention to express CBOR [RFC7049] In this document, a notational convention to express CBOR [RFC7049]
data structures is defined. data structures is defined.
The main goal for the convention is to provide a unified notation The main goal for the convention is to provide a unified notation
that can be used when defining protocols that use CBOR. We term the that can be used when defining protocols that use CBOR. We term the
convention "Concise data definition language", or CDDL. convention "Concise data definition language", or CDDL.
skipping to change at page 4, line 19 skipping to change at page 4, line 19
generic data model being a subset of the CBOR generic data model, is generic data model being a subset of the CBOR generic data model, is
the fact that CDDL can also be used for describing JSON data the fact that CDDL can also be used for describing JSON data
structures (see Appendix E.1). structures (see Appendix E.1).
This document has the following structure: This document has the following structure:
The syntax of CDDL is defined in Section 3. Examples of CDDL and The syntax of CDDL is defined in Section 3. Examples of CDDL and
related CBOR data instances are defined in Appendix H. Section 4 related CBOR data instances are defined in Appendix H. Section 4
discusses usage of CDDL. Examples are provided early in the text to discusses usage of CDDL. Examples are provided early in the text to
better illustrate concept definitions. A formal definition of CDDL better illustrate concept definitions. A formal definition of CDDL
using ABNF grammar is provided in Appendix D. Finally, a prelude of using ABNF grammar is provided in Appendix B. Finally, a prelude of
standard CDDL definitions available in every CBOR specification is standard CDDL definitions available in every CBOR specification is
listed in Appendix E. listed in Appendix E.
1.1. Requirements notation 1.1. Requirements notation
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 RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119, BCP 14 [RFC2119]. 2119, BCP 14 [RFC2119].
skipping to change at page 6, line 5 skipping to change at page 6, line 5
_rule_), which formally is the set of CBOR instances that are _rule_), which formally is the set of CBOR instances that are
acceptable for this specification. CDDL predefines a number of acceptable for this specification. CDDL predefines a number of
basic types such as "uint" (unsigned integer) or "tstr" (text basic types such as "uint" (unsigned integer) or "tstr" (text
string), often making use of a simple formal notation for CBOR string), often making use of a simple formal notation for CBOR
data items. Each value that can be expressed as a CBOR data item data items. Each value that can be expressed as a CBOR data item
also is a type in its own right, e.g. "1". A type can be built also is a type in its own right, e.g. "1". A type can be built
as a _choice_ of other types, e.g., an "int" is either a "uint" as a _choice_ of other types, e.g., an "int" is either a "uint"
or a "nint" (negative integer). Finally, a type can be built as or a "nint" (negative integer). Finally, a type can be built as
an array or a map from a group. an array or a map from a group.
The rest of this section introduces a number of basic concepts of
CDDL, and section Section 3 defines additional syntax. Appendix C
gives a concise summary of the semantics of CDDL.
2.1. Groups and Composition in CDDL 2.1. Groups and Composition in CDDL
CDDL Groups are lists of name/value pairs (group _entries_). CDDL Groups are lists of name/value pairs (group _entries_).
In an array context, only the value of the entry is represented; the In an array context, only the value of the entry is represented; the
name is annotation only (and can be left off if not needed). In a name is annotation only (and can be left off if not needed). In a
map context, the names become the map keys ("member keys"). map context, the names become the map keys ("member keys").
In an array context, the sequence of elements in the group is In an array context, the sequence of elements in the group is
important, as it is the information that allows associating actual important, as it is the information that allows associating actual
array elements with entries in the group. In a map context, the array elements with entries in the group. In a map context, the
sequence of entries in a group is not relevant (but there is still a sequence of entries in a group is not relevant (but there is still a
need to write down group entries in a sequence). need to write down group entries in a sequence).
A group can be placed in (round) parentheses, and given a name by A simple example of using a group right in a map definition is:
using it in a rule:
pii = ( person = {
age: int, age: int,
name: tstr, name: tstr,
employer: tstr, employer: tstr,
) }
Figure 1: A basic group Figure 1: Using a group in a map
Or a group can just be used in the definition of something else: The three entries of the group are written between the curly braces
that create the map: Here, "age", "name", and "employer" are the
names that turn into the map key text strings, and "int" and "tstr"
(text string) are the types of the map values under these keys.
person = {( A group by itself (without creating a map around it) can be placed in
(round) parentheses, and given a name by using it in a rule:
pii = (
age: int, age: int,
name: tstr, name: tstr,
employer: tstr, employer: tstr,
)} )
Figure 2: Using a group in a map Figure 2: A basic group
which, given the above rule for pii, is identical to: This separate, named group definition allows us to rephrase Figure 1
as:
person = { person = {
pii pii
} }
Figure 3: Using a group by name Figure 3: Using a group by name
Note that the (curly) braces signify the creation of a map; the Note that the (curly) braces signify the creation of a map; the
groups themselves are neutral as to whether they will be used in a groups themselves are neutral as to whether they will be used in a
map or an array. map or an array.
The parentheses for groups are optional when there is some other set As shown in Figure 1, the parentheses for groups are optional when
of brackets present, so it would be slightly more natural to express there is some other set of brackets present. Note that they can
Figure 2 as: still be used, leading to the not so realistic, but perfectly valid
example:
person = { person = {(
age: int, age: int,
name: tstr, name: tstr,
employer: tstr, employer: tstr,
} )}
Groups can be used to factor out common parts of structs, e.g., Groups can be used to factor out common parts of structs, e.g.,
instead of writing: instead of writing copy/paste style specifications such as in
Figure 4, one can factor out the common subgroup, choose a name for
it, and write only the specific parts into the individual maps
(Figure 5).
person = { person = {
age: int, age: int,
name: tstr, name: tstr,
employer: tstr, employer: tstr,
} }
dog = { dog = {
age: int, age: int,
name: tstr, name: tstr,
leash-length: float, leash-length: float,
} }
one can choose a name for the common subgroup and write: Figure 4: Maps with copy/paste
person = { person = {
identity, identity,
employer: tstr, employer: tstr,
} }
dog = { dog = {
identity, identity,
leash-length: float, leash-length: float,
} }
identity = ( identity = (
age: int, age: int,
name: tstr, name: tstr,
) )
Figure 4: Using a group for factorization Figure 5: Using a group for factorization
Note that the contents of the braces in the above definitions Note that the lists inside the braces in the above definitions
constitute (anonymous) groups, while "identity" is a named group. constitute (anonymous) groups, while "identity" is a named group.
2.1.1. Usage 2.1.1. Usage
Groups are the instrument used in composing data structures with Groups are the instrument used in composing data structures with
CDDL. It is a matter of style in defining those structures whether CDDL. It is a matter of style in defining those structures whether
to define groups (anonymously) right in their contexts or whether to to define groups (anonymously) right in their contexts or whether to
define them in a separate rule and to reference them with their define them in a separate rule and to reference them with their
respective name (possibly more than once). respective name (possibly more than once).
skipping to change at page 8, line 31 skipping to change at page 8, line 50
o The start of a group can be marked by '(' o The start of a group can be marked by '('
o The end of a group can be marked by ')' o The end of a group can be marked by ')'
o Definitions of entries inside of a group are noted as follows: o Definitions of entries inside of a group are noted as follows:
_keytype => valuetype,_ (read "keytype maps to valuetype"). The _keytype => valuetype,_ (read "keytype maps to valuetype"). The
comma is actually optional (not just in the final entry), but it comma is actually optional (not just in the final entry), but it
is considered good style to set it. The double arrow can be is considered good style to set it. The double arrow can be
replaced by a colon in the common case of directly using a text replaced by a colon in the common case of directly using a text
string as a key (see Section 3.5.1). string or integer literal as a key (see Section 3.5.1).
An entry consists of a _keytype_ and a _valuetype_: An entry consists of a _keytype_ and a _valuetype_:
o _keytype_ is either an atom used as the actual key or a type in o _keytype_ is either an atom used as the actual key or a type in
general. The latter case may be needed when using groups in a general. The latter case may be needed when using groups in a
table context, where the actual keys are of lesser importance than table context, where the actual keys are of lesser importance than
the key types, e.g in contexts verifying incoming data. the key types, e.g in contexts verifying incoming data.
o _valuetype_ is a type, which could be derived from the major types o _valuetype_ is a type, which could be derived from the major types
defined in [RFC7049], could be a convenience valuetype defined in defined in [RFC7049], could be a convenience valuetype defined in
skipping to change at page 9, line 16 skipping to change at page 9, line 34
Values such as numbers and strings can be used in place of a type. Values such as numbers and strings can be used in place of a type.
(For instance, this is a very common thing to do for a keytype, (For instance, this is a very common thing to do for a keytype,
common enough that CDDL provides additional convenience syntax for common enough that CDDL provides additional convenience syntax for
this.) this.)
2.2.2. Choices 2.2.2. Choices
Many places that allow a type also allow a choice between types, Many places that allow a type also allow a choice between types,
delimited by a "/" (slash). The entire choice construct can be put delimited by a "/" (slash). The entire choice construct can be put
into parentheses if this is required to make the construction into parentheses if this is required to make the construction
unambiguous (please see Appendix D for the details). unambiguous (please see Appendix B for the details).
Choices of values can be used to express enumerations: Choices of values can be used to express enumerations:
attire = "bow tie" / "necktie" / "Internet attire" attire = "bow tie" / "necktie" / "Internet attire"
protocol = 6 / 17 protocol = 6 / 17
Similarly as for types, CDDL also allows choices between groups, Similarly as for types, CDDL also allows choices between groups,
delimited by a "//" (double slash). delimited by a "//" (double slash).
address = { delivery } address = { delivery }
skipping to change at page 11, line 35 skipping to change at page 12, line 11
(Note that there is no way to use a group as a root - it must be a (Note that there is no way to use a group as a root - it must be a
type. Using a group as the root might be employed as a way to type. Using a group as the root might be employed as a way to
specify a CBOR sequence in a future version of this specification; specify a CBOR sequence in a future version of this specification;
this would act as if that group is used in an array and the data this would act as if that group is used in an array and the data
items in that fictional array form the members of the CBOR sequence.) items in that fictional array form the members of the CBOR sequence.)
3. Syntax 3. Syntax
In this section, the overall syntax of CDDL is shown, alongside some In this section, the overall syntax of CDDL is shown, alongside some
examples just illustrating syntax. (The definition will not attempt examples just illustrating syntax. (The definition will not attempt
to be overly formal; refer to Appendix D for the details.) to be overly formal; refer to Appendix B for the details.)
3.1. General conventions 3.1. General conventions
The basic syntax is inspired by ABNF [RFC5234], with The basic syntax is inspired by ABNF [RFC5234], with
o rules, whether they define groups or types, are defined with a o rules, whether they define groups or types, are defined with a
name, followed by an equals sign "=" and the actual definition name, followed by an equals sign "=" and the actual definition
according to the respective syntactic rules of that definition. according to the respective syntactic rules of that definition.
o A name can consist of any of the characters from the set {'A', o A name can consist of any of the characters from the set {'A',
skipping to change at page 12, line 33 skipping to change at page 13, line 11
used to separate syntactic elements for readability (and to used to separate syntactic elements for readability (and to
separate identifiers or numbers that follow each other); it is separate identifiers or numbers that follow each other); it is
otherwise completely optional. otherwise completely optional.
o Hexadecimal numbers are preceded by '0x' (without quotes, lower o Hexadecimal numbers are preceded by '0x' (without quotes, lower
case x), and are case insensitive. Similarly, binary numbers are case x), and are case insensitive. Similarly, binary numbers are
preceded by '0b'. preceded by '0b'.
o Text strings are enclosed by double quotation '"' characters. o Text strings are enclosed by double quotation '"' characters.
They follow the conventions for strings as defined in section 7 of They follow the conventions for strings as defined in section 7 of
[RFC7159]. (ABNF users may want to note that there is no support [RFC8259]. (ABNF users may want to note that there is no support
in CDDL for the concept of case insensitivity in text strings; if in CDDL for the concept of case insensitivity in text strings; if
necessary, regular expressions can be used (Section 3.8.3).) necessary, regular expressions can be used (Section 3.8.3).)
o Byte strings are enclosed by single quotation "'" characters and o Byte strings are enclosed by single quotation "'" characters and
may be prefixed by "h" or "b64". If unprefixed, the string is may be prefixed by "h" or "b64". If unprefixed, the string is
interpreted as with a text string, except that single quotes must interpreted as with a text string, except that single quotes must
be escaped and that the UTF-8 bytes resulting are marked as a byte be escaped and that the UTF-8 bytes resulting are marked as a byte
string (major type 2). If prefixed as "h" or "b64", the string is string (major type 2). If prefixed as "h" or "b64", the string is
interpreted as a sequence of hex digits or a base64(url) string, interpreted as a sequence of hex digits or a base64(url) string,
respectively (as with the diagnostic notation in section 6 of respectively (as with the diagnostic notation in section 6 of
skipping to change at page 15, line 31 skipping to change at page 16, line 5
"coextension", 865] "coextension", 865]
3.5. Maps 3.5. Maps
The syntax for specifying maps merits special attention, as well as a The syntax for specifying maps merits special attention, as well as a
number of optimizations and conveniences, as it is likely to be the number of optimizations and conveniences, as it is likely to be the
focal point of many specifications employing CDDL. While the syntax focal point of many specifications employing CDDL. While the syntax
does not strictly distinguish struct and table usage of maps, it does not strictly distinguish struct and table usage of maps, it
caters specifically to each of them. caters specifically to each of them.
But first, let's reiterate a feature of CBOR that it has inherited
from JSON: The key/value pairs in CBOR maps have no fixed ordering.
(One could imagine situations where fixing the ordering may be of
use. For example, a decoder could look for values related with
integer keys 1, 3 and 7. If the order were fixed and the decoder
encounters the key 4 without having encountered key 3, it could
conclude that key 3 is not available without doing more complicated
bookkeeping. Unfortunately, neither JSON nor CBOR support this, so
no attempt was made to support this in CDDL either.)
3.5.1. Structs 3.5.1. Structs
The "struct" usage of maps is similar to the way JSON objects are The "struct" usage of maps is similar to the way JSON objects are
used in many JSON applications. used in many JSON applications.
A map is defined in the same way as defining an array (see A map is defined in the same way as defining an array (see
Section 3.4), except for using curly braces "{}" instead of square Section 3.4), except for using curly braces "{}" instead of square
brackets "[]". brackets "[]".
An occurrence indicator as specified in Section 3.2 is permitted for An occurrence indicator as specified in Section 3.2 is permitted for
skipping to change at page 16, line 41 skipping to change at page 17, line 17
This is actually a complete example: an identifier that is followed This is actually a complete example: an identifier that is followed
by a colon can be directly used as the text string for a member key by a colon can be directly used as the text string for a member key
(we speak of a "bareword" member key), as can a double-quoted string (we speak of a "bareword" member key), as can a double-quoted string
or a number. (When other types, in particular multi-valued ones, are or a number. (When other types, in particular multi-valued ones, are
used as keytypes, they are followed by a double arrow, see below.) used as keytypes, they are followed by a double arrow, see below.)
If a text string key does not match the syntax for an identifier (or If a text string key does not match the syntax for an identifier (or
if the specifier just happens to prefer using double quotes), the if the specifier just happens to prefer using double quotes), the
text string syntax can also be used in the member key position, text string syntax can also be used in the member key position,
followed by a colon. The above example could therefore have been followed by a colon. The above example could therefore have been
written with quoted strings in the member key positions. written with quoted strings in the member key positions. More
generally, all the types defined can be used in a keytype position by
All the types defined can be used in a keytype position by following following them with a double arrow. A string also is a (single-
them with a double arrow. A string also is a (single-valued) type, valued) type, so another form for this example is:
so another form for this example is:
located-samples = { located-samples = {
"sample-point" => int, "sample-point" => int,
"samples" => [+ float], "samples" => [+ float],
} }
See Section 3.5.3 below for how the colon shortcut described here
also adds some implied semantics.
A better way to demonstrate the double-arrow use may be: A better way to demonstrate the double-arrow use may be:
located-samples = { located-samples = {
sample-point: int, sample-point: int,
samples: [+ float], samples: [+ float],
* equipment-type => equipment-tolerances, * equipment-type => equipment-tolerances,
} }
equipment-type = [name: tstr, manufacturer: tstr] equipment-type = [name: tstr, manufacturer: tstr]
equipment-tolerances = [+ [float, float]] equipment-tolerances = [+ [float, float]]
skipping to change at page 18, line 17 skipping to change at page 18, line 39
NameComponents, NameComponents,
? age: uint, ? age: uint,
* tstr => any * tstr => any
} }
NameComponents = ( NameComponents = (
? firstName: tstr, ? firstName: tstr,
? familyName: tstr, ? familyName: tstr,
) )
Figure 5: Personal Data: Example for extensibility Figure 6: Personal Data: Example for extensibility
The cddl tool (Appendix F) generated as one acceptable instance for The cddl tool (Appendix F) generated as one acceptable instance for
this specification: this specification:
{"familyName": "agust", "antiforeignism": "pretzel", {"familyName": "agust", "antiforeignism": "pretzel",
"springbuck": "illuminatingly", "exuviae": "ephemeris", "springbuck": "illuminatingly", "exuviae": "ephemeris",
"kilometrage": "frogfish"} "kilometrage": "frogfish"}
(See Section 3.9 for one way to explicitly identify an extension (See Section 3.9 for one way to explicitly identify an extension
point.) point.)
skipping to change at page 19, line 5 skipping to change at page 19, line 27
If the specification does not need to restrict one of x or y (i.e., If the specification does not need to restrict one of x or y (i.e.,
the application is free to choose per entry), it can be replaced by the application is free to choose per entry), it can be replaced by
the predefined name "any". the predefined name "any".
As another example, the following could be used as a conversion table As another example, the following could be used as a conversion table
converting from an integer or float to a string: converting from an integer or float to a string:
tostring = {* mynumber => tstr} tostring = {* mynumber => tstr}
mynumber = int / float mynumber = int / float
3.5.3. Cuts in Maps
The extensibility idiom discussed above for structs has one problem:
extensible-map-example = {
? "optional-key" => int,
* tstr => any
}
In this example, there is one optional key "optional-key", which,
when present, maps to an integer. There is also a wild card for any
future additions.
Unfortunately, the instance
{ "optional-key": "nonsense" }
does match this specification: While the first entry of the group
does not match, the second one (the wildcard) does. This may be very
well desirable (e.g., if a future extension is to be allowed to
extend the type of "optional-key"), but in many cases isn't.
In anticipation of a more general potential feature called "cuts",
CDDL allows inserting a cut "^" into the definition of the map entry:
extensible-map-example = {
? "optional-key" ^ => int,
* tstr => any
}
A cut in this position means that once the map key matches the entry
carrying the cut, other potential matches for the key that occur in
later entries in the group of the map are no longer allowed. (This
rule applies independent of whether the value matches, too.) So the
example above no longer matches the version modified with a cut.
Since the desire for this kind of exclusive matching is so frequent,
the ":" shortcut is actually defined to include the cut semantics.
So the preceding example (including the cut) can be written more
simply as:
extensible-map-example = {
? "optional-key": int,
* tstr => any
}
or even shorter, using a bareword for the key:
extensible-map-example = {
? optional-key: int,
* tstr => any
}
3.6. Tags 3.6. Tags
A type can make use of a CBOR tag (major type 6) by using the A type can make use of a CBOR tag (major type 6) by using the
representation type notation, giving #6.nnn(type) where nnn is an representation type notation, giving #6.nnn(type) where nnn is an
unsigned integer giving the tag number and "type" is the type of the unsigned integer giving the tag number and "type" is the type of the
data item being tagged. data item being tagged.
For example, the following line from the CDDL prelude (Appendix E) For example, the following line from the CDDL prelude (Appendix E)
defines "biguint" as a type name for a positive bignum N: defines "biguint" as a type name for a positive bignum N:
skipping to change at page 21, line 18 skipping to change at page 22, line 35
3.8.1. Control operator .size 3.8.1. Control operator .size
A ".size" control controls the size of the target in bytes by the A ".size" control controls the size of the target in bytes by the
control type. Examples: control type. Examples:
full-address = [[+ label], ip4, ip6] full-address = [[+ label], ip4, ip6]
ip4 = bstr .size 4 ip4 = bstr .size 4
ip6 = bstr .size 16 ip6 = bstr .size 16
label = bstr .size (1..63) label = bstr .size (1..63)
Figure 6: Control for size in bytes Figure 7: Control for size in bytes
When applied to an unsigned integer, the ".size" control restricts When applied to an unsigned integer, the ".size" control restricts
the range of that integer by giving a maximum number of bytes that the range of that integer by giving a maximum number of bytes that
should be needed in a computer representation of that unsigned should be needed in a computer representation of that unsigned
integer. In other words, "uint .size N" is equivalent to integer. In other words, "uint .size N" is equivalent to
"0...BYTES_N", where BYTES_N == 256**N. "0...BYTES_N", where BYTES_N == 256**N.
audio_sample = uint .size 3 ; 24-bit, equivalent to 0..16777215 audio_sample = uint .size 3 ; 24-bit, equivalent to 0..16777215
Figure 7: Control for integer size in bytes Figure 8: Control for integer size in bytes
Note that, as with value restrictions in CDDL, this control is not a Note that, as with value restrictions in CDDL, this control is not a
representation constraint; a number that fits into fewer bytes can representation constraint; a number that fits into fewer bytes can
still be represented in that form, and an inefficient implementation still be represented in that form, and an inefficient implementation
could use a longer form (unless that is restricted by some format could use a longer form (unless that is restricted by some format
constraints outside of CDDL, such as the rules in Section 3.9 of constraints outside of CDDL, such as the rules in Section 3.9 of
[RFC7049]). [RFC7049]).
3.8.2. Control operator .bits 3.8.2. Control operator .bits
skipping to change at page 22, line 21 skipping to change at page 23, line 35
ack: 12, ack: 12,
urg: 13, urg: 13,
ece: 14, ece: 14,
cwr: 15, cwr: 15,
ns: 0, ns: 0,
) / (4..7) ; data offset bits ) / (4..7) ; data offset bits
rwxbits = uint .bits rwx rwxbits = uint .bits rwx
rwx = &(r: 2, w: 1, x: 0) rwx = &(r: 2, w: 1, x: 0)
Figure 8: Control for what bits can be set Figure 9: Control for what bits can be set
The CDDL tool generates the following ten example instances for The CDDL tool generates the following ten example instances for
"tcpflagbytes": "tcpflagbytes":
h'906d' h'01fc' h'8145' h'01b7' h'013d' h'409f' h'018e' h'c05f' h'906d' h'01fc' h'8145' h'01b7' h'013d' h'409f' h'018e' h'c05f'
h'01fa' h'01fe' h'01fa' h'01fe'
These examples do not illustrate that the above CDDL specification These examples do not illustrate that the above CDDL specification
does not explicitly specify a size of two bytes: A valid all clear does not explicitly specify a size of two bytes: A valid all clear
instance of flag bytes could be "h''" or "h'00'" or even "h'000000'" instance of flag bytes could be "h''" or "h'00'" or even "h'000000'"
as well. as well.
3.8.3. Control operator .regexp 3.8.3. Control operator .regexp
A ".regexp" control indicates that the text string given as a target A ".regexp" control indicates that the text string given as a target
needs to match the PCRE regular expression given as a value in the needs to match the XSD regular expression given as a value in the
control type, where that regular expression is anchored on both control type. XSD regular expressions are defined in Appendix F of
sides. (If anchoring is not desired for a side, ".*" needs to be [W3C.REC-xmlschema-2-20041028].
inserted there.)
nai = tstr .regexp "\\w+@\\w+(\\.\\w+)+" nai = tstr .regexp "[A-Za-z0-9]+@[A-Za-z0-9]+(\\.[A-Za-z0-9]+)+"
Figure 9: Control with a PCRE regexp Figure 10: Control with an XSD regexp
The CDDL tool proposes: The CDDL tool proposes:
"N1@CH57HF.4Znqe0.dYJRN.igjf" "N1@CH57HF.4Znqe0.dYJRN.igjf"
3.8.3.1. Usage considerations
Note that XSD regular expressions do not support the usual \x or \u
escapes for hexadecimal expression of bytes or unicode code points.
However, in CDDL the XSD regular expressions are contained in text
strings, the literal notation for which provides \u escapes; this
should suffice for most applications that use regular expressions for
text strings. (Note that this also means that there is one level of
string escaping before the XSD escaping rules are applied.)
XSD regular expressions support character class subtraction, a
feature often not found in regular expression libraries;
specification writers may want to use this feature sparingly.
Similar considerations apply to Unicode character classes; where
these are used, the specification SHOULD identify which Unicode
versions are addressed.
Other surprises for infrequent users of XSD regular expressions may
include:
o No direct support for case insensitivity. While case
insensitivity has gone mostly out of fashion in protocol design,
it is sometimes needed and then needs to be expressed manually as
in "[Cc][Aa][Ss][Ee]".
o The support for popular character classes such as \w and \d is
based on Unicode character properties, which is often not what is
desired in an ASCII-based protocol and thus might lead to
surprises. (\s and \S do have their more conventional meanings,
and "." matches any character but the line ending characters \r or
\n.)
3.8.3.2. Discussion
There are many flavors of regular expression in use in the
programming community. For instance, perl-compatible regular
expressions (PCRE) are widely used and probably are more useful than
XSD regular expressions. However, there is no normative reference
for PCRE that could be used in the present document. Instead, we opt
for XSD regular expressions for now. There is precedent for that
choice in the IETF, e.g., in YANG [RFC7950].
Note that CDDL uses controls as its main extension point. This
creates the opportunity to add further regular expression formats in
addition to the one referenced here if desired. As an example, a
control ".pcre" is defined in [I-D.bormann-cbor-cddl-freezer].
3.8.4. Control operators .cbor and .cborseq 3.8.4. Control operators .cbor and .cborseq
A ".cbor" control on a byte string indicates that the byte string A ".cbor" control on a byte string indicates that the byte string
carries a CBOR encoded data item. Decoded, the data item matches the carries a CBOR encoded data item. Decoded, the data item matches the
type given as the right-hand side argument (type1 in the following type given as the right-hand side argument (type1 in the following
example). example).
"bytes .cbor type1" "bytes .cbor type1"
Similarly, a ".cborseq" control on a byte string indicates that the Similarly, a ".cborseq" control on a byte string indicates that the
skipping to change at page 25, line 27 skipping to change at page 27, line 40
) )
Names that start with a single "$" are "type sockets", names with a Names that start with a single "$" are "type sockets", names with a
double "$$" are "group sockets". It is not an error if there is no double "$$" are "group sockets". It is not an error if there is no
definition for a socket at all; this then means there is no way to definition for a socket at all; this then means there is no way to
satisfy the rule (i.e., the choice is empty). satisfy the rule (i.e., the choice is empty).
All definitions (plugs) for socket names must be augmentations, i.e., All definitions (plugs) for socket names must be augmentations, i.e.,
they must be using "/=" and "//=", respectively. they must be using "/=" and "//=", respectively.
To pick up the example illustrated in Figure 5, the socket/plug To pick up the example illustrated in Figure 6, the socket/plug
mechanism could be used as shown in Figure 10: mechanism could be used as shown in Figure 11:
PersonalData = { PersonalData = {
? displayName: tstr, ? displayName: tstr,
NameComponents, NameComponents,
? age: uint, ? age: uint,
* $$personaldata-extensions * $$personaldata-extensions
} }
NameComponents = ( NameComponents = (
? firstName: tstr, ? firstName: tstr,
skipping to change at page 26, line 30 skipping to change at page 28, line 30
$$personaldata-extensions //= ( $$personaldata-extensions //= (
favorite-salsa: tstr, favorite-salsa: tstr,
) )
; and again, somewhere else: ; and again, somewhere else:
$$personaldata-extensions //= ( $$personaldata-extensions //= (
shoesize: uint, shoesize: uint,
) )
Figure 10: Personal Data example: Using socket/plug extensibility Figure 11: Personal Data example: Using socket/plug extensibility
3.10. Generics 3.10. Generics
Using angle brackets, the left hand side of a rule can add formal Using angle brackets, the left hand side of a rule can add formal
parameters after the name being defined, as in: parameters after the name being defined, as in:
messages = message<"reboot", "now"> / message<"sleep", 1..100> messages = message<"reboot", "now"> / message<"sleep", 1..100>
message<t, v> = {type: t, value: v} message<t, v> = {type: t, value: v}
When using a generic rule, the formal parameters are bound to the When using a generic rule, the formal parameters are bound to the
skipping to change at page 28, line 5 skipping to change at page 30, line 5
group4 is a group choice between a repeatable a and a single b or c. group4 is a group choice between a repeatable a and a single b or c.
In general, as with many other languages with operator precedence In general, as with many other languages with operator precedence
rules, it is best not to rely on them, but to insert parentheses for rules, it is best not to rely on them, but to insert parentheses for
readability: readability:
t = [group4a] t = [group4a]
group4a = ((+ a) // (b / c)) group4a = ((+ a) // (b / c))
a = 1 b = 2 c = 3 a = 1 b = 2 c = 3
The operator precedences, in sequence of loose to tight binding, are The operator precedences, in sequence of loose to tight binding, are
defined in Appendix D and summarized in Table 1. (Arities given are defined in Appendix B and summarized in Table 1. (Arities given are
1 for unary prefix operators and 2 for binary infix operators.) 1 for unary prefix operators and 2 for binary infix operators.)
+----------+----+---------------------------+------+ +----------+----+---------------------------+------+
| Operator | Ar | Operates on | Prec | | Operator | Ar | Operates on | Prec |
+----------+----+---------------------------+------+ +----------+----+---------------------------+------+
| = | 2 | name = type, name = group | 1 | | = | 2 | name = type, name = group | 1 |
| /= | 2 | name /= type | 1 | | /= | 2 | name /= type | 1 |
| //= | 2 | name //= group | 1 | | //= | 2 | name //= group | 1 |
| // | 2 | group // group | 2 | | // | 2 | group // group | 2 |
| , | 2 | group, group | 3 | | , | 2 | group, group | 3 |
skipping to change at page 30, line 5 skipping to change at page 32, line 5
Topics that could be considered in a security considerations section Topics that could be considered in a security considerations section
that uses CDDL to define CBOR structures include the following: that uses CDDL to define CBOR structures include the following:
o Where could the language maybe cause confusion in a way that will o Where could the language maybe cause confusion in a way that will
enable security issues? enable security issues?
6. IANA considerations 6. IANA considerations
This document does not require any IANA registrations. This document does not require any IANA registrations.
7. Acknowledgements 7. References
CDDL was originally conceived by Bert Greevenbosch, who also wrote
the original five versions of this document.
Inspiration was taken from the C and Pascal languages, MPEG's
conventions for describing structures in the ISO base media file
format, Relax-NG and its compact syntax [RELAXNG], and in particular
from Andrew Lee Newton's "JSON Content Rules"
[I-D.newton-json-content-rules].
Useful feedback came from Joe Hildebrand, Sean Leonard and Jim
Schaad.
The CDDL tool was written by Carsten Bormann, building on previous
work by Troy Heninger and Tom Lord.
8. References
8.1. Normative References 7.1. Normative References
[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,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <http://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015, DOI 10.17487/RFC7493, March 2015,
<http://www.rfc-editor.org/info/rfc7493>. <https://www.rfc-editor.org/info/rfc7493>.
8.2. Informative References [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Recommendation
REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
7.2. Informative References
[I-D.bormann-cbor-cddl-freezer]
Bormann, C., "A feature freezer for the Concise Data
Definition Language (CDDL)", draft-bormann-cbor-cddl-
freezer-00 (work in progress), January 2018.
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[I-D.ietf-core-senml] [I-D.ietf-core-senml]
Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
Bormann, "Media Types for Sensor Measurement Lists Bormann, "Media Types for Sensor Measurement Lists
(SenML)", draft-ietf-core-senml-10 (work in progress), (SenML)", draft-ietf-core-senml-12 (work in progress),
July 2017. December 2017.
[I-D.newton-json-content-rules] [I-D.newton-json-content-rules]
Newton, A. and P. Cordell, "A Language for Rules Newton, A. and P. Cordell, "A Language for Rules
Describing JSON Content", draft-newton-json-content- Describing JSON Content", draft-newton-json-content-
rules-08 (work in progress), March 2017. rules-09 (work in progress), September 2017.
[RELAXNG] OASIS, "RELAX-NG Compact Syntax", November 2002, [RELAXNG] OASIS, "RELAX-NG Compact Syntax", November 2002,
<http://relaxng.org/compact-20021121.html>. <http://relaxng.org/compact-20021121.html>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for [RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for
Reputation Interchange", RFC 7071, DOI 10.17487/RFC7071, Reputation Interchange", RFC 7071, DOI 10.17487/RFC7071,
November 2013, <http://www.rfc-editor.org/info/rfc7071>. November 2013, <https://www.rfc-editor.org/info/rfc7071>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network
Interconnection (CDNI) Control Interface / Triggers", Interconnection (CDNI) Control Interface / Triggers",
RFC 8007, DOI 10.17487/RFC8007, December 2016, RFC 8007, DOI 10.17487/RFC8007, December 2016,
<http://www.rfc-editor.org/info/rfc8007>. <https://www.rfc-editor.org/info/rfc8007>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<http://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
Appendix A. Cemetery
The following ideas have been buried in the discussions leading up to
the present specification:
o <...> as syntax for enumerations. We view values to be just
another type (a very specific type with just one member), so that
an enumeration can be denoted as a choice using "/" as the
delimiter of choices. Because of this, no evidence is present
that a separate syntax for enumerations is needed.
A.1. Resolved Issues
o The key/value pairs in maps have no fixed ordering. One could
imagine situations where fixing the ordering may be of use. For
example, a decoder could look for values related with integer keys
1, 3 and 7. If the order were fixed and the decoder encounters
the key 4 without having encountered key 3, it could conclude that
key 3 is not available without doing more complicated bookkeeping.
Unfortunately, neither JSON nor CBOR support this, so no attempt
was made to support this in CDDL either.
o CDDL distinguishes the various CBOR number types, but there is
only one number type in JSON. There is no effect in specifying a
precision (float16/float32/float64) when using CDDL for specifying
JSON data structures. (The current validator implementation
Appendix F does not handle this very well, either.)
Appendix B. (Not used.)
Appendix C. Change Log
Changes from version 00 to version 01:
o Removed constants
o Updated the tag mechanism
o Extended the map structure
o Added examples
Changes from version 01 to version 02:
o Fixed example
Changes from version 02 to version 03:
o Added information about characters used in names
o Added text about an overall data structure and order of definition
of fields
o Added text about encoding of keys
o Added table with keywords
o Strings and integer writing conventions
o Added ABNF
Changes from version 03 to version 04:
o Removed optional fields for non-maps
o Defined all key/value pairs in maps are considered optional from
the CDDL perspective
o Allow omission of type of keys for maps with only text string and
integer keys
o Changed order of definitions
o Updated fruit and moves examples
o Renamed the "Philosophy" section to "Using CDDL", and added more
text about CDDL usage
o Several editorials
Changes from version 04 to version 05:
o Added text about alternative datatypes and any datatype
o Fixed typos
o Restructured syntax and semantics
Changes from version 05 to version 05:
o Fixed the ABNF for choices (no longer need to write a: (b/c))
o Added group choices (//)
o Added /= and //=
o Added experimental socket/plug
o Added aliases text, bytes, null to prelude
o Documented generics
o Fixed more typos
Changes from 06 to 07:
o .cbor, .cborseq, .within, .and
o Define .size on uint
o Extended Diagnostic Notation
o Precedence discussion and table
o Remove some of the "issues" that can only be understood with
historical context
o Prefer "text" over "tstr" in some of the examples
o Add "unsigned" to the prelude
Changes from 07 to 08:
o .lt, .le, .eq, .ne, .gt, .ge
o .default
Changes from 08 to 09:
o Take annotations and socket/plug out of the nursery; they have
been battle-proven enough.
o Define a value notation for byte strings as well.
o Removed discussion section that was no longer relevant; move
"Resolved Issues" to appendix.
Changes from 09 to 10:
o Remove a long but not very elucidating example. (Maybe we'll add
back some shorter examples later.)
o A few clarifications.
o Updated author list.
Changes from 10 to 11: 7.3. URIs
o Define unwrapping operator ~ [1] https://github.com/cabo/cbor-diag
o Change term for annotation into "control" (but leave "annotate" Appendix A. (Not used.)
for when it actually is meant in that sense)
Appendix D. ABNF grammar Appendix B. ABNF grammar
The following is a formal definition of the CDDL syntax in Augmented The following is a formal definition of the CDDL syntax in Augmented
Backus-Naur Form (ABNF, [RFC5234]). [_abnftodo] Backus-Naur Form (ABNF, [RFC5234]). [_abnftodo]
cddl = S 1*rule cddl = S 1*rule
rule = typename [genericparm] S assign S type S rule = typename [genericparm] S assign S type S
/ groupname [genericparm] S assign S grpent S / groupname [genericparm] S assign S grpent S
typename = id typename = id
groupname = id groupname = id
skipping to change at page 35, line 50 skipping to change at page 34, line 42
ctlop = "." id ctlop = "." id
group = grpchoice S *("//" S grpchoice S) group = grpchoice S *("//" S grpchoice S)
grpchoice = *grpent grpchoice = *grpent
grpent = [occur S] [memberkey S] type optcom grpent = [occur S] [memberkey S] type optcom
/ [occur S] groupname [genericarg] optcom ; preempted by above / [occur S] groupname [genericarg] optcom ; preempted by above
/ [occur S] "(" S group S ")" optcom / [occur S] "(" S group S ")" optcom
memberkey = type1 S "=>" memberkey = type1 S ["^" S] "=>"
/ bareword S ":" / bareword S ":"
/ value S ":" / value S ":"
bareword = id bareword = id
optcom = S ["," S] optcom = S ["," S]
occur = [uint] "*" [uint] occur = [uint] "*" [uint]
/ "+" / "+"
/ "?" / "?"
skipping to change at page 37, line 4 skipping to change at page 35, line 46
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
BINDIG = %x30-31 BINDIG = %x30-31
S = *WS S = *WS
WS = SP / NL WS = SP / NL
SP = %x20 SP = %x20
NL = COMMENT / CRLF NL = COMMENT / CRLF
COMMENT = ";" *PCHAR CRLF COMMENT = ";" *PCHAR CRLF
PCHAR = %x20-10FFFD PCHAR = %x20-10FFFD
CRLF = %x0A / %x0D.0A CRLF = %x0A / %x0D.0A
Figure 11: CDDL ABNF
Figure 12: CDDL ABNF
Appendix C. Matching rules
In this appendix, we go through the ABNF syntax rules defined in
Appendix B and briefly describe the matching semantics of each
syntactic feature. In this context, an instance (data item)
"matches" a CDDL specification if it is allowed by the CDDL
specification; this is then broken down to parts of specifications
(type and group expressions) and parts of instances (data items).
cddl = S 1*rule
A CDDL specification is a sequence of one or more rules. Each rule
gives a name to a right hand side expression, either a CDDL type or a
CDDL group. Rule names can be used in the rule itself and/or other
rules (and tools can output warnings if that is not the case). The
order of the rules is significant only in two cases, including the
following: The first rule defines the semantics of the entire
specification; hence, its name may be descriptive only (or may be
used in itself or other rules as with the other rule names).
rule = typename [genericparm] S assign S type S
/ groupname [genericparm] S assign S grpent S
typename = id
groupname = id
A rule defines a name for a type expression (production "type") or
for a group expression (production "grpent"), with the intention that
the semantics does not change when the name is replaced by its
(parenthesized if needed) definition.
assign = "=" / "/=" / "//="
A plain equals sign defines the rule name as the equivalent of the
expression to the right. A "/=" or "//=" extends a named type or a
group by additional choices; a number of these could be replaced by
collecting all the right hand sides and creating a single rule with a
type choice or a group choice built from the right hand sides in the
order of the rules given. (It is not an error to extend a rule name
that has not yet been defined; this makes the right hand side the
first entry in the choice being created.) The creation of the type
choices and group choices from the right hand sides of rules is the
other case where rule order can be significant.
genericparm = "<" S id S *("," S id S ) ">"
genericarg = "<" S type1 S *("," S type1 S ) ">"
Rule names can have generic parameters, which cause temporary
assignments within the right hand sides to the parameter names from
the arguments given when citing the rule name.
type = type1 S *("/" S type1 S)
A type can be given as a choice between one or more types. The
choice matches an instance if the instance matches any one of the
types given in the choice. The choice uses Parse Expression Grammar
(PEG) semantics: The first choice that matches wins. (As a result,
the order of rules that contribute to a single rule name can very
well matter.)
type1 = type2 [S (rangeop / ctlop) S type2]
Two types can be combined with a range operator (which see below) or
a control operator (see Section 3.8).
type2 = value
A type can be just a single value (such as 1 or "icecream" or
h'0815'), which matches only an instance with that specific value (no
conversions defined),
/ typename [genericarg]
or be defined by a rule giving a meaning to a name (possibly after
supplying generic args as required by the generic parameters),
/ "(" type ")"
or be defined in a parenthesized type expression (parentheses may be
necessary to override some operator precendence), or
/ "~" S groupname [genericarg]
an "unwrapped" group (see Section 3.7), which matches the group
inside a type defined as a map or an array by wrapping the group, or
/ "#" "6" ["." uint] "(" S type S ")" ; note no space!
a tagged data item, tagged with the "uint" given and containing the
type given as the tagged value, or
/ "#" DIGIT ["." uint] ; major/ai
an instance of a major type (given by the DIGIT), optionally
constrained to the additional information given by the uint, or
/ "#" ; any
any data item, or
/ "{" S group S "}"
a map expression, which matches a valid CBOR map the key/value pairs
of which can be ordered in such a way that the resulting sequence
matches the group expression, or
/ "[" S group S "]"
an array expression, which matches a CBOR array the elements of
which, when taken as values and complemented by a wildcard (matches
anything) key each, match the group, or
/ "&" S "(" S group S ")"
/ "&" S groupname [genericarg]
an enumeration expression, which matches any a value that is within
the set of values that the values of the group given can take.
rangeop = "..." / ".."
A range operator can be used to join two type expressions that stand
for either two integer values or two floating point values; it
matches any value that is between the two values, where the first
value is always included in the matching set and the second value is
included for ".." and excluded for "...".
ctlop = "." id
A control operator ties a _target_ type to a _controller_ type as
defined in Section 3.8. Note that control operators are an extension
point for CDDL; additional documents may want to define additional
control operators.
group = grpchoice S *("//" S grpchoice S)
A group matches any sequence of key/value pairs that matches any of
the choices given (again using Parse Expression Grammar semantics).
grpchoice = *grpent
Each of the component groups is given as a sequence of group entries.
For a match, the sequence of key/value pairs given needs to match the
sequence of group entries in the sequence given.
grpent = [occur S] [memberkey S] type optcom
A group entry can be given by a value type, which needs to be matched
by the value part of a single element, and optionally a memberkey
type, which needs to be matched by the key pard of the element, if
the memberkey is given. If the memberkey is not given, the entry can
only be used for matching arrays, not for maps. (See below how that
is modified by the occurrence indicator.)
/ [occur S] groupname [genericarg] optcom ; preempted by above
A group entry can be built from a named group, or
/ [occur S] "(" S group S ")" optcom
from a parenthesized group, again with a possible occurrence
indicator.
memberkey = type1 S ["^" S] "=>"
/ bareword S ":"
/ value S ":"
Key types can be given by a type expression, a bareword (which stands
for string value created from this bareword), or a value (which
stands for a type that just contains this value). A key value
matches its key type if the key value is a member of the key type,
unless a cut preceding it in the group applies (see Section 3.5.3 how
map matching is infuenced by the presence of the cuts denoted by "^"
or ":" in previous entries).
bareword = id
A bareword is an alternative way to write a type with a single text
string value; it can only be used in the syntactic context given
above.
optcom = S ["," S]
(Optional commas do not influence the matching.)
occur = [uint] "*" [uint]
/ "+"
/ "?"
An occurrence indicator modifies the group given to its right by
requiring the group to match the sequence to be matched exactly for a
certain number of times (see Section 3.2) in sequence, i.e. it acts
as a (possibly infinite) group choice that contains choices with the
group repeated each of the occurrences times.
The rest of the ABNF describes syntax for value notation that should
be familiar from programming languages, with the possible exception
of h'..' and b64'..' for byte strings, as well as syntactic elements
such as comments and line ends.
Appendix D. (Not used.)
Appendix E. Standard Prelude Appendix E. Standard Prelude
The following prelude is automatically added to each CDDL file The following prelude is automatically added to each CDDL file
[tdate]. (Note that technically, it is a postlude, as it does not [tdate]. (Note that technically, it is a postlude, as it does not
disturb the selection of the first rule as the root of the disturb the selection of the first rule as the root of the
definition.) definition.)
any = # any = #
uint = #0 uint = #0
skipping to change at page 38, line 50 skipping to change at page 41, line 50
float32-64 = float32 / float64 float32-64 = float32 / float64
float = float16-32 / float64 float = float16-32 / float64
false = #7.20 false = #7.20
true = #7.21 true = #7.21
bool = false / true bool = false / true
nil = #7.22 nil = #7.22
null = nil null = nil
undefined = #7.23 undefined = #7.23
Figure 12: CDDL Prelude Figure 13: CDDL Prelude
Note that the prelude is deemed to be fixed. This means, for Note that the prelude is deemed to be fixed. This means, for
instance, that additional tags beyond [RFC7049], as registered, need instance, that additional tags beyond [RFC7049], as registered, need
to be defined in each CDDL file that is using them. to be defined in each CDDL file that is using them.
A common stumbling point is that the prelude does not define a type A common stumbling point is that the prelude does not define a type
"string". CBOR has byte strings ("bytes" in the prelude) and text "string". CBOR has byte strings ("bytes" in the prelude) and text
strings ("text"), so a type that is simply called "string" would be strings ("text"), so a type that is simply called "string" would be
ambiguous. ambiguous.
E.1. Use with JSON E.1. Use with JSON
The JSON generic data model (implicit in [RFC7159]) is a subset of The JSON generic data model (implicit in [RFC8259]) is a subset of
the generic data model of CBOR. So one can use CDDL with JSON by the generic data model of CBOR. So one can use CDDL with JSON by
limiting oneself to what can be represented in JSON. Roughly limiting oneself to what can be represented in JSON. Roughly
speaking, this means leaving out byte strings, tags, and simple speaking, this means leaving out byte strings, tags, and simple
values other than "false", "true", and "null", leading to the values other than "false", "true", and "null", leading to the
following limited prelude: following limited prelude:
any = # any = #
uint = #0 uint = #0
nint = #1 nint = #1
skipping to change at page 39, line 47 skipping to change at page 42, line 47
float16-32 = float16 / float32 float16-32 = float16 / float32
float32-64 = float32 / float64 float32-64 = float32 / float64
float = float16-32 / float64 float = float16-32 / float64
false = #7.20 false = #7.20
true = #7.21 true = #7.21
bool = false / true bool = false / true
nil = #7.22 nil = #7.22
null = nil null = nil
Figure 13: JSON compatible subset of CDDL Prelude Figure 14: JSON compatible subset of CDDL Prelude
(The major types given here do not have a direct meaning in JSON, but (The major types given here do not have a direct meaning in JSON, but
they can be interpreted as CBOR major types translated through they can be interpreted as CBOR major types translated through
Section 4 of [RFC7049].) Section 4 of [RFC7049].)
There are a few fine points in using CDDL with JSON. First, JSON There are a few fine points in using CDDL with JSON. First, JSON
does not distinguish between integers and floating point numbers; does not distinguish between integers and floating point numbers;
there is only one kind of number (which may happen to be integral). there is only one kind of number (which may happen to be integral).
In this context, specifying a type as "uint", "nint" or "int" then In this context, specifying a type as "uint", "nint" or "int" then
becomes a predicate that the number be integral. As an example, this becomes a predicate that the number be integral. As an example, this
means that the following JSON numbers are all matching "uint": means that the following JSON numbers are all matching "uint":
10 10.0 1e1 1.0e1 100e-1 10 10.0 1e1 1.0e1 100e-1
(The fact that these are all integers may be surprising to users (The fact that these are all integers may be surprising to users
accustomed to the long tradition in programming languages of using accustomed to the long tradition in programming languages of using
decimal points or exponents in a number to indicate a floating point decimal points or exponents in a number to indicate a floating point
literal.) literal.)
CDDL distinguishes the various CBOR number types, but there is only
one number type in JSON. The effect of specifying a floating point
precision (float16/float32/float64) is only to restrict the set of
permissible values to those expressible with binary16/binary32/
binary64; this is unlikely to be very useful when using CDDL for
specifying JSON data structures.
Fundamentally, the number system of JSON itself is based on decimal Fundamentally, the number system of JSON itself is based on decimal
numbers and decimal fractions and does not have limits to its numbers and decimal fractions and does not have limits to its
precision or range. In practice, JSON numbers are often parsed into precision or range. In practice, JSON numbers are often parsed into
a number type that is called float64 here, creating a number of a number type that is called float64 here, creating a number of
limitations to the generic data model [RFC7493]. In particular, this limitations to the generic data model [RFC7493]. In particular, this
means that integers can only be expressed with interoperable means that integers can only be expressed with interoperable
exactness when they lie in the range [-(2**53)+1, (2**53)-1] -- a exactness when they lie in the range [-(2**53)+1, (2**53)-1] -- a
smaller range than that covered by CDDL "int". smaller range than that covered by CDDL "int".
JSON applications that want to stay compatible with I-JSON therefore JSON applications that want to stay compatible with I-JSON therefore
may want to define integer types with more limited ranges, such as in may want to define integer types with more limited ranges, such as in
Figure 14. Note that the types given here are not part of the Figure 15. Note that the types given here are not part of the
prelude; they need to be copied into the CDDL specification if prelude; they need to be copied into the CDDL specification if
needed. needed.
ij-uint = 0..9007199254740991 ij-uint = 0..9007199254740991
ij-nint = -9007199254740991..-1 ij-nint = -9007199254740991..-1
ij-int = -9007199254740991..9007199254740991 ij-int = -9007199254740991..9007199254740991
Figure 14: I-JSON types for CDDL (not part of prelude) Figure 15: I-JSON types for CDDL (not part of prelude)
JSON applications that do not need to stay compatible with I-JSON and JSON applications that do not need to stay compatible with I-JSON and
that actually may need to go beyond the 64-bit unsigned and negative that actually may need to go beyond the 64-bit unsigned and negative
integers supported by "int" (= "uint"/"nint") may want to use the integers supported by "int" (= "uint"/"nint") may want to use the
following additional types from the standard prelude, which are following additional types from the standard prelude, which are
expressed in terms of tags but can straightforwardly be mapped into expressed in terms of tags but can straightforwardly be mapped into
JSON (but not I-JSON) numbers: JSON (but not I-JSON) numbers:
biguint = #6.2(bstr) biguint = #6.2(bstr)
bignint = #6.3(bstr) bignint = #6.3(bstr)
skipping to change at page 41, line 26 skipping to change at page 44, line 33
check the syntax, generate one or more instances (expressed in CBOR check the syntax, generate one or more instances (expressed in CBOR
diagnostic notation or in pretty-printed JSON), and validate an diagnostic notation or in pretty-printed JSON), and validate an
existing instance against the specification: existing instance against the specification:
Usage: Usage:
cddl spec.cddl generate [n] cddl spec.cddl generate [n]
cddl spec.cddl json-generate [n] cddl spec.cddl json-generate [n]
cddl spec.cddl validate instance.cbor cddl spec.cddl validate instance.cbor
cddl spec.cddl validate instance.json cddl spec.cddl validate instance.json
Figure 15: CDDL tool usage Figure 16: CDDL tool usage
Install on a system with a modern Ruby via: Install on a system with a modern Ruby via:
gem install cddl gem install cddl
Figure 16: CDDL tool installation Figure 17: CDDL tool installation
The accompanying CBOR diagnostic tools (which are automatically The accompanying CBOR diagnostic tools (which are automatically
installed by the above) are described in https://github.com/cabo/ installed by the above) are described in https://github.com/cabo/
cbor-diag; they can be used to convert between binary CBOR, a pretty- cbor-diag [1]; they can be used to convert between binary CBOR, a
printed form of that, CBOR diagnostic notation, JSON, and YAML. pretty-printed form of that, CBOR diagnostic notation, JSON, and
YAML.
Appendix G. Extended Diagnostic Notation Appendix G. Extended Diagnostic Notation
Section 6 of [RFC7049] defines a "diagnostic notation" in order to be Section 6 of [RFC7049] defines a "diagnostic notation" in order to be
able to converse about CBOR data items without having to resort to able to converse about CBOR data items without having to resort to
binary data. Diagnostic notation is based on JSON, with extensions binary data. Diagnostic notation is based on JSON, with extensions
for representing CBOR constructs such as binary data and tags. for representing CBOR constructs such as binary data and tags.
(Standardizing this together with the actual interchange format does (Standardizing this together with the actual interchange format does
not serve to create another interchange format, but enables the use not serve to create another interchange format, but enables the use
skipping to change at page 48, line 26 skipping to change at page 52, line 26
precision: text, precision: text,
Latitude: float, Latitude: float,
Longitude: float, Longitude: float,
Address: text, Address: text,
City: text, City: text,
State: text, State: text,
Zip: text, Zip: text,
Country: text Country: text
}] }]
Figure 17: JCR, Figure 2, in CDDL Figure 18: JCR, Figure 2, in CDDL
Apart from the lack of a need to quote the member names, text strings Apart from the lack of a need to quote the member names, text strings
are called "text" or "tstr" in CDDL ("string" would be ambiguous as are called "text" or "tstr" in CDDL ("string" would be ambiguous as
CBOR also provides byte strings). CBOR also provides byte strings).
The CDDL tool creates the below example instance for this: The CDDL tool creates the below example instance for this:
[{"precision": "pyrosphere", "Latitude": 0.5399712314350172, [{"precision": "pyrosphere", "Latitude": 0.5399712314350172,
"Longitude": 0.5157523963028087, "Address": "resow", "Longitude": 0.5157523963028087, "Address": "resow",
"City": "problemwise", "State": "martyrlike", "Zip": "preprove", "City": "problemwise", "State": "martyrlike", "Zip": "preprove",
skipping to change at page 50, line 5 skipping to change at page 54, line 5
Width: 0..1280, Width: 0..1280,
Height: 0..1024, Height: 0..1024,
) )
The CDDL tool creates the below example instance for this: The CDDL tool creates the below example instance for this:
{"Image": {"Width": 566, "Height": 516, "Title": "leisterer", {"Image": {"Width": 566, "Height": 516, "Title": "leisterer",
"Thumbnail": {"Width": 1111, "Height": 176, "Url": 32("scrog")}, "Thumbnail": {"Width": 1111, "Height": 176, "Url": 32("scrog")},
"IDs": []}} "IDs": []}}
Acknowledgements
CDDL was originally conceived by Bert Greevenbosch, who also wrote
the original five versions of this document.
Inspiration was taken from the C and Pascal languages, MPEG's
conventions for describing structures in the ISO base media file
format, Relax-NG and its compact syntax [RELAXNG], and in particular
from Andrew Lee Newton's "JSON Content Rules"
[I-D.newton-json-content-rules].
Useful feedback came from members of the IETF CBOR WG, in particular
Joe Hildebrand, Sean Leonard and Jim Schaad. Also, Francesca
Palombini and Joe volunteered to chair this WG, providing the
framework for generating and processing this feedback.
The CDDL tool was written by Carsten Bormann, building on previous
work by Troy Heninger and Tom Lord.
Editorial Comments Editorial Comments
[_format] So far, the ability to restrict format choices have not been [_format] So far, the ability to restrict format choices have not been
needed beyond the floating point formats. Those can be needed beyond the floating point formats. Those can be
applied to ranges using the new .and control now. It is not applied to ranges using the new .and control now. It is not
clear we want to add more format control before we have a use clear we want to add more format control before we have a use
case. case.
[_range] TO DO: define this precisely. This clearly includes integers [_range] TO DO: define this precisely. This clearly includes integers
and floats. Strings - as in "a".."z" - could be added if and floats. Strings - as in "a".."z" - could be added if
skipping to change at page 50, line 33 skipping to change at page 54, line 52
bits like in RFC box notation? (Or at least per-byte? bits like in RFC box notation? (Or at least per-byte?
32-bit words don't always perfectly mesh with byte 32-bit words don't always perfectly mesh with byte
strings.) strings.)
[unflex] A comment has been that this is counter-intuitive. One [unflex] A comment has been that this is counter-intuitive. One
solution would be to simply disallow unparenthesized usage of solution would be to simply disallow unparenthesized usage of
occurrence indicators in front of type choices unless a member occurrence indicators in front of type choices unless a member
key is also present like in group2 above. key is also present like in group2 above.
[_abnftodo] Potential improvements: the prefixed byte strings are more [_abnftodo] Potential improvements: the prefixed byte strings are more
liberally specified than they actually are. [^_abnfdontdo]: liberally specified than they actually are.
representation indicators are not supported. - and this will
stay so.
[tdate] The prelude as included here does not yet have a .regexp control [tdate] The prelude as included here does not yet have a .regexp control
on tdate, but we probably do want to have one. on tdate, but we probably do want to have one.
Authors' Addresses Authors' Addresses
Henk Birkholz Henk Birkholz
Fraunhofer SIT Fraunhofer SIT
Rheinstrasse 75 Rheinstrasse 75
Darmstadt 64295 Darmstadt 64295
 End of changes. 82 change blocks. 
299 lines changed or deleted 502 lines changed or added

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