Definition of Data set: "user.home.postal" should be "user.home-info.postal"
"indovidual" should be "individual"
"presudo" should be "pseudo"
"preudo" should be "pseudo"
http://www.w3.org/2000/12/P3Pv1.dtd needs to be updated as well
Example 3.2
"identity of natural" should be "identity of a natural"
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...."
BNF [54] is missing the location category: "LOC" | ; for <location/>
example 4.1, opt_out should be opt-out
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.
<contact-and-other/> change "to other information" to "to certain other information"
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
The first extension mechanism example in section 3.5 should have the attribute optional="no" on the <EXTENSION> tag.
Remove "; none of the mechanisms overrides the other." from the third paragraph of 2.2
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.
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
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
.
Wording changes as described in email
Add the following sentence at the end of this section: "Note that the link tag is not case sensitive."
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."
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.
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.
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).
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):"
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."
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."
other-purpose compact token changed from "OPT" to "OTP" to be consistent with other "other" tokens.
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
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."
add the following definitions (we've already been using these terms, but we did not formally define them:
add new data element user.login
Wording changes related to identifiable
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.
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.
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.
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.
The required - attribute of the <current /> purpose was dropped. It gave no additional semantics.
The <customization/> - purpose was dropped.
beforehand, the Specification contained "affirmative" customization. The definition was:
<customization/>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"/>
Change of the definition of <tailoring/>.
The old definition was:
<tailoring/>The new definition is:
<tailoring/>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.
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
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."
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.
All POLICY elements must now be contained within a POLICIES element. The name attribute of the POLICY element is now mandatory all the time.
New section to clarify how P3P is used over non-standard HTTP ports and other protocols (such as SSL).
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.
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."
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.
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.
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 $