Subject: I-D Action: draft-ietf-httpbis-rfc6265bis-00.txt

From: [email-masked]
Date: Mon, 10 Oct 2016 17:45:50 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Hypertext Transfer Protocol of the IETF.

        Title           : HTTP State Management Mechanism
        Authors         : Adam Barth
                          Mike West
	Filename        : draft-ietf-httpbis-rfc6265bis-00.txt
	Pages           : 35
	Date            : 2016-10-10

Abstract:
   This document defines the HTTP Cookie and Set-Cookie header fields.
   These header fields can be used by HTTP servers to store state
   (called cookies) at HTTP user agents, letting the servers maintain a
   stateful session over the mostly stateless HTTP protocol.  Although
   cookies have many historical infelicities that degrade their security
   and privacy, the Cookie and Set-Cookie header fields are widely used
   on the Internet.  This document obsoletes RFC 2965.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Kari hurtta <[email-masked]>
Date: Tue, 11 Oct 2016 06:51:39 +0300 (EEST)

> https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-00

Looking

https://tools.ietf.org/rfcdiff?url1=rfc6265&url2=draft-ietf-httpbis-rfc6265bis-00

5.1.3.  Domain Matching
https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-00#section-5.1.3

There is some nested lists lost.

|   o  The domain string and the string are identical.  (Note that both
|      the domain string and the string will have been canonicalized to
|      lower case at this point.)
|   o  All of the following conditions hold:
|   o  The domain string is a suffix of the string.
|   o  The last character of the string that is not included in the
|      domain string is a %x2E (".") character.
|   o  The string is a host name (i.e., not an IP address

These should be on nested list, I think:

|   o  The domain string is a suffix of the string.
|   o  The last character of the string that is not included in the
|      domain string is a %x2E (".") character.
|   o  The string is a host name (i.e., not an IP address

RFC 6265 was

5.1.3.  Domain Matching
https://tools.ietf.org/html/rfc6265#section-5.1.3

|   o  The domain string and the string are identical.  (Note that both
|      the domain string and the string will have been canonicalized to
|      lower case at this point.)
|
|   o  All of the following conditions hold:
|
|      *  The domain string is a suffix of the string.
|
|      *  The last character of the string that is not included in the
|         domain string is a %x2E (".") character.
|
|      *  The string is a host name (i.e., not an IP address).

/ Kari Hurtta

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 11 Oct 2016 15:02:03 +1100

Hi Kari,

The best thing to do here is to file an issue, so it doesn't get lost; if you don't have a github account, tell me and I'll file it for you.

Cheers,

> On 11 Oct. 2016, at 2:51 pm, Kari hurtta <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 11 Oct 2016 15:01:21 +1100

Hi Everyone,

This is the -00 draft, which is pretty much a direct copy of RFC6265 (with some formatting changes, mostly caused by the tools themselves).

Mike will soon start incorporating the drafts we've taken on board, to see how they look in situ.

Cheers,

> On 11 Oct. 2016, at 11:45 am, [email-masked] wrote:
> 
>

---

From: Mike West <[email-masked]>
Date: Tue, 11 Oct 2016 10:24:33 +0200

Mark filed https://github.com/httpwg/http-extensions/issues/243, and I
fixed it in
https://github.com/httpwg/http-extensions/commit/79fc688f3b95febb9b53e2500221697cab563f8a.
I'm sure we'll find more formatting issues over the next week or so that
arose from the port from the flat text file to Markdown, so I'll hold off
on publishing a -01 draft until those shake out.

Thanks!

-mike

On Tue, Oct 11, 2016 at 6:02 AM, Mark Nottingham <[email-masked]> wrote:

> Hi Kari,
>
> The best thing to do here is to file an issue, so it doesn't get lost; if
> you don't have a github account, tell me and I'll file it for you.
>
> Cheers,
>
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 11 Oct 2016 11:40:01 +0200

On 2016-10-11 10:24, Mike West wrote:
> fixed it
> in https://github.com/httpwg/http-extensions/commit/79fc688f3b95febb9b53e2500221697cab563f8a.
> arose from the port from the flat text file to Markdown, so I'll hold
> off on publishing a -01 draft until those shake out.
>
> Thanks!
>
> -mike

FWIW, I believe this change:

Old:

   token = <token, defined in [RFC2616], Section 2.2>

New:

   token = token
             ; defined in [RFC2616], Section 2.2

is a bad idea; it makes the ABNF invalid.

(similar changes have been made to other imports)

Best regards, Julian

---

From: Mike West <[email-masked]>
Date: Tue, 11 Oct 2016 11:44:45 +0200

> is a bad idea; it makes the ABNF invalid.

I made this change because of a lint warning that the `sane-cookie-date`
definition in the same block was too long. What's a reasonable way of
marking both of these up consistently without overflowing the allotted
width?

-mike

---

From: Julian Reschke <[email-masked]>
Date: Tue, 11 Oct 2016 11:51:08 +0200

On 2016-10-11 11:44, Mike West wrote:
> ...
> ...

This:

> -sane-cookie-date  = rfc1123-date
> -                      ; defined in [RFC2616], Section 3.3.1
> +sane-cookie-date  =
> +   <rfc1123-date, defined in [RFC2616], Section 3.3.1>

should work.

Best regards, Julian

---

From: Mike West <[email-masked]>
Date: Tue, 11 Oct 2016 11:57:09 +0200

>> +   <rfc1123-date, defined in [RFC2616], Section 3.3.1>
SGTM, thanks.

What about `domain-value` below: should we change that to something like
`<subdomain, defined in ...>` as well? It doesn't look like line-breaks are
valid inside `<...>`, so maybe the comments are the right option?

-mike

---

From: Julian Reschke <[email-masked]>
Date: Tue, 11 Oct 2016 12:35:10 +0200

On 2016-10-11 11:57, Mike West wrote:
> On Tue, Oct 11, 2016 at 11:51 AM, Julian Reschke <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> `<subdomain, defined in ...>` as well? It doesn't look like line-breaks
> are valid inside `<...>`, so maybe the comments are the right option?
>
> -mike

Oh, I missed that one.

Right, line breaks in prose productions aren't allowed, so this is the 
only option. It may thus make sense to use that notation consistently...

---

From: Kari hurtta <[email-masked]>
Date: Wed, 12 Oct 2016 11:41:46 +0300 (EEST)

> on publishing a -01 draft until those shake out.

Small note about spacing on lists.

5.2.  The Set-Cookie Header
https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-00#section-5.2

|   1.  If the set-cookie-string contains a %x3B (";") character:
|
|       1.  The name-value-pair string consists of the characters up to,
|           but not including, the first %x3B (";"), and the unparsed-
|           attributes consist of the remainder of the set-cookie-string
|           (including the %x3B (";") in question).
|
|       Otherwise:
|
|       1.  The name-value-pair string consists of all the characters
|           contained in the set-cookie-string, and the unparsed-
|           attributes is the empty string.
|   2.  If the name-value-pair string lacks a %x3D ("=") character,
|       ignore the set-cookie-string entirely.

Formatting:

Because there is empty line on beginning of sublist, this
may be more readable, if there is also empty line on end of
sublist.

( Somewhat numbered sublists, where is only one item, are odd. )

Here also (on first it is not sublist, but "Let the cookie-av string 
be the characters consumed in this step." does not visually go
togetger with "3." tiem).

|   3.  If the remaining unparsed-attributes contains a %x3B (";")
|       character:
|
|       1.  Consume the characters of the unparsed-attributes up to, but
|           not including, the first %x3B (";") character.
|
|       Otherwise:
|
|       1.  Consume the remainder of the unparsed-attributes.
|
|       Let the cookie-av string be the characters consumed in this step.
|   4.  If the cookie-av string contains a %x3D ("=") character:
|
|       1.  The (possibly empty) attribute-name string consists of the
|           characters up to, but not including, the first %x3D ("=")
|           character, and the (possibly empty) attribute-value string
|           consists of the characters after the first %x3D ("=")
|           character.
|
|       Otherwise:
|
|       1.  The attribute-name string consists of the entire cookie-av
|           string, and the attribute-value string is empty.
|   5.  Remove any leading or trailing WSP characters from the attribute-
|       name string and the attribute-value string.

5.2.3.  The Domain Attribute
https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-00#section-5.2.3

|   2.  If the first character of the attribute-value string is %x2E
|       ("."):
|
|       1.  Let cookie-domain be the attribute-value without the leading
|           %x2E (".") character.
|
|       Otherwise:
|
|       1.  Let cookie-domain be the entire attribute-value.
|   3.  Convert the cookie-domain to lower case.

In other words if there is empy lines inside of item, there should be
also on end of item. Otherwise grouping look strange. Perhaps this is
idiosyncrasy of tools?

Perhaps there should be empty line between all list items if there
is at least one empty line inside of some list item?

5.2.4.  The Path Attribute
https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-00#section-5.2.3

|   1.  If the attribute-value is empty or if the first character of the
|       attribute-value is not %x2F ("/"):
|
|       1.  Let cookie-path be the default-path.
|
|       Otherwise:
|
|       1.  Let cookie-path be the attribute-value.
|   2.  Append an attribute to the cookie-attribute-list with an
|       attribute-name of Path and an attribute-value of cookie-path.

https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-00#section-5.3
5.3.  Storage Model

|        1.  Set the cookie's persistent-flag to false.
|        2.  Set the cookie's expiry-time to the latest representable
|            date.
|   4.   If the cookie-attribute-list contains an attribute with an
|        attribute-name iof "Domain":

and

|        1.  Let the domain-attribute be the empty string.
|   5.   If the user agent is configured to reject "public suffixes" and
|        the domain-attribute is a public suffix:

and

|        NOTE: A "public suffix" is a domain that is controlled by a
|        public registry, such as "com", "co.uk", and "pvt.k12.wy.us".
|        This step is essential for preventing attacker.com from
|        disrupting the integrity of example.com by setting a cookie with
|        a Domain attribute of "com".  Unfortunately, the set of public
|        suffixes (also known as "registry controlled domains") changes
|        over time.  If feasible, user agents SHOULD use an up-to-date
|        public suffix list, such as the one maintained by the Mozilla
|        project at http://publicsuffix.org/ .
|   6.   If the domain-attribute is non-empty:

and

|        1.  Set the cookie's host-only-flag to true.
|        2.  Set the cookie's domain to the canonicalized request-host.
|   7.   If the cookie-attribute-list contains an attribute with an

and so on

---

From: Kari Hurtta <[email-masked]>
Date: Fri, 14 Oct 2016 22:56:31 +0300 (EEST)

Mike West <[email-masked]>: (Tue Oct 11 11:24:33 2016)

5.3.  Storage Model

typo: iof

5.3.  Storage Model
https://tools.ietf.org/html/rfc6265#section-5.3

|        attribute-name of "Domain":

Or stray letter.

/ Kari Hurtta