idnits 2.17.00 (12 Aug 2021) /tmp/idnits19629/draft-bormann-cbor-cddl-csv-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 document date (24 February 2022) is 79 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 4180 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: Standards Track 24 February 2022 5 Expires: 28 August 2022 7 Using CDDL for CSVs 8 draft-bormann-cbor-cddl-csv-00 10 Abstract 12 The Concise Data Definition Language (CDDL), standardized in RFC 13 8610, is defined to provide data models for data shaped like JSON or 14 CBOR. 16 Another representation format that is quote popular is the CSV file 17 as defined by RFC 4180. 19 The present document shows how to use CDDL to provide a data model 20 for CSV files. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 28 August 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. CSV generic data model . . . . . . . . . . . . . . . . . . . 2 58 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 5. Security considerations . . . . . . . . . . . . . . . . . . . 5 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 6.2. Informative References . . . . . . . . . . . . . . . . . 5 64 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 The Concise Data Definition Language (CDDL), standardized in 70 [RFC4180], is defined to provide data models for data shaped like 71 JSON or CBOR. 73 Another representation format that is quote popular is the CSV file 74 as defined by [RFC4180]. 76 The present document shows how to use CDDL to provide a data model 77 for CSV files. 79 1.1. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 83 "OPTIONAL" in this document are to be interpreted as described in 84 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 85 capitals, as shown here. 87 This specification uses terminology from [RFC8610]. 89 2. CSV generic data model 91 The CSV format is defined in [RFC4180]. The generic data model for 92 the data in a CSV file can be described in CDDL as: 94 csv = [?header, *record] 95 header = [+header-field] 96 record = [+field] 97 header-field = text 98 field = text 100 Note that the elements of this data model describe the interpretation 101 of the data after removal of lexical structure such as newlines, 102 commas, escape characters, and quotation marks. 104 For the purposes of a specific application, the data model level 105 structure of each field may be described in a more elaborate way, 106 e.g., as a number. CDDL currently does not have a way to express the 107 transformation from the text string in the CSV field to the number 108 that this text string represents at the application data model level; 109 the usage of anything but "text" for a field therefore MUST be 110 accompanied by an instruction how to perform the translation. As a 111 preferred choice, the JSON representation of the data model item, if 112 it exists, MAY be chosen by that instruction. 114 Since the CSV media type text/csv defaults to us-ascii (see Section 3 115 of [RFC4180]), many uses of CSV will need to specify the media type 116 parameter charset. The media type parameter header MAY be used to 117 indicate the presence or absence of a header line; if it is not 118 given, the grammar MUST NOT be ambiguous about the presence of a 119 header (i.e., it MUST be either mandatory or absent). 121 Note that the ABNF [STD68] in [RFC4180] does not quite handle the 122 case that charset is not us-ascii. For the purposes of the present 123 specification, the ABNF is understood to allow all characters from 124 the charset except %x22 and %x2C in TEXTDATA. For the purposes of 125 the present specification, the ABNF rule CRLF is read as: 127 CRLF = [CR] LF 129 as is hinted in Section 3 of [RFC4180]. 131 3. Examples 133 A simplified CSV form definition of a SID file [I-D.ietf-core-sid] 134 might look like this: 136 ; header = absent 138 SID-File = [meta-record, 139 *dependency-record, 140 *range-record, 141 *item-record] 143 meta-record = ["meta", 144 module-name: text, 145 module-revision: empty / text, 146 sid-file-revision: empty / text, 147 description: empty / text] 149 dependency-record = ["dep", 150 module-name: text, 151 module-revision: text] 153 range-record = ["range", 154 entry-point: uint, 155 size: uint] 157 item-record = ["item", 158 namespace: "module" / "identity" / "feature" / "data", 159 identifier: yang-identifier / schema-node-path 160 ; the above probably should say which namespace 161 ; goes with which identifier 162 sid: uint] 164 yang-identifier = text .abnf ("yang-identifier" .det id-abnf) 165 schema-node-path = text .abnf ("schema-node-path" .det id-abnf) 166 id-abnf = ' 167 schema-node-path = QID *( "/" OQID) 168 yang-identifier = ID 169 QID = ID ":" ID 170 OQID = ID [":" ID] 171 ID = I *C 172 I = "_" / %x41-5a / %x61-7a 173 C = I / %x30-39 / "-" / "." 174 ' 176 empty = "" 178 TODO: show the example in Appendix A of [I-D.ietf-core-sid] 180 4. IANA Considerations 182 This document makes no requests of IANA. 184 5. Security considerations 186 The security considerations of [RFC8610] and [RFC4180] apply. 188 6. References 190 6.1. Normative References 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, 194 DOI 10.17487/RFC2119, March 1997, 195 . 197 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 198 Separated Values (CSV) Files", RFC 4180, 199 DOI 10.17487/RFC4180, October 2005, 200 . 202 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 203 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 204 May 2017, . 206 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 207 Definition Language (CDDL): A Notational Convention to 208 Express Concise Binary Object Representation (CBOR) and 209 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 210 June 2019, . 212 [STD68] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 213 Specifications: ABNF", STD 68, RFC 5234, 214 DOI 10.17487/RFC5234, January 2008, 215 . 217 6.2. Informative References 219 [I-D.ietf-core-sid] 220 Veillette, M., Pelov, A., Petrov, I., Bormann, C., and M. 221 Richardson, "YANG Schema Item iDentifier (YANG SID)", Work 222 in Progress, Internet-Draft, draft-ietf-core-sid-18, 18 223 November 2021, . 226 Acknowledgements 228 Rob Wilton, unknowingly, made me write this specification. I hope it 229 will be useful. 231 Author's Address 233 Carsten Bormann 234 Universität Bremen TZI 235 Postfach 330440 236 D-28359 Bremen 237 Germany 238 Phone: +49-421-218-63921 239 Email: cabo@tzi.org