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

Adam Barth <ietf@adambarth.com> Tue, 16 March 2010 17:55 UTC

Return-Path: <ietf@adambarth.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 86EED3A6845 for <http-state@core3.amsl.com>; Tue, 16 Mar 2010 10:55:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.945
X-Spam-Level:
X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 iPHMx6UKdfav for <http-state@core3.amsl.com>; Tue, 16 Mar 2010 10:55:34 -0700 (PDT)
Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id 559503A67A8 for <http-state@ietf.org>; Tue, 16 Mar 2010 10:55:34 -0700 (PDT)
Received: by bwz3 with SMTP id 3so250547bwz.29 for <http-state@ietf.org>; Tue, 16 Mar 2010 10:55:39 -0700 (PDT)
Received: by 10.204.24.134 with SMTP id v6mr97703bkb.204.1268762136106; Tue, 16 Mar 2010 10:55:36 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by mx.google.com with ESMTPS id 16sm3846121bwz.5.2010.03.16.10.55.34 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Mar 2010 10:55:35 -0700 (PDT)
Received: by vws13 with SMTP id 13so81766vws.31 for <http-state@ietf.org>; Tue, 16 Mar 2010 10:55:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.128.78 with SMTP id j14mr26531vcs.176.1268762133367; Tue, 16 Mar 2010 10:55:33 -0700 (PDT)
In-Reply-To: <013601cac52c$ec0c1c50$c42454f0$@com>
References: <5c4444771003071050r3475798co95cc192d1f2e8190@mail.gmail.com> <5c4444771003101823u25842652o33b49b2be81f4cfc@mail.gmail.com> <alpine.DEB.2.00.1003112201360.25452@tvnag.unkk.fr> <op.u9feulgkqrq7tp@acorna> <009401cac476$eb8c83c0$c2a58b40$@com> <5c4444771003151240h61a87c3fp9a1649d1163111ce@mail.gmail.com> <009a01cac489$47f0fda0$d7d2f8e0$@com> <5c4444771003151510n2264a33ct26f627a11b202b16@mail.gmail.com> <op.u9ny5vnavqd7e2@killashandra.oslo.osa> <013601cac52c$ec0c1c50$c42454f0$@com>
From: Adam Barth <ietf@adambarth.com>
Date: Tue, 16 Mar 2010 10:43:36 -0700
Message-ID: <5c4444771003161043l69a9035epd90a38102fe29ab1@mail.gmail.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Daniel Stenberg <daniel@haxx.se>, 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
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: Tue, 16 Mar 2010 17:55:35 -0000

On Tue, Mar 16, 2010 at 10:20 AM, Paul E. Jones <paulej@packetizer.com> wrote:
>> I wonder if the Expires/Max-age should discourage using values more
>> than a
>> few years into the future. One thing is that it is unlikely that the
>> client will exist as long (but that to the end of client existence
>> aspect
>> is probably what the designer want); another is that the server will
>> have
>> to maintain a database for those sessions for a very long time,
>> possibly
>> leading to a lot of storage overhead; a third is that quite a few
>> people
>> frown upon the use of long-lasting cookies. Maybe a recommendation of
>> "not
>> more than" 2 or 3 years should be added as a best-practice?
>
> I think that's a reasonable recommendation, since such cookies waste space
> and might be viewed as a privacy concern by some.  We've seen stories about
> user outcry over long-lived "tracking" cookies and such.

Ok.  I'll spin up some text along these lines.

> Perhaps we might
> even go a step further and say that the UA may reduce the expiration time as
> it sees fit.

The spec already lets user agents delete any cookie at any time
because many user agents expose UI to let users delete cookies in
various ways.

Adam