Re: [http-state] Make draft-abarth-cookie-06 a working group item?

[Daniel Stenberg <[e-mail]>]

On Fri, 11 Dec 2009, Adam Barth wrote:

> Now that we're officially a working group, I propose that we adopt 
> draft-abarth-cookie-06 as working group item draft-ietf-http-state-cookie:

+1

In general this is a pretty good spec now.

Here's some additional random thoughts on the current version:

Max-age is now specified to be:

       The value of the Max-Age attribute represents the maximum
       lifetime of the cookie, measured in seconds from the moment the
       user agent receives the cookie

RFC2109 and 2965 that both include max-age defined Max-age to be:

       The Max-Age attribute defines the lifetime of the cookie, in seconds.

... with no mention of exactly when the cookie's birth is. I figure we can 
define it to be since the receive moment for convenience if nothing else. 
Counting from the sending moment would be hard, even if I bet most server side 
implementations basically assumes it is from the moment they send the cookie. 
The difference should be miniscule in most cases.

I have some problems with this phrase in 4.2.1:

    NOTE: If the server supplies a Set-Cookie header that does not
    conform to the grammar in Section [TODO], the user agent might not
    supply a Cookie header that conforms to the preceding grammar.

Is that a way to say that if the server violates the spec, so can the client? 
I don't see any reason to A) offer the client a way to not adhere to the spec 
and B) imply that the client would deal with improplerly formatted cookies in 
any particular way that isn't even following this spec! But of course, I'm not 
sure what the [TODO] is so I might have misunderstood this paragraph.

And for the sake of it, I'll maintain that I am against section 5.3 rule 
number 2. I argue that both those cookie sort order keys are not a MUST. I 
just cannot agree with that.

-- 

  / daniel.haxx.se