]> Concise Diagnostic Notation (CDN) Universität Bremen TZI
Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org
Internet-Draft This document formalizes and consolidates the definition of the Concise Diagnostic Notation (CDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing CDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies registry-based extension points and uses them to support text representations such as of epoch-based dates/times and of IP addresses and prefixes. (This cref will be removed by the RFC editor:)
This revision -29 attempts to implement various change requests not covered in -28 that have been discussed in the 2026-08-19 and 2026-09-30 WG interim meetings, but does not attempt to reflect the outcome of those discussions. The text also does not have WG input yet on any renaming decisions (CDN name, b1/t1 name). About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the cbor Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction The Concise Binary Object Representation (CBOR) (RFC8949) 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. In addition to the binary interchange format, the original CBOR specification described a text-based "diagnostic notation" (, now Section of RFC 8949 ), in order to facilitate conversation about CBOR data items without having to resort to binary data. extended this into what also became known as Extended Diagnostic Notation (EDN), often including and draft revisions of the present document. Diagnostic notation is now specified by this document, obsoleting all these previous descriptions, and is known as Concise Diagnostic Notation (CDN). Diagnostic notation syntax is based on JSON, with extensions for representing CBOR constructs such as binary data and tags. The interchange format created by standardizing CDN is not intended to compete with the actual binary interchange format CBOR, but enables the use of a shared diagnostic notation in tools for and in documents about CBOR. However, between tools for CBOR development and diagnosis, document generation systems, continuous integration (CI) environments, configuration files, and user interfaces for viewing and editing for all these, CDN is often "interchanged". Therefore, CDN deserves a specification that facilitates interoperability within this domain and reliable translation to and from CBOR. CDN is not designed or intended for general-purpose use in protocol elements exchanged between systems engaged in processes outside those listed here. ​This document consolidates and formalizes the definition of CDN, providing a formal grammar (see and ), and incorporating small changes based on implementation experience. It updates by obsoleting Section of RFC 8949 , and by obsoleting . It is intended to serve as the single reference target that can be used in specifications that use CDN. It also specifies a registry-based extension point for the diagnostic notation, for adding application-oriented "prefixed" literal forms. It uses this registry to add prefixed literal forms that enhance CDN with text representations of various kinds of data items. Among others, these include epoch-based date/times, IP addresses and prefixes , as well cryptographic hash values computed from byte strings. In addition, this document registers a media type identifier and a content-format for CDN. This does not elevate its status as an interchange format, but recognizes that interaction between tools is often smoother if media types can be used. Note that CDN is not meant to be the only text-based representation of CBOR data items. For instance, is able to represent most CBOR data items, possibly requiring use of YAML's extension points. YAML does not provide certain features that can be useful with tools and documents needing text-based representations of CBOR data items (such as embedded CBOR or encoding indicators), but it does provide a host of other features that CDN does not provide such as anchor/alias data sharing, at a cost of higher implementation and learning complexity.
Structure of This Document of this document defines CDN. After introductory material, further illustrates the concept of prefixed literals by defining a number of them in app-extensions. describes syntax that can be interpreted by a diagnostic implementation to take note/take control of which of possibly several encoding variants is in use for a data item; this syntax always includes an underscore ("_") and therefore is visually easy to ignore. gives the formal syntax of CDN in ABNF. This is followed by the conventional sections for (), (), and (). An informational comparison of CDN with CDDL follows in .
Terminology and Conventions The term "ABNF" in this document refers to the language defined in as extended in , where the "characters" of Section of RFC 5234 are Unicode scalar values. Where names for ABNF rules are used in the text, they are shown in typewriter font (not distinguishable in the plaintext rendition of this document). Brief snippets of grammar may also be given in the text as I-Regexp regular expressions . The term "CDDL" (Concise Data Definition Language) refers to the data definition language defined in and its registered extensions (such as those documented in , , and ). Additional information about the relationship between the two languages CDN and CDDL is captured in . Examples sometimes need to be quoted in the text, in particular in cases where the typewriter font used for example text cannot be distinguished in the plaintext rendition of this document. ASCII quotes, however, are already taken: true, "true", 'true', and `true` are all different literals in CDN and should not be confused. Therefore, a different quoting convention as in »true« or »"true"« is used for examples in the text where this is needed to remain unambiguous. Superscript notation denotes exponentiation. For example, 2 to the power of 64+1 is notated: 264+1. In the plain-text rendition of this specification, superscript notation is not available and exponentiation is therefore rendered by the surrogate notation seen here in the plain-text rendition. 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 () () when, and only when, they appear in all capitals, as shown here.
(Non-)Objectives of this Document Section of RFC 8949 states the objective of defining a common human-readable diagnostic notation with CBOR. In particular, it states:
All actual interchange always happens in the binary format.
For Humans One important application of CDN is the notation of CBOR data for humans: in specifications, on whiteboards, and for entering test data. A number of features, such as comments inside prefixed string literals, are mainly useful for people-to-people communication via CDN. Programs also often output CDN for diagnostic purposes, such as in error messages or to enable comparison (including generation of diffs via tools) with test data.
Determinism? For comparison with test data, it is often useful if different implementations generate the same (or similar) output for the same CBOR data items. This is comparable to the objectives of deterministic serialization for CBOR data items themselves (Section of RFC 8949 ). However, there are even more representation variants in CDN than in binary CBOR, and there is little point in specifically endorsing a single variant as "deterministic" when other variants may be more useful for human understanding, e.g., the << >> notation as opposed to, say, hexadecimal h'' notation; a CDN generator may have quite a few options that control what presentation variant is most desirable for the application that it is being used for. Because of this, a deterministic representation is not defined for CDN. More generally speaking, there is no expectation for "roundtripping": Converting CDN to binary CBOR and back to CDN will generally not achieve exactly the same result as the original input CDN. This possibly was created by humans or by a different CDN generator and may contain presentation information that is not represented in the binary CBOR.
Basic Output Format However, there is a certain expectation that CDN generators can be configured to some basic output format, which:
  • looks like JSON where that is possible;
  • inserts encoding indicators, if any, only where the binary form differs from Preferred Serialization (Section of RFC 8949 );
  • uses hexadecimal representation (h'') for byte strings, not b64'' or embedded CBOR (<<>>);
  • does not generate elaborate blank space (newlines, indentation) for pretty-printing, but does use common blank spaces such as after , and :.
See for more considerations about the character repertoire used for CDN source text. Additional features such as ensuring deterministic map ordering (Section of RFC 8949 ) on output, or even deviating from the basic configuration in some systematic way, can further assist in comparing test data. Information obtained from a CDDL model can help in choosing prefixed literals or specific string representations such as embedded CBOR or b64'' in the appropriate places.
Evolution Diagnostic notation was initially designed for interchange situations where backward compatibility was considered less critical than in binary CBOR interchanges. This allowed for quite freely making extensions in and . However, with increased interchange between CBOR-related tools, this unrestricted evolution is less desirable. The present specification supports a more controlled path of evolving CDN through two well-defined extension points: one general () and one specific to diagnostic processing of encoding variants (). The present specification makes two changes to the extensions that are not entirely backward compatible. These changes are detailed in and in the aside at the end of . Some syntax from the original diagnostic notation is being deprecated () and replaced (). These changes are deemed acceptable now because the updated features were originally introduced under more permissive conditions. With CDN now more rigidly defined and focusing evolution on the new extension points, such changes are no longer foreseen.
Character Repertoire of Source Similar to JSON, CDN is designed to enable representing all CBOR data items using a source character repertoire just containing printable ASCII characters (%x20-7e in ABNF) and newlines. However, if appropriate, CDN can also make full use of larger Unicode repertoires. CDN generators may provide configuration to consistently select either the unescaped (directly readable) or an escaped (ASCII equivalent) form of characters in string literals; the latter allows CDN to be used when the diagnostic value of fully escaped characters may be desired or in environments where non-ASCII characters may not enjoy full data transparency. Similar to JSON, CDN is designed to allow a simple tool to convert any CDN into a fully escaped (printable ASCII and newlines only) form, as well as to inversely recover unescaped characters for all escapes where this is possible or for certain subsets of the characters (such as Unicode categories L, M, N, P, S, plus Zs or just ASCII space). Special considerations apply to newlines in the source. On some platforms, a CARRIAGE RETURN character (U+000D or CR, often seen escaped as "\r" in many programming languages) is always added in front of a LINE FEED (U+000A or LF) to represent a newline (which are then referred to as CRLF). On other platforms, carriage returns are not used at line breaks at all, so a newline is just an LF. (Platforms that use just a CARRIAGE RETURN by itself to signify an end of line are no longer relevant and the files they produce are out of scope for this document.) Files are often freely converted between these two newline representations, including by source code revision control systems. To ensure that platforms will generate the same bytes in the CBOR data items created from input in either conversion state, CDN MUST create the same processing result independent of which newline representation is used by its input. To deal with this variability in platform presentation of newlines, Unicode CARRIAGE RETURN characters that exist in the input unescaped are ignored as if they were not in the input wherever they appear. Specifically, any carriage return characters that may be present in a CDN (text or byte) string literal are not copied into the resulting string. If a carriage return is needed in a CBOR string data item, it can be added explicitly, for instance by using the escaped form \r in single-quoted or double-quoted strings.
Concise Diagnostic Notation (CDN) CBOR is a binary interchange format. To facilitate documentation and debugging, and in particular to facilitate communication between entities cooperating in debugging, this document defines a simple human-readable diagnostic notation. All actual interchange always happens in the binary format. Note that diagnostic notation truly was designed as a diagnostic format; it originally was not meant to be parsed. Therefore, no formal definition (as in ABNF) was given in the original documents. Recognizing that formal grammars can aid interoperation of tools and usability of documents that employ CDN, now provides ABNF definitions. CDN is a true superset of JSON as it is defined in in conjunction with (that is, any interoperable JSON text also is a CDN text), extending it both to cover the greater expressiveness of CBOR and to increase its usability. CDN borrows the JSON syntax for numbers (integer and floating-point, ), certain simple values (), UTF-8 text strings, arrays, and maps (maps are called objects in JSON; the diagnostic notation extends JSON here by allowing any data item in the map key position). CDN provides literals that represent CBOR data items textually. Many of the forms of literals provided are predefined by this document, but it also defines an extension point that enables defining additional application-oriented extension literals. These are also known as prefixed literals, as they start with a prefix that identifies the application-oriented extension and possibly a specific variant of that. discusses these in more details and defines a number of app-extensions that are included with this specification. As CDN is used for truly diagnostic purposes, its implementations MAY support generation and possibly ingestion of CDN for CBOR data items that are well-formed but not valid. It is RECOMMENDED that an implementation enables such usage only explicitly by configuration (such as an API or CLI flag). Validity of CBOR data items is discussed in Section of RFC 8949 , with basic validity discussed in Section of RFC 8949 , and tag validity discussed in Section of RFC 8949 . Tag validity is more likely a subject for individual app-extensions, while the two cases of basic validity (for text strings and for maps) are addressed in Sections and under the heading of validity. The rest of this section provides an overview over specific features of CDN, starting with certain common syntactical features and then going through kinds of CBOR data items roughly in the order of CBOR major types. Any additional detailed syntax discussion needed has been deferred to . Additional information about implementation and use of CDN is continuously being collected by the community in .
Comments For presentation to humans, CDN text may benefit from comments. JSON famously does not provide for comments, and the original diagnostic notation in inherited this property. CDN provides two comment syntaxes, which can be used where the syntax allows blank space (outside of constructs such as numbers, string literals, etc.):
  • inline comments, delimited by slashes ("/") or by C-style "/*" and "*/": In a position that allows blank space, each of the following is considered blank space (and thus effectively a comment):
    • any text that starts with a slash followed by a character that is not a star or a slash, up to another slash, or
    • any text that starts with "/*" up to and including the next following "*/"
  • end-of-line comments, delimited by "#" and an end of line (LINE FEED, U+000A): In a position that allows blank space, any text starting with "#" and ending with and including the end of the line is considered blank space (and thus effectively a comment).
Comments can be used to annotate a CBOR structure as in: This reduces to [1, 10584416, ["opsonize", 7, 105]]. Another example, combining the use of inline and end-of-line comments: This reduces to {1: 4, 3: 5, -1: h'6684523AB17337F173500E5728C628547CB37DFE68449C65F885D1B73B49EAE1'}. A CDN file used for configuration might look like this (employing '#' end of line comments throughout and an ornamental C-Style comment at the start):
Discussion introduced comments into the diagnostic notation syntax, limited to inline comments using a bare "/" as the comment delimiter. It however also hinted at the potential desire to add end-of-line comments, mentioning both "//" and "#" as start delimiters. The present specification adds "#" end-of-line comments, as well as C-style inline comments (between "/*" and "*/" delimiters). This introduces a backwards-incompatible change, restricting slash-delimited comments that were allowed by :
  • Inline comments no longer can be empty: The construct "//" that was an empty comment in is too easy to mistake for a common JSON extension that introduces an end-of-line comment, which is not provided by CDN. It therefore raises an error in CDN. (Note that the character sequence "//" may occur visually "within" a slash-delimited comment like in below: its first slash actually ends the current comment and the second slash starts a new one.)
  • Enabling the use of C-style inline comments can extend the scope of what previously were parsed as slash-delimited comments: for instance, "/*foo/" was a complete comment in and now is the beginning of a C-style comment that goes on up to a "*/".
As an example for what is enabled by this change, the introduction of C-style inline comments enables a comment explaining a COSE algorithm identifier, as in ,
C-Style Inline Comment with a Slash
instead of the previously conventional, but often less familiar :
Traditional Inline Comment Working Around a Slash
Numbers In addition to JSON's decimal number literals, CDN provides hexadecimal, octal, and binary number literals in the usual C-language notation (0x, 0o prefix only, and 0b, respectively). CBOR distinguishes two basic kinds of numbers: integers and floating point values. Numbers composed only of digits (of the respective base) are interpreted as CBOR integers (major type 0/1, or where the number cannot be represented in this way, major type 6 with tag 2/3). Any input representing a number with a leading "+" sign raises an error. A leading "-" sign inverts the sign of the number. So 0 and -0 represent the same integer zero, 1 stands for a positive integer one, and -1 designates the negative integer minus one. Using a decimal point (.) and/or an exponent (e for decimal, p for hexadecimal) turns the number into a floating point number (part of major type 7) instead, irrespective of whether it is an integral number mathematically. Note that, in floating point numbers, 0.0 is not the same number as -0.0, even if they are mathematically equal. In , all the items on a row are the same number (also shown in CBOR, hexadecimally), but they are distinct from items in a different row. Example Sets of Equivalent Notations for Some Numbers
CDN CBOR hex
4711, 0x1267, 0o11147, 0b1001001100111 19 1267 # uint
1.5, 0.15e1, 15e-1, 0x1.8p0, 0x18p-4 F9 3E00 # float16
0, -0 00      # uint
0.0, F9 0000 # float16
-0.0 F9 8000 # float16
Infinity F9 7C00 # float16
-Infinity F9 FC00 # float16
NaN F9 7E00 # float16
The non-finite floating-point values Infinity, -Infinity, and NaN are written exactly as in this sentence (this is also a way they can be written in JavaScript, although JSON does not allow them). NaN in CDN stands for the NaN value with a zero sign bit and an all-zero significand except for a set quiet bit; this is represented as F9 7E 00 in CBOR Preferred Serialization. See item in the bullet list at the end of for additional details of the CDN number syntax. (Note that literals for further number formats, e.g., for representing rational numbers as fractions, or for other NaN values than the one called NaN, can be added as app-extensions. Background information beyond that in about the representation of numbers in CBOR can be found in the informational document .)
Strings CBOR distinguishes two kinds of strings: text strings (the bytes in the string constitute UTF-8 text, major type 3), and byte strings (CBOR does not further characterize the bytes that constitute the string, major type 2). (UTF-8) text strings can be directly represented (unprefixed) in CDN either as double-quoted () or as raw strings (), while byte strings can be represented as single-quoted strings (). The latter is useful for byte strings carrying bytes that can be meaningfully notated as UTF-8 text. Many strings are best notated as prefixed literals, which may provide detailed access to the bits within those bytes (see ). Using an app-extension prefix, prefixed literals can be constructed out of single-quoted strings and raw strings, as well as sequence literals (cf. ).
Double-Quoted String Literals CDN enables notating text strings in a form compatible to that of notating text strings in JSON (i.e., as a double-quoted string literal), with a number of usability enhancements. JSON allows no control characters in text-string literals; if needed, they can be specified using escapes such as \t or \r. This also applies to CDN, and all escaping rules apply as in JSON, with a single exception: In CDN, string literals additionally can contain newlines (LINEFEED U+000A), which are copied into the resulting string like other characters in the string literal. To deal with variability in platform presentation of newlines, any carriage return characters (U+000D) that may be present in the CDN string literal are not copied into the resulting string (see ). JSON's escape scheme for characters that are not on Unicode's basic multilingual plane (BMP) is cumbersome (see Section of RFC 8259 ). CDN keeps it, but also adds the syntax \u{NNN} where NNN is the Unicode scalar value as a hexadecimal number. This means the following are equivalent (the first o is escaped as \u{6f} for no particular reason):
Single-Quoted String Literals Analogously to text-string literals delimited by double quotes, CDN allows the use of single quotes (without a prefix) to express byte-string literals with UTF-8 text; for instance, the following are equivalent: The escaping rules of JSON strings are applied equivalently for text-based byte-string literals, e.g., \\ stands for a single backslash and \' stands for a single quote. However, to facilitate parsing, in single-quoted strings CDN excludes certain escaping mechanisms available for double-quoted strings:
  • \/ is an escape in JSON that is available for double-quoted CDN text strings as well to ensure all JSON texts are CDN literals. Since CDN's single-quoted strings do not occur in JSON, this legacy compatibility feature is not available for them.
  • \u-based escapes are not available for characters in the range from U+0020 through U+007E (essentially, printable ASCII).
All other escaping mechanisms that are available in double-quoted string literals are available in single-quoted string literals. Single-quoted string literals can occur unprefixed and stand for the byte string that encodes its text string value (the "content"), or be prefixed by what looks like an app-extension prefix (see ). In a prefixed string literal, the text content of the single-quoted string literal is not used directly as a byte string, but is further processed in a way that is defined by the meaning given to the prefix. Depending on the prefix, the result of that processing can, but often is not, a byte string value. Prefixed string literals (whether single-quoted after the prefix or a raw string ()) are used for prefixed literals (see , such as base-encoded byte string literals (see ). (Additional kinds of base-encoded string literals can be defined as prefixed literals by registering their prefixes; there is no fundamental difference between the original two predefined base-encoded string literal prefixes (: h, b64) and any such potential future extension literal prefixes; for simplicity of expression, both cases are referred to as "prefixed literals".)
Raw String Literals Both double-quoted and single-quoted string literals handle backslashes in a special way. For string data items that employ backslashes themselves, possibly with additional layers of processing giving this "escaping" mechanism specific application semantics, this can lead to an exponential duplication of backslashes that has informally been described as "quoting hell". CDN therefore also allows text strings to be notated as raw string literals, which do not perform any special processing on backslashes, i.e., treat them as raw string content like any other characters. Instead, data transparency is provided by enclosing the entire string content in starting and ending delimiters built as a sequence of one or more backquote (»`«, U+0060 GRAVE ACCENT) characters. For example, the string content »[^ \t\n\r"'`]«, an I-Regexp character class that excludes blank space and quoting characters, can be notated as: instead of By using more backquotes for each of the outer delimiters than the longest sequence of backquotes that can be found in the string, internal backquotes do not prematurely end the string literal. An example for a raw string that contains a double backquote and therefore is notated starting and ending with a triple backquote: This mechanism is easy to use for the large majority of cases. However, without additional rules:
  • raw strings could not be used for empty string data items, which therefore need to be notated using double- or single-quoted strings. (Obviously, there is no need to escape the content of empty strings, so this should not be a problem.)
  • raw strings could not be used for string data items that start or end with backquotes, as these would amalgamate with the start and end delimiters.
To address these cases (predominantly the latter), two additional rules are added to perform after processing the backquotes used as delimiters:
  • any single newline (LF or CRLF, see ) at the start of the inner string is removed to yield the string content. As a result: can also be expressed as In addition to enabling leading backquotes in raw strings, this can be very useful for documentation strings etc. This rule also allows notating »``text''« as:
  • if the first rule does not apply, but the inner string starts with a space character as well as ends with one, exactly one single space character starting the inner string together with exactly one single space character ending the inner string are removed to yield the string content. This allows notating »a = ``foo``« as:
If neither of these rules apply, the inner string between the raw delimiters is used as the raw string unchanged. (The examples given here are minimal in that they show how the additional rules work; more complex examples would be necessary to provide additional motivation why this is a good way to handle the various cases.)
CBOR Sequence Literals In diagnostic notation, a sequence of zero or more CBOR data item literals can be enclosed in << and >> and separated by comma or blank space, optionally prefixed by an app-extension prefix; this specification speaks of sequence literals. CDN mainly deals with individual data items, not with CBOR sequences , so the CBOR sequence represented by the sequence literal needs to be further processed to obtain the value of the literal. Prefixed sequence literals refer to the app-extension (see ) identified by the prefix and apply the extension to its sequence content, resulting in a single data item. This data item may be a string or not (always), depending on the definition of the app-extension. An unprefixed sequence literal applies CBOR encoding to the data items in its content, taken as a CBOR sequence. The value of the literal thus is a byte string with the encoded content; this is commonly referred to as embedded CBOR. For instance, each pair of columns in the following are equivalent: > h'01' <<1, 2>> h'0102' <<"hello", null>> h'65 68656c6c6f f6' <<>> h'' ]]> A diagnostic implementation is expected to honor encoding indicators (please see ) on the individual items in the supplied sequence before assembling them into an encoded CBOR sequence. For instance, each pair of columns in the following are equivalent: > h'190001' <<1_0, 2_2>> h'1801 1a00000002' <<"hello"_0, null>> h'7805 68656c6c6f f6' ]]> For prefixed sequence literals, the processing of arguments that use specific encoding variants can be defined by the app-extension being used. See for an example of where this is done. Encoding indicators on the arguments are ignored if the app-extension does not define special handling of encoding variants.
Validity of Text Strings To be valid CBOR, Section of RFC 8949 requires that text strings are byte sequences in UTF-8 form. CDN provides several ways to construct such byte strings (in particular, see also ). These mechanisms might operate on subsequences that do not themselves constitute UTF-8, e.g., by building larger sequences out of concatenating the subsequences; for validity of a text string resulting from these mechanisms it is only of importance that the result is UTF-8. Double-quoted, single-quoted, and raw string literals have been defined such that they lead to byte sequences that are UTF-8: the source language of CDN is UTF-8, and all escaping mechanisms lead only to adding further UTF-8 characters. Only app-extensions (invoked in prefixed literals) can generate non-UTF-8 byte sequences. As discussed at the start of , CDN implementations MAY support generation and possibly ingestion of CDN for CBOR data items that are well-formed but not valid; when this is enabled, such implementations MAY relax the requirement on text strings to be valid UTF-8. CBOR has no requirements for its text strings except for conformance to . The same applies to CDN and its source language. No additional Unicode processing or validation such as normalization or checking whether a scalar value is actually assigned is foreseen by CDN, particularly not any processing that is dependent on a specific Unicode version. Such processing, if offered, MUST NOT get in the way of processing the data item represented in CDN (i.e., it may be appropriate to issue warnings but not to error out or to generate output that does not match the input at the UTF-8 level).
Arrays and Maps CDN borrows the JSON syntax for arrays and maps. (Maps are called objects in JSON.) For maps, CDN extends the JSON syntax by allowing any data item in the map key position (before the colon).
Mandatory Separators, Optional Terminators JSON requires the use of a comma as a separator character between the elements of an array as well as between the members (key/value pairs) of a map. (These commas also were required in the original diagnostic notation defined in and .) The separator commas are now optional in the places where CDN syntax allows commas; however, where no comma is used in a separator position, there must be blank space (composed of at least one space, newline, and/or comment) instead. (Stylistically, leaving out the commas is more idiomatic when they occur at line breaks, which provide the blank space.) In addition, CDN also allows, but does not require, a trailing comma before the closing bracket/brace, enabling an easier to maintain "terminator" style of their use. In summary, the following eight examples are all equivalent: as are As a comma and/or blank/comment is mandatory in a separator position, »[11]« is unambiguously an array with a single element (the integer 11), different from »[1 1]« or »[1,1]«. As this is a general rule, »[[] []]« or »[[],[]]« are well-formed CDN, while »[[][]]« is not.
Validity of Maps As discussed at the start of , CDN implementations MAY support generation and possibly ingestion of CDN for CBOR data items that are well-formed but not valid (Section of RFC 8949 ). For maps, this is relevant for map keys that occur more than once, as in this CDN that is not representing a valid CBOR data item:
Tags A tag is written as a decimal unsigned integer (no leading zeros except for the actual tag number zero, i.e., 0|[1-9][0-9]*) for the tag number, followed by the tag content in parentheses; for instance, a date in the format specified by RFC 3339 (ISO 8601) could be notated as: 0("2013-03-21T20:04:00Z") or the equivalent epoch-based time: 1(1363896240) The tag number can be followed by an encoding indicator giving the encoding of the tag head. For example, a diagnostic implementation encodes: 1_1(1363896240) ...(assuming Preferred Serialization for the tag content) as:
Simple values CDN uses JSON syntax for the simple values True (»true«), False (»false«), and Null (»null«). Undefined is written »undefined« as in JavaScript. These and all other simple values can be given as "simple()" with the appropriate decimal unsigned integer (0|[1-9][0-9]*) in the parentheses. For example, »simple(42)« indicates major type 7, value 42, and »simple(20)« indicates »false«.
Prefixed Literals After a short overview of prefixed literals in general, this section defines a number of app-extensions included with this specification. Prefixed literals start with a prefix that identifies the app-extension and possibly a specific variant of that, immediately followed by a sequence literal () or a single-quoted or raw string literal (). The string-based forms use their string literal as a shorthand form for a sequence literal representing a sequence with exactly that one text string data item, e.g., b64`Zm9v` is a shorthand for b64<<"Zm9v">> or b64<<`Zm9v`>> (this specific example obviously depends on Zm9v being allowed and meaning the same within the different forms of string literals used in the example). More precisely, an app-extension identifier is a registered name consisting of a lowercase ASCII letter ([a-z]) and zero or more additional ASCII characters that are either lowercase letters, digits, or hyphens ([a-z0-9-]). »false«, »true«, »null«, and »undefined« cannot be used as such identifiers and are reserved. app-extension identifiers are registered in the "App-Extension Identifiers" registry (). An app-extension (such as dt) MAY also define the meaning of one additional prefix derived from its app-extension identifier by replacing each lowercase character by its uppercase counterpart (such as DT). As a convention, using the all-uppercase variant implies making use of a CBOR tag appropriate for this app-extension (such as tag number 1 for DT, where in contrast the prefix dt stands for the unwrapped tag content). In summary, an app-extension identifier gives rise to one or two prefixes, one that is lexically identical to the identifier (i.e., all lowercase), and potentially another one that is an all-uppercase variation of it. In addition to specifying which of these two variations exhibits which specific semantics, the app-extension specifies what input the extension takes. When the prefix is used immediately in front of a single-quoted or a raw string, the input takes the form of a single text string CBOR data item (this is useful only if the app-extension is designed to receive a text string as input). When used immediately in front of a sequence literal, the input is a CBOR sequence of elements of the sequence literal as input. (For a single parameter, this is equivalent to receiving a single CBOR data item as the argument.) The app-extension can provide behavior that depends on the number of items supplied as input to it and their data types; it cannot distinguish between its prefix being used with a single-quoted string, a raw string, or a CBOR sequence composed of a single text string data item (as illustrated for instance in Tables , , and ). This specification defines a number of generally applicable app-extensions (), both to motivate making these extensions generally available, and to illustrate the concept. Of these, the app-extensions h, b64, t1, b1, dt and ip are mandatory to implement. (As mentioned, for simplicity we use the term "app-extensions" for the mechanism discussed in this section even if it is used to describe a part of base CDN.)
Base-Encoded Byte String Literals: h and b64 Besides the unprefixed byte string literals that are analogous to JSON text string literals, CDN provides prefixed literals that can represent byte strings by base-encoding them, typically notated as prefixed string literals. The app-extension identifier selects one of the base encodings , without padding. Most often, the base encoding is enclosed in a single-quoted or raw string literal, prefixed by »h« for base16 or »b64« for base64 or base64url (the actual encodings of the latter two have the same meaning where they overlap, so the string remains unambiguous). For example, the byte string consisting of the four bytes 12 34 56 78 (given in hexadecimal here) could be written h'12345678' or b64'EjRWeA' when using single-quoted string literals, or h`12345678` or b64`EjRWeA` when using raw string literals. Examples often benefit from some blank space (spaces, line breaks) in byte string literals. In the base-encoded byte string literals, blank space is ignored in the input; for instance, the following are equivalent: The internal syntax of prefixed single-quote literals such as h'' and b64'' also allow comments as blank space (see ). Slash characters are part of the base64 classic alphabet (see Table 1 in ), and they therefore need to be in the b64'' set of characters that contribute to the byte string. Therefore, only end-of-line comments starting with # are available inside b64 byte string literals. These two byte string literals stand for the same byte string; the deliberately confusing base64 content starts with b64'/bas' which is the same as h'FDB6AC' and ends with b64'lows' which is the same as h'968C2C'.
Date and Time: dt The app-extension identifier "dt" is used to notate a date/time literal that can be used as an Epoch-Based Date/Time as per Section of RFC 8949 . The content of the literal is a single Standard Date/Time String as per Section of RFC 8949 , as a text or byte string. The value of the literal is a number representing the result of a conversion of the given Standard Date/Time String to an Epoch-Based Date/Time. If fractional seconds are given in the text (production time-secfrac in ), the value is a floating-point number; the value is an integer number otherwise. In the all-uppercase variant of the app-prefix, the value is enclosed in a tag number 1. Each row of shows an example of "dt" notation and equivalent notation not using a prefixed literal. dt and DT literals vs. plain CDN
dt literal plain CDN
dt'1969-07-21T02:56:16Z' -14159024
dt'1969-07-21T02:56:16.0Z' -14159024.0
dt'1969-07-21T02:56:16.5Z' -14159023.5
dt`1969-07-21T02:56:16.5Z` -14159023.5
dt<<'1969-07-21T02:56:16.5Z'>> -14159023.5
dt<<"1969-07-21T02:56:16.5Z">> -14159023.5
dt<<`1969-07-21T02:56:16.5Z`>> -14159023.5
DT'1969-07-21T02:56:16Z' 1(-14159024)
See for an ABNF definition for the text string input of dt literals.
IP Addresses and Related Structures: ip The app-extension identifier "ip" is used to notate an IP address literal that can be used as an IP address as per . The input of the literal is a single text string representing an IPv4address or IPv6address as per . With the lowercase app-string prefix ip, the value of the literal is a byte string representing the binary IP address. With the uppercase app-string prefix IP, the literal is such a byte string tagged with tag number 54, if an IPv6address is used, or tag number 52, if an IPv4address is used. As an additional case, the uppercase app-string prefix IP can be used with an IP address prefix such as 2001:db8::/56 or 192.0.2.0/24, with the equivalent tag as its value. (Note that representations of address prefixes need to implement the truncation of the address byte string as described in ; see example below.) For completeness, the lowercase variant ip'2001:db8::/56' or ip'192.0.2.0/24' stands for an unwrapped [56,h'20010db8'] or [24,h'c00002']; however, in this case the information on whether an address is IPv4 or IPv6 often needs to come from the context. Note that this app-extension provides no direct representation of the "Interface format" defined in , an address combined with an optional prefix length and an optional zone identifier, and therefore no way to reference a zone identifier at all. (If needed, this format can be put together by building their structures explicitly, e.g., an interface format without a zone identifier can be represented as in 52([ip'192.0.2.42',24]), or an interface format with zone identifier 42 as in 54([ip'fe80::0202:02ff:ffff:fe03:0303',64,42]).) Each row of shows an example of "ip" notation and equivalent notation not using a prefixed literal. ip and IP literals vs. plain CDN
ip literal plain CDN
ip'192.0.2.42' h'c000022a'
ip<<'192.0.2.42'>> h'c000022a'
IP'192.0.2.42' 52(h'c000022a')
IP'192.0.2.0/24' 52([24,h'c00002'])
ip'2001:db8::42' h'20010db8000000000000000000000042'
IP'2001:db8::42' 54(h'20010db8000000000000000000000042')
IP'2001:db8::/64' 54([64,h'20010db8'])
See for an ABNF definition for the content of ip literals.
Cryptographic Hash Values: hash The app-extension identifier "hash" is used to notate the input to a cryptographic hash function as well as to identify such a hash function. Its value is a byte string that represents the output of that hash function. The input of the literal is a (text or byte) string, optionally followed by either an integer or a text string that identifies the hash function in the COSE Algorithms registry of the CBOR Object Signing and Encryption (COSE) registry group , either by the identifier (value: integer or string), or, if no algorithm is registered with this value, by its name used in the registry. If the second item is not given, the default algorithm used is -16 ("SHA-256"). No uppercase variant prefix is defined for the app-extension identifier "hash". hash literals vs. plain CDN
hash literal plain CDN
hash<<'foo'>> h'2C26B46B68FFC68FF99B453C1D304134
13422D706483BFA0F98A5E886266E7AE'
hash'foo' h'2C26B46B68FFC68FF99B453C1D304134
13422D706483BFA0F98A5E886266E7AE'
hash<<'foo', -16>> h'2C26B46B68FFC68FF99B453C1D304134
13422D706483BFA0F98A5E886266E7AE'
hash<<'foo', "SHA-256">> h'2C26B46B68FFC68FF99B453C1D304134
13422D706483BFA0F98A5E886266E7AE'
hash<<'foo', -44>> h'F7FBBA6E0636F890E56FBBF3283E524C
6FA3204AE298382D624741D0DC663832
6E282C41BE5E4254D8820772C5518A2C
5A8C0C7F7EDA19594A7EB539453E1ED7'
hash<<'foo', "SHA-512">> h'F7FBBA6E0636F890E56FBBF3283E524C
6FA3204AE298382D624741D0DC663832
6E282C41BE5E4254D8820772C5518A2C
5A8C0C7F7EDA19594A7EB539453E1ED7'
String Concatenation: b1 and t1 This section uses the placeholders t1 and b1 as provisional app-extension identifiers, allowing the text to stabilize while the actual names are still being decided by the WG. The "b1" and "t1" app-extensions allow a (byte or text) string to be built up from multiple (byte or text) string literals; these are then concatenated into a single string. The following four text string values (adapted from ) are equivalent: > t1<<"Hello", h'20', "world">> t1<> ]]> Similarly, the following byte string values are equivalent: b1<<'Hello ', 'world'>> b1<<'Hello ', h'776f726c64'>> b1<<'Hello', h'20', 'world'>> b1<> b1<> ]]> As the examples show, text strings and byte strings can mix within such a concatenation, so that, for instance, byte string literal notation can be used inside a sequence of concatenated text string notation literals, to encode characters that may be better represented in an encoded way. This is realized by simply joining together the bytes in the sequence of string arguments to the b1/t1 app-extension, proceeding from left to right. For "b1", the joining operation results in a byte string. For "t1", the joining operation results in a text string, and the result therefore needs to be valid UTF-8 except for "diagnostic" implementations that support and are enabled for generation/ingestion of CDN for CBOR data items that are well-formed but not valid; see also .
Creating Indefinite-length Encoded Strings: ilbs and ilts The ilbs and ilts app-extensions are semantically identical to t1 and b1 at the data model level, but instead of concatenating the arguments to a single (byte/text) string data item, they build an indefinite length string out of the arguments, with one chunk of the correct major type (byte string/text string for ilbs/ilts, respectively) created per argument. A diagnostic implementation would honor encoding indicators on each of the arguments, creating a chunk with the same encoding. As the app-extension is already implying indefinite length encoding, there is no point in applying an encoding indicator to the entire prefixed literal. > 5f ff ilbs<<"Hello world">> 5f 4b 48656c6c6f20776f726c64 ff ilbs<<'Hello ', "world">> 5f 46 48656c6c6f20 45 776f726c64 ff ilbs<<'Hello '_0, 'world'>> 5f 5806 48656c6c6f20 45 776f726c64 ff ]]> There is no way to include ellipses in an indefinite length string.
Floating-Point Values: float The "float" app-extension enables the notation of 2-byte, 4-byte, and 8-byte byte strings to express floating point values (mt=7, ai=25/26/27 respectively) by giving their IEEE 754 representation. A text string used as an argument is interpreted exactly as a hex literal (like the h prefix); the result is used as the byte string. The prefixed literal is interpreted as an encoded data item would be that prefixes the byte string by a single byte 0xF9 (2 bytes, i.e., binary16), 0xFA (4 bytes, i.e., binary32), and 0xFB (8 bytes, i.e., binary64), respectively. Byte strings of a different length than 2, 4, or 8 raise an error. Note that the interpretation as an encoded data item does not create or imply an encoding indicator; that can be added separately. Example (tool used: edn-abnf -afloat -e): The purpose of this app-extension is to close a gap in CDN's binary64 support: Without this (or a similar) extension there is no way to represent NaN values different from the one called out at the end of Section of RFC 8949 : "(for many applications, the single NaN encoding 0xf97e00 will suffice)". For finite floating point numbers, the decimal or hex floating point representations are preferred.
Encoding Indicators Sometimes it is useful to indicate in the diagnostic notation which of several alternative CBOR representations are actually used; for example, a data item written »1.5« by a diagnostic decoder might have been encoded in CBOR as a half-, single-, or double-precision float. Encoding indicators are always optional: CDN is usually used to describe CBOR data items at the data model level. For some diagnostic purposes, it is useful to represent the choice of a serialization variation by including encoding indicators. Implementations of CDN generally do not need to provide this functionality in full; if they do, they can be called "diagnostic implementations". To be able to process CDN that contains encoding indicators, a CDN-consuming implementation MUST accept them (i.e., process or ignore the presence or absence of each encoding indicator). It is RECOMMENDED to provide a warning for each encoding indicator value that is encountered but not further processed. When creating CDN as input for a diagnostic CBOR encoder in order to obtain specific encoding choices, encoding indicators may be placed manually or by the software generating the CDN. Where no encoding indicator is placed, a diagnostic CBOR encoder is expected to generate Preferred Serialization (Section of RFC 8949 ) with definite-length encoding only. Similarly, when using CDN as output for a diagnostic CBOR decoder, a basic diagnostic configuration of the tool is expected to provide encoding indicators only in places where the CBOR input did not use Preferred Serialization with definite-length encoding (see also ). Diagnostic implementations of CDN that process encoding indicators as discussed here are expected to document their diagnostic behavior and the processing options that can be selected.
Syntax, Semantics, Examples Encoding indicators () start with an underscore, often followed by alphanumeric characters. For example, _ or _3. Encoding indicators indicate the specific CBOR encoding that was used, or is to be used, to represent a specific CBOR data item. This specification defines six encoding indicators. Additional encoding indicators could be defined in future standards track updates to this specification. Encoding Indicators Defined by This Specification
Encoding Indicator Description Reference
_ Indefinite-Length Encoding (ai=31) RFC8949, RFC-XXXX
_i ai=0 to ai=23 RFC-XXXX
_0 ai=24 RFC8949, RFC-XXXX
_1 ai=25 RFC8949, RFC-XXXX
_2 ai=26 RFC8949, RFC-XXXX
_3 ai=27 RFC8949, RFC-XXXX
Encoding indicators can be ignored by anyone not interested in this information. Encoding indicators are placed immediately to the right of the data item or of a syntactic feature that can stand for the data item the encoding of which the encoding indicator is controlling. provides examples for data items with definite length encoding indicators used with various kinds of data items ("mt" = major type, "ignoring e.i." = example encoding when ignoring the encoding indicators). Examples for encoding indicators controlling indefinite length encoding can be found in the context of explanations in and . Examples of Definite Length Encoding Indicators for Different Data Items
mt examples encoding (in hex) ignoring e.i.
0 1_1
0x4711_3		 190001
1b0000000000004711		 01
194711
1 -1_1 390000 20
2 'A'_1 59000141 4141
3 "A"_1 79000161 6161
4 [_1 "bar"] 99000163626172 8163626172
5 {_1 "bar": 1} b900016362617201 a16362617201
6 1_1(4711) d90001191267 c1191267
7 1.5_2
0x4711p+03_3		 fa3fc00000
fb4101c44000000000		 f93e00
fa480e2200
(In the following, an abbreviation of the form ai=nn gives nn as the numeric value of the field additional information, the low-order 5 bits of the initial byte: see Section of RFC 8949 . This field is used in encoding the "argument", i.e., the value, tag, or length; ai=0 to ai=23 mean that the value of the ai field immediately is the argument, ai=24 to ai=27 mean that the argument is carried in 2ai-24 (1, 2, 4, or 8) additional bytes, and ai=31 means that indefinite-length encoding is used.) An underscore followed by a decimal digit n indicates that the item was or is to be encoded with an additional information value of ai=24+n. (The item associated to the encoding indicator may be the preceding item, or, for arrays and maps, the item starting with the preceding bracket or brace.) For an example involving floating point values (Section of RFC 8949 ), 1.5_1 is a half-precision floating-point number (21 = 2 additional bytes or 16 bits), while 1.5_3 is encoded as double precision (23 = 8 additional bytes or 64 bits). For a tool consuming CDN in a diagnostic mode, encountering an encoding indicator that does not provide enough space to correctly encode the unchanged data item given is an error; there is no truncation or rounding that would change the data item encoded. The encoding indicator _ (an underscore on its own) is used to indicate indefinite-length encoding. Indefinite-length encoding uses ai=31, which could have been indicated by _7, which is therefore not used and marked as reserved (as are _4, _5, and _6, which would stand for ai=28 to ai=30, values currently not in use in CBOR; these encoding indicators will be available if and when CBOR is extended to make use of them). Note that the encoding indicator _ is only available behind the opening brace/bracket for map and array (): strings originally had a now deprecated special syntax streamstring for indefinite-length encoding except for the special cases ''_ and ""_ (). The encoding indicators _0 to _3 indicate ai=24 to ai=27, respectively; they therefore stand for 1, 2, 4, and 8 bytes of additional information (ai) following the initial byte in the head of the data item. Section of RFC 8949 does not address ai=0 to ai=23 — the assumption seems to have been that Preferred Serialization (Section of RFC 8949 ) will be used when converting CBOR diagnostic notation to an encoded CBOR data item, so leaving out the encoding indicator for a data item with a Preferred Serialization will implicitly use ai=0 to ai=23 if that is possible. The present specification allows making this explicit: _i ("immediate") stands for encoding with ai=0 to ai=23, i.e., it indicates that the argument is encoded directly in the initial byte of the CBOR item. Specific forms of encoding indicators are discussed in further detail in for arrays and maps and in for the deprecated syntax for indefinite-length strings.
Encoding Indicators of Arrays and Maps A single underscore can be written after the opening brace of a map or the opening bracket of an array to indicate that the data item was represented in indefinite-length format. For example, [_ 1, 2] contains an indicator that an indefinite-length representation was used to represent the data item [1, 2]. At the same position, encoding indicators for specifying the size of the array or map head for definite-length format can be used instead, specifically _i or _0 to _3. For example, [_0 false, true] can be used to specify the encoding of the array [false, true] as 98 02 f4 f5.
Deprecated: Indefinite-length Encoding Indicators for Strings In CBOR, indefinite-length encoded (byte or text) strings are composed of "chunks" (Section of RFC 8949 ). The original diagnostic notation () provided a special syntax streamstring for them, which was retained and further clarified in Section of RFC 8949 . This syntax represents the individual chunks in sequence within parentheses, each optionally followed by a comma, with an encoding indicator _ immediately after the opening parenthesis: e.g., (_ h'0123', h'4567') or (_ "foo", "bar"). The overall type (byte string or text string) of the string is provided by the types of the individual chunks, which all need to be of the same type (Section of RFC 8949 ). In this syntax, an indefinite-length string with no chunks inside, (_ ) would be ambiguous as to whether a byte string (encoded 5f ff) or a text string (encoded 7f ff) is meant and is therefore not used. The basic forms ''_ and ""_ can be used instead and are reserved for the case of no chunks only — not as short forms for the (permitted, but not really useful) encodings with only empty chunks, which need to be notated as (_ ''), (_ ""), etc., when it is desired to preserve the chunk structure. With this document, the streamstring syntax is now deprecated; new CDN documents should instead use the ilbs/ilts app-extensions () to build indefinite-length encoded strings.
ABNF Definitions This section collects grammars in ABNF form ( as extended in ) that serve to define the syntax of CDN and some prefixed literals.
Overall ABNF Definition for Concise Diagnostic Notation This subsection provides an overall ABNF definition for the syntax of concise diagnostic notation. For simplicity, the internal parsing for the built-in CDN prefixes is specified in the same way. ABNF definitions for h''/h`` and b64''/b64`` are provided in and .
Overall ABNF Definition of CDN >" array = "[" (specms S item *(MSC item) SOC / spec S) "]" map = "{" (specms S keyp *(MSC keyp) SOC / spec S) "}" keyp = item S ":" S item ; We allow %x09 HT in prose, but not in string literals blank = %x09 / %x0A / %x0D / %x20 lblank = %x0A / %x20 ; Not HT or CR (gone) non-slash = blank / %x21-2e / %x30-7F / NONASCII non-slash-star = blank / %x21-29 / %x2b-2e / %x30-7F / NONASCII non-star = blank / %x21-29 / %x2b-7F / NONASCII ends-in-star = *non-star 1*"*" non-lf = %x09 / %x0D / %x20-7F / NONASCII eol-comment = "#" / "//" comment = "/" non-slash-star *non-slash "/" / "/*" ends-in-star *(non-slash-star ends-in-star) "/" / eol-comment *non-lf %x0A ; optional space S = *blank *(comment *blank) ; mandatory space MS = (blank/comment) S ; mandatory comma and/or space MSC = ("," S) / (MS ["," S]) ; optional comma and/or space SOC = S ["," S] streamstring = "(_" MS string *(MSC string) SOC ")" spec = ["_" [specchar]] specms = ["_" [specchar] MS] specchar = %s"i" / %x30-33 / reserved-ei reserved-ei = 1*wordchar ; reserved for standards track use double-quoted = unescaped / SQUOTE / "\" escapable-d single-quoted = unescaped / DQUOTE / "\" escapable-s escapable1 = %s"b" ; BS backspace U+0008 / %s"f" ; FF form feed U+000C / %s"n" ; LF line feed U+000A / %s"r" ; CR carriage return U+000D / %s"t" ; HT horizontal tab U+0009 / "\" ; \ backslash (reverse solidus) U+005C escapable-d = escapable1 / DQUOTE / "/" ; / slash (solidus) U+002F (JSON!) / (%s"u" hexchar) ; uXXXX U+XXXX escapable-s = escapable1 / SQUOTE / (%s"u" hexchar-s) ; uXXXX U+XXXX hexchar = "{" (1*"0" [ hexscalar ] / hexscalar) "}" / non-surrogate / two-surrogate non-surrogate = ((DIGIT / "A"/"B"/"C" / "E"/"F") 3HEXDIG) / ("D" ODIGIT 2HEXDIG ) two-surrogate = high-surrogate "\" %s"u" low-surrogate high-surrogate = "D" ("8"/"9"/"A"/"B") 2HEXDIG low-surrogate = "D" ("C"/"D"/"E"/"F") 2HEXDIG hexscalar = "10" 4HEXDIG / HEXDIG1 4HEXDIG / non-surrogate / 1*3HEXDIG ; single-quote hexchar-s: don't allow 0020..007e hexchar-s = "{" (1*"0" [ hexscalar-s ] / hexscalar-s) "}" / non-surrogate-s / two-surrogate non-surrogate-s = "007F" ; rubout / "00" ("0"/"1"/"8"/"9"/HEXDIGA) HEXDIG / "0" HEXDIG1 2HEXDIG / non-surrogate-1 non-surrogate-1 = ((DIGIT1 / "A"/"B"/"C" / "E"/"F") 3HEXDIG) / ("D" ODIGIT 2HEXDIG ) hexscalar-s = "10" 4HEXDIG / HEXDIG1 4HEXDIG / non-surrogate-1 / HEXDIG1 2HEXDIG / ("1"/"8"/"9"/HEXDIGA) HEXDIG / "7F" / HEXDIG1 ; Note that no other C0 characters are allowed, including %x09 HT unescaped = %x0A ; new line / %x0D ; carriage return -- ignored on input / %x20-21 ; omit 0x22 " / %x23-26 ; omit 0x27 ' / %x28-5B ; omit 0x5C \ / %x5D-7F / NONASCII newline = [%x0D] %x0A DQUOTE = %x22 ; " double quote SQUOTE = "'" ; ' single quote DIGIT = %x30-39 ; 0-9 DIGIT1 = %x31-39 ; 1-9 ODIGIT = %x30-37 ; 0-7 BDIGIT = %x30-31 ; 0-1 HEXDIGA = "A" / "B" / "C" / "D" / "E" / "F" ; Note: double-quoted strings as in "A" are case-insensitive in ABNF HEXDIG = DIGIT / HEXDIGA HEXDIG1 = DIGIT1 / HEXDIGA lcalpha = %x61-7A ; a-z lcldh = lcalpha / DIGIT / "-" ucalpha = %x41-5A ; A-Z ucldh = ucalpha / DIGIT / "-" ALPHA = lcalpha / ucalpha wordchar = "_" / ALPHA / DIGIT ; [_a-z0-9A-Z] NONASCII = %x80-D7FF / %xE000-10FFFF ]]>
Any input that matches "//" in eol-comment raises an error. While an ABNF grammar defines the set of character strings that are considered to be valid CDN by this ABNF, the mapping of these character strings into the generic data model of CBOR is not always obvious. The following additional items should help in the interpretation:
  1. As mentioned in the terminology (), the ABNF terminal values in this document define Unicode scalar values (characters) rather than their UTF-8 encoding. For example, the Unicode PLACE OF INTEREST SIGN (U+2318) would be defined in ABNF as %x2318.
  2. See for more considerations about the character repertoire used for CDN source text and, in particular, the special handling of newline characters in the source.
  3. Numbers: Any number that starts with a "+" sign (rule sign) raises an error.
    1. decnumber stands for an integer in the usual decimal notation, unless at least one of the optional parts starting with "." and "e" are present, in which case it stands for a floating point value in the usual decimal notation. Note that the grammar allows 3. for 3.0 and .3 for 0.3 (also for hexadecimal floating point below); implementers are advised that some platform numeric parsers accept only a subset of the floating point syntax in this document and may require some preprocessing to use here.
    2. hexint, octint, and binint stand for an integer in the usual base 16/hexadecimal ("0x"), base 8/octal ("0o"), or base 2/binary ("0b") notation. hexfloat stands for a floating point number in the usual hexadecimal notation (which uses a mantissa in hexadecimal and an exponent in decimal notation, see Section 5.12.3 of , Section 6.4.4.3 of , or Section 5.13.4 of ; floating-suffix/floating-point-suffix from the latter two is not used here).
    3. For hexint, octint, binint, and when decnumber stands for an integer, the corresponding CBOR data item is represented using major type 0 or 1 if possible, or using tag 2 or 3 if not. In the latter case, this specification does not define any encoding indicators that apply. If fine control over encoding is desired, this can be expressed by being explicit about the representation as a tag: E.g., 987654321098765432310, which is equivalent to 2(h'35 8a 75 04 38 f3 80 f5 f6') in its Preferred Serialization, might be written as 2_3(h'00 00 00 35 8a 75 04 38 f3 80 f5 f6'_1) if leading zeros need to be added during serialization to obtain specific sizes for tag head, byte string head, and the overall byte string.
    4. When decnumber stands for a floating point value, and for hexfloat and nonfin, a floating point data item with major type 7 is used; diagnostic implementations employ Preferred Serialization unless the item was modified by an encoding indicator, which then needs to be _1, _2, or _3. For this, the number range needs to fit into an binary64 (or the size corresponding to the encoding indicator), and the precision will be adjusted to binary64 before further applying Preferred Serialization (or to the size corresponding to the encoding indicator). Tag 4/5 representations are not generated in these cases. Future app-prefixes could be defined to allow more control for obtaining a tag 4/5 representation directly from a hex or decimal floating point literal.
  4. spec stands for an encoding indicator. See for details.
  5. The ABNF grammar for raw strings is lenient; a parser needs to implement the ABNF comments on alikerawdelim and shortrawdelim as well. Any input that matches a startrawdelim of more than 8 characters raises an error. shortrawdelim only matches sequences of backquotes that are shorter than startrawdelim. alikerawdelim only matches sequences of backquotes that are exactly as long as startrawdelim.
ABNF Definitions for App-Extension Content This subsection provides ABNF definitions for the content of prefixed literals defined in and in this specification, where applicable. These grammars describe the decoded content of the single-quoted or raw string components that combine with prefixes to form prefixed literals. Each of these may integrate ABNF rules defined in , which are not always repeated here. summarizes the app-prefix values defined in this document. App-prefix Values Defined in this Document
app-prefix content of single-quoted or raw string result type
h hexadecimal form of binary data byte string
H (not used)  
b64 base64 forms (classic or base64url) of binary data byte string
B64 (not used)  
dt RFC 3339 date/time number (int or float)
DT " Tag 1 on the above
ip IP address or prefix byte string,
array of length and byte string
IP " Tag 54 (IPv6) or 52 (IPv4) on the above
hash string (usually used with sequences) byte string
HASH (not used)  
t1 strings (usually used with sequences) text string
T1 (not used)  
b1 strings (usually used with sequences) byte string
B1 (not used)  
float floating point value from input bytes floating point value (mt=7)
FLOAT (not used)  
Note that implementation platforms may already provide implementations of grammars used in app-extensions, such as of RFC 3339 for dt'' and of IP address syntax for ip''. CDN-based tools may want to use these implementation libraries instead of using the grammars that are provided here as a reference. For convenience, the common definitions in are not repeated in the below ABNF grammars.
Common Rules Used in app-extension ABNF grammars
h: ABNF Definition of Hexadecimal representation of a byte string The syntax of the content of byte strings represented in hex, such as h'', h'0815', or h'/head/ 63 /contents/ 66 6f 6f' (another representation of << "foo" >>), is described by the ABNF in . This syntax accommodates both lowercase and uppercase hex digits, as well as blank space (including comments) around each hex digit.
ABNF Definition of Hexadecimal Representation of a Byte String
Any input that matches "//" in eol-comment and/or ends-in-star in comment raises an error.
b64: ABNF Definition of Base64 representation of a byte string The syntax of the content of byte strings represented in base64 is described by the ABNF in . This syntax allows both the classic () and the URL-safe () alphabet to be used. It accommodates, but does not require base64 padding. Note that inclusion of classic base64 makes it impossible to have comments based on slash characters in b64, as "/" is valid base64-classic.
ABNF definition of Base64 Representation of a Byte String
dt: ABNF Definition of RFC 3339 Representation of a Date/Time The syntax of the content of dt literals can be described by the ABNF for date-time in . This is derived from as summarized in .
ABNF Definition of RFC3339 Representation of a Date/Time
ip: ABNF Definition of Textual Representation of an IP Address The syntax of the content of ip literals can be described by the ABNF for IPv4address and IPv6address in , as included in slightly updated form in .
ABNF Definition of Textual Representation of an IP Address
ABNF Definitions for Integrated Extension Parsers For some applications of CDN, it is an optimization to integrate parsers for the content of some prefixed string literals into the main parser, handling both the string literal syntax (e.g., escapes such as \' and \\) and the syntax of the extension content in one go. For app-extensions that only use printable ASCII characters (from U+0020 to U+007E) minus single-quote ' and backslash \, the ABNF such as that given in can be directly used as an integrated parser, after adding some glue ABNF. For instance, for app-string-dt, add an alternative to prefixed that points to a rule for prefixed single-quoted string literals ().
Glue ABNF for Integrated DT Parser
To facilitate writing integrated ABNF for more complex prefixed string literals, the ABNF definitions in may be useful and are used in the rest of this section.
ABNF Definitions Useful for Integrated Extension Parsers
Similarly, for integrated parsers for prefixed literals built from raw strings, the ABNF definitions in can be useful. alikerawdelim only matches sequences of backquotes that are exactly as long as a previous startrawdelim.
ABNF Definitions Useful for Raw String Integrated Extension Parsers
Four subsections with ABNF for integrated parsers follow, a pair for h'' and b64'', and a pair for h`` and b64``. There is no expectation for a new app-extension to supply ABNF for an integrated parser (or any ABNF at all!), in particular if the parsing function is likely to be fulfilled by a platform library. If ABNF for the content of a single-quoted string is available in an app-extension specification, ABNF for an integrated parser can be written as a separate activity or also automatically derived (see also , where more information about implementing integrated parsers is being collected).
h'': ABNF Definition of Integrated Parser With glue ABNF similar to that in and common definitions in Figures and , ABNF such as that shown in can be used as an integrated parser for h prefixed single-quote strings.
ABNF Definition for Integrated Hex Parser
Any input that matches "//" in eol-comment and/or h-ends-in-star in h-comment raises an error.
b64'': ABNF Definition of Integrated Parser With glue ABNF similar to that in and common definitions in Figures and , ABNF such as that shown in can be used as an integrated parser for b64 prefixed single-quote strings.
ABNF Definition for Integrated Base64 Parser
h``: ABNF Definition of Integrated Parser With glue ABNF similar to that in and common definitions in Figures , and , ABNF such as that shown in can be used as an integrated parser for h prefixed raw strings.
ABNF Definition for Integrated Raw String Hex Parser
Any input that matches "//" in eol-comment and/or rh-ends-in-star in rh-comment raises an error.
b64``: ABNF Definition of Integrated Parser With glue ABNF similar to that in , common definitions in Figures , and as well as the rule b64dig from , ABNF such as that shown in can be used as an integrated parser for b64 prefixed raw strings.
ABNF Definition for Integrated Raw String Base64 Parser
IANA Considerations RFC Editor: please replace RFC-XXXX with the RFC number of this RFC, [IANA.concise-diagnostic-notation] with a reference to the new registry group, and remove this note.
Concise Diagnostic Notation App-extension Identifiers Registry IANA is requested to create an "App-Extension Identifiers" registry in a new "Concise Diagnostic Notation" registry group [IANA.concise-diagnostic-notation], with the policy "expert review" (Section of RFC 8126 ). The experts are instructed to be frugal in the allocation of app-extension identifiers that are suggestive of generally applicable semantics, keeping them in reserve for app-extensions that are likely to enjoy wide use and can make good use of their conciseness. The experts are also instructed to direct the registrant to provide a specification (Section of RFC 8126 ), but can make exceptions, for instance when a specification is not available at the time of registration but is likely forthcoming. If the experts become aware of app-extension identifiers that are deployed and in use, they may also initiate a registration on their own if they deem such a registration can avert potential future collisions. Each entry in the registry must include:
App-Extension Identifier:
a lowercase ASCII string that starts with a letter and can contain letters, digits, and hyphens after that ([a-z][a-z0-9-]*). No other entry in the registry can have the same app-extension identifier.
Description:
a brief description
Change Controller:
(see Section of RFC 8126 )
Reference:
a reference document that provides a description of the app-extension identifier
The initial content of the registry is shown in ; all initial entries have the Change Controller "IETF". Initial Content of app-extension Identifier Registry
app-extension identifier Description Reference
h Reserved RFC8949
b32 Reserved RFC8949
h32 Reserved RFC8949
b64 Reserved RFC8949
false Reserved RFC-XXXX
true Reserved RFC-XXXX
null Reserved RFC-XXXX
undefined Reserved RFC-XXXX
pragma Reserved for future use RFC-XXXX
dt Date/Time RFC-XXXX
ip IP Address/Prefix RFC-XXXX
hash Cryptographic Hash RFC-XXXX
b1 Byte String Concatenation RFC-XXXX
t1 Text String Concatenation RFC-XXXX
float Floating-Point Value RFC-XXXX
Media Type IANA is requested to add the following Media-Type to the "Media Types" registry . New Media Type application/cdn
Name Template Reference
cdn application/cdn RFC-XXXX,
Type name:
application
Subtype name:
cdn
Required parameters:
N/A
Optional parameters:
N/A
Encoding considerations:
binary (UTF-8)
Security considerations:
of RFC XXXX
Interoperability considerations:
none
Published specification:
of RFC XXXX
Applications that use this media type:
Tools interchanging a human-readable form of CBOR
Fragment identifier considerations:
The syntax and semantics of fragment identifiers is as specified for "application/cbor". (At publication of RFC XXXX, there is no fragment identification syntax defined for "application/cbor".)
Additional information:
Deprecated alias names for this type:
N/A
Magic number(s):
N/A
File extension(s):
.cdn
Macintosh file type code(s):
N/A
Person & email address to contact for further information:
CBOR WG mailing list (cbor@ietf.org), or IETF Applications and Real-Time Area (art@ietf.org)
Intended usage:
LIMITED USE
Restrictions on usage:
Concise diagnostic notation represents CBOR data items, which are the format intended for actual interchange. The media type application/cdn is intended to be used within documents about CBOR data items, in diagnostics for human consumption, and in other representations of CBOR data items that are necessarily text-based such as in configuration files or other data edited by humans, often under source-code control.
Author/Change controller:
IETF
Provisional registration:
no
Content-Format IANA is requested to register a Content-Format number in the sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry , as follows: New Content-Format for application/cdn
Content-Type Content Coding ID Reference
application/cdn - TBD1 RFC-XXXX
TBD1 is to be assigned from the space 256..9999, according to the procedure "IETF Review or IESG Approval", preferably a number less than 1000.
Security considerations The security considerations of apply, including by applying the considerations about the CBOR format to the CDN format in an analogous sense. Security considerations documented in for the CDDL language often are also applicable to the CDN language in an analogous sense. The CDN specification defines an explicit extension point: app-extension identifiers (). Extensions introduced through these can have their own security considerations, which need to be considered in the specification for the extension (see, e.g., ). Implementers of tools that support the use of CDN extensions need to avoid inadvertently introducing a vector that allows attackers to invoke extensions not planned for by the tool operator, who might not have considered security considerations of specific extensions such as those posed by their use of dereferenceable identifiers (). Tools might require explicitly enabling the use of each extension that is not on an allowlist. (This task can possibly be made less onerous by combining it with a mechanism for supplying any parameters that control such an extension.) Tools that process app-extensions need to be configured out of band to enable processing each specific app-extension only if that is desired. An allowlist built out of the mandatory-to-implement application extensions may be an exception.
References Normative References Concise Binary Object Representation (CBOR) 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. Concise Binary Object Representation (CBOR) Sequences This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences. Augmented BNF for Syntax Specifications: ABNF Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] UTF-8, a transformation format of ISO 10646 ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. Case-Sensitive String Support in ABNF This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner. Date and Time on the Internet: Timestamps This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. Uniform Resource Identifier (URI): Generic Syntax A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes This specification defines two Concise Binary Object Representation (CBOR) tags for use with IPv6 and IPv4 addresses and prefixes. I-Regexp: An Interoperable Regular Expression Format This document specifies I-Regexp, a flavor of regular expression that is limited in scope with the goal of interoperation across many different regular expression libraries. CBOR Object Signing and Encryption (COSE) IANA Media Types IANA Constrained RESTful Environments (CoRE) Parameters IANA Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. ASCII format for network interchange IEEE Standard for Floating-Point Arithmetic IEEE Information technology — Programming languages — C International Organization for Standardization 
 The standard is widely known as C23. Its technical content is also available via https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf. Edition 5 Programming languages — C++ International Organization for Standardization 
 The standard is widely known as C++23. Its technical content is also available via https://open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4950.pdf. Edition 7 Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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 Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures 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. Concise Binary Object Representation (CBOR) 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. The Base16, Base32, and Base64 Data Encodings 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] Concise Problem Details for Constrained Application Protocol (CoAP) APIs 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. The JavaScript Object Notation (JSON) Data Interchange Format 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 I-JSON Message Format I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results. On Numbers in CBOR Universität Bremen TZI The Concise Binary Object Representation (CBOR), as defined in STD 94 (RFC 8949), is a data representation format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. Among the kinds of data that a data representation format needs to be able to carry, numbers have a prominent role, but also have inherent complexity that needs attention from protocol designers, from implementers of CBOR libraries, and from implementers of the applications that use them. This document gives an overview over number formats available in CBOR and some notable CBOR tags registered, and it attempts to provide information about opportunities and potential pitfalls of these number formats. // This is still rather drafty, pieced together from various // components, so it has a higher level of redundancy than ultimately // desired. Additional Control Operators for the Concise Data Definition Language (CDDL) 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:.plus,.cat, and.det for the construction of constants;.abnf/.abnfb for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and.feature for indicating the use of a non-basic feature in an instance. Concise Data Definition Language (CDDL): Additional Control Operators for the Conversion and Processing of Text 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 in both an application-specific and a more general way. The present document defines a number of additional generally applicable control operators for text conversion (bytes, integers, printf-style formatting, and JSON) and for an operation on text. Updates to the Concise Data Definition Language (CDDL) Grammar The Concise Data Definition Language (CDDL), as defined in RFCs 8610 and 9165, provides an easy and unambiguous way to express structures for protocol messages and data formats that are represented in Concise Binary Object Representation (CBOR) or JSON. This document updates RFC 8610 by addressing related errata reports and making other small fixes for the ABNF grammar defined for CDDL. External References to Values in CBOR Diagnostic Notation (EDN) Universität Bremen TZI The Concise Binary Object Representation (CBOR, 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. CBOR diagnostic notation (EDN) is widely used to represent CBOR data items in a way that is accessible to humans, for instance for examples in a specification. At the time of writing, EDN did not provide mechanisms for composition of such examples from multiple components or sources. This document uses EDN application extensions to provide two such mechanisms, both of which insert an imported data item into the data item being described in EDN: The e'' application extension provides a way to import data items, particularly constant values, from a CDDL model (which itself has ways to provide composition). The ref'' application extension provides a way to import data items that are described in EDN. The "dereferenceable identifier" pattern Universität Bremen TZI In a protocol or an application environment, it is often important to be able to create unambiguous identifiers for some meaning (concept or some entity). Due to the simplicity of creating URIs, these have become popular for this purpose. Beyond the purpose of identifiers to be uniquely associated with a meaning, some of these URIs are in principle _dereferenceable_, so something can be placed that can be retrieved when encountering such a URI. YAML Media Type This document registers the application/yaml media type and the +yaml structured syntax suffix with IANA. Both identify document components that are serialized according to the YAML specification. YAML Ain't Markup Language (YAML™) Version 1.2 Revision 1.2.2 CDN Wiki n.d. W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes
CDN and CDDL This appendix is for information. CDN was designed as a language to provide a human-readable representation of an instance, i.e., a single CBOR data item or CBOR sequence. CDDL was designed as a language to describe an (often large) set of such instances (which itself constitutes a language), in the form of a data definition or grammar (or sometimes called schema). The two languages share some similarities, not the least because they have mutually inspired each other. But they have very different roots:
  • CDN syntax is an extension to JSON syntax .
    (Any (interoperable) JSON text is also valid CDN.)
  • CDDL syntax is inspired by ABNF's syntax .
For engineers that are using both CDN and CDDL, it is easy to write "CDDLisms" or "CDNisms" into their drafts that are meant to be in the other language. (This is one more of the many motivations to always validate formal language instances with tools.) Important differences include:
  • Comment syntax. CDDL inherits ABNF's semicolon-delimited end of line characters, while CDN finds nothing in JSON that could be inherited here. Inspired by JavaScript, CDN simplifies JavaScript's copy of the original C comment syntax to be delimited by single slashes (where line breaks are not of interest); it also adds end-of-line comments that start with #.
    CDN:
    CDDL:
    ? 1 => int / tstr, ; algorithm identifier
  • Syntax for tags. CDDL's tag syntax is part of the system for referring to CBOR's fundamentals (the major type 6, in this case) and (with ) allows specifying the actual tag number separately, while CDN's tag syntax is a simple decimal number and a pair of parentheses.
    CDN:
    CDDL:
    COSE_Sign_Tagged = #6.98(COSE_Sign)
  • Embedded CBOR. CDN has a special syntax to describe the content of byte strings that are encoded CBOR data items. CDDL can specify these with a control operator, which looks very different.
    CDN:
    >, # == h'a10126' ]) ]]>
    CDDL:
    serialized_map = bytes .cbor header_map
List of Figures
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
List of Tables
:
:
:
:
:
:
:
:
:
:
:
Acknowledgements The concept of application-oriented extensions to diagnostic notation, as well as the definition for the "dt" extension, were inspired by the CoRAL work by Klaus Hartke. (TBD)