Concise Diagnostic Notation (CDN)

1.1. Structure of This Document

Section 2 of this document has been built from Section 8 of RFC 8949 [STD94] and Appendix G of [RFC8610]. The latter provided a number of useful extensions to the initial diagnostic notation that was originally defined in Section 6 of [RFC7049]. Section 8 of RFC 8949 [STD94] and Appendix G of [RFC8610] have collectively been called "Extended Diagnostic Notation" (EDN), now simplified as "Concise Diagnostic Notation" (CDN) giving the present document its name.¶

After introductory material, Section 3 illustrates the concept of application-oriented extension literals by defining a number of application-extensions. Section 4 defines mechanisms for dealing with unknown application-oriented literals and deliberately elided information. Section 5 gives the formal syntax of CDN in ABNF, with explanations for some features of and additions to this syntax, as an overall grammar (Section 5.1) and specific grammars for the content of app-string and byte-string literals (Section 5.2). This is followed by the conventional sections for IANA Considerations (6), Security considerations (7), and References (8.1, 8.2). An informational comparison of CDN with CDDL follows in Appendix A.¶

1.2. Terminology and Conventions

Section 8 of RFC 8949 [STD94] defines the original CBOR diagnostic notation, and Appendix G of [RFC8610] supplies a number of extensions to the diagnostic notation that form the basis for what is now the Concise Diagnostic Notation (CDN). The diagnostic notation extensions include popular features such as embedded CBOR (encoded CBOR data items in byte strings) and comments. A simple diagnostic notation extension that enables representing CBOR sequences was added in Section 4.2 of [RFC8742]. As at least some elements of the extended form are now near-universally used, the terms "diagnostic notation" and "extended diagnostic notation" have become synonyms in the context of CBOR, with "concise diagnostic notation" (CDN) now the preferred synonym, hinting at knowledge of this updated specification.¶

In a similar vein, the term "ABNF" in this document refers to the language defined in [STD68] as extended in [RFC7405], where the "characters" of Section 2.3 of RFC 5234 [STD68] 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 [RFC9485].¶

The term "CDDL" (Concise Data Definition Language) refers to the data definition language defined in [RFC8610] and its registered extensions (such as those documented in [RFC9165], [RFC9741], and [RFC9682]). Additional information about the relationship between the two languages CDN and CDDL is captured in Appendix A.¶

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: 2⁶⁴⁺¹. 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 [BCP14] (RFC2119) (RFC8174) when, and only when, they appear in all capitals, as shown here.¶

1.3. (Non-)Objectives of this Document

Section 8 of RFC 8949 [STD94] 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.¶

2.1. Application-Oriented Extension Literals

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, or extension literals for short.¶

Extension literals start with a prefix that identifies the application-oriented extension, immediately followed by a sequence literal (Section 2.5.7) or a single-quoted or raw string literal (Section 2.5). 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`>>.¶

More precisely, an application-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.¶

Application-extension identifiers are registered in the "Application-Extension Identifiers" registry (Section 6.1).¶

An application-extension (such as dt) MAY also define the meaning of one additional prefix derived from its application-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 application-oriented extension (such as tag number 1 for DT, where in contrast the prefix dt stands for the unwrapped tag content).¶

In summary, an application-extension identifier gives rise to one or two application-extension 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 application 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. 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 application 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 4, 5, and 6).¶

This specification defines a number of generally applicable application-oriented extensions (Section 3), both to motivate making these extensions generally available, and to illustrate the concept.¶

Of these, the application-oriented extensions h, b64, t1, b1, dt and ip are mandatory to implement. (As mentioned, for simplicity we use the term "application-oriented extensions" for the mechanism discussed in this section even if it is used to describe a part of base CDN.)¶

2.2. Comments

For presentation to humans, CDN text may benefit from comments. JSON famously does not provide for comments, and the original diagnostic notation in Section 6 of [RFC7049] 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 "#" or "//" and an end of line (LINE FEED, U+000A):¶

  In a position that allows blank space, any text starting with "#" or "//" 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:¶

/grasp-message/ [/M_DISCOVERY/ 1, /session-id/ 10584416,
                 /objective/ [/objective-name/ "opsonize",
                              /D, N, S/ 7, /loop-count/ 105]]

This reduces to [1, 10584416, ["opsonize", 7, 105]].¶

Another example, combining the use of inline and end-of-line comments:¶

{
 /kty/ 1 : 4, # Symmetric
 /alg/ 3 : 5, # HMAC 256-256
  /k/ -1 : h'6684523ab17337f173500e5728c628547cb37df
             e68449c65f885d1b73b49eae1'
}

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):¶

/* ### MyApp Configuration
 * John Example, 2026-06-09
 */
{
  // Top-level config for the app
  "appName": "MyApp", // short name shown in UI
  "version": "1.2.0",
  ...: ...
}

4 /* HMAC 256/64 */

4 / HMAC 256//64 /

2.3. 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 4.1 of RFC 8949 [STD94]) 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 Section 1.3.3). 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.¶

2.4. 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).¶

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). A leading "+" sign is a no-op, and a leading "-" sign inverts the sign of the number. So 0, 000, +0 all represent the same integer zero, as does -0. Similarly, 1, 001, +1 and +0001 all stand for the same positive integer one, and -1 and -0001 both designate the same 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 (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 Table 2, 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.¶

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. Table 3 shows how the floating point numbers 1.1, 1.5 and these three values are encoded in preferred serialization and when encoding indicators are given.¶

See Section 5.1, Paragraph 8, Item 3 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 application-oriented literals. Background information beyond that in [STD94] about the representation of numbers in CBOR can be found in the informational document [I-D.bormann-cbor-numbers].)¶

2.5. Strings

CBOR distinguishes two kinds of strings: text strings (the bytes in the string constitute UTF-8 [STD63] 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 (Section 2.5.2) or as raw strings (Section 2.5.4), while byte strings can be represented as single-quoted strings (Section 2.5.3). The latter is useful for byte strings carrying bytes that can be meaningfully notated as UTF-8 text.¶

Many strings are best notated as extension literals, which may provide detailed access to the bits within those bytes (see Section 2.5.6). Using an application-extension prefix, extension literals can be constructed out of single-quoted strings and raw strings, as well as sequence literals (cf. Section 2.1).¶

"D\u{6f}mino's \u{1F073} + \u{2318}"   # \u{}-escape 3 chars
"D\u006Fmino's \uD83C\uDC73 + \u2318"  # escape JSON-like
"Domino's 🁳 + ⌘"                       # unescaped

'hello world'
h'68656c6c6f20776f726c64'

 ``[^ \t\n\r"'`]``

 "[^ \\t\\n\\r\"'`]"

```To emulate typographic quotes, sometimes duplicate backward and
forward single quotes are used, as in ``text.''
```

   h'48656c6c6f20776f726c64'
   h'48 65 6c 6c 6f 20 77 6f 72 6c 64'
   h'4 86 56c 6c6f
     20776 f726c64'

   h'68656c6c6f20776f726c64'
   h'68 65 6c /doubled l!/ 6c 6f # hello
     20 /space/
     77 6f 72 6c 64' /world/

   b64'/base64 not a comment/ but one follows # comment'
   h'FDB6AC 7BAE27A2D69CA2699E9EDFDBBADA2779FA25 968C2C'

   <<1>>              h'01'
   <<1, 2>>           h'0102'
   <<"hello", null>>  h'65 68656c6c6f f6'
   <<>>               h''

   <<1_1>>              h'190001'
   <<1_0, 2_2>>         h'1801 1a00000002'
   <<"hello"_0, null>>  h'7805 68656c6c6f f6'

2.6. 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).¶

[1, 2, 3]
[1, 2, 3,]
[1  2  3]
[1  2  3,]
[1  2, 3]
[1  2, 3,]
[1, 2  3]
[1, 2  3,]

{1: "n", "x": "a"}
{1: "n", "x": "a",}
{1: "n"  "x": "a"}
# etc.

{1: "to", 1: "from"}

2.7. Tags

A tag is written as a decimal unsigned integer (no leading zeros except for the actual 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 as the following:¶

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:¶

d9 0001        # tag(1)
   1a 514b67b0 # unsigned(1363896240)

2.8. 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«.¶

3.1. Date and Time: The "dt" Extension

The application-extension identifier "dt" is used to notate a date/time literal that can be used as an Epoch-Based Date/Time as per Section 3.4.2 of RFC 8949 [STD94].¶

The content of the literal is a single Standard Date/Time String as per Section 3.4.1 of RFC 8949 [STD94], 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 Figure 5), 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 Table 4 shows an example of "dt" notation and equivalent notation not using an application-extension identifier.¶

See Section 5.2.3 for an ABNF definition for the text string input of dt literals.¶

3.2. IP Addresses and Related Structures: The "ip" Extension

The application-extension identifier "ip" is used to notate an IP address literal that can be used as an IP address as per Section 3 of [RFC9164].¶

The input of the literal is a single text string representing an IPv4address or IPv6address as per Section 3.2.2 of [RFC3986].¶

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 [RFC9164] representations of address prefixes need to implement the truncation of the address byte string as described in Section 4.2 of [RFC9164]; 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 application-extension provides no direct representation of the "Interface format" defined in Section 3.1.3 of [RFC9164], 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 Table 5 shows an example of "ip" notation and equivalent notation not using an application-extension identifier.¶

See Section 5.2.4 for an ABNF definition for the content of ip literals.¶

3.3. Cryptographic Hash Values: The "hash" Extension

The application-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 [IANA.cose], 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 application-extension identifier "hash".¶

3.4. String Concatenation: The "b1" and "t1" Extensions

This section uses the placeholders t1 and b1 as provisional application extension names, allowing the text to stabilize while the actual names are still being decided by the WG.¶

The "b1" and "t1" 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 Appendix G.4 of [RFC8610]) are equivalent:¶

"Hello world"
t1<<"Hello ", "world">>
t1<<"Hello", h'20', "world">>
t1<<h'48656c6c6f20776f726c64'>>

Similarly, the following byte string values are equivalent:¶

'Hello world'
b1<"Hello world">
b1<<'Hello ', 'world'>>
b1<<'Hello ', h'776f726c64'>>
b1<<'Hello', h'20', 'world'>>
b1<<h'48656c6c6f20776f726c64', '', b64''>>
b1<<h'4 86 56c 6c6f', h' 20776 f726c64'>>

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 application 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 Section 2.5.8.¶

Besides strings, arguments to t1/b1 may include ellipses, in which case the result will be an ellipsis data item in turn (see Section 4.2). The semantic processing of these is governed by the following rules:¶

• A single ... is a general ellipsis, which by itself can stand for any data item, but when used as argument to t1/b1 must stand in for a string value.¶

• Multiple adjacent ellipses are equivalent to a single ellipsis.¶

• When an ellipsis is concatenated (on one or both sides) with strings, the result is a CBOR tag number CPA888 that contains an array with joined together spans of such strings plus the ellipses represented by /CPA/888(null).¶

• Arguments with nested ellipses are flattened and the above equivalences applied, so that, for instance, these values are equivalent:¶

  h'48656c6c6f...776f726c64'
  b1<<h'48656c6c6f...', ..., h'...776f726c64'>>
  b1<<'Hello', ..., 'world'>>
  

  ¶

• If there is no ellipsis in the concatenated list, the result of processing the list will always be a single string data item.¶

3.5. Creating Indefinite-length Encoded Strings: The "ilbs" and "ilts" Extensions

The ilbs and ilts application 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 application-extension is implying indefinite length encoding, there is no point in applying an encoding indicator to the entire application-extension literal.¶

'Hello world'                4b 48656c6c6f20776f726c64
ilbs<<>>                     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.¶

3.6. Concise Resource Identifiers: The "cri" Extension

The application-extension identifier "cri" is used to notate a CDN literal for a CRI reference as defined in [I-D.ietf-core-href].¶

The input of the literal is a URI Reference as per [RFC3986] or an IRI Reference as per [RFC3987].¶

The value of the literal is a CRI reference that can be converted to the text of the literal using the procedure of Section 6.1 of [I-D.ietf-core-href]. Note that there may be more than one CRI reference that can be converted to the URI/IRI reference given; implementations are expected to favor the simplest variant available and make non-surprising choices otherwise. In the all-uppercase variant of the app-prefix, the value is enclosed in a tag number 99.¶

As an example, the CDN¶

cri'https://example.com/bottarga/shaved'
CRI'https://example.com/bottarga/shaved'

is equivalent to¶

[-4, ["example", "com"], ["bottarga", "shaved"]]
99([-4, ["example", "com"], ["bottarga", "shaved"]])

See Section 5.2.5 for an ABNF definition for the content of cri literals.¶

3.7. The "float" Extension

The "float" application 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 application prefix); the result is used as the byte string.¶

The application-oriented 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):¶

🔧 "[float'fe00', float'fe00'_2, float'47110815']" -tpretty ➔
83             # array(3)
   F9 FE00     # primitive(65024)
   FA FFC00000 # primitive(4290772992)
   FA 47110815 # primitive(1192298517)

🔧 "[float'fe00', float'fe00'_2, float'47110815', 0x1.22102ap+15]" ➔
[float'fe00', float'fe00'_2, 37128.08203125, 37128.08203125]

The purpose of this application extension is to close a gap in CDN's [IEEE754] 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 4.1 of RFC 8949 [STD94]: "(for many applications, the single NaN encoding 0xf97e00 will suffice)". For finite floating point numbers, the decimal or hex floating point representations are preferred.¶

4.1. Handling unknown application-extension identifiers

When ingesting CDN, application-oriented extension literals are usually decoded and transformed into the corresponding data item during ingestion. If an application-extension is not known or not implemented by the ingesting process, this is usually an error and processing has to stop.¶

However, in certain cases, it can be desirable to exceptionally carry an uninterpreted application-oriented extension literal in an ingested data item, allowing to postpone its decoding to a specific later stage of ingestion.¶

This specification defines a CBOR Tag for this purpose: The Diagnostic Notation Unresolved Application-Extension Tag, tag number CPA999 (Section 6.5). The content of this tag is an array of a text string for the application-extension prefix, and another array:¶

• For app-strings, the second array contains a single item, a text string containing the text notated by the single-quoted string in the app-string.¶

• For app-sequences, the second array contains zero or more items, which represent each item in the sequence contained in the app-sequence.¶

For example, cri'https://example.com' can be represented as /CPA/ 999(["cri", ["https://example.com"]]), and hash<<"data", -44>> as /CPA/ 999(["hash", ["data", -44]]).¶

If a stage of ingestion is not prepared to handle the Unresolved Application-Extension Tag, this is an error and processing has to stop, as if this stage had been ingesting an unknown or unimplemented application-extension literal itself.¶

RFC-Editor: This document uses the CPA (code point allocation) convention described in [I-D.bormann-cbor-draft-numbers]. For each usage of the term "CPA", please remove the prefix "CPA" from the indicated value and replace the residue with the value assigned by IANA; perform an analogous substitution for all other occurrences of the prefix "CPA" in the document. Finally, please remove this note.¶

4.2. Handling information deliberately elided from a CDN document

When using CDN for exposition in a document or on a whiteboard, it is often useful to be able to leave out parts of a CDN document that are not of interest at that point of the exposition.¶

To facilitate this, this specification supports the use of an ellipsis (notated as three or more dots in a row, as in ...) to indicate parts of a CDN document that have been elided (and therefore cannot be reconstructed).¶

Upon ingesting CDN as a representation of a CBOR data item for further processing, the occurrence of an ellipsis usually is an error and processing has to stop.¶

However, it is useful to be able to process CDN documents with ellipses in the automation scripts for the documents using them. This specification defines a CBOR Tag that can be used in the ingestion for this purpose:¶

The Diagnostic Notation Ellipsis Tag, tag number CPA888 (Section 6.5). The content of this tag is one of:¶

1. null (indicating a data item entirely replaced by an ellipsis);¶

2. an array, the elements of which are alternating between parts of a string and the actual elisions, represented as ellipses carrying a null as content.¶

Elisions can stand in for entire subtrees, e.g. in:¶

[1, 2, ..., 3]
{ "a": 1,
  "b": ...,
  ...: ...
}

A single ellipsis (or key/value pair of ellipses) can imply eliding multiple elements in an array (members in a map). If more detailed control is required, a data definition language such as CDDL can be employed. (Note that the tag-based representation form defined here does not allow multiple key/value pairs with an ellipsis as a key: the CBOR data item would not be valid.)¶

Subtree elisions can be represented in a CBOR data item by using /CPA/888(null) as the placeholder CBOR data item:¶

[1, 2, 888(null), 3]
{ "a": 1,
  "b": 888(null),
  888(null): 888(null)
}

Elisions also can be used as part of a (text or byte) string:¶

{ "contract": t1<<"Herewith I buy", ..., "gned: Alice & Bob">>
  "bytes_in_IRI": b1<<'https://a.example/', ..., '&q=Übergrößenträger'>
  "signature": h'4711...0815',
}

The examples "contract" and "bytes_in_IRI" combine (text and byte) string concatenation via the t1/b1 application extension (Section 3.4) with an ellipsis. The example "signature" uses special syntax that allows the use of ellipses between the bytes notated inside h'' literals.¶

String elisions can be represented in a CBOR data item by a tag CPA888 that wraps an array containing string parts alternating with ellipsis indicators:¶

{ "contract": /CPA/888(["Herewith I buy", 888(null),
                        "gned: Alice & Bob"]),
  "bytes_in_IRI": 888(['https://a.example/', 888(null),
                       '&q=Übergrößenträger']),
  "signature": 888([h'4711', 888(null), h'0815']),
}

Note that the use of elisions is different from "commenting out" CDN text, e.g.:¶

{ "signature": h'4711/.../0815',
  # ...: ...
}

The consumer of this CDN will ignore the comments and therefore will have no idea after ingestion that some information has been elided; validation steps may then simply fail instead of being informed about the elisions.¶

5.1. 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 Section 5.2.1 and Section 5.2.2.¶

seq             = S [item *(MSC item) SOC]
one-item        = S item S
item            = map / array / tagged
                / number / simple
                / string / streamstring

string1         = (tstr / bstr) spec
string          = string1 / ellipsis
ellipsis        = 3*"." ; "..." or more dots

number          = (hexfloat / hexint / octint / binint
                   / decnumber / nonfin) spec
sign            = "+" / "-"
decnumber       = [sign] (1*DIGIT ["." *DIGIT] / "." 1*DIGIT)
                         ["e" [sign] 1*DIGIT]
hexfloat        = [sign] "0x" (1*HEXDIG ["." *HEXDIG] / "." 1*HEXDIG)
                         "p" [sign] 1*DIGIT
hexint          = [sign] "0x" 1*HEXDIG
octint          = [sign] "0o" 1*ODIGIT
binint          = [sign] "0b" 1*BDIGIT
nonfin          = %s"Infinity"
                / %s"-Infinity"
                / %s"NaN"
simple          = %s"false"
                / %s"true"
                / %s"null"
                / %s"undefined"
                / %s"simple(" S simple-number S ")"
simple-number   = "25" %x30-35         ; 250-255
                / "2" %x30-34 DIGIT    ; 200-249
                / "1" 2DIGIT           ; 100-199
                / %x34-39 DIGIT        ; 40-99
                / "3" %x32-39          ; 32-39
                ;; there are no simple values between 24-31
                / "2" %x30-33          ; 20-23
                / "1" DIGIT            ; 10-19
                / DIGIT                ; 0-9
uint            = "0" / DIGIT1 *DIGIT
tagged          = uint spec "(" S item S ")"

app-prefix      = lcalpha *lcldh ; including h and b64
                / ucalpha *ucldh ; tagged variant, if defined
app-string      = app-prefix sqstr
app-sequence    = app-prefix "<<" seq ">>"
app-rstring     = app-prefix rawstring
rawstring       = startrawdelim
                  raw-inner
                  alikerawdelim
rawdelim        = 1*"`"
startrawdelim   = rawdelim
                  ; width (number of backquotes) distinguishes
                  ; between following alikerawdelim and shortrawdelim
alikerawdelim   = rawdelim ; width == previous startrawdelim
shortrawdelim   = rawdelim ; width < previous startrawdelim
rawchars        = 1*(%x0a/%x0d / %x20-5f / %x61-7e / NONASCII)
raw-inner       = 1*(rawchars / shortrawdelim)

sqstr           = SQUOTE *single-quoted SQUOTE
bstr            = app-string / sqstr / app-rstring / rawstring
                / app-sequence / embedded
                  ; note: rawstring is text; app-... can be any type
tstr            = DQUOTE *double-quoted DQUOTE
embedded        = "<<" seq ">>"

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]

; check semantically that strings are either all text or all bytes
; note that there must be at least one string to distinguish
streamstring    = "(_" MS string *(MSC string) SOC ")"
spec            = ["_" *wordchar]
specms          = ["_" *wordchar MS]

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

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.¶

Further information can be moved up to Section 2 by splitting it up into information specific to the ABNF grammar and general information.¶

The following additional items should help in the interpretation:¶

1. As mentioned in the terminology (Section 1.2), 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 Section 1.3.5 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. 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.¶

4. 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 [IEEE754], Section 6.4.4.3 of [C], or Section 5.13.4 of [Cplusplus]; floating-suffix/floating-point-suffix from the latter two is not used here).¶

5. 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.¶

   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 [IEEE754] 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.¶

6. spec stands for an encoding indicator. See Section 2.3 for details.¶

7. The ABNF grammar for raw strings is lenient; a parser needs to implement the ABNF comments on alikerawdelim and shortrawdelim as well. shortrawdelim only matches sequences of backquotes that are shorter than startrawdelim. alikerawdelim only matches sequences of backquotes that are exactly as long as startrawdelim.¶

5.2. ABNF Definitions for Application Extension Content

This subsection provides ABNF definitions for the content of application-oriented extension literals defined in [STD94] and in this specification, where applicable. These grammars describe the decoded content of the single-quoted or raw string components that combine with the application-extension identifiers used as prefixes to form application-oriented extension literals. Each of these may integrate ABNF rules defined in Figure 1, which are not always repeated here.¶

Table 7 summarizes the app-prefix values defined in this document.¶

Note that implementation platforms may already provide implementations of grammars used in application-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 Figure 2 are not repeated in the below ABNF grammars.¶

ALPHA           = %x41-5a / %x61-7a
DIGIT           = %x30-39 ; 0-9
HEXDIG          = DIGIT / HEXDIGA
HEXDIGA         = "A" / "B" / "C" / "D" / "E" / "F"
; Note: double-quoted strings as in "A" are case-insensitive in ABNF
lblank          = %x0A / %x20  ; Not HT or CR (gone)
non-lf          = %x20-7f / NONASCII
NONASCII        = %x80-D7FF / %xE000-10FFFF

app-string-h    = S *(HEXDIG S HEXDIG S / ellipsis S)
                  [eol-comment *non-lf]
ellipsis        = 3*"."
non-slash       = lblank / %x21-2e / %x30-7f / NONASCII
non-slash-star  = lblank / %x21-29 / %x2b-2e / %x30-7f / NONASCII
non-star        = lblank / %x21-29 / %x2b-7f / NONASCII
ends-in-star    = *non-star 1*"*"
non-lf          = %x20-7f / NONASCII
eol-comment     = "#" / "//"
S               = *lblank *(comment *lblank)
comment         = "/" non-slash-star *non-slash "/"
                / "/*" ends-in-star
                       *(non-slash-star ends-in-star) "/"
                / eol-comment *non-lf %x0A

app-string-b64  = B *(4(b64dig B))
                  [b64dig B b64dig B ["=" B "=" / b64dig B ["="]] B]
                  ["#" *non-lf]
b64dig          = ALPHA / DIGIT / "-" / "_" / "+" / "/"
B               = *lblank *(comment *lblank)
comment         = "#" *non-lf %x0A

app-string-dt   = date-time

date-fullyear   = 4DIGIT
date-month      = 2DIGIT  ; 01-12
date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                          ; month/year
time-hour       = 2DIGIT  ; 00-23
time-minute     = 2DIGIT  ; 00-59
time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap sec
                          ; rules
time-secfrac    = "." 1*DIGIT
time-numoffset  = ("+" / "-") time-hour ":" time-minute
time-offset     = "Z" / time-numoffset

partial-time    = time-hour ":" time-minute ":" time-second
                  [time-secfrac]
full-date       = date-fullyear "-" date-month "-" date-mday
full-time       = partial-time time-offset

date-time       = full-date "T" full-time

app-string-ip = IPaddress ["/" uint]

IPaddress     = IPv4address
              / IPv6address

; ABNF from RFC 3986, re-arranged for PEG compatibility:

IPv6address   =                            6( h16 ":" ) ls32
              /                       "::" 5( h16 ":" ) ls32
              / [ h16               ] "::" 4( h16 ":" ) ls32
              / [ h16 *1( ":" h16 ) ] "::" 3( h16 ":" ) ls32
              / [ h16 *2( ":" h16 ) ] "::" 2( h16 ":" ) ls32
              / [ h16 *3( ":" h16 ) ] "::"    h16 ":"   ls32
              / [ h16 *4( ":" h16 ) ] "::"              ls32
              / [ h16 *5( ":" h16 ) ] "::"              h16
              / [ h16 *6( ":" h16 ) ] "::"

h16           = 1*4HEXDIG
ls32          = ( h16 ":" h16 ) / IPv4address
IPv4address   = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet     = "25" %x30-35         ; 250-255
              / "2" %x30-34 DIGIT    ; 200-249
              / "1" 2DIGIT           ; 100-199
              / %x31-39 DIGIT        ; 10-99
              / DIGIT                ; 0-9

DIGIT1        = %x31-39 ; 1-9
uint          = "0" / DIGIT1 *DIGIT

app-string-cri = URI-reference
; ABNF from RFC 3986:

URI           = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

hier-part     = "//" authority path-abempty
                 / path-absolute
                 / path-rootless
                 / path-empty

URI-reference = URI / relative-ref

absolute-URI  = scheme ":" hier-part [ "?" query ]

relative-ref  = relative-part [ "?" query ] [ "#" fragment ]

relative-part = "//" authority path-abempty
                 / path-absolute
                 / path-noscheme
                 / path-empty

scheme        = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

authority     = [ userinfo "@" ] host [ ":" port ]
userinfo      = *( unreserved / pct-encoded / sub-delims / ":" )
host          = IP-literal / IPv4address / reg-name
port          = *DIGIT

IP-literal    = "[" ( IPv6address / IPvFuture  ) "]"

IPvFuture     = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )

; Use IPv6address, h16, ls32, IPv4adress, dec-octet as re-arranged
; for PEG Compatibility in Figure 6 of [RFC XXXX]:

IPv6address   =                            6( h16 ":" ) ls32
              /                       "::" 5( h16 ":" ) ls32
              / [ h16               ] "::" 4( h16 ":" ) ls32
              / [ h16 *1( ":" h16 ) ] "::" 3( h16 ":" ) ls32
              / [ h16 *2( ":" h16 ) ] "::" 2( h16 ":" ) ls32
              / [ h16 *3( ":" h16 ) ] "::"    h16 ":"   ls32
              / [ h16 *4( ":" h16 ) ] "::"              ls32
              / [ h16 *5( ":" h16 ) ] "::"              h16
              / [ h16 *6( ":" h16 ) ] "::"

h16           = 1*4HEXDIG
ls32          = ( h16 ":" h16 ) / IPv4address
IPv4address   = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet     = "25" %x30-35         ; 250-255
              / "2" %x30-34 DIGIT    ; 200-249
              / "1" 2DIGIT           ; 100-199
              / %x31-39 DIGIT        ; 10-99
              / DIGIT                ; 0-9

reg-name      = *( unreserved / pct-encoded / sub-delims )

path          = path-abempty    ; begins with "/" or is empty
                 / path-absolute   ; begins with "/" but not "//"
                 / path-noscheme   ; begins with a non-colon segment
                 / path-rootless   ; begins with a segment
                 / path-empty      ; zero characters

path-abempty  = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty    = 0<pchar>

segment       = *pchar
segment-nz    = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
                 ; non-zero-length segment without any colon ":"

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

query         = *( pchar / "/" / "?" )

fragment      = *( pchar / "/" / "?" )

pct-encoded   = "%" HEXDIG HEXDIG

unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved      = gen-delims / sub-delims
gen-delims    = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                 / "*" / "+" / "," / ";" / "="

5.3. 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 application-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 Section 5.2 can be directly used as an integrated parser, after adding some glue ABNF. For instance, for app-string-dt, add an alternative to bstr that points to a rule for prefixed single-quoted string literals (Figure 8).¶

bstr            = sq-app-string-dt /
                  app-string / sqstr / app-sequence / embedded
sq-app-string-dt = (%s"dt'"/%s"DT'") app-string-dt "'"

To facilitate writing integrated ABNF for more complex prefixed string literals, the ABNF definitions in Figure 9 may be useful and are used in the rest of this section.¶

i-HT =        %s"\t" / %s"\u" ("0009" / "{" *("0") "9}")
i-LF = %x0a / %s"\n" / %s"\u" ("000A" / "{" *("0") "A}")
i-CR = %x0d / %s"\r" / %s"\u" ("000D" / "{" *("0") "D}")

i-blank = i-LF / i-CR / " "
i-non-lf = i-HT / i-CR / %x20-26 / "\'" / %x28-5b
         / "\\" / %x5d-7f / i-NONASCII

i-NONASCII = NONASCII / %s"\u" ESCGE7F

; hex escaping for U+007F or greater
ESCGE7F = "D" ("8"/"9"/"A"/"B") 2HEXDIG
          %s"\u" "D" ("C"/"D"/"E"/"F") 2HEXDIG
        / FOURHEX1 / "0" HEXDIG1 2HEXDIG / "00" TWOHEX1
        / "{" *("0")
          ("10" 4HEXDIG / HEXDIG1 4HEXDIG
           / FOURHEX1 / HEXDIG1 2HEXDIG / TWOHEX1)
          "}"

; xxxx - 0xxx - Dhigh\uDloow
FOURHEX1 = (DIGIT1 / "A"/"B"/"C" / "E"/"F") 3HEXDIG
         / "D" ODIGIT 2HEXDIG
; 00xx - ASCII + 007F
TWOHEX1  = ("8"/"9" / HEXDIGA) HEXDIG / "7F"

Similarly, for integrated parsers for extension literals built from raw strings, the ABNF definitions in Figure 10 can be useful. alikerawdelim only matches sequences of backquotes that are exactly as long as a previous startrawdelim.¶

r-non-lf = %x0D / %x20-5f / %x61-7f / NONASCII / shortrawdelim

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 application-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 application-extension specification, ABNF for an integrated parser can be written as a separate activity or also automatically derived (see also [CDN-WIKI], where more information about implementing integrated parsers is being collected).¶

sq-app-string-h = %s"h'" s-app-string-h "'"
s-app-string-h = h-S *(HEXDIG h-S HEXDIG h-S / ellipsis h-S)
    [eol-comment *i-non-lf]

h-S = *(i-blank) *(h-comment *(i-blank))
h-non-slash = i-blank / %x21-26 / "\'" / %x28-2e
            / %x30-5b / "\\" / %x5d-7f / i-NONASCII
h-non-slash-star = i-blank / %x21-26 / "\'" / %x28-29 / %x2b-2e
                 / %x30-5b / "\\" / %x5d-7f / i-NONASCII
h-non-star = i-blank / %x21-26 / "\'" / %x28-29 / %x2b-5b
           / "\\" / %x5d-7f / i-NONASCII
h-ends-in-star = *h-non-star 1*"*"
h-comment = "/" h-non-slash-star *h-non-slash "/"
          / "/*" h-ends-in-star
                 *(h-non-slash-star h-ends-in-star) "/"
          / eol-comment *i-non-lf i-LF

sq-app-string-b64 = %s"b64'" s-app-string-b64 "'"
s-app-string-b64  = b64-S *(4(b64dig b64-S))
                  [b64dig b64-S b64dig b64-S
                   ["=" b64-S "=" / b64dig b64-S ["="]] b64-S]
                  ["#" *i-non-lf]
b64dig          = ALPHA / DIGIT / "-" / "_" / "+" / "/"
b64-S           = *i-blank *(b64-comment *i-blank)
b64-comment     = "#" *i-non-lf %x0A

raw-app-string-h = %s"h" startrawdelim r-app-string-h
r-app-string-h = rh-S *(HEXDIG rh-S HEXDIG rh-S / ellipsis rh-S)
    (eol-comment *r-non-lf alikerawdelim / alikerawdelim)
rh-S = *(lblank) *(rh-comment *(lblank))
rh-2 = %x61-7f / NONASCII / shortrawdelim
rh-non-slash = lblank / %x21-2e / %x30-5f / rh-2
rh-non-slash-star = lblank / %x21-29 / %x2b-2e / %x30-5f / rh-2
rh-non-star = lblank / %x21-29 / %x2b-5f / rh-2
rh-ends-in-star = *rh-non-star 1*"*"
rh-comment = "/" rh-non-slash-star *rh-non-slash "/"
           / "/*" rh-ends-in-star
                  *(rh-non-slash-star rh-ends-in-star) "/"
           / eol-comment *r-non-lf %x0A

raw-app-string-b64 = %s"b64" startrawdelim r-app-string-b64
r-app-string-b64  = rb64-S *(4(b64dig rb64-S))
                  [b64dig rb64-S b64dig rb64-S
                   ["=" rb64-S "=" / b64dig rb64-S ["="]] rb64-S]
                  ("#" *r-non-lf alikerawdelim / alikerawdelim)
rb64-S           = *lblank *(rb64-comment *lblank)
rb64-comment     = "#" *r-non-lf %x0A

6.1. Concise Diagnostic Notation Application-extension Identifiers Registry

IANA is requested to create an "Application-Extension Identifiers" registry in a new "Concise Diagnostic Notation" registry group [IANA.concise-diagnostic-notation], with the policy "expert review" (Section 4.5 of RFC 8126 [BCP26]).¶

Each entry in the registry must include:¶

Application-Extension Identifier:

a lowercase ASCII [STD80] 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 application-extension identifier.¶

Description:

a brief description¶

Change Controller:

(see Section 2.3 of RFC 8126 [BCP26])¶

Reference:

a reference document that provides a description of the application-extension identifier¶

The initial content of the registry is shown in Table 8; all initial entries have the Change Controller "IETF".¶

6.2. Encoding Indicators

IANA is requested to create an "Encoding Indicators" registry in the newly created "Concise Diagnostic Notation" registry group [IANA.concise-diagnostic-notation], with the policy "specification required" (Section 4.6 of RFC 8126 [BCP26]).¶

Each entry in the registry must include:¶

Encoding Indicator:

an ASCII [STD80] string that starts with an underscore letter and can contain zero or more underscores, letters and digits after that (_[_A-Za-z0-9]*). No other entry in the registry can have the same Encoding Indicator.¶

Description:

a brief description. This description may employ an abbreviation of the form ai=nn, where nn is the numeric value of the field additional information, the low-order 5 bits of the initial byte (see Section 3 of RFC 8949 [STD94]).¶

Change Controller:

(see Section 2.3 of RFC 8126 [BCP26])¶

Reference:

a reference document that provides a description of the application-extension identifier¶

The initial content of the registry is shown in Table 9; all initial entries have the Change Controller "IETF".¶

6.3. Media Type

IANA is requested to add the following Media-Type to the "Media Types" registry [IANA.media-types].¶

Type name:

application¶

Subtype name:

cdn¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary (UTF-8)¶

Security considerations:

Section 7 of RFC XXXX¶

Interoperability considerations:

none¶

Published specification:

Section 6.3 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¶

6.4. Content-Format

IANA is requested to register a Content-Format number in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry [IANA.core-parameters], as follows:¶

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.¶

6.5. Tags

RFC-Editor: This document uses the CPA (code point allocation) convention described in [I-D.bormann-cbor-draft-numbers]. For each usage of the term "CPA", please remove the prefix "CPA" from the indicated value and replace the residue with the value assigned by IANA; perform an analogous substitution for all other occurrences of the prefix "CPA" in the document. Finally, please remove this note.¶

In the "CBOR Tags" registry [IANA.cbor-tags], IANA is requested to assign the tags in Table 12 from the "specification required" space (suggested assignments: 888 and 999), with the present document as the specification reference.¶

8.1. Normative References

[BCP14]

Best Current Practice 14, <https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[BCP26]

Best Current Practice 26, <https://www.rfc-editor.org/info/bcp26>.
At the time of writing, this BCP comprises the following:

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[C]

International Organization for Standardization, "Information technology — Programming languages — C", Edition 5, ISO/IEC 9899:2024, October 2024, <https://www.iso.org/standard/82075.html>.
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.

[Cplusplus]

International Organization for Standardization, "Programming languages — C++", Edition 7, ISO/IEC 14882:2024, October 2024, <https://www.iso.org/standard/83626.html>.
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.

[I-D.ietf-core-href]

Bormann, C. and H. Birkholz, "Constrained Resource Identifiers", Work in Progress, Internet-Draft, draft-ietf-core-href-30, 21 November 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-core-href-30>.

[IANA.cbor-tags]

IANA, "Concise Binary Object Representation (CBOR) Tags", <https://www.iana.org/assignments/cbor-tags>.

[IANA.core-parameters]

IANA, "Constrained RESTful Environments (CoRE) Parameters", <https://www.iana.org/assignments/core-parameters>.

[IANA.cose]

IANA, "CBOR Object Signing and Encryption (COSE)", <https://www.iana.org/assignments/cose>.

[IANA.media-types]

IANA, "Media Types", <https://www.iana.org/assignments/media-types>.

[IEEE754]

IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, <https://ieeexplore.ieee.org/document/8766229>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC3987]

Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <https://www.rfc-editor.org/rfc/rfc3987>.

[RFC7405]

Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/rfc/rfc7405>.

[RFC8742]

Bormann, C., "Concise Binary Object Representation (CBOR) Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, <https://www.rfc-editor.org/rfc/rfc8742>.

[RFC9164]

Richardson, M. and C. Bormann, "Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes", RFC 9164, DOI 10.17487/RFC9164, December 2021, <https://www.rfc-editor.org/rfc/rfc9164>.

[RFC9485]

Bormann, C. and T. Bray, "I-Regexp: An Interoperable Regular Expression Format", RFC 9485, DOI 10.17487/RFC9485, October 2023, <https://www.rfc-editor.org/rfc/rfc9485>.

[STD63]

Internet Standard 63, <https://www.rfc-editor.org/info/std63>.
At the time of writing, this STD comprises the following:

Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.

[STD68]

Internet Standard 68, <https://www.rfc-editor.org/info/std68>.
At the time of writing, this STD comprises the following:

Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[STD80]

Internet Standard 80, <https://www.rfc-editor.org/info/std80>.
At the time of writing, this STD comprises the following:

Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.

[STD94]

Internet Standard 94, <https://www.rfc-editor.org/info/std94>.
At the time of writing, this STD comprises the following:

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.

8.2. Informative References

[CDN-WIKI]

"CDN Wiki", n.d., <https://github.com/cbor-wg/edn/wiki>.

[I-D.bormann-cbor-numbers]

Bormann, C., "On Numbers in CBOR", Work in Progress, Internet-Draft, draft-bormann-cbor-numbers-03, 1 March 2026, <https://datatracker.ietf.org/doc/html/draft-bormann-cbor-numbers-03>.

[I-D.bormann-t2trg-deref-id]

Bormann, C. and C. Amsüss, "The "dereferenceable identifier" pattern", Work in Progress, Internet-Draft, draft-bormann-t2trg-deref-id-07, 24 February 2026, <https://datatracker.ietf.org/doc/html/draft-bormann-t2trg-deref-id-07>.

[I-D.ietf-cbor-edn-e-ref]

Bormann, C., "External References to Values in CBOR Diagnostic Notation (EDN)", Work in Progress, Internet-Draft, draft-ietf-cbor-edn-e-ref-03, 1 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-cbor-edn-e-ref-03>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC7049]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/rfc/rfc7049>.

[RFC7493]

Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/rfc/rfc7493>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC9165]

Bormann, C., "Additional Control Operators for the Concise Data Definition Language (CDDL)", RFC 9165, DOI 10.17487/RFC9165, December 2021, <https://www.rfc-editor.org/rfc/rfc9165>.

[RFC9290]

Fossati, T. and C. Bormann, "Concise Problem Details for Constrained Application Protocol (CoAP) APIs", RFC 9290, DOI 10.17487/RFC9290, October 2022, <https://www.rfc-editor.org/rfc/rfc9290>.

[RFC9512]

Polli, R., Wilde, E., and E. Aro, "YAML Media Type", RFC 9512, DOI 10.17487/RFC9512, February 2024, <https://www.rfc-editor.org/rfc/rfc9512>.

[RFC9682]

Bormann, C., "Updates to the Concise Data Definition Language (CDDL) Grammar", RFC 9682, DOI 10.17487/RFC9682, November 2024, <https://www.rfc-editor.org/rfc/rfc9682>.

[RFC9741]

Bormann, C., "Concise Data Definition Language (CDDL): Additional Control Operators for the Conversion and Processing of Text", RFC 9741, DOI 10.17487/RFC9741, March 2025, <https://www.rfc-editor.org/rfc/rfc9741>.

[STD90]

Internet Standard 90, <https://www.rfc-editor.org/info/std90>.
At the time of writing, this STD comprises the following:

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.

[YAML]

Ben-Kiki, O., Evans, C., and I. döt Net, "YAML Ain't Markup Language (YAML™) Version 1.2", Revision 1.2.2, 1 October 2021, <https://yaml.org/spec/1.2.2/>.