2.0 Website Technical Issues
The P3P specification is volumnous enough to give anyone problems. The intricacy of the specification defies you to get a firm understanding of how to implement the standard on a web site. The following are descriptions of issues contained in the standard that are little-known or are looked over enough times to warrant a closer look at what they mean.

A. The first issue invloves policy declarations. This topic is found under the heading 'Non-ambiguity'. The following summarizes the rules for sites:

1. User agents need to be able to determine unambiguously what policy applies to a given URI. Therefore, sites SHOULD avoid declaring more than one non-expired policy for a given URI.
2. In some rare case sites MAY declare more than one non-expired policy for a given URI, 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 (this is also the case for compact policies).
3. Sites MUST be cautious in their practices when they declare multiple policies for a given URI, and ensure that they can actually honor all policies simultaneously.
4. If a policy reference file at the well-known location declares a non-expired policy for a given URI, this policy applies, regardless of any conflicting policy reference files referenced through HTTP headers or HTML/XHTML link tags.
5. If an HTTP response header includes references to more than one policy reference file, P3P user agents MUST ignore all references after the first one.
6. If an HTML (resp. XHTML) file includes HTML (resp. XHTML) link tag references to more than one policy reference file, P3P user agents MUST ignore all references after the first one.
7. 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.

Probably the most common issue involving the non-ambiguity rules is number 4. Adding a header reference for the policy reference file location is not necessary if the reference file is in the well-known location.

B. There is quite a misunderstanding involving the use of the 'optional' attribute regarding data. Many website owners think you should mark an attribute as optional because the user has the option to either fill out a form and use the site or the user can just not fill out the form and not use the site. This is not the meaning of optional.

Optional 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.

So, the real question is can the user still complete the action even if they do not submit the piece of data. If they don't need to fill in the piece of data and can still meet the requirements for the submission without creating an error, then it is optional.

C. Forms are the most common method of getting user data. Because they link to server side scripts and applications, they are special. The primary reason for this is that the form has an action attribute that specifies where the data will go.

Data that is collected on one page that is posted to another (in some cases another website) is a case that warrants mention. The browser will always look for the policy for the page that the data is posted to (the action recipient). It follows that the data must be declared in the policy of the recipient and not necessarily the sender.