A request-path path-matches a given cookie-path if at least one of
the following conditions holds:
o The cookie-path and the request-path are identical.

It should say:

A request-path path-matches a given cookie-path if at least one of
the following conditions holds:
o The cookie-path and the request-path are identical. Note that this
differs from the rules in RFC 3986 for equivalence of the path
component, and hence two equivalent paths can have different
cookies.

Notes:

The "identical" rule differs from the URI equivalence rule(s) in RFC 3986
sections 6.2 and 2.1 (e.g., "If two URIs differ only in the case of hexadecimal
digits used in percent-encoded octets, they are equivalent.") The fact that
equivalent URIs have different cookies arguably violates the principle of
least astonishment. To avoid significant confusion and prevent such surprise,
this fact should be noted so that it is at least not unexpected.

max-age-av = "Max-Age=" 1*DIGIT
; In practice, both expires-av and max-age-av
; are limited to dates representable by the
; user agent.

Notes:

The current text forbids a server to send Max-Age=0.
--VERIFIER NOTES--
That is correct. As noted in the introduction, what servers should do and what clients should do are not the same. The ABNF in Section 4 limits the server intentionally, to maximize compatibility with deployed clients. See this text in the Introduction:

To maximize interoperability with user agents, servers SHOULD limit
themselves to the well-behaved profile defined in Section 4 when
generating cookies.

User agents MUST implement the more liberal processing rules defined
in Section 5, in order to maximize interoperability with existing
servers that do not conform to the well-behaved profile defined in
Section 4.

Servers SHOULD NOT include more than one Set-Cookie header field in
the same response with the same cookie-name. (See Section 5.2 for
how user agents handle this case.)

It should say:

Servers MUST NOT include more than one Set-Cookie header field in
the same response.

Notes:

The HTTP specification (RFC 2616) says in its section 4.2: "Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. [...]"

Since the mentioned condition is not fulfilled in the case of Set-Cookie headers, only one Set-Cookie header is permissible in an HTTP message.

This also applies to the third example in section 3.1, even though it is not clearly specified there whether or not the two Set-Cookies originate from the same server response.

On the internet many HTTP messages contain multiple Set-Cookie headers, and this seems to make sense in order to avoid additional roundtrips. This, however, (1) does not match the HTTP specification, see above, and therefore (2) cannot be used with implementations stating that they were HTTP compatible and consequently only allow a single Set-Cookie header per response. Clearly, this is not a defect of those implementations, but of the specifications which are at least mistakable (if not contradictory).
--VERIFIER NOTES--
Part of the point of RFC 6265 is to document how cookies are actually
used on the Internet. As is noted in the introduction, existing use
doesn't always conform to what it should. In particular, we know that
RFC 6265 doesn't always match up with RFC 2616, because the actual usage
isn't always strictly correct.

The variation from RFC 2616 that this report notes is intentional,
documenting the existing usage, and this errata report is rejected.

The user agent MUST use an algorithm equivalent to the following
algorithm to parse a cookie-date. Note that the various boolean
flags defined as a part of the algorithm (i.e., found-time, found-
day-of-month, found-month, found-year) are initially "not set".
1. Using the grammar below, divide the cookie-date into date-tokens.
cookie-date = *delimiter date-token-list *delimiter
date-token-list = date-token *( 1*delimiter date-token )
date-token = 1*non-delimiter
delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
non-digit = %x00-2F / %x3A-FF
day-of-month = 1*2DIGIT ( non-digit *OCTET )
month = ( "jan" / "feb" / "mar" / "apr" /
"may" / "jun" / "jul" / "aug" /
"sep" / "oct" / "nov" / "dec" ) *OCTET
year = 2*4DIGIT ( non-digit *OCTET )
time = hms-time ( non-digit *OCTET )
hms-time = time-field ":" time-field ":" time-field
time-field = 1*2DIGIT
2. Process each date-token sequentially in the order the date-tokens
appear in the cookie-date:
1. If the found-time flag is not set and the token matches the
time production, set the found-time flag and set the hour-
value, minute-value, and second-value to the numbers denoted
by the digits in the date-token, respectively. Skip the
remaining sub-steps and continue to the next date-token.
2. If the found-day-of-month flag is not set and the date-token
matches the day-of-month production, set the found-day-of-
month flag and set the day-of-month-value to the number
denoted by the date-token. Skip the remaining sub-steps and
continue to the next date-token.
3. If the found-month flag is not set and the date-token matches
the month production, set the found-month flag and set the
month-value to the month denoted by the date-token. Skip the
remaining sub-steps and continue to the next date-token.
4. If the found-year flag is not set and the date-token matches
the year production, set the found-year flag and set the
year-value to the number denoted by the date-token. Skip the
remaining sub-steps and continue to the next date-token.

It should say:

The user agent MUST use an algorithm equivalent to the following
algorithm to parse a cookie-date. Note that the various boolean
flags defined as a part of the algorithm (i.e., found-day-of-week,
found-time, found-day-of-month, found-month, found-year) are
initially "not set".
1. Using the grammar below, divide the cookie-date into date-tokens.
cookie-date = *delimiter date-token-list *delimiter
date-token-list = date-token *( 1*delimiter date-token )
date-token = 1*non-delimiter
delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
non-digit = %x00-2F / %x3A-FF
day-of-week = weekday / wkday
wkday = "mon" / "tue" / "wed" / "thu" / "fri" / "sat" /
"sun"
weekday = "monday" / "tuesday" / "wednesday" / "thursday" /
"friday" / "saturday" / "sunday"
day-of-month = 1*2DIGIT ( non-digit *OCTET )
month = ( "jan" / "feb" / "mar" / "apr" /
"may" / "jun" / "jul" / "aug" /
"sep" / "oct" / "nov" / "dec" ) *OCTET
year = 2*4DIGIT ( non-digit *OCTET )
time = hms-time ( non-digit *OCTET )
hms-time = time-field ":" time-field ":" time-field
time-field = 1*2DIGIT
2. Process each date-token sequentially in the order the date-tokens
appear in the cookie-date:
1. If the found-day-of-week flag is not set and the token
matches the day-of-week production, set found-day-of-week
flag. Skip the remaining steps and continue to the next
date-token.
2. If the found-time flag is not set and the token matches the
time production, set the found-time flag and set the hour-
value, minute-value, and second-value to the numbers denoted
by the digits in the date-token, respectively. Skip the
remaining sub-steps and continue to the next date-token.
3. If the found-day-of-month flag is not set and the date-token
matches the day-of-month production, set the found-day-of-
month flag and set the day-of-month-value to the number
denoted by the date-token. Skip the remaining sub-steps and
continue to the next date-token.
4. If the found-month flag is not set and the date-token matches
the month production, set the found-month flag and set the
month-value to the month denoted by the date-token. Skip the
remaining sub-steps and continue to the next date-token.
5. If the found-year flag is not set and the date-token matches
the year production, set the found-year flag and set the
year-value to the number denoted by the date-token. Skip the
remaining sub-steps and continue to the next date-token.

Notes:

4.1.1 defines "sane-cookie-date" as "rfc1123-date, defined in [RFC2616], Section 3.3.1". However, both RFC1123 and RFC2616 mandate that date starts with day of the week, and indeed, most servers send cookies where Expires starts with day of the week.

In this particular case (Expire field) the day-of-week part of the date is insignificant, and client MAY ignore it.
--VERIFIER NOTES--
The reporter misunderstood the algorithm at first, thinking that it would fail when it couldn't parse the weekday token. In fact, the algorithm actually has the flexibility to ignore tokens it doesn't care about, and to handle tokens in any order. So there's no error here.

The user agent MUST use an algorithm equivalent to the following
algorithm to compute the default-path of a cookie:

It should say:

The user agent MUST use an algorithm equivalent to the following
algorithm to compute the default value for a cookie-path
(and thereby matching the server-side semantics as defined in 4.1.2.4):

Notes:

The term "default-path" is not formally defined before and is quite misleading for the reader
A. going through the section 5.1.4 as it's only used there once and not again
until section 5.2.4 (once again) and 5.3 (once again).
B. not being a native English speaker

Furthermore, the true meaning of the "default-path" only appears sometime after at section 5.2.4 where it's finally bound altogether. Therefore, my personal recommendation would be to also replace the other occurrences of the "default-path" terms by "default cookie-path"
--VERIFIER NOTES--
This report is actually an enhancement request. The discussion of this report on the http-state mailing list should be reviewed if the document is ever revised.

Otherwise:
Set the cookie's persistent-flag to false.
Set the cookie's expiry-time to the latest representable
date.

It should say:

Otherwise:
Set the cookie's persistent-flag to false.
Set the cookie's expiry-time to the latest representable
date. This is a best-effort approach to ensure that the cookie
will effectively expire when "the current session is over"
(as defined by the user agent) and not anytime before.

Notes:

The second action item isn't necessarily obvious for an implementer/reader. If I got the intention right, then I believe it might improve the "user-friendly" rating of this document. Otherwise, it might still be beneficial to explicit a bit the reasoning behind that action.
--VERIFIER NOTES--
This report is actually an enhancement request. The discussion of this report on the http-state mailing list should be reviewed if the document is ever revised.