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

["Yngve Nysaeter Pettersen" <[e-mail]>]

On Thu, 11 Mar 2010 03:23:03 +0100, Adam Barth <[e-mail]> wrote:

> Thanks for your detailed comments.  Responses inline.
>

>> * Section 2. "General nonsense"? Maybe a more "appropriate" title should
>> be used?
>
> I'm open to suggestions.  The term "general nonsense" comes from the
> mathematics literature, where it refers to somewhat boilerplate
> information that needs to be included for correctness.

In some documents I've seen these are included in the introduction  
section, such as in RFC 2616

I have tended to reference syntax conventions at the beginning of the  
syntax section

>> * 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.
>
> That's a good point to bring up.  I wasn't sure where to put that
> warning, so I put it right before the examples.
>
> [[
>       <t>If a server sends multiple responses containing Set-Cookie  
> headers
>       concurrently to the user agent (e.g., when communicating with the  
> user
>       agent over multiple sockets), these responses create a "race  
> condition"
>       that can lead to unpredictable behavior.</t>
> ]]

Looks OK

>> * 4.1 definition of Max-age is missing. It is used in 5.2.1
>
> This is intentional.  The folks in the working group didn't think we
> should recommend Max-Age to server operators because it's not
> implemented in Internet Explorer.  I'm optimistic that IE will
> implement it, but that's why it's not there.

I still think it should be there, perhaps with a note that not all clients  
support it (Opera didn't until a couple of years ago), and that servers  
should complement it with an Expires attribute.

>> * 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
>
> I made this slightly stronger:
>
> [[
>           <t>Servers SHOULD NOT include two Set-Cookie header fields in  
> the
>           same response with the same cookie-name.</t>
> ]]

OK

> Using the same cookie name in overlapping scopes is bad new bears.

Yes.

>> * 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?
>
> Done:
>
> [[
>           <t>To maximize compatibility with user agents, servers SHOULD  
> use
>           sane-cookie-dates before 2036 due to 32-bit "time_t" rollover.
>           Hopefully the industry will resolve this issue in some way as  
> 2036
>           approaches.</t>
> ]]

OK

>> * 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
>
> The quoted-string production is not widely implemented and explicitly
> forbidden by this document.  See
> <http://trac.tools.ietf.org/wg/httpstate/trac/ticket/2> for more
> information.

OK

>> * 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
>
> I've added .co.uk as an example here.  This section doesn't contain
> any requirements on user agents, so anything more than advisory for
> servers belongs in Section 5.  In Section 5, we describe the
> requirements on user agents about this issue.  The requirements are on
> the SHOULD-level, not the MUST-level, as discussed by the working
> group in connection with Ticket 3 (search the archives for emails with
> "Ticket 3" in the subject).

OK

>> * 5.1.1  delimiter  should include which ASCII character each hex value
>> represent in a comment
>
> There are too many of them.  I'd rather folks just wrote the hex
> values in their code.  The ASCII representations are just nonsense.

But perhaps the more commonly used should be mentioned?

>> * 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.
>
> This is <http://trac.tools.ietf.org/wg/httpstate/trac/ticket/10>.

Forgot about that correspondence.

>> * 5.3 Have the name of "Mozilla Public Suffix list" been checked? just  
>> to
>> make sure the name is correct
>
> What do you mean by has the name been checked?  The first hit on
> Google for that term is the web site we intend to refer to.

OK. I managed to dig up an email on the topic which also specifically uses  
that name.

>> * 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)
>
> I'm not too worried about that.  It's virtually impossible to hit the
> current time on the dot.

It is possible for "max-age=0"

>> * 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)
>
> Elide is a perfectly good word that's been in the language for over
> 200 years.  :)
>
> http://www.merriam-webster.com/dictionary/elide

It may be, but my point is mostly that it is AFAIK not frequently used.


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