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

Re: expiry changes / cookie events

From: Rigo Wenning <rigo@w3.org>
Date: Mon, 6 Aug 2001 13:01:55 +0200
To: Sebastian Kamp <kamp@ti.informatik.uni-kiel.de>
Cc: www-p3p-dev@w3.org, www-p3p-policy@w3.org
Message-ID: <20010806130155.C712@rigo.inria.fr>
On Sun, Aug 05, 2001 at 11:16:30AM +0200, Sebastian Kamp wrote:
> On Friday 03 August 2001 18:11, Lorrie Cranor wrote:
> > while it is true that setting the ciikie is harmless, most user
> > agents evaluate cookies at the time they are set. You may evaluate
> > them again before sending them, but certainly if the policy has
> > expired already when the cookie is set, it will still be expired at a later
> > time when it might be sent. The point of this sentence was that
> > if the only policy you know that applies to a cookie has already
> > expired when you get a set-cookie event, then you can't use it.
> The last sentence is self-evident. My point is: 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 understand, that seen from the european data protection angle,
the send-cookie has to be controled. I've always put emphasis on the
send-cookie. But it is a matter of caching, performance
optimization and ease of implementation to have the set-cookie
event only monitored. 

And here we come into the more political and less technical part of
P3P. On the set-cookie, there is a policy with a certain expiry.
The cookie is only valid during the period of that policy. On the
other hand, the service has to honor the policy unless the cookie
or the policy have expired or set a new policy by setting a new
cookie. This way, it is much simpler for user-agents as this is
much closer to current implementations. The european
-self-determination-solution- solution would be better, but would
require more effort on the implementation-side and more
round-trips. From a dogmatic point of view, the send-cookie would
be cleaner, but the WG decided to facilitate the implementation
by putting emphasis on the set-cookie event.


Received on Monday, 6 August 2001 07:08:07 UTC

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