]> Universität Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

Internet-Draft The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. RFCs have added to this extension point both in an application-specific and a more general way. The present document defines a number of additional generally application control operators for text conversion (Bytes, Integers, JSON) and operations on text.

Introduction The Concise Data Definition Language (CDDL), standardized in , provides "control operators" as its main language extension point (). RFCs have added to this extension point both in an application-specific and a more general way. The present document defines a number of additional generally applicable control operators: New control operators in this document

Name	Purpose
.b64u, .b64c	Base64 representation of byte strings
.hex, .hexlc, .hexuc	Base16 representation of byte strings
.b32, .h32	Base32 representation of byte strings
.decimal	Text representation of integer numbers
.json	Text representation of JSON values
.join	Building text from array of components

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This specification uses terminology from . In particular, with respect to control operators, "target" refers to the left-hand side operand, and "controller" to the right-hand side operand. "Tool" refers to tools along the lines of that described in . Note also that the data model underlying CDDL provides for text strings as well as byte strings as two separate types, which are then collectively referred to as "strings".

Text Conversion

Byte Strings: Base16 (Hex), Base32, Base64 A CDDL model often defines data that are byte strings in essence but need to be transported in various encoded forms, such as base64 or hex. This section defines a number of control operators to model these conversions. The control operators generally are of a form that could be used like this: The specification of these control operators is complicated by the large number of transformations in use. Inspired by , we use representations defined in with the following names: Control Operators for Text Conversion of byte strings

name	meaning	reference
.b64u	Base64URL, no padding
.b64c	Base64 classic, padding
.b32	Base32, no padding
.h32	Base32/hex alphabet, no padding
.hex	Base16 (hex), either case
.hexlc	Base16 (hex), lower case
.hexuc	Base16 (hex), upper case

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

Numbers Control Operator for Text Conversion of Integers

name	meaning	reference
.decimal	Decimal Integer	---

This allows the modeling of text strings that carry numeric information, such as in the uint64/int64 formats of YANG-JSON . Again, the specification is opinionated by only providing numbers without leading zeros, i.e., the decimal numbers match the regular expression "0|-?[1-9][0-9]*" (of course, further restricted by the control type). Future specifications can provide octal, hexadecimal, or binary conversions.

JSON Values Some applications store complete JSON texts into text strings, the JSON value for can easily be defined in CDDL. This is supported by a control operator similar to .cbor in . Control Operator for Text Conversion of JSON values

name	meaning	reference
.json	JSON

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

Text Processing

Join Often, text strings need to be constructed out of parts that can best be modeled as an array. Control Operator for Text Generation from Arrays

name	meaning	reference
.join	concatenate elements of an array	---

In general, this control operator is hard to validate as it would require full parser functionality. It is therefore recommended to only use it in simple cases, and leave full parsing to ABNF or similar. , ".", digits<2>, ".", digits<3>, ".", digits<4>] digits = text .decimal byte ]]>

Intersperse (This section requires some additional design effort before it can be implemented and registered.) The previous example is somewhat unwieldy as the dots are just syntactic noise. The .intersperse control is modeled after Haskell's function of the same name . It takes the elements of an array and intersperses a given additional elements between each to elements of the additional array. .intersperse is actually not limited to text strings; it can be used for any juggling of arrays. We want to stop here, as there is a danger of generating a functional programming language in an ad-hoc fashion.

IANA Considerations This document requests IANA to register the contents of into the registry "" of : New control operators to be registered

Name	Reference
.b64u	[RFCthis]
.b64c	[RFCthis]
.b32	[RFCthis]
.h32	[RFCthis]
.hex	[RFCthis]
.hexlc	[RFCthis]
.hexuc	[RFCthis]
.decimal	[RFCthis]
.json	[RFCthis]
.join	[RFCthis]

Implementation Status In the CDDL tool described in , the control operators defined in this specification are implemented as of version 0.10.2.

Security considerations The security considerations of apply.

References Normative References JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. IANA The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed: , , and for the construction of constants; / for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and for indicating the use of a non-basic feature in an instance. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Haskell Documentation The Concise Binary Object Representation (CBOR), defined in RFC 8949, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined. This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.

Acknowledgements Henk Birkholz suggested the need for many of the control operators defined here.