draft-ietf-httpbis-retrofit-04.txt		draft-ietf-httpbis-retrofit-latest.txt
	Network Working Group M. Nottingham		Network Working Group M. Nottingham
	Internet-Draft June 8, 2022		Internet-Draft September 23, 2022
			Updates: 8941 (if approved)
	Intended status: Standards Track		Intended status: Standards Track
	Expires: December 10, 2022		Expires: March 27, 2023
	Retrofit Structured Fields for HTTP		Retrofit Structured Fields for HTTP
	draft-ietf-httpbis-retrofit-04		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.
			One of those mappings requires introduction of a new Structured
			Fields data type, Date.
	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
	<https://lists.w3.org/Archives/Public/ietf-http-wg/>. Working Group		<https://lists.w3.org/Archives/Public/ietf-http-wg/>. Working Group
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 9 ¶
	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 December 10, 2022.
			This Internet-Draft will expire on March 27, 2023.
	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		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 . . . . . . . . . . . . . . . . . . . . . . 3		2. Compatible Fields . . . . . . . . . . . . . . . . . . . . . . 4
	3. Mapped Fields . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Mapped Fields . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.2. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.3. ETags . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3.3. ETags . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.5. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 8		3.5. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	6. Normative References . . . . . . . . . . . . . . . . . . . . 11		6. Normative References . . . . . . . . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12		Appendix A. The Date Structured Type . . . . . . . . . . . . . . 13
			A.1. Serialising a Date . . . . . . . . . . . . . . . . . . . 13
			A.2. Parsing a Date . . . . . . . . . . . . . . . . . . . . . 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. 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 3, line 46 ¶		skipping to change at page 4, line 5 ¶
	negotiation. 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.
			This document uses the date-time, time-offset, and time-secfrac rules
			from [RFC3339].
	2. Compatible Fields		2. Compatible Fields
	The HTTP fields listed in Table 1 can usually have their values		The HTTP fields listed in Table 1 can usually have their values
	handled as Structured Fields according to the listed parsing and		handled as Structured Fields according to the listed parsing and
	serialisation algorithms in [STRUCTURED-FIELDS], subject to the		serialisation algorithms in [STRUCTURED-FIELDS], subject to the
	listed caveats.		listed caveats.
	The listed types are chosen for compatibility with the defined syntax		The listed types are chosen for compatibility with the defined syntax
	of the field as well as with actual internet traffic. However, not		of the field as well as with actual internet traffic. However, not
	all instances of these fields will successfully parse. This might be		all instances of these fields will successfully parse. This might be
	skipping to change at page 4, line 49 ¶		skipping to change at page 5, line 10 ¶
	| CDN-Loop | List |		| CDN-Loop | List |
	| Clear-Site-Data | List |		| Clear-Site-Data | List |
	| Connection | List |		| Connection | List |
	| Content-Encoding | List |		| Content-Encoding | List |
	| Content-Language | List |		| Content-Language | List |
	| Content-Length | List |		| Content-Length | List |
	| Content-Type | Item |		| Content-Type | Item |
	| Cross-Origin-Resource-Policy | Item |		| Cross-Origin-Resource-Policy | Item |
	| Expect | Dictionary |		| Expect | Dictionary |
	| Expect-CT | Dictionary |		| Expect-CT | Dictionary |
	| Forwarded | Dictionary |
	| Host | Item |		| Host | Item |
	| Keep-Alive | Dictionary |		| Keep-Alive | Dictionary |
	| Max-Forwards | Item |		| Max-Forwards | Item |
	| Origin | Item |		| Origin | Item |
	| Pragma | Dictionary |		| Pragma | Dictionary |
	| Prefer | Dictionary |		| Prefer | Dictionary |
	| Preference-Applied | Dictionary |		| Preference-Applied | Dictionary |
	| Retry-After | Item |		| Retry-After | Item |
	| Sec-WebSocket-Extensions | List |		| Sec-WebSocket-Extensions | List |
	| Sec-WebSocket-Protocol | List |		| Sec-WebSocket-Protocol | List |
	skipping to change at page 6, line 7 ¶		skipping to change at page 6, line 17 ¶
	Strings only escape "\" and DQUOTE. Compatibility can be improved		Strings only escape "\" and DQUOTE. Compatibility can be improved
	by unescaping other characters before parsing.		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 parsed 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
	digits; larger values will not be able to be represented in them.		digits; larger values will not be able to be represented in them.
	IPv6 Literals: Fields whose values contain IPv6 literal addresses		IPv6 Literals: Fields whose values contain IPv6 literal addresses
	(such as CDN-Loop, Host, and Origin) are not able to be		(such as CDN-Loop, Host, and Origin) are not able to be
	represented as Structured Fields Tokens, because the brackets used		represented as Structured Fields Tokens, because the brackets used
	to delimit them are not allowed in Tokens.		to delimit them are not allowed in Tokens.
	Empty Field Values: Empty and whitespace-only field values are		Empty Field Values: Empty and whitespace-only field values are
	skipping to change at page 6, line 47 ¶		skipping to change at page 7, line 9 ¶
	3. Mapped Fields		3. Mapped Fields
	Some HTTP field values have syntax that cannot be successfully parsed		Some HTTP field values have syntax that cannot be successfully parsed
	as Structured Fields. Instead, it is necessary to map them into a		as Structured Fields. Instead, it is necessary to map them into a
	separate Structured Field with an alternative name.		separate Structured Field with an alternative name.
	For example, the Date HTTP header field carries a date:		For example, the Date HTTP header field carries 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 would be mapped to:
	delta seconds from the Unix epoch (00:00:00 UTC on 1 January 1970,
	minus leap seconds). Thus, the example above would be mapped to:		SF-Date: @784111777
	SF-Date: 784072177
	As in Section 2, these fields are unable to carry values that are not		As in Section 2, these fields are unable to carry values that are not
	valid Structured Fields, and so an application using this		valid Structured Fields, and so an application using this
	specification will need to how to support such values. Typically,		specification will need to how to support such values. Typically,
	handling them using 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
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 37 ¶
	+------------------+---------------------+		+------------------+---------------------+
	| 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: URL Fields		Table 2: URL Fields
	For example, a Location field could be mapped as:		For example, this Location field
			Location: https://example.com/foo
			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 mapped into 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, excluding leap seconds).		(00:00:00 UTC on 1 January 1970, excluding leap seconds), using the
			Date Structured Fields data type defined in Appendix A.
	+---------------------+-------------------+		+---------------------+------------------------+
	| 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-If-Modified-Since |
	| If-Unmodified-Since | SF-IUS |		| If-Unmodified-Since | SF-If-Unmodified-Since |
	| Last-Modified | SF-LM |		| Last-Modified | SF-Last-Modified |
	+---------------------+-------------------+		+---------------------+------------------------+
	Table 3: Date Fields		Table 3: Date Fields
	For example, an Expires field could be mapped as:		For example, an Expires field could be mapped as:
	SF-Expires: 1571965240		SF-Expires: @1659578233
	3.3. ETags		3.3. ETags
	The field value of the ETag header field can be mapped into the SF-		The field value of the ETag header field can be mapped into the SF-
	ETag Structured Field by representing the entity-tag as a String, and		ETag Structured Field by representing the entity-tag as a String, 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, this:
	SF-ETag: "abcdef"; w=?1		ETag: W/"abcdef"
	If-None-Match's field value can be mapped into the SF-INM Structured		SF-ETag: "abcdef"; w
	Field, which is a List of the structure described above.
			If-None-Match's field value can be mapped into the SF-If-None-Match
			Structured Field, which is a List of the structure described above.
			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
			Structured Field in the same manner.
	For example:		For example:
	SF-INM: "abcdef"; w=?1, "ghijkl"		SF-If-None-Match: "abcdef"; w, "ghijkl", *
	3.4. Links		3.4. Links
	The field value of the Link header field [RFC8288] can be mapped into		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		the SF-Link List Structured Field by considering the URI-Reference as
	a String, and link-param as Parameters.		a String, and link-param as Parameters.
	For example:		For example, this:
			Link: </terms>; rel="copyright"; anchor="#foo"
			can be mapped to:
	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 [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 Dictionary), respectively.		Structured Field (a List), respectively.
	In each case, cookie names are Tokens. Their values are Strings,		In each case, a cookie is represented as an Inner List containing two
	unless the value can be successfully parsed as the textual		Items; the cookie name and value. The cookie name is always a
	representation of another, bare Item structured type (e.g., Byte		String; the cookie value is a String, unless it can be successfully
	Sequence, Decimal, Integer, Token, or Boolean).		parsed as the textual representation of another, bare Item structured
			type (e.g., Byte Sequence, Decimal, Integer, Token, or Boolean).
	Set-Cookie parameters map to Parameters on the appropriate SF-Set-		Cookie attributes map to Parameters on the Inner List, with the
	Cookie member, with the parameter name being forced to lowercase.		parameter name being forced to lowercase. Cookie attribute values
	Set-Cookie parameter values are Strings unless a specific type is		are Strings unless a specific type is defined for them. This
	defined for them. This specification defines the parameter types in		specification defines types for existing cookie attributes in
	Table 4.		Table 4.
	+----------------+-----------------+		+----------------+-----------------+
	| Parameter Name | Structured Type |		| Parameter Name | Structured Type |
	+----------------+-----------------+		+----------------+-----------------+
			| Domain | String |
	| HttpOnly | Boolean |		| HttpOnly | Boolean |
	| Expires | Integer |		| Expires | Date |
	| Max-Age | Integer |		| Max-Age | Integer |
			| Path | String |
	| Secure | Boolean |		| Secure | Boolean |
	| SameSite | Token |		| SameSite | Token |
	+----------------+-----------------+		+----------------+-----------------+
	Table 4: Set-Cookie Parameter Types		Table 4: Set-Cookie Parameter Types
	Expires is mapped to an Integer representation of parsed-cookie-date		The Expires attribute is mapped to a Date representation of parsed-
	(see Section x.x of [COOKIES]) expressed as a number of seconds delta		cookie-date (see Section 5.1.1 of [COOKIES]).
	from the Unix Epoch (00:00:00 UTC on 1 January 1970, excluding leap
	seconds).
	Note that although this mapping is very similar to the syntax of		For example, these unstructured fields:
	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:		Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT;
			samesite=Strict; secure
			Cookie: SID=31d4d96e407aad42; lang=en-US
	SF-Set-Cookie: lang="en-US"; expires="Wed, 09 Jun 2021 10:18:14 GMT";		can be mapped into:
	samesite=Strict; secure=?1
	SF-Cookie: SID="31d4d96e407aad42", lang="en-US"		SF-Set-Cookie: ("lang" "en-US"); expires=@1623233894;
			samesite=Strict; secure
			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 10, line 13 ¶		skipping to change at page 11, line 5 ¶
	fields that refer to it; see [this specification].		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.
	+---------------------+-----------------+		+------------------------+-----------------+
	| Field Name | Structured Type |		| Field Name | Structured Type |
	+---------------------+-----------------+		+------------------------+-----------------+
	| SF-Content-Location | String |		| 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-IMS | Item |		| SF-If-Match | List |
	| SF-INM | List |		| SF-If-Modified-Since | Item |
	| SF-IUS | Item |		| SF-If-None-Match | List |
	| SF-Link | List |		| SF-If-Unmodified-Since | Item |
	| SF-LM | Item |		| SF-Link | List |
	| SF-Location | String |		| SF-Last-Modified | Item |
	| SF-Referer | String |		| SF-Location | Item |
	| SF-Set-Cookie | Dictionary |		| SF-Referer | Item |
	+---------------------+-----------------+		| SF-Set-Cookie | List |
			+------------------------+-----------------+
	Table 5: New Fields		Table 5: New Fields
	Finally, add the indicated Structured Type for each existing registry		Then, add the indicated Structured Type for each existing registry
	entry listed in Table 6.		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-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 | Item |
	| Cross-Origin-Opener-Policy-Report-Only | 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: Existing Fields		Table 6: Existing Fields
			Finally, add a new column to the "Cookie Attribute Registry"
			established by [COOKIES] with the title "Structured Type", using
			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
	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.
	skipping to change at page 11, line 30 ¶		skipping to change at page 12, line 30 ¶
	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] Chen, L., Englehardt, S., West, M., and J. Wilander,
	"Cookies: HTTP State Management Mechanism", draft-ietf-		"Cookies: HTTP State Management Mechanism", draft-ietf-
	httpbis-rfc6265bis-10 (work in progress), April 2022.		httpbis-rfc6265bis-10 (work in progress), April 2022.
	[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP		[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Semantics", draft-ietf-httpbis-semantics-19 (work in		Ed., "HTTP Semantics", STD 97, RFC 9110,
	progress), September 2021.		DOI 10.17487/RFC9110, June 2022,
			<https://www.rfc-editor.org/info/rfc9110>.
	[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>.
			[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
			Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
			<https://www.rfc-editor.org/info/rfc3339>.
	[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,		[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
	DOI 10.17487/RFC8288, October 2017,		DOI 10.17487/RFC8288, October 2017,
	<https://www.rfc-editor.org/info/rfc8288>.		<https://www.rfc-editor.org/info/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
	HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,		HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
	<https://www.rfc-editor.org/info/rfc8941>.		<https://www.rfc-editor.org/info/rfc8941>.
			Appendix A. The Date Structured Type
			This section defines a new Structured Fields data type, Date.
			Dates have a data model that is similar to Integers, representing a
			(possibly negative) delta in seconds from January 1, 1970 00:00:00
			UTC, excluding leap seconds.
			The ABNF for Dates is:
			sf-date = "@" ["-"] 1*15DIGIT
			For example:
			Example-Date: @1659578233
			A.1. Serialising a Date
			Given a Date as input_integer, return an ASCII string suitable for
			use in an HTTP field value.
			1. Let output be "@".
			2. Append to output the result of running Serializing an Integer
			with input_date (see Section 4.1.4 of [STRUCTURED-FIELDS]).
			3. Return output.
			A.2. Parsing a Date
			Given an ASCII string as input_string, return a Date. input_string is
			modified to remove the parsed value.
			1. If the first character of input_string is not "@", fail parsing.
			2. Discard the first character of input_string.
			3. Let output_date be the result of running Parsing an Integer or
			Decimal with input_string (see Section 4.2.4 of
			[STRUCTURED-FIELDS]).
			4. If output_date is a Decimal, fail parsing.
			5. Return output_date.
	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. 37 change blocks.
	77 lines changed or deleted		158 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/