All actual interchange always happens in the binary format.

• looks like JSON where that is possible;
• inserts encoding indicators only where the binary form differs from preferred encoding;
• 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 :.

1. null (indicating a data item entirely replaced by an ellipsis), or it is
2. an array, the elements of which are alternating between fragments of a string and the actual elisions, represented as ellipses carrying a null as content.

• 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 now 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.
• basenumber stands for an integer in the usual base 16/hexadecimal ("0x"), base 8/octal ("0o"), or base 2/binary ("0b") notation, unless the optional part containing a "p" is present, in which case it 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.2 of , or Section 5.13.4 of ; floating-suffix/floating-point-suffix from the latter two is not used here).
• When decnumber or basenumber 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. Otherwise, and for infin, a floating point data item with major type 7 is used in preferred serialization (unless modified by an encoding indicator, which then needs to be _1, _2, or _3). For this, the number range needs to fit into a 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.
• spec stands for an encoding indicator. (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 .) As per Section of RFC 8949 :
  • an underscore _ on its own stands for indefinite length encoding (ai=31, only available behind the opening brace/bracket for map and array: strings have a special syntax streamstring for indefinite length encoding except for the special cases ''_ and ""_), and
  • _0 to _3 stand for ai=24 to ai=27, respectively.
  Surprisingly, Section of RFC 8949 does not address ai=0 to ai=23 — the assumption seems to be 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 to make this explicit:
  • _i ("immediate") stands for encoding with ai=0 to ai=23.
  While no pressing use for further values for encoding indicators comes to mind, this is an extension point for EDN; defines a registry for additional values.
• string and the rules preceding it in the same block realize both the representation of strings that are split up into multiple chunks () and the use of ellipses to represent elisions (). Note that the syntax defined here for concatenation of components uses an explicit + operator between the components to be concatenated; used simple juxtaposition, which got in the way of making the use of commas optional in other places (OC). The example equivalent text strings from now read: Similarly, the following byte string values are equivalent: The semantic processing of these rules is relatively complex:
  • A single ... is a general ellipsis, which can stand for any data item.
  • An ellipsis can be concatenated (on one or both sides) with string chunks (string1); the result is a CBOR tag number CPA888 that contains an array with joined together spans of such chunks plus the ellipses represented by 888(null).
  • A concatenated sequence of string chunks is simply joined together. In both cases of joining strings, the rules of need to be followed; in particular, if a text string results from the joining operation, that result needs to be valid UTF-8.
  • Some of the strings may be app-strings. If the type of the app-string is an actual string, joining of chunked strings occurs as with directly notated strings; otherwise the occurrence of more than one app-string or an app-string together with a directly notated string cannot be processed.

Application-Extension Identifier:

a lower case ASCII string that starts with a letter and can contain letters and digits 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 of RFC 8126 )

Reference:

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

Encoding Indicator:

an ASCII 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 of RFC 8949 ).

Change Controller:

(see Section of RFC 8126 )

Reference:

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

Type name:

application

Subtype name:

cbor-diagnostic

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

.diag

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:

CBOR diagnostic notation represents CBOR data items, which are the format intended for actual interchange. The media type application/cbor-diagnostic 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