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