idnits 2.17.1 draft-bormann-cbor-cddl-freezer-09.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 6 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 (26 December 2021) is 851 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Duplicate reference: RFC8610, mentioned in 'Err6526', was also mentioned in 'RFC8610'. -- Duplicate reference: RFC8610, mentioned in 'Err6527', was also mentioned in 'Err6526'. -- Duplicate reference: RFC8610, mentioned in 'Err6543', was also mentioned in 'Err6527'. == Outdated reference: A later version (-02) exists of draft-bormann-cbor-edn-literals-00 == Outdated reference: A later version (-04) exists of draft-bormann-jsonpath-iregexp-01 == Outdated reference: A later version (-06) exists of draft-ietf-core-coral-04 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 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 26 December 2021 5 Expires: 29 June 2022 7 A feature freezer for the Concise Data Definition Language (CDDL) 8 draft-bormann-cbor-cddl-freezer-09 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, or the specifications 17 exercising its extension points, such as RFC 9165. 19 It is now time to discuss thawing some of the concepts discussed 20 here. A number of additional proposals have been added. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 29 June 2022. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Base language features . . . . . . . . . . . . . . . . . . . 3 57 2.1. Cuts . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Literal syntax . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Tag-oriented Literals . . . . . . . . . . . . . . . . . . 3 60 3.2. Regular Expression Literals . . . . . . . . . . . . . . . 4 61 3.3. Clarifications . . . . . . . . . . . . . . . . . . . . . 4 62 3.3.1. Err6527 . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.3.2. Err6543 . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Controls . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Control operator .pcre . . . . . . . . . . . . . . . . . 6 66 4.2. Endianness in .bits . . . . . . . . . . . . . . . . . . . 6 67 4.3. .bitfield control . . . . . . . . . . . . . . . . . . . . 7 68 5. Co-occurrence Constraints . . . . . . . . . . . . . . . . . . 7 69 6. Module superstructure . . . . . . . . . . . . . . . . . . . . 8 70 6.1. Namespacing . . . . . . . . . . . . . . . . . . . . . . . 8 71 6.2. Cross-universe references . . . . . . . . . . . . . . . . 8 72 6.2.1. IANA references . . . . . . . . . . . . . . . . . . . 8 73 6.3. Potential examples . . . . . . . . . . . . . . . . . . . 9 74 6.3.1. How name spaces might look like . . . . . . . . . . . 9 75 6.3.2. Explicitly interacting with namespaces . . . . . . . 9 76 6.3.3. Document references . . . . . . . . . . . . . . . . . 10 77 6.3.4. Add retroactive exporting to RFCs . . . . . . . . . . 10 78 6.3.5. Operations . . . . . . . . . . . . . . . . . . . . . 10 79 6.3.6. To be discussed . . . . . . . . . . . . . . . . . . . 11 80 7. Alternative Representations . . . . . . . . . . . . . . . . . 11 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 9. Security considerations . . . . . . . . . . . . . . . . . . . 11 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . 12 86 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 In defining the Concise Data Definition Language (CDDL), some 92 features have turned up that would be nice to have. In the interest 93 of completing this specification in a timely manner, the present 94 document was started to collect nice-to-have features that did not 95 make it into the first RFC for CDDL [RFC8610], or the specifications 96 exercising its extension points, such as [RFC9165]. 98 It is now time to discuss thawing some of the concepts discussed 99 here. A number of additional proposals have been added. 101 There is always a danger for a document like this to become a 102 shopping list; the intention is to develop this document further 103 based on the rapidly growing real-world experience with the first 104 CDDL standard. 106 2. Base language features 108 2.1. Cuts 110 Section 3.5.4 of [RFC8610] alludes to a new language feature, _cuts_, 111 and defines it in a fashion that is rather focused on a single 112 application in the context of maps and generating better diagnostic 113 information about them. 115 The present document is expected to grow a more complete definition 116 of cuts, with the expectation that it will be upwards-compatible to 117 the existing one in [RFC8610], before this possibly becomes a 118 mainline language feature in a future version of CDDL. 120 3. Literal syntax 122 3.1. Tag-oriented Literals 124 Some CBOR tags often would be most natural to use in a CDDL spec with 125 a literal syntax that is tailored to their semantics instead of their 126 serialization in CBOR. There is currently no way to add such 127 syntaxes, no defined extension point either. 129 Based on the CoRAL work [I-D.ietf-core-coral], the proposal 130 "Application-Oriented Literals in CBOR Extended Diagnostic Notation" 131 [I-D.bormann-cbor-edn-literals] defines application-oriented 132 literals, e.g., of the form 134 dt'2019-07-21T19:53Z' 136 for datetime items. With additional considerations for unambiguous 137 syntax, a similar literal form could be included in CDDL. 139 3.2. Regular Expression Literals 141 Regular expressions currently are notated as strings in CDDL, with 142 all the string escaping rules applied once. It might be convenient 143 to have a more conventional literal format for regular expressions, 144 possibly also providing a place to add modifiers such as /i. This 145 might also imply text .regexp ..., which with the proposal in 146 Section 4.1 then raises the question of how to indicate the regular 147 expression flavor. 149 3.3. Clarifications 151 A number of errata reports have been made around some details of text 152 string and byte string literal syntax: [Err6527] and [Err6543]. 153 These need to be addressed by re-examining the details of these 154 literal syntaxes. Also, [Err6526] needs to be applied. 156 3.3.1. Err6527 158 The ABNF used in [RFC8610] for the content of text string literals is 159 rather permissive: 161 text = %x22 *SCHAR %x22 162 SCHAR = %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC 163 SESC = "\" (%x20-7E / %x80-10FFFD) 165 This allows almost any non-C0 character to be escaped by a backslash, 166 but critically misses out on the \uXXXX and \uHHHH\uLLLL forms that 167 JSON allows to specify characters in hex. Both can be solved by 168 updating the SESC production to: 170 SESC = "\" ( %x22 / "/" / "\" / ; \" \/ \\ 171 %x62 / %x66 / %x6E / %x72 / %x74 / ; \b \f \n \r \t 172 (%x75 hexchar) ) ; \u 173 hexchar = non-surrogate / (high-surrogate "\" %x75 low-surrogate) 174 non-surrogate = ((DIGIT / "A"/"B"/"C" / "E"/"F") 3HEXDIG) / 175 ("D" %x30-37 2HEXDIG ) 176 high-surrogate = "D" ("8"/"9"/"A"/"B") 2HEXDIG 177 low-surrogate = "D" ("C"/"D"/"E"/"F") 2HEXDIG 179 Now that SESC is more restrictively formulated, this also requires an 180 update to the BCHAR production used in the ABNF syntax for byte 181 string literals: 183 bytes = [bsqual] %x27 *BCHAR %x27 184 BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF 185 bsqual = "h" / "b64" 186 The updated version explicit allows \', which is no longer allowed in 187 the updated SESC: 189 BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / "\'" / CRLF 191 3.3.2. Err6543 193 The ABNF used in [RFC8610] for the content of byte string literals 194 lumps together byte strings notated as text with byte strings notated 195 in base16 (hex) or base64 (but see also updated BCHAR production 196 above): 198 bytes = [bsqual] %x27 *BCHAR %x27 199 BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF 201 Errata report 6543 proposes to handle the two cases in separate 202 productions (where, with an updated SESC, BCHAR obviously needs to be 203 updated as above): 205 bytes = %x27 *BCHAR %x27 206 / bsqual %x27 *QCHAR %x27 207 BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF 208 QCHAR = DIGIT / ALPHA / "+" / "/" / "-" / "_" / "=" / WS 210 This potentially causes a subtle change, which is hidden in the WS 211 production: 213 WS = SP / NL 214 SP = %x20 215 NL = COMMENT / CRLF 216 COMMENT = ";" *PCHAR CRLF 217 PCHAR = %x20-7E / %x80-10FFFD 218 CRLF = %x0A / %x0D.0A 220 This allows any non-C0 character in a comment, so this fragment 221 becomes possible: 223 foo = h' 224 43424F52 ; 'CBOR' 225 0A ; LF, but don't use CR! 226 ' 228 The current text is not unambiguously saying whether the three 229 apostrophes need to be escaped with a \ or not, as in: 231 foo = h' 232 43424F52 ; \'CBOR\' 233 0A ; LF, but don\'t use CR! 234 ' 236 ... which would be supported by the existing ABNF in [RFC8610]. 238 4. Controls 240 Controls are the main extension point of the CDDL language. It is 241 relatively painless to add controls to CDDL; this mechanism has been 242 exercised in [RFC9090] for SDNV [RFC6256] and ASN.1 OID related byte 243 strings, and in [RFC9165] for more generally applicable controls, 244 including an interface to ABNF [RFC5234] [RFC7405]. Several further 245 candidates have been identified that aren't quite ready for adoption, 246 of which a few shall be listed here. 248 4.1. Control operator .pcre 250 There are many variants of regular expression languages. 251 Section 3.8.3 of [RFC8610] defines the .regexp control, which is 252 based on XSD [XSD2] regular expressions. As discussed in that 253 section, the most desirable form of regular expressions in many cases 254 is the family called "Perl-Compatible Regular Expressions" ([PCRE]); 255 however, no formally stable definition of PCRE is available at this 256 time for normatively referencing it from an RFC. 258 The present document defines the control operator .pcre, which is 259 similar to .regexp, but uses PCRE2 regular expressions. More 260 specifically, a .pcre control indicates that the text string given as 261 a target needs to match the PCRE regular expression given as a value 262 in the control type, where that regular expression is anchored on 263 both sides. (If anchoring is not desired for a side, .* needs to be 264 inserted there.) 266 Similarly, .es2018re could be defined for ECMAscript 2018 regular 267 expressions with anchors added. 269 See also [I-D.draft-bormann-jsonpath-iregexp], which could be 270 specifically called out via .iregexp (even though .regexp as per 271 Section 3.8.3 of [RFC8610] would also have the same semantics, except 272 for a wider range of regexps). 274 4.2. Endianness in .bits 276 How useful would it be to have another variant of .bits that counts 277 bits like in RFC box notation? (Or at least per-byte? 32-bit words 278 don't always perfectly mesh with byte strings.) 280 4.3. .bitfield control 282 Provide a way to specify bitfields in byte strings and uints to a 283 higher level of detail than is possible with .bits. Strawman: 285 Field = uint .bitfield Fieldbits 287 Fieldbits = [ 288 flag1: [1, bool], 289 val: [4, Vals], 290 flag2: [1, bool], 291 ] 293 Vals = &(A: 0, B: 1, C: 2, D: 3) 295 Note that the group within the controlling array can have choices, 296 enabling the whole power of a context-free grammar (but not much 297 more). 299 5. Co-occurrence Constraints 301 While there are no co-occurrence constraints in CDDL, many actual use 302 cases can be addressed by using the fact that a group is a grammar: 304 postal = { 305 ( street: text, 306 housenumber: text) // 307 ( pobox: text .regexp "[0-9]+" ) 308 } 310 However, constraints that are not just structural/tree-based but are 311 predicates combining parts of the structure cannot be expressed: 313 session = { 314 timeout: uint, 315 } 317 other-session = { 318 timeout: uint .lt [somehow refer to session.timeout], 319 } 321 As a minimum, this requires the ability to reach over to other parts 322 of the tree in a control. Compare JSON Pointer [RFC6901] and JSON 323 Relative Pointer [I-D.handrews-relative-json-pointer]. Stefan 324 Goessner's jsonpath is a JSON variant of XPath that has not been 325 formally standardized yet [jsonpath]. 327 More generally, something akin to what Schematron is to Relax-NG may 328 be needed. 330 6. Module superstructure 332 CDDL rules could be packaged as modules and referenced from other 333 modules. There could be some control of namespace pollution, as well 334 as unambiguous referencing ("versioning"). 336 This is probably best achieved by a pragma-like syntax which could be 337 carried in CDDL comments, leaving each module to be valid CDDL (if 338 missing some rule definitions to be imported). 340 6.1. Namespacing 342 A convention for mapping CDDL-internal names to external ones could 343 be developed, possibly steered by some pragma-like constructs. 344 External names would likely be URI-based, with some conventions as 345 they are used in RDF or Curies. Internal names might look similar to 346 XML QNames. Note that the identifier character set for CDDL 347 deliberately includes $ and @, which could be used in such a 348 convention. 350 6.2. Cross-universe references 352 Often, a CDDL specfication needs to import from specifications in a 353 different language or platform. 355 6.2.1. IANA references 357 In many cases, CDDL specifications make use of values that are 358 specified in IANA registries. The .iana control operator can be used 359 to reference such a set of values. 361 The reference needs to be able to point to a draft, the registry of 362 which has not been established yet, as well as to an established IANA 363 registry. 365 An example of such a usage might be: 367 cose-algorithm = int .iana ["cose", "algorithms", "value"] 369 Unfortunately, the vocabulary employed in IANA registries has not 370 been designed for machine references. In this case, the potential 371 values would come from applying the XPath expression 373 //iana:registry[@id='algorithms']/iana:record/iana:value 374 to https://www.iana.org/assignments/cose/cose.xml, plus some 375 filtering on the records returned that only leaves actual 376 allocations. Additional functionality may be needed for filtering 377 with respect to other columns of the registry record, e.g., 378 in the case of this example. 380 6.3. Potential examples 382 This section shows some examples that illustrate potential syntaxes 383 and semantics to be examined. 385 One of the potential objectives here is to keep documents that make 386 use of this extension generally valid as CDDL 1.0 documents, albeit 387 possibly with a need to add further CDDL 1.0 rules to obtain a 388 complete specification. 390 6.3.1. How name spaces might look like 392 Implicit namespacing might be provided by using a document reference 393 as a namespace tag: 395 RFC8610.int ⬌ int 396 RFC9090.oid ⬌ oid 398 Note that this example establishes a namespace for the prelude 399 (RFC8610.int); maybe it is worth to do that more explicitly. 401 6.3.2. Explicitly interacting with namespaces 403 New syntax for explicitly interacting with namespaces might be but 404 into RFC 8610 comments, with a specific prefix (and possibly starting 405 left-aligned). Prefixes proposed include ;;< and ;#; the below will 406 use ;# even though that probably could pose too many conflicts; it 407 also might be too inconspicuous. 409 ;# export oid, roid, pen as RFC9090 410 oid = #6.111(bstr) 411 roid = #6.110(bstr) 412 pen = #6.112(bstr) 414 Besides an implicit import such as 416 ; unadorned, just import? 417 a = [RFC9090.oid] 419 there also could be an explicit import syntax: 421 ;# import oid from RFC9090 422 a = [oid] 424 Such an explicit syntax might also be able to provide additional 425 parameters such as in the IANA examples above. 427 6.3.3. Document references 429 A convention for establishing RFC references might be easy to 430 establish, but at least Internet-Draft references and IANA registry 431 references should also supported. It is probably worth to add some 432 indirection here, as names of Internet-Drafts might change (including 433 by becoming RFCs). 435 6.3.4. Add retroactive exporting to RFCs 437 Existing RFCs with CDDL in them could presume an export ...all... as 438 RFCnnnn (Possibly also per-section exports as in RFC8610.D for the 439 prelude?) 441 Namespace tags for those exports need to be reserved so they cannot 442 be occupied by explicit exporting. 444 New specifications (including RFCs) can "include"/"import" from these 445 namespaces, and maybe "export" their own rules in a more considered 446 way. 448 6.3.5. Operations 450 * "export": 452 1. prefix: add a namespace name to "local" rulenames: 454 `oid` ➔ `RFC9090.oid` 456 2. make that namespace available to other specs 458 * "import": include (prefixed) definitions from a source 460 1. use as is: RFC9090.oid 462 2. unprefix: oid 464 Example: prelude processing -- include+unprefix from Appendix D of 465 RFC8610. 467 * "include": find files, turn into namespaces to import from 469 6.3.6. To be discussed 471 How to find the document that exports a namespace (IANA? Use by 472 other SDOs? Internal use in an org? How to transition between these 473 states?) 475 Multiple documents exporting into one namespace (_Immutable_ RFC9090 476 namespace vs. "OID"-namespace? Who manages _mutable_ namespaces?) 478 Updates, revisions, versions, semver: 480 ;# insert OID ~> 2.2 ; twiddle-wakka: this version or higher 482 7. Alternative Representations 484 For CDDL, alternative representations e.g. in JSON (and thus in YAML) 485 could be defined, similar to the way YANG defines an XML-based 486 serialization called YIN in Section 11 of [RFC6020]. One proposal 487 for such a syntax is provided by the cddlc tool [cddlc], which is 488 reproduced below. This could be written up in more detail and agreed 489 upon. 491 cddlj = ["cddl", +rule] 492 rule = ["=" / "/=" / "//=", namep, type] 493 namep = ["name", id] / ["gen", id, +id] 494 id = text .regexp "[A-Za-z@_$](([-.])*[A-Za-z0-9@_$])*" 495 op = ".." / "..." / 496 text .regexp "\\.[A-Za-z@_$](([-.])*[A-Za-z0-9@_$])*" 497 namea = ["name", id] / ["gen", id, +type] 498 type = value / namea / ["op", op, type, type] / 499 ["map", group] / ["ary", group] / ["tcho", 2*type] / 500 ["unwrap", namea] / ["enum", group / namea] / 501 ["prim", ?(0..7, ?uint)] 502 group = ["mem", null/type, type] / 503 ["rep", uint, uint/false, group] / 504 ["seq", 2*group] / ["gcho", 2*group] 505 value = ["number"/"text"/"bytes", text] 507 8. IANA Considerations 509 This document makes no requests of IANA. 511 9. Security considerations 513 The security considerations of [RFC8610] apply. 515 10. References 516 10.1. Normative References 518 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 519 Definition Language (CDDL): A Notational Convention to 520 Express Concise Binary Object Representation (CBOR) and 521 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 522 June 2019, . 524 [RFC9165] Bormann, C., "Additional Control Operators for the Concise 525 Data Definition Language (CDDL)", RFC 9165, 526 DOI 10.17487/RFC9165, December 2021, 527 . 529 10.2. Informative References 531 [cddlc] "CDDL conversion utilities", n.d., 532 . 534 [Err6526] "Errata Report 6526", RFC 8610, 535 . 537 [Err6527] "Errata Report 6527", RFC 8610, 538 . 540 [Err6543] "Errata Report 6543", RFC 8610, 541 . 543 [I-D.bormann-cbor-edn-literals] 544 Bormann, C., "Application-Oriented Literals in CBOR 545 Extended Diagnostic Notation", Work in Progress, Internet- 546 Draft, draft-bormann-cbor-edn-literals-00, 6 October 2021, 547 . 550 [I-D.draft-bormann-jsonpath-iregexp] 551 Bormann, C., "I-Regexp: An Interoperable Regexp Format", 552 Work in Progress, Internet-Draft, draft-bormann-jsonpath- 553 iregexp-01, 13 November 2021, 554 . 557 [I-D.handrews-relative-json-pointer] 558 Luff, G. and H. Andrews, "Relative JSON Pointers", Work in 559 Progress, Internet-Draft, draft-handrews-relative-json- 560 pointer-02, 18 September 2019, 561 . 564 [I-D.ietf-core-coral] 565 Amsüss, C. and T. Fossati, "The Constrained RESTful 566 Application Language (CoRAL)", Work in Progress, Internet- 567 Draft, draft-ietf-core-coral-04, 25 October 2021, 568 . 571 [jsonpath] "jsonpath online evaluator", n.d., . 573 [PCRE] "Perl-compatible Regular Expressions (revised API: 574 PCRE2)", n.d., . 576 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 577 Specifications: ABNF", STD 68, RFC 5234, 578 DOI 10.17487/RFC5234, January 2008, 579 . 581 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 582 the Network Configuration Protocol (NETCONF)", RFC 6020, 583 DOI 10.17487/RFC6020, October 2010, 584 . 586 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 587 Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 588 2011, . 590 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 591 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 592 DOI 10.17487/RFC6901, April 2013, 593 . 595 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 596 RFC 7405, DOI 10.17487/RFC7405, December 2014, 597 . 599 [RFC9090] Bormann, C., "Concise Binary Object Representation (CBOR) 600 Tags for Object Identifiers", RFC 9090, 601 DOI 10.17487/RFC9090, July 2021, 602 . 604 [XSD2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 605 Second Edition", World Wide Web Consortium Recommendation 606 REC-xmlschema-2-20041028, 28 October 2004, 607 . 609 Acknowledgements 611 Many people have asked for CDDL to be completed, soon. These are 612 usually also the people who have brought up observations that led to 613 the proposals discussed here. Sean Leonard has campaigned for a 614 regexp literal syntax. 616 Author's Address 618 Carsten Bormann 619 Universität Bremen TZI 620 Postfach 330440 621 D-28359 Bremen 622 Germany 624 Phone: +49-421-218-63921 625 Email: cabo@tzi.org