draft-ietf-cbor-packed-03.txt		draft-ietf-cbor-packed-04.txt
	Network Working Group C. Bormann		Network Working Group C. Bormann
	Internet-Draft Universität Bremen TZI		Internet-Draft Universität Bremen TZI
	Intended status: Informational 13 August 2021		Intended status: Informational 13 February 2022
	Expires: 14 February 2022		Expires: 17 August 2022
	Packed CBOR		Packed CBOR
	draft-ietf-cbor-packed-03		draft-ietf-cbor-packed-04
	Abstract		Abstract
	The Concise Binary Object Representation (CBOR, RFC 8949) is a data		The Concise Binary Object Representation (CBOR, RFC 8949) is a data
	format whose design goals include the possibility of extremely small		format whose design goals include the possibility of extremely small
	code size, fairly small message size, and extensibility without the		code size, fairly small message size, and extensibility without the
	need for version negotiation.		need for version negotiation.
	CBOR does not provide any forms of data compression. CBOR data		CBOR does not provide any forms of data compression. CBOR data
	items, in particular when generated from legacy data models often		items, in particular when generated from legacy data models often
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	This specification describes Packed CBOR, a simple transformation of		This specification describes Packed CBOR, a simple transformation of
	a CBOR data item into another CBOR data item that is almost as easy		a CBOR data item into another CBOR data item that is almost as easy
	to consume as the original CBOR data item. A separate decompression		to consume as the original CBOR data item. A separate decompression
	step is therefore often not required at the receiver.		step is therefore often not required at the receiver.
	Note to Readers		Note to Readers
	This is a working-group draft of the CBOR working group of the IETF,		This is a working-group draft of the CBOR working group of the IETF,
	https://datatracker.ietf.org/wg/cbor/about/		https://datatracker.ietf.org/wg/cbor/about/
	(https://datatracker.ietf.org/wg/cbor/about/). Discussion takes		(https://datatracker.ietf.org/wg/cbor/about/). Discussion takes
	places on the github repository https://github.com/cbor-wg/cbor-		places on the GitHub repository https://github.com/cbor-wg/cbor-
	packed (https://github.com/cbor-wg/cbor-packed) and on the CBOR WG		packed (https://github.com/cbor-wg/cbor-packed) and on the CBOR WG
	mailing list, https://www.ietf.org/mailman/listinfo/cbor		mailing list, https://www.ietf.org/mailman/listinfo/cbor
	(https://www.ietf.org/mailman/listinfo/cbor).		(https://www.ietf.org/mailman/listinfo/cbor).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 14 February 2022.		This Internet-Draft will expire on 17 August 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Revised BSD License text as
	as described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Packed CBOR . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Packed CBOR . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Packing Tables . . . . . . . . . . . . . . . . . . . . . 4		2.1. Packing Tables . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Referencing Shared Items . . . . . . . . . . . . . . . . 4		2.2. Referencing Shared Items . . . . . . . . . . . . . . . . 4
	2.3. Referencing Affix Items . . . . . . . . . . . . . . . . . 5		2.3. Referencing Affix Items . . . . . . . . . . . . . . . . . 5
	2.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7		2.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7
	skipping to change at page 3, line 38 ¶		skipping to change at page 3, line 38 ¶
	(Section 2) and setting up packing tables (Section 3).		(Section 2) and setting up packing tables (Section 3).
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Packed reference: A shared item reference or an affix reference		Packed reference: A shared item reference or an affix reference.
	Shared item reference: A reference to a shared item as defined in		Shared item reference: A reference to a shared item as defined in
	Section 2.2		Section 2.2.
	Affix reference: A reference that combines an affix item as defined		Affix reference: A reference that combines an affix item as defined
	in Section 2.3.		in Section 2.3.
	Affix: Prefix or suffix.		Affix: Prefix or suffix.
	Packing tables: The triple of a shared item table, a prefix table,		Packing tables: The triple of a shared item table, a prefix table,
	and a suffix table.		and a suffix table.
			Current set: The packing tables in effect at the data item under
			consideration.
	Expansion: The result of applying a packed reference in the context		Expansion: The result of applying a packed reference in the context
	of given Packing tables.		of given Packing tables.
	The definitions of [RFC8949] apply. The term "byte" is used in its		The definitions of [STD94] apply. Specifically: The term "byte" is
	now customary sense as a synonym for "octet". Where bit arithmetic		used in its now customary sense as a synonym for "octet"; "byte
	is explained, this document uses the notation familiar from the		strings" are CBOR data items carrying a sequence of zero or more
	programming language C (including C++14's 0bnnn binary literals),		(binary) bytes, while "text strings" are CBOR data items carrying a
	except that, in the plain text form of this document, the operator		sequence of zero or more Unicode code points, encoded in UTF-8
	"^" stands for exponentiation, and, in the HTML and PDF versions,		[STD63].
	subtraction and negation are rendered as a hyphen ("-", as are
	various dashes).		Where bit arithmetic is explained, this document uses the notation
			familiar from the programming language C (including C++14's 0bnnn
			binary literals), except that, in the plain text form of this
			document, the operator "^" stands for exponentiation, and, in the
			HTML and PDF versions, subtraction and negation are rendered as a
			hyphen ("-", as are various dashes).
	2. Packed CBOR		2. Packed CBOR
	This section describes the packing tables, their structure, and how		This section describes the packing tables, their structure, and how
	they are referenced.		they are referenced.
	2.1. Packing Tables		2.1. Packing Tables
	At any point within a data item making use of Packed CBOR, there is a		At any point within a data item making use of Packed CBOR, there is a
	Current Set of packing tables that applies.		Current Set of packing tables that applies.
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 44 ¶
	* Shared item table		* Shared item table
	* Prefix table		* Prefix table
	* Suffix table		* Suffix table
	Without any table setup, all these tables are empty arrays.		Without any table setup, all these tables are empty arrays.
	Table setup can cause these arrays to be non-empty, where the		Table setup can cause these arrays to be non-empty, where the
	elements are (potentially themselves packed) data items. Each of the		elements are (potentially themselves packed) data items. Each of the
	tables is indexed by an unsigned integer (starting from 0), which may		tables is indexed by an unsigned integer (starting from 0). Such an
	be computed from information in tags and their content as well as		index may be derived from information in tags and their content as
	from CBOR simple values.		well as from CBOR simple values.
	2.2. Referencing Shared Items		2.2. Referencing Shared Items
	Shared items are stored in the shared item table of the Current Set.		Shared items are stored in the shared item table of the Current Set.
	The shared data items are referenced by using the reference data		The shared data items are referenced by using the reference data
	items in Table 1. When reconstructing the original data item, such a		items in Table 1. When reconstructing the original data item, such a
	reference is replaced by the referenced data item, which is then		reference is replaced by the referenced data item, which is then
	recursively unpacked.		recursively unpacked.
	skipping to change at page 5, line 17 ¶		skipping to change at page 5, line 22 ¶
	+===========================+==============+		+===========================+==============+
	| Simple value 0-15 | 0-15 |		| Simple value 0-15 | 0-15 |
	+---------------------------+--------------+		+---------------------------+--------------+
	| Tag 6(unsigned integer N) | 16 + 2*N |		| Tag 6(unsigned integer N) | 16 + 2*N |
	+---------------------------+--------------+		+---------------------------+--------------+
	| Tag 6(negative integer N) | 16 - 2*N - 1 |		| Tag 6(negative integer N) | 16 - 2*N - 1 |
	+---------------------------+--------------+		+---------------------------+--------------+
	Table 1: Referencing Shared Values		Table 1: Referencing Shared Values
	As examples in CBOR diagnostic notation (Section 8 of [RFC8949]), the		As examples in CBOR diagnostic notation (Section 8 of [STD94]), the
	first 22 elements of the shared item table are referenced by		first 22 elements of the shared item table are referenced by
	"simple(0)", "simple(1)", ... "simple(15)", "6(0)", "6(-1)", "6(1)",		simple(0), simple(1), ... simple(15), 6(0), 6(-1), 6(1), 6(-2), 6(2),
	"6(-2)", "6(2)", "6(-3)". (The alternation between unsigned and		6(-3). (The alternation between unsigned and negative integers for
	negative integers for even/odd table index values makes systematic		even/odd table index values makes systematic use of shorter integer
	use of shorter integer encodings first.)		encodings first.)
	Taking into account the encoding of these referring data items, there		Taking into account the encoding of these referring data items, there
	are 16 one-byte references, 48 two-byte references, 512 three-byte		are 16 one-byte references, 48 two-byte references, 512 three-byte
	references, 131072 four-byte references, etc. As integers can grow		references, 131072 four-byte references, etc. As CBOR integers can
	to very large (or negative) values, there is no practical limit to		grow to very large (or negative) values, there is no practical limit
	how many shared items might be used in a Packed CBOR item.		to how many shared items might be used in a Packed CBOR item.
	Note that the semantics of Tag 6 depend on its content: An integer		Note that the semantics of Tag 6 depend on its content: An integer
	turns the tag into a shared item reference, a string or container		turns the tag into a shared item reference, a string or container
	(map or array) into a prefix reference (see Table 2).		(map or array) into a prefix reference (see Table 2).
	2.3. Referencing Affix Items		2.3. Referencing Affix Items
	Prefix items are stored in the prefix table of the Current Set;		Prefix items are stored in the prefix table of the Current Set;
	suffix items are stored in the suffix table of the Current Set. We		suffix items are stored in the suffix table of the Current Set. We
	collectively call these items affix items; when referencing, which of		collectively call these items affix items; when referencing, which of
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 5 ¶
	* For a rump of type array and map, the affix also needs to be an		* For a rump of type array and map, the affix also needs to be an
	array or a map. For an array, the elements from the prefix are		array or a map. For an array, the elements from the prefix are
	prepended, and the elements from a suffix are appended to the rump		prepended, and the elements from a suffix are appended to the rump
	array. For a map, the entries in the affix are added to those of		array. For a map, the entries in the affix are added to those of
	the rump; prefix and suffix references differ in how entries with		the rump; prefix and suffix references differ in how entries with
	identical keys are combined: for prefix references, an entry in		identical keys are combined: for prefix references, an entry in
	the rump with the same key as an entry in the affix overrides the		the rump with the same key as an entry in the affix overrides the
	one in the affix, while for suffix references, an entry in the		one in the affix, while for suffix references, an entry in the
	affix overrides an entry in the rump that has the same key.		affix overrides an entry in the rump that has the same key.
	| ISSUE: Not sure that we want to use the efficiencies of		| NOTE: Not sure that we want to use the efficiencies of
	| overriding, but having default values supplied out of a		| overriding, but having default values supplied out of a
	| dictionary to be overridden by a rump sounds rather handy.		| dictionary to be overridden by a rump sounds rather handy.
	| Note that there is no way to remove a map entry from the table.		| Note that there is no way to remove a map entry from the table.
	* For a rump of one of the string types, the affix also needs to be		* For a rump of one of the string types, the affix also needs to be
	one of the string types; the bytes of the strings are concatenated		one of the string types; the bytes of the strings are concatenated
	as specified (prefix + rump, rump + suffix). The result of the		as specified (prefix + rump, rump + suffix). The result of the
	concatenation gets the type of the rump; this way a single affix		concatenation gets the type of the rump; this way a single affix
	can be used to build both byte and text strings, depending on what		can be used to build both byte and text strings, depending on what
	type of rump is being used.		type of rump is being used.
	As a contrived (but short) example, if the prefix table is		As a contrived (but short) example, if the prefix table is ["foobar",
	"["foobar", "foob", "fo"]", the following prefix references will all		"foob", "fo"], the following prefix references will all unpack to
	unpack to ""foobart"": "6("t")", "224("art")", "225("obart")" (the		"foobart": 6("t"), 224("art"), 225("obart") (the last example is not
	last example is not an optimization).		an optimization).
	Taking into account the encoding, there is one single-byte prefix		Taking into account the encoding, there is one single-byte prefix
	reference, 31 (2^5-2^0) two-byte references, 4064 (2^12-2^5) three-		reference, 31 (2^5-2^0) two-byte references, 4064 (2^12-2^5) three-
	byte references, and 26843160 (2^28-2^12) five-byte references for		byte references, and 26843160 (2^28-2^12) five-byte references for
	prefixes. 268435455 (2^28) is an artificial limit, but should be high		prefixes. 268435455 (2^28) is an artificial limit, but should be high
	enough that there, again, is no practical limit to how many prefix		enough that there, again, is no practical limit to how many prefix
	items might be used in a Packed CBOR item. The numbers for suffix		items might be used in a Packed CBOR item. The numbers for suffix
	references are one quarter of those, except that there is no single-		references are one quarter of those, except that there is no single-
	byte reference and 8 two-byte references.		byte reference and 8 two-byte references.
	| Rationale: Experience suggests that prefix packing might be		| Rationale: Experience suggests that prefix packing might be
	| more likely than suffix packing. Also for this reason, there		| more likely than suffix packing. Also for this reason, there
	| is no intent to spend a 1+0 tag value for suffix matching.		| is no intent to spend a 1+0 tag value for suffix packing.
	2.4. Discussion		2.4. Discussion
	This specification uses up a large number of Simple Values and Tags,		This specification uses up a large number of Simple Values and Tags,
	in particular one of the rare one-byte tags and half of the one-byte		in particular one of the rare one-byte tags and half of the one-byte
	simple values. Since the objective is compression, this is warranted		simple values. Since the objective is compression, this is warranted
	if and only if there is consensus that this specific format could be		if and only if there is consensus that this specific format could be
	useful for a wide area of applications, while maintaining reasonable		useful for a wide area of applications, while maintaining reasonable
	simplicity in particular at the side of the consumer.		simplicity in particular at the side of the consumer.
	skipping to change at page 9, line 23 ¶		skipping to change at page 9, line 23 ¶
	combine with application-environment supplied tables that apply to		combine with application-environment supplied tables that apply to
	the entire CBOR data item.		the entire CBOR data item.
	For table setup, the present specification only defines a single tag,		For table setup, the present specification only defines a single tag,
	which operates by prepending to the (by default empty) tables.		which operates by prepending to the (by default empty) tables.
	| We could also define a tag for dictionary referencing (or		| We could also define a tag for dictionary referencing (or
	| include that in the basic packed CBOR), but the desirable		| include that in the basic packed CBOR), but the desirable
	| details are likely to vary considerably between applications.		| details are likely to vary considerably between applications.
	| A URI-based reference would be easy to add, but might be too		| A URI-based reference would be easy to add, but might be too
	| inefficient when used in the likely combination with an "ni:"		| inefficient when used in the likely combination with an ni: URI
	| URI [RFC6920].		| [RFC6920].
	3.1. Basic Packed CBOR		3.1. Basic Packed CBOR
	A predefined tag for packing table setup is defined in CDDL [RFC8610]		A predefined tag for packing table setup is defined in CDDL [RFC8610]
	as in Figure 1:		as in Figure 1:
	Basic-Packed-CBOR = #6.51([[*shared-item], [*prefix-item],		Basic-Packed-CBOR = #6.51([[*shared-item], [*prefix-item],
	[*suffix-item], rump])		[*suffix-item], rump])
	rump = any		rump = any
	prefix-item = any		prefix-item = any
	skipping to change at page 11, line 40 ¶		skipping to change at page 11, line 40 ¶
	+=======+=====================+========================+		+=======+=====================+========================+
	| Value | Semantics | Reference |		| Value | Semantics | Reference |
	+=======+=====================+========================+		+=======+=====================+========================+
	| 0-15 | Packed CBOR: shared | draft-ietf-cbor-packed |		| 0-15 | Packed CBOR: shared | draft-ietf-cbor-packed |
	+-------+---------------------+------------------------+		+-------+---------------------+------------------------+
	Table 5: Simple Values		Table 5: Simple Values
	5. Security Considerations		5. Security Considerations
	The security considerations of [RFC8949] apply.		The security considerations of [STD94] apply.
	Loops in the Packed CBOR can be used as a denial of service attack,		Loops in the Packed CBOR can be used as a denial of service attack,
	see Section 2.4.		see Section 2.4.
	As the unpacking is deterministic, packed forms can be used as		As the unpacking is deterministic, packed forms can be used as
	signing inputs. (Note that if external dictionaries are added to		signing inputs. (Note that if external dictionaries are added to
	cbor-packed, this requires additional consideration.)		cbor-packed, this requires additional consideration.)
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[IANA.cbor-simple-values]		[IANA.cbor-simple-values]
	IANA, "Concise Binary Object Representation (CBOR) Simple		IANA, "Concise Binary Object Representation (CBOR) Simple
	Values",		Values",
	<http://www.iana.org/assignments/cbor-simple-values>.		<https://www.iana.org/assignments/cbor-simple-values>.
	[IANA.cbor-tags]		[IANA.cbor-tags]
	IANA, "Concise Binary Object Representation (CBOR) Tags",		IANA, "Concise Binary Object Representation (CBOR) Tags",
	<http://www.iana.org/assignments/cbor-tags>.		<https://www.iana.org/assignments/cbor-tags>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/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/info/rfc8610>.		June 2019, <https://www.rfc-editor.org/info/rfc8610>.
	[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object		[STD94] 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>.
	6.2. Informative References		6.2. Informative References
	[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,		[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
	Keranen, A., and P. Hallam-Baker, "Naming Things with		Keranen, A., and P. Hallam-Baker, "Naming Things with
	Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,		Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
	<https://www.rfc-editor.org/info/rfc6920>.		<https://www.rfc-editor.org/info/rfc6920>.
	skipping to change at page 13, line 5 ¶		skipping to change at page 13, line 5 ¶
	October 2013, <https://www.rfc-editor.org/info/rfc7049>.		October 2013, <https://www.rfc-editor.org/info/rfc7049>.
	[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,		[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
	DOI 10.17487/RFC7322, September 2014,		DOI 10.17487/RFC7322, September 2014,
	<https://www.rfc-editor.org/info/rfc7322>.		<https://www.rfc-editor.org/info/rfc7322>.
	[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)		[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
	Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,		Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
	<https://www.rfc-editor.org/info/rfc8742>.		<https://www.rfc-editor.org/info/rfc8742>.
			[STD63] Yergeau, F., "UTF-8, a transformation format of ISO
			10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
			2003, <https://www.rfc-editor.org/info/rfc3629>.
	Appendix A. Examples		Appendix A. Examples
	The (JSON-compatible) CBOR data structure depicted in Figure 2, 400		The (JSON-compatible) CBOR data structure depicted in Figure 2, 400
	bytes of binary CBOR, could lead to a packed CBOR data item depicted		bytes of binary CBOR, could lead to a packed CBOR data item depicted
	in Figure 3, ~309 bytes. Note that this particular example does not		in Figure 3, ~309 bytes. Note that this particular example does not
	lend itself to prefix compression.		lend itself to prefix compression.
	{ "store": {		{ "store": {
	"book": [		"book": [
	{ "category": "reference",		{ "category": "reference",
	skipping to change at page 17, line 46 ¶		skipping to change at page 17, line 46 ¶
	simple(4): simple(5)}], simple(6): simple(7), simple(0):		simple(4): simple(5)}], simple(6): simple(7), simple(0):
	"colorTemperatureChanged", simple(1): ["Event"]}],		"colorTemperatureChanged", simple(1): ["Event"]}],
	simple(1): "Lamp", "id": "0", "base": 225(""),		simple(1): "Lamp", "id": "0", "base": 225(""),
	"@context": 6("2:8444/wot/w3c-wot-td-context.jsonld")}])		"@context": 6("2:8444/wot/w3c-wot-td-context.jsonld")}])
	Figure 5: Example packed CBOR data item		Figure 5: Example packed CBOR data item
	Acknowledgements		Acknowledgements
	CBOR packing was originally invented with the rest of CBOR, but did		CBOR packing was originally invented with the rest of CBOR, but did
	not make it into [RFC7049], the predecessor of [RFC8949]. Various		not make it into [RFC7049], the predecessor of [STD94]. Various
	attempts to come up with a specification over the years didn't		attempts to come up with a specification over the years didn't
	proceed. In 2017, Sebastian Käbisch proposed investigating compact		proceed. In 2017, Sebastian Käbisch proposed investigating compact
	representations of W3C Thing Descriptions, which prompted the author		representations of W3C Thing Descriptions, which prompted the author
	to come up with essentially the present design.		to come up with essentially the present design.
	Author's Address		Author's Address
	Carsten Bormann		Carsten Bormann
	Universität Bremen TZI		Universität Bremen TZI
	Postfach 330440		Postfach 330440
End of changes. 24 change blocks.
	43 lines changed or deleted		55 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/