idnits 2.17.1 draft-bormann-cbor-edn-literals-00.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (6 October 2021) is 931 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-core-href-06 == Outdated reference: A later version (-06) exists of draft-ietf-core-coral-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universität Bremen TZI 4 Intended status: Informational 6 October 2021 5 Expires: 9 April 2022 7 Application-Oriented Literals in CBOR Extended Diagnostic Notation 8 draft-bormann-cbor-edn-literals-00 10 Abstract 12 The Concise Binary Object Representation, CBOR (RFC 8949) defines a 13 "diagnostic notation" in order to be able to converse about CBOR data 14 items without having to resort to binary data. 16 This document specifies how to add application-oriented extensions to 17 the diagnostic notation. It then defines two such extensions for the 18 use of CBOR diagnostic notation with CoRAL and Constrained Resource 19 Identifiers (draft-ietf-core-coral, draft-ietf-core-href). 21 Note 23 This note is to be removed before publishing as an RFC. 25 The content of this draft may preferably be distributed to a number 26 of different documents. This is to be decided. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 9 April 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Application-Oriented Extension Literals . . . . . . . . . . . 2 63 3. The "cri" Extension . . . . . . . . . . . . . . . . . . . . . 3 64 4. The "dt" Extension . . . . . . . . . . . . . . . . . . . . . 4 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 6. Security considerations . . . . . . . . . . . . . . . . . . . 5 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 69 7.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 For the Concise Binary Object Representation, CBOR, Section 8 of 76 [RFC8949] defines a "diagnostic notation" in order to be able to 77 converse about CBOR data items without having to resort to binary 78 data. Diagnostic notation is based on JSON, with extensions for 79 representing CBOR constructs such as binary data and tags. 80 (Standardizing this together with the actual interchange format does 81 not serve to create another interchange format, but enables the use 82 of a shared diagnostic notation in tools for and documents about 83 CBOR.) 85 This document specifies how to add application-oriented extensions to 86 the diagnostic notation. It then defines two such extensions for the 87 use of CBOR diagnostic notation with CoRAL and Constrained Resource 88 Identifiers [I-D.ietf-core-coral] [I-D.ietf-core-href]. 90 2. Application-Oriented Extension Literals 92 This document extends the syntax used in diagnostic notation for byte 93 string literals to also be available for application-oriented 94 extensions. 96 As per Section 8 of [RFC8949], the diagnostic notation can notate 97 byte strings in a number of [RFC4648] base encodings, where the 98 encoded text is enclosed in single quotes, prefixed by an identifier 99 (>h< for base16, >b32< for base32, >h32< for base32hex, >b64< for 100 base64 or base64url). 102 This syntax can be thought to establish a name space, with the names 103 "h", "b32", "h32", and "b64" taken, but other names being 104 unallocated. The present specification defines additional names for 105 this namespace, which we call _application-extension identifiers_. 106 For the quoted string, the same rules apply as for byte strings. In 107 particular, the escaping rules of JSON strings are applied 108 equivalently for application-oriented extensions, e.g., \\ stands for 109 a single backslash and \' stands for a single quote. 111 An application-extension identifier is a name consisting of a lower- 112 case ASCII letter (a-z) and zero or more additional ASCII characters 113 that are either lower-case letters or digits (a-z0-9). 115 Application-extension identifiers are registered in a registry 116 (Section 5). Prefixing a single-quoted string, an application- 117 extension identifier is used to build an application-oriented 118 extension literal, which stands for a CBOR data item the value of 119 which is derived from the text given in the single-quoted string 120 using a procedure defined in the specification for an application- 121 extension identifier. 123 Examples for application-oriented extensions to CBOR diagnostic 124 notation can be found in the following sections. 126 3. The "cri" Extension 128 The application-extension identifier "cri" is used to notate a 129 Constrained Resource Identifier literal as per [I-D.ietf-core-href]. 131 The text of the literal is a URI Reference as per [RFC3986] or an IRI 132 Reference as per [RFC3987]. 134 The value of the literal is a CRI that can be converted to the text 135 of the literal using the procedure of Section 6.1 of 136 [I-D.ietf-core-href]. Note that there may be more than one CRI that 137 can be converted to the URI/IRI given; implementations are expected 138 to favor the simplest variant available and make non-surprising 139 choices otherwise. 141 As an example, the CBOR diagnostic notation 143 cri'https://example.com/bottarga/shaved' 144 is equivalent to 146 [-4, ["example", "com"], ["bottarga", "shaved"]] 148 4. The "dt" Extension 150 The application-extension identifier "dt" is used to notate a date/ 151 time literal that can be used as an Epoch-Based Date/Time as per 152 Section 3.4.2 of [RFC8949]. 154 The text of the literal is a Standard Date/Time String as per 155 Section 3.4.1 of [RFC8949]. 157 The value of the literal is a number representing the result of a 158 conversion of the given Standard Date/Time String to an Epoch-Based 159 Date/Time. If fractional seconds are given in the text (production 160 time-fraction in Appendix A of [RFC3339]), the value is a floating- 161 point number; the value is an integer number otherwise. 163 As an example, the CBOR diagnostic notation 165 dt'1969-07-21T02:56:16Z' 167 is equivalent to 169 -14159024 171 5. IANA Considerations 173 IANA is requested to create a registry [[where?]] for application- 174 extension identifiers, with the initial content shown in Table 1. 176 +=======================+=====================+===========+ 177 | application-extension | description | reference | 178 | identifier | | | 179 +=======================+=====================+===========+ 180 | h | Reserved | RFC8949 | 181 +-----------------------+---------------------+-----------+ 182 | b32 | Reserved | RFC8949 | 183 +-----------------------+---------------------+-----------+ 184 | h32 | Reserved | RFC8949 | 185 +-----------------------+---------------------+-----------+ 186 | b64 | Reserved | RFC8949 | 187 +-----------------------+---------------------+-----------+ 188 | cri | Constrained | RFCthis | 189 | | Resource Identifier | | 190 +-----------------------+---------------------+-----------+ 191 | dt | Date/Time | RFCthis | 192 +-----------------------+---------------------+-----------+ 194 Table 1: Initial Content of application extension 195 identifier registry 197 // (Define policy; detailed template) 199 6. Security considerations 201 The security considerations of [RFC8949] and [RFC8610] apply. 203 // Anything else meaningful to say here? 205 7. References 207 7.1. Normative References 209 [I-D.ietf-core-href] 210 Bormann, C. and H. Birkholz, "Constrained Resource 211 Identifiers", Work in Progress, Internet-Draft, draft- 212 ietf-core-href-06, 25 July 2021, 213 . 216 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 217 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 218 . 220 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 221 Resource Identifier (URI): Generic Syntax", STD 66, 222 RFC 3986, DOI 10.17487/RFC3986, January 2005, 223 . 225 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 226 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 227 January 2005, . 229 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 230 Definition Language (CDDL): A Notational Convention to 231 Express Concise Binary Object Representation (CBOR) and 232 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 233 June 2019, . 235 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 236 Representation (CBOR)", STD 94, RFC 8949, 237 DOI 10.17487/RFC8949, December 2020, 238 . 240 7.2. Informative References 242 [I-D.ietf-core-coral] 243 Hartke, K., "The Constrained RESTful Application Language 244 (CoRAL)", Work in Progress, Internet-Draft, draft-ietf- 245 core-coral-03, 9 March 2020, 246 . 249 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 250 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 251 . 253 Acknowledgements 255 The concept of application-oriented extensions to diagnostic 256 notation, as well as the definition for the "dt" extension were 257 inspired by the CoRAL work by Klaus Hartke. 259 Author's Address 261 Carsten Bormann 262 Universität Bremen TZI 263 Postfach 330440 264 D-28359 Bremen 265 Germany 267 Phone: +49-421-218-63921 268 Email: cabo@tzi.org