draft-reschke-http-jfv-13.txt		draft-reschke-http-jfv-14.txt
	Network Working Group J. F. Reschke		Network Working Group J. F. Reschke
	Internet-Draft greenbytes		Internet-Draft greenbytes
	Intended status: Informational 22 February 2021		Intended status: Informational 22 April 2021
	Expires: 26 August 2021		Expires: 24 October 2021
	A JSON Encoding for HTTP Field Values		A JSON Encoding for HTTP Field Values
	draft-reschke-http-jfv-13		draft-reschke-http-jfv-14
	Abstract		Abstract
	This document establishes a convention for use of JSON-encoded field		This document establishes a convention for use of JSON-encoded field
	values in HTTP fields.		values in new HTTP fields.
	Editorial Note		Editorial Note
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	Distribution of this document is unlimited. Although this is not a		Distribution of this document is unlimited. Although this is not a
	work item of the HTTPbis Working Group, comments should be sent to		work item of the HTTPbis Working Group, comments should be sent to
	the Hypertext Transfer Protocol (HTTP) mailing list at ietf-http-		the Hypertext Transfer Protocol (HTTP) mailing list at ietf-http-
	wg@w3.org (mailto:ietf-http-wg@w3.org), which may be joined by		wg@w3.org (mailto:ietf-http-wg@w3.org), which may be joined by
	sending a message with subject "subscribe" to ietf-http-wg-		sending a message with subject "subscribe" to ietf-http-wg-
	request@w3.org (mailto:ietf-http-wg-		request@w3.org (mailto:ietf-http-wg-
	request@w3.org?subject=subscribe).		request@w3.org?subject=subscribe).
	Discussions of the HTTPbis Working Group are archived at		Discussions of the HTTPbis Working Group are archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	XML versions and latest edits for this document are available from		XML versions and latest edits for this document are available from
	<http://greenbytes.de/tech/webdav/#draft-reschke-http-jfv>.		<http://greenbytes.de/tech/webdav/#draft-reschke-http-jfv>.
	The changes in this draft are summarized in Appendix B.16.		The changes in this draft are summarized in Appendix D.17.
	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 26 August 2021.		This Internet-Draft will expire on 24 October 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as 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 Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
			1.1. Relation to "Structured Field Values for HTTP"
			(RFC8941) . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Data Model and Format . . . . . . . . . . . . . . . . . . . . 4		2. Data Model and Format . . . . . . . . . . . . . . . . . . . . 4
	3. Sender Requirements . . . . . . . . . . . . . . . . . . . . . 5		3. Sender Requirements . . . . . . . . . . . . . . . . . . . . . 5
	4. Recipient Requirements . . . . . . . . . . . . . . . . . . . 5		3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Using this Format in Field Definitions . . . . . . . . . . . 5		4. Recipient Requirements . . . . . . . . . . . . . . . . . . . 6
	6. Deployment Considerations . . . . . . . . . . . . . . . . . . 6		4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Interoperability Considerations . . . . . . . . . . . . . . . 6		5. Using this Format in Field Definitions . . . . . . . . . . . 7
	7.1. Encoding and Characters . . . . . . . . . . . . . . . . . 6		6. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
	7.2. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. Interoperability Considerations . . . . . . . . . . . . . . . 7
	7.3. Object Constraints . . . . . . . . . . . . . . . . . . . 7		7.1. Encoding and Characters . . . . . . . . . . . . . . . . . 7
	8. Internationalization Considerations . . . . . . . . . . . . . 7		7.2. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 7		7.3. Object Constraints . . . . . . . . . . . . . . . . . . . 8
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. Internationalization Considerations . . . . . . . . . . . . . 8
	10.1. Normative References . . . . . . . . . . . . . . . . . . 7		9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	10.2. Informative References . . . . . . . . . . . . . . . . . 8		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
			10.1. Normative References . . . . . . . . . . . . . . . . . . 9
			10.2. Informative References . . . . . . . . . . . . . . . . . 9
	10.3. Specifications Using This Syntax (at some point of		10.3. Specifications Using This Syntax (at some point of
	time) . . . . . . . . . . . . . . . . . . . . . . . . . 8		time) . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Appendix A. Use of JSON Field Value Encoding in the Wild . . . . 9		Appendix A. Comparison with Structured Fields . . . . . . . . . 10
	A.1. W3C Reporting API Specification . . . . . . . . . . . . . 9		A.1. Base Types . . . . . . . . . . . . . . . . . . . . . . . 10
	A.2. W3C Clear Site Data Specification . . . . . . . . . . . . 9		A.2. Structures . . . . . . . . . . . . . . . . . . . . . . . 11
	A.3. W3C Feature Policy Specification . . . . . . . . . . . . 10		Appendix B. Use of JSON Field Value Encoding in the Wild . . . . 11
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 10		B.1. W3C Reporting API Specification . . . . . . . . . . . . . 12
	B.1. Since draft-reschke-http-jfv-00 . . . . . . . . . . . . . 10		B.2. W3C Clear Site Data Specification . . . . . . . . . . . . 12
	B.2. Since draft-reschke-http-jfv-01 . . . . . . . . . . . . . 10		B.3. W3C Feature Policy Specification . . . . . . . . . . . . 12
	B.3. Since draft-reschke-http-jfv-02 . . . . . . . . . . . . . 10		Appendix C. Implementations . . . . . . . . . . . . . . . . . . 12
	B.4. Since draft-reschke-http-jfv-03 . . . . . . . . . . . . . 10		Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 12
	B.5. Since draft-reschke-http-jfv-04 . . . . . . . . . . . . . 10		D.1. Since draft-reschke-http-jfv-00 . . . . . . . . . . . . . 12
	B.6. Since draft-ietf-httpbis-jfv-00 . . . . . . . . . . . . . 10		D.2. Since draft-reschke-http-jfv-01 . . . . . . . . . . . . . 12
	B.7. Since draft-ietf-httpbis-jfv-01 . . . . . . . . . . . . . 11		D.3. Since draft-reschke-http-jfv-02 . . . . . . . . . . . . . 13
	B.8. Since draft-ietf-httpbis-jfv-02 . . . . . . . . . . . . . 11		D.4. Since draft-reschke-http-jfv-03 . . . . . . . . . . . . . 13
	B.9. Since draft-reschke-http-jfv-05 . . . . . . . . . . . . . 11		D.5. Since draft-reschke-http-jfv-04 . . . . . . . . . . . . . 13
	B.10. Since draft-reschke-http-jfv-06 . . . . . . . . . . . . . 11		D.6. Since draft-ietf-httpbis-jfv-00 . . . . . . . . . . . . . 13
	B.11. Since draft-reschke-http-jfv-07 . . . . . . . . . . . . . 11		D.7. Since draft-ietf-httpbis-jfv-01 . . . . . . . . . . . . . 13
	B.12. Since draft-reschke-http-jfv-08 . . . . . . . . . . . . . 11		D.8. Since draft-ietf-httpbis-jfv-02 . . . . . . . . . . . . . 13
	B.13. Since draft-reschke-http-jfv-09 . . . . . . . . . . . . . 11		D.9. Since draft-reschke-http-jfv-05 . . . . . . . . . . . . . 13
	B.14. Since draft-reschke-http-jfv-10 . . . . . . . . . . . . . 12		D.10. Since draft-reschke-http-jfv-06 . . . . . . . . . . . . . 14
	B.15. Since draft-reschke-http-jfv-11 . . . . . . . . . . . . . 12		D.11. Since draft-reschke-http-jfv-07 . . . . . . . . . . . . . 14
	B.16. Since draft-reschke-http-jfv-12 . . . . . . . . . . . . . 12		D.12. Since draft-reschke-http-jfv-08 . . . . . . . . . . . . . 14
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12		D.13. Since draft-reschke-http-jfv-09 . . . . . . . . . . . . . 14
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12		D.14. Since draft-reschke-http-jfv-10 . . . . . . . . . . . . . 14
			D.15. Since draft-reschke-http-jfv-11 . . . . . . . . . . . . . 14
			D.16. Since draft-reschke-http-jfv-12 . . . . . . . . . . . . . 15
			D.17. Since draft-reschke-http-jfv-13 . . . . . . . . . . . . . 15
			Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	Defining syntax for new HTTP fields ([HTTP], Section 5) is non-		Defining syntax for new HTTP fields ([HTTP], Section 5) is non-
	trivial. Among the commonly encountered problems are:		trivial. Among the commonly encountered problems are:
	* There is no common syntax for complex field values. Several well-		* There is no common syntax for complex field values. Several well-
	known fields do use a similarly looking syntax, but it is hard to		known fields do use a similarly looking syntax, but it is hard to
	write generic parsing code that will both correctly handle valid		write generic parsing code that will both correctly handle valid
	field values but also reject invalid ones.		field values but also reject invalid ones.
	skipping to change at page 3, line 40 ¶		skipping to change at page 4, line 4 ¶
	Section 2), so fields are either stuck with US-ASCII ([RFC0020]),		Section 2), so fields are either stuck with US-ASCII ([RFC0020]),
	or need out-of-band information to decide what encoding scheme is		or need out-of-band information to decide what encoding scheme is
	used. Furthermore, APIs usually assume a default encoding scheme		used. Furthermore, APIs usually assume a default encoding scheme
	in order to map from octet sequences to strings (for instance,		in order to map from octet sequences to strings (for instance,
	[XMLHttpRequest] uses the IDL type "ByteString", effectively		[XMLHttpRequest] uses the IDL type "ByteString", effectively
	resulting in the ISO-8859-1 character encoding scheme [ISO-8859-1]		resulting in the ISO-8859-1 character encoding scheme [ISO-8859-1]
	being used).		being used).
	(See Section 16.3 of [HTTP] for a summary of considerations for new		(See Section 16.3 of [HTTP] for a summary of considerations for new
	fields.)		fields.)
	This specification addresses the issues listed above by defining both		This specification addresses the issues listed above by defining both
	a generic JSON-based ([RFC8259]) data model and a concrete wire		a generic JSON-based ([RFC8259]) data model and a concrete wire
	format that can be used in definitions of new fields, where the goals		format that can be used in definitions of new fields, where the goals
	were:		were:
	* to be compatible with field recombination when field lines occur		* to be compatible with field recombination when field lines occur
	multiple times in a single message (Section 5.3 of [HTTP]), and		multiple times in a single message (Section 5.3 of [HTTP]), and
	* not to use any problematic characters in the field value (non-		* not to use any problematic characters in the field value (non-
	ASCII characters and certain whitespace characters).		ASCII characters and certain whitespace characters).
	| *Note:* [RFC8941], a work item of the IETF HTTP Working Group,		1.1. Relation to "Structured Field Values for HTTP" ([RFC8941])
	| is a different attempt to address this set of problems - it
	| tries to identify and formalize common field structures in		"Structured Field Values for HTTP", an IETF RFC on the Standards
	| existing fields; the syntax defined over there would usually		Track, is a different approach to this set of problems. It uses a
	| lead to a more compact notation.		more compact notation, similar to what is used in existing header
			fields, and avoids several potential interoperability problems
			inherent to the use of JSON.
			In general, that format is preferred for newly defined fields. The
			JSON-based format defined by this document might however be useful in
			case the data that needs to be transferred is already in JSON format,
			or features not covered by "Structured Field Values" are needed.
			See Appendix A for more details.
	2. Data Model and Format		2. Data Model and Format
	In HTTP, field lines with the same field name can occur multiple		In HTTP, field lines with the same field name can occur multiple
	times within a single message (Section 5.3 of [HTTP]). When this		times within a single message (Section 5.3 of [HTTP]). When this
	happens, recipients are allowed to combine the field line values		happens, recipients are allowed to combine the field line values
	using commas as delimiter, forming a combined "field value". This		using commas as delimiter, forming a combined "field value". This
	rule matches nicely JSON's array format (Section 5 of [RFC8259]).		rule matches nicely JSON's array format (Section 5 of [RFC8259]).
	Thus, the basic data model used here is the JSON array.		Thus, the basic data model used here is the JSON array.
	skipping to change at page 5, line 29 ¶		skipping to change at page 5, line 48 ¶
	replacing them by space ("SP") characters,		replacing them by space ("SP") characters,
	3. replacing all remaining non-VSPACE characters by the equivalent		3. replacing all remaining non-VSPACE characters by the equivalent
	backslash-escape sequence ([RFC8259], Section 7).		backslash-escape sequence ([RFC8259], Section 7).
	The resulting list of strings is transformed into an HTTP field value		The resulting list of strings is transformed into an HTTP field value
	by combining them using comma (%x2C) plus optional SP as delimiter,		by combining them using comma (%x2C) plus optional SP as delimiter,
	and encoding the resulting string into an octet sequence using the		and encoding the resulting string into an octet sequence using the
	US-ASCII character encoding scheme ([RFC0020]).		US-ASCII character encoding scheme ([RFC0020]).
			3.1. Example
			With the JSON data below, containing the non-ASCII characters "ü"
			(LATIN SMALL LETTER U WITH DIAERESIS, U+00FC) and "€" (EURO SIGN,
			U+20AC):
			[
			{
			"destination": "Münster",
			"price": 123,
			"currency": "€"
			}
			]
			The generated field value would be:
			{ "destination": "M\u00FCnster", "price": 123, "currency": "\u20AC" }
	4. Recipient Requirements		4. Recipient Requirements
	To map a set of HTTP field line values to a JSON array:		To map a set of HTTP field line values to a JSON array:
	1. combine all field line values into a single field value as per		1. combine all field line values into a single field value as per
	Section 5.3 of [HTTP],		Section 5.3 of [HTTP],
	2. add a leading begin-array ("[") octet and a trailing end-array		2. add a leading begin-array ("[") octet and a trailing end-array
	("]") octet, then		("]") octet, then
	3. run the resulting octet sequence through a JSON parser.		3. run the resulting octet sequence through a JSON parser.
	The result of the parsing operation is either an error (in which case		The result of the parsing operation is either an error (in which case
	the field values needs to be considered invalid), or a JSON array.		the field values needs to be considered invalid), or a JSON array.
			4.1. Example
			An HTTP message containing the field lines:
			Example: "\u221E"
			Example: {"date":"2012-08-25"}
			Example: [17,42]
			would be parsed into the JSON array below:
			[
			"∞",
			{
			"date": "2012-08-25"
			},
			[
			17,
			42
			]
			]
	5. Using this Format in Field Definitions		5. Using this Format in Field Definitions
	Specifications defining new HTTP fields need to take the		Specifications defining new HTTP fields need to take the
	considerations listed in Section 16.3 of [HTTP] into account. Many		considerations listed in Section 16.3 of [HTTP] into account. Many
	of these will already be accounted for by using the format defined in		of these will already be accounted for by using the format defined in
	this specification.		this specification.
	Readers of HTTP-related specifications frequently expect an ABNF		Readers of HTTP-related specifications frequently expect an ABNF
	definition of the field value syntax. This is not really needed		definition of the field value syntax. This is not really needed
	here, as the actual syntax is JSON text, as defined in Section 2 of		here, as the actual syntax is JSON text, as defined in Section 2 of
	skipping to change at page 6, line 42 ¶		skipping to change at page 7, line 49 ¶
	7. Interoperability Considerations		7. Interoperability Considerations
	The "I-JSON Message Format" specification ([RFC7493]) addresses known		The "I-JSON Message Format" specification ([RFC7493]) addresses known
	JSON interoperability pain points. This specification borrows from		JSON interoperability pain points. This specification borrows from
	the requirements made over there:		the requirements made over there:
	7.1. Encoding and Characters		7.1. Encoding and Characters
	This specification requires that field values use only US-ASCII		This specification requires that field values use only US-ASCII
	characters, and thus by definition use a subset of UTF-8 (Section 2.1		characters, and thus by definition uses a subset of UTF-8
	of [RFC7493]).		(Section 2.1 of [RFC7493]).
			Furthermore, escape sequences in JSON strings (Section 7 of
			[RFC8259]) - both in object member names and string values - are not
			allowed to represent non-Unicode code points such as unpaired
			surrogates or Noncharacters (see "General Structure" in [UNICODE]).
	7.2. Numbers		7.2. Numbers
	Be aware of the issues around number precision, as discussed in		Be aware of the issues around number precision, as discussed in
	Section 2.2 of [RFC7493].		Section 2.2 of [RFC7493].
	7.3. Object Constraints		7.3. Object Constraints
	As described in Section 4 of [RFC8259], JSON parser implementations		As described in Section 4 of [RFC8259], JSON parser implementations
	differ in the handling of duplicate object names. Therefore, senders		differ in the handling of duplicate object names. Therefore, senders
	MUST NOT use duplicate object names, and recipients SHOULD either		are not allowed to use duplicate object names, and recipients are
	treat field values with duplicate names as invalid (consistent with		advised to either treat field values with duplicate names as invalid
	[RFC7493], Section 2.3) or use the lexically last value (consistent		(consistent with [RFC7493], Section 2.3) or use the lexically last
	with [ECMA-262], Section 24.3.1.1).		value (consistent with [ECMA-262], Section 24.3.1.1).
	Furthermore, ordering of object members is not significant and can		Furthermore, ordering of object members is not significant and can
	not be relied upon.		not be relied upon.
	8. Internationalization Considerations		8. Internationalization Considerations
	In current versions of HTTP, field values are represented by octet		In current versions of HTTP, field values are represented by octet
	sequences, usually used to transmit ASCII characters, with		sequences, usually used to transmit ASCII characters, with
	restrictions on the use of certain control characters, and no		restrictions on the use of certain control characters, and no
	associated default character encoding, nor a way to describe it		associated default character encoding, nor a way to describe it
	skipping to change at page 8, line 7 ¶		skipping to change at page 9, line 16 ¶
	smuggle information through field values; however, this concern is		smuggle information through field values; however, this concern is
	shared with other widely used formats, such as those using parameters		shared with other widely used formats, such as those using parameters
	in the form of name/value pairs.		in the form of name/value pairs.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", Work in Progress, Internet-Draft,		Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
	draft-ietf-httpbis-semantics-14, 13 January 2021,		draft-ietf-httpbis-semantics-15, 30 March 2021,
	<https://tools.ietf.org/html/draft-ietf-httpbis-semantics-		<https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
	14>.		15>.
	[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,		[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
	RFC 20, DOI 10.17487/RFC0020, October 1969,		RFC 20, DOI 10.17487/RFC0020, October 1969,
	<https://www.rfc-editor.org/info/rfc20>.		<https://www.rfc-editor.org/info/rfc20>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<https://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
	[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/info/rfc7493>.		<https://www.rfc-editor.org/info/rfc7493>.
	[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 8259, DOI 10.17487/RFC8259,		Interchange Format", RFC 8259, DOI 10.17487/RFC8259,
	December 2017, <https://www.rfc-editor.org/info/rfc8259>.		December 2017, <https://www.rfc-editor.org/info/rfc8259>.
			[UNICODE] The Unicode Consortium, "The Unicode Standard",
			<http://www.unicode.org/versions/latest/>.
	10.2. Informative References		10.2. Informative References
	[ECMA-262] Ecma International, "ECMA-262 6th Edition, The ECMAScript		[ECMA-262] Ecma International, "ECMA-262 6th Edition, The ECMAScript
	2015 Language Specification", Standard ECMA-262, June		2015 Language Specification", Standard ECMA-262, June
	2015, <http://www.ecma-international.org/ecma-262/6.0/>.		2015, <http://www.ecma-international.org/ecma-262/6.0/>.
	[ISO-8859-1]		[ISO-8859-1]
	International Organization for Standardization,		International Organization for Standardization,
	"Information technology -- 8-bit single-byte coded graphic		"Information technology -- 8-bit single-byte coded graphic
	character sets -- Part 1: Latin alphabet No. 1", ISO/		character sets -- Part 1: Latin alphabet No. 1", ISO/
	skipping to change at page 9, line 24 ¶		skipping to change at page 10, line 38 ¶
	<https://w3c.github.io/webappsec-feature-policy/>.		<https://w3c.github.io/webappsec-feature-policy/>.
	[REPORTING]		[REPORTING]
	Creager, D., Grigorik, I., Meyer, P., and M. West,		Creager, D., Grigorik, I., Meyer, P., and M. West,
	"Reporting API", W3C Working Draft WD-reporting-		"Reporting API", W3C Working Draft WD-reporting-
	1-20180925, 25 September 2018,		1-20180925, 25 September 2018,
	<https://www.w3.org/TR/2018/WD-reporting-1-20180925/>.		<https://www.w3.org/TR/2018/WD-reporting-1-20180925/>.
	Latest version available at <https://www.w3.org/TR/		Latest version available at <https://www.w3.org/TR/
	reporting-1/>.		reporting-1/>.
	Appendix A. Use of JSON Field Value Encoding in the Wild		Appendix A. Comparison with Structured Fields
			A.1. Base Types
			+==========+==================================+==================+
			| Type | in Structured Fields | in JSON-based |
			| | | Fields |
			+==========+==================================+==================+
			| Integer | [RFC8941], Section 3.3.1 | [RFC8259], |
			| | | Section 6 |
			| +----------------------------------+------------------+
			| | (restricted to 15 digits) | |
			+==========+----------------------------------+------------------+
			| Decimal | [RFC8941], Section 3.3.2 | [RFC8259], |
			| | | Section 6 |
			| +----------------------------------+------------------+
			| | (a fixed point decimal | |
			| | restricted to 12 + 3 digits) | |
			+==========+----------------------------------+------------------+
			| String | [RFC8941], Section 3.3.3 | [RFC8259], |
			| | | Section 7 |
			| +----------------------------------+------------------+
			| | (only ASCII supported, non-ASCII | |
			| | requires using Byte Sequences) | |
			+==========+----------------------------------+------------------+
			| Token | [RFC8941], Section 3.3.4 | not available |
			+==========+----------------------------------+------------------+
			| Byte | [RFC8941], Section 3.3.5 | not available |
			| Sequence +----------------------------------+------------------+
			| | | (usually mapped |
			| | | to strings using |
			| | | base64 encoding) |
			+==========+----------------------------------+------------------+
			| Boolean | [RFC8941], Section 3.3.6 | [RFC8259], |
			| | | Section 3 |
			+==========+----------------------------------+------------------+
			Table 1
			Structured Fields provide more data types (such as "token" or "byte
			sequence"). Numbers are restricted, avoiding the JSON interop
			problems described in Section 7.2. Strings are limited to ASCII,
			requiring the use of byte sequences should non-ASCII characters be
			needed.
			A.2. Structures
			Structured Fields define Lists ([RFC8941], Section 3.1), similar to
			JSON arrays ([RFC8259], Section 5), and Dictionaries ([RFC8941],
			Section 3.2), similar to JSON objects ([RFC8259], Section 4).
			In addition, most items in Structured Fields can be parametrized
			([RFC8941], Section 3.1.2), attaching a dictionary-like structure to
			the value. To emulate this in JSON based field, an additional
			nesting of objects would be needed.
			Finally, nesting of data structures is intentionally limited to two
			levels (see Appendix A.1 of [RFC8941] for the motivation).
			Appendix B. Use of JSON Field Value Encoding in the Wild
	This section is to be removed before publishing as an RFC.		This section is to be removed before publishing as an RFC.
	Since work started on this document, various specifications have		Since work started on this document, various specifications have
	adopted this format. At least one of these moved away after the HTTP		adopted this format. At least one of these moved away after the HTTP
	Working Group decided to focus on [RFC8941] (see thread starting at		Working Group decided to focus on [RFC8941] (see thread starting at
	<https://lists.w3.org/Archives/Public/ietf-http-		<https://lists.w3.org/Archives/Public/ietf-http-
	wg/2016OctDec/0505.html>).		wg/2016OctDec/0505.html>).
	The sections below summarize the current usage of this format.		The sections below summarize the current usage of this format.
	A.1. W3C Reporting API Specification		B.1. W3C Reporting API Specification
	Defined in W3C Working Draft "Reporting API" (Section 3.1 of		Defined in W3C Working Draft "Reporting API" (Section 3.1 of
	[REPORTING]). Still in use in latest working draft dated September		[REPORTING]). Still in use in latest working draft dated September
	2018.		2018.
	A.2. W3C Clear Site Data Specification		B.2. W3C Clear Site Data Specification
	Used in earlier versions of "Clear Site Data". The current version		Used in earlier versions of "Clear Site Data". The current version
	replaces the use of JSON with a custom syntax that happens to be		replaces the use of JSON with a custom syntax that happens to be
	somewhat compatible with an array of JSON strings (see Section 3.1 of		somewhat compatible with an array of JSON strings (see Section 3.1 of
	[CLEARSITE] and <https://lists.w3.org/Archives/Public/ietf-http-		[CLEARSITE] and <https://lists.w3.org/Archives/Public/ietf-http-
	wg/2017AprJun/0214.html> for feedback).		wg/2017AprJun/0214.html> for feedback).
	A.3. W3C Feature Policy Specification		B.3. W3C Feature Policy Specification
	Originally defined in W3C document "Feature Policy" ([FEATUREPOL]),		Originally defined in W3C document "Feature Policy" ([FEATUREPOL]),
	but switched to use of Structured Header Fields ([RFC8941]).		but switched to use of Structured Header Fields ([RFC8941]).
	Appendix B. Change Log		Appendix C. Implementations
	This section is to be removed before publishing as an RFC.		This section is to be removed before publishing as an RFC.
	B.1. Since draft-reschke-http-jfv-00		See <https://github.com/reschke/json-fields> for a proof-of-concept
			(in development).
			Appendix D. Change Log
			This section is to be removed before publishing as an RFC.
			D.1. Since draft-reschke-http-jfv-00
	Editorial fixes + working on the TODOs.		Editorial fixes + working on the TODOs.
	B.2. Since draft-reschke-http-jfv-01		D.2. Since draft-reschke-http-jfv-01
	Mention slightly increased risk of smuggling information in header		Mention slightly increased risk of smuggling information in header
	field values.		field values.
	B.3. Since draft-reschke-http-jfv-02		D.3. Since draft-reschke-http-jfv-02
	Mention Kazuho Oku's proposal for abbreviated forms.		Mention Kazuho Oku's proposal for abbreviated forms.
	Added a bit of text about the motivation for a concrete JSON subset		Added a bit of text about the motivation for a concrete JSON subset
	(ack Cory Benfield).		(ack Cory Benfield).
	Expand I18N section.		Expand I18N section.
	B.4. Since draft-reschke-http-jfv-03		D.4. Since draft-reschke-http-jfv-03
	Mention relation to KEY header field.		Mention relation to KEY header field.
	B.5. Since draft-reschke-http-jfv-04		D.5. Since draft-reschke-http-jfv-04
	Between June and December 2016, this was a work item of the HTTP		Between June and December 2016, this was a work item of the HTTP
	working group (see <https://datatracker.ietf.org/doc/draft-ietf-		working group (see <https://datatracker.ietf.org/doc/draft-ietf-
	httpbis-jfv/>). Work (if any) continues now on		httpbis-jfv/>). Work (if any) continues now on
	<https://datatracker.ietf.org/doc/draft-reschke-http-jfv/>.		<https://datatracker.ietf.org/doc/draft-reschke-http-jfv/>.
	Changes made while this was a work item of the HTTP Working Group:		Changes made while this was a work item of the HTTP Working Group:
	B.6. Since draft-ietf-httpbis-jfv-00		D.6. Since draft-ietf-httpbis-jfv-00
	Added example for "Accept-Encoding" (inspired by Kazuho's feedback),		Added example for "Accept-Encoding" (inspired by Kazuho's feedback),
	showing a potential way to optimize the format when default values		showing a potential way to optimize the format when default values
	apply.		apply.
	B.7. Since draft-ietf-httpbis-jfv-01		D.7. Since draft-ietf-httpbis-jfv-01
	Add interop discussion, building on I-JSON and ECMA-262 (see		Add interop discussion, building on I-JSON and ECMA-262 (see
	<https://github.com/httpwg/http-extensions/issues/225>).		<https://github.com/httpwg/http-extensions/issues/225>).
	B.8. Since draft-ietf-httpbis-jfv-02		D.8. Since draft-ietf-httpbis-jfv-02
	Move non-essential parts into appendix.		Move non-essential parts into appendix.
	Updated XHR reference.		Updated XHR reference.
	B.9. Since draft-reschke-http-jfv-05		D.9. Since draft-reschke-http-jfv-05
	Add meat to "Using this Format in Header Field Definitions".		Add meat to "Using this Format in Header Field Definitions".
	Add a few lines on the relation to "Key".		Add a few lines on the relation to "Key".
	Summarize current use of the format.		Summarize current use of the format.
	B.10. Since draft-reschke-http-jfv-06		D.10. Since draft-reschke-http-jfv-06
	RFC 5987 is obsoleted by RFC 8187.		RFC 5987 is obsoleted by RFC 8187.
	Update CLEARSITE comment.		Update CLEARSITE comment.
	B.11. Since draft-reschke-http-jfv-07		D.11. Since draft-reschke-http-jfv-07
	Update JSON and HSTRUCT references.		Update JSON and HSTRUCT references.
	FEATUREPOL doesn't use JSON syntax anymore.		FEATUREPOL doesn't use JSON syntax anymore.
	B.12. Since draft-reschke-http-jfv-08		D.12. Since draft-reschke-http-jfv-08
	Update HSTRUCT reference.		Update HSTRUCT reference.
	Update notes about CLEARSITE and FEATUREPOL.		Update notes about CLEARSITE and FEATUREPOL.
	B.13. Since draft-reschke-http-jfv-09		D.13. Since draft-reschke-http-jfv-09
	Update HSTRUCT and FEATUREPOL references.		Update HSTRUCT and FEATUREPOL references.
	Update note about REPORTING.		Update note about REPORTING.
	Changed category to "informational".		Changed category to "informational".
	B.14. Since draft-reschke-http-jfv-10		D.14. Since draft-reschke-http-jfv-10
	Update HSTRUCT reference.		Update HSTRUCT reference.
	B.15. Since draft-reschke-http-jfv-11		D.15. Since draft-reschke-http-jfv-11
	Update HSTRUCT reference.		Update HSTRUCT reference.
	Update note about FEATUREPOL (now using Structured Fields).		Update note about FEATUREPOL (now using Structured Fields).
	Reference [HTTP] instead if RFC723* and adjust (header) field		Reference [HTTP] instead if RFC723* and adjust (header) field
	terminology accordingly.		terminology accordingly.
	Remove discussion about the relation to KEY (as that spec is dormant:		Remove discussion about the relation to KEY (as that spec is dormant:
	<https://datatracker.ietf.org/doc/draft-ietf-httpbis-key/>).		<https://datatracker.ietf.org/doc/draft-ietf-httpbis-key/>).
	Remove appendices "Examples" and "Discussion".		Remove appendices "Examples" and "Discussion".
	Mark "Use of JSON Field Value Encoding in the Wild" for removal in		Mark "Use of JSON Field Value Encoding in the Wild" for removal in
	RFC.		RFC.
	B.16. Since draft-reschke-http-jfv-12		D.16. Since draft-reschke-http-jfv-12
	Update HTTP reference and update terminology some more.		Update HTTP reference and update terminology some more.
	Update HSTRUCT reference (now RFC 8941).		Update HSTRUCT reference (now RFC 8941).
			D.17. Since draft-reschke-http-jfv-13
			Update HTTP reference.
			Mention test implementation.
			Clarify that Unicode unpaired surrogates or Noncharacters must not be
			sent.
			Rewrite text about [RFC8941], add appendix comparing both formats.
			And send/receive examples.
	Acknowledgements		Acknowledgements
	Thanks go to the Hypertext Transfer Protocol Working Group		Thanks go to the Hypertext Transfer Protocol Working Group
	participants.		participants.
	Author's Address		Author's Address
	Julian F. Reschke		Julian F. Reschke
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
End of changes. 39 change blocks.
	77 lines changed or deleted		220 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/