draft-ietf-httpbis-rfc6265bis-02.txt		draft-ietf-httpbis-rfc6265bis-latest.txt
	HTTP Working Group A. Barth		HTTP Working Group A. Barth
	Internet-Draft M. West		Internet-Draft M. West
	Obsoletes: 6265 (if approved) Google, Inc		Obsoletes: 6265 (if approved) Google, Inc
	Intended status: Standards Track August 7, 2017		Intended status: Standards Track April 24, 2019
	Expires: February 8, 2018		Expires: October 26, 2019
	Cookies: HTTP State Management Mechanism		Cookies: HTTP State Management Mechanism
	draft-ietf-httpbis-rfc6265bis-latest		draft-ietf-httpbis-rfc6265bis-latest
	Abstract		Abstract
	This document defines the HTTP Cookie and Set-Cookie header fields.		This document defines the HTTP Cookie and Set-Cookie header fields.
	These header fields can be used by HTTP servers to store state		These header fields can be used by HTTP servers to store state
	(called cookies) at HTTP user agents, letting the servers maintain a		(called cookies) at HTTP user agents, letting the servers maintain a
	stateful session over the mostly stateless HTTP protocol. Although		stateful session over the mostly stateless HTTP protocol. Although
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	https://github.com/httpwg/http-extensions/labels/6265bis [3].		https://github.com/httpwg/http-extensions/labels/6265bis [3].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://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 February 8, 2018.		This Internet-Draft will expire on October 26, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2019 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		(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.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	skipping to change at page 2, line 51 ¶		skipping to change at page 2, line 51 ¶
	4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 9		4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 9
	4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 9		4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 9
	4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 9		4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 9
	4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 11		4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 11
	4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 14		4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 14
	4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 15		4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 15
	4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 15		4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 15
	4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16		4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16
	5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 16		5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 16
	5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 16		5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 16
	5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 16		5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 17
	5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 18		5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 18
	5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 19		5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 19
	5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 19		5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 19
	5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 20		5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 20
	5.2.1. Document-based requests . . . . . . . . . . . . . . . 20		5.2.1. Document-based requests . . . . . . . . . . . . . . . 21
	5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 21		5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 22
	5.3. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 23		5.3. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 23
	5.3.1. The Expires Attribute . . . . . . . . . . . . . . . . 25		5.3.1. The Expires Attribute . . . . . . . . . . . . . . . . 25
	5.3.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 25		5.3.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 26
	5.3.3. The Domain Attribute . . . . . . . . . . . . . . . . 26		5.3.3. The Domain Attribute . . . . . . . . . . . . . . . . 26
	5.3.4. The Path Attribute . . . . . . . . . . . . . . . . . 26		5.3.4. The Path Attribute . . . . . . . . . . . . . . . . . 27
	5.3.5. The Secure Attribute . . . . . . . . . . . . . . . . 27		5.3.5. The Secure Attribute . . . . . . . . . . . . . . . . 27
	5.3.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 27		5.3.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 27
	5.3.7. The SameSite Attribute . . . . . . . . . . . . . . . 27		5.3.7. The SameSite Attribute . . . . . . . . . . . . . . . 27
	5.4. Storage Model . . . . . . . . . . . . . . . . . . . . . . 28		5.4. Storage Model . . . . . . . . . . . . . . . . . . . . . . 28
	5.5. The Cookie Header . . . . . . . . . . . . . . . . . . . . 33		5.5. The Cookie Header . . . . . . . . . . . . . . . . . . . . 33
	6. Implementation Considerations . . . . . . . . . . . . . . . . 35		6. Implementation Considerations . . . . . . . . . . . . . . . . 35
	6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 35		6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 35
	6.2. Application Programming Interfaces . . . . . . . . . . . 35		6.2. Application Programming Interfaces . . . . . . . . . . . 35
	6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 35		6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 36
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36
	7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 36		7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 36
	7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 37		7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 37
	7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . 37		7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . 37
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 37		8. Security Considerations . . . . . . . . . . . . . . . . . . . 38
	8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 37		8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 38
	8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 38		8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 38
	8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 38		8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 39
	8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 39		8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 40
	8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 40		8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 40
	8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 40		8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 41
	8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 41		8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 42
	8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 41		8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 42
	8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 41		8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 42
	8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 42		8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 42
	8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 42		8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 43
	8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 43		8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 43
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
	9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 43		9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 43
	9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 43		9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 44
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
	10.1. Normative References . . . . . . . . . . . . . . . . . . 44		10.1. Normative References . . . . . . . . . . . . . . . . . . 44
	10.2. Informative References . . . . . . . . . . . . . . . . . 45		10.2. Informative References . . . . . . . . . . . . . . . . . 45
	10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 47		10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 47
	Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 48		Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 48
	A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 48		A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 48
	A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 48		A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 48
	A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 48		A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 49
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 49		A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 49
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
			Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 49
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
	1. Introduction		1. Introduction
	This document defines the HTTP Cookie and Set-Cookie header fields.		This document defines the HTTP Cookie and Set-Cookie header fields.
	Using the Set-Cookie header field, an HTTP server can pass name/value		Using the Set-Cookie header field, an HTTP server can pass name/value
	pairs and associated metadata (called cookies) to a user agent. When		pairs and associated metadata (called cookies) to a user agent. When
	the user agent makes subsequent requests to the server, the user		the user agent makes subsequent requests to the server, the user
	agent uses the metadata and other information to determine whether to		agent uses the metadata and other information to determine whether to
	return the name/value pairs in the Cookie header.		return the name/value pairs in the Cookie header.
	skipping to change at page 6, line 9 ¶		skipping to change at page 6, line 9 ¶
	; "optional" whitespace		; "optional" whitespace
	obs-fold = CRLF		obs-fold = CRLF
	OWS SHOULD either not be produced or be produced as a single SP		OWS SHOULD either not be produced or be produced as a single SP
	character.		character.
	2.3. Terminology		2.3. Terminology
	The terms "user agent", "client", "server", "proxy", and "origin		The terms "user agent", "client", "server", "proxy", and "origin
	server" have the same meaning as in the HTTP/1.1 specification		server" have the same meaning as in the HTTP/1.1 specification
	([RFC2616], Section 1.3).		([RFC7230], Section 2).
	The request-host is the name of the host, as known by the user agent,		The request-host is the name of the host, as known by the user agent,
	to which the user agent is sending an HTTP request or from which it		to which the user agent is sending an HTTP request or from which it
	is receiving an HTTP response (i.e., the name of the host to which it		is receiving an HTTP response (i.e., the name of the host to which it
	sent the corresponding HTTP request).		sent the corresponding HTTP request).
	The term request-uri is defined in Section 5.1.2 of [RFC2616].		The term request-uri refers to "request-target" as defined in
			Section 5.3 of [RFC7230].
	Two sequences of octets are said to case-insensitively match each		Two sequences of octets are said to case-insensitively match each
	other if and only if they are equivalent under the i;ascii-casemap		other if and only if they are equivalent under the i;ascii-casemap
	collation defined in [RFC4790].		collation defined in [RFC4790].
	The term string means a sequence of non-NUL octets.		The term string means a sequence of non-NUL octets.
	The terms "active document", "ancestor browsing context", "browsing		The terms "active document", "ancestor browsing context", "browsing
	context", "dedicated worker", "Document", "WorkerGlobalScope",		context", "dedicated worker", "Document", "WorkerGlobalScope",
	"sandboxed origin browsing context flag", "parent browsing context",		"sandboxed origin browsing context flag", "parent browsing context",
	skipping to change at page 6, line 42 ¶		skipping to change at page 6, line 43 ¶
	The term "origin", the mechanism of deriving an origin from a URI,		The term "origin", the mechanism of deriving an origin from a URI,
	and the "the same" matching algorithm for origins are defined in		and the "the same" matching algorithm for origins are defined in
	[RFC6454].		[RFC6454].
	"Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as		"Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as
	defined in Section 4.2.1 of [RFC7231].		defined in Section 4.2.1 of [RFC7231].
	The term "public suffix" is defined in a note in Section 5.3 of		The term "public suffix" is defined in a note in Section 5.3 of
	[RFC6265] as "a domain that is controlled by a public registry", and		[RFC6265] as "a domain that is controlled by a public registry", and
	are also know as "effective top-level domains" (eTLDs). For example,		are also known as "effective top-level domains" (eTLDs). For
	"example.com"'s public suffix is "com". User agents SHOULD use an		example, "example.com"'s public suffix is "com". User agents SHOULD
	up-to-date public suffix list, such as the one maintained by Mozilla		use an up-to-date public suffix list, such as the one maintained by
	at [PSL].		Mozilla at [PSL].
	An origin's "registered domain" is the origin's host's public suffix		An origin's "registered domain" is the origin's host's public suffix
	plus the label to its left. That is, for "https://www.example.com",		plus the label to its left. That is, for "https://www.example.com",
	the public suffix is "com", and the registered domain is		the public suffix is "com", and the registered domain is
	"example.com". This concept is defined more rigorously in [PSL], and		"example.com". This concept is defined more rigorously in [PSL], and
	is also know as "effective top-level domain plus one" (eTLD+1).		is also known as "effective top-level domain plus one" (eTLD+1).
	The term "request", as well as a request's "client", "current url",		The term "request", as well as a request's "client", "current url",
	"method", and "target browsing context", are defined in [FETCH].		"method", and "target browsing context", are defined in [FETCH].
	3. Overview		3. Overview
	This section outlines a way for an origin server to send state		This section outlines a way for an origin server to send state
	information to a user agent and for the user agent to return the		information to a user agent and for the user agent to return the
	state information to the origin server.		state information to the origin server.
	skipping to change at page 7, line 32 ¶		skipping to change at page 7, line 32 ¶
	response. User agents MAY ignore Set-Cookie headers contained in		response. User agents MAY ignore Set-Cookie headers contained in
	responses with 100-level status codes but MUST process Set-Cookie		responses with 100-level status codes but MUST process Set-Cookie
	headers contained in other responses (including responses with 400-		headers contained in other responses (including responses with 400-
	and 500-level status codes). An origin server can include multiple		and 500-level status codes). An origin server can include multiple
	Set-Cookie header fields in a single response. The presence of a		Set-Cookie header fields in a single response. The presence of a
	Cookie or a Set-Cookie header field does not preclude HTTP caches		Cookie or a Set-Cookie header field does not preclude HTTP caches
	from storing and reusing a response.		from storing and reusing a response.
	Origin servers SHOULD NOT fold multiple Set-Cookie header fields into		Origin servers SHOULD NOT fold multiple Set-Cookie header fields into
	a single header field. The usual mechanism for folding HTTP headers		a single header field. The usual mechanism for folding HTTP headers
	fields (i.e., as defined in [RFC2616]) might change the semantics of		fields (i.e., as defined in Section 3.2.2 of [RFC7230]) might change
	the Set-Cookie header field because the %x2C (",") character is used		the semantics of the Set-Cookie header field because the %x2C (",")
	by Set-Cookie in a way that conflicts with such folding.		character is used by Set-Cookie in a way that conflicts with such
			folding.
	3.1. Examples		3.1. Examples
	Using the Set-Cookie header, a server can send the user agent a short		Using the Set-Cookie header, a server can send the user agent a short
	string in an HTTP response that the user agent will return in future		string in an HTTP response that the user agent will return in future
	HTTP requests that are within the scope of the cookie. For example,		HTTP requests that are within the scope of the cookie. For example,
	the server can send the user agent a "session identifier" named SID		the server can send the user agent a "session identifier" named SID
	with the value 31d4d96e407aad42. The user agent then returns the		with the value 31d4d96e407aad42. The user agent then returns the
	session identifier in subsequent requests.		session identifier in subsequent requests.
	skipping to change at page 10, line 14 ¶		skipping to change at page 10, line 14 ¶
	set-cookie-header = "Set-Cookie:" SP set-cookie-string		set-cookie-header = "Set-Cookie:" SP set-cookie-string
	set-cookie-string = cookie-pair *( ";" SP cookie-av )		set-cookie-string = cookie-pair *( ";" SP cookie-av )
	cookie-pair = cookie-name "=" cookie-value		cookie-pair = cookie-name "=" cookie-value
	cookie-name = token		cookie-name = token
	cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )		cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
	cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E		cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
	; US-ASCII characters excluding CTLs,		; US-ASCII characters excluding CTLs,
	; whitespace DQUOTE, comma, semicolon,		; whitespace DQUOTE, comma, semicolon,
	; and backslash		; and backslash
	token = <token, defined in [RFC2616], Section 2.2>		token = <token, defined in [RFC7230], Section 3.2.6>
	cookie-av = expires-av / max-age-av / domain-av /		cookie-av = expires-av / max-age-av / domain-av /
	path-av / secure-av / httponly-av /		path-av / secure-av / httponly-av /
	samesite-av / extension-av		samesite-av / extension-av
	expires-av = "Expires=" sane-cookie-date		expires-av = "Expires=" sane-cookie-date
	sane-cookie-date =		sane-cookie-date =
	<rfc1123-date, defined in [RFC2616], Section 3.3.1>		<IMF-fixdate, defined in [RFC7231], Section 7.1.1.1>
	max-age-av = "Max-Age=" non-zero-digit *DIGIT		max-age-av = "Max-Age=" non-zero-digit *DIGIT
	; In practice, both expires-av and max-age-av		; In practice, both expires-av and max-age-av
	; are limited to dates representable by the		; are limited to dates representable by the
	; user agent.		; user agent.
	non-zero-digit = %x31-39		non-zero-digit = %x31-39
	; digits 1 through 9		; digits 1 through 9
	domain-av = "Domain=" domain-value		domain-av = "Domain=" domain-value
	domain-value = <subdomain>		domain-value = <subdomain>
	; defined in [RFC1034], Section 3.5, as		; defined in [RFC1034], Section 3.5, as
	; enhanced by [RFC1123], Section 2.1		; enhanced by [RFC1123], Section 2.1
	path-av = "Path=" path-value		path-av = "Path=" path-value
	path-value = *av-octet		path-value = *av-octet
	secure-av = "Secure"		secure-av = "Secure"
	httponly-av = "HttpOnly"		httponly-av = "HttpOnly"
	samesite-av = "SameSite=" samesite-value		samesite-av = "SameSite=" samesite-value
	samesite-value = "Strict" / "Lax"		samesite-value = "Strict" / "Lax" / "None"
	extension-av = *av-octet		extension-av = *av-octet
	av-octet = %x20-3A / %x3C-7E		av-octet = %x20-3A / %x3C-7E
	; any CHAR except CTLs or ";"		; any CHAR except CTLs or ";"
	Note that some of the grammatical terms above reference documents		Note that some of the grammatical terms above reference documents
	that use different grammatical notations than this document (which		that use different grammatical notations than this document (which
	uses ABNF from [RFC5234]).		uses ABNF from [RFC5234]).
	The semantics of the cookie-value are not defined by this document.		The semantics of the cookie-value are not defined by this document.
	skipping to change at page 14, line 28 ¶		skipping to change at page 14, line 28 ¶
	The "SameSite" attribute limits the scope of the cookie such that it		The "SameSite" attribute limits the scope of the cookie such that it
	will only be attached to requests if those requests are same-site, as		will only be attached to requests if those requests are same-site, as
	defined by the algorithm in Section 5.2. For example, requests for		defined by the algorithm in Section 5.2. For example, requests for
	"https://example.com/sekrit-image" will attach same-site cookies if		"https://example.com/sekrit-image" will attach same-site cookies if
	and only if initiated from a context whose "site for cookies" is		and only if initiated from a context whose "site for cookies" is
	"example.com".		"example.com".
	If the "SameSite" attribute's value is "Strict", the cookie will only		If the "SameSite" attribute's value is "Strict", the cookie will only
	be sent along with "same-site" requests. If the value is "Lax", the		be sent along with "same-site" requests. If the value is "Lax", the
	cookie will be sent with same-site requests, and with "cross-site"		cookie will be sent with same-site requests, and with "cross-site"
	top-level navigations, as described in Section 5.3.7.1. If the		top-level navigations, as described in Section 5.3.7.1. If the value
	"SameSite" attribute's value is neither of these, the cookie will be		is "None", the cookie will be sent with same-site and cross-site
	ignored.		requests. If the "SameSite" attribute's value is something other
			than these three known keywords, the attribute's value will be
			treated as "None".
	4.1.3. Cookie Name Prefixes		4.1.3. Cookie Name Prefixes
	Section 8.5 and Section 8.6 of this document spell out some of the		Section 8.5 and Section 8.6 of this document spell out some of the
	drawbacks of cookies' historical implementation. In particular, it		drawbacks of cookies' historical implementation. In particular, it
	is impossible for a server to have confidence that a given cookie was		is impossible for a server to have confidence that a given cookie was
	set with a particular set of attributes. In order to provide such		set with a particular set of attributes. In order to provide such
	confidence in a backwards-compatible way, two common sets of		confidence in a backwards-compatible way, two common sets of
	requirements can be inferred from the first few characters of the		requirements can be inferred from the first few characters of the
	cookie's name.		cookie's name.
	skipping to change at page 21, line 11 ¶		skipping to change at page 21, line 21 ¶
	represents the context in which a user most likely believes		represents the context in which a user most likely believes
	themselves to be interacting. We'll label this domain the "top-level		themselves to be interacting. We'll label this domain the "top-level
	site".		site".
	For a document displayed in a top-level browsing context, we can stop		For a document displayed in a top-level browsing context, we can stop
	here: the document's "site for cookies" is the top-level site.		here: the document's "site for cookies" is the top-level site.
	For documents which are displayed in nested browsing contexts, we		For documents which are displayed in nested browsing contexts, we
	need to audit the origins of each of a document's ancestor browsing		need to audit the origins of each of a document's ancestor browsing
	contexts' active documents in order to account for the "multiple-		contexts' active documents in order to account for the "multiple-
	nested scenarios" described in Section 4 of [RFC7034]. These		nested scenarios" described in Section 4 of [RFC7034]. A document's
	document's "site for cookies" is the top-level site if and only if		"site for cookies" is the top-level site if and only if the document
	the document and each of its ancestor documents' origins have the		and each of its ancestor documents' origins have the same registered
	same registered domain as the top-level site. Otherwise its "site		domain as the top-level site. Otherwise its "site for cookies" is
	for cookies" is the empty string.		the empty string.
	Given a Document ("document"), the following algorithm returns its		Given a Document ("document"), the following algorithm returns its
	"site for cookies" (either a registered domain, or the empty string):		"site for cookies" (either a registered domain, or the empty string):
	1. Let "top-document" be the active document in "document"'s		1. Let "top-document" be the active document in "document"'s
	browsing context's top-level browsing context.		browsing context's top-level browsing context.
	2. Let "top-origin" be the origin of "top-document"'s URI if "top-		2. Let "top-origin" be the origin of "top-document"'s URI if "top-
	document"'s sandboxed origin browsing context flag is set, and		document"'s sandboxed origin browsing context flag is set, and
	"top-document"'s origin otherwise.		"top-document"'s origin otherwise.
	skipping to change at page 22, line 42 ¶		skipping to change at page 23, line 5 ¶
	the empty string.		the empty string.
	3. Return "site".		3. Return "site".
	5.2.2.2. Service Workers		5.2.2.2. Service Workers
	Service Workers are more complicated, as they act as a completely		Service Workers are more complicated, as they act as a completely
	separate execution context with only tangential relationship to the		separate execution context with only tangential relationship to the
	Document which registered them.		Document which registered them.
	Requests which simply pass through a service worker will be handled		Requests which simply pass through a Service Worker will be handled
	as described above: the request's client will be the Document or		as described above: the request's client will be the Document or
	Worker which initiated the request, and its "site for cookies" will		Worker which initiated the request, and its "site for cookies" will
	be those defined in Section 5.2.1 and Section 5.2.2.1		be those defined in Section 5.2.1 and Section 5.2.2.1
	Requests which are initiated by the Service Worker itself (via a		Requests which are initiated by the Service Worker itself (via a
	direct call to "fetch()", for instance), on the other hand, will have		direct call to "fetch()", for instance), on the other hand, will have
	a client which is a ServiceWorkerGlobalScope. Its "site for cookies"		a client which is a ServiceWorkerGlobalScope. Its "site for cookies"
	will be the registered domain of the Service Worker's URI.		will be the registered domain of the Service Worker's URI.
	Given a ServiceWorkerGlobalScope ("worker"), the following algorithm		Given a ServiceWorkerGlobalScope ("worker"), the following algorithm
	skipping to change at page 27, line 23 ¶		skipping to change at page 27, line 40 ¶
	If the attribute-name case-insensitively matches the string		If the attribute-name case-insensitively matches the string
	"HttpOnly", the user agent MUST append an attribute to the cookie-		"HttpOnly", the user agent MUST append an attribute to the cookie-
	attribute-list with an attribute-name of HttpOnly and an empty		attribute-list with an attribute-name of HttpOnly and an empty
	attribute-value.		attribute-value.
	5.3.7. The SameSite Attribute		5.3.7. The SameSite Attribute
	If the attribute-name case-insensitively matches the string		If the attribute-name case-insensitively matches the string
	"SameSite", the user agent MUST process the cookie-av as follows:		"SameSite", the user agent MUST process the cookie-av as follows:
	1. If cookie-av's attribute-value is not a case-insensitive match		1. Let "enforcement" be "None".
	for "Strict" or "Lax", ignore the "cookie-av".
	2. Let "enforcement" be "Lax" if cookie-av's attribute-value is a		2. If cookie-av's attribute-value is a case-insensitive match for
	case-insensitive match for "Lax", and "Strict" otherwise.		"Strict", set "enforcement" to "Strict".
	3. Append an attribute to the cookie-attribute-list with an		3. If cookie-av's attribute-value is a case-insensitive match for
			"Lax", set "enforcement" to "Lax".
			4. Append an attribute to the cookie-attribute-list with an
	attribute-name of "SameSite" and an attribute-value of		attribute-name of "SameSite" and an attribute-value of
	"enforcement".		"enforcement".
			Note: This algorithm maps the "None" value, as well as any unknown
			value, to the "None" behavior, which is helpful for backwards
			compatibility when introducing new variants.
	5.3.7.1. "Strict" and "Lax" enforcement		5.3.7.1. "Strict" and "Lax" enforcement
	Same-site cookies in "Strict" enforcement mode will not be sent along		Same-site cookies in "Strict" enforcement mode will not be sent along
	with top-level navigations which are triggered from a cross-site		with top-level navigations which are triggered from a cross-site
	document context. As discussed in Section 8.8.2, this might or might		document context. As discussed in Section 8.8.2, this might or might
	not be compatible with existing session management systems. In the		not be compatible with existing session management systems. In the
	interests of providing a drop-in mechanism that mitigates the risk of		interests of providing a drop-in mechanism that mitigates the risk of
	CSRF attacks, developers may set the "SameSite" attribute in a "Lax"		CSRF attacks, developers may set the "SameSite" attribute in a "Lax"
	enforcement mode that carves out an exception which sends same-site		enforcement mode that carves out an exception which sends same-site
	cookies along with cross-site requests if and only if they are top-		cookies along with cross-site requests if and only if they are top-
	skipping to change at page 31, line 21 ¶		skipping to change at page 31, line 44 ¶
	Note: The path comparison is not symmetric, ensuring only that a		Note: The path comparison is not symmetric, ensuring only that a
	newly-created, non-secure cookie does not overlay an existing		newly-created, non-secure cookie does not overlay an existing
	secure cookie, providing some mitigation against cookie-fixing		secure cookie, providing some mitigation against cookie-fixing
	attacks. That is, given an existing secure cookie named 'a'		attacks. That is, given an existing secure cookie named 'a'
	with a path of '/login', a non-secure cookie named 'a' could be		with a path of '/login', a non-secure cookie named 'a' could be
	set for a path of '/' or '/foo', but not for a path of '/login'		set for a path of '/' or '/foo', but not for a path of '/login'
	or '/login/en'.		or '/login/en'.
	13. If the cookie-attribute-list contains an attribute with an		13. If the cookie-attribute-list contains an attribute with an
	attribute-name of "SameSite", set the cookie's same-site-flag to		attribute-name of "SameSite", set the cookie's same-site-flag to
	attribute-value (i.e. either "Strict" or "Lax"). Otherwise, set		attribute-value (i.e. either "Strict", "Lax", or "None").
	the cookie's same-site-flag to "None".		Otherwise, set the cookie's same-site-flag to "None".
	14. If the cookie's "same-site-flag" is not "None", and the cookie		14. If the cookie's "same-site-flag" is not "None", and the cookie
	is being set from a context whose "site for cookies" is not an		is being set from a context whose "site for cookies" is not an
	exact match for request-uri's host's registered domain, then		exact match for request-uri's host's registered domain, then
	abort these steps and ignore the newly created cookie entirely.		abort these steps and ignore the newly created cookie entirely.
	15. If the cookie-name begins with a case-sensitive match for the		15. If the cookie-name begins with a case-sensitive match for the
	string "__Secure-", abort these steps and ignore the cookie		string "__Secure-", abort these steps and ignore the cookie
	entirely unless the cookie's secure-only-flag is true.		entirely unless the cookie's secure-only-flag is true.
	skipping to change at page 31, line 45 ¶		skipping to change at page 32, line 21 ¶
	entirely unless the cookie meets all the following criteria:		entirely unless the cookie meets all the following criteria:
	1. The cookie's secure-only-flag is true.		1. The cookie's secure-only-flag is true.
	2. The cookie's host-only-flag is true.		2. The cookie's host-only-flag is true.
	3. The cookie-attribute-list contains an attribute with an		3. The cookie-attribute-list contains an attribute with an
	attribute-name of "Path", and the cookie's path is "/".		attribute-name of "Path", and the cookie's path is "/".
	17. If the cookie store contains a cookie with the same name,		17. If the cookie store contains a cookie with the same name,
	domain, and path as the newly-created cookie:		domain, host-only-flag, and path as the newly-created cookie:
	1. Let old-cookie be the existing cookie with the same name,		1. Let old-cookie be the existing cookie with the same name,
	domain, and path as the newly-created cookie. (Notice that		domain, host-only-flag, and path as the newly-created
	this algorithm maintains the invariant that there is at most		cookie. (Notice that this algorithm maintains the invariant
	one such cookie.)		that there is at most one such cookie.)
	2. If the newly-created cookie was received from a "non-HTTP"		2. If the newly-created cookie was received from a "non-HTTP"
	API and the old-cookie's http-only-flag is true, abort these		API and the old-cookie's http-only-flag is true, abort these
	steps and ignore the newly created cookie entirely.		steps and ignore the newly created cookie entirely.
	3. Update the creation-time of the newly-created cookie to		3. Update the creation-time of the newly-created cookie to
	match the creation-time of the old-cookie.		match the creation-time of the old-cookie.
	4. Remove the old-cookie from the cookie store.		4. Remove the old-cookie from the cookie store.
	skipping to change at page 44, line 21 ¶		skipping to change at page 44, line 33 ¶
	[HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt,		[HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt,
	P., and D. Denicola, "HTML", n.d.,		P., and D. Denicola, "HTML", n.d.,
	<https://html.spec.whatwg.org/>.		<https://html.spec.whatwg.org/>.
	[PSL] "Public Suffix List", n.d.,		[PSL] "Public Suffix List", n.d.,
	<https://publicsuffix.org/list/>.		<https://publicsuffix.org/list/>.
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<http://www.rfc-editor.org/info/rfc1034>.		<https://www.rfc-editor.org/info/rfc1034>.
	[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -		[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
	Application and Support", STD 3, RFC 1123,		Application and Support", STD 3, RFC 1123,
	DOI 10.17487/RFC1123, October 1989,		DOI 10.17487/RFC1123, October 1989,
	<http://www.rfc-editor.org/info/rfc1123>.		<https://www.rfc-editor.org/info/rfc1123>.
	[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,
	<http://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616,
	DOI 10.17487/RFC2616, June 1999,
	<http://www.rfc-editor.org/info/rfc2616>.
	[RFC3490] Costello, A., "Internationalizing Domain Names in		[RFC3490] Costello, A., "Internationalizing Domain Names in
	Applications (IDNA)", RFC 3490, DOI 10.17487/RFC3490,		Applications (IDNA)", RFC 3490, DOI 10.17487/RFC3490,
	March 2003, <https://www.rfc-editor.org/info/rfc3490>.		March 2003, <https://www.rfc-editor.org/info/rfc3490>.
	See Section 6.3 for an explanation why the normative		See Section 6.3 for an explanation why the normative
	reference to an obsoleted specification is needed.		reference to an obsoleted specification is needed.
	[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet		[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
	Application Protocol Collation Registry", RFC 4790,		Application Protocol Collation Registry", RFC 4790,
	DOI 10.17487/RFC4790, March 2007,		DOI 10.17487/RFC4790, March 2007,
	<http://www.rfc-editor.org/info/rfc4790>.		<https://www.rfc-editor.org/info/rfc4790>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<http://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
	[RFC5890] Klensin, J., "Internationalized Domain Names for		[RFC5890] Klensin, J., "Internationalized Domain Names for
	Applications (IDNA): Definitions and Document Framework",		Applications (IDNA): Definitions and Document Framework",
	RFC 5890, DOI 10.17487/RFC5890, August 2010,		RFC 5890, DOI 10.17487/RFC5890, August 2010,
	<http://www.rfc-editor.org/info/rfc5890>.		<https://www.rfc-editor.org/info/rfc5890>.
	[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,		[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
	DOI 10.17487/RFC6454, December 2011,		DOI 10.17487/RFC6454, December 2011,
	<http://www.rfc-editor.org/info/rfc6454>.		<https://www.rfc-editor.org/info/rfc6454>.
			[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
			Protocol (HTTP/1.1): Message Syntax and Routing",
			RFC 7230, DOI 10.17487/RFC7230, June 2014,
			<https://www.rfc-editor.org/info/rfc7230>.
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,		Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
	DOI 10.17487/RFC7231, June 2014,		DOI 10.17487/RFC7231, June 2014,
	<http://www.rfc-editor.org/info/rfc7231>.		<https://www.rfc-editor.org/info/rfc7231>.
	[SERVICE-WORKERS]		[SERVICE-WORKERS]
	Russell, A., Song, J., and J. Archibald, "Service		Russell, A., Song, J., and J. Archibald, "Service
	Workers", n.d., <http://www.w3.org/TR/service-workers/>.		Workers", n.d., <http://www.w3.org/TR/service-workers/>.
	[USASCII] American National Standards Institute, "Coded Character		[USASCII] American National Standards Institute, "Coded Character
	Set -- 7-bit American Standard Code for Information		Set -- 7-bit American Standard Code for Information
	Interchange", ANSI X3.4, 1986.		Interchange", ANSI X3.4, 1986.
	10.2. Informative References		10.2. Informative References
	skipping to change at page 46, line 33 ¶		skipping to change at page 46, line 40 ¶
	West, M. and M. Goodwin, "Same-Site Cookies", draft-ietf-		West, M. and M. Goodwin, "Same-Site Cookies", draft-ietf-
	httpbis-cookie-same-site-00 (work in progress), June 2016.		httpbis-cookie-same-site-00 (work in progress), June 2016.
	[prerendering]		[prerendering]
	Bentzel, C., "Chrome Prerendering", n.d.,		Bentzel, C., "Chrome Prerendering", n.d.,
	<https://www.chromium.org/developers/design-documents/		<https://www.chromium.org/developers/design-documents/
	prerender>.		prerender>.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	DOI 10.17487/RFC2818, May 2000,		DOI 10.17487/RFC2818, May 2000,
	<http://www.rfc-editor.org/info/rfc2818>.		<https://www.rfc-editor.org/info/rfc2818>.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November		10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
	2003, <http://www.rfc-editor.org/info/rfc3629>.		2003, <https://www.rfc-editor.org/info/rfc3629>.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90, RFC 3864,
	DOI 10.17487/RFC3864, September 2004,		DOI 10.17487/RFC3864, September 2004,
	<http://www.rfc-editor.org/info/rfc3864>.		<https://www.rfc-editor.org/info/rfc3864>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<http://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<http://www.rfc-editor.org/info/rfc4648>.		<https://www.rfc-editor.org/info/rfc4648>.
	[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for		[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for
	Internationalized Domain Names in Applications (IDNA)		Internationalized Domain Names in Applications (IDNA)
	2008", RFC 5895, DOI 10.17487/RFC5895, September 2010,		2008", RFC 5895, DOI 10.17487/RFC5895, September 2010,
	<http://www.rfc-editor.org/info/rfc5895>.		<https://www.rfc-editor.org/info/rfc5895>.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011,		DOI 10.17487/RFC6265, April 2011,
	<http://www.rfc-editor.org/info/rfc6265>.		<https://www.rfc-editor.org/info/rfc6265>.
	[RFC7034] Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-		[RFC7034] Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-
	Options", RFC 7034, DOI 10.17487/RFC7034, October 2013,		Options", RFC 7034, DOI 10.17487/RFC7034, October 2013,
	<http://www.rfc-editor.org/info/rfc7034>.		<https://www.rfc-editor.org/info/rfc7034>.
	[UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility		[UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility
	Processing", UNICODE Unicode Technical Standards # 46,		Processing", UNICODE Unicode Technical Standards # 46,
	June 2016, <http://unicode.org/reports/tr46/>.		June 2016, <http://unicode.org/reports/tr46/>.
	10.3. URIs		10.3. URIs
	[1] https://lists.w3.org/Archives/Public/ietf-http-wg/		[1] https://lists.w3.org/Archives/Public/ietf-http-wg/
	[2] http://httpwg.github.io/		[2] http://httpwg.github.io/
	skipping to change at page 48, line 5 ¶		skipping to change at page 48, line 13 ¶
	[10] https://github.com/httpwg/http-extensions/issues/204		[10] https://github.com/httpwg/http-extensions/issues/204
	[11] https://github.com/httpwg/http-extensions/issues/222		[11] https://github.com/httpwg/http-extensions/issues/222
	[12] https://github.com/httpwg/http-extensions/issues/248		[12] https://github.com/httpwg/http-extensions/issues/248
	[13] https://github.com/httpwg/http-extensions/issues/295		[13] https://github.com/httpwg/http-extensions/issues/295
	[14] https://github.com/httpwg/http-extensions/issues/302		[14] https://github.com/httpwg/http-extensions/issues/302
			[15] https://github.com/httpwg/http-extensions/issues/389
			[16] https://github.com/httpwg/http-extensions/issues/199
			[17] https://github.com/httpwg/http-extensions/issues/788
	Appendix A. Changes		Appendix A. Changes
	A.1. draft-ietf-httpbis-rfc6265bis-00		A.1. draft-ietf-httpbis-rfc6265bis-00
	o Port [RFC6265] to Markdown. No (intentional) normative changes.		o Port [RFC6265] to Markdown. No (intentional) normative changes.
	A.2. draft-ietf-httpbis-rfc6265bis-01		A.2. draft-ietf-httpbis-rfc6265bis-01
	o Fixes to formatting caused by mistakes in the initial port to		o Fixes to formatting caused by mistakes in the initial port to
	Markdown:		Markdown:
	skipping to change at page 49, line 21 ¶		skipping to change at page 49, line 35 ¶
	https://github.com/httpwg/http-extensions/issues/248 [12]		https://github.com/httpwg/http-extensions/issues/248 [12]
	* Noted that double-quotes in cookie values are part of the		* Noted that double-quotes in cookie values are part of the
	value, and are not stripped: https://github.com/httpwg/http-		value, and are not stripped: https://github.com/httpwg/http-
	extensions/issues/295 [13]		extensions/issues/295 [13]
	* Fixed the "site for cookies" algorithm to return something that		* Fixed the "site for cookies" algorithm to return something that
	makes sense: https://github.com/httpwg/http-extensions/		makes sense: https://github.com/httpwg/http-extensions/
	issues/302 [14]		issues/302 [14]
	Appendix B. Acknowledgements		A.4. draft-ietf-httpbis-rfc6265bis-03
			o Clarified handling of invalid SameSite values:
			https://github.com/httpwg/http-extensions/issues/389 [15]
			o Reflect widespread implementation practice of including a cookie's
			"host-only-flag" when calculating its uniqueness:
			https://github.com/httpwg/http-extensions/issues/199 [16]
			o Introduced an explicit "None" value for the SameSite attribute:
			https://github.com/httpwg/http-extensions/issues/788 [17]
			Acknowledgements
	This document is a minor update of RFC 6265, adding small features,		This document is a minor update of RFC 6265, adding small features,
	and aligning the specification with the reality of today's		and aligning the specification with the reality of today's
	deployments. Here, we're standing upon the shoulders of giants.		deployments. Here, we're standing upon the shoulders of giants.
	Authors' Addresses		Authors' Addresses
	Adam Barth		Adam Barth
	Google, Inc		Google, Inc
End of changes. 52 change blocks.
	81 lines changed or deleted		110 lines changed or added
This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/