Re: [http-state] draft-ietf-httpstate-cookie-05 posted

["Yngve N. Pettersen (Developer Opera Software ASA)" <[e-mail]>]

Hi,

On Sun, 07 Mar 2010 19:50:57 +0100, Adam Barth <[e-mail]> wrote:

> My understanding is that Monday is the deadline for uploading I-Ds
> before IETF77.  I've uploaded the latest version of the draft:
>
> http://www.ietf.org/id/draft-ietf-httpstate-cookie-05.txt
>
> If you're going to IETF77, this is the version of the draft that we'll
> be discussing.  Looking forward to seeing many of you there.

Here are some comments about this draft

* "infelicities". While the general meaning is relatively obvious  from
context, IMO a more generally known phrasing should be chosen, e.g.
"unfortunate choices"

* Section 2. "General nonsense"? Maybe a more "appropriate" title should
be used?

* Maybe discuss race conditions when a cookie set by one response is
needed in the next request, but user interaction blocks the cookie for a
while. The user agent may have to delay sending requests to prevent user
experience problems. Additionally, such race conditions can occur if one
resource depends on a cookie being set by a separate request and the
dependent request is not dependably started after receipt of the cookie
in the first request.

* 3.1 examples

           "Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure, HttpOnly"

should be

           "Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly"

Comma is not allowed as a separator in Set-Cookie; it is used in RFC 2109
and 2965 to separate multiple cookies in the same header

* 4.1 definition of Max-age is missing. It is used in 5.2.1

* 4.1 Multiple Set-cookies in the same response with the same name and
scope
should not be used. Opera ignores cookies with the same name following an
unexpired cookie, including cookies set from other parallel requests (see
also race conditions, usually only a problem when the user is manually
accepting cookies) I have also observed that such multiple cookies in the
same requets can cause problems for sites when the client picks the
"wrong" cookie

* 4.1 sane-cookie-date should IMO discourage dates past 2036 due to 32-bit
time_t rollover, at least for the time being. Might recommend best
behavior for clients, and might suggest that using too long expiration
time should be avoided?

* 4.1 cookie-value should be token or quoted-string. Quotes are
particularly needed if the value contain restricted characters, like ";" .
RFC 2109 allows quoted string

* 4.1.2.2 The domain description should emphasize that cookies with
non-dotted domain attributes MUST be refused, the example should instead
be from a ccTLD, e.g. co.uk

* 5.1.1  delimiter  should include which ASCII character each hex value
represent in a comment

* 5.1.2 The domain parser should mention IDNA encoded names, and how to
process them. IMO, all names must be converted to A-label for purposes of
comparison, and server should/(must?) only send A-labels; although clients
may understand UTF-8 encoded names.

* 5.2.2 The expires should not be processed if there is a max-age
attribute. 5.3 does specify that max-age take precedence, but it might be
an idea to specify precedence elsewhere, too.

* 5.3 Have the name of "Mozilla Public Suffix list" been checked? just to
make sure the name is correct

* 5.3 step 10: Maybe specify that client must ignore cookies with
expiration date at the current time? (similar with use of "expiration date
in the past" elsewhere)


* 5.4 "elide" is  not a word I see frequently, and may be confusing to
some readers, though it is clear from the context. (I searched through 3
CDs of Baen ebooks and found the word used in just one book)

* 7.5 should mutually distrusting server on different machines in the same
domain  be mentioned? (even though it is mentioned somewhat in 7.6)



-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************