draft-ietf-httpbis-retrofit-05.txt		draft-ietf-httpbis-retrofit-latest.txt
	Network Working Group M. Nottingham		HTTP Working Group M. Nottingham
	Internet-Draft December 4, 2022		Internet-Draft February 9, 2023
	Updates: 8941 (if approved)
	Intended status: Standards Track		Intended status: Standards Track
	Expires: June 7, 2023		Expires: August 13, 2023
	Retrofit Structured Fields for HTTP		Retrofit Structured Fields for HTTP
	draft-ietf-httpbis-retrofit-05		draft-ietf-httpbis-retrofit-latest
	Abstract		Abstract
	This specification nominates a selection of existing HTTP fields as		This specification nominates a selection of existing HTTP fields as
	having syntax that is compatible with Structured Fields, so that they		having syntax that is compatible with Structured Fields, so that they
	can be handled as such (subject to certain caveats).		can be handled as such (subject to certain caveats).
	To accommodate some additional fields whose syntax is not compatible,		To accommodate some additional fields whose syntax is not compatible,
	it also defines mappings of their semantics into new Structured		it also defines mappings of their semantics into new Structured
	Fields. It does not specify how to negotiate their use.		Fields. It does not specify how to negotiate their use.
	skipping to change at page 2, line 6 ¶		skipping to change at page 2, line 4 ¶
	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 August 13, 2023.
	This Internet-Draft will expire on June 7, 2023.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2023 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
	2. Compatible Fields . . . . . . . . . . . . . . . . . . . . . . 4		2. Compatible Fields . . . . . . . . . . . . . . . . . . . . . . 3
	3. Mapped Fields . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Mapped Fields . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3.2. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.3. ETags . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3.3. ETags . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.4. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.5. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 9		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Normative References . . . . . . . . . . . . . . . . . . . . 11
	6. Normative References . . . . . . . . . . . . . . . . . . . . 12		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	Structured Field Values for HTTP [STRUCTURED-FIELDS] introduced a		Structured Field Values for HTTP [STRUCTURED-FIELDS] introduced a
	data model with associated parsing and serialization algorithms for		data model with associated parsing and serialization algorithms for
	use by new HTTP field values. Fields that are defined as Structured		use by new HTTP field values. Fields that are defined as Structured
	Fields can realise a number of benefits, including:		Fields can realise a number of benefits, including:
	o Improved interoperability and security: precisely defined parsing		o Improved interoperability and security: precisely defined parsing
	and serialisation algorithms are typically not available for		and serialisation algorithms are typically not available for
	skipping to change at page 5, line 36 ¶		skipping to change at page 5, line 29 ¶
	| Vary | List |		| Vary | List |
	| X-Content-Type-Options | Item |		| X-Content-Type-Options | Item |
	| X-Frame-Options | Item |		| X-Frame-Options | Item |
	| X-XSS-Protection | List |		| X-XSS-Protection | List |
	+----------------------------------+-----------------+		+----------------------------------+-----------------+
	Table 1: Compatible Fields		Table 1: Compatible Fields
	Note the following caveats regarding compatibility:		Note the following caveats regarding compatibility:
			Parsing differences: Some values may fail to parse as Structured
			Fields, even though they are valid according to their originally
			specified syntax. For example, HTTP parameter names are case-
			insensitive (per Section 5.6.6 of [HTTP]), but Structured Fields
			require them to be all-lowercase. Likewise, many Dictionary-based
			fields (e.g., Cache-Control, Expect-CT, Pragma, Prefer,
			Preference-Applied, Surrogate-Control) have case-insensitive keys.
			Similarly, the parameters rule in HTTP (see Section 5.6.6 of
			[HTTP]) allows whitespace before the ";" delimiter, but Structured
			Fields does not. And, Section 5.6.4 of [HTTP] allows backslash-
			escaping most characters in quoted strings, whereas Structured
			Field Strings only escape "\" and DQUOTE. The vast majority of
			fields seen in typical traffic do not exhibit these behaviors.
	Error handling: Parsing algorithms specified (or just widely		Error handling: Parsing algorithms specified (or just widely
	implemented) for current HTTP headers may differ from those in		implemented) for current HTTP headers may differ from those in
	Structured Fields in details such as error handling. For example,		Structured Fields in details such as error handling. For example,
	HTTP specifies that repeated directives in the Cache-Control		HTTP specifies that repeated directives in the Cache-Control
	header field have a different precedence than that assigned by a		header field have a different precedence than that assigned by a
	Dictionary structured field (which Cache-Control is mapped to).		Dictionary structured field (which Cache-Control is mapped to).
	Parameter and Dictionary keys: HTTP parameter names are case-
	insensitive (per Section 5.6.6 of [HTTP]), but Structured Fields
	require them to be all-lowercase. Although the vast majority of
	parameters seen in typical traffic are all-lowercase,
	compatibility can be improved by force-lowercasing parameters when
	parsing. Likewise, many Dictionary-based fields (e.g., Cache-
	Control, Expect-CT, Pragma, Prefer, Preference-Applied, Surrogate-
	Control) have case-insensitive keys, and compatibility can be
	improved by force-lowercasing them when parsing.
	Parameter delimitation: The parameters rule in HTTP (see
	Section 5.6.6 of [HTTP]) allows whitespace before the ";"
	delimiter, but Structured Fields does not. Compatibility can be
	improved by allowing such whitespace when parsing.
	String quoting: Section 5.6.4 of [HTTP] allows backslash-escaping
	most characters in quoted strings, whereas Structured Field
	Strings only escape "\" and DQUOTE. Compatibility can be improved
	by unescaping other characters before parsing.
	Token limitations: In Structured Fields, tokens are required to		Token limitations: In Structured Fields, tokens are required to
	begin with an alphabetic character or "*", whereas HTTP tokens		begin with an alphabetic character or "*", whereas HTTP tokens
	allow a wider range of characters. This prevents use of mapped		allow a wider range of characters. This prevents use of mapped
	values that begin with one of these characters. For example,		values that begin with one of these characters. For example,
	media types, field names, methods, range-units, character and		media types, field names, methods, range-units, character and
	transfer codings that begin with a number or special character		transfer codings that begin with a number or special character
	other than "*" might be valid HTTP protocol elements, but will not		other than "*" might be valid HTTP protocol elements, but will not
	be able to be represented as Structured Field Tokens.		be able to be represented as Structured Field Tokens.
	Integer limitations: Structured Fields Integers can have at most 15		Integer limitations: Structured Fields Integers can have at most 15
	skipping to change at page 9, line 5 ¶		skipping to change at page 8, line 46 ¶
	Structured Field, which is a List of the structure described above.		Structured Field, which is a List of the structure described above.
	When a field value contains "*", it is represented as a Token.		When a field value contains "*", it is represented as a Token.
	Likewise, If-Match's field value can be mapped into the SF-If-Match		Likewise, If-Match's field value can be mapped into the SF-If-Match
	Structured Field in the same manner.		Structured Field in the same manner.
	For example:		For example:
	SF-If-None-Match: "abcdef"; w, "ghijkl", *		SF-If-None-Match: "abcdef"; w, "ghijkl", *
	3.4. Links		3.4. Cookies
	The field value of the Link header field [RFC8288] can be mapped into
	the SF-Link List Structured Field by considering the URI-Reference as
	a String, and link-param as Parameters.
	For example, this:
	Link: </terms>; rel="copyright"; anchor="#foo"
	can be mapped to:
	SF-Link: "/terms"; rel="copyright"; anchor="#foo"
	3.5. Cookies
	The field values of the Cookie and Set-Cookie fields [COOKIES] can be		The field values of the Cookie and Set-Cookie fields [COOKIES] can be
	mapped into the SF-Cookie Structured Field (a List) and SF-Set-Cookie		mapped into the SF-Cookie Structured Field (a List) and SF-Set-Cookie
	Structured Field (a List), respectively.		Structured Field (a List), respectively.
	In each case, a cookie is represented as an Inner List containing two		In each case, a cookie is represented as an Inner List containing two
	Items; the cookie name and value. The cookie name is always a		Items; the cookie name and value. The cookie name is always a
	String; the cookie value is a String, unless it can be successfully		String; the cookie value is a String, unless it can be successfully
	parsed as the textual representation of another, bare Item structured		parsed as the textual representation of another, bare Item structured
	type (e.g., Byte Sequence, Decimal, Integer, Token, or Boolean).		type (e.g., Byte Sequence, Decimal, Integer, Token, or Boolean).
	skipping to change at page 10, line 22 ¶		skipping to change at page 9, line 51 ¶
	SF-Set-Cookie: ("lang" "en-US"); expires=@1623233894;		SF-Set-Cookie: ("lang" "en-US"); expires=@1623233894;
	samesite=Strict; secure		samesite=Strict; secure
	SF-Cookie: ("SID" "31d4d96e407aad42"), ("lang" "en-US")		SF-Cookie: ("SID" "31d4d96e407aad42"), ("lang" "en-US")
	4. IANA Considerations		4. IANA Considerations
	Please add the following note to the "Hypertext Transfer Protocol		Please add the following note to the "Hypertext Transfer Protocol
	(HTTP) Field Name Registry":		(HTTP) Field Name Registry":
	The "Structured Type" column indicates the type of the field (per		A prefix of "*" in the Structured Type column indicates that it is
	RFC8941), if any, and may be "Dictionary", "List" or "Item". A		a retrofit type (i.e., not natively Structured); see RFC nnnn.
	prefix of "*" indicates that it is a retrofit type (i.e., not
	natively Structured); see [this specification].
	Note that field names beginning with characters other than ALPHA
	or "*" will not be able to be represented as a Structured Fields
	Token, and therefore may be incompatible with being mapped into
	fields that refer to it; see [this specification].
	Then, add a new column, "Structured Type", with the values from		Then, add a new column, "Structured Type", with the values from
	Section 2 assigned to the nominated registrations, prefixing each		Section 2 assigned to the nominated registrations, prefixing each
	with "*" to indicate that it is a retrofit type.		with "*" to indicate that it is a retrofit type.
	Then, add the field names in Table 5, with the corresponding		Then, add the field names in Table 5, with the corresponding
	Structured Type as indicated, a status of "permanent" and referring		Structured Type as indicated, a status of "permanent" and referring
	to this document.		to this document.
	+------------------------+-----------------+		+------------------------+-----------------+
	skipping to change at page 11, line 17 ¶		skipping to change at page 10, line 25 ¶
	+------------------------+-----------------+		+------------------------+-----------------+
	| SF-Content-Location | Item |		| SF-Content-Location | Item |
	| SF-Cookie | List |		| SF-Cookie | List |
	| SF-Date | Item |		| SF-Date | Item |
	| SF-ETag | Item |		| SF-ETag | Item |
	| SF-Expires | Item |		| SF-Expires | Item |
	| SF-If-Match | List |		| SF-If-Match | List |
	| SF-If-Modified-Since | Item |		| SF-If-Modified-Since | Item |
	| SF-If-None-Match | List |		| SF-If-None-Match | List |
	| SF-If-Unmodified-Since | Item |		| SF-If-Unmodified-Since | Item |
	| SF-Link | List |
	| SF-Last-Modified | Item |		| SF-Last-Modified | Item |
	| SF-Location | Item |		| SF-Location | Item |
	| SF-Referer | Item |		| SF-Referer | Item |
	| SF-Set-Cookie | List |		| SF-Set-Cookie | List |
	+------------------------+-----------------+		+------------------------+-----------------+
	Table 5: New Fields		Table 5: New Fields
	Then, add the indicated Structured Type for each existing registry
	entry listed in Table 6.
	+------------------------------------------+-----------------+
	| Field Name | Structured Type |
	+------------------------------------------+-----------------+
	| Accept-CH | List |
	| Cache-Status | List |
	| CDN-Cache-Control | Dictionary |
	| Cross-Origin-Embedder-Policy | Item |
	| Cross-Origin-Embedder-Policy-Report-Only | Item |
	| Cross-Origin-Opener-Policy | Item |
	| Cross-Origin-Opener-Policy-Report-Only | Item |
	| Origin-Agent-Cluster | Item |
	| Priority | Dictionary |
	| Proxy-Status | List |
	+------------------------------------------+-----------------+
	Table 6: Existing Fields
	Finally, add a new column to the "Cookie Attribute Registry"		Finally, add a new column to the "Cookie Attribute Registry"
	established by [COOKIES] with the title "Structured Type", using		established by [COOKIES] with the title "Structured Type", using
	information from Table 4.		information from Table 4.
	5. Security Considerations		5. Security Considerations
	Section 2 identifies existing HTTP fields that can be parsed and		Section 2 identifies existing HTTP fields that can be parsed and
	serialised with the algorithms defined in [STRUCTURED-FIELDS].		serialised with the algorithms defined in [STRUCTURED-FIELDS].
	Variances from existing parser behavior might be exploitable,		Variances from existing parser behavior might be exploitable,
	particularly if they allow an attacker to target one implementation		particularly if they allow an attacker to target one implementation
	skipping to change at page 12, line 44 ¶		skipping to change at page 11, line 27 ¶
	[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>.
	[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
	DOI 10.17487/RFC8288, October 2017,
	<https://www.rfc-editor.org/info/rfc8288>.
	[STRUCTURED-FIELDS]		[STRUCTURED-FIELDS]
	Nottingham, M. and P. Kamp, "Structured Field Values for		Nottingham, M. and P. Kamp, "Structured Field Values for
	HTTP", draft-ietf-httpbis-sfbis-00 (work in progress),		HTTP", draft-ietf-httpbis-sfbis-01 (work in progress),
	November 2022.		December 2022.
	Author's Address		Author's Address
	Mark Nottingham		Mark Nottingham
	Prahran		Prahran
	Australia		Australia
	Email: mnot@mnot.net		Email: mnot@mnot.net
	URI: https://www.mnot.net/		URI: https://www.mnot.net/
End of changes. 16 change blocks.
	88 lines changed or deleted		33 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/