]> Universität Bremen TZI

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

CDDL models A number of CBOR- and JSON-based protocols have been defined before CDDL was standardized or widely used. This short draft records some CDDL definitions for such protocols, which could become part of a library of CDDL definitions available for use in CDDL2 processors. It focuses on CDDL in (almost) published IETF RFCs.

Introduction (Please see abstract.) Add in

CDDL definitions for (almost) published RFCs This section is intended to have one subsection for each CDDL data model presented for an existing RFC. As a start, it is fleshed out with three such data models.

RFC 7071 contains two CDDL definitions for , which are not copied here. Typically, the compact form would be used in applications using the RFC 7071 format; while the extended form might be useful to cherry-pick features of RFC 7071 into another protocol.

7807bis The RFC to be published out of defines a simple data model that is reproduced in CDDL here: any * text .feature "problem-object-extension" => any } ]]> Note that also defines a CBOR-specific data model that may be useful for tunneling problem details in Concise Problem Details.

YANG-SID The RFC to be published out of defines a data model for a "SID file" in YANG, to be transported as a YANG-JSON instance. An equivalent CDDL data model is given here: =cat3<"(", RE, ")*"> opt=cat3<"(", RE, ")?"> cat3 = (A .cat B) .cat C id-re = "[a-zA-Z_][a-zA-Z0-9\\-_.]*" yang$yang-identifier = text .regexp id-re revision-identifier = text .regexp "[0-9]{4}-[0-9]{2}-[0-9]{2}" sid-file-version-identifier = uint .size 4 sid = yang-json-uint64 ; expressing range 0..9223372036854775807 here would be complex yang-json-uint64 = text .regexp "0|[1-9][0-9]*" plus-id = Prefix .cat id-re schema-node-re = cat3, plus-id<":">, ; qualified rep .cat ; optionally opt> > > ; qualified schema-node-path = text .regexp schema-node-re dependency-revision = { module-name: yang$yang-identifier module-revision: revision-identifier } assignment-range = { entry-point: sid size: sid } item = { ? status: "stable" / "unstable" / "obsolete" ( namespace: "module" / "identity" / "feature" identifier: yang$yang-identifier // namespace: "data" identifier: schema-node-path ) sid: sid } ]]>

Your favorite RFC here...

IANA Considerations This document makes no requests of IANA.

Security considerations The security considerations of , , and apply. This collection of CDDL models is not thought to create new security considerations. Errors in the models could -- if we knew of them, we'd fix those errors instead of explaining their security consequences in this section.

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. 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. Informative References This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs. This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-httpapi/rfc7807bis. This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational State Transfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807. This document defines the format of reputation response data ("reputons"), the media type for packaging it, and definition of a registry for the names of reputation applications and response sets. Trilliant Networks Inc. Acklio Google Switzerland GmbH Universität Bremen TZI Sandelman Software Works YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit unsigned integers used to identify YANG items, as a more compact method to identify YANG items that can be used for efficiency and in constrained environments (RFC 7228). This document defines the semantics, the registration, and assignment processes of YANG SIDs for IETF managed YANG modules. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. // The present version (-19) adds in draft text about objectives, // parties, and roles. This attempts to record discussions at side // meetings before, at, and after IETF 113.

Acknowledgements TBD