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

"Yngve Nysaeter Pettersen" <yngve@opera.com> Thu, 11 March 2010 17:31 UTC

Return-Path: <yngve@opera.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 655983A6BBC for <http-state@core3.amsl.com>; Thu, 11 Mar 2010 09:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vat+kV2kY-jb for <http-state@core3.amsl.com>; Thu, 11 Mar 2010 09:31:47 -0800 (PST)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id B56663A6DC8 for <http-state@ietf.org>; Thu, 11 Mar 2010 09:06:25 -0800 (PST)
Received: from killashandra.oslo.osa (pat-tdc.opera.com [213.236.208.22]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o2BH6NwC023405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Mar 2010 17:06:28 GMT
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Adam Barth" <ietf@adambarth.com>
References: <5c4444771003071050r3475798co95cc192d1f2e8190@mail.gmail.com> <op.u9dpzpdoqrq7tp@acorna> <5c4444771003101823u25842652o33b49b2be81f4cfc@mail.gmail.com>
Date: Thu, 11 Mar 2010 18:06:27 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Yngve Nysaeter Pettersen" <yngve@opera.com>
Organization: Opera Software
Message-ID: <op.u9exs1lkvqd7e2@killashandra.oslo.osa>
In-Reply-To: <5c4444771003101823u25842652o33b49b2be81f4cfc@mail.gmail.com>
User-Agent: Opera Mail/10.50 (Win32)
Cc: http-state <http-state@ietf.org>
Subject: Re: [http-state] draft-ietf-httpstate-cookie-05 posted
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: yngve@opera.com
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Mar 2010 17:31:48 -0000

On Thu, 11 Mar 2010 03:23:03 +0100, Adam Barth <ietf@adambarth.com> 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: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************