draft-ietf-httpbis-retrofit-01.txt		draft-ietf-httpbis-retrofit-02.txt
	Network Working Group M. Nottingham		Network Working Group M. Nottingham
	Internet-Draft 23 April 2022		Internet-Draft 11 May 2022
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 25 October 2022		Expires: 12 November 2022
	Retrofit Structured Fields for HTTP		Retrofit Structured Fields for HTTP
	draft-ietf-httpbis-retrofit-01		draft-ietf-httpbis-retrofit-02
	Abstract		Abstract
	This specification defines how a selection of existing HTTP fields		This specification nominates a selection of existing HTTP fields as
	can be handled as Structured Fields.		having syntax that is compatible with Structured Fields, so that they
			can be handled as such (subject to certain caveats).
			To accommodate some additional fields whose syntax is not compatible,
			it also defines mappings of their semantics into new Structured
			Fields. It does not specify how to negotiate their use.
	About This Document		About This Document
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	Status information for this document may be found at		Status information for this document may be found at
	https://datatracker.ietf.org/doc/draft-ietf-httpbis-retrofit/.		https://datatracker.ietf.org/doc/draft-ietf-httpbis-retrofit/.
	Discussion of this document takes place on the HTTP Working Group		Discussion of this document takes place on the HTTP Working Group
	mailing list (mailto:ietf-http-wg@w3.org), which is archived at		mailing list (mailto:ietf-http-wg@w3.org), which is archived at
	skipping to change at page 1, line 45 ¶		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 12 November 2022.
	This Internet-Draft will expire on 25 October 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 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
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 31 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
	2. Compatible Fields . . . . . . . . . . . . . . . . . . . . . . 3		2. Compatible Fields . . . . . . . . . . . . . . . . . . . . . . 3
	3. Mapped Fields . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Mapped Fields . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3.1. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.2. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3.2. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.3. ETags . . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.3. ETags . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.5. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 10		3.5. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 10
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6. Normative References . . . . . . . . . . . . . . . . . . . . 12		6. Normative References . . . . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
	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. Header fields that are defined as		use by new HTTP field values. Fields that are defined as Structured
	Structured Fields can realise a number of benefits, including:		Fields can realise a number of benefits, including:
	* Improved interoperability and security: precisely defined parsing		* Improved interoperability and security: precisely defined parsing
	and serialisation algorithms are typically not available for		and serialisation algorithms are typically not available for
	fields defined with just ABNF and/or prose.		fields defined with just ABNF and/or prose.
	* Reuse of common implementations: many parsers for other fields are		* Reuse of common implementations: many parsers for other fields are
	specific to a single field or a small family of fields		specific to a single field or a small family of fields.
	* Canonical form: because a deterministic serialisation algorithm is		* Canonical form: because a deterministic serialisation algorithm is
	defined for each type, Structure Fields have a canonical		defined for each type, Structure Fields have a canonical
	representation		representation.
	* Enhanced API support: a regular data model makes it easier to		* Enhanced API support: a regular data model makes it easier to
	expose field values as a native data structure in implementations		expose field values as a native data structure in implementations.
	* Alternative serialisations: While [STRUCTURED-FIELDS] defines a		* Alternative serialisations: While [STRUCTURED-FIELDS] defines a
	textual serialisation of that data model, other, more efficient		textual serialisation of that data model, other, more efficient
	serialisations of the underlying data model are also possible.		serialisations of the underlying data model are also possible.
	However, a field needs to be defined as a Structured Field for these		However, a field needs to be defined as a Structured Field for these
	benefits to be realised. Many existing fields are not, making up the		benefits to be realised. Many existing fields are not, making up the
	bulk of header and trailer fields seen in HTTP traffic on the		bulk of header and trailer fields seen in HTTP traffic on the
	internet.		internet.
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 32 ¶
	can be handled as Structured Fields, so that these benefits can be		can be handled as Structured Fields, so that these benefits can be
	realised -- thereby making them Retrofit Structured Fields.		realised -- thereby making them Retrofit Structured Fields.
	It does so using two techniques. Section 2 lists compatible fields		It does so using two techniques. Section 2 lists compatible fields
	-- those that can be handled as if they were Structured Fields due to		-- those that can be handled as if they were Structured Fields due to
	the similarity of their defined syntax to that in Structured Fields.		the similarity of their defined syntax to that in Structured Fields.
	Section 3 lists mapped fields -- those whose syntax needs to be		Section 3 lists mapped fields -- those whose syntax needs to be
	transformed into an underlying data model which is then mapped into		transformed into an underlying data model which is then mapped into
	that defined by Structured Fields.		that defined by Structured Fields.
	While implementations can parse and serialise compatible fields as		Note that while implementations can parse and serialise compatible
	Structured Fields subject to the caveats in Section 2, a sender		fields as Structured Fields subject to the caveats in Section 2, a
	cannot generate mapped fields from Section 3 and expect them to be		sender cannot generate mapped fields from Section 3 and expect them
	understood and acted upon by the recipient without prior negotiation.		to be understood and acted upon by the recipient without prior
	This specification does not define such a mechanism.		negotiation. This specification does not define such a mechanism.
	1.1. Notational Conventions		1.1. Notational Conventions
	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.
	2. Compatible Fields		2. Compatible Fields
	skipping to change at page 6, line 27 ¶		skipping to change at page 6, line 27 ¶
	+----------------------------------+-----------------+		+----------------------------------+-----------------+
	| 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		Table 1: Compatible Fields
	Note the following caveats regarding compatibility:		Note the following caveats regarding compatibility:
	Parameter and Dictionary keys: HTTP parameter names are case-		Parameter and Dictionary keys: HTTP parameter names are case-
	insensitive (per Section 5.6.6 of [HTTP]), but Structured Fields		insensitive (per Section 5.6.6 of [HTTP]), but Structured Fields
	require them to be all-lowercase. Although the vast majority of		require them to be all-lowercase. Although the vast majority of
	parameters seen in typical traffic are all-lowercase,		parameters seen in typical traffic are all-lowercase,
	compatibility can be improved by force-lowercasing parameters when		compatibility can be improved by force-lowercasing parameters when
	encountered. Likewise, many Dictionary-based fields (e.g., Cache-		encountered. Likewise, many Dictionary-based fields (e.g., Cache-
	Control, Expect-CT, Pragma, Prefer, Preference-Applied, Surrogate-		Control, Expect-CT, Pragma, Prefer, Preference-Applied, Surrogate-
	Control) have case-insensitive keys, and compatibility can be		Control) have case-insensitive keys, and compatibility can be
	improved by force-lowercasing them.		improved by force-lowercasing them.
	Parameter delimitation: The parameters rule in HTTP (see		Parameter delimitation: The parameters rule in HTTP (see
	Section 5.6.6 of [HTTP]) allows whitespace before the ";"		Section 5.6.6 of [HTTP]) allows whitespace before the ";"
	delimiter, but Structured Fields does not. Compatibility can be		delimiter, but Structured Fields does not. Compatibility can be
	improved by allowing such whitespace.		improved by allowing such whitespace.
	String quoting: Section 5.6.4 of [HTTP] allows backslash-escaping		String quoting: Section 5.6.4 of [HTTP] allows backslash-escaping
	most characters in quoted strings, whereas Structured Field		most characters in quoted strings, whereas Structured Field
	Strings only escapes "" and DQUOTE. Compatibility can be improved		Strings only escape "\" and DQUOTE. Compatibility can be improved
	by unescaping other characters before processing as Strings.		by unescaping other characters before processing as Strings.
	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 parsed as Structured Field Tokens.		be able to be parsed as Structured Field Tokens.
	skipping to change at page 7, line 40 ¶		skipping to change at page 7, line 40 ¶
	not uncommon for implementations to mistakenly send multiple		not uncommon for implementations to mistakenly send multiple
	values. See Section 8.6 of [HTTP] for handling requirements.		values. See Section 8.6 of [HTTP] for handling requirements.
	Retry-After: Only the delta-seconds form of Retry-After is		Retry-After: Only the delta-seconds form of Retry-After is
	supported; a Retry-After value containing a http-date will need to		supported; a Retry-After value containing a http-date will need to
	be either converted into delta-seconds or represented as a raw		be either converted into delta-seconds or represented as a raw
	value.		value.
	3. Mapped Fields		3. Mapped Fields
	Some HTTP fields can have their values represented in Structured		Some HTTP field values have syntax that cannot be successfully parsed
	Fields by mapping them into its data types and then serialising the		as Structured Fields. Instead, it is necessary to map them into a
	result using an alternative field name.		separate Structured Field with an alternative name.
	For example, the Date HTTP header field carries a string representing		For example, the Date HTTP header field carries a date:
	a date:
	Date: Sun, 06 Nov 1994 08:49:37 GMT		Date: Sun, 06 Nov 1994 08:49:37 GMT
	Its value is more efficiently represented as an integer number of		Its value is more efficiently represented as an Integer number of
	delta seconds from the Unix epoch (00:00:00 UTC on 1 January 1970,		delta seconds from the Unix epoch (00:00:00 UTC on 1 January 1970,
	minus leap seconds). Thus, the example above would be mapped as:		minus leap seconds). Thus, the example above would be mapped to:
	SF-Date: 784072177		SF-Date: 784072177
	As in Section 2, these fields are unable to represent values that are		As in Section 2, these fields are unable to carry values that are not
	not parseable, and so an application using this specification will		valid Structured Fields, and so an application using this
	need to how to support such values. Typically, handling them using		specification will need to how to support such values. Typically,
	the original field name is sufficient.		handling them using the original field name is sufficient.
	Each field name listed below indicates a replacement field name and a		Each field name listed below indicates a replacement field name and a
	means of mapping its original value into a Structured Field.		means of mapping its original value into a Structured Field.
	3.1. URLs		3.1. URLs
	The field names in Table 2 (paired with their mapped field names)		The field names in Table 2 (paired with their mapped field names)
	have values that can be represented as Structured Fields by		have values that can be mapped into Structured Fields by treating the
	considering the original field's value as a string.		original field's value as a String.
	+==================+=====================+		+==================+=====================+
	| Field Name | Mapped Field Name |		| Field Name | Mapped Field Name |
	+==================+=====================+		+==================+=====================+
	| Content-Location | SF-Content-Location |		| Content-Location | SF-Content-Location |
	+------------------+---------------------+		+------------------+---------------------+
	| Location | SF-Location |		| Location | SF-Location |
	+------------------+---------------------+		+------------------+---------------------+
	| Referer | SF-Referer |		| Referer | SF-Referer |
	+------------------+---------------------+		+------------------+---------------------+
	Table 2		Table 2: URL Fields
	For example, a Location field could be represented as:		For example, a Location field could be mapped as:
	SF-Location: "https://example.com/foo"		SF-Location: "https://example.com/foo"
	3.2. Dates		3.2. Dates
	The field names in Table 3 (paired with their mapped field names)		The field names in Table 3 (paired with their mapped field names)
	have values that can be represented as Structured Fields by parsing		have values that can be mapped into Structured Fields by parsing
	their payload according to Section 5.6.7 of [HTTP] and representing		their payload according to Section 5.6.7 of [HTTP] and representing
	the result as an integer number of seconds delta from the Unix Epoch		the result as an Integer number of seconds delta from the Unix Epoch
	(00:00:00 UTC on 1 January 1970, minus leap seconds).		(00:00:00 UTC on 1 January 1970, minus leap seconds).
	+=====================+===================+		+=====================+===================+
	| Field Name | Mapped Field Name |		| Field Name | Mapped Field Name |
	+=====================+===================+		+=====================+===================+
	| Date | SF-Date |		| Date | SF-Date |
	+---------------------+-------------------+		+---------------------+-------------------+
	| Expires | SF-Expires |		| Expires | SF-Expires |
	+---------------------+-------------------+		+---------------------+-------------------+
	| If-Modified-Since | SF-IMS |		| If-Modified-Since | SF-IMS |
	+---------------------+-------------------+		+---------------------+-------------------+
	| If-Unmodified-Since | SF-IUS |		| If-Unmodified-Since | SF-IUS |
	+---------------------+-------------------+		+---------------------+-------------------+
	| Last-Modified | SF-LM |		| Last-Modified | SF-LM |
	+---------------------+-------------------+		+---------------------+-------------------+
	Table 3		Table 3: Date Fields
	For example, an Expires field could be represented as:		For example, an Expires field could be mapped as:
	SF-Expires: 1571965240		SF-Expires: 1571965240
	3.3. ETags		3.3. ETags
	The field value of the ETag header field can be represented as a		The field value of the ETag header field can be mapped into the SF-
	String Structured Field by representing the entity-tag as a string,		ETag Structured Field by representing the entity-tag as a String, and
	and the weakness flag as a boolean "w" parameter on it, where true		the weakness flag as a Boolean "w" parameter on it, where true
	indicates that the entity-tag is weak; if 0 or unset, the entity-tag		indicates that the entity-tag is weak; if 0 or unset, the entity-tag
	is strong.		is strong.
	For example:		For example:
	SF-ETag: "abcdef"; w=?1		SF-ETag: "abcdef"; w=?1
	If-None-Match's field value can be represented as SF-INM, which is a		If-None-Match's field value can be mapped into the SF-INM Structured
	List of the structure described above.		Field, which is a List of the structure described above.
	For example:		For example:
	SF-INM: "abcdef"; w=?1, "ghijkl"		SF-INM: "abcdef"; w=?1, "ghijkl"
	3.4. Links		3.4. Links
	The field value of the Link header field [RFC8288] can be represented		The field value of the Link header field [RFC8288] can be mapped into
	in the SF-Link List Structured Field by representing the URI-		the SF-Link List Structured Field by considering the URI-Reference as
	Reference as a string, and link-param as parameters.		a String, and link-param as Parameters.
	For example:		For example:
	SF-Link: "/terms"; rel="copyright"; anchor="#foo"		SF-Link: "/terms"; rel="copyright"; anchor="#foo"
	3.5. Cookies		3.5. Cookies
	The field values of the Cookie and Set-Cookie fields [RFC6265] can be		The field values of the Cookie and Set-Cookie fields [COOKIES] can be
	represented in the SF-Cookie Structured Field (a List) and SF-Set-		mapped into the SF-Cookie Structured Field (a List) and SF-Set-Cookie
	Cookie Structured Field (a Dictionary), respectively.		Structured Field (a Dictionary), respectively.
	In each case, cookie names are serialized as tokens, whereas their		In each case, cookie names are Tokens. Their values are Strings,
	values are serialised as Strings, unless they can be represented		unless they can be represented accurately and unambiguously using the
	accurately and unambiguously using the textual representation of		textual representation of another structured types (e.g., an Integer
	another structured types (e.g., an Integer or Decimal).		or Decimal).
	Set-Cookie parameters map to parameters on the appropriate SF-Set-		Set-Cookie parameters map to Parameters on the appropriate SF-Set-
	Cookie member, with the parameter name being forced to lowercase.		Cookie member, with the parameter name being forced to lowercase.
	Set-Cookie parameter values are Strings unless a specific type is		Set-Cookie parameter values are Strings unless a specific type is
	defined. This specification defines the parameter types in Table 4.		defined for them. This specification defines the parameter types in
			Table 4.
	+================+=================+		+================+=================+
	| Parameter Name | Structured Type |		| Parameter Name | Structured Type |
	+================+=================+		+================+=================+
			| HttpOnly | Boolean |
			+----------------+-----------------+
			| Expires | Integer |
			+----------------+-----------------+
	| Max-Age | Integer |		| Max-Age | Integer |
	+----------------+-----------------+		+----------------+-----------------+
	| Secure | Boolean |		| Secure | Boolean |
	+----------------+-----------------+		+----------------+-----------------+
	| HttpOnly | Boolean |
	+----------------+-----------------+
	| SameSite | Token |		| SameSite | Token |
	+----------------+-----------------+		+----------------+-----------------+
	Table 4		Table 4: Set-Cookie Parameter Types
	Note that cookies in both fields are separated by commas, not		Expires is mapped to an Integer representation of parsed-cookie-date
	semicolons, and multiple cookies can appear in each field.		(see Part x.x of [COOKIES]) expressed as a number of seconds delta
			from the Unix Epoch (00:00:00 UTC on 1 January 1970, minus leap
			seconds).
			Note that although this mapping is very similar to the syntax of
			Cookie and Set-Cookie headers, cookies in both fields are separated
			by commas, not semicolons, and multiple cookies can appear in each
			field.
	For example:		For example:
	SF-Set-Cookie: lang=en-US; expires="Wed, 09 Jun 2021 10:18:14 GMT";		SF-Set-Cookie: lang="en-US"; expires="Wed, 09 Jun 2021 10:18:14 GMT";
	samesite=Strict		samesite=Strict; secure=?1
	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		The "Structured Type" column indicates the type of the field (per
	RFC8941), if any, and may be "Dictionary", "List" or "Item". A		RFC8941), if any, and may be "Dictionary", "List" or "Item". A
	prefix of "*" indicates that it is a retrofit type (i.e., not		prefix of "*" indicates that it is a retrofit type (i.e., not
	natively Structured); see [this specification].		natively Structured); see [this specification].
	skipping to change at page 11, line 23 ¶		skipping to change at page 12, line 10 ¶
	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.
	+=====================+=================+		+=====================+=================+
	| Field Name | Structured Type |		| Field Name | Structured Type |
	+=====================+=================+		+=====================+=================+
	| SF-Content-Location | String |		| SF-Content-Location | String |
	+---------------------+-----------------+		+---------------------+-----------------+
	| SF-Location | String |		| SF-Cookie | List |
	+---------------------+-----------------+
	| SF-Referer | String |
	+---------------------+-----------------+		+---------------------+-----------------+
	| SF-Date | Item |		| SF-Date | Item |
	+---------------------+-----------------+		+---------------------+-----------------+
			| SF-ETag | Item |
			+---------------------+-----------------+
	| SF-Expires | Item |		| SF-Expires | Item |
	+---------------------+-----------------+		+---------------------+-----------------+
	| SF-IMS | Item |		| SF-IMS | Item |
	+---------------------+-----------------+		+---------------------+-----------------+
			| SF-INM | List |
			+---------------------+-----------------+
	| SF-IUS | Item |		| SF-IUS | Item |
	+---------------------+-----------------+		+---------------------+-----------------+
	| SF-LM | Item |		| SF-Link | List |
	+---------------------+-----------------+		+---------------------+-----------------+
	| SF-ETag | Item |		| SF-LM | Item |
	+---------------------+-----------------+		+---------------------+-----------------+
	| SF-INM | List |		| SF-Location | String |
	+---------------------+-----------------+		+---------------------+-----------------+
	| SF-Link | List |		| SF-Referer | String |
	+---------------------+-----------------+		+---------------------+-----------------+
	| SF-Set-Cookie | Dictionary |		| SF-Set-Cookie | Dictionary |
	+---------------------+-----------------+		+---------------------+-----------------+
	| SF-Cookie | List |
	+---------------------+-----------------+
	Table 5		Table 5: New Fields
	Finally, add the indicated structured type for each existing registry		Finally, add the indicated Structured Type for each existing registry
	entry below:		entry listed in Table 6.
	+==========================================+=================+		+==========================================+=================+
	| Field Name | Structured Type |		| Field Name | Structured Type |
	+==========================================+=================+		+==========================================+=================+
	| Accept-CH | List |		| Accept-CH | List |
	+------------------------------------------+-----------------+		+------------------------------------------+-----------------+
	| Cache-Status | List |		| Cache-Status | List |
	+------------------------------------------+-----------------+		+------------------------------------------+-----------------+
	| CDN-Cache-Control | Dictionary |		| CDN-Cache-Control | Dictionary |
	+------------------------------------------+-----------------+		+------------------------------------------+-----------------+
	| Cross-Origin-Opener-Policy | Item |
	+------------------------------------------+-----------------+
	| Cross-Origin-Opener-Policy-Report-Only | Item |
	+------------------------------------------+-----------------+
	| Cross-Origin-Embedder-Policy | Item |		| Cross-Origin-Embedder-Policy | Item |
	+------------------------------------------+-----------------+		+------------------------------------------+-----------------+
	| Cross-Origin-Embedder-Policy-Report-Only | Item |		| Cross-Origin-Embedder-Policy-Report-Only | Item |
	+------------------------------------------+-----------------+		+------------------------------------------+-----------------+
			| Cross-Origin-Opener-Policy | Item |
			+------------------------------------------+-----------------+
			| Cross-Origin-Opener-Policy-Report-Only | Item |
			+------------------------------------------+-----------------+
	| Origin-Agent-Cluster | Item |		| Origin-Agent-Cluster | Item |
	+------------------------------------------+-----------------+		+------------------------------------------+-----------------+
	| Priority | Dictionary |		| Priority | Dictionary |
	+------------------------------------------+-----------------+		+------------------------------------------+-----------------+
	| Proxy-Status | List |		| Proxy-Status | List |
	+------------------------------------------+-----------------+		+------------------------------------------+-----------------+
	Table 6		Table 6: Existing Fields
	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 other implementations 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
	in a chain (e.g., an intermediary). However, given the considerable		in a chain (e.g., an intermediary). However, given the considerable
	variance in parsers already deployed, convergence towards a single		variance in parsers already deployed, convergence towards a single
	parsing algorithm is likely to have a net security benefit in the		parsing algorithm is likely to have a net security benefit in the
	longer term.		longer term.
	Section 3 defines alternative representations of existing fields.		Section 3 defines alternative representations of existing fields.
	Because downstream consumers might interpret the message differently		Because downstream consumers might interpret the message differently
	based upon whether they recognise the alternative representation,		based upon whether they recognise the alternative representation,
	implementations are prohibited from generating such fields unless		implementations are prohibited from generating such fields unless
	they have negotiated support for them with their peer. This		they have negotiated support for them with their peer. This
	specification does not define such a mechanism, but any such		specification does not define such a mechanism, but any such
	definition needs to consider the implications of doing so carefully.		definition needs to consider the implications of doing so carefully.
	6. Normative References		6. Normative References
			[COOKIES] Chen, L., Englehardt, S., West, M., and J. Wilander,
			"Cookies: HTTP State Management Mechanism", Work in
			Progress, Internet-Draft, draft-ietf-httpbis-rfc6265bis-
			10, 24 April 2022, <https://datatracker.ietf.org/doc/html/
			draft-ietf-httpbis-rfc6265bis-10>.
	[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP		[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
	Semantics", Work in Progress, Internet-Draft, draft-ietf-		Semantics", Work in Progress, Internet-Draft, draft-ietf-
	httpbis-semantics-19, 12 September 2021,		httpbis-semantics-19, 12 September 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	semantics-19>.		semantics-19>.
	[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/rfc/rfc2119>.		<https://www.rfc-editor.org/rfc/rfc2119>.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011,
	<https://www.rfc-editor.org/rfc/rfc6265>.
	[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/rfc/rfc8174>.		May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
	[RFC8288] Nottingham, M., "Web Linking", RFC 8288,		[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
	DOI 10.17487/RFC8288, October 2017,		DOI 10.17487/RFC8288, October 2017,
	<https://www.rfc-editor.org/rfc/rfc8288>.		<https://www.rfc-editor.org/rfc/rfc8288>.
	[STRUCTURED-FIELDS]		[STRUCTURED-FIELDS]
	Nottingham, M. and P-H. Kamp, "Structured Field Values for		Nottingham, M. and P-H. Kamp, "Structured Field Values for
End of changes. 53 change blocks.
	89 lines changed or deleted		104 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/