In order to achieve these benefits, policy reference files SHOULD contain
EXPIRY element, which indicates the lifetime of the policy
reference file. If the policy reference file does not contain an
EXPIRY element, then it is given a 24-hour lifetime.
The lifetime of a policy reference file tells user agents how long they can rely on the claims made in the policy reference file. By setting the lifetime of a policy reference file, the publishing site agrees that the policies mentioned in the policy reference file are appropriate for the lifetime of the policy reference file. For example, if a policy reference file has a lifetime of 3 days, then a- user agent need not reload that file for 3 days, and can assume that the references made in that policy reference file are good for 3 days. All of the policy references made in a single policy reference file will receive the same lifetime. The only way to specify different lifetimes for different policy references is to use separate policy reference files.
The same mechanism used to indicate the lifetime of a policy reference
file is also used to indicate the lifetime of a P3P policy. Thus P3P
POLICIES elements SHOULD have an
associated with them as well. This lifetime applies to all P3P policies
contained within that
POLICIES element. If there is no
EXPIRY element associated with a P3P policy, then it is given a
When picking a lifetime for policies and policy reference files, sites need to pick a lifetime which balances two competing concerns. One concern is that the lifetime ought to be long enough to allow user agents to receive significant benefits from caching. The other concern is that the site would like to be able to change their policy for new data colleciton without waiting for an extremely long lifetime to expire. It is expected that lifetimes in the range of 1-7 days would be a reasonable balance between these two competing desires. Sites also need to remember the policy update requirements when updating their policies.
When a policy reference file has expired, the information in the policy reference file MUST NOT be used by a user agent until that user agent has successfully revalidated the policy reference file, or has fetched a new copy of the policy reference file.
Note that while user agents are not obligated to revalidate policy reference files or policy files that have not expired, they MAY choose to revalidate those files before their expiry period has passed, in order to reduce the need for using "safe zone" practices. A valid P3P user agent implementation NEED NOT contain a cache for policies and policy reference files, though the implementation will have a better performance if it does.
EXPIRY element can be used in a policy reference file
and/or in a
POLICIES element to state how long the policy
reference file (or policies) remains valid. The
expiry is given as either an absolute expiry time, or a relative expiry time.
An absolute expiry time is a time, given in GMT, until which the policy
reference file (or policies) is valid. A relative
expiry time gives a number of seconds for which the policy reference file (or
policies) is valid. This expiry time is relative to
the time the policy reference file (or policies) was
requested or last revalidated by the client. This computation MUST be done
using the time of the original request or revalidation, and the current time,
with both times generated from the client's clock. Revalidation is defined in
section 13.3 of [HTTP1.1].
The minimum amount of time for any relative expiry time is 24 hours, or 86400 seconds. Any relative expiration time shorter than 86400 seconds MUST be treated as being equal to 86400 seconds in a client implementation. If a client encounters an absolute expiration time that is in the past, it MUST act as if NO policy reference file (or policy) is available. See section 2.4.7 "Absence of Policy Reference File" for the required procedure in such cases.
"<EXPIRY" (absdate|reldate) "/>"
`date="` HTTP-date `"`
`max-age="` delta-seconds `"`
|Here, HTTP-date is defined in section 3.3.1 of [HTTP1.1], and delta-seconds is defined in section 3.3.2 of [HTTP1.1].|
In a real-world network, there may be caches which will cache the contents of policies and policy reference files. This is good for increasing the overall network performance, but may have deleterious effects on the operation of P3P if not used correctly. There are two specific concerns:
HTTP 1.1 [HTTP1.1] contains powerful cache-control mechanisms to allow clients to place requirements on the operations of network caches; these mechanisms can resolve the problems mentioned above. The specific method will be discussed below.
HTTP 1.0, however, does not provide those more sophisticated cache control
mechanisms. An HTTP 1.0 network cache will, in all likelihood, compute a
cache lifetime for the policy reference file (or policies) based on the
file's last-modified date; the resulting cache lifetime could be
significantly longer than the lifetime specified by the
element. The network cache could then serve the policy reference file (or
policies) to clients beyond the lifetime in the
result would be that user-agents would receive a useless policy reference
file (or policies).
The second problem with HTTP 1.0 network caches is that a user agent has no way to know how long the reference file may have been stored by the network cache. If the policy reference file (or policies) relies on relative expiry, it would then be impossible for the user agent to determine if the reference file's lifetime has already expired, or when it will expire.
Thus, if a user agent is requesting a policy reference file or a policy, and does not know for certain that there are no HTTP 1.0 caches in the path to the origin server, then the request must force an end-to-end revalidation. This can be done with the Pragma: no-cache HTTP request-header. Note that neither HTTP nor P3P define a way to determine if there is a HTTP 1.0-compliant cache in any given network path, so unless the user agent has this information derived from an outside source, it MUST force the end-to-end revalidation.
If the user agent has some way to know that all caches in the network path to the origin server are compliant with HTTP 1.1 (or that there are no caches in the network path to the origin server), then the client MUST do the following:
Note that it is impossible for a client to accurately predict the amount of latency that may affect an HTTP request. Thus, if the policy reference file covering a request is going to expire soon, clients MAY wish to consider warning their users and/or revalidating the policy reference file before continuing with the request.
The following situations have their semantics specifically defined:
EXPIRYelement, the first one takes precedence for determining the lifetime of the policy reference file.