< draft-bormann-cbor-cddl-freezer-00.txt		draft-bormann-cbor-cddl-freezer-01.txt >
	Network Working Group C. Bormann		Network Working Group C. Bormann
	Internet-Draft Universitaet Bremen TZI		Internet-Draft Universitaet Bremen TZI
	Intended status: Informational January 27, 2018		Intended status: Informational August 10, 2018
	Expires: July 31, 2018		Expires: February 11, 2019
	A feature freezer for the Concise Data Definition Language (CDDL)		A feature freezer for the Concise Data Definition Language (CDDL)
	draft-bormann-cbor-cddl-freezer-00		draft-bormann-cbor-cddl-freezer-01
	Abstract		Abstract
	In defining the Concise Data Definition Language (CDDL), some		In defining the Concise Data Definition Language (CDDL), some
	features have turned up that would be nice to have. In the interest		features have turned up that would be nice to have. In the interest
	of completing this specification in a timely manner, the present		of completing this specification in a timely manner, the present
	document collects nice-to-have features that did not make it into the		document collects nice-to-have features that did not make it into the
	first RFC for CDDL.		first RFC for CDDL.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 31, 2018.		This Internet-Draft will expire on February 11, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Cuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Cuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. Literal syntax . . . . . . . . . . . . . . . . . . . . . . . 2		3. Literal syntax . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Computed Literals . . . . . . . . . . . . . . . . . . . . 2		3.1. Computed Literals . . . . . . . . . . . . . . . . . . . . 3
	3.2. Tag-oriented Literals . . . . . . . . . . . . . . . . . . 3		3.2. Tag-oriented Literals . . . . . . . . . . . . . . . . . . 3
	3.3. Regular Expression Literals . . . . . . . . . . . . . . . 3		3.3. Regular Expression Literals . . . . . . . . . . . . . . . 3
	4. Embedded ANBF . . . . . . . . . . . . . . . . . . . . . . . . 3		4. Embedded ANBF . . . . . . . . . . . . . . . . . . . . . . . . 3
	5. Controls . . . . . . . . . . . . . . . . . . . . . . . . . . 3		5. Controls . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5.1. Control operator .pcre . . . . . . . . . . . . . . . . . 4		5.1. Control operator .pcre . . . . . . . . . . . . . . . . . 4
	6. Module superstructure . . . . . . . . . . . . . . . . . . . . 4		5.2. Endianness in .bits . . . . . . . . . . . . . . . . . . . 4
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		5.3. .bitfield control . . . . . . . . . . . . . . . . . . . . 4
	8. Security considerations . . . . . . . . . . . . . . . . . . . 4		6. Co-occurrence Constraints . . . . . . . . . . . . . . . . . . 5
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4		7. Module superstructure . . . . . . . . . . . . . . . . . . . . 5
	9.1. Normative References . . . . . . . . . . . . . . . . . . 4		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	9.2. Informative References . . . . . . . . . . . . . . . . . 5		9. Security considerations . . . . . . . . . . . . . . . . . . . 6
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5		10.1. Normative References . . . . . . . . . . . . . . . . . . 6
			10.2. Informative References . . . . . . . . . . . . . . . . . 6
			Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	(TO DO: Insert an extended form of the abstract first here, expanding		(TO DO: Insert an extended form of the abstract first here, expanding
	the reference to [I-D.ietf-cbor-cddl].)		the reference to [I-D.ietf-cbor-cddl].)
	There is always a danger for a document like this to become a		There is always a danger for a document like this to become a
	shopping list; the intention is to develop this document further		shopping list; the intention is to develop this document further
	based on real-world experience with the first CDDL standard.		based on real-world experience with the first CDDL standard.
	skipping to change at page 4, line 23 ¶		skipping to change at page 4, line 30 ¶
	at this time for normatively referencing it from an RFC.		at this time for normatively referencing it from an RFC.
	The present document defines the control operator .pcre, which is		The present document defines the control operator .pcre, which is
	similar to .regexp, but uses PCRE2 regular expressions. More		similar to .regexp, but uses PCRE2 regular expressions. More
	specifically, a ".pcre" control indicates that the text string given		specifically, a ".pcre" control indicates that the text string given
	as a target needs to match the PCRE regular expression given as a		as a target needs to match the PCRE regular expression given as a
	value in the control type, where that regular expression is anchored		value in the control type, where that regular expression is anchored
	on both sides. (If anchoring is not desired for a side, ".*" needs		on both sides. (If anchoring is not desired for a side, ".*" needs
	to be inserted there.)		to be inserted there.)
	6. Module superstructure		5.2. Endianness in .bits
			How useful would it be to have another variant of .bits that counts
			bits like in RFC box notation? (Or at least per-byte? 32-bit words
			don't always perfectly mesh with byte strings.)
			5.3. .bitfield control
			Provide a way to specify bitfields in byte strings and uints to a
			higher level of detail than is possible with .bits. Strawman:
			Field = uint .bitfield Fieldbits
			Fieldbits = [
			flag1: [1, bool],
			val: [4, Vals],
			flag2: [1, bool],
			]
			Vals = &(A: 0, B: 1, C: 2, D: 3)
			Note that the group within the controlling array can have choices,
			enabling the whole power of a context-free grammar (but not much
			more).
			6. Co-occurrence Constraints
			While there are no co-occurrence constraints in CDDL, many actual use
			cases can be addressed by using the fact that a group is a grammar:
			postal = {
			( street: text,
			housenumber: text) //
			( pobox: text .regexp "[0-9]+" )
			}
			However, constraints that are not just structural/tree-based but are
			predicates combining parts of the structure cannot be expressed:
			session = {
			timeout: uint,
			}
			other-session = {
			timeout: uint .lt [somehow refer to session.timeout],
			}
			As a minimum, this requires the ability to reach over to other parts
			of the tree in a control. Compare JSON Pointer [RFC6901] and JSON
			Relative Pointer [I-D.handrews-relative-json-pointer]. More
			generally, something akin to what Schematron is to Relax-NG may be
			needed.
			7. Module superstructure
	CDDL rules could be packaged as modules and referenced from other		CDDL rules could be packaged as modules and referenced from other
	modules. There could be some control of namespace pollution, as well		modules. There could be some control of namespace pollution, as well
	as unambiguous referencing ("versioning").		as unambiguous referencing ("versioning").
	This is probably best achieved by a pragma-like syntax which could be		This is probably best achieved by a pragma-like syntax which could be
	carried in CDDL comments, leaving each module to be valid CDDL (if		carried in CDDL comments, leaving each module to be valid CDDL (if
	missing some rule definitions to be imported).		missing some rule definitions to be imported).
	7. IANA Considerations		8. IANA Considerations
	This document makes no requests of IANA.		This document makes no requests of IANA.
	8. Security considerations		9. Security considerations
	The security considerations of [I-D.ietf-cbor-cddl] apply.		The security considerations of [I-D.ietf-cbor-cddl] apply.
	9. References		10. References
	9.1. Normative References		10.1. Normative References
	[I-D.ietf-cbor-cddl]		[I-D.ietf-cbor-cddl]
	Birkholz, H., Vigano, C., and C. Bormann, "Concise data		Birkholz, H., Vigano, C., and C. Bormann, "Concise data
	definition language (CDDL): a notational convention to		definition language (CDDL): a notational convention to
	express CBOR data structures", draft-ietf-cbor-cddl-00		express CBOR data structures", draft-ietf-cbor-cddl-03
	(work in progress), July 2017.		(work in progress), July 2018.
	9.2. Informative References		10.2. Informative References
			[I-D.handrews-relative-json-pointer]
			Luff, G. and H. Andrews, "Relative JSON Pointers", draft-
			handrews-relative-json-pointer-01 (work in progress),
			January 2018.
	[PCRE] "Perl-compatible Regular Expressions (revised API:		[PCRE] "Perl-compatible Regular Expressions (revised API:
	PCRE2)", n.d., <http://pcre.org/current/doc/html/>.		PCRE2)", n.d., <http://pcre.org/current/doc/html/>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<https://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
			[RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed.,
			"JavaScript Object Notation (JSON) Pointer", RFC 6901,
			DOI 10.17487/RFC6901, April 2013,
			<https://www.rfc-editor.org/info/rfc6901>.
	[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",		[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
	RFC 7405, DOI 10.17487/RFC7405, December 2014,		RFC 7405, DOI 10.17487/RFC7405, December 2014,
	<https://www.rfc-editor.org/info/rfc7405>.		<https://www.rfc-editor.org/info/rfc7405>.
	[XSD2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes		[XSD2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
	Second Edition", World Wide Web Consortium Recommendation		Second Edition", World Wide Web Consortium Recommendation
	REC-xmlschema-2-20041028, October 2004,		REC-xmlschema-2-20041028, October 2004,
	<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.		<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
	Acknowledgements		Acknowledgements
End of changes. 14 change blocks.
	23 lines changed or deleted		88 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/