Skip to main content

Application-Oriented Literals in CBOR Extended Diagnostic Notation
draft-bormann-cbor-edn-literals-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Author Carsten Bormann
Last updated 2022-10-24
Replaced by draft-ietf-cbor-edn-literals, draft-ietf-cbor-edn-literals, draft-ietf-cbor-edn-literals
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-bormann-cbor-edn-literals-01
Network Working Group                                         C. Bormann
Internet-Draft                                    Universität Bremen TZI
Intended status: Informational                           24 October 2022
Expires: 27 April 2023

   Application-Oriented Literals in CBOR Extended Diagnostic Notation
                   draft-bormann-cbor-edn-literals-01

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

About This Document

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

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-bormann-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/cabo/edn-literal.

Note

   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.

Bormann                   Expires 27 April 2023                 [Page 1]
Internet-Draft              CBOR EDN Literals               October 2022

   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 27 April 2023.

Copyright Notice

   Copyright (c) 2022 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Application-Oriented Extension Literals . . . . . . . . . . .   3
   3.  The "cri" Extension . . . . . . . . . . . . . . . . . . . . .   4
   4.  The "dt" Extension  . . . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security considerations . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

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
   is based on JSON, with extensions for representing CBOR constructs
   such as binary data and tags.  (Standardizing this together with the

Bormann                   Expires 27 April 2023                 [Page 2]
Internet-Draft              CBOR EDN Literals               October 2022

   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.

Bormann                   Expires 27 April 2023                 [Page 3]
Internet-Draft              CBOR EDN Literals               October 2022

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

Bormann                   Expires 27 April 2023                 [Page 4]
Internet-Draft              CBOR EDN Literals               October 2022

5.  IANA Considerations

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

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

             Table 1: Initial Content of application extension
                            identifier registry

   // (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-11, 7 September 2022,
              <https://www.ietf.org/archive/id/draft-ietf-core-href-
              11.txt>.

Bormann                   Expires 27 April 2023                 [Page 5]
Internet-Draft              CBOR EDN Literals               October 2022

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <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, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
              January 2005, <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,
              June 2019, <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, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

7.2.  Informative References

   [I-D.ietf-core-coral]
              Amsüss, C. and T. Fossati, "The Constrained RESTful
              Application Language (CoRAL)", Work in Progress, Internet-
              Draft, draft-ietf-core-coral-05, 7 March 2022,
              <https://www.ietf.org/archive/id/draft-ietf-core-coral-
              05.txt>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <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

Bormann                   Expires 27 April 2023                 [Page 6]
Internet-Draft              CBOR EDN Literals               October 2022

   Carsten Bormann
   Universität Bremen TZI
   Postfach 330440
   D-28359 Bremen
   Germany
   Phone: +49-421-218-63921
   Email: cabo@tzi.org

Bormann                   Expires 27 April 2023                 [Page 7]