Internet-Draft | CBOR EDN Literals | July 2023 |
Bormann | Expires 11 January 2024 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://cbor-wg.github.io/edn-literal/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/.¶
Discussion of this document takes place on the cbor Working Group mailing list (mailto:cbor@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cbor/. Subscribe at https://www.ietf.org/mailman/listinfo/cbor/.¶
Source for this draft and an issue tracker can be found at https://github.com/cbor-wg/edn-literal.¶
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 11 January 2024.¶
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.¶
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 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 [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.¶
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., \\
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.¶
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.¶
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'¶
is equivalent to¶
-14159024¶
See Appendix A.2.3 for an ABNF definition for the content of DT literals.¶
IANA is requested to create a registry [[where?]] for application-extension identifiers, with the initial content shown in Table 1.¶
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)¶
IANA is requested to add the following Media-Type to the "Media Types" registry [IANA.media-types].¶
Name | Template | Reference |
---|---|---|
cbor-diagnostic | application/cbor-diagnostic | RFC XXXX, Section 5.2 |
application¶
cbor-diagnostic¶
N/A¶
N/A¶
binary (UTF-8)¶
none¶
Section 5.2 of RFC XXXX¶
Tools interchanging a human-readable form of CBOR¶
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".)¶
CBOR WG mailing list (cbor@ietf.org), or IETF Applications and Real-Time Area (art@ietf.org)¶
COMMON¶
none¶
IETF¶
no¶
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:¶
Content-Type | Content Coding | ID | Reference |
---|---|---|---|
application/cbor-diagnostic | - | TBD1 | RFC XXXX |
TBD1 is to be assigned from the space 256..999.¶
The security considerations of [RFC8949] and [RFC8610] apply.¶
Anything else meaningful to say here?¶
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 Appendix A.2.¶
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 Appendix A.2.1 and
Appendix A.2.2.
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.¶
This appendix provides ABNF definitions for application-oriented extension
literals defined in [RFC8949] 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 Figure 1.¶
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 Figure 2.
This syntax accommodates both lower case and upper case hex digits, as
well as blank space (including comments) around each hex digit.¶
The syntax of the content of byte strings represented in base64 is described by the ABNF in Figure 2.¶
This syntax allows both the classic Section 4 of [RFC4648] and the URL-safe Section 5 of [RFC4648] 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.¶
The syntax of the content of dt
literals can be described by the
ABNF for date-time
from [RFC3339] as summarized in Section 3 of [RFC9165]:¶
The syntax of the content of cri
literals can be described by the
ABNF for URI-reference
in Section 4.1 of [RFC3986]:¶
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.¶