idnits 2.17.1 draft-bormann-cbor-cddl-freezer-05.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 (22 February 2021) is 1156 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '4' on line 175 == Missing Reference: 'Vals' is mentioned on line 175, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-core-coral-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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 22 February 2021 5 Expires: 26 August 2021 7 A feature freezer for the Concise Data Definition Language (CDDL) 8 draft-bormann-cbor-cddl-freezer-05 10 Abstract 12 In defining the Concise Data Definition Language (CDDL), some 13 features have turned up that would be nice to have. In the interest 14 of completing this specification in a timely manner, the present 15 document was started to collect nice-to-have features that did not 16 make it into the first RFC for CDDL, RFC 8610. 18 It is now time to discuss thawing some of the concepts discussed 19 here. A number of additional proposals have been added. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 26 August 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Base language features . . . . . . . . . . . . . . . . . . . 3 56 2.1. Cuts . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Literal syntax . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Tag-oriented Literals . . . . . . . . . . . . . . . . . . 3 59 3.2. Regular Expression Literals . . . . . . . . . . . . . . . 3 60 4. Controls . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4.1. Control operator .pcre . . . . . . . . . . . . . . . . . 4 62 4.2. Endianness in .bits . . . . . . . . . . . . . . . . . . . 4 63 4.3. .bitfield control . . . . . . . . . . . . . . . . . . . . 4 64 5. Co-occurrence Constraints . . . . . . . . . . . . . . . . . . 5 65 6. Module superstructure . . . . . . . . . . . . . . . . . . . . 5 66 6.1. Namespacing . . . . . . . . . . . . . . . . . . . . . . . 6 67 7. Alternative Representations . . . . . . . . . . . . . . . . . 6 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 9. Security considerations . . . . . . . . . . . . . . . . . . . 6 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 10.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 In defining the Concise Data Definition Language (CDDL), some 79 features have turned up that would be nice to have. In the interest 80 of completing this specification in a timely manner, the present 81 document was started to collect nice-to-have features that did not 82 make it into the first RFC for CDDL [RFC8610]. 84 It is now time to discuss thawing some of the concepts discussed 85 here. A number of additional proposals have been added. 87 There is always a danger for a document like this to become a 88 shopping list; the intention is to develop this document further 89 based on real-world experience with the first CDDL standard. 91 2. Base language features 93 2.1. Cuts 95 Section 3.5.4 of [RFC8610] alludes to a new language feature, _cuts_, 96 and defines it in a fashion that is rather focused on a single 97 application in the context of maps and generating better diagnostic 98 information about them. 100 The present document is expected to grow a more complete definition 101 of cuts, with the expectation that it will be upwards-compatible to 102 the existing one in [RFC8610], before this possibly becomes a 103 mainline language feature in a future version of CDDL. 105 3. Literal syntax 107 3.1. Tag-oriented Literals 109 Some CBOR tags often would be most natural to use in a CDDL spec with 110 a literal syntax that is tailored to their semantics instead of their 111 serialization in CBOR. There is currently no way to add such 112 syntaxes, no defined extension point either. 114 The text form of CoRAL [I-D.ietf-core-coral] defines literals of the 115 form 117 dt'2019-07-21T19:53Z' 119 for datetime items. (Similar advances should then probably be made 120 in diagnostic notation.) 122 3.2. Regular Expression Literals 124 Regular expressions currently are notated as strings in CDDL, with 125 all the string escaping rules applied once. It might be convenient 126 to have a more conventional literal format for regular expressions, 127 possibly also providing a place to add modifiers such as "/i". This 128 might also imply "text .regexp ...", which with the proposal in 129 Section 4.1 then raises the question of how to indicate the regular 130 expression flavor. 132 4. Controls 134 Controls are the main extension point of the CDDL language. It is 135 relatively painless to add controls to CDDL. Several candidates have 136 been identified that aren't quite ready for adoption, of which one 137 shall be listed here. 139 4.1. Control operator .pcre 141 There are many variants of regular expression languages. 142 Section 3.8.3 of [RFC8610] defines the .regexp control, which is 143 based on XSD [XSD2] regular expressions. As discussed in that 144 section, the most desirable form of regular expressions in many cases 145 is the family called "Perl-Compatible Regular Expressions" ([PCRE]); 146 however, no formally stable definition of PCRE is available at this 147 time for normatively referencing it from an RFC. 149 The present document defines the control operator .pcre, which is 150 similar to .regexp, but uses PCRE2 regular expressions. More 151 specifically, a ".pcre" control indicates that the text string given 152 as a target needs to match the PCRE regular expression given as a 153 value in the control type, where that regular expression is anchored 154 on both sides. (If anchoring is not desired for a side, ".*" needs 155 to be inserted there.) 157 Similarly, ".es2018re" could be defined for ECMAscript 2018 regular 158 expressions with anchors added. 160 4.2. Endianness in .bits 162 How useful would it be to have another variant of .bits that counts 163 bits like in RFC box notation? (Or at least per-byte? 32-bit words 164 don't always perfectly mesh with byte strings.) 166 4.3. .bitfield control 168 Provide a way to specify bitfields in byte strings and uints to a 169 higher level of detail than is possible with .bits. Strawman: 171 Field = uint .bitfield Fieldbits 173 Fieldbits = [ 174 flag1: [1, bool], 175 val: [4, Vals], 176 flag2: [1, bool], 177 ] 179 Vals = &(A: 0, B: 1, C: 2, D: 3) 181 Note that the group within the controlling array can have choices, 182 enabling the whole power of a context-free grammar (but not much 183 more). 185 5. Co-occurrence Constraints 187 While there are no co-occurrence constraints in CDDL, many actual use 188 cases can be addressed by using the fact that a group is a grammar: 190 postal = { 191 ( street: text, 192 housenumber: text) // 193 ( pobox: text .regexp "[0-9]+" ) 194 } 196 However, constraints that are not just structural/tree-based but are 197 predicates combining parts of the structure cannot be expressed: 199 session = { 200 timeout: uint, 201 } 203 other-session = { 204 timeout: uint .lt [somehow refer to session.timeout], 205 } 207 As a minimum, this requires the ability to reach over to other parts 208 of the tree in a control. Compare JSON Pointer [RFC6901] and JSON 209 Relative Pointer [I-D.handrews-relative-json-pointer]. Stefan 210 Goessner's jsonpath is a JSON variant of XPath that has not been 211 formally standardized [jsonpath]. 213 More generally, something akin to what Schematron is to Relax-NG may 214 be needed. 216 6. Module superstructure 218 CDDL rules could be packaged as modules and referenced from other 219 modules. There could be some control of namespace pollution, as well 220 as unambiguous referencing ("versioning"). 222 This is probably best achieved by a pragma-like syntax which could be 223 carried in CDDL comments, leaving each module to be valid CDDL (if 224 missing some rule definitions to be imported). 226 6.1. Namespacing 228 A convention for mapping CDDL-internal names to external ones could 229 be developed, possibly steered by some pragma-like constructs. 230 External names would likely be URI-based, with some conventions as 231 they are used in RDF or Curies. Internal names might look similar to 232 XML QNames. Note that the identifier character set for CDDL 233 deliberately includes $ and @, which could be used in such a 234 convention. 236 7. Alternative Representations 238 For CDDL, alternative representations e.g. in JSON (and thus in YAML) 239 could be defined, similar to the way YANG defines an XML-based 240 serialization called YIN in Section 11 of [RFC6020]. One proposal 241 for such a syntax is provided by the "cddlc" tool [cddlc]; this could 242 be written up and agreed upon. 244 cddlj = ["cddl", +rule] 245 rule = ["=" / "/=" / "//=", namep, type] 246 namep = ["name", id] / ["gen", id, +id] 247 id = text .regexp "[A-Za-z@_$](([-.])*[A-Za-z0-9@_$])*" 248 op = ".." / "..." / 249 text .regexp "\\.[A-Za-z@_$](([-.])*[A-Za-z0-9@_$])*" 250 namea = ["name", id] / ["gen", id, +type] 251 type = value / namea / ["op", op, type, type] / 252 ["map", group] / ["ary", group] / ["tcho", 2*type] / 253 ["unwrap", namea] / ["enum", group / namea] / 254 ["prim", ?(0..7, ?uint)] 255 group = ["mem", null/type, type] / 256 ["rep", uint, uint/false, group] / 257 ["seq", 2*group] / ["gcho", 2*group] 258 value = ["number"/"text"/"bytes", text] 260 8. IANA Considerations 262 This document makes no requests of IANA. 264 9. Security considerations 266 The security considerations of [RFC8610] apply. 268 10. References 270 10.1. Normative References 272 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 273 Definition Language (CDDL): A Notational Convention to 274 Express Concise Binary Object Representation (CBOR) and 275 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 276 June 2019, . 278 10.2. Informative References 280 [cddlc] "CDDL conversion utilities", n.d., 281 . 283 [I-D.handrews-relative-json-pointer] 284 Luff, G. and H. Andrews, "Relative JSON Pointers", Work in 285 Progress, Internet-Draft, draft-handrews-relative-json- 286 pointer-02, 18 September 2019, 287 . 290 [I-D.ietf-core-coral] 291 Hartke, K., "The Constrained RESTful Application Language 292 (CoRAL)", Work in Progress, Internet-Draft, draft-ietf- 293 core-coral-03, 9 March 2020, 294 . 297 [jsonpath] "jsonpath online evaluator", n.d., . 299 [PCRE] "Perl-compatible Regular Expressions (revised API: 300 PCRE2)", n.d., . 302 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 303 the Network Configuration Protocol (NETCONF)", RFC 6020, 304 DOI 10.17487/RFC6020, October 2010, 305 . 307 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 308 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 309 DOI 10.17487/RFC6901, April 2013, 310 . 312 [XSD2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 313 Second Edition", World Wide Web Consortium Recommendation 314 REC-xmlschema-2-20041028, 28 October 2004, 315 . 317 Acknowledgements 319 Many people have asked for CDDL to be completed, soon. These are 320 usually also the people who have brought up observations that led to 321 the proposals discussed here. Sean Leonard has campaigned for a 322 regexp literal syntax. 324 Author's Address 326 Carsten Bormann 327 Universität Bremen TZI 328 Postfach 330440 329 D-28359 Bremen 330 Germany 332 Phone: +49-421-218-63921 333 Email: cabo@tzi.org