]> Universität Bremen TZI

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

Internet-Draft The Concise Binary Object Representation, CBOR (RFC 8949), defines a "diagnostic notation" in order to be able to converse about CBOR data items without having to resort to binary data. ​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 (draft-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. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the cbor Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction For the Concise Binary Object Representation, CBOR, in conjunction with defines a "diagnostic notation" in order to be able to converse about CBOR data items without having to resort to binary data. Diagnostic notation 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 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 . To facilitate tool interoperation, this document also specifies a formal ABNF definition for extended diagnostic notation (EDN) that accommodates application-oriented literals. (See for an overall ABNF grammar as well as the ABNF definitions in for grammars for both the byte string presentations predefined in and the application-extensions). Note that and about CRIs may move to the specification, depending on the relative speed of approval; the later document gets the section.

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 , the diagnostic notation can notate byte strings in a number of 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., \\ 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 (). 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.

The "cri" Extension The application-extension identifier "cri" is used to notate a Constrained Resource Identifier literal as per . The text of the literal is a URI Reference as per or an IRI Reference as per . The value of the literal is a CRI that can be converted to the text of the literal using the procedure of . 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 is equivalent to See for an ABNF definition for the content of CRI literals.

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 . The text of the literal is a Standard Date/Time String as per . The value of the literal is a number representing the result of a conversion of the given Standard Date/Time String to an Epoch-Based Date/Time. If fractional seconds are given in the text (production time-secfrac in ), the value is a floating-point number; the value is an integer number otherwise. As an example, the CBOR diagnostic notation is equivalent to See for an ABNF definition for the content of DT literals.

IANA Considerations

CBOR Diagnostic Notation application extension identifiers registry IANA is requested to create a registry [[where?]] for application-extension identifiers, with the initial content shown in . Initial Content of application extension identifier registry

application-extension identifier	description	reference
h	Reserved	RFC8949
b32	Reserved	RFC8949
h32	Reserved	RFC8949
b64	Reserved	RFC8949
cri	Constrained Resource Identifier	RFCthis
dt	Date/Time	RFCthis

(Define policy: probably specification required?; detailed template)

Media Type IANA is requested to add the following Media-Type to the "Media Types" registry . New Media Type application/cbor-diagnostic

Name	Template	Reference
cbor-diagnostic	application/cbor-diagnostic	RFC XXXX,

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:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

Content-Format IANA is requested to register a Content-Format number in the sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry , as follows: New Content-Format

Content-Type	Content Coding	ID	Reference
application/cbor-diagnostic	-	TBD1	RFC XXXX

TBD1 is to be assigned from the space 256..999.

Security considerations The security considerations of and apply. Anything else meaningful to say here?

References Normative References This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Universität Bremen TZI Fraunhofer SIT The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that serializes the URI components in Concise Binary Object Representation (CBOR) instead of a sequence of characters. This simplifies parsing, comparison and reference resolution in environments with severe limitations on processing power, code size, and memory size. // The present revision -12 of this draft adds a registry that is // intended to provide full coverage for representing a URI scheme // (and certain text strings used in their place) as negative // integers. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources. The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs. The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed:,, and for the construction of constants; / for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and for indicating the use of a non-basic feature in an instance. IANA Informative References This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] IANA

ABNF Definitions

Overall ABNF Definition for Extended Diagnostic Notation This appendix provides an overall ABNF definition for the syntax of CBOR extended diagnostic notation. To complete the parsing of an app-string with prefix, say, p, the processed sqstr inside it is further parsed using the ABNF definition specified for the production app-string-p in . For simplicity, the internal parsing for the built-in EDN prefixes is specified in the same way. ABNF definitions for h'' and b64'' are provided in and . However, the prefixes b32'' and h32'' are not in wide use and an ABNF definition in this document could therefore not be based on implementation experience.

>" array = "[" spec [item S *("," S item S)] "]" map = "{" spec [kp S *("," S kp S)] "}" 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 / %x2f-10FFFF S = *blank *("/" *non-slash "/" *blank ) ; note that there must be at least one string to distinguish streamstring = "(" spec1 tstr S *("," S tstr S) ")" / "(" spec1 sqstr S *("," S sqstr S) ")" 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-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 ALPHA = %x41-5A / lcalpha ; A-Z / a-z ]]>

ABNF Definitions for app-string Content This appendix provides ABNF definitions for application-oriented extension literals defined in and in this specification. These grammars describe the decoded content of the sqstr components that combine with the application-extension identifiers to form application-oriented extension literals. Each of these may make use of rules defined in .

h: ABNF Definition of Hexadecimal representation of a byte string The syntax of the content of byte strings represented in hex, such as h'', h'0815, or h'/head/ 63 /contents/ 66 6f 6f' (another representation of `<< "foo" >>), is described by the ABNF in . This syntax accommodates both lower case and upper case hex digits, as well as blank space (including comments) around each hex digit.

ABNF Definition of Hexadecimal Representation of a Byte String

b64: ABNF Definition of Base64 representation of a byte string The syntax of the content of byte strings represented in base64 is described by the ABNF in . This syntax allows both the classic and the URL-safe alphabet to be used. It accommodates, but does not require base64 padding. Note that inclusion of classic base64 makes it impossible to have comments in b64, as "/" is valid base64-classic.

ABNF definition of Base64 Representation of a Byte String

dt: ABNF Definition of RFC 3339 Representation of a Date/Time The syntax of the content of dt literals can be described by the ABNF for date-time from as summarized in :

ABNF Definition of RFC3339 Representation of a Date/Time

cri: ABNF Definition of URI Representation of a CRI The syntax of the content of cri literals can be described by the ABNF for URI-reference in :

ABNF Definition of URI Representation of a CRI 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 = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" ]]>

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.