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