Diff: rfc8949-authors.txt

	rfc8949-authors.txt	rfc8949.txt

	skipping to change at line 108 ¶	skipping to change at line 108 ¶
	6.2. Converting from JSON to CBOR	6.2. Converting from JSON to CBOR
	7. Future Evolution of CBOR	7. Future Evolution of CBOR
	7.1. Extension Points	7.1. Extension Points
	7.2. Curating the Additional Information Space	7.2. Curating the Additional Information Space
	8. Diagnostic Notation	8. Diagnostic Notation
	8.1. Encoding Indicators	8.1. Encoding Indicators
	9. IANA Considerations	9. IANA Considerations
	9.1. CBOR Simple Values Registry	9.1. CBOR Simple Values Registry
	9.2. CBOR Tags Registry	9.2. CBOR Tags Registry
	9.3. Media Types Registry	9.3. Media Types Registry

	9.4. CoAP Content-Format	9.4. CoAP Content-Format Registry
	9.5. The +cbor Structured Syntax Suffix Registration	9.5. Structured Syntax Suffix Registry
	10. Security Considerations	10. Security Considerations
	11. References	11. References
	11.1. Normative References	11.1. Normative References
	11.2. Informative References	11.2. Informative References
	Appendix A. Examples of Encoded CBOR Data Items	Appendix A. Examples of Encoded CBOR Data Items
	Appendix B. Jump Table for Initial Byte	Appendix B. Jump Table for Initial Byte
	Appendix C. Pseudocode	Appendix C. Pseudocode
	Appendix D. Half-Precision	Appendix D. Half-Precision
	Appendix E. Comparison of Other Binary Formats to CBOR's Design	Appendix E. Comparison of Other Binary Formats to CBOR's Design
	Objectives	Objectives

	skipping to change at line 912 ¶	skipping to change at line 912 ¶
	that employ a tag.	that employ a tag.

	The tag definition usually defines which nested data items are valid	The tag definition usually defines which nested data items are valid
	for such tags. Tag definitions may restrict their content to a very	for such tags. Tag definitions may restrict their content to a very
	specific syntactic structure, as the tags defined in this document	specific syntactic structure, as the tags defined in this document
	do, or they may define their content more semantically. An example	do, or they may define their content more semantically. An example
	for the latter is how tags 40 and 1040 accept multiple ways to	for the latter is how tags 40 and 1040 accept multiple ways to
	represent arrays [RFC8746].	represent arrays [RFC8746].

	As a matter of convention, many tags do not accept "null" or	As a matter of convention, many tags do not accept "null" or

	"undefined" values as tag content; instead, a "null" or "undefined"	"undefined" values as tag content; instead, the expectation is that a
	value can be used in place of the entire tag. For example,	"null" or "undefined" value can be used in place of the entire tag;
	Section 3.4.2 provides guidance on the handling of this convention in	Section 3.4.2 provides some further considerations for one specific
	application protocols and the mapping to platform types for tag	tag about the handling of this convention in application protocols
	number 1.	and in mapping to platform types.

	Decoders do not need to understand tags of every tag number, and tags	Decoders do not need to understand tags of every tag number, and tags
	may be of little value in applications where the implementation	may be of little value in applications where the implementation
	creating a particular CBOR data item and the implementation decoding	creating a particular CBOR data item and the implementation decoding
	that stream know the semantic meaning of each item in the data flow.	that stream know the semantic meaning of each item in the data flow.
	The primary purpose of tags in this specification is to define common	The primary purpose of tags in this specification is to define common
	data types such as dates. A secondary purpose is to provide	data types such as dates. A secondary purpose is to provide
	conversion hints when it is foreseen that the CBOR data item needs to	conversion hints when it is foreseen that the CBOR data item needs to
	be translated into a different format, requiring hints about the	be translated into a different format, requiring hints about the
	content of items. Understanding the semantics of tags is optional	content of items. Understanding the semantics of tags is optional

	skipping to change at line 1929 ¶	skipping to change at line 1929 ¶
	decoder may deliver a decoded map to an application that needs to be	decoder may deliver a decoded map to an application that needs to be
	checked for duplicate map keys by that application (alternatively,	checked for duplicate map keys by that application (alternatively,
	the decoder may provide a programming interface to perform this	the decoder may provide a programming interface to perform this
	service for the application). Specific data models are not able to	service for the application). Specific data models are not able to
	distinguish values for map keys that are equal for this purpose at	distinguish values for map keys that are equal for this purpose at
	the generic data model level.	the generic data model level.

	5.7. Undefined Values	5.7. Undefined Values

	In some CBOR-based protocols, the simple value (Section 3.3) of	In some CBOR-based protocols, the simple value (Section 3.3) of

	Undefined might be used by an encoder as a substitute for a data item	"undefined" might be used by an encoder as a substitute for a data
	with an encoding problem, in order to allow the rest of the enclosing	item with an encoding problem, in order to allow the rest of the
	data items to be encoded without harm.	enclosing data items to be encoded without harm.

	6. Converting Data between CBOR and JSON	6. Converting Data between CBOR and JSON

	This section gives non-normative advice about converting between CBOR	This section gives non-normative advice about converting between CBOR
	and JSON. Implementations of converters MAY use whichever advice	and JSON. Implementations of converters MAY use whichever advice
	here they want.	here they want.

	It is worth noting that a JSON text is a sequence of characters, not	It is worth noting that a JSON text is a sequence of characters, not
	an encoded sequence of bytes, while a CBOR data item consists of	an encoded sequence of bytes, while a CBOR data item consists of
	bytes, not characters.	bytes, not characters.

	skipping to change at line 2337 ¶	skipping to change at line 2337 ¶
	Area (art@ietf.org)	Area (art@ietf.org)

	Intended usage: COMMON	Intended usage: COMMON

	Restrictions on usage: none	Restrictions on usage: none

	Author: IETF CBOR Working Group (cbor@ietf.org)	Author: IETF CBOR Working Group (cbor@ietf.org)

	Change controller: The IESG (iesg@ietf.org)	Change controller: The IESG (iesg@ietf.org)


	9.4. CoAP Content-Format	9.4. CoAP Content-Format Registry

	The CoAP Content-Format for CBOR has been registered in the "CoAP	The CoAP Content-Format for CBOR has been registered in the "CoAP
	Content-Formats" subregistry within the "Constrained RESTful	Content-Formats" subregistry within the "Constrained RESTful
	Environments (CoRE) Parameters" registry [IANA.core-parameters]:	Environments (CoRE) Parameters" registry [IANA.core-parameters]:

	Media Type: application/cbor	Media Type: application/cbor

	Encoding: -	Encoding: -

	ID: 60	ID: 60

	Reference: RFC 8949	Reference: RFC 8949


	9.5. The +cbor Structured Syntax Suffix Registration	9.5. Structured Syntax Suffix Registry

	The structured syntax suffix [RFC6838] for media types based on a	The structured syntax suffix [RFC6838] for media types based on a
	single encoded CBOR data item is +cbor, which IANA has registered in	single encoded CBOR data item is +cbor, which IANA has registered in
	the "Structured Syntax Suffixes" registry [IANA.structured-suffix]:	the "Structured Syntax Suffixes" registry [IANA.structured-suffix]:

	Name: Concise Binary Object Representation (CBOR)	Name: Concise Binary Object Representation (CBOR)

	+suffix: +cbor	+suffix: +cbor

	References: RFC 8949	References: RFC 8949

	skipping to change at line 2595 ¶	skipping to change at line 2595 ¶
	Edition, IEEE Std 1003.1, 2018,	Edition, IEEE Std 1003.1, 2018,
	<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/	<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
	V1_chap04.html#tag_04_16>.	V1_chap04.html#tag_04_16>.

	11.2. Informative References	11.2. Informative References

	[ASN.1] International Telecommunication Union, "Information	[ASN.1] International Telecommunication Union, "Information
	Technology - ASN.1 encoding rules: Specification of Basic	Technology - ASN.1 encoding rules: Specification of Basic
	Encoding Rules (BER), Canonical Encoding Rules (CER) and	Encoding Rules (BER), Canonical Encoding Rules (CER) and
	Distinguished Encoding Rules (DER)", ITU-T Recommendation	Distinguished Encoding Rules (DER)", ITU-T Recommendation

	X.690, 1994.	X.690, 2015,
		<https://www.itu.int/rec/T-REC-X.690-201508-I/en>.

	[BSON] Various, "BSON - Binary JSON", 2013,	[BSON] Various, "BSON - Binary JSON", 2013,
	<http://bsonspec.org/>.	<http://bsonspec.org/>.

	[CBOR-TAGS]	[CBOR-TAGS]
	Bormann, C., "Notable CBOR Tags", Work in Progress,	Bormann, C., "Notable CBOR Tags", Work in Progress,
	Internet-Draft, draft-bormann-cbor-notable-tags-02, 25	Internet-Draft, draft-bormann-cbor-notable-tags-02, 25
	June 2020, <https://tools.ietf.org/html/draft-bormann-	June 2020, <https://tools.ietf.org/html/draft-bormann-
	cbor-notable-tags-02>.	cbor-notable-tags-02>.


	[ECMA262] Ecma International, "ECMAScript 2018 Language	[ECMA262] Ecma International, "ECMAScript 2020 Language
	Specification", Standard ECMA-262, 9th Edition, June 2018,	Specification", Standard ECMA-262, 11th Edition, June
	<https://www.ecma-international.org/publications/files/	2020, <https://www.ecma-
	ECMA-ST/Ecma-262.pdf>.	international.org/publications/standards/Ecma-262.htm>.

	[Err3764] RFC Errata, Erratum ID 3764, RFC 7049,	[Err3764] RFC Errata, Erratum ID 3764, RFC 7049,
	<https://www.rfc-editor.org/errata/eid3764>.	<https://www.rfc-editor.org/errata/eid3764>.

	[Err3770] RFC Errata, Erratum ID 3770, RFC 7049,	[Err3770] RFC Errata, Erratum ID 3770, RFC 7049,
	<https://www.rfc-editor.org/errata/eid3770>.	<https://www.rfc-editor.org/errata/eid3770>.

	[Err4294] RFC Errata, Erratum ID 4294, RFC 7049,	[Err4294] RFC Errata, Erratum ID 4294, RFC 7049,
	<https://www.rfc-editor.org/errata/eid4294>.	<https://www.rfc-editor.org/errata/eid4294>.


	skipping to change at line 2666 ¶	skipping to change at line 2667 ¶
	[IANA.structured-suffix]	[IANA.structured-suffix]
	IANA, "Structured Syntax Suffixes",	IANA, "Structured Syntax Suffixes",
	<https://www.iana.org/assignments/media-type-structured-	<https://www.iana.org/assignments/media-type-structured-
	suffix>.	suffix>.

	[MessagePack]	[MessagePack]
	Furuhashi, S., "MessagePack", 2013,	Furuhashi, S., "MessagePack", 2013,
	<https://msgpack.org/>.	<https://msgpack.org/>.

	[PCRE] Hazel, P., "PCRE - Perl Compatible Regular Expressions",	[PCRE] Hazel, P., "PCRE - Perl Compatible Regular Expressions",

	2018, <https://www.pcre.org/>.	<https://www.pcre.org/>.

	[RFC0713] Haverty, J., "MSDTP-Message Services Data Transmission	[RFC0713] Haverty, J., "MSDTP-Message Services Data Transmission
	Protocol", RFC 713, DOI 10.17487/RFC0713, April 1976,	Protocol", RFC 713, DOI 10.17487/RFC0713, April 1976,
	<https://www.rfc-editor.org/info/rfc713>.	<https://www.rfc-editor.org/info/rfc713>.

	[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type	[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
	Specifications and Registration Procedures", BCP 13,	Specifications and Registration Procedures", BCP 13,
	RFC 6838, DOI 10.17487/RFC6838, January 2013,	RFC 6838, DOI 10.17487/RFC6838, January 2013,
	<https://www.rfc-editor.org/info/rfc6838>.	<https://www.rfc-editor.org/info/rfc6838>.


	skipping to change at line 2741 ¶	skipping to change at line 2742 ¶
	2009, <https://www.yaml.org/spec/1.2/spec.html>.	2009, <https://www.yaml.org/spec/1.2/spec.html>.

	Appendix A. Examples of Encoded CBOR Data Items	Appendix A. Examples of Encoded CBOR Data Items

	The following table provides some CBOR-encoded values in hexadecimal	The following table provides some CBOR-encoded values in hexadecimal
	(right column), together with diagnostic notation for these values	(right column), together with diagnostic notation for these values
	(left column). Note that the string "\u00fc" is one form of	(left column). Note that the string "\u00fc" is one form of
	diagnostic notation for a UTF-8 string containing the single Unicode	diagnostic notation for a UTF-8 string containing the single Unicode
	character U+00FC (LATIN SMALL LETTER U WITH DIAERESIS, "ü").	character U+00FC (LATIN SMALL LETTER U WITH DIAERESIS, "ü").
	Similarly, "\u6c34" is a UTF-8 string in diagnostic notation with a	Similarly, "\u6c34" is a UTF-8 string in diagnostic notation with a

	single character U+6C34 U+000A U+0020 U+0020 U+0020 U+0020 U+0020	single character U+6C34 (CJK UNIFIED IDEOGRAPH-6C34, "水"), often
	U+0020 U+0020 U+0020 (CJK UNIFIED IDEOGRAPH-6C34, U+000a, SPACE,
	SPACE, SPACE, SPACE, SPACE, SPACE, SPACE, SPACE, "水 "), often
	representing "water", and "\ud800\udd51" is a UTF-8 string in	representing "water", and "\ud800\udd51" is a UTF-8 string in
	diagnostic notation with a single character U+10151 (GREEK ACROPHONIC	diagnostic notation with a single character U+10151 (GREEK ACROPHONIC

	ATTIC FIFTY STATERS, "𐅑"). In the diagnostic notation provided for	ATTIC FIFTY STATERS, "𐅑"). (Note that all these single-character
	bignums, their intended numeric value is shown as a decimal number	strings could also be represented in native UTF-8 in diagnostic
	(such as 18446744073709551616) instead of a tagged byte string (such	notation, just not in an ASCII-only specification.) In the
	as 2(h'010000000000000000')).	diagnostic notation provided for bignums, their intended numeric
		value is shown as a decimal number (such as 18446744073709551616)
		instead of a tagged byte string (such as 2(h'010000000000000000')).

	+==============================+====================================+	+==============================+====================================+
	\|Diagnostic \| Encoded \|	\|Diagnostic \| Encoded \|
	+==============================+====================================+	+==============================+====================================+
	\|0 \| 0x00 \|	\|0 \| 0x00 \|
	+------------------------------+------------------------------------+	+------------------------------+------------------------------------+
	\|1 \| 0x01 \|	\|1 \| 0x01 \|
	+------------------------------+------------------------------------+	+------------------------------+------------------------------------+
	\|10 \| 0x0a \|	\|10 \| 0x0a \|
	+------------------------------+------------------------------------+	+------------------------------+------------------------------------+

	skipping to change at line 3513 ¶	skipping to change at line 3514 ¶
	by adding "Second value" to a comment to the last example in	by adding "Second value" to a comment to the last example in
	Section 3.2.2).	Section 3.2.2).

	Other clerical changes include:	Other clerical changes include:

	* the use of new xml2rfc functionality [RFC7991];	* the use of new xml2rfc functionality [RFC7991];

	* more explanation of the notation used;	* more explanation of the notation used;

	* the update of references, e.g., from RFC 4627 to [RFC8259], from	* the update of references, e.g., from RFC 4627 to [RFC8259], from

	CNN-TERMS to [RFC7228], and from the 5.1 edition to the 9th	CNN-TERMS to [RFC7228], and from the 5.1 edition to the 11th
	edition of [ECMA262]; the addition of a reference to [IEEE754] and	edition of [ECMA262]; the addition of a reference to [IEEE754] and
	importation of required definitions; and the addition of a	importation of required definitions; and the addition of a
	reference to [RFC8618] that further illustrates the discussion in	reference to [RFC8618] that further illustrates the discussion in
	Appendix E;	Appendix E;

	* in the discussion of diagnostic notation (Section 8), the	* in the discussion of diagnostic notation (Section 8), the
	"Extended Diagnostic Notation" (EDN) defined in [RFC8610] is now	"Extended Diagnostic Notation" (EDN) defined in [RFC8610] is now
	mentioned, the gap in representing NaN payloads is now	mentioned, the gap in representing NaN payloads is now
	highlighted, and an explanation of representing indefinite-length	highlighted, and an explanation of representing indefinite-length
	strings with no chunks has been added (Section 8.1);	strings with no chunks has been added (Section 8.1);

End of changes. 11 change blocks.
	26 lines changed or deleted	27 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/