Internet-Draft CBOR EDN Literals October 2021
Bormann Expires 9 April 2022 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-bormann-cbor-edn-literals-00
Published:
Intended Status:
Informational
Expires:
Author:
C. Bormann
Universität Bremen TZI

Application-Oriented Literals in CBOR Extended Diagnostic Notation

Abstract

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 the use of CBOR diagnostic notation with CoRAL and Constrained Resource Identifiers (draft-ietf-core-coral, draft-ietf-core-href).

This note is to be removed before publishing as an RFC.

The content of this draft may preferably be distributed to a number of different documents. This is to be decided.

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 9 April 2022.

Table of Contents

1. Introduction

For the Concise Binary Object Representation, CBOR, Section 8 of [RFC8949] 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 the use of CBOR diagnostic notation with CoRAL and Constrained Resource Identifiers [I-D.ietf-core-coral] [I-D.ietf-core-href].

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., \\ 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). 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.

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"]]

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-fraction in Appendix A of [RFC3339]), 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

5. IANA Considerations

IANA is requested to create a registry [[where?]] for application-extension identifiers, with the initial content shown in Table 1.

Table 1: 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; detailed template)

6. Security considerations

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

Anything else meaningful to say here?

7. References

7.1. Normative References

[I-D.ietf-core-href]
Bormann, C. and H. Birkholz, "Constrained Resource Identifiers", Work in Progress, Internet-Draft, draft-ietf-core-href-06, , <https://www.ietf.org/archive/id/draft-ietf-core-href-06.txt>.
[RFC3339]
Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, , <https://www.rfc-editor.org/info/rfc3339>.
[RFC3986]
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <https://www.rfc-editor.org/info/rfc3986>.
[RFC3987]
Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, , <https://www.rfc-editor.org/info/rfc3987>.
[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, , <https://www.rfc-editor.org/info/rfc8610>.
[RFC8949]
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/info/rfc8949>.

7.2. Informative References

[I-D.ietf-core-coral]
Hartke, K., "The Constrained RESTful Application Language (CoRAL)", Work in Progress, Internet-Draft, draft-ietf-core-coral-03, , <https://www.ietf.org/archive/id/draft-ietf-core-coral-03.txt>.
[RFC4648]
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, , <https://www.rfc-editor.org/info/rfc4648>.

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

Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany