rfc9277v2.txt		rfc9277.txt
	skipping to change at line 13 ¶		skipping to change at line 13 ¶
	Request for Comments: 9277 Sandelman Software Works		Request for Comments: 9277 Sandelman Software Works
	Category: Standards Track C. Bormann		Category: Standards Track C. Bormann
	ISSN: 2070-1721 Universität Bremen TZI		ISSN: 2070-1721 Universität Bremen TZI
	August 2022		August 2022
	On Stable Storage for Items in Concise Binary Object Representation		On Stable Storage for Items in Concise Binary Object Representation
	(CBOR)		(CBOR)
	Abstract		Abstract
	This document defines a stored ("file") format for Consice Binary		This document defines a stored ("file") format for Concise Binary
	Object Representation (CBOR) data items that is friendly to common		Object Representation (CBOR) data items that is friendly to common
	systems that recognize file types, such as the Unix file(1) command.		systems that recognize file types, such as the Unix file(1) command.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	skipping to change at line 72 ¶		skipping to change at line 72 ¶
	5. References		5. References
	5.1. Normative References		5.1. Normative References
	5.2. Informative References		5.2. Informative References
	Appendix A. Advice to Protocol Designer		Appendix A. Advice to Protocol Designer
	A.1. Is the on-wire format new?		A.1. Is the on-wire format new?
	A.2. Can many items be trivially concatenated?		A.2. Can many items be trivially concatenated?
	A.3. Are there tags at the start?		A.3. Are there tags at the start?
	Appendix B. CBOR Tags for CoAP Content Formats		Appendix B. CBOR Tags for CoAP Content Formats
	B.1. Content-Format Tag Examples		B.1. Content-Format Tag Examples
	Appendix C. Example from Openswan		Appendix C. Example from Openswan
	Appendix D. Using CBOR Labels for Non-CBOR data		Appendix D. Using CBOR Labels for Non-CBOR Data
	D.1. Content-Format Tag Examples		D.1. Content-Format Tag Examples
	Acknowledgements		Acknowledgements
	Contributors		Contributors
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	Since very early in computing, operating systems have sought ways to		Since very early in computing, operating systems have sought ways to
	mark which files could be processed by which programs. In Unix,		mark which files could be processed by which programs. In Unix,
	everything is a stream of bytes; identifying the contents of a stream		everything is a stream of bytes; identifying the contents of a stream
	of bytes became a heuristic activity.		of bytes became a heuristic activity.
	For instance, the Unix file(1) command, which has existed since 1973		For instance, the Unix file(1) command, which has existed since 1973
	[FILE], has been able to identify many file formats based upon the		[FILE], has been able to identify many file formats based upon the
	contents of the file for decades.		contents of the file for decades.
	Many systems (Linux, macOS, Windows) will select the correct		Many systems (Linux, macOS, Windows) will select the correct
	application based upon the file contents if the system cannot		application based upon the file contents if the system cannot
	determine it by other means. For instance, in classical macOS, a		determine it by other means. For instance, in classical Mac OS, a
	resource fork was maintained separately from the file data that		resource fork was maintained separately from the file data that
	included file type information; this way, the OS ideally never needed		included file type information; this way, the OS ideally never needed
	to know anything about the file data contents to determine the media		to know anything about the file data contents to determine the media
	type.		type.
	Many other systems do this by using file extensions. Many common Web		Many other systems do this by using file extensions. Many common Web
	servers derive the media-type information from file extensions.		servers derive the media-type information from file extensions.
	Having a media type associated with the file contents can avoid some		Having a media type associated with the file contents can avoid some
	of the brittleness of this approach. When files become disconnected		of the brittleness of this approach. When files become disconnected
	from their type information, such as when attempting to do forensics		from their type information, such as when attempting to do forensics
	on a damaged system, being able to identify the type of information		on a damaged system, being able to identify the type of information
	stored in a file can become very important.		stored in a file can become very important.
	A common way to identify the type of a file from its contents is to		A common way to identify the type of a file from its contents is to
	place a "magic number" at the start of the file contents [MAGIC]. In		place a "magic number" at the start of the file contents [MAGIC]. In
	the media type registration template [RFC6838], it is noted that a		the media type registration template [RFC6838], a magic number is
	magic number is asked for, if available, as is a file extension.		asked for, if available, as is a file extension.
	A challenge for the file(1) command is often that it can be confused		A challenge for the file(1) command is often that it can be confused
	by recognizing the overall encoding but not the content being		by recognizing the overall encoding but not the content being
	encoded. For instance, an Android APK (as used to transfer and store		encoded. For instance, an Android APK (as used to transfer and store
	an application) may be identified as a ZIP file. Additionally, both		an application) may be identified as a ZIP file. Additionally, both
	OpenOffice and MSOffice files are ZIP files of XML files; the		OpenOffice and MSOffice files are ZIP files of XML files; the
	identification may stop at identifying them as ZIP files.		identification may stop at identifying them as ZIP files.
	As CBOR becomes a more and more common encoding for a wide variety of		As CBOR becomes a more and more common encoding for a wide variety of
	artifacts, identifying them as just "CBOR" is probably not		artifacts, identifying them as just "CBOR" is probably not
	skipping to change at line 131 ¶		skipping to change at line 131 ¶
	into the beginning of a CBOR format file. As a CBOR format may use a		into the beginning of a CBOR format file. As a CBOR format may use a
	single CBOR data item or a CBOR sequence of data items [RFC8742], two		single CBOR data item or a CBOR sequence of data items [RFC8742], two
	possible methods of enveloping data are presented; a CBOR Protocol		possible methods of enveloping data are presented; a CBOR Protocol
	designer will specify one. (A CBOR Protocol is a specification that		designer will specify one. (A CBOR Protocol is a specification that
	uses CBOR as its encoding.)		uses CBOR as its encoding.)
	This document also gives advice to designers of CBOR Protocols on		This document also gives advice to designers of CBOR Protocols on
	choosing one of these mechanisms for identifying their contents.		choosing one of these mechanisms for identifying their contents.
	This advice is informative.		This advice is informative.
	A third method is also proposed by which this CBOR format tag is		A third method is also proposed by which a CBOR format tag is
	prepended to identify non-CBOR files. Further information on this		prepended to identify non-CBOR files. Further information on this
	method appears in Appendix D because it is not about identifying		method appears in Appendix D because it is not about identifying
	media types containing CBOR-encoded data items. This includes a		media types containing CBOR-encoded data items. This includes a
	simple way to derive a magic number for content-formats as defined in		simple way to derive a magic number for content-formats as defined in
	[RFC7252], even if the file is not in CBOR form.		[RFC7252], even if the file is not in CBOR form.
	Examples of CBOR Protocols currently under development include		Examples of CBOR Protocols currently under development include
	Concise Software Identification Tags [CoSWID] and Entity Attestation		Concise Software Identification Tags [CoSWID] and Entity Attestation
	Tokens [EAT]. CBOR Object Signing and Encryption (COSE) itself		Tokens [EAT]. CBOR Object Signing and Encryption (COSE) itself
	[RFC8152] is considered infrastructure. The encoding of public keys		[RFC8152] is considered infrastructure. The encoding of public keys
	skipping to change at line 342 ¶		skipping to change at line 342 ¶
	the first item with the two tags.		the first item with the two tags.
	Should this file be reviewed by a human (directly in an editor or in		Should this file be reviewed by a human (directly in an editor or in
	a hexdump display), it will include the ASCII characters "CBOR"		a hexdump display), it will include the ASCII characters "CBOR"
	prominently. This value is also included simply because the inner		prominently. This value is also included simply because the inner
	nested tag needs to tag something.		nested tag needs to tag something.
	2.3.1. Example		2.3.1. Example
	To construct an example without registering a new tag, we use ID 272		To construct an example without registering a new tag, we use ID 272
	as assigned for application/missing-blocks+cbor-seq of the "CAP		as assigned for application/missing-blocks+cbor-seq of the "CoAP
	Content-Formats" registry [RFC9177].		Content-Formats" registry [RFC9177].
	Using the technique described in Appendix B, this translates into the		Using the technique described in Appendix B, this translates into the
	tag TN(272) = 1668574090.		tag TN(272) = 1668547090.
	This is a somewhat contrived example, as this is not a media type		This is a somewhat contrived example, as this is not a media type
	that is likely to be committed to storage. Nonetheless, with this		that is likely to be committed to storage. Nonetheless, with this
	tag, missing blocks list 0, 8, 15 would be enveloped as (in		tag, missing blocks list 0, 8, 15 would be enveloped as (in
	diagnostic notation):		diagnostic notation):
	55800(1668574090('BOR')),		55800(1668547090('BOR')),
	0,		0,
	8,		8,
	15		15
	Or in hex:		Or in hex:
	# CBOR sequence with 4 elements		# CBOR sequence with 4 elements
	d9 d9f8 # tag(55800)		d9 d9f8 # tag(55800)
	da 63740212 # tag(1668574090)		da 63740212 # tag(1668547090)
	43 # bytes(3)		43 # bytes(3)
	424f52 # "BOR"		424f52 # "BOR"
	00 # unsigned(0)		00 # unsigned(0)
	08 # unsigned(8)		08 # unsigned(8)
	0f # unsigned(15)		0f # unsigned(15)
	At the representation level, the unique fingerprint for application/		At the representation level, the unique fingerprint for application/
	missing-blocks+cbor-seq is composed of the 8 bytes d9d9f8da63740212		missing-blocks+cbor-seq is composed of the 8 bytes d9d9f8da63740212
	hex, after which the unadorned CBOR sequence (00... for the missing		hex, after which the unadorned CBOR sequence (00... for the missing
	block list given) is appended.		block list given) is appended.
	skipping to change at line 386 ¶		skipping to change at line 386 ¶
	This document provides a way to identify CBOR Protocol objects.		This document provides a way to identify CBOR Protocol objects.
	Clearly identifying CBOR contents in files may have a variety of		Clearly identifying CBOR contents in files may have a variety of
	impacts.		impacts.
	The most obvious is that it may allow malware to identify interesting		The most obvious is that it may allow malware to identify interesting
	stored objects, and then exfiltrate or corrupt them.		stored objects, and then exfiltrate or corrupt them.
	Protective applications (that check data) cannot rely on the		Protective applications (that check data) cannot rely on the
	applications they try to protect (that use the data) to make exactly		applications they try to protect (that use the data) to make exactly
	the same decisions in recognizing file formats. (This is an instance		the same decisions in recognizing file formats. (This is an instance
	of a check versus a use issue.) For example, end-point assessment		of a check versus use issue.) For example, end-point assessment
	technologies should not solely rely on the labeling approaches		technologies should not solely rely on the labeling approaches
	described in this document to decide whether to inspect a given file.		described in this document to decide whether to inspect a given file.
	Similarly, depending on operating system configurations and related		Similarly, depending on operating system configurations and related
	properties of the execution environment, the labeling might influence		properties of the execution environment, the labeling might influence
	the default application used to process a file in a way that may not		the default application used to process a file in a way that may not
	be predicted by a protective application.		be predicted by a protective application.
	4. IANA Considerations		4. IANA Considerations
	These IANA considerations are entirely about CBOR tags in the		These IANA considerations are entirely about CBOR tags in the
	"Concise Binary Object Representation (CBOR) Tags" registry		"Concise Binary Object Representation (CBOR) Tags" registry
	[IANA.CBOR-TAGS].		[IANA.CBOR-TAGS].
	Section 4.1 documents the allocation for a CBOR tag to be used in a		Section 4.1 documents the allocation for a CBOR tag to be used in a
	CBOR sequence to identify the sequence (an example for using this tag		CBOR sequence to identify the sequence (an example for using this tag
	is found in Appendix C). Section 4.3 allocates a CBOR tag for each		is found in Appendix C). Section 4.2 documents the allocation for a
	actual or potential CoAP Content-Format number (examples are in		CBOR tag to be used in the CBOR-Labeled Non-CBOR Data Enveloping
	Appendix B).		Method (Appendix D, which also shows examples). Section 4.3
			allocates a CBOR tag for each actual or potential CoAP Content-Format
			number (examples are in Appendix B).
	4.1. Labeled CBOR Sequence Tag		4.1. Labeled CBOR Sequence Tag
	IANA has allocated tag 55800 for the Labeled CBOR Sequence Enveloping		IANA has allocated tag 55800 for the Labeled CBOR Sequence Enveloping
	Method from the "CBOR Tags" registry. IANA has updated this tag		Method from the "CBOR Tags" registry. IANA has updated this tag
	registration to point to this document.		registration to point to this document.
	This tag is from the First Come First Served area.		This tag is from the First Come First Served area.
	The value has been picked to have properties similar to the 55799 tag		The value has been picked to have properties similar to the 55799 tag
	skipping to change at line 593 ¶		skipping to change at line 595 ¶
	Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,		Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,
	DOI 10.17487/RFC8428, August 2018,		DOI 10.17487/RFC8428, August 2018,
	<https://www.rfc-editor.org/info/rfc8428>.		<https://www.rfc-editor.org/info/rfc8428>.
	[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/info/rfc8610>.		June 2019, <https://www.rfc-editor.org/info/rfc8610>.
			[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
			Ed., "HTTP Semantics", STD 97, RFC 9110,
			DOI 10.17487/RFC9110, June 2022,
			<https://www.rfc-editor.org/info/rfc9110>.
	[RFC9177] Boucadair, M. and J. Shallow, "Constrained Application		[RFC9177] Boucadair, M. and J. Shallow, "Constrained Application
	Protocol (CoAP) Block-Wise Transfer Options Supporting		Protocol (CoAP) Block-Wise Transfer Options Supporting
	Robust Transmission", RFC 9177, DOI 10.17487/RFC9177,		Robust Transmission", RFC 9177, DOI 10.17487/RFC9177,
	March 2022, <https://www.rfc-editor.org/info/rfc9177>.		March 2022, <https://www.rfc-editor.org/info/rfc9177>.
	[X.690] ITU-T, "Information technology - ASN.1 encoding rules:		[X.690] ITU-T, "Information technology - ASN.1 encoding rules:
	Specification of Basic Encoding Rules (BER), Canonical		Specification of Basic Encoding Rules (BER), Canonical
	Encoding Rules (CER) and Distinguished Encoding Rules		Encoding Rules (CER) and Distinguished Encoding Rules
	(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1,		(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1,
	February 2021, <https://www.itu.int/rec/T-REC-X.690>.		February 2021, <https://www.itu.int/rec/T-REC-X.690>.
	skipping to change at line 686 ¶		skipping to change at line 693 ¶
	If the 8 bytes are a problem on the wire (and they often are if CBOR		If the 8 bytes are a problem on the wire (and they often are if CBOR
	is being considered), then the Labeled CBOR Sequence format should be		is being considered), then the Labeled CBOR Sequence format should be
	adopted for the stored format.		adopted for the stored format.
	A.2. Can many items be trivially concatenated?		A.2. Can many items be trivially concatenated?
	If the programs that read the contents of the file already expect to		If the programs that read the contents of the file already expect to
	process all of the CBOR data items in the file (not just the first),		process all of the CBOR data items in the file (not just the first),
	then the Labeled CBOR Sequence format may be easily retrofitted.		then the Labeled CBOR Sequence format may be easily retrofitted.
	The program involved may throw errors or warnings on the Labeled CBOR		The programs involved may throw errors or warnings on the Labeled
	Sequence if they have not yet been updated, but this may not be a		CBOR Sequence if they have not yet been updated, but this may not be
	problem.		a problem.
	There are situations where multiple objects may be concatenated into		There are situations where multiple objects may be concatenated into
	a single file. If each object is preceded by a Labeled CBOR Sequence		a single file. If each object is preceded by a Labeled CBOR Sequence
	label, then there may be multiple such labels in the file.		label, then there may be multiple such labels in the file.
	A protocol based on CBOR Sequences may specify that Labeled CBOR		A protocol based on CBOR Sequences may specify that Labeled CBOR
	Sequence labels can occur within a CBOR Sequence, possibly even to		Sequence labels can occur within a CBOR Sequence, possibly even to
	switch to data items following in the sequence that are of a		switch to data items following in the sequence that are of a
	different type.		different type.
	skipping to change at line 733 ¶		skipping to change at line 740 ¶
	If the Protocol expects to use other tags at its top level, then the		If the Protocol expects to use other tags at its top level, then the
	use of the CBOR Tag Wrapped format may be easy to explain at the same		use of the CBOR Tag Wrapped format may be easy to explain at the same
	place in the protocol description.		place in the protocol description.
	Appendix B. CBOR Tags for CoAP Content Formats		Appendix B. CBOR Tags for CoAP Content Formats
	Section 5.10.3 of [RFC7252] defines the concept of a Content-Format,		Section 5.10.3 of [RFC7252] defines the concept of a Content-Format,
	which is a short, 16-bit unsigned integer that identifies a specific		which is a short, 16-bit unsigned integer that identifies a specific
	content type (media type plus (optionally) parameters), optionally		content type (media type plus (optionally) parameters), optionally
	together with a content encoding.		together with a content coding (see Section 8.4.1 of [RFC9110]).
	Outside of a transfer protocol that indicates the Content-Format for		Outside of a transfer protocol that indicates the Content-Format for
	a representation, it may be necessary to identify the Content-Format		a representation, it may be necessary to identify the Content-Format
	of the representation when it is stored in a file, in firmware, or		of the representation when it is stored in a file, in firmware, or
	when debugging.		when debugging.
	This specification allocates CBOR tag numbers 1668546817 (0x63740101)		This specification allocates CBOR tag numbers 1668546817 (0x63740101)
	to 1668612095 (0x6374FFFF) for the tagging of representations of		to 1668612095 (0x6374FFFF) for the tagging of representations of
	specific content formats.		specific content formats.
	skipping to change at line 781 ¶		skipping to change at line 788 ¶
	string wrapping). This only works for Content-Formats that		string wrapping). This only works for Content-Formats that
	are represented by a single CBOR data item in identity		are represented by a single CBOR data item in identity
	content-coding.		content-coding.
	2. The data items in the CBOR sequence within the representation,		2. The data items in the CBOR sequence within the representation,
	without byte string wrapping, but wrapped in a CBOR array.		without byte string wrapping, but wrapped in a CBOR array.
	This works for Content-Formats that are represented by a CBOR		This works for Content-Formats that are represented by a CBOR
	sequence in identity content-coding.		sequence in identity content-coding.
	Tags 55800 (Section 2.3) or 55801 (Appendix D): the byte string		Tags 55800 (Section 2.3) or 55801 (Appendix D): the byte string
	"BOR", signifying that the representation of the given content-		'BOR', signifying that the representation of the given content-
	format follows in the file, in the way defined for these tags.		format follows in the file, in the way defined for these tags.
	B.1. Content-Format Tag Examples		B.1. Content-Format Tag Examples
	The "CoAP Content-Formats" registry [IANA.CORE-PARAMETERS] defines		The "CoAP Content-Formats" registry [IANA.CORE-PARAMETERS] defines
	content formats that can be used as examples:		content formats that can be used as examples:
	* As discussed in Section 2.2.1, Content-Format ID 112 represents		* As discussed in Section 2.2.1, Content-Format ID 112 represents
	the application/senml+cbor media type (no parameters). The		the application/senml+cbor media type (no parameters). The
	corresponding tag number is TN(112) = 1668546929.		corresponding tag number is TN(112) = 1668546929.
	skipping to change at line 805 ¶		skipping to change at line 812 ¶
	senml-cbor = #6.1668546929(bstr)		senml-cbor = #6.1668546929(bstr)
	Note that a byte string is used as the type of the tag content		Note that a byte string is used as the type of the tag content
	because a media type representation in general can be any byte		because a media type representation in general can be any byte
	string.		string.
	* Content-Format ID 272 represents the application/missing-		* Content-Format ID 272 represents the application/missing-
	blocks+cbor-seq media type, which is a CBOR sequence [RFC9177].		blocks+cbor-seq media type, which is a CBOR sequence [RFC9177].
	The corresponding tag number is TN(272) = 1668574090.		The corresponding tag number is TN(272) = 1668547090.
	The following CDDL snippet can be used to identify application/		The following CDDL snippet can be used to identify application/
	missing-blocks+cbor-seq representations as embedded in a CBOR byte		missing-blocks+cbor-seq representations as embedded in a CBOR byte
	string:		string:
	missing-blocks = #6.1668574090(bstr)		missing-blocks = #6.1668547090(bstr)
	Appendix C. Example from Openswan		Appendix C. Example from Openswan
	The Openswan IPsec project has a daemon ("pluto") and two control		The Openswan IPsec project has a daemon ("pluto") and two control
	programs ("addconn" and "whack"). They communicate via a Unix-domain		programs ("addconn" and "whack"). They communicate via a Unix-domain
	socket, over which a C-structure containing pointers to strings is		socket, over which a C-structure containing pointers to strings is
	serialized using a bespoke mechanism. This is normally not a problem		serialized using a bespoke mechanism. This is normally not a problem
	as the structure is compiled by the same compiler; but when there are		as the structure is compiled by the same compiler; but when there are
	upgrades, it is possible for the daemon and the control programs to		upgrades, it is possible for the daemon and the control programs to
	get out of sync by the bespoke serialization. As a result, there are		get out of sync by the bespoke serialization. As a result, there are
	skipping to change at line 852 ¶		skipping to change at line 859 ¶
	55800(1330664270(h'424F52'))		55800(1330664270(h'424F52'))
	Or in hex:		Or in hex:
	d9 d9f8 # tag(55800)		d9 d9f8 # tag(55800)
	da 4f50534e # tag(1330664270)		da 4f50534e # tag(1330664270)
	43 # bytes(3)		43 # bytes(3)
	424f52 # "BOR"		424f52 # "BOR"
	Appendix D. Using CBOR Labels for Non-CBOR data		Appendix D. Using CBOR Labels for Non-CBOR Data
	The CBOR-Labeled Non-CBOR data method is appropriate for adding a		The CBOR-Labeled Non-CBOR data method is appropriate for adding a
	magic number to a Non-CBOR data format, particularly one that can be		magic number to a Non-CBOR data format, particularly one that can be
	described by a Content-Format tag (Appendix B).		described by a Content-Format tag (Appendix B).
	This method prepends a CBOR data item to the Non-CBOR data; this data		This method prepends a CBOR data item to the Non-CBOR data; this data
	item is called the "header" and, similar to the Labeled CBOR-Sequence		item is called the "header" and, similar to the Labeled CBOR-Sequence
	label, consists of two nested tags around a constant byte string for		label, consists of two nested tags around a constant byte string for
	a total of 12 bytes.		a total of 12 bytes.
	1. The outer tag is the CBOR-Labeled Non-CBOR Data tag, 55801.		1. The outer tag is the CBOR-Labeled Non-CBOR Data tag, 55801.
	2. The inner tag is a CBOR tag from the First Come First Served		2. The inner tag is a CBOR tag from the First Come First Served
	space that uniquely identifies the CBOR Protocol. As with CBOR		space that uniquely identifies the CBOR Protocol. As with CBOR
	Tag Wrapped, the use of a 4-byte tag is encouraged that encodes		Tag Wrapped, the use of a 4-byte tag is encouraged that encodes
	without zero bytes.		without zero bytes.
	3. The tag content is a 3-byte CBOR byte string containing		3. The tag content is a 3-byte CBOR byte string containing
	0x42_4F_52 ("BOR" in diagnostic notation).		0x42_4F_52 ('BOR' in diagnostic notation).
	The outer tag in the label identifies the file as being prefixed by a		The outer tag in the label identifies the file as being prefixed by a
	Non-CBOR data label and does so with all the desirable properties		Non-CBOR data label and does so with all the desirable properties
	explained in Section 3.4.6 of [STD94]. Specifically, it does not		explained in Section 3.4.6 of [STD94]. Specifically, it does not
	appear to conflict with any known file types, and it is not valid		appear to conflict with any known file types, and it is not valid
	Unicode in any Unicode encoding.		Unicode in any Unicode encoding.
	The inner tag in the label identifies which Non-CBOR Protocol is		The inner tag in the label identifies which Non-CBOR Protocol is
	used.		used.
	The inner tag content is a constant byte string that is represented		The inner tag content is a constant byte string that is represented
	as 0x43_42_4f_52, the ASCII characters "CBOR", which is the CBOR-		as 0x43_42_4f_52, the ASCII characters "CBOR", which is the CBOR-
	encoded data item for the 3-byte string 0x42_4f_52 ("BOR" in		encoded data item for the 3-byte string 0x42_4f_52 ('BOR' in
	diagnostic notation).		diagnostic notation).
	The actual Non-CBOR Protocol data then follow directly appended to		The actual Non-CBOR Protocol data then follow directly appended to
	the CBOR representation of the header. This allows the application		the CBOR representation of the header. This allows the application
	to trivially remove the header item with the two nested tags and the		to trivially remove the header item with the two nested tags and the
	byte string.		byte string.
	As with the Labeled CBOR Sequence {#sequences}, this choice of the		As with the Labeled CBOR Sequence {#sequences}, this choice of the
	tag content places the ASCII characters "CBOR" prominently into the		tag content places the ASCII characters "CBOR" prominently into the
	header.		header.
	D.1. Content-Format Tag Examples		D.1. Content-Format Tag Examples
	The "CoAP Content-Formats" registry [IANA.CORE-PARAMETERS] defines		The "CoAP Content-Formats" registry [IANA.CORE-PARAMETERS] defines
	content formats that can be used as examples:		content formats that can be used as examples:
	* Content-Format ID 432 represents the application/td+json media		* Content-Format ID 432 represents the application/td+json media
	type (no parameters).		type (no parameters).
	The corresponding tag number is TN(432) = 1668574250.		The corresponding tag number is TN(432) = 1668547250.
	The following CDDL snippet can be used to identify a CBOR-Labeled		The following CDDL snippet can be used to identify a CBOR-Labeled
	Non-CBOR data for application/td+json representations:		Non-CBOR data for application/td+json representations:
	td-json-header = #6.55801(#6.1668574250('BOR'))		td-json-header = #6.55801(#6.1668547250('BOR'))
	* Content-Format 11050 represents the application/json media type in		* Content-Format 11050 represents the application/json media type in
	deflate content-coding.		deflate content-coding.
	The corresponding tag number is TN(11050) = 1668557910.		The corresponding tag number is TN(11050) = 1668557910.
	The following CDDL snippet can be used to identify a CBOR-Labeled		The following CDDL snippet can be used to identify a CBOR-Labeled
	Non-CBOR data for application/json representations compressed in		Non-CBOR data for application/json representations compressed in
	deflate content-coding:		deflate content-coding:
End of changes. 22 change blocks.
	26 lines changed or deleted		33 lines changed or added
This html diff was produced by rfcdiff 1.48.