2.3.2.3 Policy reference file lifetimes and the EXPIRY element

2.3.2.3.1 Motivation and mechanism

It is desirable for servers to inform user agents about how long they can use the claims made in a policy reference file. By enabling clients to cache the contents of a policy reference file, it reduces the time required to process the privacy policy associated with a Web page. This also reduces load on the network. In addition, clients that don't have a valid policy reference file for a URI will need to use "safe zone" practices for their requests. If clients have policy reference files that they know are still valid, then they can make more informed decisions on how to proceed.

In order to achieve these benefits, policy reference files SHOULD contain an 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 EXPIRY element 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 24-hour lifetime.

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.

2.3.2.3.2 The EXPIRY element

The 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

=

"<EXPIRY" (absdate|reldate) "/>"

absdate

=

`date="` HTTP-date `"`

reldate

=

`max-age="` delta-seconds `"`

2.3.2.3.3 Requesting Policies and Policy Reference Files

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:

1. When a user agent receives a policy reference file (or policy), if it was served from a network cache, the user agent needs to know how long the policy reference file or policy resided in the network cache. This time MUST be subtracted from the lifetime of the policy or policy reference file which uses relative expiry.
2. When a user agent needs to revalidate a policy reference file (or policy), it needs to make sure that the revalidation fetches a current version of the policy reference file (or policy). For example, consider the case where a user agent holds a policy reference file with a 1 day relative expiry. If the user agent refetches it from a network cache, and the file has been residing in the network cache for 3 days, then the resulting file is useless.

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 EXPIRY element. The network cache could then serve the policy reference file (or policies) to clients beyond the lifetime in theEXPIRY; 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:

1. Use cache-control request-headers to ensure that the received response is not older than its lifetime. This is done with the max-age cache-control setting, with a maximum age significantly less than the lifetime of the policy reference file (or policies). For example, a user agent could send Cache-Control: max-age=43200, thus ensuring that the response is no more than 12 hours old.
2. Subtract the age of the response from the lifetime of the policy reference file (or policies), if it uses a relative expiry time. The age of the response is given by the Age: HTTP response-header.

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.

2.3.2.3.4 Error handling for policy reference file and policy lifetimes

The following situations have their semantics specifically defined:

1. An absolute expiry date in the past renders the policy reference file (or policies) useless, as does an invalid or malformed expiry date, whether relative or absolute. In this case, user agents MUST act as if NO policy reference file (or policies) is available. See section 2.4.7 "Absence of Policy Reference File" for the required procedure in such cases.
2. A relative expiration time shorter than 86400 seconds (1 day) is considered to be equal to 86400 seconds.
3. When a policy reference file contains more than one EXPIRY element, the first one takes precedence for determining the lifetime of the policy reference file.