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

Re: expiry changes / cookie events

From: Sebastian Kamp <kamp@ti.informatik.uni-kiel.de>
Date: Sun, 5 Aug 2001 17:30:27 +0200
To: "Lorrie Cranor" <lorrie@research.att.com>, <www-p3p-dev@w3.org>, <www-p3p-policy@w3.org>
Message-Id: <01080517302713.07894@rosmarin>
On Sunday 05 August 2001 14:13, you wrote:
> > 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?

First of all I had the (admittedly vague) intuition, that a policy rather 
than a collection of policies should have an expiry date.
A more severe argument is that in the case of "inline" policies (a 
POLICIES-element within a PRF) it won't be possible anymore to assign 
different expiry dates to different policies, because a PRF allows only one 
Besides it is slightly more work to extract a policy from a file, when one 
has to consider a POLICIES/EXPIRY element wrapped around the actual 
policydata. A policy inherits its expiry date from its container, but there 
is an additional indirection.

On the other hand - unfortunately I got the idea first when Nikolaj and me 
were discussing this matter - one can treat inline policies now the same way 
one treats external/stand-alone policies.
This is a remarkable advantage I did not see before ;-)

> Lorrie

Received on Sunday, 5 August 2001 11:32:11 UTC

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