- 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>
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 POLICIES-element. 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 Regards Sebastian
Received on Sunday, 5 August 2001 11:32:11 UTC