Network Working Group C. Bormann Internet-Draft Universität Bremen TZI Intended status: Informational 1 October 2023 Expires: 3 April 2024 CBOR Extended Diagnostic Notation (EDN): Application-Oriented Literals and ABNF draft-ietf-cbor-edn-literals-04 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 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 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Bormann Expires 3 April 2024 [Page 1] Internet-Draft CBOR EDN: Literals and ABNF October 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Application-Oriented Extension Literals . . . . . . . . . . . 4 3. The "cri" Extension . . . . . . . . . . . . . . . . . . . . . 5 4. The "dt" Extension . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5.1. CBOR Diagnostic Notation application extension identifiers registry . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Content-Format . . . . . . . . . . . . . . . . . . . . . 8 6. Security considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. ABNF Definitions . . . . . . . . . . . . . . . . . . 10 A.1. Overall ABNF Definition for Extended Diagnostic Notation . . . . . . . . . . . . . . . . . . . . . . . . 10 A.2. ABNF Definitions for app-string Content . . . . . . . . . 13 A.2.1. h: ABNF Definition of Hexadecimal representation of a byte string . . . . . . . . . . . . . . . . . . . . . 13 Bormann Expires 3 April 2024 [Page 2] Internet-Draft CBOR EDN: Literals and ABNF October 2023 A.2.2. b64: ABNF Definition of Base64 representation of a byte string . . . . . . . . . . . . . . . . . . . . . . . 13 A.2.3. dt: ABNF Definition of RFC 3339 Representation of a Date/Time . . . . . . . . . . . . . . . . . . . . . . 13 A.2.4. cri: ABNF Definition of URI Representation of a CRI . . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix B. EDN and CDDL . . . . . . . . . . . . . . . . . . . . 16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 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. 1.1. Terminology Section 8 of [RFC8949] defines the original CBOR diagnostic notation, and Appendix G of [RFC8610] supplies a number of extensions to the diagnostic notation that result in the Extended Diagnostic Notation (EDN). The diagnostic notation extensions include popular features such as embedded CBOR (encoded CBOR data items in byte strings) and comments. A simple diagnostic notation extension that enables representing CBOR sequences was added in Section 4.2 of [RFC8742]. Bormann Expires 3 April 2024 [Page 3] Internet-Draft CBOR EDN: Literals and ABNF October 2023 As diagnostic notation is not used in the kind of interchange situations where backward compatibility would pose a significant obstacle, there is little point in not using these extensions. Therefore, when we refer to "_diagnostic notation_", we mean to include the original notation from Section 8 of [RFC8949] as well as the extensions from Appendix G of [RFC8610], Section 4.2 of [RFC8742], and the present document. However, we stick to the abbreviation "_EDN_" as it has become quite popular and is more sharply distinguishable from other meanings than "DN" would be. In a similar vein, the term "ABNF" in this document refers to the language defined in [RFC5234] as extended in [RFC7405], where the "characters" of Section 2.3 of [RFC5234] are Unicode scalar values. The term "CDDL" refers to the data definition language defined in [RFC8610] and its registered extensions (such as those in [RFC9165]), as well as [I-D.ietf-cbor-update-8610-grammar]. 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 Bormann Expires 3 April 2024 [Page 4] Internet-Draft CBOR EDN: Literals and ABNF October 2023 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]. Bormann Expires 3 April 2024 [Page 5] Internet-Draft CBOR EDN: Literals and ABNF October 2023 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 5.1. 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 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 Bormann Expires 3 April 2024 [Page 6] Internet-Draft CBOR EDN: Literals and ABNF October 2023 // (Define policy: probably specification required?; detailed // template) 5.2. Media Type 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 | +-----------------+-----------------------------+-------------+ Table 2: New Media Type application/cbor-diagnostic Type name: application Subtype name: cbor-diagnostic Required parameters: N/A Optional parameters: N/A Encoding considerations: binary (UTF-8) Security considerations: Section 6 of RFC XXXX Interoperability considerations: none Published specification: Section 5.2 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 Bormann Expires 3 April 2024 [Page 7] Internet-Draft CBOR EDN: Literals and ABNF October 2023 5.3. Content-Format 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 | +-----------------------------+----------------+------+-----------+ Table 3: New Content-Format TBD1 is to be assigned from the space 256..999. 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-cbor-update-8610-grammar] Bormann, C., "Updates to the CDDL grammar of RFC 8610", Work in Progress, Internet-Draft, draft-ietf-cbor-update- 8610-grammar-00, 17 June 2023, . [I-D.ietf-core-href] Bormann, C. and H. Birkholz, "Constrained Resource Identifiers", Work in Progress, Internet-Draft, draft- ietf-core-href-13, 10 July 2023, . [IANA.media-types] IANA, "Media Types", . Bormann Expires 3 April 2024 [Page 8] Internet-Draft CBOR EDN: Literals and ABNF October 2023 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [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, . [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [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, . [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9165] Bormann, C., "Additional Control Operators for the Concise Data Definition Language (CDDL)", RFC 9165, DOI 10.17487/RFC9165, December 2021, . 7.2. Informative References Bormann Expires 3 April 2024 [Page 9] Internet-Draft CBOR EDN: Literals and ABNF October 2023 [IANA.core-parameters] IANA, "Constrained RESTful Environments (CoRE) Parameters", . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . Appendix A. ABNF Definitions A.1. 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 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. 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 ")" Bormann Expires 3 April 2024 [Page 10] Internet-Draft CBOR EDN: Literals and ABNF October 2023 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 Bormann Expires 3 April 2024 [Page 11] Internet-Draft CBOR EDN: Literals and ABNF October 2023 / (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 Figure 1 While an ABNF grammar defines the set of character strings that are considered to be valid EDN by this ABNF, the mapping of these character strings into the generic data model of CBOR is not always obvious. The following additional items should help in the interpretation: * decnumber stands for an integer in the usual decimal notation, unless at least one of the optional parts starting with "." and "e" are present, in which case it stands for a floating point value in the usual decimal notation. * basenumber stands for an integer in the usual base 16/hexadecimal ("0x"), base 8/octal ("0o"), or base 2/binary ("0b") notation, unless the optional part containing a "p" is present, in which case it stands for a floating point number in the usual hexadecimal notation (which uses a mantissa in hexadecimal and an exponent in decimal notation). Bormann Expires 3 April 2024 [Page 12] Internet-Draft CBOR EDN: Literals and ABNF October 2023 A.2. ABNF Definitions for app-string Content 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. A.2.1. 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 Figure 2. This syntax accommodates both lower case and upper case hex digits, as well as blank space (including comments) around each hex digit. app-string-h = S *(HEXDIG S HEXDIG S) Figure 2: ABNF Definition of Hexadecimal Representation of a Byte String A.2.2. 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 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 in-line comments in b64, as "/" is valid base64-classic. 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 Figure 3: ABNF definition of Base64 Representation of a Byte String A.2.3. 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 [RFC3339] as summarized in Section 3 of [RFC9165]: Bormann Expires 3 April 2024 [Page 13] Internet-Draft CBOR EDN: Literals and ABNF October 2023 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 Figure 4: ABNF Definition of RFC3339 Representation of a Date/Time A.2.4. 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 Section 4.1 of [RFC3986], as reproduced in Figure 5. If the content is not ASCII only (i.e., for IRIs), first apply Section 3.1 of [RFC3987] and apply this grammar to the result. 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 Bormann Expires 3 April 2024 [Page 14] Internet-Draft CBOR EDN: Literals and ABNF October 2023 / 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 Bormann Expires 3 April 2024 [Page 15] Internet-Draft CBOR EDN: Literals and ABNF October 2023 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 = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" Figure 5: ABNF Definition of URI Representation of a CRI 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: Bormann Expires 3 April 2024 [Page 16] Internet-Draft CBOR EDN: Literals and ABNF October 2023 * 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. Bormann Expires 3 April 2024 [Page 17] Internet-Draft CBOR EDN: Literals and ABNF October 2023 Author's Address Carsten Bormann Universität Bremen TZI Postfach 330440 D-28359 Bremen Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Bormann Expires 3 April 2024 [Page 18]