- From: Lorrie Cranor <lorrie@research.att.com>
- Date: Sun, 5 Aug 2001 08:13:57 -0400
- 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 policy > > > (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 this > 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. Lorrie
Received on Sunday, 5 August 2001 08:29:22 UTC