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

"Paul E. Jones" <paulej@packetizer.com> Tue, 16 March 2010 17:20 UTC

Return-Path: <paulej@packetizer.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 B1B6B3A6816 for <http-state@core3.amsl.com>; Tue, 16 Mar 2010 10:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.669
X-Spam-Level:
X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_05=-1.11]
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 8HC8DJlLh49j for <http-state@core3.amsl.com>; Tue, 16 Mar 2010 10:20:19 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 7179A3A67A8 for <http-state@ietf.org>; Tue, 16 Mar 2010 10:20:18 -0700 (PDT)
Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o2GHK9VO004899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Mar 2010 13:20:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1268760016; bh=ATyy3dPiwnVwmLFSS1Ibj9YOlbbzETQB5Kz1Y+IcGn8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=hs5F18ot0zdY0wucTcQlV3XNqdne4tVU3zH/8WuK+Dy8XUHpWGs0NsUHggtQ5VdZC 29PJAHti3wfEYtYRyLjAerPewZhdcTJ0b+ZahWl9A0Tv7SD6/FDeJ1yfAnOq2UHd+w TwYRVeTzj2GmZqKR3ljPLBi/UOmozSeQkxFTMc5I=
Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o2GHK3QN019560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Mar 2010 13:20:04 -0400
From: "Paul E. Jones" <paulej@packetizer.com>
To: yngve@opera.com, 'Adam Barth' <ietf@adambarth.com>
References: <5c4444771003071050r3475798co95cc192d1f2e8190@mail.gmail.com> <op.u9dpzpdoqrq7tp@acorna> <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>
In-Reply-To: <op.u9ny5vnavqd7e2@killashandra.oslo.osa>
Date: Tue, 16 Mar 2010 13:20:01 -0400
Message-ID: <013601cac52c$ec0c1c50$c42454f0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Content-language: en-us
Thread-index: AcrFEwJ4VoenoluMTv6+EdsOZoQaBgAGVZOQ
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:20:21 -0000

> 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.  Perhaps we might
even go a step further and say that the UA may reduce the expiration time as
it sees fit.

Paul