idnits 2.17.1 draft-bormann-cbor-cddl-freezer-01.txt: 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: ---------------------------------------------------------------------------- No issues found here. 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 (August 10, 2018) is 2084 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-03 == Outdated reference: A later version (-02) exists of draft-handrews-relative-json-pointer-01 Summary: 0 errors (**), 0 flaws (~~), 3 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 Universitaet Bremen TZI 4 Intended status: Informational August 10, 2018 5 Expires: February 11, 2019 7 A feature freezer for the Concise Data Definition Language (CDDL) 8 draft-bormann-cbor-cddl-freezer-01 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 collects nice-to-have features that did not make it into the 16 first RFC for CDDL. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 11, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Cuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Literal syntax . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Computed Literals . . . . . . . . . . . . . . . . . . . . 3 56 3.2. Tag-oriented Literals . . . . . . . . . . . . . . . . . . 3 57 3.3. Regular Expression Literals . . . . . . . . . . . . . . . 3 58 4. Embedded ANBF . . . . . . . . . . . . . . . . . . . . . . . . 3 59 5. Controls . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5.1. Control operator .pcre . . . . . . . . . . . . . . . . . 4 61 5.2. Endianness in .bits . . . . . . . . . . . . . . . . . . . 4 62 5.3. .bitfield control . . . . . . . . . . . . . . . . . . . . 4 63 6. Co-occurrence Constraints . . . . . . . . . . . . . . . . . . 5 64 7. Module superstructure . . . . . . . . . . . . . . . . . . . . 5 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 9. Security considerations . . . . . . . . . . . . . . . . . . . 6 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 10.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 (TO DO: Insert an extended form of the abstract first here, expanding 76 the reference to [I-D.ietf-cbor-cddl].) 78 There is always a danger for a document like this to become a 79 shopping list; the intention is to develop this document further 80 based on real-world experience with the first CDDL standard. 82 2. Cuts 84 Section 3.5.3 of [I-D.ietf-cbor-cddl] alludes to a new language 85 feature, _cuts_, and defines it in a fashion that is rather focused 86 on a single application in the context of maps and generating better 87 diagnostic information about them. 89 The present document is expected to grow a more complete definition 90 of cuts, with the expectation that it will be upwards-compatible to 91 the existing one in [I-D.ietf-cbor-cddl], before this possibly 92 becomes a mainline language feature in a future version of CDDL. 94 3. Literal syntax 96 3.1. Computed Literals 98 CDDL cannot compute. 100 This is a liability in at least two situations: 102 o integers often need to be defined relative to an offset. It might 103 be desirable to be able to write something like: 105 base = 16777216 106 a = base + 1 107 b = base + 2 109 o some string literals (in particular, complex regular expressions) 110 would best be composed from components. This could be done by 111 adding a concatenation operator (maybe even "+" as used for 112 addition above), or by adding string interpolation to the string 113 literal syntax. 115 3.2. Tag-oriented Literals 117 Some CBOR tags often would be most natural to use in a CDDL spec with 118 a literal syntax that is tailored to their semantics instead of their 119 serialization in CBOR. There is currently no way to add such 120 syntaxes, no defined extension point either. 122 3.3. 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 5.1 then raises the question of how to indicate the regular 130 expression flavor. 132 4. Embedded ANBF 134 It would often be desirable to define a text string type by employing 135 ABNF [RFC5234] [RFC7405] embedded into the CDDL specification. 136 Currently, that ABNF would usually need to be translated into a 137 regular expression (if that is even possible). 139 Note that some applications of computed literals for strings could be 140 covered by such a feature (or partially vice versa). 142 5. Controls 144 Controls are the main extension point of the CDDL language. It is 145 relatively painless to add controls to CDDL. Several candidates have 146 been identified that aren't quite ready for adoption, of which one 147 shall be listed here. 149 5.1. Control operator .pcre 151 There are many variants of regular expression languages. 152 Section 3.8.3 of [I-D.ietf-cbor-cddl] defines the .regexp control, 153 which is based on XSD [XSD2] regular expressions. As discussed in 154 that section, the most desirable form of regular expressions in many 155 cases is the family called "Perl-Compatible Regular Expressions" 156 ([PCRE]); however, no formally stable definition of PCRE is available 157 at this time for normatively referencing it from an RFC. 159 The present document defines the control operator .pcre, which is 160 similar to .regexp, but uses PCRE2 regular expressions. More 161 specifically, a ".pcre" control indicates that the text string given 162 as a target needs to match the PCRE regular expression given as a 163 value in the control type, where that regular expression is anchored 164 on both sides. (If anchoring is not desired for a side, ".*" needs 165 to be inserted there.) 167 5.2. Endianness in .bits 169 How useful would it be to have another variant of .bits that counts 170 bits like in RFC box notation? (Or at least per-byte? 32-bit words 171 don't always perfectly mesh with byte strings.) 173 5.3. .bitfield control 175 Provide a way to specify bitfields in byte strings and uints to a 176 higher level of detail than is possible with .bits. Strawman: 178 Field = uint .bitfield Fieldbits 180 Fieldbits = [ 181 flag1: [1, bool], 182 val: [4, Vals], 183 flag2: [1, bool], 184 ] 186 Vals = &(A: 0, B: 1, C: 2, D: 3) 187 Note that the group within the controlling array can have choices, 188 enabling the whole power of a context-free grammar (but not much 189 more). 191 6. Co-occurrence Constraints 193 While there are no co-occurrence constraints in CDDL, many actual use 194 cases can be addressed by using the fact that a group is a grammar: 196 postal = { 197 ( street: text, 198 housenumber: text) // 199 ( pobox: text .regexp "[0-9]+" ) 200 } 202 However, constraints that are not just structural/tree-based but are 203 predicates combining parts of the structure cannot be expressed: 205 session = { 206 timeout: uint, 207 } 209 other-session = { 210 timeout: uint .lt [somehow refer to session.timeout], 211 } 213 As a minimum, this requires the ability to reach over to other parts 214 of the tree in a control. Compare JSON Pointer [RFC6901] and JSON 215 Relative Pointer [I-D.handrews-relative-json-pointer]. More 216 generally, something akin to what Schematron is to Relax-NG may be 217 needed. 219 7. Module superstructure 221 CDDL rules could be packaged as modules and referenced from other 222 modules. There could be some control of namespace pollution, as well 223 as unambiguous referencing ("versioning"). 225 This is probably best achieved by a pragma-like syntax which could be 226 carried in CDDL comments, leaving each module to be valid CDDL (if 227 missing some rule definitions to be imported). 229 8. IANA Considerations 231 This document makes no requests of IANA. 233 9. Security considerations 235 The security considerations of [I-D.ietf-cbor-cddl] apply. 237 10. References 239 10.1. Normative References 241 [I-D.ietf-cbor-cddl] 242 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 243 definition language (CDDL): a notational convention to 244 express CBOR data structures", draft-ietf-cbor-cddl-03 245 (work in progress), July 2018. 247 10.2. Informative References 249 [I-D.handrews-relative-json-pointer] 250 Luff, G. and H. Andrews, "Relative JSON Pointers", draft- 251 handrews-relative-json-pointer-01 (work in progress), 252 January 2018. 254 [PCRE] "Perl-compatible Regular Expressions (revised API: 255 PCRE2)", n.d., . 257 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 258 Specifications: ABNF", STD 68, RFC 5234, 259 DOI 10.17487/RFC5234, January 2008, 260 . 262 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 263 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 264 DOI 10.17487/RFC6901, April 2013, 265 . 267 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 268 RFC 7405, DOI 10.17487/RFC7405, December 2014, 269 . 271 [XSD2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 272 Second Edition", World Wide Web Consortium Recommendation 273 REC-xmlschema-2-20041028, October 2004, 274 . 276 Acknowledgements 278 Many people have asked for CDDL to be completed, soon. These are 279 usually also the people who have brought up observations that led to 280 the proposals discussed here. Sean Leonard has campaigned for a 281 regexp syntax. 283 Author's Address 285 Carsten Bormann 286 Universitaet Bremen TZI 287 Postfach 330440 288 Bremen D-28359 289 Germany 291 Phone: +49-421-218-63921 292 Email: cabo@tzi.org