[updates to the 15 December 2000 P3P1.0 Candidate Recommendation]
<uniqueID/> should be <uniqueid/> in the comments on BNF 
All changes suggested by Mark adopted, except as follows:
2.2 we will use the term resource instead of entity and document (in other sections too). We will add a definition of resource to the glossary.
2.2.1 We will change the language about the WKL from a SHOULD to a MAY and note that it is strongly encouraged.
184.108.40.206.4 we will leave as-is
220.127.116.11 Change third paragraph to:
A policy referenced in a policy reference file can be applied only to URIs on the DNS (Domain Name System) host that reference it. Thus, for example, a policy reference file at the well known location of host www.example.com can apply policies only to resources on www.example.com. However, if foo.example.com includes a P3P HTTP header in its responses that references a policy reference file on bar.example.com, that policy reference file would be applied to resources on foo.example.com (not bar.example.com or www.example.com). The same policy reference file might be referenced in P3P HTTP headers sent by multiple hosts, in which case it may be applied to each host that references it. The INCLUDE and EXCLUDE elements MUST specify URI patterns relative to the root of the DNS host to which they are applied. This requirement does NOT apply to the location of the P3P policy file (the about attribute on the POLICY-REF element).
18.104.22.168 change domain attribute to include protocol, hostname, and port (to be explained in substantive change section below)
2.3.4 Add definition of action URI
The ACTION URI is the URI given in the action attribute of the HTML <FORM> element, as defined in section 17.3 of [HTML]
Move [HTML] from the non-normative references to the normative references.
Change HEAD example to PUT Or DELETE
2.4.1 Change last paragraph to:
If no policy is declared for a given URI by a policy reference file at the well-known location, and if a user agent discovers more than one non-expired P3P policy for a given URI (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.
2.4.4 Remove this section completely
4.1 Drop highlighted sentence
Add to last paragraph of Section 1.1.3 P3P Policies: "In addition, note that each P3P policy is applied to specific web resources (web pages, images, cookies, etc.) listed in a policy reference file. By placing one or more P3P policies on a web site, a company or organization does not make any statements about the privacy practices associated with other web resources not mentioned in their policy reference file, with other online activities that do not involve data collected on web sites covered by their P3P policy, or with offline activities that do not involve data collected on web sites covered by their P3P policy."
first paragraph of 2.1: page --> web resource
example 2.1 page --> resource
22.214.171.124.1 page --> resource
1.3 Terminology, change definition of service to: Service A program that issues policies and (possibly) data requests. By this definition, a service may be a server (site), a local application, a piece of locally active code, such as an ActiveX control or Java applet, or even another user agent. Typically, however, a service is usually a Web site. In this specification the terms "service" and "Web site" are often used interchangeably.
1.3 Terminology, change defintion of User to: User An individual (or group of individuals acting as a single entity) on whose behalf a service is accessed and for which personal data exists. P3P policies describe the collection and use of personal data about this individual or group.
3.2.2 Add to definition of opturi: "Note that the opt-in or opt-out procedures are determined by each site and may not necessarily include a central mechanism for the entire site or an automated online mechanism."
3.3.7 Change wording of optional definition to: indicates whether or not the site requires visitors to submit this data element to access a resource or complete a transaction; "no" indicates that the data element is not optional (it is required), while "yes" indicates that the data element is optional. The default is "no." The optional attribute is used only in policies (not in data schema definitions).
change "about a person" to "about a person or legal entity"
change text to "The business data set features a subset of user data relevant for describing legal entities. In P3P1.0, this data set is primarily used for declaring the policy entity, a-though it should also be applicable to business-to-business interactions."
Policy reference files make statements about what policy applies to a given URI. Policy reference files support a simple wildcard character to allow making statements about regions of URI-space. The character asterisk ("*") is used to represent a sequence of 0 or more of any character. No other special characters (such are those found in regular expressions) are supported.
Note that since the asterisk is also a legal character in URIs ([URI]), some special conventions have to be followed when encoding such "extended URIs" in a policy reference file:
URI escaping and unescaping is very much dependant on the actual scheme used, and might even differ between individual components within a single scheme, so no simple rule for which characters need to be escaped can be given here. Please refer directly to [URI] for details on the standard escaping process. Note that P3P user agents MAY ignore any URI pattern that does not conform to [URI].
The wildcard character MAY be used in the INCLUDE and EXCLUDE elements, in the COOKIE-INCLUDE and COOKIE-EXCLUDE elements, and in the HINT element.
add a note to the first paragraph of seciton 3.4 that Categories should not be used with data references in the ENTITY field
(This was adopted by the working group August 28, but accidently ommited from the 24 September 2001 working draft.) Now that each POLICY has to be contained in a POLICIES it makes much sense to actually let the dataschema be embedded in the POLICIES, and not in the POLICY. This is clearer, better, and entails the same functionalities: now we have to be careful not to allow more than one local dataschema embedded in a single file, while with this solution, we can have this restriction directly in the XML Schema/DTD; also, this allows more policies to use the same local dataschema, which is impossible in the present setting.
Changes to make it illegal to refer to #dynamic in a policy and related issues.
Add the following paragraph to the end of section1.1.4 P3P User Agents (to make explicit previous understanding of the working group):
Update section 2.3 to allow for <EXTENTION> element to be included in policy reference file. Changes needed to BNF 6/7 and add new section 126.96.36.199 The EXTENSION element -- similar to section 3.5. Remove note in 2.3.2 about not supporting extension mechanism. We also need to update the DTD and schema for the PRF to include this.
Replace 2.3.2 text with: This section defines the syntax and semantics of P3P policy reference files. All policy reference files. MUST be encoded using [UTF-8] and conform to the syntax specified in this section. The XML schema provided in Appendix 4 serves as the normative definition of this syntax. The DTDs provided in Appendix 5 MAY be used to verify that P3P files are valid. However, there are some valid files that may be rejected if checked against the DTD due to their use of name spaces.
Replace second paragraph of 3.2 with:
All policies MUST be encoded using [UTF-8] and conform to the syntax specified in this section. The XML schema provided in Appendix 4 serves as the normative definition of this syntax. The DTDs provided in Appendix 5 MAY be used to verify that P3P files are valid. However, there are some valid files that may be rejected if checked against the DTD due to their use of name spaces. In cases where the p3p vocabulary is not precise enough to describe a web site's practises, sites should use the vocabulary terms that most closely match their practices and provide further explanation in the consequence field and/or their human-readable policy. However, policies MUST NOT make false or misleading statements.
Add a new section 2.4.4 (old was removed as per E21 above): Policy and Policy Reference File Processing by User Agents
P3P user agents MUST only render or act upon P3P policies and policy reference files that are well-formed XML.
P3P user agents SHOULD only render or act upon P3P policies and policy reference files that conform to the XML schema given in Appendix 4, and user agents SHOULD NOT rely upon any part of a policy or policy reference file that does not conform to this XML schema.
User agents MUST NOT locally modify a P3P policy or policy reference file in order to make it conform to the XML schema.
Rename section 3.6 "User preferences" and add the following paragraph:
P3P user agents MUST act according to the preference settings selected by the user. This requires that they be able to process policy and policy reference files as appropriate to evaluate each policy with respect to a user's preferences or other criteria specified by the settings. Depending on these settings, this may require, for example, that the user agent verify that required parts of the P3P policy are present, or check that the syntax of the entire policy is valid.
Substitute new HINT text to change the HINT attributes and make this section more clear.
Add to introduction: P3P user agents are encouraged to recognize this schema as well as http://www.w3.org/2001/09/P3Pv1.xsd . The only differences between these two schemas are a change in the name of the "domain" attribute of the HINT element to "scope" and the addition of the EXTENSION element to the policy reference file. User agents may also find it useful to recognize http://www.w3.org/2000/12/P3Pv1.xsd.
Add to the first paragraph after the list of attributes: If the value of the domain attribute is set to the dot character ("."), the domain will match only cookies that omit the domain attribute (and thus have domain equivalent to the request host as per RFC 2965).
at the end of this section use the term "dot" instead of "full stop"
Change XML Schema and DTD to make DATA-GROUP, PURPOSE, RECIPIENT, and RETENTION optional if the NON-IDENTIFIABLE element is present in a statement, but always require them otherwise. Also always require that there be at least one STATEMENT in every policy.
A STATEMENT element may optionally contain the NON-IDENTIFIABLE element, signifying either that there is no data collected under this STATEMENT, or that all of the data referenced by that STATEMENT will be anonymized upon collection.
<NON-IDENTIFIABLE/> This element signifies that either no data is collected (including Web logs), or that the organization collecting the data will anonymize the data referenced in the enclosing STATEMENT. In order to consider the data "anonymized", there must be no reasonable way for the entity or a third party to attach the collected data to the identity of a natural person. Some types of data are inherently anonymous, such as randomly-generated session IDs. Data which might identify natural people in some circumstances, such as IP addresses, names, or addresses, must have a non-reversible transformation applied in order be considered "anonymized".
An example of a non-reversible transformation is removing the last seven bits of an IP address and replacing them with zeros. This transformation must be applied to all copies of the data, including those that might be stored on backup tapes. An algorithm that replaces identified data with unique corresponding values from a table is not considered non-reversible. In addition, a one-way cryptographic hash would not be considered non-reversible if the set of possible data values is small enough that all possible hashed values can be generated and compared with the value that someone is attempting to reverse.
If the NON-IDENTIFIABLE element is present in any STATEMENT elements in a policy, then a human readable explanation of how the data is anonymized MUST be included or linked to at the discuri.
Add to server requirements: "If the user agent suppresses the Accept-Language header as part of safe-zone operation, the server is free to choose any of the available translations.”
Add to first paragraph: "Servers SHOULD return a localized policy in response to an HTTP request with an Accept-Language header when a policy matching the given language preferences is available."
Add something like "The POLICY, POLICIES, META, and DATA-SCHEMA elements MAY take an xml:lang attribute to indicate the language of an human-readable fields they contain." (give URI for list of language codes)
Update XML schema and DTD to include optional xml:lang attribute.
Update policy and PRF examples in spec to include xml:lang attribute.
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/12/11 21:36:47 $ by $Author: lorrie $