Re: Response to BITS comments

Dear Ms. Allen,

Thank you for your comments to the P3P Specification Working Group on
behalf of BITS. We appreciate your group taking the time to review our
specification and send us your feedback.

Let me begin by responding to your high-level comments and
recommendations.

>  It would be accurate and appropriate for the W3C to state explicitly
>  that P3P is neither a legal nor an audit standard and should not be
>  treated as such in contracts, site monitoring, and for other legal
>  and regulatory purposes.

This comment has been addressed separately by the P3P Policy and
Outreach Working Group.

>  We encourage a roll-out strategy that reflects the view that
>  development and implementation of P3P is an evolutionary process, at
>  an early stage. Therefore, certain elements included in the first
>  stage should not lead to disproportionate negative impacts.

In recognition of the fact that many companies will want to experiment
with P3P before using it to commit to honoring a privacy policy, the
P3P1.0 specification includes a TEST element. Any policies that
include this element are considered to be available for testing
purposes only. We hope companies will take advantage of this feature
as they experiment with P3P.

>  We request that W3C work with the financial services industry to
>  make changes in the language of P3P.  P3P has been developed to
>  intentionally limit the ways in which an entity can express its
>  privacy policy; for example, one of the most significant decisions
>  of the P3P Working Group was not to enable use of the word "may"
>  within the P3P nomenclature. We believe that the P3P nomenclature
>  should enable verbatim translation of existing plain language
>  policies, and that failure to incorporate that capability will
>  materially affect the speed with which this standard is adopted in
>  the marketplace. Although such a fully robust specification may not
>  be possible in Version 1.0, key omissions, such as the word "may"
>  noted above, should be corrected in the final version of the current
>  generation.  The current P3P language cannot handle the complex
>  requirements of the European Union Directive, Gramm-Leach-Bliley,
>  HIPPA, COPPA, or other specific laws and regulations. For example,
>  real world cookie statements at a corporate level often include the
>  word "may."  The actual usage is then made explicit for the
>  particular page or service where a cookie is used.

The P3P working groups have welcomed the participation of the
financial services industry throughout the P3P development process and
we hope representatives of the financial services industry will
continue to participate in the process. However, at this point in the
process the vocabulary for P3P1.0 is not likely to change. The issue
you raise about the word "may" was debated at length in December 1999
and January 2000. As a result of that debate, the P3P vocabulary was
adjusted so that every purpose element of the vocabulary includes the
word "may". For example the "telemarketing" purpose has the following
definition: "Information may be used to contact the individual via
voice telephone call for promotion of a product or service. This does
not include a direct reply to a question or comment or customer
service for a single transaction -- in those cases, <current/> would
be used." Thus, the word "may" is not omitted. We are aware that some
working group members would have preferred that sites could indicate
either that they may engage in a certain practice or that they
definitely will engage in that practice. However, the majority of the
working group members felt that allowing sites to make this
distinction serves no useful purpose and would just complicate the
vocabulary. We believe the current vocabulary will allow sites to make
disclosures consistent with all of the laws that you cited, although
some of the details of the disclosure may be represented in the
human-readable policy rather than the P3P policy. As long as the P3P
policy is consistent with the human-readable policy, it is permissible
for the human-readable policy to provide a more detailed explanation
than is possible in the P3P policy.

>  We recommend that a means be specified whereby the User Agent
>  (e.g. browser) can communicate back to the service when it is
>  actually blocking or downgrading a request (e.g., blocking or
>  downgrading a cookie).

Early drafts of the P3P specification did include this functionality
as part of the P3P protocol. This protocol allowed web sites to offer
a P3P policy as a "proposal" that users could accept or
reject. However, in order to support this protocol, web sites would
have to adopt new web server software. The feedback we received from
companies (including BITS members), was that a specification that
required web sites to adopt special software in order to use P3P was
not acceptable. They suggested that we focus on using P3P to provide
notice about web site policies rather than negotiating agreements.
Thus the P3P 1.0 specification only provides a mechanism for web sites
to inform users about their privacy policies. Indeed, the cookie
blocking or downgrading you refer to is not a part of the P3P
specification and is something that some user agents might do with or
without P3P.

>  The compact policy section is listed as optional. Considering that
>  the first implementation requires and only looks at compact
>  policies, and that this was based upon difficulties in implementing
>  the full specification within accepted performance constraints, it
>  is recommended that the compact policy should be changed from
>  "optional" to "required."  If this is not the desire of the W3C,
>  then User Agents should be required to follow the specified
>  practices now recommended.

It is the intention of the working group to keep the compact policy
optional. The compact format is very limiting, and does not allow the
level of granularity needed for many companies to explain their
privacy practices. In addition, the compact policy is designed
specifically to describe cookie policies, not general web site privacy
policies. Thus, the compact policy is not even appropriate in areas of
a site that don't use cookies, and some sites may have good reasons
not to use it with their cookies. Despite these limitations the
working group decided to make the compact policy available as an
option for those web sites that wanted to take advantage of more
efficient cookie processing that some user agents might be able to
offer to sites that provide compact policies. The P3P specification
already recommends that "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."

>  A service should be able to declare domains that are actually part
>  of the same organization and should be treated as first
>  parties. This should be possible by pointing to a file that lists
>  those domains that actually are part of the same organization and
>  should be treated as first party cookies, and/or listing those
>  domains in the compact policy (that is adding tokens to the compact
>  policy that indicates those URI's whose domains should all be
>  treated as first party cookies). While the HINT method may work for
>  site policies, no such tool is available at the compact policy
>  level.

The P3P specification does not make any distinctions between first and
third party cookies or make any recommendation that such cookies be
treated in different ways. Thus this issue is outside the scope of the
P3P1.0 specification. We suggest that you work with implementors that
are making these distinctions to develop an extension that will
address your concerns.

>  It should be made clear that "compact policies" should only address
>  cookie practices and these may or may not reflect the overall use of
>  information on the site.

Section 4 of the P3P1.0 specification states "In P3Pv1, compact
policies contain policy information related to cookies only."

>  It should also be made clear that P3P policies should only address
>  the information gathering and use practices on specific sites,
>  pages, and services and should not be interpreted as a company's
>  overall privacy policy.  

This is already explained in section 2 of the P3P1.0
specification. However, we will make that more clear
in section 1.1.3 "P3P Policies" as well.


You made a number of more detailed comments about the legal and
regulatory environment. These comments have been addressed by the P3P
Policy and Outreach Working Group. Responses to your other detailed
comments follow. We intend to provide clarifying language to the
specification where appropriate to address your concerns (see
http://www.w3.org/P3P/updates.html for the list of updates we made to
address the concerns you raised). Please realize, however, that it is
difficult for us to make substantive changes to the specification at
this time. Most of the areas of the specification where you suggest
substantive changes have been part of the document for well over a
year. We already revised those sections based on the comments
submitted during the previous Last Call periods.


> Extension of Language for Organizations and Services Now Impacted by
> P3P 
>
>  Many sites and services will be impacted by Browsers with Default P3P
>  preferences turned on.  This is true even for sites that do not work
>  with consumers or consumer data.  There are also many services that
>  may appear to have cookie-like behavior but which are used for other
>  purposes.
>
>  Therefore, site developers should have elements and tokens to identify
>  sites and services that should not be impacted by P3P or other
>  privacy policies. Ideally, these would:
>
>  * Have a brief policy with only one or two required statements; or
>  * Have a single "token" in the Compact Policy.
>  Worst case, these could be described in the same section (3.3.3) as
>  The NON-IDENTIFIABLE element. However, this would still require a
>  significant number of statements.  For the compact policies, these
>  may all share the same "NOI" token, even though these may cover
>  areas as diverse as:
>
>  * Purely corporate sites.
>  * Business to Business sites.
>  * Pictures or other materials (PDF files) hosted on a different server.
>  * Certificates
>  * Purely "counting" devices with only non-identifiable information.
>  * [This is not meant to be a complete list at this time.  The list
>  will need to be expanded as current implementation programs identify
>  additional situations.]

The P3P vocabulary can be used to explain what data is collected and
how it is used. If a site uses cookies, it can explain how they are
used. There is no assumption in P3P that cookies are used for any one
particular purpose. We don't think it is appropriate for the
specification to exclude certain types of content from P3P.

> Clarification of Terms and Intent
>
> There is need for additional clarity about how P3P is supposed to
> work, since the current requirement still contains much ambiguity and
> many items are suggested but not developed or resolved.
>
> It would be helpful to have one chart or section which could say:
> * Names of each element;
> * Whether this element is required (and whether this may be required
> if other optional elements are or are not used);
> * Default (and consequences) if this element is not included; [often
> buried] and
> * Whether or not it applies to cookies or just to sites.

Section 3 of the P3P1.0 specification already includes this. We are in
the process of developing a P3P Implementation Guide that will make
this information more accessible.

> In 1.3 Definitions:
> Change "Identified Data" to "Personally Identifiable Data (PI)" to
> better match other Internet privacy usage.

The term "identified data" was chosen after careful consideration. It
has a very specific definition. The term "Personally Identifiable
Data" is not well defined.

> The definition for Repository is limited to user information stored
> under the control of the user agent.  However, in 5.6.4. it is also
> used to define data stored under the control of the service provider.
> While the User Agent Repositories are an extremely important subject
> for both browsers and P3P, it is not adequately covered in this
> specification.  We recommend either tackling it in the next phase or
> leaving it out.

We are not sure how you get that understanding from the text
of section 5.6.4. This section is about naming the dynamic
data elements. P3P1.0 does not include any mechanisms for service
providers to store data as part of a P3P user agent.

> The concept of Safe Zone is similarly abstract and may be more
>  appropriate for the next phase. 

We believe it is an important concept and that it would be inappropriate
to remove it at this time.

> The terms "Site", "Service" and "Page" are not used carefully or
> consistently throughout the document.  For example, while most compact
> policies appear to handled at the "Service" level, all references are
> to the "Site."  This may be easier to incorporate consistently if
> there were a defined term for a "P3P Impacted Service."  This may be
> one that included one or more cookie behaviors.  Note that Service is
> currently defined as:  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.

The terms site, service, and page are generally used interchangeably
throughout the document. You should not try to find any special
meaning in this. We will make some wording changes so that these terms
are used more consistently.

>  While this specification recognizes the concept of Service Provider
>  (Data Controller, Legal Entity), with an appropriate definition,
>  this concept appears to have been lost in the actual
>  implementations, where there is little difference between a third
>  party web site under the control of the Service Provider and a third
>  party web site which is not under that control.  Future
>  specifications should work to implement technologies so that a third
>  party web site under the control of the Data Controller is treated
>  as such. There must be a better way, outside of hard coding each
>  element, to capture and use this.

We will keep this in mind when we begin work on version 2.

> Since Statement is a very important concept, the definition should be
> expanded to show the scope.  For example, this could read:  "A P3P
> statement is a set of privacy practice disclosures relevant to a site,
> page, or other Service, such as 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.  This talks to the collection of
> data elements on that service."

This is not an accurate definition of statement. The definition
in the specification is accurate.

> The definition of User should be expanded to indicate impact on how
> data should be classified.  : For example:  An individual (or group of
> individuals acting as a single entity) on whose behalf a service is
> accessed. P3P statements address the capture and use of personal data
> about this individual or group.

We will clarify this definition along the lines you suggest.

> The definition for User Agent should clearly point out that this is
> only software.  While pointing out how it SHOULD work, there also
> should be some cautions to indicate that it may not always work in
> that way.  For example, anyone sharing a machine with this User Agent
> installed, such as another family member, an employer, a public
> institution (library/school) may not be allowed to change the set
> preferences. .  

This goes into more detail than is necessary in the definitions section
of the specification.

> [There appears to be also an intent to say here that
> the service is not allowed to change the settings without notifying
> the user.   If this is the desire, this should be said outside of the
> definitions section.]...."

No this is not our intention.

> The last paragraph of 2.2 raises many ambiguities.  These are also
> raised, but not resolved, throughout the document.
>
> This now says:  "This document does not specify how P3P policies may
>  be associated with documents retrieved by means other than
>  HTTP. However, it does not preclude future development of mechanisms
>  for associating P3P policies with documents retrieved over other
>  protocols. Furthermore, additional methods of associating P3P
>  policies with documents retrieved using HTTP may be developed in the
>  future. " 
>
> While this may be true, it leaves the user hanging.  Will this be
> resolved by the time the standard is finalized?  Should User Agents
> bypass such documents?  For example, it is unlikely that a PDF file
> would either be setting cookies or have a P3P statement.  This at
> least would allow for certainty in implementation.  It is not
> desirable to allow each User Agent to define whatever rules they
> want, leading to sites that will function differently with different
> browser implementations.

You misunderstand the meaning of this paragraph. This paragraph is
referring to protocols, not document formats. The P3P specification
applies to all documents retrieved over HTTP, including PDF files.
Whether or not they have cookies associated with them is irrelevant
(and yes, PDF files can have cookies associated with them). The
purpose of this paragraph is to explain that in the future when people
develop new protocols, they can also specify techniques for applying
P3P to them. Also, if people wanted to, they could specify ways of
applying P3P to other existing protocols like the one used to transfer
Real Audio files, for example. Until the use of P3P is defined for
other protocols, user agents obviously can't look for P3P policies for
content fetched using other protocols. 

> Section 2.3.2.3.3 "Requesting Policies and Policy Reference Files"
> raises a problem where there may be HTTP 1.0 caches.  The proposed
> solution provides a very difficult scenario for developers, who would
> theoretically need to know if any user cache site were still using
> HTTP 1.0 and implementing around this.  This would be much simpler if
> the User Agent developer were told to refresh the policy if an HTTP
> 1.0 cache were encountered.

That is what this section says already.

> Paragraphs in Section 2.3.4 provide a significant amount of
> ambiguity by having loose requirements for User Agents which lead to
> the suggestion that services should implement many defensive
> measures which may or may not actually work.  Recommendation:  Leave
> things that are this complex to the next phase, giving service
> providers some latitude, especially with the limitations of current
> User Agents to handle complexity.  For example, the second paragraph
>  reads:
>
> If a User Agent is unable to find a matching include-rule for a
> given action URI in the policy reference file that was referenced
> from the page, it SHOULD assume that no policy is in effect. Under
> these circumstances, User Agents SHOULD check the well-known
> location on the host of the action URI to attempt to find a policy
> reference file that covers the action URI. If this does not provide
> a P3P policy to cover the action URI, then a user agent MAY try to
> retrieve the policy reference file by using the HINT mechanism on
> the action URI, and/or by issuing a HEAD request to the action URI
> before actually submitting any data in order to find the policy in
> effect. Services SHOULD ensure that server-side applications can
> properly respond to such HEAD requests and return the corresponding
> policy reference link in the headers. In case the underlying
> application does not understand the HEAD request and no policy has
> been pre-declared for the action URI in question, user agents MUST
> assume that no policy is in effect and SHOULD inform the user about
> this or take the corresponding actions according to the user's
> preferences.

The reason it sounds so complicated is that we do give service
providers a lot of latitude. We give them many options, so user
agents have to try several things to find the appropriate policy.

> For the same reason, the "SHOULD NOT" in the following paragraph
> should be changed to a "MUST NOT":
> Note that services might want to make use of the <METHOD> element in
> order to declare policies for server-side applications that only
> cover a subset of supported methods, e.g., POST or GET. Under such
> circumstances, it is acceptable that the application in question
> only supports the methods given in the policy reference file (i.e.,
> HEAD requests need not be supported). User agents SHOULD NOT attempt
> to issue a HEAD request to an action URI if the relevant methods
> specified in the form's method attribute have been properly
> pre-declared in the page's policy reference file.

There may be other reasons that a user agent wants to issue a HEAD
request. It is beyond the scope of the P3P specification to prohibit
HEAD requests.

> Section 2.5 provides several examples.  If a particular User Agent
> (such as IE 6.0) does not behave in this way and it affects the
> performance or requirements at a Service site, who has the
> responsibility of telling developers what to do to be in compliance?

W3C does not certify that implementations are in compliance with the
specification. It would certainly be appropriate for your organization
to discuss compliance issues with the implementors that you do not
believe to be in compliance with the specification.

> For example, Example 1 does not appear to require compact statements
> for cookies to be correctly handled.  Current language reads:
> Scenario 1: Web site basic.example.com uses a variety of images, all
> of which it hosts. It also includes some forms, which are all
> submitted directly to the site. This site can declare a single P3P
> policy for the entire site (or if different privacy policies apply
> to different parts of the site, it can declare multiple P3P
> policies). As long as all of the images and form action URIs are in
> directories covered by the site's P3P policy, User Agents will
> automatically recognize the images and forms as covered by the
> site's policy

Example one has nothing to do with cookies, and therefore does not
mention compact policies.

> Section 3.2.2. on the Policy element could be clearer about what the
> referenced page from opturi should or must contain, since the act of
> opting-in may be an integrated part of signing up for a service. For
> example, many opt-in programs simply tell the user (on each page
> that collects information) to only input information if they want
> information to be used.  There is no point in collecting information
> and then marking it so that it cannot be used.  Therefore, there may
> not be a single URI for this.  For example, a second sentence could
> be added so the description would read: URI of instructions that
> users can follow to request or decline to have their data used for a
> particular purpose (opt-in or opt-out). This attribute is mandatory
> for policies that contain a purpose with required attribute set to
> opt-in or opt-out. This can be a generic description of how opt-ins
> and opt-outs are handled and does not need to be a specific page
> from which all opt-ins or opt-outs for a company may be managed.

We will add language to section 3.2.2 to make this more clear.

> Section 3.2.3 could better explain the purpose of the TEST
> element. Current description simply says that it will cause a policy
> to be ignored.  Is there actually a way to test a site's performance
> using a policy with a TEST element?

Some P3P tools such as W3C's P3P validator will provide feedback
to web site implementors about their policies that contain the TEST
element. This is very useful for debugging purposes.

> Section 3.2.5 on the Access element appears to be very helpful in
> terms of data which are addressed.  However, there are internal
> inconsistencies: When used in a Compact Policy, this would imply
> that the compact policy would only need to get access to data
> carried on cookies.  For most companies, this would be "No Personal
> Information."  However, policy enforcement agencies, like the US
> Federal Trade Commission, may not come to the same reading going
> through this specification.  The second paragraph clearly says:
> "However, the scope of P3P statements are limited to data collected
> through HTTP or other Web transport protocols."  [This does not
> appear to be a consistent point of view throughout the
> specification.]  Also, if access is provided through the Web, use of
> strong authentication and security mechanisms for such access is
> recommended; however, security issues are outside the scope of this
> document.  [Are these intended for future documents?]

As explained in section 2.3.2.7, cookie policies also cover data
linked via cookies. So access may be relevant to that data.
Security issues are indeed outside the scope of this document. We have
no plans to address security issues at this time, but the issue is
certainly open for discussion in the context of version 2.

> Also in 3.2.5 and in many other sections "sites" is used instead of
> "service." (The discussion for <nonident/>):
> While the elements are the same for both "sites" and "services which
> use cookies," having a single description that applies to both types
> of uses introduces a great amount of confusion.  Either there should
> be a second section which discusses these elements when used in a
> cookie statement, or each of the descriptions should separately
> state how these work for sites and how they work for services that
> employ cookies. 

We did not intend to imply that there is any difference between a site
and a service. We will try to use the terms more consistently.

> Also in 3.2.5, the description under <contact-and-other/> should be
> made simpler and clearer.  Simply say that this would result in the
> same behavior as saying both <ident-contact> and <other-ident>.

We can clarify this.

> In the overview for Section 3.0, or specifically in 3.3 The
> NON-IDENTIFIABLE element, it should be made clear whether any of the
> other Statement elements are required if this option is selected.
> In fact, most do not make sense if no identifiable information is
> captured.  For example, it would seem as if a statement with
> NON-IDENTIFIABLE would not need PURPOSE, etc. This is never clearly
> stated.  This section also appears to be a logical place to identify
> other sites and services that should not be impacted by P3P
> policies, since these would go significantly beyond any law or even
> self-regulatory program.  See above.

We will change the spec to make it clear that some of the
elements are optional when the NON-IDENTIFIABLE element is present.

> In 3.3.6, the Retention element, many sections, such as
> <legal-requirement/> impose significant requirements on sites.  If
> these are important, they should be raised to the top.  For example,
> there is a statement that says: "Sites MUST have a retention policy
> that establishes a destruction time table....The retention policy
> MUST be included in or linked from the site's human-readable privacy
> policy."  This could give rise to both security risks and also
> litigation risks and goes significantly above laws or regulations
> for many site operators.  Therefore, this should be changed to
> SHOULD or MAY

Sites only have to make this disclosure if they want to make the
declaration <legal-requirement/>. There are other declarations they
can make if they don't want to make this sort of disclosure.

> In 3.3.7, the text under optional appears to be overkill for the
> initial implementation.  This is likely to lead to more errors and
> end-user confusion than it would be to help.  This now reads: Note
> that User Agents should be cautious about using the optional
> attribute in automated decision-making. If the optional attribute is
> associated with a data element directly controlled by the User Agent
> (such as the HTTP Referer header or cookies), the User Agent should
> make sure that this data is not transmitted to Web sites at which a
> data element is optional if the site's policy would not match a
> user's preferences if the data element was required. Likewise, for
> data elements that users typically type into forms, user agents
> should alert users when a site's practices about optional data do
> not match their preferences.

This is just a note to user agent developers. It is not intended for
end users and it does not place any requirements on anyone.

> Section 4. on Compact Policies appears to be the most incomplete,
> with many ideas raised and then not discussed.  For example, Section
> 4.0 says: In P3Pv1, compact policies contain policy information
> related to cookies only.  Is this true? 

yes

> 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.  However there is no explanation of how a web server should
> accomplish this, how the web server should build a P3P compact
> policy to represent the cookies referenced, and also how it should
> deliver this if it were not to do so in a P3P header

The whole section is about how to build a compact policy. The only way
to deliver a compact policy is in a P3P header.

> Section 4.0 also raises ambiguity by saying what a User Agent SHOULD
> do, but offering no certainty that it will do this, or what the
> defaults should be if the User Agent cannot or chooses not to do
> this.  Current language says: 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 order for a user agent to be fully compliant it has to do what all
the shoulds say. Otherwise, it is not fully compliant.

> Section 4.2.1 on use of Access in Compact Policies illustrates one
> of the fundamental problems with the document.  This would apply to
> both the cookie information in the full policies as well as the
> tokens in the compact polices.  Section 4.0 says that: "In P3Pv1,
> compact policies contain policy information related to cookies
> only." However, the options do not appear to relate to how cookies
> work. For example, many cookies can be accessed on the user machine.
> Other "cookie like objects" may simply capture NOI information for
> counts or for session performance.  If this is a session cookie that
> disappears, what should the setting be, since there would be no
> access after the session is over.  This is why the document should
> go through each item from both a cookie and a Compact Policy
> perspective.  The language and tokens available should also consider
> how cookies typically work.

We are not sure what you mean by "cookie like objects." Section 4.2 is
only concerned with policies for cookies. In some cases all of the
information in a cookie is stored in plain text on a user's
machine. In that case, the site might explain that in the access part
of their human-readable privacy policy. However, many cookies are
encoded and do not provide information in a format that is accessible
to users. In addition, many are linked to information in a company's
database that is not actually stored in the cookie.

> It is hard to image Disputes or Remedies having use in many
> cookies. There should be an easy way to bypass these, for example,
> for Session Cookies.

If the site does not have a DISPUTES element in their policy they can
simply omit the DSP token in their compact policy.

> The items in 4.2.7 on RETENTION are not very relevant to most
> cookies. These may be set to session, persistent, etc., especially
> if the user can remove these at any time.

See our response to your question about ACCESS.

> Again 4.5 and 4.6 should make it very clear that the developer is only
> translating the "cookie policy" in to a Compact Policy.  While a very
> seasoned programmer may pick this up, most non-technical users who may
> be questioning the accuracy of a Compact Policy would not.

Most non-technical users will not be reading this specification. It is
up to user agent implementors to display policy and/or compact policy
information in a format that will make sense to users. If you have
suggestions for how to do that, we encourage you to discuss them with
user agent implementors.

> The items in 5.3.1 talking to possibilities for defining different
> data structures and elements are meant to be helpful.  However, the
> current explanations are likely to be beyond the reach of all but a
> few.  Our recommendation is to simplify, and take away many of the
> risks for sites that are attempting to comply-at least for the first
> round. It appears that very simple solutions are possible for many
> sites, even those with a very large number of data elements.  It
> also appears that there are some very punitive risks for some who
> may use these solutions.

There is no obligation for sites to declare their own data
elements. Sites that don't have the expertise to do it right don't
have to do it at all. However, some sites have already found it useful
to have this functionality.

> Section 5.7.2 on Variable Category Data Elements/Structures, gets
> very complex.  Perhaps the penalties from making minor mistakes
> could be reduced for the initial implementation.  This is
> potentially a good tool, however, there needs to be some flexibility
> for making minor mistakes the first time.

This section is only of use to the small number of people who may
create their own data schemas.

> Additional Suggestions In 3.3.7, The DATA-GROUP and DATA elements,
> the text under optional should be rephrased so that the answers are
> intuitive.  Should read: "indicates whether or not the "session?"
> treats this data element as an "optional" field; "no" indicates that
> the data element is required, while "yes" indicates that the data
> element is not required. The default is "no". The optional attribute
> is used only in policies (not in data schema definitions).

We will change the wording of 3.3.7 to make this more clear.

> It may be helpful to review the standard structures against other
> database management and Customer Relationship Management (CRM) tools
> to ensure that these are consistent in terms of groupings and
> descriptions.  Otherwise companies are likely to have separate
> descriptors that are inconsistent.  For example, 5.5.5. Telephones is
> likely to need a designator for Home or Work.  Information in the
> "telecom" structure. This may be more likely to be compatible with the
> structure in other standard implementations.

We did review other structures. Unfortunately there is no single
standard format for these sorts of fields. However, we believe that it
is pretty easy to translate between most formats. We already provide
home or work indication through the user.home-info and
user.business-info data elements.


Once again, thank you for your comments. We have made a number of
changes to the specification as a result of your comments. We look
forward to continuing to work with your organization in the future.

Regards,

Lorrie Cranor
P3P Specification Working Group Chair

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lorrie Faith Cranor <lorrie@research.att.com>
AT&T Labs-Research, Shannon Laboratory 
180 Park Ave. Room A241, Florham Park, NJ 07932 
http://lorrie.cranor.org/    973-360-8607

Received on Tuesday, 18 December 2001 08:47:47 UTC