rfc9741.original		rfc9741.txt
	Network Working Group C. Bormann		Internet Engineering Task Force (IETF) C. Bormann
	Internet-Draft Universität Bremen TZI		Request for Comments: 9741 Universität Bremen TZI
	Intended status: Standards Track 9 January 2025		Category: Standards Track March 2025
	Expires: 13 July 2025		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
	draft-ietf-cbor-cddl-more-control-08
	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 both in an		point. RFCs have added to this extension point in both an
	application-specific and a more general way.		application-specific and a more general way.
	The present document defines a number of additional generally		The present document defines a number of additional generally
	applicable control operators for text conversion (Bytes, Integers,		applicable control operators for text conversion (bytes, integers,
	JSON, Printf-style formatting) and for an operation on text.		printf-style formatting, and JSON) and for an operation on text.
	About This Document
	This note is to be removed before publishing as an RFC.
	The latest revision of this draft can be found at https://cbor-
	wg.github.io/cddl-more-control/. Status information for this
	document may be found at https://datatracker.ietf.org/doc/draft-ietf-
	cbor-cddl-more-control/.
	Discussion of this document takes place on the Concise Binary Object
	Representation (CBOR) Maintenance and Extensions Working Group
	mailing list (mailto:cbor@ietf.org), which is archived at
	https://mailarchive.ietf.org/arch/browse/cbor/. Subscribe at
	https://www.ietf.org/mailman/listinfo/cbor/.
	Source for this draft and an issue tracker can be found at
	https://github.com/cbor-wg/cddl-more-control.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on 13 July 2025.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9741.
	Copyright Notice		Copyright Notice
	Copyright (c) 2025 IETF Trust and the persons identified as the		Copyright (c) 2025 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Terminology
	2. Text Conversion . . . . . . . . . . . . . . . . . . . . . . . 4		2. Text Conversion
	2.1. Byte Strings: Base 16 (Hex), Base 32, Base 45, Base 64 . 4		2.1. Byte Strings: Base 16 (Hex), Base 32, Base 45, and Base 64
	2.2. Numerals . . . . . . . . . . . . . . . . . . . . . . . . 6		2.2. Numerals
	2.3. Printf-style Formatting . . . . . . . . . . . . . . . . . 7		2.3. Printf-Style Formatting
	2.4. JSON Values . . . . . . . . . . . . . . . . . . . . . . . 8		2.4. JSON Values
	3. Text Processing . . . . . . . . . . . . . . . . . . . . . . . 9		3. Text Processing
	3.1. Join . . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.1. Join
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		4. IANA Considerations
	5. Implementation Status . . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations
	6. Security considerations . . . . . . . . . . . . . . . . . . . 12		6. References
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		6.1. Normative References
	7.1. Normative References . . . . . . . . . . . . . . . . . . 12		6.2. Informative References
	7.2. Informative References . . . . . . . . . . . . . . . . . 13		List of Figures
	List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . 14		List of Tables
	List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . 14		Acknowledgements
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14		Author's Address
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
	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 both in 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:		applicable control operators. In Table 1, the column marked t is for
			"target type" (left-hand side), and the column marked c is for
			"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 |
	+---------------+---------+-------+------------------------------+		+---------------+---------+-------+------------------------------+
	| .hex, .hexlc, | text | bytes | Base16 representation of |		| .hex, .hexlc, | text | bytes | Base16 representation of |
	| .hexuc | | | byte strings |		| .hexuc | | | byte strings |
	+---------------+---------+-------+------------------------------+		+---------------+---------+-------+------------------------------+
	| .b32, .h32 | text | bytes | Base32 representation of |		| .b32, .h32 | text | bytes | Base32 representation of |
	| | | | byte strings |		| | | | byte strings |
	+---------------+---------+-------+------------------------------+		+---------------+---------+-------+------------------------------+
	| .b45 | text | bytes | Base45 representation of |		| .b45 | text | bytes | Base45 representation of |
	| | | | byte strings |		| | | | byte strings |
	+---------------+---------+-------+------------------------------+		+---------------+---------+-------+------------------------------+
	skipping to change at page 3, line 47 ¶		skipping to change at line 115 ¶
	| .printf | text | array | Printf-formatted text |		| .printf | text | array | Printf-formatted text |
	| | | | representation of data items |		| | | | representation of data items |
	+---------------+---------+-------+------------------------------+		+---------------+---------+-------+------------------------------+
	| .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
	[BCP14] (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.		side operand and "controller" to the right-hand-side operand. "Tool"
	"Tool" refers to tools along the lines of that described in		refers to tools along the lines of that described in Appendix F of
	Appendix F of [RFC8610]. Note also that the data model underlying		[RFC8610]. Note also that the data model underlying CDDL provides
	CDDL provides for text strings as well as byte strings as two		for text strings as well as byte strings as two separate types, which
	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, 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 is complicated by the		The specification of these control operators cannot provide full
	large number of transformations in use. Inspired by Section 8 of RFC		coverage of the large number of transformations in use; it focuses on
	8949 [STD94], this specification uses representations defined in		[RFC4648] and additionally [RFC9285], as shown in Table 2. For the
	[RFC4648] with the following names:		representations defined in [RFC4648], this specification uses names
			as inspired by Section 8 of RFC 8949 [STD94]:
	+==============+=======================+========================+		+==============+===========================+========================+
	| name | meaning | reference |		| Name | Meaning | Reference |
	+==============+=======================+========================+		+==============+===========================+========================+
	| .b64u | Base64URL, no padding | Section 5 of [RFC4648] |		| .b64u | Base64url, no padding | Section 5 of |
	+--------------+-----------------------+------------------------+		| | | [RFC4648] |
	| .b64u-sloppy | Base64URL, no | Section 5 of [RFC4648] |		+--------------+---------------------------+------------------------+
	| | padding, sloppy | |		| .b64u-sloppy | Base64url, no padding, | Section 5 of |
	+--------------+-----------------------+------------------------+		| | sloppy | [RFC4648] |
	| .b64c | Base64 classic, | Section 4 of [RFC4648] |		+--------------+---------------------------+------------------------+
	| | padding | |		| .b64c | Base64 classic, padding | Section 4 of |
	+--------------+-----------------------+------------------------+		| | | [RFC4648] |
	| .b64c-sloppy | Base64 classic, | Section 4 of [RFC4648] |		+--------------+---------------------------+------------------------+
	| | padding, sloppy | |		| .b64c-sloppy | Base64 classic, padding, | Section 4 of |
	+--------------+-----------------------+------------------------+		| | sloppy | [RFC4648] |
	| .b32 | Base32, no padding | Section 6 of [RFC4648] |		+--------------+---------------------------+------------------------+
	+--------------+-----------------------+------------------------+		| .b32 | Base32, no padding | Section 6 of |
	| .h32 | Base32/hex alphabet, | Section 7 of [RFC4648] |		| | | [RFC4648] |
	| | no padding | |		+--------------+---------------------------+------------------------+
	+--------------+-----------------------+------------------------+		| .h32 | Base32 with "Extended | Section 7 of |
	| .hex | Base16 (hex), either | Section 8 of [RFC4648] |		| | Hex" alphabet, no padding | [RFC4648] |
	| | case | |		+--------------+---------------------------+------------------------+
	+--------------+-----------------------+------------------------+		| .hex | Base16 (hex), either case | Section 8 of |
	| .hexlc | Base16 (hex), lower | Section 8 of [RFC4648] |		| | | [RFC4648] |
	| | case | |		+--------------+---------------------------+------------------------+
	+--------------+-----------------------+------------------------+		| .hexlc | Base16 (hex), lower case | Section 8 of |
	| .hexuc | Base16 (hex), upper | Section 8 of [RFC4648] |		| | | [RFC4648] |
	| | case | |		+--------------+---------------------------+------------------------+
	+--------------+-----------------------+------------------------+		| .hexuc | Base16 (hex), upper case | Section 8 of |
	| .b45 | Base45 | [RFC9285] |		| | | [RFC4648] |
	+--------------+-----------------------+------------------------+		+--------------+---------------------------+------------------------+
			| .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 base32hex encoding with padding, or		not provide base64url or base32(hex) encoding with padding or base64
	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 maybe worth pointing out here		each of them, respectively. (This is perhaps worth pointing out
	explicitly as this contrasts with the "b64" literal prefix that can		explicitly as it contrasts with the "b64" literal prefix that can be
	be used to notate byte strings in CDDL source code, which simply		used to notate byte strings in CDDL source code, which simply accepts
	accepts characters from either alphabet. This behavior is different		characters from either alphabet. This behavior is different from the
	from the matching behavior of the four base64 control operators		matching behavior of the four base64 control operators defined here.)
	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 behind 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		with limited data transparency (such as URLs) but is included because
	because of its close relationship to QR codes and its wide use in		of its close relationship to QR codes and its wide use in health
	health informatics (note that base45 is strongly specified not to		informatics (note that base45 is strongly specified not to allow
	allow sloppy forms of encoding).		sloppy forms of encoding).
	2.2. Numerals		2.2. Numerals
	+=========+============================+===========+		+=========+============================+===========+
	| name | meaning | reference |		| Name | Meaning | Reference |
	+=========+============================+===========+		+=========+============================+===========+
	| .base10 | Base-ten (decimal) Integer | --- |		| .base10 | Base-ten (decimal) integer | --- |
	+---------+----------------------------+-----------+		+---------+----------------------------+-----------+
	Table 3: Control Operator for Text Conversion of		Table 3: Control Operator for Text Conversion of
	Integers		Integers
	The control operator .base10 allows the modeling of text strings that		The control operator .base10 allows the modeling of text strings that
	carry an integer number in decimal form (as a text string with digits		carry an integer number in decimal form (as a text string with digits
	in the usual base-ten positional numeral system), such as in the		in the usual base-ten positional numeral system), such as in the
	uint64/int64 formats of YANG-JSON [RFC7951].		uint64/int64 formats of YANG-JSON [RFC7951].
	yang-json-sid = text .base10 (0..9223372036854775807)		yang-json-sid = text .base10 (0..9223372036854775807)
	Again, the specification is opinionated by only providing for integer		Again, the specification is opinionated by only providing for integer
	numbers and these only represented without leading zeros, i.e., the		numbers represented without leading zeros, i.e., the decimal integer
	decimal integer numerals match the regular expression 0|-?[1-9][0-9]*		numerals match the regular expression 0|-?[1-9][0-9]* (of course,
	(of course, further restricted by the control type). See the next		this is further restricted by the control type). See Section 2.3 for
	section for more flexibility, and for other numeric bases such as		more flexibility and for other numeric bases such as octal,
	octal, hexadecimal, or binary conversions.		hexadecimal, or binary conversions.
	Note that this control operator governs text representations of		Note that this control operator governs text representations of
	integers and should not be confused with the control operators		integers and should not be confused with the control operators
	governing text representations of byte strings (b64u etc.). This		governing text representations of byte strings (such as .b64u). This
	contrast is somewhat reinforced by spelling out "base" in the name		contrast is somewhat reinforced by spelling out "base" in the name
	base10 as opposed to those of the byte string operators.		.base10 as opposed to those of the byte string operators.
	2.3. Printf-style Formatting		2.3. Printf-Style Formatting
	+=========+===================================+===========+		+=========+=========================================+===========+
	| name | meaning | reference |		| Name | Meaning | Reference |
	+=========+===================================+===========+		+=========+=========================================+===========+
	| .printf | Printf-formatting of data item(s) | --- |		| .printf | Printf-style formatting of data item(s) | --- |
	+---------+-----------------------------------+-----------+		+---------+-----------------------------------------+-----------+
	Table 4: Control Operator for Printf-formatting of Data		Table 4: Control Operator for Printf-Style Formatting of Data
	Item(s)		Item(s)
	The control operator .printf allows the modeling of text strings that		The control operator .printf allows the modeling of text strings that
	carry various formatted information, as long as the format can be		carry various formatted information, as long as the format can be
	represented in Printf-style formatting strings as they are used in		represented in printf-style formatting strings as they are used in
	the C language (see Section 7.21.6.1 of [C]).		the C language (see Section 7.23.6.1 of [C]; note that the "C23"
			standard includes %b and %B for formatting into binary digits).
	The controller (right-hand side) of the .printf control is an array		The controller (right-hand side) of the .printf control is an array
	of one Printf-style format string and zero or more data items that		of one printf-style format string and zero or more data items that
	fit the individual conversion specifications in the format string.		fit the individual conversion specifications in the format string.
	The construct matches a text string representing the textual output		The construct matches a text string representing the textual output
	of an equivalent C-language printf function call that is given the		of an equivalent C-language printf function call that receives as
	format string and the data items following it in the array.		arguments the format string and the data items following it in the
			array.
	From the printf specification in the C language, length modifiers		Out of the functionality described for printf formatting in
	(paragraph 7) are not used and MUST NOT be included in the format		Section 7.23.6.1 of the C language specification [C], length
	string. The 's' conversion specifier (paragraph 8) is used to		modifiers (paragraph 7) are not used and MUST NOT be included in the
	interpolate a text string in UTF-8 form. The 'c' conversion		format string. The "s" conversion specifier (paragraph 8) is used to
			interpolate a text string in UTF-8 form. The "c" conversion
	specifier (paragraph 8) represents a single Unicode scalar value as a		specifier (paragraph 8) represents a single Unicode scalar value as a
	UTF-8 character. The 'p' and 'n' conversion specifiers (paragraph 8)		UTF-8 character. The "p" and "n" conversion specifiers (paragraph 8)
	are not used and MUST NOT be included in the format string.		are not used and MUST NOT be included in the format string.
	In the following example, my_alg_19 matches the text string "0x0013":		In the following example, my_alg_19 matches the text string "0x0013":
	my_alg_19 = hexlabel<19>		my_alg_19 = hexlabel<19>
	hexlabel<K> = text .printf (["0x%04x", K])		hexlabel<K> = text .printf (["0x%04x", K])
	The data items in the controller array do not need to be literals, as		The data items in the controller array do not need to be literals, as
	for example in:		in the following example:
	any_alg = hexlabel<1..20>		any_alg = hexlabel<1..20>
	hexlabel<K> = text .printf (["0x%04x", K])		hexlabel<K> = text .printf (["0x%04x", K])
	Here, any_alg matches the text strings "0x0013" or "0x0001" but not		Here, any_alg matches the text strings "0x0013" or "0x0001" but not
	"0x1234".		"0x1234".
	2.4. JSON Values		2.4. JSON Values
	Some applications store complete JSON texts [STD90] into text		Some applications store complete JSON texts [STD90] into text
	strings, the JSON value for which can easily be defined in CDDL by		strings. The JSON value of these can easily be defined in CDDL by
	using the default JSON-to-CBOR conversion rules provided by		using the default JSON-to-CBOR conversion rules provided in
	Section 6.2 of RFC 8949 [STD94]. This is supported by a control		Section 6.2 of RFC 8949 [STD94]. This is supported by a control
	operator similar to .cbor as defined in Section 3.8.4 of [RFC8610].		operator similar to .cbor as defined in Section 3.8.4 of [RFC8610].
	+=======+=========+===========+		+=======+=========+===========+
	| name | meaning | reference |		| Name | Meaning | Reference |
	+=======+=========+===========+		+=======+=========+===========+
	| .json | JSON | [STD90] |		| .json | JSON | [STD90] |
	+-------+---------+-----------+		+-------+---------+-----------+
	Table 5: Control Operator		Table 5: Control Operator
	for Text Conversion of JSON		for Text Conversion of JSON
	Values		Values
	embedded-claims = text .json claims		embedded-claims = text .json claims
	claims = {iss: text, exp: text}		claims = {iss: text, exp: text}
	skipping to change at page 8, line 44 ¶		skipping to change at line 344 ¶
	underlying CDDL. Note that the intention of Section 2.2 of		underlying CDDL. Note that the intention of Section 2.2 of
	[RFC7493] is directly supported by Section 6.2 of RFC 8949		[RFC7493] is directly supported by Section 6.2 of RFC 8949
	[STD94]. The recommendation to use text strings for representing		[STD94]. The recommendation to use text strings for representing
	numbers outside JSON's interoperable range is a requirement on the		numbers outside JSON's interoperable range is a requirement on the
	application data model and therefore needs to be reflected on the		application data model and therefore needs to be reflected on the
	right-hand side of the .json control operator.		right-hand side of the .json control operator.
	* This control operator provides no way to constrain the use of		* This control operator provides no way to constrain the use of
	blank space or other serialization variants in the JSON		blank space or other serialization variants in the JSON
	representation of the data items; restrictions on the		representation of the data items; restrictions on the
	serialization to specific variants (e.g, not providing for the		serialization to specific variants (e.g., not providing for the
	addition of any insignificant blank space, prescribing an order in		addition of any insignificant blank space and prescribing an order
	which map entries are serialized) could be defined in future		in which map entries are serialized) could be defined in future
	control operators.		control operators.
	* A .jsonseq is not provided in this document for [RFC7464], as no		* A .jsonseq is not provided in this document for JSON text
	use case for inclusion in CDDL is known at the time of writing;		sequences [RFC7464], as no use case for inclusion in CDDL is known
	again, future control operators could address this use case.		at the time of writing; again, future control operators could
			address this use case.
	3. Text Processing		3. Text Processing
	3.1. Join		3.1. Join
	Often, text strings need to be constructed out of parts that can best		Often, text strings need to be constructed out of parts that can best
	be modeled as an array.		be modeled as an array.
	+=======+==================================+===========+		+=======+==================================+===========+
	| name | meaning | reference |		| Name | Meaning | Reference |
	+=======+==================================+===========+		+=======+==================================+===========+
	| .join | concatenate elements of an array | --- |		| .join | Concatenate elements of an array | --- |
	+-------+----------------------------------+-----------+		+-------+----------------------------------+-----------+
	Table 6: Control Operator for Text Generation from		Table 6: Control Operator for Text Generation from
	Arrays		Arrays
	For example, an IPv4 address in dotted-decimal might be modeled as in		For example, an IPv4 address in dotted-decimal might be modeled as in
	Figure 1.		Figure 1.
	legacy-ip-address = text .join legacy-ip-address-elements		legacy-ip-address = text .join legacy-ip-address-elements
	legacy-ip-address-elements = [bytetext, ".", bytetext, ".",		legacy-ip-address-elements = [bytetext, ".", bytetext, ".",
	bytetext, ".", bytetext]		bytetext, ".", bytetext]
	bytetext = text .base10 byte		bytetext = text .base10 byte
	byte = 0..255		byte = 0..255
	Figure 1: Using the .join operator to build dotted-decimal IPv4		Figure 1: Using the .join Operator to Build Dotted-Decimal IPv4
	addresses		Addresses
	The elements of the controller array need to be strings (text or byte		The elements of the controller array need to be strings (text or byte
	strings). The control operator matches a data item if that data item		strings). The control operator matches a data item if that data item
	is also a string, built by concatenating the strings in the array.		is also a string, built by concatenating the strings in the array.
	The result of this concatenation is of the same kind of string (text		The result of this concatenation is of the same kind of string (text
	or bytes) as the first element of the array. (If there is no element		or bytes) as the first element of the array. (If there is no element
	in the array, the .join construct matches either kind of empty		in the array, the .join construct matches either kind of empty
	string, obviously further constrained by the control operator		string, obviously further constrained by the control operator
	target.) The concatenation is performed on the sequences of bytes in		target.) The concatenation is performed on the sequences of bytes in
	the strings. If the result of the concatenation is a text string,		the strings. If the result of the concatenation is a text string,
	the resulting sequence of bytes only matches the target data item if		the resulting sequence of bytes only matches the target data item if
	that result is a valid text string (i.e., valid UTF-8; note that in		that result is a valid text string (i.e., valid UTF-8). Note that in
	contrast to the algorithm used in Section 3.2.3 of RFC 8949 [STD94]		contrast to the algorithm used in Section 3.2.3 of RFC 8949 [STD94],
	there is no need that all individual byte sequences going into the		there is no need for all individual byte sequences going into the
	concatenation constitute valid text strings).		concatenation to constitute valid text strings.
	Note that this control operator is hard to validate in the most		Note that this control operator is hard to validate in the most
	general case, as this would require full parser functionality.		general case, as this would require full parser functionality.
	Simple implementation strategies will use array elements with		Simple implementation strategies will use array elements with
	constant values as guideposts ("markers", such as the "." in		constant values as guideposts ("markers", such as the "." in
	Figure 1) for isolating the variable elements that need further		Figure 1) for isolating the variable elements that need further
	validation at the CDDL data model level. It is therefore recommended		validation at the CDDL data model level. Therefore, it is
	to limit the use of .join to simple arrangements where the array		recommended to limit the use of .join to simple arrangements where
	elements are laid out explicitly and there are no adjacent variable		the array elements are laid out explicitly and there are no adjacent
	elements without intervening constant values, and where these		variable elements without intervening constant values, and where
	constant values do not occur within the text described by the		these constant values do not occur within the text described by the
	variable elements.		variable elements. If more complex parsing functionality is
	If more complex parsing functionality is required, the ABNF control		required, the ABNF control operators (see Section 3 of [RFC9165]) may
	operators (see Section 3 of [RFC9165]) may be useful; however, these		be useful; however, these cannot reach back into CDDL-specified
	cannot reach back into CDDL-specified elements like .join can do.		elements like .join can.
	| Implementation note: A validator implementation can use the		| Implementation note: A validator implementation can use the
	| marker elements to scan the text, isolating the variable		| marker elements to scan the text and isolate the variable
	| elements. It also can build a parsing regexp (Section 6 of		| elements. It also can build a parsing regexp from the elements
	| [RFC9485]; see also Section 8 of [RFC9485] for security		| of the controller array, with capture groups for each element,
	| considerations related to regexps) from the elements of the		| and validate the captures against the elements of the array.
	| controller array, with capture groups for each element, and		| (For more about parsing regexps, see Section 6 of [RFC9485];
	| validate the captures against the elements of the array. In		| see also Section 8 of [RFC9485] for security considerations
	| the most general case, these implementation strategies can		| related to regexps.) In the most general case, these
	| exhibit false negatives, where the implementation cannot find		| implementation strategies can exhibit false negatives, where
	| the structure that would be successfully validated using the		| the implementation cannot find the structure that would be
	| controller; it is RECOMMENDED that implementations provide full		| successfully validated using the controller; it is RECOMMENDED
	| coverage at least for the marker-based subset outlined in the		| that implementations provide full coverage at least for the
	| previous paragraph.		| marker-based subset outlined in the previous paragraph.
	4. IANA Considerations		4. IANA Considerations
	// RFC Editor: please replace RFC-XXXX with the RFC number of this		IANA has registered the contents of Table 7 into the "CDDL Control
	// RFC and remove this note.		Operators" registry of [IANA.cddl]:
	This document requests IANA to register the contents of Table 7 into
	the registry "CDDL Control Operators" of [IANA.cddl]:
	+==============+============+
	| Name | Reference |
	+==============+============+
	| .b64u | [RFC-XXXX] |
	+--------------+------------+
	| .b64u-sloppy | [RFC-XXXX] |
	+--------------+------------+
	| .b64c | [RFC-XXXX] |
	+--------------+------------+
	| .b64c-sloppy | [RFC-XXXX] |
	+--------------+------------+
	| .b45 | [RFC-XXXX] |
	+--------------+------------+
	| .b32 | [RFC-XXXX] |
	+--------------+------------+
	| .h32 | [RFC-XXXX] |
	+--------------+------------+
	| .hex | [RFC-XXXX] |
	+--------------+------------+
	| .hexlc | [RFC-XXXX] |
	+--------------+------------+
	| .hexuc | [RFC-XXXX] |
	+--------------+------------+
	| .base10 | [RFC-XXXX] |
	+--------------+------------+
	| .printf | [RFC-XXXX] |
	+--------------+------------+
	| .json | [RFC-XXXX] |
	+--------------+------------+
	| .join | [RFC-XXXX] |
	+--------------+------------+
	Table 7: New Control
	Operators To Be
	Registered
	5. Implementation Status
	This section is to be removed before publishing as an RFC.
	In the CDDL tool described in Appendix F of [RFC8610], the control
	operators defined in the present revision of this specification are
	implemented as of version 0.10.4.
	6. Security considerations
	The security considerations in Section 5 of [RFC8610] apply, as well		+==============+===========+
	as those in Section 12 of [RFC4648] for the control operators defined		| Name | Reference |
	in Section 2.1.		+==============+===========+
			| .b64u | RFC 9741 |
			+--------------+-----------+
			| .b64u-sloppy | RFC 9741 |
			+--------------+-----------+
			| .b64c | RFC 9741 |
			+--------------+-----------+
			| .b64c-sloppy | RFC 9741 |
			+--------------+-----------+
			| .b45 | RFC 9741 |
			+--------------+-----------+
			| .b32 | RFC 9741 |
			+--------------+-----------+
			| .h32 | RFC 9741 |
			+--------------+-----------+
			| .hex | RFC 9741 |
			+--------------+-----------+
			| .hexlc | RFC 9741 |
			+--------------+-----------+
			| .hexuc | RFC 9741 |
			+--------------+-----------+
			| .base10 | RFC 9741 |
			+--------------+-----------+
			| .printf | RFC 9741 |
			+--------------+-----------+
			| .json | RFC 9741 |
			+--------------+-----------+
			| .join | RFC 9741 |
			+--------------+-----------+
	7. References		Table 7: New Control
			Operators
	7.1. Normative References		5. Security Considerations
	[BCP14] Best Current Practice 14,		The security considerations in Section 5 of [RFC8610] apply. In
	<https://www.rfc-editor.org/info/bcp14>.		addition, for the control operators defined in Section 2.1, the
	At the time of writing, this BCP comprises the following:		security considerations in Section 12 of [RFC4648] apply.
	Bradner, S., "Key words for use in RFCs to Indicate		6. References
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.
	Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		6.1. Normative References
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[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:2018, June 2018,		Fourth Edition, ISO/IEC 9899:2024, October 2024,
	<https://www.iso.org/standard/74528.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/20181230041359if_/		<https://www.open-std.org/jtc1/sc22/wg14/www/docs/
	http://www.open- std.org/jtc1/sc22/wg14/www/abq/		n3220.pdf>.
	c17_updated_proposed_fdis.pdf
	(https://web.archive.org/web/20181230041359if_/
	http://www.open- std.org/jtc1/sc22/wg14/www/abq/
	c17_updated_proposed_fdis.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
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<https://www.rfc-editor.org/rfc/rfc4648>.		<https://www.rfc-editor.org/info/rfc4648>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data		[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
	Definition Language (CDDL): A Notational Convention to		Definition Language (CDDL): A Notational Convention to
	Express Concise Binary Object Representation (CBOR) and		Express Concise Binary Object Representation (CBOR) and
	JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,		JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
	June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.		June 2019, <https://www.rfc-editor.org/info/rfc8610>.
	[RFC9165] Bormann, C., "Additional Control Operators for the Concise		[RFC9165] Bormann, C., "Additional Control Operators for the Concise
	Data Definition Language (CDDL)", RFC 9165,		Data Definition Language (CDDL)", RFC 9165,
	DOI 10.17487/RFC9165, December 2021,		DOI 10.17487/RFC9165, December 2021,
	<https://www.rfc-editor.org/rfc/rfc9165>.		<https://www.rfc-editor.org/info/rfc9165>.
	[RFC9285] Fältström, P., Ljunggren, F., and D.W. van Gulik, "The		[RFC9285] Fältström, P., Ljunggren, F., and D.W. van Gulik, "The
	Base45 Data Encoding", RFC 9285, DOI 10.17487/RFC9285,		Base45 Data Encoding", RFC 9285, DOI 10.17487/RFC9285,
	August 2022, <https://www.rfc-editor.org/rfc/rfc9285>.		August 2022, <https://www.rfc-editor.org/info/rfc9285>.
	[RFC9485] Bormann, C. and T. Bray, "I-Regexp: An Interoperable		[RFC9485] Bormann, C. and T. Bray, "I-Regexp: An Interoperable
	Regular Expression Format", RFC 9485,		Regular Expression Format", RFC 9485,
	DOI 10.17487/RFC9485, October 2023,		DOI 10.17487/RFC9485, October 2023,
	<https://www.rfc-editor.org/rfc/rfc9485>.		<https://www.rfc-editor.org/info/rfc9485>.
	[STD90] Internet Standard 90,		[STD90] Internet Standard 90,
	<https://www.rfc-editor.org/info/std90>.		<https://www.rfc-editor.org/info/std90>.
	At the time of writing, this STD comprises the following:		At the time of writing, this STD comprises the following:
	Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", STD 90, RFC 8259,		Interchange Format", STD 90, RFC 8259,
	DOI 10.17487/RFC8259, December 2017,		DOI 10.17487/RFC8259, December 2017,
	<https://www.rfc-editor.org/info/rfc8259>.		<https://www.rfc-editor.org/info/rfc8259>.
	[STD94] Internet Standard 94,		[STD94] Internet Standard 94,
	<https://www.rfc-editor.org/info/std94>.		<https://www.rfc-editor.org/info/std94>.
	At the time of writing, this STD comprises the following:		At the time of writing, this STD comprises the following:
	Bormann, C. and P. Hoffman, "Concise Binary Object		Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", STD 94, RFC 8949,		Representation (CBOR)", STD 94, RFC 8949,
	DOI 10.17487/RFC8949, December 2020,		DOI 10.17487/RFC8949, December 2020,
	<https://www.rfc-editor.org/info/rfc8949>.		<https://www.rfc-editor.org/info/rfc8949>.
	7.2. Informative References		6.2. Informative References
	[RFC7464] Williams, N., "JavaScript Object Notation (JSON) Text		[RFC7464] Williams, N., "JavaScript Object Notation (JSON) Text
	Sequences", RFC 7464, DOI 10.17487/RFC7464, February 2015,		Sequences", RFC 7464, DOI 10.17487/RFC7464, February 2015,
	<https://www.rfc-editor.org/rfc/rfc7464>.		<https://www.rfc-editor.org/info/rfc7464>.
	[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,		[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
	DOI 10.17487/RFC7493, March 2015,		DOI 10.17487/RFC7493, March 2015,
	<https://www.rfc-editor.org/rfc/rfc7493>.		<https://www.rfc-editor.org/info/rfc7493>.
	[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",		[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
	RFC 7951, DOI 10.17487/RFC7951, August 2016,		RFC 7951, DOI 10.17487/RFC7951, August 2016,
	<https://www.rfc-editor.org/rfc/rfc7951>.		<https://www.rfc-editor.org/info/rfc7951>.
	[RFC9090] Bormann, C., "Concise Binary Object Representation (CBOR)		[RFC9090] Bormann, C., "Concise Binary Object Representation (CBOR)
	Tags for Object Identifiers", RFC 9090,		Tags for Object Identifiers", RFC 9090,
	DOI 10.17487/RFC9090, July 2021,		DOI 10.17487/RFC9090, July 2021,
	<https://www.rfc-editor.org/rfc/rfc9090>.		<https://www.rfc-editor.org/info/rfc9090>.
	List of Figures		List of Figures
	1. Using the .join operator to build dotted-decimal IPv4 addresses		Figure 1: Using the .join Operator to Build Dotted-Decimal IPv4
	(Figure 1)		Addresses
	List of Tables		List of Tables
	1. Summary of New Control Operators in this Document (Table 1)		Table 1: Summary of New Control Operators in This Document
	2. Control Operators for Text Conversion of Byte Strings (Table 2)		Table 2: Control Operators for Text Conversion of Byte Strings
	3. Control Operator for Text Conversion of Integers (Table 3)		Table 3: Control Operator for Text Conversion of Integers
	4. Control Operator for Printf-formatting of Data Item(s) (Table 4)		Table 4: Control Operator for Printf-Style Formatting of Data Item(s)
	5. Control Operator for Text Conversion of JSON Values (Table 5)		Table 5: Control Operator for Text Conversion of JSON Values
	6. Control Operator for Text Generation from Arrays (Table 6)		Table 6: Control Operator for Text Generation from Arrays
	7. New Control Operators To Be Registered (Table 7)		Table 7: New Control Operators
	Acknowledgements		Acknowledgements
	Henk Birkholz suggested the need for many of the control operators		Henk Birkholz suggested the need for many of the control operators
	defined here. The author would like to thank Laurence Lundblade and		defined here. The author would like to thank Laurence Lundblade and
	Jeremy O'Donoghue for sharpening some of the mandates, Mikolai		Jeremy O'Donoghue for sharpening some of the mandates, Mikolai
	Gütschow for improvements to some examples, A.J. Stein for serving as		Gütschow for improvements to some examples, A.J. Stein for serving as
	shepherd for this document and for his shepherd review, the IESG and		shepherd for this document and for his shepherd review, the IESG and
	Directorate reviewers (notably Ari Keränen, Darrel Miller, and Éric		Directorate reviewers (notably Ari Keränen, Darrel Miller, and Éric
	Vyncke), and Orie Steele for serving as responsible AD and for		Vyncke), and Orie Steele for serving as responsible AD and for
End of changes. 76 change blocks.
	287 lines changed or deleted		259 lines changed or added
This html diff was produced by rfcdiff 1.48.