rfc9741v2.txt		rfc9741.txt
	Internet Engineering Task Force (IETF) C. Bormann		Internet Engineering Task Force (IETF) C. Bormann
	Request for Comments: 9741 Universität Bremen TZI		Request for Comments: 9741 Universität Bremen TZI
	Category: Standards Track February 2025		Category: Standards Track March 2025
	ISSN: 2070-1721		ISSN: 2070-1721
	Concise Data Definition Language (CDDL): Additional Control Operators		Concise Data Definition Language (CDDL): Additional Control Operators
	for the Conversion and Processing of Text		for the Conversion and Processing of Text
	Abstract		Abstract
	The Concise Data Definition Language (CDDL), standardized in RFC		The Concise Data Definition Language (CDDL), standardized in RFC
	8610, provides "control operators" as its main language extension		8610, provides "control operators" as its main language extension
	point. RFCs have added to this extension point in both an		point. RFCs have added to this extension point in both an
	skipping to change at line 80 ¶		skipping to change at line 80 ¶
	1. Introduction		1. Introduction
	The Concise Data Definition Language (CDDL), standardized in		The Concise Data Definition Language (CDDL), standardized in
	[RFC8610], provides "control operators" as its main language		[RFC8610], provides "control operators" as its main language
	extension point (Section 3.8 of [RFC8610]). RFCs have added to this		extension point (Section 3.8 of [RFC8610]). RFCs have added to this
	extension point in both an application-specific [RFC9090] and a more		extension point in both an application-specific [RFC9090] and a more
	general [RFC9165] way.		general [RFC9165] way.
	The present document defines a number of additional generally		The present document defines a number of additional generally
	applicable control operators. In the table below, the column marked		applicable control operators. In Table 1, the column marked t is for
	t is for "target type" (left-hand side), and the column marked c is		"target type" (left-hand side), and the column marked c is for
	for "controller type" (right-hand side).		"controller type" (right-hand side).
	+===============+=========+=======+==============================+		+===============+=========+=======+==============================+
	| Name | t | c | Purpose |		| Name | t | c | Purpose |
	+===============+=========+=======+==============================+		+===============+=========+=======+==============================+
	| .b64u, .b64c | text | bytes | Base64 representation of |		| .b64u, .b64c | text | bytes | Base64 representation of |
	| | | | byte strings |		| | | | byte strings |
	+---------------+---------+-------+------------------------------+		+---------------+---------+-------+------------------------------+
	| .b64u-sloppy, | text | bytes | Sloppy-tolerant variants of |		| .b64u-sloppy, | text | bytes | Sloppy-tolerant variants of |
	| .b64c-sloppy | | | the above |		| .b64c-sloppy | | | the above |
	+---------------+---------+-------+------------------------------+		+---------------+---------+-------+------------------------------+
	skipping to change at line 117 ¶		skipping to change at line 117 ¶
	+---------------+---------+-------+------------------------------+		+---------------+---------+-------+------------------------------+
	| .json | text | any | Text representation of JSON |		| .json | text | any | Text representation of JSON |
	| | | | values |		| | | | values |
	+---------------+---------+-------+------------------------------+		+---------------+---------+-------+------------------------------+
	| .join | text or | array | Build text or byte string |		| .join | text or | array | Build text or byte string |
	| | bytes | | from array of components |		| | bytes | | from array of components |
	+---------------+---------+-------+------------------------------+		+---------------+---------+-------+------------------------------+
	Table 1: Summary of New Control Operators in This Document		Table 1: Summary of New Control Operators in This Document
	t = target type (left-hand side)
	c = controller type (right-hand side)
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Regular expressions mentioned in the text are as defined in		Regular expressions mentioned in the text are as defined in
	[RFC9485].		[RFC9485].
	This specification uses terminology from [RFC8610]. In particular,		This specification uses terminology from [RFC8610]. In particular,
	with respect to control operators, "target" refers to the left-hand-		with respect to control operators, "target" refers to the left-hand-
	side operand and "controller" to the right-hand-side operand. "Tool"		side operand and "controller" to the right-hand-side operand. "Tool"
	refers to tools along the lines of that described in Appendix F of		refers to tools along the lines of that described in Appendix F of
	[RFC8610]. Note also that the data model underlying CDDL provides		[RFC8610]. Note also that the data model underlying CDDL provides
	for text strings as well as byte strings as two separate types, which		for text strings as well as byte strings as two separate types, which
	are then collectively referred to as "strings".		are then collectively referred to as "strings".
			The term "opinionated" is used in this document to explain that the
			selection of operators included is somewhat frugal, based on opinions
			about what the preferred (and likely) usage scenarios will be.
			Specifically, not including a potential choice doesn’t by itself
			intend to express that the choice is unacceptable; it might still be
			added in a future registration if these opinions evolve.
	2. Text Conversion		2. Text Conversion
	2.1. Byte Strings: Base 16 (Hex), Base 32, Base 45, and Base 64		2.1. Byte Strings: Base 16 (Hex), Base 32, Base 45, and Base 64
	A CDDL model often defines data that are byte strings in essence but		A CDDL model often defines data that are byte strings in essence but
	need to be transported in various encoded forms, such as base64 or		need to be transported in various encoded forms, such as base64 or
	hex. This section defines a number of control operators to model		hex. This section defines a number of control operators to model
	these conversions.		these conversions.
	The control operators generally are of a form that could be used like		The control operators generally are of a form that could be used like
	this:		this:
	signature-for-json = text .b64u signature		signature-for-json = text .b64u signature
	signature = bytes .cbor COSE_Sign1		signature = bytes .cbor COSE_Sign1
	The specification of these control operators cannot provide full		The specification of these control operators cannot provide full
	coverage of the large number of transformations in use; it focuses on		coverage of the large number of transformations in use; it focuses on
	[RFC4648] and additionally [RFC9285]. For the representations		[RFC4648] and additionally [RFC9285], as shown in Table 2. For the
	defined in [RFC4648], this specification uses names as inspired by 8		representations defined in [RFC4648], this specification uses names
	of RFC 8949 [STD94]:		as inspired by Section 8 of RFC 8949 [STD94]:
	+==============+===========================+========================+		+==============+===========================+========================+
	| Name | Meaning | Reference |		| Name | Meaning | Reference |
	+==============+===========================+========================+		+==============+===========================+========================+
	| .b64u | Base64url, no padding | Section 5 of |		| .b64u | Base64url, no padding | Section 5 of |
	| | | [RFC4648] |		| | | [RFC4648] |
	+--------------+---------------------------+------------------------+		+--------------+---------------------------+------------------------+
	| .b64u-sloppy | Base64url, no padding, | Section 5 of |		| .b64u-sloppy | Base64url, no padding, | Section 5 of |
	| | sloppy | [RFC4648] |		| | sloppy | [RFC4648] |
	+--------------+---------------------------+------------------------+		+--------------+---------------------------+------------------------+
	skipping to change at line 196 ¶		skipping to change at line 200 ¶
	+--------------+---------------------------+------------------------+		+--------------+---------------------------+------------------------+
	| .hexuc | Base16 (hex), upper case | Section 8 of |		| .hexuc | Base16 (hex), upper case | Section 8 of |
	| | | [RFC4648] |		| | | [RFC4648] |
	+--------------+---------------------------+------------------------+		+--------------+---------------------------+------------------------+
	| .b45 | Base45 | [RFC9285] |		| .b45 | Base45 | [RFC9285] |
	+--------------+---------------------------+------------------------+		+--------------+---------------------------+------------------------+
	Table 2: Control Operators for Text Conversion of Byte Strings		Table 2: Control Operators for Text Conversion of Byte Strings
	Note that this specification is somewhat opinionated here: It does		Note that this specification is somewhat opinionated here: It does
	not provide base64url, base32, or base32(/hex) encoding with padding,		not provide base64url or base32(hex) encoding with padding or base64
	or base64 classic without padding. Experience indicates that these		classic without padding. Experience indicates that these
	combinations only ever occur in error, so the usability of CDDL is		combinations only ever occur in error, so the usability of CDDL is
	increased by not providing them in the first place. Also, adding "c"		increased by not providing them in the first place. Also, adding "c"
	makes sure that any decision for classic base64 is actively taken.		makes sure that any decision for classic base64 is actively taken.
	These control operators are "strict" in their matching, i.e., they		These control operators are "strict" in their matching, i.e., they
	only match base encodings that conform to the mandates of their		only match base encodings that conform to the mandates of their
	defining documents. Note that this also means that .b64u and .b64c		defining documents. Note that this also means that .b64u and .b64c
	only match text strings composed of the set of characters defined for		only match text strings composed of the set of characters defined for
	each of them, respectively. (This is perhaps worth pointing out		each of them, respectively. (This is perhaps worth pointing out
	explicitly as it contrasts with the "b64" literal prefix that can be		explicitly as it contrasts with the "b64" literal prefix that can be
	used to notate byte strings in CDDL source code, which simply accepts		used to notate byte strings in CDDL source code, which simply accepts
	characters from either alphabet. This behavior is different from the		characters from either alphabet. This behavior is different from the
	matching behavior of the four base64 control operators defined here.)		matching behavior of the four base64 control operators defined here.)
	The additional designation "sloppy" indicates that the text string is		The additional designation "sloppy" indicates that the text string is
	not validated for any additional bits being zero, in variance to what		not validated for any additional bits being zero, in variance to what
	is specified in the paragraph that follows Table 1 in Section 4 of		is specified in the paragraph that follows Table 1 in Section 4 of
	[RFC4648]. Note that the present specification is opinionated again		[RFC4648]. Note that the present specification is opinionated again
	in not specifying a sloppy variant of base32 or base32/hex, as no		in not specifying a sloppy variant of base32 or base32hex, as no
	legacy use of sloppy base32(/hex) was known at the time of writing.		legacy use of sloppy base32(hex) was known at the time of writing.
	Base45 [RFC9285] is known to be suboptimal for use in environments		Base45 [RFC9285] is known to be suboptimal for use in environments
	with limited data transparency (such as URLs) but is included because		with limited data transparency (such as URLs) but is included because
	of its close relationship to QR codes and its wide use in health		of its close relationship to QR codes and its wide use in health
	informatics (note that base45 is strongly specified not to allow		informatics (note that base45 is strongly specified not to allow
	sloppy forms of encoding).		sloppy forms of encoding).
	2.2. Numerals		2.2. Numerals
	+=========+============================+===========+		+=========+============================+===========+
	| Name | Meaning | Reference |		| Name | Meaning | Reference |
	skipping to change at line 477 ¶		skipping to change at line 481 ¶
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[C] International Organization for Standardization,		[C] International Organization for Standardization,
	"Information technology - Programming languages - C",		"Information technology - Programming languages - C",
	Fourth Edition, ISO/IEC 9899:2024, October 2024,		Fourth Edition, ISO/IEC 9899:2024, October 2024,
	<https://www.iso.org/standard/82075.html>. Technically		<https://www.iso.org/standard/82075.html>. Technically
	equivalent specification text is available at		equivalent specification text is available at
	<https://web.archive.org/web/20250212071536/		<https://www.open-std.org/jtc1/sc22/wg14/www/docs/
	https://www.open- std.org/jtc1/sc22/wg14/www/docs/
	n3220.pdf>.		n3220.pdf>.
	[IANA.cddl]		[IANA.cddl]
	IANA, "Concise Data Definition Language (CDDL)",		IANA, "Concise Data Definition Language (CDDL)",
	<https://www.iana.org/assignments/cddl>.		<https://www.iana.org/assignments/cddl>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
End of changes. 8 change blocks.
	16 lines changed or deleted		19 lines changed or added
This html diff was produced by rfcdiff 1.48.