CBOR Extended Diagnostic Notation (EDN): Application-Oriented Literals and ABNF

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 3 April 2024.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

For the Concise Binary Object Representation, CBOR, Section 8 of [RFC8949] in conjunction with Appendix G of [RFC8610] defines a "diagnostic notation" in order to be able to converse about CBOR data items without having to resort to binary data. Diagnostic notation syntax is based on JSON, with extensions for representing CBOR constructs such as binary data and tags. (Standardizing this together with the actual interchange format does not serve to create another interchange format, but enables the use of a shared diagnostic notation in tools for and in documents about CBOR.)¶

This document specifies how to add application-oriented extensions to the diagnostic notation. It then defines two such extensions for text representations of epoch-based date/times and of Constrained Resource Identifiers [I-D.ietf-core-href].¶

To facilitate tool interoperation, this document also specifies a formal ABNF definition for extended diagnostic notation (EDN) that accommodates application-oriented literals. (See Appendix A.1 for an overall ABNF grammar as well as the ABNF definitions in Appendix A.2 for grammars for both the byte string presentations predefined in [RFC8949] and the application-extensions).¶

Note that Section 3 and Appendix A.2.4 about CRIs may move to the [I-D.ietf-core-href] specification, depending on the relative speed of approval; the later document gets the section.¶

2. Application-Oriented Extension Literals

This document extends the syntax used in diagnostic notation for byte string literals to also be available for application-oriented extensions.¶

As per Section 8 of [RFC8949], the diagnostic notation can notate byte strings in a number of [RFC4648] base encodings, where the encoded text is enclosed in single quotes, prefixed by an identifier (»h« for base16, »b32« for base32, »h32« for base32hex, »b64« for base64 or base64url).¶

This syntax can be thought to establish a name space, with the names "h", "b32", "h32", and "b64" taken, but other names being unallocated. The present specification defines additional names for this namespace, which we call application-extension identifiers. For the quoted string, the same rules apply as for byte strings. In particular, the escaping rules of JSON strings are applied equivalently for application-oriented extensions, e.g., within the quoted string \\ stands for a single backslash and \' stands for a single quote.¶

An application-extension identifier is a name consisting of a lower-case ASCII letter (a-z) and zero or more additional ASCII characters that are either lower-case letters or digits (a-z0-9).¶

Application-extension identifiers are registered in a registry (Section 5.1). Prefixing a single-quoted string, an application-extension identifier is used to build an application-oriented extension literal, which stands for a CBOR data item the value of which is derived from the text given in the single-quoted string using a procedure defined in the specification for an application-extension identifier.¶

Examples for application-oriented extensions to CBOR diagnostic notation can be found in the following sections.¶

In addition, this document finally registers a media type identifier and a content-format for CBOR diagnostic notation. 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.¶

3. The "cri" Extension

The application-extension identifier "cri" is used to notate a Constrained Resource Identifier literal as per [I-D.ietf-core-href].¶

The text 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 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 that can be converted to the URI/IRI given; implementations are expected to favor the simplest variant available and make non-surprising choices otherwise.¶

As an example, the CBOR diagnostic notation¶

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

is equivalent to¶

[-4, ["example", "com"], ["bottarga", "shaved"]]

See Appendix A.2.4 for an ABNF definition for the content of CRI literals.¶

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

The text of the literal is a Standard Date/Time String as per Section 3.4.1 of [RFC8949].¶

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 4), the value is a floating-point number; the value is an integer number otherwise.¶

As an example, the CBOR diagnostic notation¶

[dt'1969-07-21T02:56:16Z',
 dt'1969-07-21T02:56:16.5Z']

is equivalent to¶

[-14159024, -14159023.5]

See Appendix A.2.3 for an ABNF definition for the content of DT literals.¶

5. IANA Considerations

6. Security considerations

The security considerations of [RFC8949] and [RFC8610] apply.¶

Anything else meaningful to say here?¶

Appendix A. ABNF Definitions

seq             = S [item S *("," S item S) OC] S
item            = map / array / tagged
                / basenumber / decnumber / infin / simple
                / tstr / bstr / embedded / streamstring

sign            = "+" / "-"
decnumber       = [sign] 1*DIGIT ["." 1*DIGIT] ["e" [sign] 1*DIGIT]
basenumber      = [sign] "0" ("x" 1*HEXDIG
                              [["." 1*HEXDIG] "p" [sign] *DIGIT]
                            / "o" 1*ODIGIT
                            / "b" 1*BDIGIT)
infin           = %s"Infinity"
                / %s"-Infinity"
                / %s"NaN"
simple          = %s"false"
                / %s"true"
                / %s"null"
                / %s"undefined"
                / %s"simple(" S item S ")"
uint            = "0" / DIGIT1 *DIGIT
tagged          = uint "(" S item S ")"

app-prefix      = lcalpha *lcalnum ; including h and b64
app-string      = app-prefix sqstr
sqstr           = "'" *single-quoted "'"
bstr            = app-string / sqstr ; app could be any type
tstr            = DQUOTE *double-quoted DQUOTE
embedded        = "<<" seq ">>"

array           = "[" spec [item S *("," S item S) OC] "]"
map             = "{" spec [kp S *("," S kp S) OC] "}"
kp              = item S ":" S item

; We allow %x09 HT in prose, but not in strings
blank           = %x09 / %x0A / %x0D / %x20
non-slash       = blank / %x21-2e / %x30-D7FF / %xE000-10FFFF
non-lf          = %x09 / %x0D / %x20-D7FF / %xE000-10FFFF
S               = *blank *(comment *blank)
comment         = "/" *non-slash "/"
                / "#" *non-lf %x0A

; optional trailing comma (ignored)
OC              = ["," S]

; note that there must be at least one string to distinguish
streamstring    = "(" spec1 tstr S *("," S tstr S) OC ")"
                / "(" spec1 bstr S *("," S bstr S) OC ")"
spec            = S ["_" S]
spec1           = S "_" S

double-quoted   = unescaped
                / "'"
                / "\" DQUOTE
                / "\" escapable

single-quoted   = unescaped
                / DQUOTE
                / "\" "'"
                / "\" escapable

escapable       = %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
                / "/"   ; / slash (solidus) U+002F (JSON!)
                / "\"   ; \ backslash (reverse solidus) U+005C
                / (%s"u" hexchar) ;  uXXXX      U+XXXX

hexchar         = non-surrogate
                / (high-surrogate "\" %s"u" low-surrogate)
non-surrogate   = ((DIGIT / "A"/"B"/"C" / "E"/"F") 3HEXDIG)
                / ("D" ODIGIT 2HEXDIG )
high-surrogate  = "D" ("8"/"9"/"A"/"B") 2HEXDIG
low-surrogate   = "D" ("C"/"D"/"E"/"F") 2HEXDIG

; 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-D7FF ; skip surrogate code points
                / %xE000-10FFFF

DQUOTE          = %x22    ; " double quote
DIGIT           = %x30-39 ; 0-9
DIGIT1          = %x31-39 ; 1-9
ODIGIT          = %x30-37 ; 0-7
BDIGIT          = %x30-31 ; 0-1
HEXDIG          = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
; Note: double-quoted strings as in "A" are case-insensitive in ABNF
lcalpha         = %x61-7A ; a-z
lcalnum         = lcalpha / DIGIT

app-string-h    = S *(HEXDIG S HEXDIG S)

app-string-b64  = B *(4(b64dig B))
                  [b64dig B b64dig B ["=" B "=" / b64dig B ["="]] B]
b64dig          = ALPHA / DIGIT / "-" / "_" / "+" / "/"
B               = *iblank *(icomment *iblank)
iblank          = %x0A / %x20  ; Not HT or CR (gone)
icomment        = "#" *inon-lf %x0A
inon-lf         = %x20-D7FF / %xE000-10FFFF

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
DIGIT           =  %x30-39 ; 0-9

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

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

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

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    = "!" / "$" / "&" / "'" / "(" / ")"
                 / "*" / "+" / "," / ";" / "="

Appendix B. EDN and CDDL

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

• EDN syntax is an extension to JSON syntax [RFC8259]. (Any (interoperable) JSON text is also valid EDN.)¶

• CDDL syntax is inspired by ABNF's syntax [RFC5234].¶

For engineers that are using both EDN and CDDL, it is easy to write "CDDLisms" or "EDNisms" 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 EDN finds nothing in JSON that could be inherited here. Inspired by JavaScript, EDN simplifies JavaScript's copy of the original C comment syntax to be delimited by single slashes (where line ends are not of interest); it also adds end-of-line comments starting with #.¶

  EDN:

  { / alg / 1: -7 / ECDSA 256 / }
  ,
  { 1:   # alg
      -7 # ECDSA 256
  }
  

  ¶

  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 [I-D.ietf-cbor-update-8610-grammar]) allows specifying the actual tag number separately, while EDN's tag syntax is a simple decimal number and a pair of parentheses.¶

  EDN:

  98(['', {}, /rest elided here: …/])¶

  CDDL:

  COSE_Sign_Tagged = #6.98(COSE_Sign)¶

• Separator character. Like JSON, EDN requires commas as separators between array elements and map members and doesn't allow a trailing comma before the closing bracket/brace. CDDL's comma separators in these contexts (CDDL groups) are optional (and actually are terminators, which together with their optionality allows them to be used like separators as well or even not at all).¶

• Embedded CBOR. EDN 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.¶

  EDN:

  98([/h'a10126'/ << {/alg/ 1: -7 /ECDSA 256/ } >>, /…/])¶

  CDDL:

  serialized_map = bytes .cbor header_map¶

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

Author's Address