W3C P3P

Updates to the 15 December 2000 P3P1.0 Candidate Recommendation

EDITORIAL CORRECTIONS

E1.) 1.3 Terminology

Definition of Data set: "user.home.postal" should be "user.home-info.postal"

E2.) 4.2.1 Compact PURPOSE (BNF [50]: )


"indovidual" should be "individual"
"presudo" should be "pseudo"
"preudo" should be "pseudo"

E3.) Appendix 5 XML DTD Definition (Normative)

http://www.w3.org/2000/12/P3Pv1.dtd needs to be updated as well

E4.) 3.1.2 XML encoding of policies

Example 3.2

E5.) 3.3.3 The NON-IDENTIFIABLE element

"identity of natural" should be "identity of a natural"

E6.) 5.3.6.1 URI

Change the second sentence to "The stem of a URI is defined as the information contained in the portion of the URI after the authority and up to (and including) the first '?' character in the URI...."

E7.) 4.2.4 Compact CATEGORIES

BNF [54] is missing the location category: "LOC" | ; for <location/>

E8.) 4.5 Transforming a P3P Policy to a Compact Policy

example 4.1, opt_out should be opt-out

E9.) 3.3.4 The PURPOSE element

The last three paragraphs should be removed from this section, ("Service providers MUST disclose all the recipients that....", "- Transmitting customer data....", and "Note that in some cases the above set of recipients..." ) The duplication of these paragraphs exists in "3.3.5 The RECIPIENT element" section.

E10.) 3.2.5 The ACCESS element

<contact-and-other/> change "to other information" to "to certain other information"

E11.) Correct typos found by Susan Lesch

we will make all BNF comments and strings to display to users lower case (except for acronyms) and we will spell implementer with an e rather than an o throughout

E12.) 3.5 Extension Mechanism

The first extension mechanism example in section 3.5 should have the attribute optional="no" on the <EXTENSION> tag.

E13.) 2.2 Locating Policy Reference Files

Remove "; none of the mechanisms overrides the other." from the third paragraph of 2.2

E14.) xmlns - attribute in the whole specification

Clarify that xmlns attribute should appear in <POLICY>, <POLICIES>, and <DATASCHEMA> elements only when these elements are the outer most element (not contained within another XML element that has the P3P namespace). BNF needs to be fixed for <POLICY> and <POLICIES> and note should be added to all three sections.

E15.) user.home / user.home-info

Replace all references to the user.home data element with user.home-info -- the problem occurs in the following sections: 1.3 Data set definition, 3.3.7 ref attribute of <DATA> element, 5.1 name attribute of <DATA-DEF>, and 5.4.1

E16.) 2.3.4. Forms and Related Mechanisms

Replace in second paragraph: If a user agent is unable to find a matching prefix for by If a user agent is unable to find a matching include-rule for.

E17.) 4.5 Transforming a P3P Policy to a Compact Policy

Wording changes as described in email

E18.) 2.2.3 The HTML link Tag

Add the following sentence at the end of this section: "Note that the link tag is not case sensitive."

E19.) 2.2.2 HTTP Headers

Replace "In keeping with the rules for other HTTP headers, the P3P portion of this header may be written in any case." with "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."

CLARIFYING LANGUAGE AND SUBSTANTIVE CHANGES TO THE SPECIFICATION

S1.) (6 February 2001) add: 2.4.7 Absence of Policy Reference File

P3P specification group adopted a proposal (posted to public developers mailing list 1/29/01) that if no policy reference file is available at a site, user agents must recheck the well-known location every 24 hours if the user returns to the site. 24 hours is the default expiry for policy reference files. Previously the specification did not provide any indication as to how frequently user agents should check for a policy reference file. The following language will be added as a new section 2.4.7 Absence of Policy Reference File:

If no policy reference file is available for a given site, user agents MUST assume (an empty) policy reference file exists at the well-known location with a 24 hour expiry, and therefore if the user returns to the site after 24 hours, the user agent MUST attempt to fetch a policy reference file from the well-known location again. User agents MAY check the well-known location more frequently, or upon a certain event such as the user clicking a browser refresh button. Sites MAY place a policy reference file at the well-known location that indicates that no policy is available, but set the expiry such that user agents know they need not check every 24 hours.

S2.) (12 February 2001) 3.2 Policies

P3P specification group addressed the exit criteria that requires specifying the appropriate behavior for a user agent that encounters a P3P policy with invalid syntax. The group agreed to add the following language to the intro of section 3.2:

User agents SHOULD NOT act upon or render policy data containing a syntax error. Furthermore, user agents MUST NOT act upon or render policy data containing a syntax error, unless the user has been informed in a meaningful way that there may be an error, or unless the user's preferences specify that errors may be ignored.

S3.) (26 February 2001) 5.3.5.1 Postal

The categories assigned to some of the fields in the postal address structure (section 5.3.5.1) are inconsistent. Therefore the following changes are being made:

a) city and stateprov are being changed from the physical contact information category to the demographic and socioeconomic data category.

b) organization will be assigned only to the demographic and socioeconomic data category (not the physical contact information category).

S4.) (26 February 2001) 3.3.3 The NON-IDENTIFIABLE element

The following language was added to clarify the way the non-identifiable element is aggregated across statements:

Add the following to section 3.3.1 at the end of the paragraph beginning "To simplify practice declaration": "Note that when aggregating disclosures across statements that include the NON-IDENTIFIABLE element, you may only include this element in the aggregated statement if it would otherwise appear in every statement if the statements were written separately."

Change the short paragraph in section 4.2.5 to say: "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):"

S5.) (26 February 2001) 4.2 Compact policies

Add clarifying language to section 4.2 Compact policies: "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."

S6.) (6 March 2001) add section 2.4.8: Asynchronous Evaluation

Add clarifying language as new section 2.4.8: "User-agents MAY asynchronously fetch and evaluate P3P policies. That is, P3P policies need not necessarily be fetched and evaluated prior to other HTTP transactions.This behavior may be dependent on the the user's preferences and the type of request being made. Until a policy is evaluated, the user agent SHOULD treat the site as if it has no privacy policy. Once the policy has been evaluated, the user agent SHOULD apply the user's preferences. To promote deterministic behavior, the user-agent SHOULD defer application of a policy until a consistent point in time. For example, a web browser might apply a user's preferences just after the user agent completes a navigation, or when confirming a form submission."

S7.) (27 March 2001) Section 4.2.1 Compact PURPOSE

other-purpose compact token changed from "OPT" to "OTP" to be consistent with other "other" tokens.

S8.) (3 April 2001) Section 2.3.2.3.2 The EXPIRY element

New text for this section. We now define a minumum expiry time of 24 hours and we have clarified the way the expiry time is calculated. REPLACED BY S21

S9.) (3 April 2001) Section 2.4.1 Non-ambiguity

New text for this section. This clarifies the precedence of multiple policy reference files.

(1 May 2001) add to 2.4.1 "If an HTTP response includes more than one compact policy, P3P user agents MUST ignore all compact policies after the first one."

S10.) (15 April 2001) Section 1.3 Terminology

add the following definitions (we've already been using these terms, but we did not formally define them:

Data Structure
A hierarchical description of a set of data elements. A data set can be described according to its data structure. P3P1.0 defines a set of basic datastructures that are used to describe the data sets in the P3P Base DataSchema.
Data Schema
A collection of data elements and sets defined using the P3P <DATASCHEMA> element. P3P1.0 defines a standard data schema called the P3P Base Data Schema.

S11.) (24 April 2001) Section 5.4.1 User Data and Appendix 3

add new data element user.login

S12.) (24 April 2001) Identifiable in sections 1.1.3, 1.3, 2.2.2, 2.3.2.7, 2.4.3, 3.1.1, 3.2.5, 3.3.3, 3.3.4, 3.4, 5.5.2 and appendix 7

Wording changes related to identifiable

S13.) (24 April 2001) Section 2.3.2.5 The INCLUDE and EXCLUDE elements

Replace "A policy reference file can only cover URIs on the same host as the reference file. Therefore the INCLUDE and EXCLUDE elements MUST specify only local URI prefixes; they MUST NOT refer to URIs on other hosts." with "A policyref can be applied only to URIs on the DNS host that reference it. The INCLUDE and EXCLUDE elements MUST specify URI patterns relative to the root of the DNS host to which they are applied.

S14.) (1 May 2001) Section 4 Compact Policy Scope

change last sentence of section 4 (before section 4.1) to "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.

S15.) (3 July 2001) 5.4.4 Dynamic Data

the categories defined for dynamic.clickstream.clientip and its sub-elements were inconsistent. Their categories have been adjusted to be more consistent, as described in this note.

S. 16) (27 July 2001) 3.3.4 The PURPOSE element

The old definition:

<current/>

Completion and Support of Current Activity: Information may be used by the service provider to complete the activity for which it was provided, such as the provision of information, communications, or interactive services -- for example to return the results from a Web search, to forward email, or place an order.

is replaced by:

<current/>

Completion and Support of Activity For Which Data Was Provided: Information may be used by the service provider to complete the activity for which it was provided, whether a one-time activity such as returning the results from a Web search, forwarding an email message, or placing an order; or a recurring activity such as providing a subscription service, or allowing access to an online address book or electronic wallet.

S. 17) (27 July 2001) 3.3.4 The PURPOSE element

The required - attribute of the <current /> purpose was dropped. It gave no additional semantics.

S. 18) (27 July 2001) 3.3.4 The PURPOSE element

The <customization/> - purpose was dropped.

beforehand, the Specification contained "affirmative" customization. The definition was:

<customization/>
Affirmative Customization: Information may be used to tailor or modify the content or design of the site only to specifications affirmatively selected by the particular individual during a single visit or multiple visits to the site. For example, a financial site that lets users select several stocks whose current prices are displayed whenever the user visits.

During the discussion around the "required" attribute we found, that "affirmative" customization had only the option of "opt-in" as it was "affirmative", means the user had to select and complete an action. Yuichi Koike suggested, that we drop this purpose, as the semantics could be covered with <pseudo-decision required="opt-in" /> or <individual-decision required="opt-in"/>

S. 19) (27 July 2001) 3.3.4 The PURPOSE element

Change of the definition of <tailoring/>.

The old definition was:

<tailoring/>
One-time Tailoring: Information may be used to tailor or modify content or design of the site not affirmatively selected by the particular individual where the information is used only for a single visit to the site and not used for any kind of future customization. For example, an online store that suggests other items a visitor may wish to purchase based on the items he has already placed in his shopping basket.

The new definition is:

<tailoring/>
One-time Tailoring: Information may be used to tailor or modify content or design of the site where the information is used only for a single visit to the site and not used for any kind of future customization. For example, an online store that suggests other items a visitor may wish to purchase based on the items he has already placed in his shopping basket.

As we dropped the "affirmative" customization, we modified the definition of <tailoring/>. If you look closely, you will see, that we dropped the "not affirmatively selected by the particular individual". This reflects also the dropping of "affirmative" customization.

S. 20) (27 July 2001) 2.4.1 Non-ambiguity

The group decided to give this section a better wording:

2.4.1 Non-ambiguity

User agents need to be able to determine unambiguously what policy applies to a given URI or cookie. Therefore, sites SHOULD avoid declaring more than one non-expired policy for a given URI or cookie. In some rare case sites MAY declare more than one non-expired policy for a given URI or cookie, for example, during a transition period when the site is changing its policy. In those cases, the site will probably not be able to determine reliably which policy any given user has seen, and thus it MUST honor all policies. Sites MUST be cautious in their practices when they declare multiple policies for a given URI or cookie, and ensure that they can actually honor all policies simultaneously. Because a cookie may be shared between multiple hosts in a domain, sites should be careful to honor all policies declared by any host that might have set the cookie.

If a policy reference file at the well-known location declares a non-expired policy for a given URI or cookie, this policy applies, regardless of any conflicting policy reference files referenced through HTTP headers or HTML link tags.

If an HTTP response includes references to more than one policy reference file, P3P user agents MUST ignore all references after the first one.

If an HTML file includes HTML LINK tag references to more than one policy reference file, P3P user agents MUST ignore all references after the first one.

If a user agent discovers more than one non-expired P3P policy for a given URI or cookie (for example because a page has both a P3P header and a LINK tag that reference different policy reference files, or because P3P headers for two pages on the site reference different policy reference files that declare different policies for the same URI), the user agent MAY assume any (or all) of these policies apply as the site MUST honor all of them

S.21) (1 August 2001) 2.3.2.3 expiry (and related sections)

New text for section 2.3.2.3 was adopted. 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).

The paragraph before example 2.3 in section 2.3.2.7 will be changed to say: "The policy that applies to a cookie applies until the policy expires, even if the associated policy reference file expires prior to policy expiry (but after the cookie was set). If the policy associated with a cookie has expired, then the user agent SHOULD reevaluate the cookie policy before sending the cookie. In addition, user agents MUST use only non-expired policies and policy reference files when evaluating new set-cookie events."

S.22) (7 August 2001) 2.3.2.7 The COOKIE-INCLUDE and COOKIE-EXCLUDE elements

This section will be rewritten as described in the email so that the syntax of the COOKIE-INCLUDE/EXCLUDE changes to include attributes and to allow for matching the value of a cookie.

S.23) (7 August 2001) 3.2 Policies

All POLICY elements must now be contained within a POLICIES element. The name attribute of the POLICY element is now mandatory all the time.

S.24) (14 August 2001) 2.4.3 The Safe Zone

New text to clarify.

S.25) (14 August 2001) 2.2.4 HTTP ports and other protocols

New section to clarify how P3P is used over non-standard HTTP ports and other protocols (such as SSL).

S.26) (21 August 2001) 2.3.2.6 Policy Reference Hints

The P3P Specification working group decided to remove the EMBEDDED-INCLUDE mechanism from the specification and replace it with the following "hints" mechanism. Implementers reported that EMBEDDED-INCLUDE was proving problematic due to difficulties in identifying embedded content reliably. The definition required that this determination be based on the HTTP Referer header. But this was a major problem for proxy implementations, and difficult for other user agent implementations. The group believes the hints mechanism will be significantly easier to implement than EMBEDDED-INCLUDE, while still providing a performance optimization.

S.27) (21 August 2001) 2.2.2 HTTP Headers and 2.2.3 The HTML link Tag

Add the following sentence to the second paragraph after the BNF in 2.2.2 as a clarification: "When the policyref attribute is a relative URI, that URI is interpreted relative to the request URI."

Add the following sentence after the BNF in 2.2.3 as a clarification: "When the href attribute is a relative URI, that URI is interpreted relative to the request URI."

S.28) (21 August 2001) 2.3.2.1.1 Significance of order

Add the following sentences to 2.3.2.1.1 for clarification: Note that each POLICY-REF may contain multiple INLCUDE, EXCLUDE, METHOD, COOKIE-INCLUDE, and COOKIE-EXCLUDE elements and that all of these elements within a given POLICY-REF MUST be considered together to determine whether the POLICY-REF applies to a given URI. Thus, it is not sufficient to find an INCLUDE element that matches a given URI, as EXCLUDE or METHOD elements may serve as modifiers that cause the POLICY-REF not to match.

S.29) (21 August 2001) 2.3.2.5 The POLICY-REF element

Add the following sentence to 2.3.2.5 at the end of the third paragraph for clarification: It is legal but pointless to supply a METHOD element without any INCLUDE or COOKIE-INCLUDE elements.

S.30) (21 August 2001) 2.3.2.8

Add the following sentece to 2.3.2.8 for clarification:

The METHOD element is designed to be used in conjunction with INCLUDE or COOKIE-INCLUDE elements. A METHOD element by itself will never apply a POLICY-REF to a URI.


Copyright 1997-2000 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability,trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.

last revised $Date: 2001/09/26 19:45:57 $ by $Author: lorrie $