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

Dan Winship <dan.winship@gmail.com> Sat, 12 December 2009 16:06 UTC

Return-Path: <dan.winship@gmail.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 4DD063A6855 for <http-state@core3.amsl.com>; Sat, 12 Dec 2009 08:06:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.335
X-Spam-Level:
X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
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 q35wgtWJL7ZX for <http-state@core3.amsl.com>; Sat, 12 Dec 2009 08:06:57 -0800 (PST)
Received: from mysterion.org (mysterion.org [69.25.196.35]) by core3.amsl.com (Postfix) with ESMTP id 946813A6825 for <http-state@ietf.org>; Sat, 12 Dec 2009 08:06:57 -0800 (PST)
Received: from x61.home.mysterion.org (151.Red-80-33-141.staticIP.rima-tde.net [80.33.141.151]) by mysterion.org (Postfix) with ESMTPA id 99661802AE; Sat, 12 Dec 2009 11:06:44 -0500 (EST)
Message-ID: <4B23BF42.2000002@gmail.com>
Date: Sat, 12 Dec 2009 11:05:22 -0500
From: Dan Winship <dan.winship@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4
MIME-Version: 1.0
To: Daniel Stenberg <daniel@haxx.se>
References: <7789133a0912111441t38d8142frecfc149e2d8464fd@mail.gmail.com> <alpine.DEB.2.00.0912120005060.16918@tvnag.unkk.fr>
In-Reply-To: <alpine.DEB.2.00.0912120005060.16918@tvnag.unkk.fr>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: http-state <http-state@ietf.org>
Subject: Re: [http-state] Make draft-abarth-cookie-06 a working group item?
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Sat, 12 Dec 2009 16:06:58 -0000

On 12/11/2009 06:48 PM, Daniel Stenberg wrote:
> 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.

For the "max-age" Cache-Control directive, you count from the time in
the Date header. We could do the same (though we need to put something
about what to do if there's no Date header).

-- Dan