Re: expiry changes / cookie events

Sebastian Kamp wrote:

> On Wednesday 01 August 2001 20:27, Lorrie Cranor wrote:
> > ...
> > These changes eliminate the use of
> > HTTP headers for determining policy and policy reference
> > file expiry, move the EXPIRY element to be a child of
> > the POLICIES element, and clarify the meaning of expiry.
> >
> > In addition, we will change sections 3.2.1 and 3.2.2 to
> > move the EXPIRY element to be a child of the POLICIES
> > element instead of the POLICY element (and update
> > the DTD and schema accordingly).
>
> 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.


> > user agents MUST use only non-expired policies
> > and policy reference files when evaluating new set-cookie events."
>
> This is confusing. Maybe I am wrong, but isn't setting a cookie (or rather
> letting it set) is actually harmless? I think sending a cookie (back to
the
> domain which set it) is the crucial moment. The policies and policy
> references involved should not be expired the moment we *send* a cookie.
> Since there could elapse quite a period of time between these two events,
I
> think this is an important difference.

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.

Lorrie

Received on Friday, 3 August 2001 12:10:55 UTC