idnits 2.17.1 draft-bormann-cbor-cddl-freezer-00.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 (January 27, 2018) is 2281 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-00 Summary: 0 errors (**), 0 flaws (~~), 2 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 January 27, 2018 5 Expires: July 31, 2018 7 A feature freezer for the Concise Data Definition Language (CDDL) 8 draft-bormann-cbor-cddl-freezer-00 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 July 31, 2018. 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 . . . . . . . . . . . . . . . . . . . . . . . 2 55 3.1. Computed Literals . . . . . . . . . . . . . . . . . . . . 2 56 3.2. Tag-oriented Literals . . . . . . . . . . . . . . . . . . 3 57 3.3. Regular Expression Literals . . . . . . . . . . . . . . . 3 58 4. Embedded ANBF . . . . . . . . . . . . . . . . . . . . . . . . 3 59 5. Controls . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 5.1. Control operator .pcre . . . . . . . . . . . . . . . . . 4 61 6. Module superstructure . . . . . . . . . . . . . . . . . . . . 4 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 8. Security considerations . . . . . . . . . . . . . . . . . . . 4 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 66 9.2. Informative References . . . . . . . . . . . . . . . . . 5 67 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 (TO DO: Insert an extended form of the abstract first here, expanding 73 the reference to [I-D.ietf-cbor-cddl].) 75 There is always a danger for a document like this to become a 76 shopping list; the intention is to develop this document further 77 based on real-world experience with the first CDDL standard. 79 2. Cuts 81 Section 3.5.3 of [I-D.ietf-cbor-cddl] alludes to a new language 82 feature, _cuts_, and defines it in a fashion that is rather focused 83 on a single application in the context of maps and generating better 84 diagnostic information about them. 86 The present document is expected to grow a more complete definition 87 of cuts, with the expectation that it will be upwards-compatible to 88 the existing one in [I-D.ietf-cbor-cddl], before this possibly 89 becomes a mainline language feature in a future version of CDDL. 91 3. Literal syntax 93 3.1. Computed Literals 95 CDDL cannot compute. 97 This is a liability in at least two situations: 99 o integers often need to be defined relative to an offset. It might 100 be desirable to be able to write something like: 102 base = 16777216 103 a = base + 1 104 b = base + 2 106 o some string literals (in particular, complex regular expressions) 107 would best be composed from components. This could be done by 108 adding a concatenation operator (maybe even "+" as used for 109 addition above), or by adding string interpolation to the string 110 literal syntax. 112 3.2. Tag-oriented Literals 114 Some CBOR tags often would be most natural to use in a CDDL spec with 115 a literal syntax that is tailored to their semantics instead of their 116 serialization in CBOR. There is currently no way to add such 117 syntaxes, no defined extension point either. 119 3.3. Regular Expression Literals 121 Regular expressions currently are notated as strings in CDDL, with 122 all the string escaping rules applied once. It might be convenient 123 to have a more conventional literal format for regular expressions, 124 possibly also providing a place to add modifiers such as "/i". This 125 might also imply "text .regexp ...", which with the proposal in 126 Section 5.1 then raises the question of how to indicate the regular 127 expression flavor. 129 4. Embedded ANBF 131 It would often be desirable to define a text string type by employing 132 ABNF [RFC5234] [RFC7405] embedded into the CDDL specification. 133 Currently, that ABNF would usually need to be translated into a 134 regular expression (if that is even possible). 136 Note that some applications of computed literals for strings could be 137 covered by such a feature (or partially vice versa). 139 5. Controls 141 Controls are the main extension point of the CDDL language. It is 142 relatively painless to add controls to CDDL. Several candidates have 143 been identified that aren't quite ready for adoption, of which one 144 shall be listed here. 146 5.1. Control operator .pcre 148 There are many variants of regular expression languages. 149 Section 3.8.3 of [I-D.ietf-cbor-cddl] defines the .regexp control, 150 which is based on XSD [XSD2] regular expressions. As discussed in 151 that section, the most desirable form of regular expressions in many 152 cases is the family called "Perl-Compatible Regular Expressions" 153 ([PCRE]); however, no formally stable definition of PCRE is available 154 at this time for normatively referencing it from an RFC. 156 The present document defines the control operator .pcre, which is 157 similar to .regexp, but uses PCRE2 regular expressions. More 158 specifically, a ".pcre" control indicates that the text string given 159 as a target needs to match the PCRE regular expression given as a 160 value in the control type, where that regular expression is anchored 161 on both sides. (If anchoring is not desired for a side, ".*" needs 162 to be inserted there.) 164 6. Module superstructure 166 CDDL rules could be packaged as modules and referenced from other 167 modules. There could be some control of namespace pollution, as well 168 as unambiguous referencing ("versioning"). 170 This is probably best achieved by a pragma-like syntax which could be 171 carried in CDDL comments, leaving each module to be valid CDDL (if 172 missing some rule definitions to be imported). 174 7. IANA Considerations 176 This document makes no requests of IANA. 178 8. Security considerations 180 The security considerations of [I-D.ietf-cbor-cddl] apply. 182 9. References 184 9.1. Normative References 186 [I-D.ietf-cbor-cddl] 187 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 188 definition language (CDDL): a notational convention to 189 express CBOR data structures", draft-ietf-cbor-cddl-00 190 (work in progress), July 2017. 192 9.2. Informative References 194 [PCRE] "Perl-compatible Regular Expressions (revised API: 195 PCRE2)", n.d., . 197 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 198 Specifications: ABNF", STD 68, RFC 5234, 199 DOI 10.17487/RFC5234, January 2008, 200 . 202 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 203 RFC 7405, DOI 10.17487/RFC7405, December 2014, 204 . 206 [XSD2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 207 Second Edition", World Wide Web Consortium Recommendation 208 REC-xmlschema-2-20041028, October 2004, 209 . 211 Acknowledgements 213 Many people have asked for CDDL to be completed, soon. These are 214 usually also the people who have brought up observations that led to 215 the proposals discussed here. Sean Leonard has campaigned for a 216 regexp syntax. 218 Author's Address 220 Carsten Bormann 221 Universitaet Bremen TZI 222 Postfach 330440 223 Bremen D-28359 224 Germany 226 Phone: +49-421-218-63921 227 Email: cabo@tzi.org