Re: expiry changes / cookie events

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:14 UTC