W3C home > Mailing lists > Public > www-p3p-policy@w3.org > August 2001

Re: expiry changes / cookie events

From: Lorrie Cranor <lorrie@research.att.com>
Date: Sun, 5 Aug 2001 08:13:57 -0400
Message-ID: <01de01c11da8$1aef82e0$3a06cf87@research.att.com>
To: "Sebastian Kamp" <kamp@ti.informatik.uni-kiel.de>, <www-p3p-dev@w3.org>, <www-p3p-policy@w3.org>
> On Friday 03 August 2001 18:11, Lorrie Cranor wrote:
> > > ...
> > > Is it correct that the only way then to associate a lifetime to a
> > > (other than 24-hours) is by putting it into a POLICIES element?
> > > If this was true, I'd find it somehow inconvenient.
> >
> > Correct.
> Ok, let me pose an explicit question then. Why is this so? What is the
> advantage of this solution?

It makes for simpler implementations -- there's only one place
you have to look to find an expiration date. Also, we are no longer
overloading the semantics of the HTTP headers.

Why do you find this solution incovenient?

> the moment you send a cookie
> is the moment to make sure a policy applying is still valid, the moment a
> cookie is set is irrelevant.
> This statement is meant as an opinion as well as an implied question to
> list. Do you share this view or does anybody have another understanding of
> this?

I think we all agree that the moment you send a cookie is the
moment that is relavant with respect to privacy. But it is easier for
implementations to find cookie policies when the cookie is set.
So we expect most implementations to evaluate cookeis when they
are set and to record how long the policy is valid. When a user returns
to a site and the user agent has to decide whether or not to send the
cookie back, in many cases it will already know what to do. Only
if the policy has expired prior to the cookie expiring does it need to
check to see if there is a new policy available. But you are welcome
to build an implementation that only evaluates cookie policies before
sending cookies if that's what you prefer.

Received on Sunday, 5 August 2001 08:29:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:07 UTC