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

"Paul E. Jones" <paulej@packetizer.com> Mon, 15 March 2010 19:37 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 6EE763A6861 for <http-state@core3.amsl.com>; Mon, 15 Mar 2010 12:37:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level:
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001]
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 wO9mzMY0kwWC for <http-state@core3.amsl.com>; Mon, 15 Mar 2010 12:37:28 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 24F383A6778 for <http-state@ietf.org>; Mon, 15 Mar 2010 12:37:28 -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 o2FJbJQZ029697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Mar 2010 15:37:24 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1268681846; bh=BQp1Tr0ItYvhfSodR64ieHMJUnjFPQD+Ev+gIlur7Pw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=rBPawKgTjYIRb6QUmQA4q1T8bI+RzvSyZW2NEJRAjgbflz5FYr44QEtbcC/uGHTUE KLwoP3vezIFALv+VWAfrQ1LBWEz85N4HbCcOKWXJhTrm+ghhc5XnYMUuwID+xN7H/j UC04WYzCzanBUb1bqT9ebh5E772pu4MhqPH+eDTI=
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 o2FJbBt8015905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Mar 2010 15:37:12 -0400
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'Yngve N. Pettersen \(Developer Opera Software ASA\)'" <yngve@opera.com>, "'Daniel Stenberg'" <daniel@haxx.se>, "'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>
In-Reply-To: <op.u9feulgkqrq7tp@acorna>
Date: Mon, 15 Mar 2010 15:37:10 -0400
Message-ID: <009401cac476$eb8c83c0$c2a58b40$@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: AcrBcK8AEn+mWBLHRaSB3cOthHDD6gDA28bQ
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
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: Mon, 15 Mar 2010 19:37:29 -0000

> On Thu, 11 Mar 2010 22:05:34 +0100, Daniel Stenberg <daniel@haxx.se>
> wrote:
> 
> > On Wed, 10 Mar 2010, Adam Barth wrote:
> >
> >>          <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>
> >
> > Did you actually mean 2038 or is there any particular reason why
> there's
> > a margin? See http://en.wikipedia.org/wiki/Year_2038_problem
> 
> 
> As I recall, at least some years ago, the documentation for several 32-
> bit
> time_t functions I've used clearly specified that the conversion
> methods
> to/from time_t were only valid until a specific date in 2036.

The rollover definitely occurs in 2038 if using a signed 32-bit integer to
keep track of seconds since Jan 1, 1070.  However, I would recommend not
inserting language like this into the spec, because it assumes a certain
implementation.  Dates in the cookie spec themselves are not subject to this
issue, after all.

Didn't user agents already take this into consideration?  One could convert
dates to a string format like "2010-03-15T19:32:00Z" or simply use a 64-bit
integer similar to the Unix time_t type.  In any case, we should separate
the protocol from implementation, and there's nothing preventing one from
developing a user agent that handles the year 3054 if we so desired.  There
will likely always be a maximum year supported by a user agent and, if the
expiration date exceeds that year, I would assume that the user agent will
apply the maximum expiration time it supports.

Paul