draft-ietf-httpbis-jfv-01.txt		draft-ietf-httpbis-jfv-02.txt
	HTTP Working Group J. Reschke		HTTP Working Group J. Reschke
	Internet-Draft greenbytes		Internet-Draft greenbytes
	Intended status: Standards Track July 8, 2016		Intended status: Standards Track October 24, 2016
	Expires: January 9, 2017		Expires: April 27, 2017
	A JSON Encoding for HTTP Header Field Values		A JSON Encoding for HTTP Header Field Values
	draft-ietf-httpbis-jfv-01		draft-ietf-httpbis-jfv-02
	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 header fields.		values in HTTP header fields.
	Editorial Note (To be removed by RFC Editor before publication)		Editorial Note (To be removed by RFC Editor before publication)
	Discussion of this draft takes place on the HTTPBIS working group		Discussion of this draft takes place on the HTTPBIS working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 January 9, 2017.		This Internet-Draft will expire on April 27, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	3. Sender Requirements . . . . . . . . . . . . . . . . . . . . . 4		3. Sender Requirements . . . . . . . . . . . . . . . . . . . . . 4
	4. Recipient Requirements . . . . . . . . . . . . . . . . . . . . 5		4. Recipient Requirements . . . . . . . . . . . . . . . . . . . . 5
	5. Using this Format in Header Field Definitions . . . . . . . . 5		5. Using this Format in Header Field Definitions . . . . . . . . 5
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	6.1. Content-Length . . . . . . . . . . . . . . . . . . . . . . 5		6.1. Content-Length . . . . . . . . . . . . . . . . . . . . . . 5
	6.2. Content-Disposition . . . . . . . . . . . . . . . . . . . 6		6.2. Content-Disposition . . . . . . . . . . . . . . . . . . . 6
	6.3. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 7		6.3. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 7
	6.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 8		6.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 8
	7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8. Deployment Considerations . . . . . . . . . . . . . . . . . . 9		8. Deployment Considerations . . . . . . . . . . . . . . . . . . 9
	9. Internationalization Considerations . . . . . . . . . . . . . 9		9. Interoperability Considerations . . . . . . . . . . . . . . . 9
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 10		9.1. Encoding and Characters . . . . . . . . . . . . . . . . . 9
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		9.2. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 10
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 10		9.3. Object Constraints . . . . . . . . . . . . . . . . . . . . 10
	11.2. Informative References . . . . . . . . . . . . . . . . . . 11		10. Internationalization Considerations . . . . . . . . . . . . . 10
			11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
			12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
			12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
			12.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Appendix A. Change Log (to be removed by RFC Editor before		Appendix A. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 11		publication) . . . . . . . . . . . . . . . . . . . . 12
	A.1. Since draft-reschke-http-jfv-00 . . . . . . . . . . . . . 11		A.1. Since draft-reschke-http-jfv-00 . . . . . . . . . . . . . 12
	A.2. Since draft-reschke-http-jfv-01 . . . . . . . . . . . . . 12		A.2. Since draft-reschke-http-jfv-01 . . . . . . . . . . . . . 12
	A.3. Since draft-reschke-http-jfv-02 . . . . . . . . . . . . . 12		A.3. Since draft-reschke-http-jfv-02 . . . . . . . . . . . . . 12
	A.4. Since draft-reschke-http-jfv-03 . . . . . . . . . . . . . 12		A.4. Since draft-reschke-http-jfv-03 . . . . . . . . . . . . . 13
	A.5. Since draft-reschke-http-jfv-04 . . . . . . . . . . . . . 12		A.5. Since draft-reschke-http-jfv-04 . . . . . . . . . . . . . 13
	A.6. Since draft-ietf-httpbis-jfv-00 . . . . . . . . . . . . . 12		A.6. Since draft-ietf-httpbis-jfv-00 . . . . . . . . . . . . . 13
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 12		A.7. Since draft-ietf-httpbis-jfv-01 . . . . . . . . . . . . . 13
			Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	Defining syntax for new HTTP header fields ([RFC7230], Section 3.2)		Defining syntax for new HTTP header fields ([RFC7230], Section 3.2)
	is non-trivial. Among the commonly encountered problems are:		is non-trivial. Among the commonly encountered problems are:
	o There is no common syntax for complex field values. Several well-		o There is no common syntax for complex field values. Several well-
	known header fields do use a similarly looking syntax, but it is		known header fields do use a similarly looking syntax, but it is
	hard to write generic parsing code that will both correctly handle		hard to write generic parsing code that will both correctly handle
	valid field values but also reject invalid ones.		valid field values but also reject invalid ones.
	skipping to change at page 9, line 43 ¶		skipping to change at page 9, line 43 ¶
	[[anchor8: Mention potential "Key" header field extension ([KEY]).]]		[[anchor8: Mention potential "Key" header field extension ([KEY]).]]
	8. Deployment Considerations		8. Deployment Considerations
	This JSON-based syntax will only apply to newly introduced header		This JSON-based syntax will only apply to newly introduced header
	fields, thus backwards compatibility is not a problem. That being		fields, thus backwards compatibility is not a problem. That being
	said, it is conceivable that there is existing code that might trip		said, it is conceivable that there is existing code that might trip
	over double quotes not being used for HTTP's quoted-string syntax		over double quotes not being used for HTTP's quoted-string syntax
	(Section 3.2.6 of [RFC7230]).		(Section 3.2.6 of [RFC7230]).
	9. Internationalization Considerations		9. Interoperability Considerations
			The "I-JSON Message Format" specification ([RFC7493]) addresses known
			JSON interoperability pain points. This specification borrows from
			the requirements made over there:
			9.1. Encoding and Characters
			This specification requires that field values use only US-ASCII
			characters, and thus by definition use a subset of UTF-8 (Section 2.1
			of [RFC7493]).
			9.2. Numbers
			Be aware of the issues around number precision, as discussed in
			Section 2.2 of [RFC7493].
			9.3. Object Constraints
			As described in Section 4 of [RFC7159], JSON parser implementations
			differ in the handling of duplicate object names. Therefore, senders
			MUST NOT use duplicate object names, and recipients SHOULD either
			treat field values with duplicate names as invalid (consistent with
			[RFC7493], Section 2.3) or use the lexically last value (consistent
			with [ECMA-262], Section 24.3.1.1).
			Furthermore, ordering of object members is not significant and can
			not be relied upon.
			10. Internationalization Considerations
	In HTTP/1.1, header field values are represented by octet sequences,		In HTTP/1.1, header field values are represented by octet sequences,
	usually used to transmit ASCII characters, with restrictions on the		usually used to transmit ASCII characters, with restrictions on the
	use of certain control characters, and no associated default		use of certain control characters, and no associated default
	character encoding, nor a way to describe it ([RFC7230], Section		character encoding, nor a way to describe it ([RFC7230], Section
	3.2). HTTP/2 does not change this.		3.2). HTTP/2 does not change this.
	This specification maps all characters which can cause problems to		This specification maps all characters which can cause problems to
	JSON escape sequences, thereby solving the HTTP header field		JSON escape sequences, thereby solving the HTTP header field
	internationalization problem.		internationalization problem.
	Future specifications of HTTP might change to allow non-ASCII		Future specifications of HTTP might change to allow non-ASCII
	characters natively. In that case, header fields using the syntax		characters natively. In that case, header fields using the syntax
	defined by this specification would have a simple migration path (by		defined by this specification would have a simple migration path (by
	just stopping to require escaping of non-ASCII characters).		just stopping to require escaping of non-ASCII characters).
	10. Security Considerations		11. Security Considerations
	Using JSON-shaped field values is believed to not introduce any new		Using JSON-shaped field values is believed to not introduce any new
	threads beyond those described in Section 12 of [RFC7159], namely the		threads beyond those described in Section 12 of [RFC7159], namely the
	risk of recipients using the wrong tools to parse them.		risk of recipients using the wrong tools to parse them.
	Other than that, any syntax that makes extensions easy can be used to		Other than that, any syntax that makes extensions easy can be used to
	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.
	11. References		12. References
			12.1. Normative References
	11.1. Normative References
	[RFC0020] Cerf, V., "ASCII format for network interchange",		[RFC0020] Cerf, V., "ASCII format for network interchange",
	STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969,		STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969,
	<http://www.rfc-editor.org/info/rfc20>.		<http://www.rfc-editor.org/info/rfc20>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
	Syntax Specifications: ABNF", STD 68, RFC 5234,		Syntax Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<http://www.rfc-editor.org/info/rfc5234>.		<http://www.rfc-editor.org/info/rfc5234>.
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 32 ¶
	Routing", RFC 7230, DOI 10.17487/RFC7230,		Routing", RFC 7230, DOI 10.17487/RFC7230,
	June 2014,		June 2014,
	<http://www.rfc-editor.org/info/rfc7230>.		<http://www.rfc-editor.org/info/rfc7230>.
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext		[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
	Transfer Protocol (HTTP/1.1): Semantics and		Transfer Protocol (HTTP/1.1): Semantics and
	Content", RFC 7231, DOI 10.17487/RFC7231,		Content", RFC 7231, DOI 10.17487/RFC7231,
	June 2014,		June 2014,
	<http://www.rfc-editor.org/info/rfc7231>.		<http://www.rfc-editor.org/info/rfc7231>.
	11.2. Informative References		[RFC7493] Bray, T., Ed., "The I-JSON Message Format",
			RFC 7493, DOI 10.17487/RFC7493, March 2015,
			<http://www.rfc-editor.org/info/rfc7493>.
			12.2. Informative References
			[ECMA-262] Ecma International, "ECMA-262 6th Edition, The
			ECMAScript 2015 Language Specification",
			Standard ECMA-262, June 2015,
			<http://www.ecma-international.org/ecma-262/6.0/>.
	[ISO-8859-1] International Organization for Standardization,		[ISO-8859-1] International Organization for Standardization,
	"Information technology -- 8-bit single-byte coded		"Information technology -- 8-bit single-byte coded
	graphic character sets -- Part 1: Latin alphabet		graphic character sets -- Part 1: Latin alphabet
	No. 1", ISO/IEC 8859-1:1998, 1998.		No. 1", ISO/IEC 8859-1:1998, 1998.
	[KEY] Fielding, R. and M. Nottingham, "The Key HTTP		[KEY] Fielding, R. and M. Nottingham, "The Key HTTP
	Response Header Field", draft-ietf-httpbis-key-01		Response Header Field", draft-ietf-httpbis-key-01
	(work in progress), March 2016.		(work in progress), March 2016.
	skipping to change at page 12, line 33 ¶		skipping to change at page 13, line 21 ¶
	A.5. Since draft-reschke-http-jfv-04		A.5. Since draft-reschke-http-jfv-04
	Change to HTTP Working Group draft.		Change to HTTP Working Group draft.
	A.6. Since draft-ietf-httpbis-jfv-00		A.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.
			A.7. Since draft-ietf-httpbis-jfv-01
			Add interop discussion, building on I-JSON and ECMA-262 (see
			<https://github.com/httpwg/http-extensions/issues/225>).
	Appendix B. Acknowledgements		Appendix B. 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. 11 change blocks.
	21 lines changed or deleted		68 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/