rfc9682v2.txt		rfc9682.txt
	skipping to change at line 100 ¶		skipping to change at line 100 ¶
	The terminology from [RFC8610] applies. The grammar in [RFC8610] is		The terminology from [RFC8610] applies. The grammar in [RFC8610] is
	based on ABNF, which is defined in [STD68] and [RFC7405].		based on ABNF, which is defined in [STD68] and [RFC7405].
	2. Clarifications and Changes Based on Errata Reports		2. Clarifications and Changes Based on Errata Reports
	A number of errata reports have been made regarding some details of		A number of errata reports have been made regarding some details of
	text string and byte string literal syntax: for example, [Err6527]		text string and byte string literal syntax: for example, [Err6527]
	and [Err6543]. These are being addressed in this section, updating		and [Err6543]. These are being addressed in this section, updating
	details of the ABNF for these literal syntaxes. Also, the changes		details of the ABNF for these literal syntaxes. Also, the changes
	described in [Err6526] need to be applied (backslashes have been lost		described in [Err6526] need to be applied (backslashes have been lost
	during the RFC publication process of Appendix G.2, garbling the text		during the RFC publication process of Appendix G.2 of [RFC8610],
	explaining backslash escaping).		garbling the text explaining backslash escaping).
	These changes are intended to mirror the way existing implementations		These changes are intended to mirror the way existing implementations
	have dealt with the errata reports. This document also uses the		have dealt with the errata reports. This document also uses the
	opportunity presented for the necessary cleanup of the grammar of		opportunity presented by the necessary cleanup of the grammar of
	string literals for a backward-compatible addition to the syntax for		string literals for a backward-compatible addition to the syntax for
	hexadecimal escapes. The latter change is not automatically forward		hexadecimal escapes. The latter change is not automatically forward
	compatible (i.e., CDDL specifications that make use of this syntax do		compatible (i.e., CDDL specifications that make use of this syntax do
	not necessarily work with existing implementations until these are		not necessarily work with existing implementations until these are
	updated, which is recommended in this specification).		updated, which is recommended by this specification).
	2.1. Updates to String Literal Grammar		2.1. Updates to String Literal Grammar
	2.1.1. Erratum ID 6527 (Text String Literals)		2.1.1. Erratum ID 6527 (Text String Literals)
	The ABNF used in [RFC8610] for the content of text string literals is		The ABNF used in [RFC8610] for the content of text string literals is
	rather permissive:		rather permissive:
	; ABNF from RFC 8610:		; ABNF from RFC 8610:
	text = %x22 *SCHAR %x22		text = %x22 *SCHAR %x22
	SCHAR = %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC		SCHAR = %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC
	SESC = "\" (%x20-7E / %x80-10FFFD)		SESC = "\" (%x20-7E / %x80-10FFFD)
	Figure 1: Original ABNF from RFC 8610 for Strings with Permissive		Figure 1: Original ABNF from RFC 8610 for Strings with Permissive
	ABNF for SESC (Which Did Not Allow Hex Escapes)		ABNF for SESC (Which Did Not Allow Hex Escapes)
	This allows almost any non-C0 character to be escaped by a backslash,		This allows almost any non-C0 character to be escaped by a backslash,
	but critically misses out on the \uXXXX and \uHHHH\uLLLL forms that		but critically misses out on the \uXXXX and \uHHHH\uLLLL forms that
	JSON allows to specify characters in hex (which should be applied		JSON allows to specify characters in hex (which should apply here
	here according to item 6 of Section 3.1 of [RFC8610]). (Note that		according to item 6 of Section 3.1 of [RFC8610]). (Note that CDDL
	CDDL imports from JSON the unwieldy \uHHHH\uLLLL syntax, which		imports from JSON the unwieldy \uHHHH\uLLLL syntax, which represents
	represents Unicode code points beyond U+FFFF by making them look like		Unicode code points beyond U+FFFF by making them look like UTF-16
	UTF-16 surrogate pairs; CDDL text strings do not use UTF-16 or		surrogate pairs; CDDL text strings do not use UTF-16 or surrogates.)
	surrogates.)
	Both can be solved by updating the SESC rule. This document uses the		Both can be solved by updating the SESC rule. This document uses the
	opportunity to add a popular form of directly specifying characters		opportunity to add a popular form of directly specifying characters
	in strings using hexadecimal escape sequences of the form \u{hex},		in strings using hexadecimal escape sequences of the form \u{hex},
	where hex is the hexadecimal representation of the Unicode scalar		where hex is the hexadecimal representation of the Unicode scalar
	value. The result is the new set of rules defining SESC in Figure 2.		value. The result is the new set of rules defining SESC in Figure 2.
	; new rules collectively defining SESC:		; new rules collectively defining SESC:
	SESC = "\" ( %x22 / "/" / "\" / ; \" \/ \\		SESC = "\" ( %x22 / "/" / "\" / ; \" \/ \\
	%x62 / %x66 / %x6E / %x72 / %x74 / ; \b \f \n \r \t		%x62 / %x66 / %x6E / %x72 / %x74 / ; \b \f \n \r \t
	skipping to change at line 162 ¶		skipping to change at line 161 ¶
	hexscalar = "10" 4HEXDIG / HEXDIG1 4HEXDIG		hexscalar = "10" 4HEXDIG / HEXDIG1 4HEXDIG
	/ non-surrogate / 1*3HEXDIG		/ non-surrogate / 1*3HEXDIG
	HEXDIG1 = DIGIT1 / "A" / "B" / "C" / "D" / "E" / "F"		HEXDIG1 = DIGIT1 / "A" / "B" / "C" / "D" / "E" / "F"
	Figure 2: Update to String ABNF in Appendix B of [RFC8610]: Allow		Figure 2: Update to String ABNF in Appendix B of [RFC8610]: Allow
	Hex Escapes		Hex Escapes
	| Notes: In ABNF, strings such as "A", "B", etc., are case		| Notes: In ABNF, strings such as "A", "B", etc., are case
	| insensitive, as is intended here. The rules above could have		| insensitive, as is intended here. The rules above could have
	| also used %s"b", etc., instead of %x62, but didn't, in order to		| also used %s"b", etc., instead of %x62, but didn't, in order to
	| maximize compatibility of ABNF tools.		| maximize compatibility with ABNF tools.
	Now that SESC is more restrictively formulated, an update to the		Now that SESC is more restrictively formulated, an update to the
	BCHAR rule used in the ABNF syntax for byte string literals is also		BCHAR rule used in the ABNF syntax for byte string literals is also
	required:		required:
	; ABNF from RFC 8610:		; ABNF from RFC 8610:
	bytes = [bsqual] %x27 *BCHAR %x27		bytes = [bsqual] %x27 *BCHAR %x27
	BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF		BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
	bsqual = "h" / "b64"		bsqual = "h" / "b64"
	skipping to change at line 312 ¶		skipping to change at line 311 ¶
	The existing ABNF syntax for expressing tags in CDDL is as follows:		The existing ABNF syntax for expressing tags in CDDL is as follows:
	; extracted from the ABNF in RFC 8610:		; extracted from the ABNF in RFC 8610:
	type2 =/ "#" "6" ["." uint] "(" S type S ")"		type2 =/ "#" "6" ["." uint] "(" S type S ")"
	Figure 9: Original ABNF from RFC 8610 for Tag Syntax		Figure 9: Original ABNF from RFC 8610 for Tag Syntax
	This means tag numbers can only be given as literal numbers (uints).		This means tag numbers can only be given as literal numbers (uints).
	Some specifications operate on ranges of tag numbers; for example,		Some specifications operate on ranges of tag numbers; for example,
	[RFC9277] has a range of tag numbers 1668546817 (0x63740101) to		[RFC9277] has a range of tag numbers 1668546817 (0x63740101) to
	1668612095 (0x6374FFFF) to tag specific content formats. This can		1668612095 (0x6374FFFF) to tag specific content formats. This cannot
	currently not be expressed in CDDL. Similar considerations apply to		currently be expressed in CDDL. Similar considerations apply to
	simple values (#7.xx).		simple values (#7.xx).
	This update extends the syntax to the following:		This update extends the syntax to the following:
	; new rules collectively defining the tagged case:		; new rules collectively defining the tagged case:
	type2 =/ "#" "6" ["." head-number] "(" S type S ")"		type2 =/ "#" "6" ["." head-number] "(" S type S ")"
	/ "#" "7" ["." head-number]		/ "#" "7" ["." head-number]
	head-number = uint / ("<" type ">")		head-number = uint / ("<" type ">")
	Figure 10: Update to Tag and Simple Value ABNF in Appendices B		Figure 10: Update to Tag and Simple Value ABNF in Appendices B
	skipping to change at line 373 ¶		skipping to change at line 372 ¶
	The grammar fixes and updates in this document are not believed to		The grammar fixes and updates in this document are not believed to
	create additional security considerations. The security		create additional security considerations. The security
	considerations in Section 5 of [RFC8610] apply. Specifically, the		considerations in Section 5 of [RFC8610] apply. Specifically, the
	potential for confusion is increased in an environment that uses a		potential for confusion is increased in an environment that uses a
	combination of CDDL tools, some of which have been updated and some		combination of CDDL tools, some of which have been updated and some
	of which have not, in particular based on Section 2.		of which have not, in particular based on Section 2.
	Attackers may want to exploit such potential confusion by crafting		Attackers may want to exploit such potential confusion by crafting
	CDDL models that are interpreted differently by different parts of a		CDDL models that are interpreted differently by different parts of a
	system. There will be a period of transition from the details that		system. There will be a period of transition from the details that
	the grammar in [RFC8610] handled in a less-well-defined way, to the		the grammar in [RFC8610] handled in a less well-defined way, to the
	updated grammar defined in the present document. This transition		updated grammar defined in the present document. This transition
	might offer one (but not the only) type of opportunity for the kind		might offer one (but not the only) type of opportunity for the kind
	of attack that relies on differences between implementations.		of attack that relies on differences between implementations.
	Implementations that make use of CDDL models operationally already		Implementations that make use of CDDL models operationally already
	need to ascertain the provenance (and thus authenticity and		need to ascertain the provenance (and thus authenticity and
	integrity) and applicability of models they employ. At the time of		integrity) and applicability of models they employ. At the time of
	writing, it is expected that the models will generally be processed		writing, it is expected that the models will generally be processed
	by a software developer, within a software-development environment.		by a software developer, within a software development environment.
	Therefore, developers are advised to treat CDDL models with the same		Therefore, developers are advised to treat CDDL models with the same
	care as any other source code.		care as any other source code.
	5. IANA Considerations		5. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	skipping to change at line 667 ¶		skipping to change at line 666 ¶
	processing the syntax of the bytes and BCHAR rules, as updated by		processing the syntax of the bytes and BCHAR rules, as updated by
	Figures 2 and 4 in Section 2.1 (updates prompted by the combination		Figures 2 and 4 in Section 2.1 (updates prompted by the combination
	of [Err6527] and [Err6278]).		of [Err6527] and [Err6278]).
	Therefore, the rules in Figure 14 (as updated by Figure 4) are		Therefore, the rules in Figure 14 (as updated by Figure 4) are
	applied to the result of this processing where bsqual is given as h		applied to the result of this processing where bsqual is given as h
	or b64.		or b64.
	Note that this approach also works well with the use of byte strings		Note that this approach also works well with the use of byte strings
	in Section 3 of [RFC9165]. It does require some care when copying-		in Section 3 of [RFC9165]. It does require some care when copying-
	and-pasting into CDDL models from ABNF that contain single quotes		and-pasting into CDDL models from ABNF that contains single quotes
	(which may also hide as apostrophes in comments); these need to be		(which may also hide as apostrophes in comments); these need to be
	escaped or possibly replaced by %x27.		escaped or possibly replaced by %x27.
	Finally, the approach taken lends support to extending bsqual in CDDL		Finally, the approach taken lends support to extending bsqual in CDDL
	similar to the way this is done for CBOR diagnostic notation in		similar to the way this is done for CBOR diagnostic notation in
	[EDN-LITERALS]. (Note that, at the time of writing, the processing		[EDN-LITERALS]. (Note that, at the time of writing, the processing
	of string literals is quite similar for both CDDL and Extended		of string literals is quite similar for both CDDL and Extended
	Diagnostic Notation (EDN), except that CDDL has end-of-line comments		Diagnostic Notation (EDN), except that CDDL has end-of-line comments
	that are ";" based and EDN has two comment syntaxes: those that are		that are ";" based and EDN has two comment syntaxes: one in-line "/"
	in-line "/" based and those that are end-of-line "#" based.)		based and one end-of-line "#" based.)
	Acknowledgments		Acknowledgments
	Many thanks go to the submitters of the errata reports addressed in		Many thanks go to the submitters of the errata reports addressed in
	this document. In one of the ensuing discussions, Doug Ewell		this document. In one of the ensuing discussions, Doug Ewell
	proposed defining an ABNF rule "NONASCII", of which we have included		proposed defining an ABNF rule "NONASCII", of which we have included
	the essence. Special thanks to the reviewers Marco Tiloca, Christian		the essence. Special thanks to the reviewers Marco Tiloca, Christian
	Amsüss ( Shepherd Review and further guidance), Orie Steele (AD		Amsüss (Shepherd Review and further guidance), Orie Steele (AD Review
	Review and further guidance), and Éric Vyncke (detailed IESG review).		and further guidance), and Éric Vyncke (detailed IESG review).
	Author's Address		Author's Address
	Carsten Bormann		Carsten Bormann
	Universität Bremen TZI		Universität Bremen TZI
	Postfach 330440		Postfach 330440
	D-28359 Bremen		D-28359 Bremen
	Germany		Germany
	Phone: +49-421-218-63921		Phone: +49-421-218-63921
	Email: cabo@tzi.org		Email: cabo@tzi.org
End of changes. 11 change blocks.
	20 lines changed or deleted		19 lines changed or added
This html diff was produced by rfcdiff 1.48.