Software Project Management in Practice

Compact policies are summarized P3P policies that provide hints to user agents to enable the user agent to make quick, synchronous decisions about applying policy. Compact policies are a performance optimization that is OPTIONAL for either user agents or servers. User agents that are unable to obtain enough information from a compact policy to make a decision according to a user's preferences SHOULD fetch the full policy.

In P3Pv1, compact policies contain policy information related to cookies only. The web server is responsible for building a P3P compact policy to represent the cookies referenced in a full policy. The policy specified in a P3P compact policy applies to data stored within all cookies set in the same HTTP response as the compact policy, all cookies set by scripts associated with that HTTP response, and also to data linked to the cookies.

4.1 Referencing Compact Policies

Any document transferred by HTTP MAY include a P3P compact policy through the P3P header. If a site is using P3P headers, it MAY include this on responses for all appropriate request methods , including HEAD and OPTION requests .

To specify a compact policy within the P3P header, a site specifies the compact policy in the P3P header (cf. Section 2.2.2). The P3P compact policy header has a quoted string that may contain one or more delimited tokens (the "compact policy"). Tokens can appear in any order, and the space character (" ") is the only valid delimiter . The syntax for this header is as follows :

In keeping with the rules for other HTTP headers, the name of the P3P header may be written with any casing. The contents should be specified using the casing precisely as specified in this document.

User agents MAY process the P3P-compact-policy-field.

If an HTTP response includes more than one compact policy, P3P user agents MUST ignore all compact policies after the first one.

4.2 Compact Policy Vocabulary

P3P compact policies use tokens representing the following elements from the P3P vocabulary: ACCESS , CATEGORIES , DISPUTES , NON-INDENTIFIABLE , PURPOSE , RECIPIENT , REMEDIES , RETENTION , TEST .

If a token appears more than once in a single compact policy, the compact policy has the same semantics as if that token appeared only once. If an unrecognized token appears in a compact policy, the compact policy has the same semantics as if that token was not present.

The P3P compact policy vocabulary is expressed using a developer-readable language to reduce the number of bytes transferred over the wire within a HTTP response header. The syntax of the tokens follows.

4.2.1 Compact ACCESS

Information in the ACCESS element is represented in compact policies using tokens composed by a three letter code:

4.2.2 Compact DISPUTES

If a full P3P policy contains a DISPUTES- GROUP element that contains one or more DISPUTES elements, then the server should signal the user agent by providing a single "DSP" token in the P3P-compact policy field:

4.2.3 Compact REMEDIES

Information in the REMEDIES element is represented in compact policies as follows:

4.2.4 Compact NON-IDENTIFIABLE

The presence of the NON-IDENTIFIABLE element in every statement of the policy is signaled by the NID token (note that the NID token MUST NOT be used unless the NON-IDENTIFIABLE element is present in every statement within the policy):

4.2.5 Compact PURPOSE

Purposes are expressed in P3P compact policy format using tokens composed by a three letter code plus an optional one letter attribute. Such an optional attribute encodes the value of the " required" attribute in full P3P policies: its value can be "a" , "i" and "o" , which mean that the "required" attribute in the corresponding P3P policy must be set to "always" , "opt-in" and " opt-out " respectively.

If a P3P compact policy needs to specify one or more other-purposes in its full P3P policy, a single OTP flag is used to signal the user agent that other-purposes exist in the full P3P policy.

The corresponding associations among P3P purposes and compact policy codes follow:

4.2.6 Compact RECIPIENT

Recipients are expressed in P3P compact policy format using a three letter code plus an optional one letter attribute. Such an optional attribute encodes the value of the " required" attribute in full P3P policies: its value can be "a" , "i" and "o" , which mean that the "required" attribute in the corresponding P3P policy must be set to "always" , "opt-in" and "opt-out" respectively.

The corresponding associations among P3P recipients and compact policy codes follow:

4.2.7 Compact RETENTION

Information in the RETENTION element is represented in compact policies as follows:

4.2.8 Compact CATEGORIES

Categories are represented in compact policies as follows:

Note that if a P3P policy specifies one or more other-category in its full P3P policy, a single OTC token is used to signal the user agent that other-category s exist in the full P3P policy.

4.2.9 Compact TEST

The presence of the TEST element is signaled by the TST token:

4.3 Compact Policy Scope

When a P3P compact policy is included in a HTTP response header, it applies to cookies set by the current response. This includes cookies set through the use of a HTTP SET-COOKIE header or cookies set by script.

4.4 Compact Policy Lifetime

To use compact policies, the validity of the full P3P policy must span the lifetime of the cookie. There is no method to indicate that policy is valid beyond the life of the cookie because the value of user agent caching is marginal, since sites would not know when to optimize by not sending the compact policy. When a server sends a compact policy, it is asserting that the compact policy and corresponding full P3P policy will be in effect for at least the lifetime of the cookie to which it applies.

4.5 Transforming a P3P Policy to a Compact Policy

When using P3P compact policies, the web site is responsible for building a compact policy by summarizing the policy referenced by the COOKIE-INCLUDE elements of a P3P policy reference file. If a site's policy reference file uses COOKIE-EXCLUDE elements then the site will need to manage sending the correct P3P compact policies to the user agent given the cookies set in a specific response.

The transformation of a P3P policy to a P3P compact policy may result in a loss of descriptive policy information ”the compact policy may not contain all of the policy information specified in the full P3P policy. The information from the full policy that is discarded when building a compact policy includes expiry, data group/data-schema elements, entity elements, consequences elements, and disputes elements are reduced.

Full policies that include mandatory extensions MUST NOT be represented as compact policies.

All of the purposes, recipients, and categories that appear in multiple statements in a full policy MUST be aggregated in a compact policy, as described in section 3.3.1. When performing the aggregation, a web site MUST disclose all relevant tokens (for instance, observe Example 4.1, where multiple retention policies are specified).

In addition, for each fixed category data element appearing in a statement the associated category as defined in the associated schema MUST be included in the compact policy.

The corresponding compact policy is:

"NON DSP ADM DEV PSD IVDo OUR IND STP PHY PRE NAV UNI"

4.6 Transforming a Compact Policy to a P3P Policy

Some user agents may attempt to generate a full P3P policy from a compact policy, for use in evaluating user preferences. They will not be able to provide values for the ENTITY and DISPUTES elements as well as a number of the attributes. However:

In case there are not multiple different values of compact retention, they should be able to generate a policy with an appropriate ACCESS element, and: a single STATEMENT element that contains the appropriate RECIPIENT , RETENTION , and PURPOSE elements, as well as a dynamic.miscdata element with the appropriate CATEGORIES .

In case there are multiple different values of compact retention, they should be able to generate a policy with an appropriate ACCESS element, and: multiple STATEMENT elements (as many as the different values of the compact retention) that contain a different corresponding value for the RETENTION element, the appropriate RECIPIENT , and PURPOSE elements, as well as a dynamic.miscdata element with the appropriate CATEGORIES .

Note that, in agreement with the non-ambiguity requirements stated in Section 2.4.1, a site MUST honor a compact policy for a given URI in any case (even when the full policy referenced in the policy reference file for that URI does not correspond , as per Section 4.5, to the compact policy itself).