server_playground/doc/www.w3.org/TR/2006/NOTE-P3P11-20061113/index.html


								<?xml version="1.0" encoding="UTF-8"?>

								<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

								       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

								<html xmlns="http://www.w3.org/1999/xhtml">

								<head>

								  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

								  <title>The Platform for Privacy Preferences 1.1 (P3P1.1)

								  Specification</title>

								  <style type="text/css">

								    /*<![CDATA[*/

								    code {font-size: 105%;

								          font-family: monospace;

								          font-style: italic

								         }

								    pre {

								        font-family: monospace;

								        font-size: 85%;

								        white-space: pre;

								        background-color: rgb(204,204,234);

								        padding: 0.5em;

								        margin-left: 0;

								        border: none;

								        width: 97%;

								        }

								    pre.tree {line-height:1.0;}


								    pre.sample {

								        font-family: monospace;

								        font-size: 85%;

								        white-space: pre;

								        background-color: rgb(204,255,130);

								        padding: 0.5em;

								        margin-left: 1cm;

								        border: none;

								        width: 90%;

								        }


								    table.schema {

								        border-collapse: collapse;

								        empty-cells:show;

								        vertical-align:top;

								        width:100%;

								        border: groove 3px silver;

								        }

								    table.abnf {

								        background-color:rgb(204,204,234);

								        border: groove 3px;

								        font-family: monospace;

								        width:100%;

								        }

								    td.bds  {

								        vertical-align:top;

								        border: solid #87CEFA 2px;

								        background-color: #EAEAEA;

								        }

								    th {

								        font-size: large;

								        font-weight: bold;

								        background-color: #87CEFA;

								        }

								    td.abnf { background-color: rgb(204,204,234) }

								    tr.green {background-color: #ADD8E6}

								    tr.grey  {background-color: #B0C4DE}

								    .change { background-color: #4CE3E3  }

								    .remove {background-color: #B0C4DE ; text-decoration: line-through }

								    /*]]>


								    */</style>

								  <link rel="stylesheet" type="text/css"

								  href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE" />

								</head>


								<body>


								<div class="head">

								<a href="http://www.w3.org/"><img alt="W3C"

								src="http://www.w3.org/Icons/w3c_home" height="48" width="72" /></a>


								<h1 style="clear:both" id="title">The Platform for Privacy Preferences 1.1 (P3P1.1)

								Specification</h1>


								<h2 id="W3C-doctype">W3C Working Group Note 13 November 2006</h2>


								<dl>

								  <dt>This Version:</dt>

								    <dd><a href="http://www.w3.org/TR/2006/NOTE-P3P11-20061113/" shape="rect">

								    http://www.w3.org/TR/2006/NOTE-P3P11-20061113/</a></dd>

								  <dt>Latest Version:</dt>

								    <dd><a href="http://www.w3.org/TR/P3P11/" shape="rect">

								    http://www.w3.org/TR/P3P11/</a></dd>

								  <dt>Previous Version:</dt>

								    <dd><a href="http://www.w3.org/TR/2006/WD-P3P11-20060210/">

								    http://www.w3.org/TR/2006/WD-P3P11-20060210/</a></dd>

								</dl>


								<dl>

								  <dt>Editors:</dt>

								    <dd><a href="http://www.w3.org/People/all#rigo">Rigo Wenning</a>, <a

								      href="http://www.w3.org/">W3C</a> / <a

								      href="http://www.ercim.org/">ERCIM</a> (<a

								      href="mailto:rigo@w3.org">rigo@w3.org</a>)</dd>

								    <dd><a href="http://www.zurich.ibm.com/%7Emts/">Matthias Schunter</a>,

								      IBM </dd>

								  <dt>Authors:</dt>

								    <dd><a href="http://lorrie.cranor.org/">Lorrie Cranor</a>, CMU (P3P 1.0

								      &amp; P3P 1.1)</dd>

								    <dd>Brooks Dobbs, bdobbs at doubleclick.net, Doubleclick Inc. (P3P

								    1.1)</dd>

								    <dd>Serge Egelman, CMU (P3P 1.1), serge at guanotronic.com</dd>

								    <dd><a href="http://p3p.jrc.it/">Giles Hogben</a>, Joint Research Center

								      of the European Commission (P3P 1.1)</dd>

								    <dd>Jack Humphrey, JHumphrey at coremetrics.com, Coremetrics</dd>

								    <dd><a href="http://www.inf.ethz.ch/%7Elanghein/">Marc Langheinrich</a>,

								      ETH Zurich (P3P 1.0)</dd>

								    <dd><a href="http://www.w3.org/People/Massimo/">Massimo Marchiori</a>,

								      W3C / MIT / University of Venice (P3P 1.0)</dd>

								    <dd><a href="mailto:mpresler@us.ibm.com">Martin Presler-Marshall</a>, IBM

								      (P3P 1.0)</dd>

								    <dd><a href="http://www.w3.org/People/Reagle/Overview.html">Joseph

								      Reagle</a>, W3C/MIT(P3P 1.0)</dd>

								    <dd><a href="http://www.zurich.ibm.com/%7Emts/">Matthias Schunter</a>,

								      IBM (P3P 1.1)</dd>

								    <dd>David A. Stampley, David_Stampley at reyrey.com, Invited Expert</dd>

								    <dd>Rigo Wenning, W3C</dd>

								</dl>


								<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> &copy; 2006 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>&reg;</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>


								<hr title="Separator for header" />

								</div>


								<div  id="abstract">

								<h2>Abstract</h2>


								<p>This is the specification of the Platform for Privacy Preferences 1.1 (P3P

								1.1). This document, along with its normative references, includes all the

								specification necessary for the implementation of interoperable P3P 1.1

								applications. P3P 1.1 is based on <a href="http://www.w3.org/TR/P3P/">the P3P

								1.0 Recommendation</a> and adds some features using the <a

								href="http://www.w3.org/TR/P3P/#extension">P3P 1.0 Extension mechanism</a>.

								It also contains a new binding mechanism that can be used to bind policies

								for XML Applications beyond HTTP transactions.</p>

								</div>


								<div id="status">

								<h2>Status of This Document</h2>


								<p><em>This section describes the status of this document at the time of its

								publication. Other documents may supersede this document. A list of current W3C

								publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at

								http://www.w3.org/TR/.</em></p>


								<p>Publication as a Working Group Note does not imply endorsement by the W3C

								Membership. This is a draft document and may be updated, replaced or obsoleted by

								other documents at any time. It is inappropriate to cite this document as other than

								work in progress.</p>


								<p>This document is a Working Group Note describing the proposed P3P

								Version 1.1 (P3P11). The P3P Specification Working Group is lacking the

								necessary support from implementers to carry on through the Recommendation

								Process. Therefor the Working Group decided to publish the current P3P

								1.1 Specification as a Working Group Note after a successful Last Call.

								In this Note, all Last Call comments are taken into account.

								The Working Group thinks that the Specification is usable and implementable.

								If there is sufficient support from implementers and the community at large,

								this work can be taken up and brought to Recommendation. The P3P community

								continues to discuss privacy issues and P3P implementation issues in the

								<a href="mailto:www-p3p-policy@w3.org">www-p3p-policy@w3.org</a> mailing

								list that is <a href="http://lists.w3.org/Archives/Public/www-p3p-policy/">

								publicly archived</a>. Comments should be directed to this list.</p>


								<p>The P3P 1.1 Specification was developed from

								suggestions out of a <a href="http://www.w3.org/2002/p3p-ws/">Workshop in

								Dulles/Virginia</a> and a <a href="http://www.w3.org/2003/p3p-ws/">Workshop

								in Kiel/Germany</a>. The community at large gave feedback on limitations and

								shortcomings of <a href="http://www.w3.org/TR/P3P/">P3P 1.0</a>. As far as

								those suggestions have found sufficient support, they are now included in

								this P3P 1.1 Working Group Note. All new features are built using P3P's own <a

								href="http://www.w3.org/TR/P3P/#extension">Extension mechanism</a>. Those

								extensions are contained in a new XML Schema in <a

								href="#p3p11_schema">Appendix 5</a> and carry their own new namespace. All

								P3P 1.0 preserve their old namespace. Additionally, this Working Group Note

								contains all the errata to P3P 1.0. </p>


								<p>This document has been produced by the <a href="http://www.w3.org/P3P/1.1/">

								P3P Specification Working Group</a> as part

								of the <a href="http://www.w3.org/Privacy/Activity.html">Privacy Activity</a>

								in the W3C <a href="http://www.w3.org/TandS/">Technology &amp; Society

								Domain</a>.</p>


								<p> This document is governed by the <a href="http://www.w3.org/TR/2002/NOTE-patent-practice-20020124">24 January 2002 CPP</a> as amended by the <a href="http://www.w3.org/2004/02/05-pp-transition">W3C Patent Policy Transition Procedure</a>. W3C maintains a <a rel="disclosure" href="@@URI to IPP status or other page@@">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>. </p>


								</div>


								<hr />


								<div id="toc">

								<h2>Table of Contents</h2>

								<ol>

								  <li><a href="#Introduction">Introduction</a>

								    <ol>

								      <li><a href="#P3P1.1">The P3P1.1 Specification</a>

								        <ol>

								          <li><a href="#goals_and_capabs">Goals and Capabilities of

								          P3P1.1</a></li>

								          <li><a href="#intro_example">Example of P3P in Use</a></li>

								          <li><a href="#P3PPolicies">P3P Policies</a></li>

								          <li><a href="#UserAgents">P3P User Agents</a></li>

								          <li><a href="#Implementing">Implementing P3P1.1 on Servers</a></li>

								          <li><a href="#Future">Future Versions of P3P</a></li>

								     <li><a href="#backwards">Backwards Compatibility</a></li>

								        </ol>

								      </li>

								      <li><a href="#About">About this Specification</a>

								<ol>

								<li><a href="#Conformance">Conformance Clause for P3P 1.1</a></li>

								</ol>

								</li>


								      <li><a href="#def_identity">Identity Definitions in the P3P

								        Specification</a>

								        <ol>

								          <li><a href="#identified_data"><q>Identified</q>Data</a></li>

								          <li><a href="#linked_data"><q>Non-Identifiable</q> Data</a></li>

								          <li><a href="#identifiers">Identifiers</a></li>

								          <li><a href="#linked">Linked and Linkable Data</a></li>

								        </ol>

								      </li>

								      <li><a href="#Terminology">Terminology</a></li>

								    </ol>

								  </li>

								  <li><a href="#Referencing">Referencing Policies</a>

								    <ol>

								      <li><a href="#overview_of_prfs">Overview and Purpose of Policy

								        References</a></li>

								      <li><a href="#ref_syntax">Locating Policy Reference Files</a>

								        <ol>

								          <li><a href="#Well_Known_Location">Well-Known Location</a></li>

								          <li><a href="#syntax_ext">HTTP Headers</a></li>

								          <li><a href="#syntax_link">The HTML <code>link</code> Tag</a></li>

								          <li><a href="#XHTML-link">The XHTML <code>link</code> Tag</a></li>

								          <li><a href="#other_protocols">HTTP ports and other

								          protocols</a></li>

								        </ol>

								      </li>

								      <li><a href="#ref_file">Policy Reference File Syntax and Semantics</a>

								        <ol>

								          <li><a href="#ref_file_example">Example Policy Reference

								          File</a></li>

								          <li><a href="#ref_file_syntax">Policy Reference File Definition</a>

								            <ol>

								              <li><a href="#ref_file_processing">Policy reference file

								                processing</a>

								                <ol>

								                  <li><a href="#ref_file_ordering">Significance of

								                  order</a></li>

								                  <li><a href="#ref_file_wildcards">Wildcards in policy

								                    reference files</a></li>

								                </ol>

								              </li>

								              <li><a href="#ref_file_refs">The <code>META</code> and

								                <code>POLICY-REFERENCES</code> elements</a></li>

								              <li><a href="#ref_file_lifetime">Policy reference file

								                lifetimes and the <code>EXPIRY element</code></a>

								                <ol>

								                  <li><a href="#motivation_and_mechanism">Motivation and

								                    mechanism</a></li>

								                  <li><a href="#the_expiry_element">The <code>EXPIRY</code>

								                    element</a></li>

								                  <li><a href="#use_of_http_headers">Use of HTTP

								                  headers</a></li>

								                  <li><a href="#error_handling">Error handling for policy

								                    reference file lifetimes</a></li>

								                </ol>

								              </li>

								              <li><a href="#ref_file_policyref">The <code>POLICY-REF</code>

								                element</a></li>

								              <li><a href="#ref_file_preexc">The <code>INCLUDE</code> and

								                <code>EXCLUDE</code> elements</a></li>

								              <li><a href="#hints">The <code>HINT</code> element</a></li>

								              <li><a href="#cookies">The <code>COOKIE-INCLUDE</code> and

								                <code>COOKIE-EXCLUDE</code> elements</a></li>

								              <li><a href="#ref_file_method">The <code>METHOD</code>

								                element</a></li>

								              <li><a href="#oho">Domain Relationships</a>

								                <ol>

								                  <li><a href="#oho_ex"><code>OUR-HOST</code>

								                  Extension</a></li>

								                  <li><a href="#playback">Cookie Playback</a></li>

								                  <li><a href="#oho_cp">Extension to P3P Compact Policy

								                    Header</a></li>

								                </ol>

								              </li>

								            </ol>

								          </li>

								          <li><a href="#active_content">Applying a Policy to a URI</a></li>

								          <li><a href="#forms">Forms and Related Mechanisms</a></li>

								        </ol>

								      </li>

								      <li><a href="#additional_requirements">Additional Requirements</a>

								        <ol>

								          <li><a href="#non-ambiguity">Non-ambiguity</a></li>

								          <li><a href="#multiple">Multiple Languages</a></li>

								          <li><a href="#safezone">The Safe Zone</a></li>

								          <li><a href="#processing">Policy and Policy Reference File

								            Processing by User Agents</a></li>

								          <li><a href="#security">Security of Policy Transport</a></li>

								          <li><a href="#policy_updates">Policy Updates</a></li>

								          <li><a href="#absence_of_prf">Absence of Policy Reference

								          File</a></li>

								          <li><a href="#asynchronous_evaluation">Asynchronous

								          Evaluation</a></li>

								        </ol>

								      </li>

								      <li><a href="#generic_attribute">The P3P Generic Attribute for XML

								        Applications</a></li>

								      <li><a href="#example_scenarios">Example Scenarios</a></li>

								    </ol>

								  </li>

								  <li><a href="#P3P_markup">Policy Syntax and Semantics</a>

								    <ol>

								      <li><a href="#Example_policy">Example policies</a>

								        <ol>

								          <li><a href="#English">English language policies</a></li>

								          <li><a href="#encoding">XML encoding of policies</a></li>

								        </ol>

								      </li>

								      <li><a href="#Policies">Policies</a>

								        <ol>

								          <li><a href="#POLICIES">The <code>POLICIES</code> element</a></li>

								          <li><a href="#POLICY">The <code>POLICY</code> element</a></li>

								          <li><a href="#StatementGroupDef">The <code>STATEMENT-

								            GROUP-DEF</code> (EXTENSION)</a></li>

								          <li><a href="#test">The <code>TEST</code> element</a></li>

								          <li><a href="#ENTITY">The <code>ENTITY</code> element</a></li>

								          <li><a href="#ACCESS">The <code>ACCESS</code> element</a></li>

								          <li><a href="#DISPUTES">The <code>DISPUTES</code> element</a></li>

								          <li><a href="#REMEDIES">The <code>REMEDIES</code> element</a></li>

								        </ol>

								      </li>

								      <li><a href="#Statements">Statements</a>

								        <ol>

								          <li><a href="#STATEMENT">The <code>STATEMENT</code> element</a></li>

								          <li><a href="#statement_group">The <code>STATEMENT-GROUP</code>

								            element (EXTENSION)</a></li>

								          <li><a href="#CONSEQUENCE">The <code>CONSEQUENCE</code>

								          element</a></li>

								          <li><a href="#NON-IDENTIFIABLE">The <code>NON-IDENTIFIABLE</code>

								            element</a></li>

								          <li><a href="#PURPOSE">The <code>PURPOSE</code> element</a>

								            <ol>

								              <li><a href="#ppurpose">Primary Purposes</a></li>

								            </ol>

								          </li>

								          <li><a href="#RECPNT">The <code>RECIPIENT</code> element</a></li>

								          <li><ol>

								              <li><a href="#jurisdiction">The JURISDICTION element

								                (EXTENSION)</a></li>

								            </ol>

								          </li>

								          <li><a href="#RETENTION">The <code>RETENTION</code> element</a></li>

								          <li><a href="#DATA">The <code>DATA-GROUP</code> and

								            <code>DATA</code> elements</a></li>

								        </ol>

								      </li>

								      <li><a href="#Categories">Categories and the <code>CATEGORIES</code>

								        element</a></li>

								      <li><a href="#extension">Extension Mechanism: the

								        <code>EXTENSION</code> element</a></li>

								      <li><a href="#PREFERENCES">User Preferences</a></li>

								    </ol>

								  </li>

								  <li><a href="#compact_policies">Compact Policies</a>

								    <ol>

								      <li><a href="#referencing_compact_policies">Referencing Compact

								        Policies</a></li>

								      <li><a href="#compact_policy_vocabulary">Compact Policies Vocabulary</a>

								        <ol>

								          <li><a href="#compact_access">Compact <code>ACCESS</code></a></li>

								          <li><a href="#compact_disputes">Compact

								          <code>DISPUTES</code></a></li>

								          <li><a href="#compact_remedies">Compact

								          <code>REMEDIES</code></a></li>

								          <li><a href="#compact_non_identifiable">Compact

								            <code>NON-IDENTIFIABLE</code></a></li>

								          <li><a href="#compact_purposes">Compact

								          <code>PURPOSE</code></a></li>

								          <li><a href="#compact_recipients">Compact

								          <code>RECIPIENT</code></a></li>

								          <li><a href="#compact_retention">Compact

								          <code>RETENTION</code></a></li>

								          <li><a href="#compact_categories">Compact

								            <code>CATEGORIES</code></a></li>

								          <li><a href="#compact_test">Compact <code>TEST</code></a></li>

								          <li><a href="#compact_statement">Compact

								          <code>STATEMENT</code></a></li>

								        </ol>

								      </li>

								      <li><a href="#compact_policy_scope">Compact Policy Scope</a></li>

								      <li><a href="#compact_policy_lifetime">Compact Policy Lifetime</a></li>

								      <li><a href="#full_into_compact">Transforming a P3P Policy to a Compact

								        Policy</a></li>

								    </ol>

								  </li>

								  <li><a href="#Data_Schemas">Data Schemas</a>

								    <ol>

								      <li><a href="#Data_Schemas_intro">Introduction</a>

								        <ol>

								          <li><a href="#Data_Schemas_overview">P3P 1.1 Data Element Syntax

								            Overview</a></li>

								        </ol>

								      </li>

								      <li><a href="#Data_Schemas_types">How to express data types in P3P

								        Policies</a>

								        <ol>

								          <li><a href="#Data_Schemas_basics">Basics</a></li>

								          <li><a href="#Data_Schemas_categories">Categories in P3P Data

								            Schemas</a></li>

								          <li><a href="#Data_Schemas_extern">Referencing External

								          Schemas</a></li>

								          <li><a href="#Data_Schemas_natural">Natural Language description of

								            data elements</a></li>

								        </ol>

								      </li>

								      <li><a href="#Data_Schemas_new">Defining new Schemas</a>

								        <ol>

								          <li><a href="#Data_Schemas_semantics">Semantics of data schemas</a></li>

								        </ol>

								      </li>

								      <li><a href="#Data_Schemas_persistence">Persistence of data

								      schemas</a></li>

								      <li><a href="#base_data_structure">Structure of the Base Data Schema</a>

								        <ol>

								          <li><a href="#base_data_overview">Visual overview of the base data

								            schema hierarchy</a>

								            <ol>

								              <li><a href="#dynamic_data">Dynamic Data</a></li>

								              <li><a href="#user_data">User Data</a></li>

								              <li><a href="#third_party_data">Third Party Data</a></li>

								              <li><a href="#business_data">Business Data</a></li>

								            </ol>

								          </li>

								          <li><a href="#schema_detail">Data Schema Element Details</a></li>

								        </ol>

								      </li>

								      <li><a href="#using_elements">Using Data Elements</a></li>

								      <li><a href="#Data_Schemas_back">Backward Compatibility Requirements</a></li>

								      <li><a href="#data_semantics">Semantics of P3P Data Schemas</a></li>

								    </ol>

								  </li>

								  <li><a href="#ua">User Agent Guidelines</a>

								    <ol>

								      <li><a href="#complete_trans">Completeness of Human-Readable

								        Translations</a></li>

								      <li><a href="#plain_trans">Plain Language Translations of P3P

								        Vocabulary Elements</a></li>

								      <li><a href="#ua_storage">Storage of P3P Policies and

								      Translations</a></li>

								      <li><a href="#ua_compact">Compact Policy Processing</a></li>

								      <li><a href="#ua_sanity">Sanity Checking P3P Policies</a></li>

								      <li><a href="#ua_notice">Timing of Notices to Users</a></li>

								    </ol>

								  </li>

								  <li><a href="#Appendices">Appendices</a>

								    <ol>

								      <li><a href="#References_normative">Appendix 1: References (Normative)</a></li>

								      <li><a href="#References_nonnormative">Appendix 2: References (Non-normative)</a></li>

								      <li><a href="#basedataxml">Appendix 3: The P3P 1.1 Base Data Schema Definition (Normative)</a></li>

								      <li><a href="#Appendix_xslt">Appendix 4: XSLT Transforms for Policies and Schema files from P3P 1.0 to P3P 1.1</a>

								        <ol>

								          <li><a href="#policy_xslt">P3P 1.1 Data Element backward compatibility transform</a></li>

								          <li><a href="#duplicates_xslt">P3P 1.1 transform to remove duplicates

								              from previous transforms</a></li>

								        </ol>

								      </li>

								      <li><a href="#p3p11_schema">Appendix 5: The XML Schema for P3P 1.1 Extensions and the P3P generic attribute</a></li>

								      <li><a href="#Appendix_Notation">Appendix 6: ABNF Notation (Normative)</a></li>

								      <li><a href="#guiding_principles">Appendix 7: P3P Guiding Principles (Non-normative)</a></li>

								      <li><a href="#Appendix_Working">Appendix 8: Working Group Contributors (Non-normative)</a></li>

								      <li><a href="#changelog">Change Log</a></li>

								    </ol>

								  </li>

								</ol>

								</div>

								<hr />


								<div id="Introduction">

								<h1>1. Introduction</h1>


								<p>The Platform for Privacy Preferences Project (P3P) enables Web sites to

								express their privacy practices in a standard format that can be retrieved

								automatically and interpreted easily by user agents. P3P user agents will

								allow users to be informed of site practices (in both machine- and

								human-readable formats) and to automate decision-making based on these

								practices when appropriate. Thus users need not read the privacy policies at

								every site they visit.</p>


								<p>Although P3P provides a technical mechanism for ensuring that users can be

								informed about privacy policies before they release personal information, it

								does not provide a technical mechanism for making sure sites act according to

								their policies. Products implementing this specification MAY provide some

								assistance in that regard, but that is up to specific implementations and

								outside the scope of this specification. However, P3P is complementary to

								laws and self-regulatory programs that can provide enforcement mechanisms. In

								addition, P3P does not include mechanisms for transferring data or for

								securing personal data in transit or storage. P3P may be built into tools

								designed to facilitate data transfer. These tools should include appropriate

								security safeguards.</p>


								<h2 id="P3P1.1">1.1 The P3P 1.1 Specification</h2>


								<p>The P3P1.1 specification defines the syntax and semantics of P3P privacy

								policies, and the mechanisms for associating policies with Web resources. P3P

								policies consist of statements made using the P3P <em>vocabulary</em> for

								expressing privacy practices. P3P policies also reference elements of the P3P

								<em><a href="#base_data_structure">base data schema</a></em> -- a standard set

								of data elements that all P3P user agents should be aware of. The P3P

								specification includes a mechanism for defining new data elements and data

								sets, and a simple mechanism that allows for extensions to the P3P

								vocabulary.</p>


								<h3 id="goals_and_capabs">1.1.1 Goals and Capabilities of P3P 1.1</h3>


								  <p><a

								  href="http://www.w3.org/TR/2002/REC-P3P-20020416/">P3P version

								  1.0</a> is a protocol designed to inform Web users about the

								  data-collection practices of Web sites. It provides a way for a Web

								  site to encode its data-collection and data-use practices in a

								  machine-readable XML format known as a <em>P3P policy</em>. The P3P

								  specification defines:</p> <ul>

								 <li>A standard schema for data a Web site may wish to collect,

								 known as the  "P3P base data schema" (<a

								 href="#base_data_structure">5.5</a>)</li>


								 <li>A standard set of uses, recipients, data categories, and

								 other privacy  disclosures</li>


								 <li>An XML format for expressing a privacy policy</li>

								 <li>A means of associating privacy policies with Web pages or

								 sites, and  cookies</li>


								 <li>A mechanism for transporting P3P policies over HTTP</li>

								</ul>

								  <p>The goal of P3P is twofold.  First, it allows Web sites to

								  present their data-collection practices in a standardized,

								  machine-readable, easy-to-locate manner. Second, it enables Web

								  users to understand what data will be collected by sites they

								  visit, how that data will be used, and what data/uses they may

								  "opt-out" of or "opt-in" to.</p>


								  <p>A number of changes were made in P3P version 1.1. These are

								  enumerated in the change log at the end of this document. The most

								  significant changes are summarized here:</p>

								  <ul>

								    <li>All the <a href="http://www.w3.org/2002/04/P3Pv1-errata">

								    errata from P3P 1.0</a> have been incorporated into this

								    specification.</li>


								     <li>In <a href="#def_identity">Section 1.3</a>, definitions are

								     now provided for <i>identified, identifiable, linked,</i> and

								     <i>linkable</i> data</li>


								     <li>In <a href="#oho">Section 2.3.2.9</a> an optional

								     <code>OUR-HOST</code> element has been added for declaring domain

								     relationships, allowing user agents to recognize when hosts in

								     different domains are owned by the same entity or entities acting

								     as agents for one another.</li>


								     <li>In <a href="#generic_attribute">Section 2.5</a> a new P3P

								     generic attribute for XML applications has been added. This is a

								     new mechanism for binding P3P policies to XML elements that

								     describe interfaces, for example, in <a

								     href="http://www.w3.org/TR/xforms/">XForms</a>

								    or <a href="http://www.w3.org/TR/wsdl20/">WSDL</a>.</li>


								    <li>In <a href="#StatementGroupDef">Section 3.2.3</a> and <a href

								    = "#statement_group">Section 3.3.2</a> a mechanism has been added

								    for naming P3P <code>STATEMENT</code> elements and grouping

								    <code>STATEMENT</code> elements together. This allows user agents

								    to better organize the summary display of P3P policies and obtain

								    opt-in or opt-out choices to a group of statements. </li>


								    <li>In <a href ="#DISPUTES">Section 3.2.7</a> and <a href =

								    "#REMEDIES">Section 3.2.8</a> new definitions are provided for the

								    <code>DISPUTES</code> and <code>REMEDIES</code> elements and their

								    sub-elements.</li>


								    <li>In <a href="#RECPNT">Section 3.36</a> a new definition is

								    provided for the <code>RECIPIENT</code> element.</li>


								    <li>In <a href="#Categories">Section 3.4</a> a new definition is

								  provided for the <code>demographic</code> element.</li>


								    <li>In <a href="#ppurpose">Section 3.3.5.1</a> an optional

								    <code>ppurpose</code> element has been added added to allow user

								    agents to determine the primary reason why the data recipient is

								    collecting data.</li>


								    <li>In <a href="#jurisdiction">Section 3.3.6.1</a> an optional

								    <code>JURISDICTION</code> element has been added for declaring the

								    jurisdiction of data recipients.</li>


								    <li>In <a href="#compact_policies">Section 4</a> language was

								    added to explain the use of compact policies as a

								    performance optimization, and to emphasize their optional nature

								    and non-authoritative status.</li>


								    <li>In <a href="#compact_statement">Section 4.2.10</a> new

								    syntax has been added to provide a compact version of the

								    <code>STATEMENT</code> element for use in compact policies. This

								    allows for the creation of compact policies that make more

								    granular statements about data practices than is possible with

								    the P3P 1.0 syntax.</li>


								    <li>In <a href="#Data_Schemas">Section 5</a>, the format for

								    specifying P3P data schemas has been changed substantially so that

								    it is now simpler and more standardized than the format used in

								    P3P 1.0. The new format uses the XML Schema Definition Standard

								    (XSD) format, which can be validated against an XML schema. In <a

								    href = "#basedataxml">Appendix 3</a> the P3P base data schema

								    definition has been updated to reflect this change. </li>


								    <li>In <a href="#ua">Section 6</a> new user agent guidelines have

								    been added to assist user agent implementers. These guidelines

								    include a set of plain language translations of P3P vocabulary

								    elements. </li>


								     <li>The XML DTD definition for P3P has been removed from

								     the Specification.</li>


								  </ul>


								<h3 id="intro_example">1.1.2 Example of P3P in Use</h3>


								<p>As an introduction to P3P, let us consider one common scenario that makes

								use of P3P. Claudia has decided to check out a store called CatalogExample,

								located at http://www.catalog.example.com/. Let us assume that CatalogExample

								has placed P3P policies on all their pages, and that Claudia is using a Web

								browser with P3P built in.</p>


								<p>Claudia types the address for CatalogExample into her Web browser. Her

								browser is able to automatically fetch the P3P policy for that page. The

								policy states that the only data the site collects on its home page is the

								data found in standard HTTP access logs. Now Claudia's Web browser checks

								this policy against the preferences Claudia has given it. Is this policy

								acceptable to her, or should she be notified? Let's assume that Claudia has

								told her browser that this is acceptable. In this case, the homepage is

								displayed normally, with no pop-up messages appearing. Perhaps her browser

								displays a small icon somewhere along the edge of its window to tell her that

								a privacy policy was given by the site, and that it matched her

								preferences.</p>


								<p>Next, Claudia clicks on a link to the site's online catalog. The catalog

								section of the site has some more complex software behind it. This software

								uses cookies to implement a "shopping cart" feature. Since more information

								is being gathered in this section of the Web site, the Web server provides a

								separate P3P policy to cover this section of the site. Again, let's assume

								that this policy matches Claudia's preferences, so she gets no pop-up

								messages. Claudia continues and selects a few items she wishes to purchase.

								Then she proceeds to the checkout page.</p>


								<p>The checkout page of CatalogExample requires some additional information:

								Claudia's name, address, credit card number, and telephone number. Another

								P3P policy is available that describes the data that is collected here and

								states that her data will be used only for completing the current

								transaction, her order.</p>


								<p>Claudia's browser examines this P3P policy. Imagine that Claudia has told

								her browser that she wants to be warned whenever a site asks for her

								telephone number. In this case, the browser will pop up a message saying that

								this Web site is asking for her telephone number, and explaining the contents

								of the P3P statement. Claudia can then decide if this is acceptable to her.

								If it is acceptable, she can continue with her order; otherwise she can

								cancel the transaction.</p>


								<p>Alternatively, Claudia could have told her browser that she wanted to be

								warned only if a site is asking for her telephone number and was going to

								give it to third parties and/or use it for uses other than completing the

								current transaction. In that case, she would have received no prompts from

								her browser at all, and she could proceed with completing her order.</p>


								<p>Note that this scenario describes one hypothetical implementation of P3P.

								Other types of user interfaces are also possible.</p>


								<h3 id="P3PPolicies">1.1.3 P3P Policies</h3>


								<p>P3P policies use XML with namespaces (cf. [<a href="#XML">XML</a>] and

								[<a href="#XML-Name">XML-Name</a>]) encoding of the P3P vocabulary to provide

								contact information for the legal entity making the representation of privacy

								practices in a policy, enumerate the types of data or data elements

								collected, and explain how the data will be used. In addition, policies

								identify the data recipients, and make a variety of other disclosures

								including information about dispute resolution, and the address of a site's

								human-readable privacy policy. P3P policies must cover all relevant data

								elements and practices. However, legal issues regarding law enforcement

								demands for information are not addressed by this specification. It is

								possible that a site that otherwise abides by its policy of not

								redistributing data to others may be required to do so by force of law. P3P

								declarations are positive, meaning that sites state what they do, rather than

								what they do not do. The P3P vocabulary is designed to be descriptive of a

								site's practices rather than simply an indicator of compliance with a

								particular law or code of conduct. However, user agents may be developed that

								can test whether a site's practices are compliant with a law or code.</p>


								<p>P3P policies represent the practices of the site. Intermediaries such as

								telecommunication providers, Internet service providers, proxies and others

								may be privy to the exchange of data between a site and a user, but their

								practices may not be governed by the site's 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.</p>


								<p>In cases where the P3P vocabulary is not precise enough to describe a Web

								site's practices, sites should use the vocabulary terms that most closely

								match their practices and provide further explanations (as stated in <a

								href="#Policies">Section 3.2</a>). However, policies MUST NOT make false or

								misleading statements.</p>


								<h3 id="UserAgents">1.1.4 P3P User Agents</h3>


								<p>P3P 1.1 user agents can be built into Web browsers, browser plug-ins, or

								proxy servers. They can also be implemented as Java applets or JavaScript; or

								built into electronic wallets, automatic form-fillers, or other user data

								management tools. P3P user agents look for references to a P3P policy at a

								well-known location, in P3P headers in HTTP responses, and in P3P

								<code>link</code> tags embedded in HTML content. These references indicate

								the location of a relevant P3P policy. User agents can fetch the policy from

								the indicated location, parse it, and display symbols, play sounds, or

								generate user prompts that reflect a site's P3P privacy practices. They can

								also compare P3P policies with privacy preferences set by the user and take

								appropriate actions. P3P can perform a sort of "gate keeper" function for

								data transfer mechanisms such as electronic wallets and automatic form

								fillers. A P3P user agent integrated into one of these mechanisms would

								retrieve P3P policies, compare them with user's preferences, and authorize

								the release of data only if a) the policy is consistent with the user's

								preferences and b) the requested data transfer is consistent with the policy.

								If one of these conditions is not met, the user might be informed of the

								discrepancy and given an opportunity to authorize the data release

								themselves.</p>


								<p>The P3P 1.1 Specification gives implementers a lot of flexibility to

								determine the design and functionality of P3P user agents. However, the

								specification does include some requirements and guidelines for user agent

								implementers. Most of these can be found in <a href="#ua">section 6</a> and

								<a href="#guiding_principles">Appendix 7</a>.</p>


								<h3 id="Implementing">1.1.5 Implementing P3P 1.1 on Servers</h3>


								<p>Web sites can implement P3P 1.1 on their servers by translating their

								human-readable privacy policies into P3P syntax and then publishing the

								resulting files along with a policy reference file that indicates the parts

								of the site to which the policy applies. Automated tools can assist site

								operators in performing this translation. P3P 1.1 can be implemented on

								existing HTTP/1.1-compliant Web servers without requiring additional or

								upgraded software. Servers may publish their policy reference files at a <a

								href="#Well_Known_Location">well-known location</a>, or they may reference

								their P3P policy reference files in HTML/XHTML content using a

								<code>link</code> tag. Alternatively, compatible servers may be configured to

								insert a P3P extension header into all HTTP responses that indicates the

								location of a site's P3P policy reference file.</p>


								<p>Web sites have some flexibility in how they use P3P: they can opt for one

								P3P policy for their entire site or they can designate different policies for

								different parts of their sites. A P3P policy MUST cover all data generated or

								exchanged as part of a site's HTTP interactions with visitors. In addition,

								some sites may wish to write policies that cover all data an entity collects,

								regardless of how the data is collected.</p>


								<h3 id="Future">1.1.6 Future Versions of P3P</h3>


								<p>Significant sections were removed from earlier drafts of the P3P 1.0

								specification in order to facilitate rapid implementation and deployment of a

								P3P first step. A future version of the P3P specification might incorporate

								those features after P3P 1.0 is deployed. Such specification would likely

								include improvements based on feedback from implementation and deployment

								experience as well as four major components that were part of the original

								P3P vision but not included in P3P 1.0 or 1.1:</p>

								<ul>

								  <li>a mechanism to allow sites to offer a choice of P3P policies to

								  visitors</li>

								  <li>a mechanism to allow visitors (through their user agents) to explicitly

								    agree to a P3P policy</li>

								  <li>mechanisms to allow for non-repudiation of agreements between visitors

								    and Web sites</li>

								  <li>a mechanism to allow user agents to transfer user data to services</li>

								</ul>


								<p>The P3P 1.1 Specification contains the most urgent improvements suggested

								by the <a href="http://www.w3.org/2002/p3p-ws/">P3P Workshop of December 2002

								in Dulles/Virginia</a>. Some of the Work suggested by this Workshop and by

								the <a href="http://www.w3.org/2003/p3p-ws/">P3P Workshop in Kiel</a> are

								delayed to later versions.</p>


								<h3 id="backwards">1.1.7 Backwards Compatibility</h3>


								<p>P3P 1.1 has been designed so that P3P 1.0 user agents can process P3P 1.1

								policies and policy reference files. This implies both that the P3P 1.1

								policies and policy reference files are fully compliant with the P3P 1.0 XML

								schema, and that the semantics of these files will not be misinterpreted by a

								user agent that interprets them according to the P3P 1.0 specification. All

								new syntax introduced in P3P 1.1 has been introduced as optional extensions

								using the P3P 1.0 extension mechanism. Changes to requirements or definitions

								introduced in P3P 1.1 add clarity where the P3P 1.0 specification is

								ambiguous, but do not cause a particular P3P vocabulary element to have

								different meanings in P3P 1.0 and P3P 1.1. In addition, some new requirements

								or features have been introduced in the P3P 1.1 specification that do not

								impact the ability of P3P 1.0 user agents to process P3P 1.1 policies and

								policy reference files. For the <a href="#Data_Schemas">base data-schema</a>,

								the <a href="#Data_Schemas_back">guidelines described there</a> apply. </p>


								<p>Note, P3P 1.1 data schemas cannot be read by P3P 1.0 user

								agents. This only impacts P3P 1.0 user agents that download and

								parse data schemas, and only when they access P3P 1.1 web sites

								that make use of data schemas beyond the P3P base data schema.</p>


								<h2 id="About">1.2 About this Specification</h2>


								<p>The Platform for Privacy Preferences Version 1.1 (P3P 1.1) defines

								a format for machine-readable privacy notices. It aims at two classes

								of products: Collectors of personal information such as web-sites can

								generate P3P 1.1 output to define what personal data may be collected

								and how it may be used. User agents consume a P3P 1.1. They may

								display a human readable version of the  privacy notice or change

								their behavior based on the content of the notice. </p>


								<h3 id="Conformance">1.2.1 Conformance Clause for P3P 1.1</h3>

								<p>The P3P specification defines, with the exception of <a

								href="#syntax_ext">section 2.2.2</a>, <a href="#syntax_link">section

								2.2.3</a> and <a href="#compact_policies">section 4</a>, an <em>XML with

								namespaces</em> syntax (cf. [<a href="#XML">XML</a>] and [<a

								href="#XML-Name">XML-Name</a>]). In the following, for the sake of brevity we

								will liberally talk about "XML", meaning the more accurate "XML with

								namespaces".</p>


								<p>As far as the non-XML syntax defined in this specification is concerned

								(<a href="#syntax_ext">section 2.2.2</a> defining P3P's HTTP header, <a

								href="#syntax_link">section 2.2.3</a> defining usage of P3P in HTML, and <a

								href="#compact_policies">section 4</a> defining compact policies), instead,

								the ABNF notation (together with the other constraints expressed in this

								specification using natural language) constitutes the <em>normative</em>

								definition.</p>


								<p>The normative parts of this specification are identified by

								"Normative" &amp; "Informative" labels within sections. The

								(non-normative) DTD provided formerly in Appendix 5 was removed due to

								the limits of expressiveness. The XML Schema is now the only normative

								source.</p>


								  <p>Individual conformance requirements or testable statements are

								     identifiable in the

								     <span class="form-data"><cite>

								       P3P 1.1

								     </cite></span>

								     specification as follows: </p>

								  <ul>

								      <li><span class="form-data">RFC2119 keywords </span>

								<p>The following key words are used throughout the document and have to be

								read as interoperability requirements. This specification uses words as

								defined in <a href="http://www.ietf.org/rfc/rfc2119.txt">RFC2119</a> [<a

								href="#KEY">KEY</a>] for defining the significance of each particular

								requirement. These words are:

								</p>


								<dl>

								  <dt>MUST or MUST NOT</dt>

								    <dd>This word or the adjective "required" means that the item is an

								      absolute requirement of the specification.</dd>

								  <dt>SHOULD or SHOULD NOT</dt>

								    <dd>This word or the adjective "recommended" means that there may exist

								      valid reasons in particular circumstances to ignore this item, but the

								      full implications should be understood and the case carefully weighed

								      before choosing a different course.</dd>

								  <dt>MAY</dt>

								    <dd>This word or the adjective "optional" means that this item is truly

								      optional. One vendor may choose to include the item because a

								      particular marketplace requires it or because it enhances the product,

								      for example; another vendor may omit the same item.</dd>

								</dl>

								<p/>

								</li>


								<li><span class="form-data">Formal specification </span>:

								<p>A BNF-like notation is also used thorough the specification: the [<a

								href="#ABNF">ABNF</a>] notation used in this specification is specified in <a

								href="http://www.ietf.org/rfc/rfc2234.txt">RFC2234</a> and summarized in <a

								href="#Appendix_Notation">Appendix 6</a>. However, note that in the case of

								XML syntax, such ABNF syntax is only a grammar representative used to enhance

								readability (lacking, for example, all the syntactic flexibilities that are

								implicitly included in XML, e.g. whitespace rules, quoting using either

								single quote (') or double quote ("), <a

								href="http://www.w3.org/TR/REC-xml/#dt-chardata">character escaping</a>,

								comments, case sensitivity, order of attributes, namespace handling), and as

								such it has no normative value. All the XML syntax defined in this

								specification MUST conform to the XML Schema for P3P (see <a

								href="#p3p11_schema">Appendix 5)</a>, which, together with the other

								constraints expressed in this specification using natural language,

								constitutes the <em>normative</em> definition.</p></li>

								  </ul>


								<h2 id="def_identity">1.3 Identity Definitions in the P3P Specification</h2>


								<p>In privacy regulations, guidelines and papers about privacy a variety of

								terms are used to describe data that identifies an individual to varying

								degrees.</p>


								<p>The European Union Directive 95/46/EC defines <q>an identifiable person</q> as

								<q>one who can be identified, directly or indirectly, in particular by

								reference to an identification number or to one or more factors specific to

								his physical, physiological, mental, economic, cultural or social

								identity.</q> The Directive also states that in determining whether a person

								is identifiable <q>account should be taken of all the means likely reasonably

								to be used either by the controller or by any other person to identify the

								said person; whereas the principles of protection shall not apply to data

								rendered anonymous in such a way that the data subject is no longer

								identifiable.</q></p>


								<p>In Australia, <q>personal information</q> is information about an

								individual <q>who can be identified, or whose identity could be reasonably

								ascertained.</q> In Canada <q>personal information</q> means information

								about an <q>identifiable</q> individual. In the United States, different

								sectors have different standards for identifiability of data. Similarly, in

								many other policy documents, terms such as <q>personally identifiable

								information (PII)</q> are often not defined or the cause for heated

								debate.</p>


								<p>The P3P Specification Working Group has taken the view point that most

								information referring to an individual is <q>identifiable</q> in some way. As

								with other important areas of the specification, the goal of the working

								group was to allow for a wide variety of understandings of identity in order

								to allow data collectors to best express their policy and users to make

								choices based on a definition of identity information that is important to

								them. (More information on the debate and the definitions can be found in [<a

								href="#cranor-p3p">Cranor,P3P</a>].</p>


								<h3 id="identified_data">1.3.1 <q>Identified</q> Data</h3>


								<p>The most common term in the specification is <q>identified data</q> and

								focuses on whether a service knows the data subject's identity.</p>


								<p><q>Identified data</q> is information in a record or profile that can

								reasonably be tied to an individual. Admittedly, this is a somewhat

								subjective standard. For example, a data collector storing Internet Protocol

								(IP) addresses (which can be created dynamically or could be static and

								therefore tied to a particular computer used by a single individual) should

								consider the IP address <q>identified data</q> only when this data is added

								to the record or profile of a specific individual. In the more common case,

								where data collectors use IP addressing information in the aggregate or make

								no attempt to tie the IP address to a specified individual or computer over a

								long period of time, IP addresses are not considered identified even though

								it is possible for someone (eg, law enforcement agents with proper subpoena

								powers) to identify the individual based on the stored data.</p>


								<p>As mentioned above, in the P3P context, any data that can be used

								reasonably by a data controller or any other person to identify an individual

								is considered to be identifiable data. The P3P specification uses the term

								<q>identified</q> to describe a subset of this data that can be reasonably be

								used by a data collector <em>without assistance from other parties to

								identify an individual</em>.</p>


								<h3 id="linked_data">1.3.2 <q>Non-Identifiable</q> Data</h3>


								<p>The working group also felt that data collectors should be able

								acknowledge when they make specific attempts to anonymize information.</p>


								<p>The term <q>non-identifiable</q> data refers to efforts made specifically

								to de-identify data. For example, a data collector collecting and storing IP

								addresses but not using them should NOT call this data

								<q>non-identifiable</q> even in the common case where they have no plans to

								identify an actual individual or computer. However, if a Web site collects IP

								addresses, but actively deletes all but the last four digits of this

								information in order to determine short term use, but insure that a

								particular individual or computer cannot be consistently identified, then the

								data collector can and should call this information <q>non-identifiable.</q>

								Also, non-identifiable can be used in cases where no information is being

								collected at all. Since most Web servers are designed to keep Web logs for

								maintenance, this would most likely mean that the data collector has taken

								specific efforts to ensure the anonymity of users.</p>


								<p>Under the above definitions, a lot of information could be

								<q>identifiable</q> (not specifically made anonymous), but not

								<q>identified</q> (reasonably able to be tied to an individual or

								computer).</p>


								<h3 id="identifiers">1.3.3 Identifiers</h3>


								<p>The Working Group decided against an identified or identifiable label for

								particular types of data. However, user agent implementers have the option of

								assigning these or other labels themselves and building user interfaces that

								allow users to make decisions about web sites on the basis of how they

								collect and use certain types of data.</p>


								<p>The Working Group felt that different user agent implementations could be

								created to focus on different concerns around data type. Therefore, the

								working group enabled the creation of a robust data schema including broad

								categories of information that may be considered sensitive by certain user

								groups. The Working Group hopes that a diverse set of user agents will be

								created to allow users the ability to make identity decisions based on

								specific collections and types of collects if they desire to do so. For

								example, a user agent could allow users to opt to be prompted when medical or

								financial identifier is being collected, independent of how that information

								is being used.</p>


								<h3 id="linked">1.3.4. Linked and Linkable Data</h3>


								<p>Cookies often store a unique number or database key that links to a

								database record, rather than storing the complete database record. Web sites

								that use P3P must disclose not only the types of data stored directly in a

								cookie, but also all data linked to a cookie. A large amount of data may be

								"linkable" to a cookie without actually being "linked" to that cookie.</p>


								<p>A piece of data X is said to be <i>linkable</i> to a cookie Y if a key

								stored in cookie Y can be used to retrieve X either directly or indirectly. A

								direct retrieval might happen, for example, if the key is associated with a

								database record in which X is stored. An indirect retrieval might happen, for

								example, if the key is associated with a database record that contains a

								piece of data that may be used, in turn, as a key to retrieve a record in a

								second database, and X is stored in the second database. Furthermore, if

								cookie Y is stored in a server log file, the log file may facilitate further

								linking. For example, when cookie Y is replayed, it may be accompanied by a

								referrer field that includes additional identifiable information or even

								another key. Alternatively, imagine a web site that sets two cookies, Y and

								Z. Cookies Y and Z may get replayed in the same HTTP request and subsequently

								recorded side-by-side in the server log file. Thus all data associated with

								cookie Y are also linkable to cookie Z. Indeed, unless precautions are taken

								to minimize server log files and severely restrict the use of identifiable

								data, almost all data an entity stores about an individual are likely to be

								linkable to any cookies they have set on that individual's computer.</p>


								<p>A piece of data X is said to be <i>linked</i> to a cookie Y if at least

								one of the following activities may take place as a result of cookie Y being

								replayed, immediately upon cookie replay or at some future time (perhaps as a

								result of retrospective analysis or processing of server logs):</p>

								<ul>

								  <li>A cookie containing X is set or reset.</li>

								  <li>X is retrieved from a persistent data store or archival media.</li>

								  <li>Information identifiable with the user -- including but not limited to

								    data entered into forms, IP address, clickstream data, and client events

								    -- is retrieved from a record, data structure, or file (other than a log

								    file) in which X is stored.</li>

								</ul>


								<p>Entities should consider their data collection and storage architectures

								carefully to determine what data may be linkable to their cookies and what

								data will actually be linked to each cookie. If data is linkable but not

								linked to a particular cookie, it does not have to be disclosed in a P3P

								statement concerning that cookie. However, should the entity associated with

								that P3P policy ever link the data for any reason other than to comply with

								law enforcement demands, they would be in violation of their stated

								policy.</p>


								<h2 id="Terminology">1.4 Terminology</h2>

								<dl>

								  <dt><a name="character" id="character"><strong>Character</strong></a></dt>

								    <dd>Strings consist of a sequence of zero or more characters, where a

								      character is defined as in the XML Recommendation [<a

								      href="#XML">XML</a>]. A single character in P3P thus corresponds to a

								      single Unicode abstract character with a single corresponding Unicode

								      scalar value (see [<a href="#UNICODE">UNICODE</a>]).</dd>

								  <dt><a name="Data_Elements" id="Data_Elements"><strong>Data

								  Element</strong></a></dt>

								    <dd>An individual data entity, such as last name or telephone number. For

								      interoperability, P3P 1.1 specifies a base set of data elements.</dd>

								  <dt><a name="Data_Category" id="Data_Category"><strong>Data

								  Category</strong></a></dt>

								    <dd>A significant attribute of a <a href="#Data_Elements">data

								      element</a> or <a href="#Data_Sets">data set</a> that may be used by a

								      trust engine to determine what type of element is under discussion,

								      such as physical contact information. P3P 1.1 specifies a set of <a

								      href="#Categories">data categories</a>.</dd>

								  <dt><a name="Data_Sets" id="Data_Sets"><strong>Data Set</strong></a></dt>

								    <dd>A known grouping of <a href="#Data_Elements">data elements</a>, such

								      as "<a href="#Postal"><code>user.home-info.postal</code></a>". The P3P

								      1.1 base data schema specifies a number of data sets.</dd>

								  <dt><strong>Data Schema</strong></dt>

								    <dd>A collection of data elements and sets defined using the P3P 1.1

								      <code>DATASCHEMA</code> element. P3P 1.1 defines a standard data schema

								      called the <em>P3P base data schema</em>.</dd>

								  <dt><strong>Data Structure</strong></dt>

								    <dd>A hierarchical description of a set of data elements. A data set can

								      be described according to its data structure. P3P 1.1 defines a set of

								      basic data structures that are used to describe the data sets in the P3P

								      base data schema.</dd>

								  <dt><strong>Equable Practice</strong></dt>

								    <dd>A practice that is very similar to another in that the purpose and

								      recipients are the same or more constrained than the original, and the

								      other disclosures are not substantially different. For example, two

								      sites with otherwise similar practices that follow different -- but

								      similar -- sets of industry guidelines.</dd>

								  <dt><strong>Identified Data</strong></dt>

								    <dd><q>Identified data</q> is information in a record or profile that can

								      reasonably be tied to an individual, as defined in <a

								      href="#def_identity">Section 1.3</a></dd>

								  <dt><strong>Policy</strong></dt>

								    <dd>A collection of one or more privacy statements together with

								      information asserting the identity, URI, assurances, and dispute

								      resolution procedures of the service covered by the policy.</dd>

								  <dt><strong>Practice</strong></dt>

								    <dd>The set of disclosures regarding data usage, including purpose,

								      recipients, and other disclosures.</dd>

								  <dt><strong>Preference</strong></dt>

								    <dd>A rule, or set of rules, that determines what action(s) a user agent

								      will take. A preference might be expressed as a formally defined

								      computable statement (e.g., the [<a href="#APPEL">APPEL</a>] preference

								      exchange language).</dd>

								  <dt><strong>Purpose</strong></dt>

								    <dd>The reason(s) for data collection and use.</dd>

								  <dt><strong>Repository</strong></dt>

								    <dd>A mechanism for storing user information under the control of the

								      user agent.</dd>

								  <dt><strong>Resource</strong></dt>

								    <dd>A network data object or service that can be identified by a URI.

								      Resources may be available in multiple representations (e.g. multiple

								      languages, data formats, size, and resolutions) or vary in other

								    ways.</dd>

								  <dt><strong>Safe Zone</strong></dt>

								    <dd>Part of a Web site where the service provider performs only minimal

								      data collection, and any data that is collected is used only in ways

								      that would not reasonably identify an individual.</dd>

								  <dt><strong>Service</strong></dt>

								    <dd>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.</dd>

								  <dt><strong>Service Provider (Data Controller, Legal Entity)</strong></dt>

								    <dd>The person or legal entity which offers information, products or

								      services from a Web site, collects information, and is responsible for

								      the representations made in a practice statement.</dd>

								  <dt><strong>Statement</strong></dt>

								    <dd>A P3P statement is a set of privacy practice disclosures relevant to

								      a collection of data elements.</dd>

								  <dt><strong>URI</strong></dt>

								    <dd>A Uniform Resource Identifier used to locate Web resources. For

								      definitive information on <a href="#URI">URI</a> syntax and semantics,

								      see [<a href="#URI">URI</a>]. URIs that appear within XML or HTML have

								   to be treated as specified in [<a

								   href="#CHARMODEL">CHARMODEL</a>]. This does not apply to

								   URIs appearing in HTTP header fields; the URIs there should

								   always be fully escaped.</dd>

								  <dt><strong>User</strong></dt>

								    <dd>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.</dd>

								  <dt><strong>User Agent</strong></dt>

								    <dd>A program whose purpose is to mediate interactions with services on

								      behalf of the user under the user's preferences. A user may have more

								      than one user agent, and agents need not reside on the user's desktop,

								      but <em>any agent must be controlled by and act on behalf of only the

								      user</em>. The trust relationship between a user and his or her agent

								      may be governed by constraints outside of P3P. For instance, an agent

								      may be trusted as a part of the user's operating system or Web client,

								      or as a part of the terms and conditions of an Internet Service Provider or privacy

								    proxy.</dd>

								</dl>

								</div>


								<div id="Referencing">

								<h1>2. Referencing Policies</h1>


								<h2 id="overview_of_prfs">2.1 Overview and Purpose of Policy References</h2>


								<p>Locating a P3P policy is one of the first steps in the operation of the

								P3P protocol. Services use policy references to state what policy applies to

								a specific URI or set of URIs. User agents use policy references to locate

								the privacy policy that applies to a Web resource, so that they can process

								that policy for the benefit of their user.</p>


								<p>Policy references are used extensively as a performance optimization. P3P

								policies are typically several kilobytes of data, while a URI that references

								a privacy policy is typically less than 100 bytes. In addition to the

								bandwidth savings, policy references also reduce the need for computation:

								policies can be uniquely associated with URIs, so that a user agent need only

								parse and process a policy once rather than process it with every document to

								which the policy applies. Furthermore, by placing the information about

								relevant policies in a centralized location, Web site administration is

								simplified.</p>


								<p>A policy reference file is used to associate P3P policies with certain

								regions of URI-space. The policy reference file is an XML with namespaces

								(see [<a href="#XML">XML</a>] and [<a href="#XML-Name">XML-Name</a>]) file

								that can specify the policy for a single Web document, portions of a Web

								site, or for an entire site. The policy reference file may refer to one or

								more P3P policies; this allows for a single reference file to cover an entire

								site, even if different P3P policies apply to different portions of the

								site.The policy reference file is used to make any or all of the following

								statements:</p>

								<ul>

								  <li>The URI where a P3P policy is found</li>

								  <li>The URIs or regions of URI-space covered by this policy</li>

								  <li>The URIs or regions of URI-space not covered by this policy</li>

								  <li>The regions of URI-space for embedded content on other servers that are

								    covered by this policy</li>

								  <li>The cookies that are or are not covered by this policy</li>

								  <li>The access methods for which this policy is applicable</li>

								  <li>The period of time for which these claims are considered to be

								  valid</li>

								</ul>


								<p>All of these statements are made in the body of the policy reference

								file.</p>


								<h2 id="ref_syntax">2.2 Locating Policy Reference Files</h2>


								<p>This section describes the mechanisms used to indicate the location of a

								policy reference file. Detailed syntax is also given for the supported

								mechanisms.</p>


								<p>The location of the policy reference file can be indicated using one of

								four mechanisms. The policy reference file</p>

								<ol>

								  <li>may be located in a predefined <a

								    href="#Well_Known_Location">"well-known" location</a>, or</li>

								  <li>a document may indicate a policy reference file through an HTML

								    <code>link</code> tag, or</li>

								  <li>a document may indicate a policy reference file through an XHTML

								    <code>link</code> tag, or</li>

								  <li>through an HTTP header.</li>

								</ol>


								<p>Note that if user agents support retrieving HTML (resp. XHTML) content

								over HTTP, they MUST handle mechanisms 1, 2 and 3 (resp. 4) listed above

								interchangeably. See also the requirements for <a

								href="#non-ambiguity">non-ambiguity</a>.</p>


								<p>Policies are applied at the level of resources. A "page" from the user's

								perspective may be composed of multiple HTTP resources; each may have its own

								P3P policy associated with it. As a practical note, however, placing many

								different P3P policies on different resources on a single page may make

								rendering the page and informing the user of the relevant policies difficult

								for user agents. Additionally, services are recommended to attempt to craft

								their policy reference files such that a single policy reference file covers

								any given "page"; this will speed up the user's browsing experience.</p>


								<p>For a user agent to process the policy that applies to a given resource,

								it must locate the policy reference file for that resource, fetch the policy

								reference file, parse the policy reference file, fetch any required P3P

								policies, and then parse the P3P policy or policies.</p>


								<p>This document does not specify how P3P policies may be associated with Web

								resources retrieved by means other than HTTP. However, it does not preclude

								future development of mechanisms for associating P3P policies with resources

								retrieved using other protocols. Furthermore, additional methods of

								associating P3P policies with HTTP resources may be developed in the

								future.</p>


								<h3 id="Well_Known_Location">2.2.1 Well-Known Location</h3>


								<p>Web sites using P3P MAY (and, are strongly encouraged to) place a policy

								reference file in a "well-known" location. To do this, a policy reference

								file would be made available on the site at the path

								<code>/w3c/p3p.xml</code>.</p>


								<p>Note that sites are not required to use this mechanism; however, by using

								this mechanism, sites can ensure that their P3P policy will be accessible to

								user agents before any other resources are requested from the site. This will

								reduce the need for user agents to access the site using safe zone practices.

								Additionally, if a site chooses to use this mechanism, the policy reference

								file located in the well-known location is not required to cover the entire

								site. For example, sites where not all of the content is under the control of

								a single organization MAY choose not to use this mechanism, or MAY choose to

								post a policy reference file which covers only a limited portion of the

								site.</p>


								<p>Use of the well-known location for a policy reference file does not

								preclude use of other mechanisms for specifying a policy reference file.

								Portions of the site MAY use any of the other supported mechanisms to specify

								a policy reference file, so long as the <a

								href="#non-ambiguity">non-ambiguity requirements</a> are met.</p>


								<p>For example, imagine a shopping-mall Web site run by the MallExample

								company. On their Web site (<code>mall.example.com</code>), companies

								offering goods or services at the mall would get a company-specific subtree

								of the site, perhaps in the path

								<code>/companies/<em>company-name</em></code>. The MallExample company may

								choose to put a policy reference file in the well-known location which covers

								all of their site except the <code>/companies</code> subtree. Then if the

								ShoeStoreExample company has some content in

								<code>/companies/shoestoreexample</code>, they could use one of the other

								mechanisms to indicate the location of a policy reference file covering their

								portion of the <code>mall.example.com</code> site.</p>


								<p>One case where using the well-known location for policy reference files is

								expected to be particularly useful is in the case of a site which has divided

								its content across several hosts. For example, consider a site which uses a

								different logical host for all of its Web-based applications than for its

								static HTML content. The other mechanisms allowed for specifying the location

								of a policy reference file require that some URI on the host being accessed

								must be fetched to locate the policy reference file. However, the well-known

								location mechanism has no such requirement. Consider the example of an HTML

								form located on <code>www.example.com</code>. Imagine that the action URI on

								that form points to server <code>cgi.example.com</code>. The policy reference

								file that covers the form is unable to make any statements about the action

								URI that processes the form. However, the site administrator publishes a

								policy reference file at <code>http://cgi.example.com/w3c/p3p.xml</code> that

								covers the action URI, thus enabling a user agent to easily locate the P3P

								policy that applies to the action URI before submitting the form contents.</p>


								<h3 id="syntax_ext">2.2.2 HTTP Headers</h3>


								<p>Any document retrieved by HTTP MAY point to a policy reference file

								through the use of a new response header, the <code>P3P</code> header ([<a

								href="#P3P-HEADER">P3P-HEADER</a>]). If a site is using P3P headers, it

								SHOULD include this on responses for all appropriate request methods,

								including <code>HEAD</code> and <code>OPTIONS</code> requests.</p>


								<p>The P3P header gives one or more comma-separated directives. The syntax

								follows:</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0">

								  <tbody>

								    <tr>

								      <td valign="top">[1]</td>

								      <td valign="top"><pre>p3p-header</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`P3P: ` p3p-header-field *(`,` p3p-header-field)</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[2]</td>

								      <td valign="top"><pre>p3p-header-field</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>policy-ref-field | compact-policy-field | extension-field</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[3]</td>

								      <td valign="top"><pre>policy-ref-field</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`policyref="` URI-reference `"`</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[4]</td>

								      <td valign="top"><pre>extension-field</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>token

								[`=` (token | quoted-string) ]</pre>

								      </td>

								    </tr>

								    <tr>

								      <td colspan="4" valign="top">Here, <code>URI-reference</code> is

								        defined as per <a href="http://www.ietf.org/rfc/rfc3986.txt">RFC

								        3986</a> [<a href="#URI">URI</a>], <code>token</code> and

								        <code>quoted-string</code> are defined by [<a

								        href="#HTTP1_1_ref">HTTP1.1</a>].</td>

								    </tr>

								  </tbody>

								</table>


								<p>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.</p>


								<p>The <code>policyref</code> directive gives a URI which specifies the

								location of a policy reference file which may reference the P3P policy

								covering the document that pointed to the reference file, and possibly others

								as well. When the <code>policyref</code> attribute is a relative URI, that

								URI is interpreted relative to the request URI. Note that fetching the URI

								given in the <code>policyref</code> directive MAY result in a 300-class HTTP

								return code (redirection); user agents MUST interpret those redirects with

								normal HTTP semantics. Services should note, of course, that use of redirects

								will increase the time required for user agents to find and interpret their

								policies. The <code>policyref</code> URI MUST NOT be used for any other

								purpose beyond locating and referencing P3P policies.</p>


								<p>The <code>compact-policy-field</code> is used to specify "compact

								policies". This is described in <a href="#compact_policies">Section 4</a>.</p>


								<p>User agents which find unrecognized directives (in the

								<code>extension-field</code>s) MUST ignore the unrecognized directives. This

								is to allow easier deployment of future versions of P3P.</p>


								<p><strong><a name="example_header" id="example_header">Example

								2.1:</a></strong></p>


								<p>1. Client makes a <code>GET</code> request.</p>

								<pre class="sample">GET /index.html HTTP/1.1

								Host: catalog.example.com

								Accept: */*

								Accept-Language: de, en

								User-Agent: WonderBrowser/5.2 (RT-11)</pre>


								<p>2. Server returns content and the <code>P3P</code> header pointing to the

								policy of the resource.</p>

								<pre class="sample">HTTP/1.1 200 OK

								P3P: policyref="http://catalog.example.com/P3P/PolicyReferences.xml"

								Content-Type: text/html

								Content-Length: 7413

								Server: CC-Galaxy/1.3.18</pre>


								<h3 id="syntax_link">2.2.3 The HTML <code>link</code> Tag</h3>


								<p>Servers MAY serve HTML content with embedded <code>link</code> tags (cf.

								[<a href="#HTML">HTML</a>]) that indicate the location of the relevant P3P

								policy reference file. This use of P3P does not require any change in the

								server behavior.</p>


								<p>The <code>link</code> tag encodes the policy reference information that

								could be expressed using the <code>P3P</code> header. The <code>link</code>

								tag takes the following form (here, we just produce one possible ABNF format

								for the link tag, and suppose the [<a href="#HTML">HTML</a>] syntax rules can

								be used when using such a tag into an HTML file):</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0">

								  <tbody>

								    <tr>

								      <td valign="top">[5]</td>

								      <td valign="top"><pre>p3p-link-tag</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`&lt;link rel="P3Pv1" href="` URI `"&gt;`</pre>

								      </td>

								    </tr>

								    <tr>

								      <td colspan="4">Here, <code>URI</code> is defined as per <a

								        href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986</a> [<a

								        href="#URI">URI</a>].</td>

								    </tr>

								  </tbody>

								</table>


								<p>When the <code>href</code> attribute is a relative URI, that URI is

								interpreted relative to the request URI.</p>


								<p>In order to illustrate with an example the use of the <code>link</code>

								tag, we consider the policy reference expressed in <a

								href="#example_header">Example 2.1</a> using HTTP headers. That example can

								be equivalently expressed using the link tag with the following piece of

								HTML:</p>

								<pre class="sample">&lt;link rel="P3Pv1"

								    href="http://catalog.example.com/P3P/PolicyReferences.xml"&gt;</pre>


								<p>Finally, note that since the <code>p3p-link-tag</code> is embedded in an

								HTML document, its character encoding will be the same as that of the HTML

								document. In contrast to P3P policy and policy reference documents (see <a

								href="#ref_file">section 2.3</a> and <a href="#P3P_markup">section 3</a>

								below), the <code>p3p-link-tag</code> need not be encoded using [<a

								href="#UTF-8">UTF-8</a>]. Note also that the <code>link</code> tag is not

								case sensitive.</p>


								<h3 id="XHTML-link">2.2.4 The XHTML <code>link</code> tag</h3>


								<p>Correspondingly to the HTML <code>link</code> tag, P3P also supports XHTML

								(cf. [<a href="#XHTML-MOD">XHTML-MOD</a>]). Servers MAY serve XHTML content

								that, using the <em>XHTML Link Module</em> (cf. <a

								href="http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_linkmodule">Section

								5.19</a> of [<a href="#XHTML-MOD">XHTML-MOD</a>]), indicates the location of

								the relevant P3P policy reference file with an embedded XHTML

								<code>link</code> tag. Like in the HTML case, an XHTML <code>link</code> tag

								can be used to encode the policy reference information that could be

								expressed using the <code>P3P</code> header, by:</p>

								<ul>

								  <li>setting its <code>rel</code> attribute to "<code>P3Pv1</code>"</li>

								  <li>setting its <code>href</code> attribute to the URI of the relevant P3P

								    policy reference file</li>

								</ul>


								<h3 id="other_protocols">2.2.5 HTTP ports and other protocols</h3>


								<p>The mechanisms described here MAY be used for HTTP transactions over any

								underlying protocol. This includes plain-text HTTP over TCP/IP connections or

								encrypted HTTP over SSL connections, as well as HTTP over any other

								communications protocol designers wish to implement.</p>


								<p>URIs MAY contain network port numbers, as specified in <a

								href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986</a> [<a

								href="#URI">URI</a>]. For the purposes of P3P, different ports on a single

								host MUST be considered to be separate "sites". Thus, for example, the policy

								reference file at the well-known location for www.example.com on port 80

								(http://www.example.com/w3c/p3p.xml) would not give any information about the

								policies which apply to www.example.com when accessed over SSL (as the SSL

								communication would take place on a different port, 443 by default).</p>


								<p>This document does not specify how P3P policies may be associated with

								resources retrieved by means other than HTTP. However, it does not preclude

								future development of mechanisms for associating P3P policies with resources

								retrieved over other protocols. Furthermore, additional methods of

								associating P3P policies with resources retrieved using HTTP may be developed

								in the future.</p>


								<h2 id="ref_file">2.3 Policy Reference File Syntax and Semantics</h2>


								<p>This section explains the contents of policy reference files in detail.</p>


								<h3 id="ref_file_example">2.3.1 Example Policy Reference File</h3>


								<p>Consider the case of a Web site wishing to make the following

								statements:</p>

								<ol>

								  <li>P3P policy <code>/P3P/Policies.xml#first</code> applies to the entire

								    site, except resources whose paths begin with <code>/catalog</code>,

								    <code>/cgi-bin</code>, or <code>/servlet</code>.</li>

								  <li>P3P policy <code>/P3P/Policies.xml#second</code> applies to all

								    resources whose paths begin with <code>/catalog</code>.</li>

								  <li>P3P policy <code>/P3P/Policies.xml#third</code> applies to all

								    resources whose paths begin with <code>/cgi-bin</code> or

								    <code>/servlet</code>, except for <code>/servlet/unknown</code>.</li>

								  <li>No statement is made about what P3P policy applies to

								    <code>/servlet/unknown</code>.</li>

								  <li>These statements are valid for 2 days.</li>

								</ol>


								<p>These statements can be represented by the following XML:</p>


								<p><strong><a name="example_prf" id="example_prf">Example

								2.2:</a></strong></p>

								<pre class="sample">&lt;META xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								 &lt;POLICY-REFERENCES&gt;

								  &lt;EXPIRY max-age="172800"/&gt;


								    &lt;POLICY-REF about="/P3P/Policies.xml#first"&gt;

								      &lt;INCLUDE&gt;/*&lt;/INCLUDE&gt;

								      &lt;EXCLUDE&gt;/catalog/*&lt;/EXCLUDE&gt;

								      &lt;EXCLUDE&gt;/cgi-bin/*&lt;/EXCLUDE&gt;

								      &lt;EXCLUDE&gt;/servlet/*&lt;/EXCLUDE&gt;

								    &lt;/POLICY-REF&gt;


								    &lt;POLICY-REF about="/P3P/Policies.xml#second"&gt;

								      &lt;INCLUDE&gt;/catalog/*&lt;/INCLUDE&gt;

								    &lt;/POLICY-REF&gt;


								    &lt;POLICY-REF about="/P3P/Policies.xml#third"&gt;

								      &lt;INCLUDE&gt;/cgi-bin/*&lt;/INCLUDE&gt;

								      &lt;INCLUDE&gt;/servlet/*&lt;/INCLUDE&gt;

								      &lt;EXCLUDE&gt;/servlet/unknown&lt;/EXCLUDE&gt;

								    &lt;/POLICY-REF&gt;


								 &lt;/POLICY-REFERENCES&gt;

								&lt;/META&gt;</pre>


								<p>Note this example also includes via <code><a

								href="#the_expiry_element">EXPIRY</a></code> a relative expiry time in the

								document (cf. <a href="#the_expiry_element">Section 2.3.2.3.2</a>).</p>


								<h3 id="ref_file_syntax">2.3.2 Policy Reference File Definition</h3>


								<p>This section defines the syntax and semantics of P3P policy reference

								files. All policy reference files MUST be encoded using [<a

								href="#UTF-8">UTF-8</a>]. P3P servers MUST encode their policy reference

								files using this syntax.</p>


								<h4 id="ref_file_processing">2.3.2.1 Policy reference file processing</h4>


								<h5 id="ref_file_ordering">2.3.2.1.1 Significance of order</h5>


								<p>A policy reference file has the <code>META</code> element as root. It may

								contain multiple <code>POLICY-REF</code> elements. If it does contain more

								than one element, they MUST be processed by user agents in the order given in

								the file. When a user agent is attempting to determine what policy applies to

								a given URI, it MUST use the first <code>POLICY-REF</code> element in the

								policy reference file which applies to that URI.</p>


								<p>Note that each <code>POLICY-REF</code> may contain multiple

								<code>INCLUDE</code>, <code>EXCLUDE</code>, <code>METHOD</code>,

								<code>COOKIE-INCLUDE</code>, and <code>COOKIE-EXCLUDE</code> elements and

								that all of these elements within a given <code>POLICY-REF</code> MUST be

								considered together to determine whether the <code>POLICY-REF</code> applies

								to a given URI. Thus, it is not sufficient to find an <code>INCLUDE</code>

								element that matches a given URI, as <code>EXCLUDE</code> or

								<code>METHOD</code> elements may serve as modifiers that cause the

								<code>POLICY-REF</code> not to match.</p>


								<h5 id="ref_file_wildcards">2.3.2.1.2 Wildcards in policy reference files</h5>


								<p>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

								('<code>*</code>') is used to represent a sequence of 0 or more of any

								character. No other special characters (such as those found in regular

								expressions) are supported.</p>


								<p>Note that since the asterisk is also a legal character in URIs ([<a

								href="#URI">URI</a>]), some special conventions have to be followed when

								encoding such "extended URIs" in a policy reference file:</p>

								<ul>

								  <li>URIs represented in policy reference files MUST be properly escaped, as

								    described in [<a href="#URI">URI</a>], <em>except</em>:

								    <ul>

								      <li>Literal '<code>*</code>'s in URIs MUST be escaped in policy

								        reference files (i.e., they MUST be represented as

								        "<code>%2A</code>"). Any '<code>*</code>' present in a URI within a

								        policy reference file will be taken as representing the asterisk

								        wildcard character.</li>

								      <li>Consequently, P3P user agents MUST properly un-escape a URI given

								        in a policy reference file, according to [<a href="#URI">URI</a>],

								        before trying to match it against an internally represented URI, but

								        only after recognizing any literal '<code>*</code>' present as the

								        asterisk wildcard character.</li>

								    </ul>

								  </li>

								</ul>


								<p>URI escaping and un-escaping is very much dependent 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 [<a href="#URI">URI</a>] for details on

								the standard escaping process. Note that P3P user agents MAY ignore any URI

								pattern that does not conform to [<a href="#URI">URI</a>].</p>


								<p>The wildcard character MAY be used in the <code>INCLUDE</code> and

								<code>EXCLUDE</code> elements, in the <code>COOKIE-INCLUDE</code> and

								<code>COOKIE-EXCLUDE</code> elements, and in the <code>HINT</code>

								element.</p>


								<h4 id="ref_file_refs">2.3.2.2 The <code>META</code>

								and <code>POLICY-REFERENCES</code> elements</h4>

								<dl>

								  <dt><strong><code>&lt;META&gt;</code></strong></dt>

								    <dd>The <code>META</code> element contains a complete policy reference

								      file. Optionally, one <code>POLICIES</code> element can follow.

								      <code>META</code> can also contain one or more one or more <a

								      href="#extension"><code>EXTENSION</code> elements</a> (cf. <a

								      href="#extension">section 3.5</a>), as well as an <code>xml:lang</code>

								      attribute (see <a href="#multiple">section 2.4.2</a>), to indicate the

								      language in which its content is expressed.</dd>

								  <dt><strong><code>&lt;POLICY-REFERENCES</code>&gt;</strong></dt>

								    <dd>This element MAY contain one or more <code>POLICY-REF</code> (policy

								      reference) elements. It MAY also contain one <a

								      href="#the_expiry_element"><code>EXPIRY</code> element</a> (indicating

								      their expiration time), one or more <a href="#hints"><code>HINT</code>

								      element</a>, and one or more <a

								      href="#extension"><code>EXTENSION</code> element</a> (cf. <a

								      href="#extension">section 3.5</a>).</dd>

								</dl>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0">

								  <tbody>

								    <tr>

								      <td valign="top">[6]</td>

								      <td valign="top"><pre>prf</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`&lt;META xmlns="http://www.w3.org/2002/01/P3Pv1"` [xml-lang] `&gt;`

								*extension

								policyrefs

								[policies]

								*extension

								"&lt;/META&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[7]</td>

								      <td valign="top"><pre>policyrefs</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"&lt;POLICY-REFERENCES&gt;"

								[expiry]

								*policyref

								*hint

								*extension

								"&lt;/POLICY-REFERENCES&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td colspan="4">Here <code>PCDATA</code> is defined in [<a

								        href="#XML">XML</a>].</td>

								    </tr>

								  </tbody>

								</table>


								<h4 id="ref_file_lifetime">2.3.2.3 Policy reference file lifetimes

								and the <code>EXPIRY</code> element</h4>


								<h5 id="motivation_and_mechanism">2.3.2.3.1 Motivation and mechanism</h5>


								<p>It is desirable for servers to inform user agents about how long they can

								use the claims made in a policy reference file. By enabling clients to cache

								the contents of a policy reference file, it reduces the time required to

								process the privacy policy associated with a Web resource. This also reduces

								load on the network. In addition, clients that don't have a valid policy

								reference file for a URI will need to use <a href="#safezone">"safe zone"

								practices</a> for their requests. If clients have policy reference files that

								they know are still valid, then they can make more informed decisions on how

								to proceed.</p>


								<p>In order to achieve these benefits, policy reference files SHOULD contain

								an <code>EXPIRY</code> element, which indicates the lifetime of the policy

								reference file. If the policy reference file does not contain an

								<code>EXPIRY</code> element, then it defaults to 24-hour lifetime.</p>


								<p>The lifetime of a policy reference file tells user agents how long they

								can rely on the claims made in the policy reference file. By setting the

								lifetime of a policy reference file, the publishing site agrees that the

								policies mentioned in the policy reference file are appropriate for the

								lifetime of the policy reference file. For example, if a policy reference

								file has a lifetime of 3 days, then a user agent need not reload that file

								for 3 days, and can assume that the references made in that policy reference

								file are good for 3 days. All of the policy references made in a single

								policy reference file will receive the same lifetime. The only way to specify

								different lifetimes for different policy references is to use separate policy

								reference files.</p>


								<p>The same mechanism used to indicate the lifetime of a policy reference

								file is also used to indicate the lifetime of a P3P policy. Thus P3P

								<code>POLICIES</code> elements SHOULD have an <code>EXPIRY</code> element

								associated with them as well. This lifetime applies to all P3P policies

								contained within that <code>POLICIES</code> element. If there is no

								<code>EXPIRY</code> element associated with a P3P policy, then it defaults to

								24-hour lifetime.</p>


								<p>When picking a lifetime for policies and policy reference files, sites

								need to pick a lifetime which balances two competing concerns. One concern is

								that the lifetime ought to be long enough to allow user agents to receive

								significant benefits from caching. The other concern is that the site would

								like to be able to change their policy for new data collection without

								waiting for an extremely long lifetime to expire. It is expected that

								lifetimes in the range of 1-7 days would be a reasonable balance between

								these two competing desires. Sites also need to remember the <a

								href="#policy_updates">policy update requirements</a> when updating their

								policies.</p>


								<p>When a policy reference file has expired, the information in the policy

								reference file MUST NOT be used by a user agent until that user agent has

								successfully revalidated the policy reference file, or has fetched a new copy

								of the policy reference file.</p>


								<p>Note that while user agents are not obligated to re-validate policy

								reference files or policy files that have not expired, they MAY choose to

								re-validate those files before their expiry period has passed in order to

								reduce the need for using <a href="#safezone">"safe zone" practices</a>. A

								valid P3P user agent implementation does not need to contain a cache for

								policies and policy reference files, though the implementation will have

								better performance if it does.</p>


								<h5 id="the_expiry_element">2.3.2.3.2 The

								<code>EXPIRY</code> element</h5>


								<p>The <code>EXPIRY</code> element can be used in a policy reference file

								and/or in a <code>POLICIES</code> element to state how long the policy

								reference file (or <a href="#Policies">policies</a>) remains valid. The

								expiry is given as either an absolute expiry time, or a relative expiry time.

								An absolute expiry time is a time, given in GMT, until which the policy

								reference file (or <a href="#Policies">policies</a>) is valid. A relative

								expiry time gives a number of seconds for which the policy reference file (or

								<a href="#Policies">policies</a>) is valid. This expiry time is relative to

								the time the policy reference file (or <a href="#Policies">policies</a>) was

								requested or last revalidated by the client. This computation MUST be done

								using the time of the original request or revalidation, and the current time,

								with both times generated from the client's clock. Revalidation is defined in

								section 13.3 of [<a href="#HTTP1_1_ref">HTTP1.1</a>].</p>


								<p>The minimum amount of time for any relative expiry time is 24 hours, or

								86400 seconds. Any relative expiration time shorter than 86400 seconds MUST

								be treated as being equal to 86400 seconds in a client implementation. If a

								client encounters an absolute expiration time that is in the past, it MUST

								act as if NO policy reference file (or policy) is available. See section

								2.4.7 "<a href="#absence_of_prf">Absence of Policy Reference File</a>" for

								the required procedure in such cases.</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0">

								  <tbody>

								    <tr>

								      <td valign="top">[8]</td>

								      <td valign="top"><pre>expiry</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"&lt;EXPIRY" (absdate|reldate) "/&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[9]</td>

								      <td valign="top"><pre>absdate</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`date="` HTTP-date `"`</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[10]</td>

								      <td valign="top"><pre>reldate</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`max-age="` delta-seconds `"`</pre>

								      </td>

								    </tr>

								    <tr>

								      <td colspan="4">Here, HTTP-date is defined in section 3.3.1 of [<a

								        href="#HTTP1_1_ref">HTTP1.1</a>], and delta-seconds is defined in

								        section 3.3.2 of [<a href="#HTTP1_1_ref">HTTP1.1</a>].</td>

								    </tr>

								  </tbody>

								</table>


								<h5 id="use_of_http_headers">2.3.2.3.3

								Requesting Policies and Policy Reference Files</h5>


								<p>In a real-world network, there may be caches which will cache the contents

								of policies and policy reference files. This is good for increasing the

								overall network performance, but may have deleterious effects on the

								operation of P3P if not used correctly. There are two specific concerns:</p>

								<ol>

								  <li>When a user agent receives a policy reference file (or policy), if it

								    was served from a caching proxy (see e.g. [<a

								    href="#CACHING">CACHING</a>]) the user agent needs to know how long the

								    policy reference file or policy resided in the caching proxy. This time

								    MUST be subtracted from the lifetime of the policy or policy reference

								    file which uses relative expiry.</li>

								  <li>When a user agent needs to re-validate a policy reference file (or

								    policy), it needs to make sure that the revalidation fetches a current

								    version of the policy reference file (or policy). For example, consider

								    the case where a user agent holds a policy reference file with a 1 day

								    relative expiry. If the user agent re-fetches it from a caching proxy, and

								    the file has been residing in the caching proxy for 3 days, then the

								    resulting file is useless.</li>

								</ol>


								<p>HTTP 1.1 [<a href="#HTTP1_1_ref">HTTP1.1</a>] contains powerful

								cache-control mechanisms to allow clients to place requirements on the

								operations of network caches; these mechanisms can resolve the problems

								mentioned above. The specific method will be discussed below.</p>


								<p>HTTP 1.0, however, does not provide those more sophisticated cache control

								mechanisms. An HTTP 1.0 caching proxy will, in all likelihood, compute a

								cache lifetime for the policy reference file (or policies) based on the

								file's last-modified date; the resulting cache lifetime could be

								significantly longer than the lifetime specified by the <code>EXPIRY</code>

								element. The caching proxy could then serve the policy reference file (or

								policies) to clients beyond the lifetime in the <code>EXPIRY</code>; the

								result would be that user-agents would receive a useless policy reference

								file (or policies).</p>


								<p>The second problem with an HTTP 1.0 caching proxy is that a user agent has

								no way to know how long the reference file may have been stored by the

								caching proxy. If the policy reference file (or policies) relies on relative

								expiry, it would then be impossible for the user agent to determine if the

								reference file's lifetime has already expired, or when it will expire.</p>


								<p>Thus, if a user agent is requesting a policy reference file or a policy,

								and does not know for certain that there are no HTTP 1.0 caches in the path

								to the origin server, then the request MUST force an end-to-end revalidation.

								This can be done with the <tt>Pragma: no-cache</tt> HTTP request-header. Note

								that neither HTTP nor P3P define a way to determine if there is a HTTP

								1.0-compliant cache in any given network path, so unless the user agent has

								this information derived from an outside source, it MUST force the end-to-end

								revalidation.</p>


								<p>If the user agent has some way to know that all caches in the network path

								to the origin server are compliant with HTTP 1.1 (or that there are no caches

								in the network path to the origin server), then the client MAY do the

								following instead of forcing an end-to-end revalidation:</p>

								<ol>

								  <li>Use cache-control request-headers to ensure that the received response

								    is not older than its lifetime. This is done with the max-age

								    cache-control setting, with a maximum age significantly less than the

								    lifetime of the policy reference file (or policies). For example, a user

								    agent could send Cache-Control: max-age=43200, thus ensuring that the

								    response is no more than 12 hours old.</li>

								  <li>Subtract the age of the response from the lifetime of the policy

								    reference file (or policies), if it uses a relative expiry time. The age

								    of the response is given by the Age: HTTP response-header.</li>

								</ol>


								<p>Note that it is impossible for a client to accurately predict the amount

								of latency that may affect an HTTP request. Thus, if the policy reference

								file covering a request is going to expire soon, clients MAY wish to consider

								warning their users and/or re-validating the policy reference file before

								continuing with the request.</p>


								<h5 id="error_handling">2.3.2.3.4 Error handling for

								policy reference file and policy lifetimes</h5>


								<p>The following situations have their semantics specifically defined:</p>

								<ol>

								  <li>An absolute expiry date in the past renders the policy reference file

								    (or policies) useless, as does an invalid or malformed expiry date,

								    whether relative or absolute. In this case, user agents MUST act as if NO

								    policy reference file (or <a href="#Policies">policies</a>) is available.

								    See section 2.4.7 "<a href="#absence_of_prf">Absence of Policy Reference

								    File</a>" for the required procedure in such cases.</li>

								  <li>A relative expiration time shorter than 86400 seconds (1 day) is

								    considered to be equal to 86400 seconds.</li>

								  <li>When a policy reference file contains more than one <code>EXPIRY</code>

								    element, the first one takes precedence for determining the lifetime of

								    the policy reference file.</li>

								</ol>


								<h4 id="ref_file_policyref">2.3.2.4 The

								<code>POLICY-REF</code> element</h4>


								<p>A policy reference file may refer to multiple P3P policies, specifying

								information about each. The <code>POLICY-REF</code> element describes

								attributes of a single P3P policy. Elements within the

								<code>POLICY-REF</code> element give the location of the policy and specify

								the areas of URI-space (and cookies) that each policy covers.</p>

								<dl>

								  <dt><code><strong>POLICY-REF</strong></code></dt>

								    <dd>contains information about a single P3P policy.</dd>

								  <dt><code><strong>about</strong></code> <strong><em>(mandatory

								  attribute)</em></strong></dt>

								    <dd><em>URI reference</em> ([<a href="#URI">URI</a>]), where the fragment

								      identifier part denotes the <em>name</em> of the policy (given in its

								      <code>name</code> attribute), and the URI part denotes the URI where

								      the policy resides (a policy file, or a policy reference file, see <a

								      href="#Policies">Section 3.2</a>). If this is a relative URI reference,

								      it is interpreted relative to the URI of the policy reference file it

								      resides in.</dd>

								</dl>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0">

								  <tbody>

								    <tr>

								      <td valign="top">[11]</td>

								      <td valign="top"><pre>policy-ref</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`&lt;POLICY-REF about="` URI-reference `"&gt;`

								*include

								*exclude

								*cookie-include

								*cookie-exclude

								*method-element

								*extension

								`&lt;/POLICY-REF&gt;`</pre>

								      </td>

								    </tr>

								    <tr>

								      <td colspan="4">Here, <code>URI-reference</code> is defined as per <a

								        href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986</a> [<a

								        href="#URI">URI</a>].</td>

								    </tr>

								  </tbody>

								</table>


								<h4 id="ref_file_preexc">2.3.2.5 The

								<code>INCLUDE</code> and <code>EXCLUDE</code> elements</h4>


								<p>Each <code>INCLUDE</code> or <code>EXCLUDE</code> element specifies one

								local URI or set of local URIs. A set of URIs is specified if the <a

								href="#ref_file_wildcards">wildcard character '*'</a> is used in the

								URI-pattern. These elements are used to specify the portion of the Web site

								that is covered by the policy referenced by the enclosing

								<code>POLICY-REF</code> element.</p>


								<p>When <code>INCLUDE</code> (and optionally, <code>EXCLUDE</code>) elements

								are present in a <code>POLICY-REF</code> element, it means that the policy

								specified in the <code>about</code> attribute of the <code>POLICY-REF</code>

								element applies to all the URIs at the requested host corresponding to the

								local-URI(s) matched by any of the <code>INCLUDE</code>s, but not matched by

								an <code>EXCLUDE</code> element.</p>


								<p>A policy referenced in a policy reference file can be applied only to URIs

								on the DNS (Domain Name System) host that references 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 <code>INCLUDE</code> and <code>EXCLUDE</code>

								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 <code>POLICY-REF</code>

								element).</p>


								<p>If a <code>METHOD</code> element (<a href="#ref_file_method">section

								2.3.2.8</a>) specifies one or more methods for an enclosing policy reference,

								it follows that all methods <em>not</em> mentioned are consequently

								<em>not</em> covered by this policy. In the case that this is the only policy

								reference for a given URI prefix, user agents MUST assume that NO policy is

								in effect for all methods NOT mentioned in the policy reference file. It is

								legal but pointless to supply a <code>METHOD</code> element without any

								<code>INCLUDE</code> or <code>COOKIE-INCLUDE</code> elements.</p>


								<p>It is legal, but pointless, to supply an <code>EXCLUDE</code> element

								without any <code>INCLUDE</code> elements; in that case, the

								<code>EXCLUDE</code> element MUST be ignored by user agents.</p>


								<p>Note that the set of URIs specified with <code>INCLUDE</code> and

								<code>EXCLUDE</code> does not include cookies that might be set or replayed

								when requesting one of such URIs: in order to associate policies with

								cookies, the <a href="#cookies"><code>COOKIE-INCLUDE</code> and

								<code>COOKIE-EXCLUDE</code></a> elements are needed.</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[12]</td>

								      <td valign="top"><pre>include</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"&lt;INCLUDE&gt;" relativeURI "&lt;/INCLUDE&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[13]</td>

								      <td valign="top"><pre>exclude</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"&lt;EXCLUDE&gt;" relativeURI "&lt;/EXCLUDE&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td colspan="4">Here, <code>relativeURI</code> is defined as per <a

								        href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986</a> [<a

								        href="#URI">URI</a>], with the addition that the '<code>*</code>'

								        character is to be treated as a wildcard, as defined in <a

								        href="#ref_file_wildcards">section 2.3.2.1.2</a>.</td>

								    </tr>

								  </tbody>

								</table>


								<h4 id="hints">2.3.2.6 The <code>HINT</code> element</h4>


								<p>Policy reference hints are a performance optimization that can be used

								under certain conditions. A site may declare a policy reference for itself

								using the well-known location, the P3P response header, or the HTML/XHTML

								<code>link</code> tag. It MAY further provide a hint to additional policy

								references, such as those declared by other sites.</p>


								<p>For example, an HTML page might hint at policy references for its

								hyper-links, embedded content, and action URIs. User agents MAY use the hint

								mechanism to discover policy reference files before requesting the affected

								URIs when the policy references are not available from the well-known

								location.</p>


								<p>User agents which use hints to retrieve policies MUST NOT apply them to

								any site other than the one which contains the hinted policy reference

								file.</p>


								<p>Any policy reference file MAY contain zero or more policy reference hints.

								Each hint is contained in a <code>HINT</code> element with two attributes,

								<code>scope</code> and <code>path</code>.</p>


								<p>The <code>scope</code> attribute is used to specify a URI scheme and

								authority to which the hinted policy reference can be applied. If the

								authority component (cf. [<a href="#URI">URI</a>]) is a server component

								(e.g., a host name or IP address) the host part of the authority MAY begin

								with a <a href="#ref_file_wildcards">wildcard</a>, as defined in Section

								2.3.2.1.2. The <code>scope</code> attribute MUST NOT contain a wildcard in

								any other position, MUST be encoded according to the conventions in Section

								2.3.2.1.2, and MUST NOT contain a path, query or fragment URI component.

								Additionally, if the authority is a server, it SHOULD NOT contain a userinfo

								part.</p>


								<p>For example, legal values for <code>scope</code> include:</p>

								<ul>

								  <li><code>http://www.example.com</code></li>

								  <li><code>http://www.example.com:81</code></li>

								  <li><code>http://*.example.com</code></li>

								  <li><code>ftp://ftp.example.org</code></li>

								</ul>


								<p>The following are illegal values for the <code>scope</code> attribute:</p>

								<ul>

								  <li><code>http://www.*.com</code> ; the wildcard can only be at the

								  start</li>

								  <li><code>http://www.example.com/</code> ; the trailing slash is not

								  allowed</li>

								  <li><code>www.example.com</code> ; the scheme must be stated</li>

								  <li><code>*://www.example.com</code> ; the scheme cannot contain a

								  wildcard</li>

								  <li><code>http://www.example.com:*</code>; the port cannot contain a

								    wildcard</li>

								</ul>


								<p>The <code>path</code> attribute is used to locate the policy reference

								file on the hinted site. It is a relative URI whose base is the URI scheme

								and authority matched in the <code>scope</code> attribute. The

								<code>path</code> attribute MUST NOT be an absolute URI, so that the policy

								reference file is always retrieved from the same site that it is applied

								to.</p>


								<p><strong>Example 2.3:</strong></p>

								<pre class="sample">&lt;HINT scope="http://www.example.org" path="/mypolicy/p3.xml" /&gt;

								&lt;HINT scope="http://www.example.net:81" path="/w3c/prf.xml" /&gt;

								&lt;HINT scope="http://*.shop.example.com" path="/w3c/prf.xml" /&gt;</pre>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[14]</td>

								      <td valign="top"><pre>hint</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`&lt;HINT scope="` scheme ( `://` | `:/` ) authority `" path="` relativeURI `/&gt;`</pre>

								      </td>

								    </tr>

								    <tr>

								      <td colspan="4">Here, <code>scheme</code>, <code>authority</code> and

								        <code>relativeURI</code> are taken from <a

								        href="http://www.ietf.org/rfc/rfc2965.txt">RFC 2965</a> [<a

								        href="#ref_STATE">STATE</a>].</td>

								    </tr>

								  </tbody>

								</table>


								<h4><a id="cookies">2.3.2.7 The <code>COOKIE-INCLUDE</code> and

								<code>COOKIE-EXCLUDE</code> elements</a></h4>


								<p>The <code>COOKIE-INCLUDE</code> and <code>COOKIE-EXCLUDE</code> elements

								are used to associate policies to cookies (cf. [<a

								href="#ref_COOKIES">COOKIES</a>] and [<a href="#ref_STATE">STATE</a>]).</p>


								<p>A cookie policy MUST cover any data (within the scope of P3P)

								that is stored in that cookie or <a href="#linked">linked</a> via

								that cookie. It MUST also reference all purposes associated with

								data stored in that cookie or enabled by that cookie. In

								addition, any data/purpose stored or <a href="#linked">linked</a>

								via a cookie MUST also be put in the cookie policy. In addition,

								if that linked data is collected by HTTP, then the policy that

								covers that <code>GET</code>/<code>POST</code>/whatever request

								must cover that data collection. For example, when CatalogExample

								asks customers to fill out a form with their name, billing, and

								shipping information, the P3P policy that covers the form

								submittal will disclose that CatalogExample collects this data

								and explain how it is used. If CatalogExample sets a cookie so

								that it can recognize its customers and observe their behavior on

								its Web site, it would have a separate policy for this cookie.

								However, if this cookie is also linked to the user's name,

								billing, and shipping information -- perhaps so CatalogExample

								can generate custom catalog pages based on where the customer

								lives -- then that data must also be disclosed in the cookie

								policy.</p>


								<p>For the purpose of this specification, state management mechanisms use

								either <code>SET-COOKIE</code> or <code>SET-COOKIE2</code> headers, and

								cookie-namespace is defined as the value of the NAME, VALUE, Domain and Path

								attributes, specified in [<a href="#ref_COOKIES">COOKIES</a>] and [<a

								href="#ref_STATE">STATE</a>].</p>


								<p>Each <code>COOKIE-INCLUDE</code> or <code>COOKIE-EXCLUDE</code> element

								can be used to match (similarly to <code>INCLUDE</code> and

								<code>EXCLUDE</code>) the NAME, VALUE, Domain and Path components of a

								cookie, expressing the cookies which are covered by the policy specified by

								the <code>about</code> attribute when the cookies are set from the resources

								on the Web site where the policy reference file resides:</p>

								<dl>

								  <dt><code><strong>COOKIE-INCLUDE</strong></code> (resp.

								  <code><strong>COOKIE-EXCLUDE</strong></code>)</dt>

								    <dd>include (resp. exclude) cookies that match the <code>name</code>,

								      <code>value</code>, <code>domain</code> and <code>path</code>

								    attributes</dd>

								  <dt><code><strong>name</strong></code></dt>

								    <dd>match the NAME portion of the cookie</dd>

								  <dt><code><strong>value</strong></code></dt>

								    <dd>match the VALUE portion of the cookie</dd>

								  <dt><code><strong>domain</strong></code></dt>

								    <dd>match the Domain portion of the cookie</dd>

								  <dt><code><strong>path</strong></code></dt>

								    <dd>match the Path portion of the cookie</dd>

								</dl>


								<p>If the value of the <code>domain</code> attribute is set to the dot

								character ("<code>.</code>"), the domain will match only cookies that omit

								the <code>domain</code> attribute (and thus have domain equivalent to the

								request host as per <a href="http://www.ietf.org/rfc/rfc2965.txt">RFC

								2965</a> ([<a href="#ref_STATE">STATE</a>]).</p>


								<p>Cookies that omit the path attribute have the default path of the request

								URI that generated the set-cookie response as per <a

								href="http://www.ietf.org/rfc/rfc2965.txt">RFC 2965</a> [<a

								href="#ref_STATE">STATE</a>]. The <code>path</code> attribute of a

								<code>COOKIE-INCLUDE</code> should be matched against this default value if a

								cookie omits the <code>path</code> attribute.</p>


								<p>All four attributes are optional. If an attribute is absent, the

								<code>COOKIE-INCLUDE</code> (resp. <code>COOKIE-EXCLUDE</code>) will match

								cookies that have that attribute set to any value.</p>


								<p>When <code>COOKIE-INCLUDE</code> (and optionally,

								<code>COOKIE-EXCLUDE</code>) elements are present in a

								<code>POLICY-REF</code> element, the policy specified in the

								<code>about</code> attribute of the <code>POLICY-REF</code> element applies

								to every cookie that is matched by any <code>COOKIE-INCLUDE</code>'s, and not

								matched by a <code>COOKIE-EXCLUDE</code> element.</p>


								<p>User agents MUST interpret <code>COOKIE-INCLUDE</code> and

								<code>COOKIE-EXCLUDE</code> elements in a policy reference file to determine

								the policy that applies to cookies set by or replayed to the host to which

								the policy reference file applies. While the domain attribute of a

								<code>COOKIE-INCLUDE</code> may match more broadly (for example, if the

								domain attribute is omitted it defaults to matching any domain value), user

								agents MUST limit their application of the policy to domains that could be

								legally used in a cookie set by the host to which the policy reference file

								applies. For example, if abc.xyz.example.com declares a policyref with

								<code>&lt;COOKIE-INCLUDE domain="*.xyz.*ple.com"/&gt;</code>, this would be

								matched to cookies with domains such as .abc.xyz.example.com and

								.xyz.example.com, but not .example.com or .xyz.sample.com.</p>


								<p>A P3P policy can be associated with a cookie by the host that set that

								cookie as well as by any or all of the hosts to which it might be replayed. A

								user agent MAY fetch a cookie policy at the time a cookie is set and apply it

								later when the cookie is replayed, perhaps to other hosts in the domain. A

								user agent MAY request a policy reference file from a host before replaying a

								cookie to that host, and if the policy reference file contains an appropriate

								<code>COOKIE-INCLUDE</code>, a policy will be applied to that cookie even if

								the cookie was not set by that host. Any host to which the cookie may be

								replayed MUST be able to honor all the policies associated with the cookie,

								regardless of whether that host declares a policy for that cookie. Thus sites

								that set cookies that may be replayed to multiple hosts within a domain need

								to coordinate to make sure all the hosts can follow the declared policy. In

								addition, sites should be cautious with their use of wildcards to make sure

								that they do not inadvertently apply a policy to cookies to which it should

								not be applied (including previously set cookies that are still in use and

								cookies set by other hosts in the domain).</p>


								<p>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.</p>


								<p>User agents that evaluate cookie policies SHOULD perform this evaluation

								*and its resultant behavior* before setting a cookie so that the cookie can

								be discarded without being set if that is what is dictated by the user's

								preferences.</p>


								<p>Example 2.4 states that <code>/P3P/Policies.xml#first</code> applies to

								all cookies.</p>


								<p><strong>Example 2.4:</strong></p>

								<pre class="sample">&lt;META xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								  &lt;POLICY-REFERENCES&gt;

								    &lt;POLICY-REF about="/P3P/Policies.xml#first"&gt;

								      &lt;COOKIE-INCLUDE name="*" value="*" domain="*" path="*"/&gt;

								    &lt;/POLICY-REF&gt;

								  &lt;/POLICY-REFERENCES&gt;

								&lt;/META&gt;</pre>


								<p>Example 2.5 states that <code>/P3P/Policies.xml#first</code> applies to

								all cookies, except cookies with the cookie name value of

								"<code>obnoxious-cookie</code>", a domain value of

								"<code>.example.com</code>", and a path value of "<code>/</code>", and that

								<code>/P3P/Policies.xml#second</code> applies to all cookies with the cookie

								name of "<code>obnoxious-cookie</code>", a domain value of

								"<code>.example.com</code>", and a path value of "<code>/</code>".</p>


								<p><strong>Example 2.5:</strong></p>

								<pre class="sample">&lt;META xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								  &lt;POLICY-REFERENCES&gt;

								    &lt;POLICY-REF about="/P3P/Policies.xml#first"&gt;

								      &lt;COOKIE-INCLUDE name="*" value="*" domain="*" path="*"/&gt;

								      &lt;COOKIE-EXCLUDE name="obnoxious-cookie" value="*" domain=".example.com" path="/"/&gt;

								    &lt;/POLICY-REF&gt;

								    &lt;POLICY-REF about="/P3P/Policies.xml#second"&gt;

								      &lt;COOKIE-INCLUDE name="obnoxious-cookie" value="*" domain=".example.com" path="/"/&gt;

								    &lt;/POLICY-REF&gt;

								  &lt;/POLICY-REFERENCES&gt;

								&lt;/META&gt;</pre>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[15]</td>

								      <td valign="top"><pre>cookie-include</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"&lt;COOKIE-INCLUDE"

								   [` name="` token `"`]   ; matches the cookie's NAME

								   [` value="` token `"`]  ; matches the cookie's VALUE

								   [` domain="` token `"`] ; matches the cookie's Domain

								   [` path="` token `"`]   ; matches the cookie's Path

								"/&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[16]</td>

								      <td valign="top"><pre>cookie-exclude</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"&lt;COOKIE-EXCLUDE"

								   [` name="` token `"`]   ; matches the cookie's NAME

								   [` value="` token `"`]  ; matches the cookie's VALUE

								   [` domain="` token `"`] ; matches the cookie's Domain

								   [` path="` token `"`]   ; matches the cookie's Path

								"/&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td colspan="4">Here, <code>token</code>, <code>NAME</code>,

								        <code>VALUE</code>, <code>Domain</code> and <code>Path</code> are

								        defined as per <a href="http://www.ietf.org/rfc/rfc2965.txt">RFC

								        2965</a> [<a href="#ref_STATE">STATE</a>], with the addition that the

								        '<code>*</code>' character is to be treated as a wildcard, as defined

								        in <a href="#ref_file_wildcards">section 2.3.2.1.2</a>.</td>

								    </tr>

								  </tbody>

								</table>


								<p>Note that [<a href="#ref_STATE">STATE</a>] states default values for the

								domain and path attributes of cookies: these should be used in the comparison

								if those attributes are not found in a specific cookie. Also, conforming to

								[<a href="#ref_STATE">STATE</a>], if an explicitly specified

								<code>Domain</code> value does not start with a full stop ("<code>.</code>"),

								the user agent MUST prepend a full stop for it; and, note that every

								<code>Path</code> begins with the "<code>/</code>" character.</p>


								<h4><a id="ref_file_method">2.3.2.8 The <code>METHOD</code> element</a></h4>


								<p>By default, a policy reference applies to the stated URIs regardless of

								the method used to access the resource. However, a Web site may wish to

								define different P3P policies depending on the method to be applied to a

								resource. For example, a site may wish to collect more data from users when

								they are performing <code>PUT</code> or <code>DELETE</code> methods than when

								performing <code>GET</code> methods.</p>


								<p>The <code>METHOD</code> element in a policy reference file is used to

								state that the enclosing policy reference only applies when the specified

								methods are used to access the referenced resources. The <code>METHOD</code>

								element may be repeated to indicate multiple applicable methods. If the

								<code>METHOD</code> element is not present in a <code>POLICY-REF</code>

								element, then that <code>POLICY-REF</code> element covers the resources

								indicated regardless of the method used to access them.</p>


								<p>So, to state that <code>/P3P/Policies.xml#first</code> applies to all

								resources whose paths begin with <code>/docs/</code> for <code>GET</code> and

								<code>HEAD</code> methods, while <code>/P3P/Policies.xml#second</code>

								applies for <code>PUT</code> and <code>DELETE</code> methods, the following

								policy reference would be written:</p>


								<p><strong>Example 2.6:</strong></p>

								<pre class="sample">&lt;META xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								  &lt;POLICY-REFERENCES&gt;

								    &lt;POLICY-REF about="/P3P/Policies.xml#first"&gt;

								      &lt;INCLUDE&gt;/docs/*&lt;/INCLUDE&gt;

								      &lt;METHOD&gt;GET&lt;/METHOD&gt;

								      &lt;METHOD&gt;HEAD&lt;/METHOD&gt;

								    &lt;/POLICY-REF&gt;

								    &lt;POLICY-REF about="/P3P/Policies.xml#second"&gt;

								      &lt;INCLUDE&gt;/docs/*&lt;/INCLUDE&gt;

								      &lt;METHOD&gt;PUT&lt;/METHOD&gt;

								      &lt;METHOD&gt;DELETE&lt;/METHOD&gt;

								    &lt;/POLICY-REF&gt;

								  &lt;/POLICY-REFERENCES&gt;

								&lt;/META&gt;</pre>


								<p>Note that HTTP requires the same behavior for <code>GET</code> and

								<code>HEAD</code> requests, thus it is inappropriate to specify different P3P

								policies for these methods. The syntax for the <code>METHOD</code> element

								is:</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[17]</td>

								      <td valign="top"><pre>method-element</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`&lt;METHOD&gt;` Method `&lt;/METHOD&gt;`</pre>

								      </td>

								    </tr>

								    <tr>

								      <td colspan="4">Here, <code>Method</code> is defined in the section

								        5.1.1 of [<a href="#HTTP1_1_ref">HTTP1.1</a>].</td>

								    </tr>

								  </tbody>

								</table>


								<p>Finally, note that the <code>METHOD</code> element is designed to be used

								in conjunction with <code>INCLUDE</code> or <code>COOKIE-INCLUDE</code>

								elements. A <code>METHOD</code> element by itself will never apply a

								<code>POLICY-REF</code> to a URI.</p>


								<h4 id="oho">2.3.2.9 Domain Relationships</h4>


								<p>This section describes a method to allow user agents to

								recognize when hosts in different domains are owned by the same entity or

								entities acting as agents for one another. User agents may use this

								information when applying privacy preferences, particularly to avoid

								implementation issues encountered when more stringent privacy preferences are

								applied to domains that are deemed to be owned by third-parties. See [<a

								href="#coremetrics">Coremetrics</a>]</p>


								<h4 id="oho_ex">2.3.2.9.1 <code>OUR-HOST</code> Extension</h4>


								<p>The <code>OUR-HOST</code> element allows sites to declare hosts that are

								owned by the entity in the associated policy or that are acting as agents of

								that entity. User agents may use this extension to distinguish between such a

								host and actual third-party hosts.</p>


								<p>The attribute <code>name</code> is a host name qualifier that can be a

								full individual host/domain name (e.g. www.example.com) or a wildcard

								qualifier describing a set of hosts/domains.</p>

								<pre>  our-hosts-extension   = `&lt;EXTENSION optional="yes"&gt;`

								  *[our-host]

								  `&lt;/EXTENSION&gt;`

								  our-host      = `&lt;OUR-HOST xmlns="http://www.w3.org/2006/01/P3Pv11"`

								  [`name="` authority `"`]

								  `/&gt;`

								 </pre>


								<p>Here, <em>authority</em>is defined as per <a

								href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986</a> [URI], with the

								addition that the '*' character is to be treated as a wildcard, as defined in

								<a href="#ref_file_wildcards">section 2.3.2.1.2</a>.</p>


								<p>The <code>OUR-HOST</code>element is declared in the

								<code>POLICY-REF</code> element. For URIs covered by the associated policy,

								the user agent can encounter other hosts in different domains serving

								embedded content, link, or action requests. The user agent may consider such

								a host to be owned by the same entity or one of its agents if its URI matches

								an associated <code>OUR-HOST</code> entry. Any number of

								<code>OUR-HOST</code>elements can be declared inside a

								<code>POLICY-REF</code>element.</p>


								<p>Embedded content is considered to be any content that is retrieved during

								the processing of the current document, such as images, documents in frames,

								script files, etc. Content embedded more than 1 level deep (e.g. an image

								inside a frame) is still considered embedded content and the

								<code>OUR-HOST</code> declarations at the top-level may still apply.</p>


								<p>Any relationships inferred by this mechanism are valid only in the context

								for which they were discovered -- this is not a mechanism for declaring

								globally that two hosts have a relationship in all contexts. By extension,

								the relationships are not transitive. Suppose two distinct hosts A and C are

								matched by <code>OUR-HOST</code> entries in a policy reference file for host

								B. Even if the same policy applies to both, nothing may be inferred about the

								relationship between A and C for use in other contexts. The relationships are

								not transitive even in the case of multi-level embedded content -- the

								top-level host must declare <code>OUR-HOST</code> relationships for all

								levels of embedded content.</p>


								<p>In this example, example.com and example.net are owned by the same

								company. The example.net file has an <code>OUR-HOST</code> declaration for

								hosts in the example.com domain.</p>

								<pre class="sample">&lt;META xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								  &lt;POLICY-REFERENCES&gt;

								    &lt;POLICY-REF about="/p3p/policy.xml#corporate"&gt;

								      &lt;INCLUDE&gt;/*&lt;/INCLUDE&gt;

								        &lt;COOKIE-INCLUDE name="*" value="*"/&gt;

								          <strong>&lt;EXTENSION&gt;</strong>

								            <strong>&lt;OUR-HOST name="*.example.com"

								            xmlns="http://www.w3.org/2006/01/P3Pv11" /&gt;</strong>

								          <strong>&lt;/EXTENSION&gt;</strong>

								    &lt;/POLICY-REF&gt;

								  &lt;/POLICY-REFERENCES&gt;

								&lt;/META&gt;</pre>


								<p>The following example.com policy reference file shows two policies and two

								<code>OUR-HOST</code>declarations. The first declaration is for hosts in the

								example.net domain and applies to all URIs except for ones that begin with

								"/surveys/". The second <code>OUR-HOST</code> declaration is for hosts in the

								example.org domain and applies to all URIs that begin with "/surveys/". Since

								the example.net domain is not declared with this policy reference, user

								agents can not verify a relationship between example.com and example.net

								hosts for the survey URIs.</p>

								<pre class="sample">&lt;META xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								  &lt;POLICY-REFERENCES&gt;

								    &lt;POLICY-REF about="/p3p/policy.xml#corporate"&gt;

								      &lt;INCLUDE&gt;/*&lt;/INCLUDE&gt;

								      &lt;EXCLUDE&gt;/surveys/*&lt;/EXCLUDE&gt;

								        <strong>&lt;EXTENSION&gt;</strong>

								        <strong>&lt;OUR-HOST name="*.example.net"

								        xmlns="http://www.w3.org/2006/01/P3Pv11" /&gt;</strong>

								        <strong>&lt;/EXTENSION&gt;</strong>

								    &lt;/POLICY-REF&gt;

								    &lt;POLICY-REF about="/p3p/policy.xml#surveys"&gt;

								      &lt;INCLUDE&gt;/surveys/*&lt;/INCLUDE&gt;

								        <strong>&lt;EXTENSION&gt;</strong>

								        <strong>&lt;OUR-HOST name="*.example.org"

								        xmlns="http://www.w3.org/2006/01/P3Pv11" /&gt;</strong>

								        <strong>&lt;/EXTENSION&gt;</strong>

								    &lt;/POLICY-REF&gt;

								  &lt;/POLICY-REFERENCES&gt;

								&lt;/META&gt;</pre>


								<p>Browsers may cache the policy reference file based on its EXPIRY element.

								The expiration information associated with that element should also be

								considered to apply to the <code>OUR-HOST</code> declarations; i.e. that

								information may be cached along with the policy reference information.</p>


								<p>The use of the <code>OUR-HOST</code> extension is optional. This extension

								provides more information that user agents may use in applying users' privacy

								preferences.</p>


								<h4 id="playback">2.3.2.9.2 Cookie Playback</h4>


								<p>If a user agent allows a cookie to be set based on a relationship

								established by <code>OUR-HOST</code> declarations, it should verify that such

								a relationship exists at cookie playback time, and not send the cookie if

								not. When not using compact policies, such verification implies re-fetching

								an expired policy reference file and evaluating its <code>OUR-HOST</code>

								declarations.</p>


								<h4 id="oho_cp">2.3.2.9.3 Extension to P3P Compact Policy Header</h4>


								<p>Hosts may return an special token ("OHO:") in the P3P compact policy

								header to indicate <code>OUR-HOST</code> relationships. This token is

								followed by a comma-delimited list of hostname qualifiers that describe hosts

								that are owned by the same entity as the current host or that are acting as

								agents of the current host. This list is equivalent to the

								<code>OUR-HOST</code> declarations in the policy reference file, but it may

								be applied when using compact policies. In the example above, example.com

								could return the header:</p>

								<pre class="sample">  P3P: CP="NON DSP ADM DEV PSD IVDo OUR IND STP PHY PRE NAV UNI OHO:*.example.org"</pre>


								<p>Hosts returning embedded content are not required to declare a

								corresponding <code>OHO</code> token in their compact policies.</p>


								<p>This token is optional and may be ignored by user agents. The syntax for

								the token is as follows:</p>

								<pre>  compact-our-host    = `OHO:` authority *(`,` authority)

								  </pre>


								<p>Here, <code>authority</code>is defined as per <a

								href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986</a> [URI], with the

								addition that the '*' character is to be treated as a wildcard, as defined in

								<a href="#ref_file_wildcards">section 2.3.2.1.2</a>.</p>


								<h3 id="active_content">2.3.3 Applying a Policy to a URI</h3>


								<p>A policy reference file specifies the policy which applies to a given URI.

								In other words, the indicated policy describes all effects of dereferencing

								the given URI (in some cases, with the appropriately specified

								<code>METHOD</code>).</p>


								<p>There is a general rule which describes what it means for a P3P policy to

								cover a URI: <i>the referenced policy MUST cover actions that the user's

								client software is expected to perform as a result of requesting that

								URI</i>. Obviously, the policy must describe all data collection performed by

								site as a result of processing the request for the URI. Thus, if a given URI

								is covered for terms of <code>GET</code> requests, then the policy given by

								the policy reference file MUST describe all data collection performed by the

								site when that URI is dereferenced. Likewise, if a URI is covered for

								<code>POST</code> requests, then any data collection that occurs as a result

								of POSTing a form or other content to that URI MUST be described by the

								policy.</p>


								<p>The concept of "actions that the client software is expected to perform"

								includes the setting of client-side cookies or other state-management

								mechanisms invoked by the response. If executable code is returned when a URI

								is requested, then the P3P policy covering that URI MUST cover certain

								actions which will occur when that code is executed. The covered actions are

								any actions which could take place without the user explicitly invoking them.

								If explicit user action causes data to be collected, then the P3P policy

								covering the URI for that action would disclose that data collection.</p>


								<p>Some specific examples:</p>

								<ol>

								  <li>Fetching a URI returns an HTML page which contains a form, and the form

								    contents are sent to a second URI when the user clicks a "Submit" button.

								    The P3P policy covering the second URI MUST disclose all data collected

								    by the form. The P3P policy covering the first URI (the URI the form was

								    loaded from) MAY or MAY NOT disclose any of the data that will be

								    collected on the form.</li>

								  <li>An HTML page includes JavaScript code which tracks how long the page is

								    displayed and whether the user moved the mouse over a certain object on

								    the page; when the page is unloaded, the JavaScript code sends that

								    information to the server where the HTML page originated. The activity of

								    the JavaScript code MUST be covered by the P3P policy of the HTML page.

								    The reasoning is that this activity takes place without the user's

								    knowledge or consent, and it occurs automatically as a result of loading

								    the page.</li>

								  <li>A resource returns an executable for an electronic mail program. In

								    order to use the email program, the user must run an installation

								    program, start the email program, and use its facilities. The P3P policy

								    covering URI from where the email program was downloaded is not required

								    to make a statement about the data which could be collected by using the

								    email program. Installing and running the email program is clearly

								    outside the Web browsing experience, so it is not covered by this

								    specification. A separate protocol could be designed to allow downloaded

								    applications to present a P3P policy, but this is outside the scope of

								    this specification.</li>

								  <li>An HTML page containing a form includes a reference to an executable

								    which provides a custom client-side control. The data in the control is

								    submitted to a site when the form is submitted. In this case, the URI for

								    the HTML page and the URI for the custom control is not required to make

								    a statement about the data the custom control represents. However, the

								    URI to which the form contents are posted MUST cover the data from the

								    custom control, just as it would cover any other data collected by

								    processing the form. This behavior is similar to the way HTML forms are

								    handled when they use only standard HTML controls: the control itself

								    collects no data, and the data is collected when the form is posted. Note

								    that this example assumes that the form is only posted when the user

								    actively presses a "submit" or similar button. If the form were posted

								    automatically (for example, by some JavaScript code in the page), then

								    this example would be similar to example #2, and the data collected by

								    the form MUST be described in the P3P policy which covers the HTML

								  form.</li>

								  <li>Requests to a URI are redirected to a third party. If the first party

								    embeds previously collected personal data in the query string or other

								    part of the redirect URI, the privacy policy for the first party's URI

								    MUST describe the types of data transmitted and include the third party

								    as a recipient.</li>

								</ol>


								<h3 id="forms">2.3.4 Forms and Related Mechanisms</h3>


								<p>Forms deserve special consideration, as they often link to CGI scripts or

								other server-side applications in their action URIs (the <em>action URI</em>

								is the URI given in the action attribute of the HTML

								<code>&lt;FORM&gt;</code> element, as defined in section 17.3 of [<a

								href="#HTML">HTML</a>]). It is often the case that those action URIs are

								covered by a different policy than the form itself.</p>


								<p>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 <em>no</em> policy is in effect. Under these

								circumstances, user agents SHOULD check the <a

								href="#Well_Known_Location">well-known location</a> 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 <a

								href="#hints"><code>HINT</code> mechanism</a> on the action URI, and/or by

								issuing a <code>HEAD</code> 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

								<code>HEAD</code> requests and return the corresponding policy reference link

								in the headers. In case the underlying application does not understand the

								<code>HEAD</code> request and <em>no</em> policy has been predeclared for the

								action URI in question, user agents MUST assume that <em>no</em> policy is in

								effect and SHOULD inform the user about this or take the corresponding

								actions according to the user's preferences.</p>


								<p>Note that services might want to make use of the

								<code>&lt;METHOD&gt;</code> element in order to declare policies for

								server-side applications that only cover a subset of supported methods, e.g.,

								<code>POST</code> or <code>GET</code>. Under such circumstances, it is

								acceptable that the application in question only supports the methods given

								in the policy reference file (e.g., <code>PUT</code> requests need not be

								supported). User agents SHOULD NOT attempt to issue a <code>HEAD</code>

								request to an action URI if the relevant methods specified in the form's

								<code>method</code> attribute have been properly predeclared in the page's

								policy reference file.</p>


								<p>In some cases, <em>different</em> data is collected at the <em>same</em>

								action URI depending on some selection in the form. For example, a search

								service might offer to both search for people (by name and/or email) and

								(arbitrary) images. Using a set of radio buttons on the form, a single

								server-side application located at one and the same action URI handles both

								cases and collects the required information necessary for the search. If a

								service wants to predeclare the data collection practices of the server-side

								application it MAY declare <em>all</em> of the data collection practices in a

								<em>single</em> policy file (using a <code>&lt;INCLUDE&gt;</code> declaration

								matching the action URI). In this case, user agents MUST assume that all data

								elements are collected under every circumstance. This solution offers the

								convenience of a single policy but might not properly reflect the fact that

								only parts of the listed data elements are collected at a time. Services

								SHOULD make sure that a simple <code>HEAD</code> request to the action URI

								(i.e., without any arguments, especially without the value of the selected

								radio button) will return a policy that covers all cases.</p>


								<p>Note that if a form is handled through use of the <code>GET</code> method,

								then the action URI reflects the choice of form elements selected by the

								user. In some cases, it will be possible to make use of the wildcard syntax

								allowed in policy reference files to specify different policies for different

								uses of the same form action-handler URI. Therefore, user agents MUST include

								the query-string portion of URIs when making comparisons with

								<code>INCLUDE</code> and <code>EXCLUDE</code> elements in policy reference

								files.</p>


								<h2 id="additional_requirements">2.4 Additional Requirements</h2>


								<h3 id="non-ambiguity">2.4.1 Non-ambiguity</h3>


								<p>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. 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, cf. <a href="#referencing_compact_policies">Section

								4.1</a> . 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.</p>


								<p>If a policy reference file at the <a

								href="#Well_Known_Location">well-known location</a> 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.</p>


								<p>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.</p>


								<p>If an HTML (resp. XHTML) file includes HTML (resp. XHTML)

								<code>link</code> tag references to more than one policy reference file, P3P

								user agents MUST ignore all references after the first one.</p>


								<p>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 <code>link</code>

								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.</p>


								<h3 id="multiple">2.4.2 Multiple Languages</h3>


								<p>Multiple language versions (translations) of the same policy can be

								offered by the server using the HTTP "<code>Content-Language</code>" header

								to properly indicate that a particular language has been used for the policy.

								This is useful so that human-readable fields such as entity and consequence

								can be presented in multiple languages. The same mechanism can also be used

								to offer multiple language versions for data schemas. Servers SHOULD return a

								localized policy in response to an HTTP request with an HTTP

								"<code>Accept-Language</code>" header when a policy matching the given

								language preferences is available.</p>


								<p>Whenever <code>Content-Language</code> is used to distinguish policies at

								the same URI that are offered in multiple languages, the policies MUST have

								the same meaning in each language. Two policies (or two data schemas) are

								taken to be identical if</p>

								<ul>

								  <li>All formal (not natural language) protocol elements are semantically

								    identical (e.g., attribute order does not matter, the presence or absence

								    of a default value does not matter, but attribute values matter)</li>

								  <li>All natural language protocol elements correspond one-to-one, and for

								    each correspondence, one is a careful translation of the other.</li>

								</ul>


								<p>Due to the use of the <code>Accept-Language</code> mechanism, implementers

								should take note that user agents may see different language versions of a

								policy or policy reference file despite sending the same

								<code>Accept-Language</code> request header if a new language version of a

								policy or data schema has been added.</p>


								<p>Finally, language declarations can be also included directly within P3P

								XML files: the <code>POLICY</code>, <code>POLICIES</code>, <code>META</code>,

								and <code>DATASCHEMA</code> elements MAY take an <code>xml:lang</code>

								attribute to indicate the language of any human-readable fields they contain

								(<code>xml:lang</code> is normatively defined in section 2.12 of [<a

								href="#XML">XML</a>]).</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[18]</td>

								      <td valign="top"><pre>xml-lang</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>` xml:lang="` language `"`</pre>

								      </td>

								    </tr>

								    <tr>

								      <td colspan="4">Here, <code>language</code> is a language identifier as

								        defined in [<a href="#LANG">LANG</a>].</td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="safezone">2.4.3 The <q>Safe Zone</q></h3>


								<p>P3P defines a special set of "safe zone" practices, which SHOULD be used

								by all P3P-enabled user agents and services for the communications which take

								place as part of fetching a P3P policy or policy reference file. In

								particular, requests to the <a href="#Well_Known_Location">well-known

								location</a> for policy reference files SHOULD be covered by these "safe

								zone" practices. Communications covered by the safe zone practices SHOULD

								have only minimal data collection, and any data that is collected is used

								only in non-identifiable ways.</p>


								<p>To support this safe zone, P3P user agents SHOULD suppress the

								transmission of data unnecessary for the purpose of finding a site's policy

								until the policy has been fetched. Therefore safe-zone practices for user

								agents include the following requirements:</p>

								<ul>

								  <li>User agents SHOULD NOT send the HTTP <code>Referer</code> header in the

								    safe zone</li>

								  <li>User agents SHOULD NOT accept cookies from safe-zone requests</li>

								  <li>User agents MAY also wish to refrain from sending user agent

								    information or cookies accepted in a previous session on safe zone

								    requests</li>

								  <li>User agent implementers need to be aware that there is a privacy

								    trade-off with using the <code>Accept-Language</code> HTTP header in the

								    safe zone. Sending the correct <code>Accept-Language</code> header will

								    allow fetching a P3P policy in the user's preferred natural language (if

								    available), but does expose a certain amount of information about the

								    identity of the user. User agents MAY wish to allow users to decide when

								    these headers should be sent.</li>

								</ul>


								<p>Safe-zone practices for servers include the following requirements:</p>

								<ul>

								  <li>Servers SHOULD NOT require the receipt of an HTTP <code>Referer</code>

								    header, cookies, user agent information, or other information unnecessary

								    for responding to requests in the safe zone</li>

								  <li>If the user agent suppresses the <code>Accept-Language</code> HTTP

								    header as part of safe-zone operation, the server is free to choose any

								    of the available translations</li>

								  <li>If the communications is taking place over a secure connection (such as

								    SSL), then the server SHOULD NOT require an identity certificate from the

								    user agent for safe zone requests</li>

								  <li>In addition, servers SHOULD NOT use in an identifiable way any

								    information collected while serving a safe zone request</li>

								</ul>


								<p>Note that the safe zone requirements do not say that sites cannot keep

								identifiable information -- only that they SHOULD NOT use in an identifiable

								way any information collected while serving a policy file or policy reference

								file. Tracking down the source of a denial of service attack, for example,

								would be a legitimate reason to use this information.</p>


								<h3 id="processing">2.4.4 Policy and Policy Reference File Processing by User

								Agents</h3>


								<p>P3P user agents MUST only render or act upon P3P policies and policy

								reference files that are well-formed XML.</p>


								<p>P3P user agents SHOULD only render or act upon P3P policies and policy

								reference files that conform to the XML schema given in <a

								href="#p3p11_schema">Appendix 5</a>, and user agents SHOULD NOT rely upon

								any part of a policy or policy reference file that does not conform to this

								XML schema.</p>


								<p>User agents MUST NOT locally modify a P3P policy or policy reference file

								in order to make it conform to the XML schema.</p>


								<h3 id="security">2.4.5 Security of Policy Transport</h3>


								<p>P3P policies and references to P3P policies SHOULD NOT contain any

								sensitive information. This means that there are no additional security

								requirements for transporting a reference to a P3P policy beyond the

								requirements of the document it is associated with; so, if an HTML document

								would normally be served over a non-encrypted session, then P3P does

								<strong>not</strong> require nor recommend that the document be served over

								an encrypted session when a reference to a P3P policy is included with that

								document.</p>


								<h3 id="policy_updates">2.4.6 Policy Updates</h3>


								<p>Note that when a Web site changes its P3P policy, the old policy applies

								to data collected when it was in effect. It is the responsibility of the site

								to keep records of past P3P policies and policy reference files along with

								the dates when they were in effect, and to apply these policies

								appropriately.</p>


								<p>If a site wishes to apply a new P3P policy to previously collected data,

								it MUST provide appropriate notice and opportunities for users to accept the

								new policy that are consistent with applicable laws, industry guidelines, or

								other privacy-related agreements the site has made.</p>


								<h3 id="absence_of_prf">2.4.7 Absence of Policy Reference File</h3>


								<p>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.</p>


								<h3 id="asynchronous_evaluation">2.4.8 Asynchronous Evaluation</h3>


								<p>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.</p>


								<h2 id="generic_attribute">2.5. The P3P Generic Attribute for XML

								Applications</h2>


								<p><a href="http://www.w3.org/TR/2002/REC-P3P-20020416/">P3P 1.0</a> was

								designed to associate XML-encoded privacy policies with URIs, sets of URIs,

								or cookies. P3P 1.0 is well suited for use with HTML and XHTML pages

								transmitted over <code>[<a href="#HTTP1_1_ref">HTTP1.1</a>]</code> or

								<code>[<a href="#HTTP1_0_ref">HTTP1.0</a>]</code>. However, P3P 1.0 cannot

								be used in situations where a request is not directed to a URI, for example,

								some applications of <a href="http://www.w3.org/2002/ws/">Web Services</a>

								and <a href="http://www.w3.org/2000/xp/Group/">SOAP</a>. In addition, P3P 1.0

								cannot be used in situations where policies apply to only a subset of the

								content associated with a given URI. For example, while P3P 1.0 can be used

								to apply a P3P policy to an entire form specified by <a

								href="http://www.w3.org/TR/xforms/">XForms</a>, it cannot be used to apply

								the policy to only a single form field.</p>


								<p>The P3P 1.1 Specification provides a new binding mechanism to allow for

								increased granularity beyond the URI level and to allow policies to apply to

								content not associated with a URI. The new mechanism takes the form of a

								generic attribute (similar to <code><a

								href="http://www.w3.org/TR/REC-xml/#sec-lang-tag">xml:lang</a></code>) that

								binds a P3P policy to an XML element.</p>


								<p>A P3P policy referenced by the P3P generic attribute MUST apply to all

								data collection performed as a result of processing the

								<em>element</em>carrying the P3P Generic Attribute. The policy also MUST

								describe all data collection performed as a result of the processing of

								<em>all subelements</em>.</p>


								<p>For all XML applications in which the P3P Generic Attribute is to be used,

								the attribute MUST be imported into the relevant XML schema.</p>


								<p>If the element is re-used by mechanisms such as <a

								href="http://www.w3.org/TR/xinclude/">XInclude</a> or the <a

								href="http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#UseElement">SVG

								&lt;use&gt; Element</a>, the Policy applies also in the new context where the

								element is re-used. The policy is <em>sticky</em> to the element from which

								it is referenced.</p>


								<p>The P3P Generic Attribute is designed for use in XML elements that

								describe <i>interfaces</i>, not XML elements that encode user data. Thus, it

								is meaningful to use the P3P Generic Attribute to associate a P3P policy with

								a blank form or form field. The semantics of such an association are that any

								data entered into the form will be processed in a manner consistent with the

								P3P policy. It is not meaningful to use the P3P Generic Attribute to

								associate a P3P policy with data a user has entered into a form.</p>


								<p>The P3P Generic Attribute MUST NOT be used in applications, such as RDF,

								that do not have a tree structure because its semantics relies on the concept

								of subelements. In the case of RDF, one of the other three binding mechanisms

								described in <a href="#Referencing">2. Referencing Policies</a> may be used,

								as RDF makes use of URIs.</p>


								<p>The P3P generic attribute takes a URI of a valid P3P 1.1 policy as

								its value. If multiple policy elements are contained, a fragment must

								be used to identify the applicable policy.  The P3P generic attribute

								MUST NOT reference a P3P <code>Policy Reference File</code>.</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[19]</td>

								      <td valign="top"><pre>p3pattr</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`p3pattr=`p3p11:p3p="`

								        quoted-URI

								        `"`

								        `xmlns:p3p11="http://www.w3.org/2006/01/P3Pv11" `</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<p>Here is an example of how the P3P attribute might be used with WSDL.</p>

								<pre class="sample">&lt;?xml version="1.0"?&gt;

								&lt;definitions xmlns="http://www.w3.org/2003/11/wsdl"

								  xmlns:myns="http://example.org/myservice"

								  xmlns:mytypes="http://example.org/myservice-types"

								  xmlns:p3p11="http://www.w3.org/2006/01/P3Pv11"

								  xmlns:soap="http://www.w3.org/2003/06/wsdl/soap12"

								  xmlns:xs="http://www.w3.org/2001/XMLSchema"

								  targetNamespace="http://example.org/myservice" &gt;

								  &lt;documentation&gt;

								    Sample service definition showing the use of the P3P generic attribute

								  &lt;/documentation&gt;

								  &lt;types&gt;

								    &lt;xs:import namespave='http://example.org/myservice'/&gt;

								  &lt;/types&gt;

								  &lt;interface name="Interface"&gt;

								    &lt;operation name="Operation"

								      pattern="http://www.w3.org/2003/11/wsdl/in-out"&gt;

								      &lt;input message="mytypes:commentReq"/&gt;

								      &lt;output message="myntypes:commentResp"/&gt;

								    &lt;/operation&gt;

								  &lt;/interface&gt;

								  &lt;binding name="Binding" interface="myns:Interface"&gt;

								    &lt;soap:binding protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"/&gt;

								  &lt;/binding&gt;

								  &lt;service name="Service" interface="myns:Interface"

								      p3p11:p3p="http://example.com/p3p-pol3.xml#pol3" &gt;

								    &lt;endpoint name="Endpoint1" binding="myns:binding"&gt;

								      &lt;soap:address location="http://ws.example.org/myservice" /&gt;

								    &lt;/endpoint&gt;

								  &lt;/service&gt;

								&lt;/definitions&gt;</pre>


								<h2 id="example_scenarios">2.6 Example Scenarios</h2>


								<p>As an aid to sites deploying P3P, several example scenarios are presented,

								along with descriptions of how P3P is used on those sites.</p>


								<p><strong>Scenario 1</strong>: 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.</p>


								<p><strong>Scenario 2</strong>: Web site busy.example.com uses a content

								distribution network called cdn.example.com to host its images so as to

								reduce the load on its servers. Thus, all of the images on the site have URIs

								at cdn.example.com. CDN acts as an agent to Busy in this situation, and

								collects no data other than log data. This log data is used only for Web site

								and system administration in support of providing the services that Busy

								contracted for. Busy's privacy policy applies to the images hosted by CDN, so

								Busy uses the <code>HINT</code> element in its policy reference file to point

								to a suitable policy reference file at CDN, indicating that such images are

								covered by example.com P3P policy.</p>


								<p><strong>Scenario 3</strong>: Web site busy.example.com also has a contract

								with an advertising company called clickads.example.com to provide banner ads

								on its site. The contract allows Clickads to set cookies so as to make sure

								each user does not see a given ad more than three times. Clickads collects

								statistics on how many users view each ad and reports them to the companies

								whose products are being advertised. But these reports do not reveal

								information about any individual users. As was the case in Scenario 2, Busy's

								privacy policies applies to these ads hosted by Clickads, so Busy uses the

								<code>HINT</code> element in its policy reference file to point to a suitable

								policy reference file at Clickads, indicating that Busy P3P policy applies to

								such embedded content served by clickads.example.com. The companies whose

								products are being advertised need not be mentioned in the Busy privacy

								policy because the only data they are receiving is aggregate data.</p>


								<p><strong>Scenario 4</strong>: Web site busy.example.com also has a contract

								with funchat.example.com to host a chat room for its users. When users enter

								the chat room they are actually leaving the Busy site. However, the chat room

								has the Busy logo and is actually covered by the Busy privacy policy. In this

								instance Funchat is acting as an agent for Busy, but -- unlike the previous

								examples -- their content is not embedded in the Busy site. Busy can use the

								<code>HINT</code> element in its policy reference file to point to a suitable

								Funchat policy reference file, that indicates that Funchat chat room is

								covered by Busy privacy policy, therefore facilitating a smoother transition

								to the chat room.</p>


								<p><strong>Scenario 5</strong>: Web site bigsearch.example.com has a form

								that allows users to type in a search query and have it performed on their

								choice of search engines located on other sites. When a user clicks the

								"submit" button, the search query is actually submitted directly to these

								search engines -- the action URI is not on bigsearch.example.com but rather

								on the search engine selected by the user. Bigsearch can declare the privacy

								policies for these search engines by using the <code>HINT</code> element to

								point to their corresponding policy reference files. So when a user clicks

								the "submit" button, their user agent can check its privacy policy before

								posting any data. In order to make this search choice mechanism work,

								Bigsearch might actually have a form with an action URI on its own site,

								which redirects to the appropriate search engine. In this case, the user

								agent should check the search engine privacy policy upon receiving the

								redirect response.</p>


								<p><strong>Scenario 6</strong>: Web site bigsearch.example.com also has a

								form that allows users to type in a search query and have it simultaneously

								performed on ten different search engines. Bigsearch submits the queries,

								gets back the results from each search engine, removes the duplicates, and

								presents the results to the user. In this case, the user interacts only with

								Bigsearch. Thus, the only P3P policy involved is the one that covers the

								Bigsearch Web site. However, Bigsearch must disclose that it shares the

								users' search queries with third parties (the search Web sites), unless

								Bigsearch has a contract with these search engines and they act as agents to

								Bigsearch.</p>


								<p><strong>Scenario 7</strong>: Web site bigsearch.example.com also has

								banner advertisements provided by a company called adnetwork.example.com.

								Adnetwork uses cookies to develop profiles of users across many different Web

								sites so that it can provide them with ads better suited to their interests.

								Because the data about the sites that users are visiting is being used for

								purposes other than just serving ads on the Bigsearch Web site, Adnetwork

								cannot be considered an agent in this context. Adnetwork must create its own

								P3P policy and use its own policy reference file to indicate what content it

								applies to. In addition, Bigsearch may optionally use the <code>HINT</code>

								element in its policy reference file to indicate that the Adnetwork P3P

								policy reference file applies to these advertisements. Bigsearch should only

								do this if Adnetwork has told it what P3P policy applies to these

								advertisements and has agreed to notify Bigsearch if the policy reference

								needs to be changed.</p>


								<p><strong>Scenario 8:</strong> Web site busy.example.com uses cookies

								throughout its Web site. It discloses a cookie policy, separate from its

								regular P3P policy to cover these cookies. It uses the

								<code>COOKIE-INCLUDE</code> element in its policy reference file to declare

								the appropriate policy for these cookies. As a performance optimization, it

								also makes available a compact policy by sending a P3P header that includes

								this compact policy whenever it sets a cookie.</p>


								<p><strong>Scenario 9:</strong> Web site config.example.com provides a

								service in which they optimize various kinds of Web content based on each

								user's computer and Internet configuration. Users go to the Config Web site

								and answer questions about their computer, monitor, and Internet connection.

								Config encodes the responses and stores them in a cookie. Later, when the

								user is visiting Busy -- a Web site that has contracted with Config --

								whenever the browser requests content that can be optimized (certain images,

								audio files, etc.), Busy will redirect the user to Config, which will read

								the user's cookie, and deliver the appropriate content. In this case, Config

								should declare a privacy policy that describes the kinds of data collected

								and stored in its cookies, and how that data is used. It should use a

								<code>COOKIE-INCLUDE</code> element in its policy reference file to declare

								the policy for the cookies. It will probably reference Busy's P3P policy for

								the actual images or audio files delivered, as it is acting much like CDN

								acts in scenario 2. Busy will probably also use <code>HINT</code> elements in

								its policy reference file to reference the policy for the Config-delivered

								content.</p>

								</div>


								<div id="P3P_markup">

								<h1>3. Policy Syntax and Semantics</h1>


								<p>P3P policies are encoded in XML with namespaces (see [<a

								href="#XML">XML</a>] and [<a href="#XML-Name">XML-Name</a>]). A possible

								encoding using the RDF data model ([<a href="#RDF">RDF</a>]) is provided in

								[<a href="#P3P-RDF">P3P-RDF</a>].</p>


								<p>Section 3.1 begins with an example of an English language privacy policy

								and a corresponding P3P policy. P3P policies include general assertions that

								apply to the entire policy as well as specific assertions -- called

								<em>statements</em> -- that apply only to the handling of particular types of

								data referred to by <em>data references</em>. Section 3.2 describes the

								<code>POLICY</code> element and policy-level assertions. Section 3.3

								describes statements and data references.</p>


								<h2 id="Example_policy">3.1 Example policies</h2>


								<h3 id="English">3.1.1 English language policies</h3>


								<p>The following are two examples of English-language privacy policy to be

								encoded as a P3P policy. Both policies are for one example company,

								CatalogExample, which has different policies for those browsing their site

								and those actually purchasing products. Example 3.1. is provided in both

								English and as a more formal description using P3P element and attribute

								names.</p>

								<dl>

								  <dt><strong>Example 3.1: CatalogExample's Privacy Policy for

								  Browsers</strong></dt>

								    <dd>At CatalogExample, we care about your privacy. When you come to our

								      site to look for an item, we will only use this information to improve

								      our site and will not store it with information we could use to

								      identify you.<br />

								      <br />

								      CatalogExample, Inc. is a licensee of the PrivacySealExample Program.

								      The PrivacySealExample Program ensures your privacy by holding Web site

								      licensees to high privacy standards and confirming with independent

								      auditors that these information practices are being followed.<br />

								      <br />

								      Questions regarding this statement should be directed to:<br />

								      <code>CatalogExample<br />

								      4000 Lincoln Ave.<br />

								      Birmingham, MI 48009 USA<br />

								      email: catalog@example.com<br />

								      Telephone 248-EXAMPLE (248-392-6753)</code><br />

								      <br />

								      If we have not responded to your inquiry or your inquiry has not been

								      satisfactorily addressed, you can contact PrivacySealExample at

								      http://www.privacyseal.example.org. CatalogExample will correct all

								      errors or wrongful actions arising in connection with the privacy

								      policy.<br />

								      <br />

								      <em>What We Collect and Why:</em><br />

								      When you browse through our site we collect:

								      <ul>

								        <li>the basic information about your computer and connection to make

								          sure that we can get you the proper information and for security

								          purposes.</li>

								        <li>aggregate information on what pages consumers access or visit to

								          improve our site.</li>

								      </ul>

								      <p><em>Data retention:</em><br />

								      We purge every two weeks the browsing information that we collect.</p>

								    </dd>

								</dl>


								<p>Here is Example 3.1 in a more formal description, using the P3P element

								and attribute names [with the section of the spec that was used cited in

								brackets for easy reference]:</p>

								<ul>

								  <li>Disclosure URI:

								    http://www.catalog.example.com/PrivacyPracticeBrowsing.html<br />

								    [<a href="#POLICY">3.2.2 Policy</a>]</li>

								  <li>Entity: CatalogExample<br />

								    4000 Lincoln Ave.<br />

								    Birmingham, MI 48009<br />

								    USA<br />

								    catalog@example.com<br />

								    +1 (248) 392-6753<br />

								    [<a href="#ENTITY">3.2.5 Entity</a>]</li>

								  <li>Access to Identifiable Information: None<br />

								    [<a href="#ACCESS">3.2.6 Access</a>]</li>

								  <li>Disputes:<br />

								    resolution type: independent<br />

								    service: http://www.privacyseal.example.org<br />

								    description: PrivacySealExample<br />

								    [<a href="#DISPUTES">3.2.7 Disputes</a>]</li>

								  <li>Remedies: we'll correct any harm done wrong<br />

								    [<a href="#REMEDIES">3.2.8 Remedies</a>]</li>

								  <li>We collect:<br />

								    dynamic.clickstream<br />

								    dynamic.http<br />

								    [<a href="#base_data_structure">5.5 Base data schema</a>]</li>

								  <li>For purpose: Web site and system administration, research and

								    development<br />

								    [<a href="#PURPOSE">3.3.5 Purpose</a>]</li>

								  <li>Recipients: Only ourselves and our agents<br />

								    [<a href="#RECPNT">3.3.6 Recipients</a>]</li>

								  <li>Retention: As long as appropriate for the stated purposes<br />

								    [<a href="#RETENTION">3.3.7 Retention</a>]<br />

								    (Note also that the site's human-readable privacy policy MUST mention

								    that data is purged every two weeks, or provide a link to this

								    information.)</li>

								</ul>

								<dl>

								  <dt><strong>Example 3.2: CatalogExample's Privacy Policy for

								  Shoppers</strong></dt>

								    <dd>At CatalogExample, we care about your privacy. We will never share

								      your credit card number or any other financial information with any

								      third party. With your permission only, we will share information with

								      carefully selected marketing partners that meet either the preferences

								      that you've specifically provided or your past purchasing habits. The

								      more we and know about your likes and dislikes, the better we can

								      tailor offerings to your needs.<br />

								      <br />

								      CatalogExample is a licensee of the PrivacySealExample Program. The

								      PrivacySealExample Program ensures your privacy by holding Web site

								      licensees to high privacy standards and confirming with independent

								      auditors that these information practices are being followed.<br />

								      <br />

								      Questions regarding this statement should be directed to:<br />

								      <code>CatalogExample<br />

								      4000 Lincoln Ave.<br />

								      Birmingham, MI 48009 USA<br />

								      email: catalog@example.com<br />

								      Telephone +1 248-EXAMPLE (+1 248-392-6753)</code><br />

								      <br />

								      If we have not responded to your inquiry or your inquiry has not been

								      satisfactorily addressed, you can contact PrivacySealExample -

								      http://privacyseal.example.org/privacyseal. CatalogExample will correct

								      all errors or wrongful actions arising in connection with the privacy

								      policy.<br />

								      <br />

								      When you browse through our site we collect:

								      <ul>

								        <li>the basic information about your computer and connection to make

								          sure that we can get you the proper information and for security

								          purposes; and</li>

								        <li>aggregate information on what pages consumers access or visit to

								          improve our site</li>

								      </ul>

								      <p><br />

								      If you choose to purchase an item we will ask you for more information

								      including:</p>

								      <ul>

								        <li>your name and address so that we can have your purchase delivered

								          to you and so we can contact you in the future;</li>

								        <li>your email address and telephone number so we can contact

								        you;</li>

								        <li>a login and password to use to update your information at any

								          time in the future; and</li>

								        <li>financial information to complete your purchase (you may choose

								          to store this for future use)</li>

								        <li>optionally, you can enter other demographic information so that

								          we can tailor services to you in the future.</li>

								      </ul>

								      <p><br />

								      Also on this page we will give you the option to choose if you would

								      like to receive email, telephone calls or written service from

								      CatalogExample or from our carefully selected marketing partners who

								      maintain similar privacy practices. If you would like to receive these

								      solicitations simply check the appropriate boxes. You can choose to

								      stop participating at any time simply by changing your preferences.<br

								      />

								      <br />

								      <em>Changing and Updating personal information</em><br />

								      Consumers can change all of their personal account information by going

								      to the preferences section of CatalogExample at

								      http://catalog.example.com/preferences.html. You can change your

								      address, telephone number, email address, password as well as your

								      privacy settings.<br />

								      <br />

								      <em>Cookies</em><br />

								      CatalogExample uses cookies only to see if you have been an

								      CatalogExample customer in the past and, if so, customize services

								      based on your past browsing habits and purchases. We do not store any

								      personal data in the cookie nor do we share or sell the any of the

								      information with other parties or affiliates.<br />

								      <br />

								      <em><a name="retention_secondexample" id="retention_secondexample">Data

								      retention</a></em><br />

								      We will keep the information about you and your purchases for as long

								      as you remain our customer. If you do not place an order from us for

								      one year we will remove your information from our databases.</p>

								    </dd>

								</dl>


								<h3 id="encoding">3.1.2 <a href="#XML">XML</a> encoding of policies</h3>


								<p>The following pieces of [<a href="#XML">XML</a>] capture the information

								as expressed in the above two examples. P3P policies are statements that are

								properly expressed as well-formed <a href="#XML">XML</a>. The policy syntax

								will be explained in more detail in the sections that follow.</p>


								<p><strong>XML Encoding of Example 3.1</strong>:</p>

								<pre class="sample">

								&lt;POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1"

								          xmlns:p3p11="http://www.w3.org/2006/01/P3Pv11"&gt;

								  &lt;POLICY name="forBrowsers"

								    discuri="http://www.catalog.example.com/PrivacyPracticeBrowsing.html"

								    xml:lang="en"&gt;

								    &lt;ENTITY&gt;

								      &lt;EXTENSION&gt;

								        &lt;p3p11:data-group&gt;

								          &lt;p3p11:datatype&gt;

								            &lt;p3p11:business&gt;

								               &lt;p3p11:orgname&gt;CatalogExample&lt;/p3p11:orgname&gt;

								              &lt;p3p11:contact-info&gt;

								                &lt;p3p11:postal&gt;

								                   &lt;p3p11:street&gt;4000 Lincoln Ave.&lt;/p3p11:street&gt;

								                   &lt;p3p11:city&gt;Birmingham&lt;/p3p11:city&gt;

								                   &lt;p3p11:state&gt;MI&lt;/p3p11:state&gt;

								                   &lt;p3p11:postalcode&gt;48009&lt;/p3p11:postalcode&gt;

								                   &lt;p3p11:country&gt;USA&lt;/p3p11:country&gt;

								                &lt;/p3p11:postal&gt;

								                &lt;p3p11:online&gt;

								                   &lt;p3p11:email&gt;catalog@example.co.uk&lt;/p3p11:email&gt;

								                &lt;/p3p11:online&gt;

								                &lt;p3p11:telecom&gt;

								                  &lt;p3p11:telephone&gt;

								                     &lt;p3p11:intcode&gt;1&lt;/p3p11:intcode&gt;

								                     &lt;p3p11:loccode&gt;248&lt;/p3p11:loccode&gt;

								                     &lt;p3p11:number&gt;3926753&lt;/p3p11:number&gt;

								                  &lt;/p3p11:telephone&gt;

								                &lt;/p3p11:telecom&gt;

								              &lt;/p3p11:contact-info&gt;

								            &lt;/p3p11:business&gt;

								          &lt;/p3p11:datatype&gt;

								        &lt;/p3p11:data-group&gt;

								      &lt;/EXTENSION&gt;

								      &lt;DATA-GROUP&gt;

								        &lt;DATA ref="#business.name"&gt;CatalogExample&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.postal.street"&gt;4000 Lincoln Ave.&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.postal.city"&gt;Birmingham&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.postal.stateprov"&gt;MI&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.postal.postalcode"&gt;48009&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.postal.country"&gt;USA&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.online.email"&gt;catalog@example.com&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.telecom.telephone.intcode"&gt;1&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.telecom.telephone.loccode"&gt;248&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.telecom.telephone.number"&gt;3926753&lt;/DATA&gt;

								      &lt;/DATA-GROUP&gt;

								    &lt;/ENTITY&gt;

								  &lt;ACCESS&gt;&lt;nonident/&gt;&lt;/ACCESS&gt;

								  &lt;DISPUTES-GROUP&gt;

								    &lt;DISPUTES resolution-type="independent"

								     service="http://www.PrivacySeal.example.org"

								     short-description="PrivacySeal.example.org"&gt;

								      &lt;IMG src="http://www.PrivacySeal.example.org/Logo.gif" alt="PrivacySeal's logo"/&gt;

								      &lt;REMEDIES&gt;

								        &lt;correct/&gt;

								      &lt;/REMEDIES&gt;

								    &lt;/DISPUTES&gt;

								  &lt;/DISPUTES-GROUP&gt;

								  &lt;STATEMENT&gt;

								    &lt;PURPOSE&gt;

								      &lt;admin/&gt;

								      &lt;develop/&gt;

								    &lt;/PURPOSE&gt;

								    &lt;RECIPIENT&gt;

								      &lt;ours/&gt;

								    &lt;/RECIPIENT&gt;

								    &lt;RETENTION&gt;

								      &lt;stated-purpose/&gt;

								      &lt;/RETENTION&gt;

								      &lt;!-- Note also that the site's human-readable

								      privacy policy MUST mention that data

								      is purged every two weeks, or provide a

								      link to this information. --&gt;

								    &lt;EXTENSION&gt;

								      &lt;p3p11:data-group&gt;

								        &lt;p3p11:datatype&gt;

								          &lt;p3p11:dynamic&gt;

								            &lt;p3p11:clickstream/&gt;

								            &lt;p3p11:http/&gt;

								          &lt;/p3p11:dynamic&gt;

								        &lt;/p3p11:datatype&gt;

								      &lt;/p3p11:data-group&gt;

								    &lt;/EXTENSION&gt;

								    &lt;DATA-GROUP&gt;

								      &lt;DATA ref="#dynamic.clickstream"/&gt;

								      &lt;DATA ref="#dynamic.http"/&gt;

								     &lt;/DATA-GROUP&gt;

								   &lt;/STATEMENT&gt;

								  &lt;/POLICY&gt;

								&lt;/POLICIES&gt;</pre>


								<p><strong>XML Encoding of Example 3.2:</strong></p>

								<pre class="sample">

								&lt;POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1"

								           xmlns:p3p11="http://www.w3.org/2006/01/P3Pv11"&gt;

								  &lt;POLICY name="forShoppers"

								   discuri="http://www.catalog.example.com/Privacy/PrivacyPracticeShopping.html"

								   opturi="http://catalog.example.com/preferences.html"

								   xml:lang="en"&gt;

								    &lt;ENTITY&gt;

								      &lt;EXTENSION&gt;

								        &lt;p3p11:data-group&gt;

								          &lt;p3p11:datatype&gt;

								            &lt;p3p11:business&gt;

								              &lt;p3p11:orgname&gt;CatalogExample&lt;/p3p11:orgname&gt;

								              &lt;p3p11:contact-info&gt;

								                &lt;p3p11:postal&gt;

								                  &lt;p3p11:street&gt;4000 Lincoln Ave.&lt;/p3p11:street&gt;

								                  &lt;p3p11:city&gt;Birmingham&lt;/p3p11:city&gt;

								                  &lt;p3p11:state&gt;MI&lt;/p3p11:state&gt;

								                  &lt;p3p11:postalcode&gt;48009&lt;/p3p11:postalcode&gt;

								                  &lt;p3p11:country&gt;USA&lt;/p3p11:country&gt;

								                &lt;/p3p11:postal&gt;

								                &lt;p3p11:online&gt;

								                  &lt;p3p11:email&gt;catalog@example.co.uk&lt;/p3p11:email&gt;

								                &lt;/p3p11:online&gt;

								                &lt;p3p11:telecom&gt;

								                  &lt;p3p11:telephone&gt;

								                    &lt;p3p11:intcode&gt;1&lt;/p3p11:intcode&gt;

								                    &lt;p3p11:loccode&gt;248&lt;/p3p11:loccode&gt;

								                    &lt;p3p11:number&gt;3926753&lt;/p3p11:number&gt;

								                  &lt;/p3p11:telephone&gt;

								                &lt;/p3p11:telecom&gt;

								              &lt;/p3p11:contact-info&gt;

								            &lt;/p3p11:business&gt;

								          &lt;/p3p11:datatype&gt;

								        &lt;/p3p11:data-group&gt;

								      &lt;/EXTENSION&gt;

								      &lt;DATA-GROUP&gt;

								        &lt;DATA ref="#business.name"&gt;CatalogExample&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.postal.street"&gt;4000 Lincoln Ave.&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.postal.city"&gt;Birmingham&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.postal.stateprov"&gt;MI&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.postal.postalcode"&gt;48009&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.postal.country"&gt;USA&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.online.email"&gt;catalog@example.com&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.telecom.telephone.intcode"&gt;1&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.telecom.telephone.loccode"&gt;248&lt;/DATA&gt;

								        &lt;DATA ref="#business.contact-info.telecom.telephone.number"&gt;3926753&lt;/DATA&gt;

								      &lt;/DATA-GROUP&gt;

								    &lt;/ENTITY&gt;

								    &lt;ACCESS&gt;&lt;contact-and-other/&gt;&lt;/ACCESS&gt;

								    &lt;DISPUTES-GROUP&gt;

								      &lt;DISPUTES resolution-type="independent"

								       service="http://www.PrivacySeal.example.org"

								       short-description="PrivacySeal.example.org"&gt;

								        &lt;IMG src="http://www.PrivacySeal.example.org/Logo.gif" alt="PrivacySeal's logo"/&gt;

								        &lt;REMEDIES&gt;&lt;correct/&gt;&lt;/REMEDIES&gt;

								      &lt;/DISPUTES&gt;

								    &lt;/DISPUTES-GROUP&gt;

								    &lt;STATEMENT&gt;

								      &lt;CONSEQUENCE&gt;

								       We record some information in order to serve your request

								       and to secure and improve our Web site.

								      &lt;/CONSEQUENCE&gt;

								      &lt;PURPOSE&gt;&lt;admin/&gt;&lt;develop/&gt;&lt;/PURPOSE&gt;

								      &lt;RECIPIENT&gt;&lt;ours/&gt;&lt;/RECIPIENT&gt;

								      &lt;RETENTION&gt;&lt;stated-purpose/&gt;&lt;/RETENTION&gt;

								      &lt;DATA-GROUP&gt;

								        &lt;EXTENSION&gt;

								          &lt;p3p11:data-group&gt;

								            &lt;p3p11:datatype&gt;

								              &lt;p3p11:dynamic&gt;

								                &lt;p3p11:clickstream/&gt;

								                &lt;p3p11:http&gt;

								                  &lt;p3p11:useragent/&gt;

								                &lt;/p3p11:http&gt;

								              &lt;/p3p11:dynamic&gt;

								            &lt;/p3p11:datatype&gt;

								          &lt;/p3p11:data-group&gt;

								        &lt;/EXTENSION&gt;

								        &lt;DATA ref="#dynamic.clickstream"/&gt;

								        &lt;DATA ref="#dynamic.http.useragent"/&gt;

								      &lt;/DATA-GROUP&gt;

								    &lt;/STATEMENT&gt;

								    &lt;STATEMENT&gt;

								      &lt;CONSEQUENCE&gt;

								        We use this information when you make a purchase.

								      &lt;/CONSEQUENCE&gt;

								      &lt;PURPOSE&gt;&lt;current/&gt;&lt;/PURPOSE&gt;

								      &lt;RECIPIENT&gt;&lt;ours/&gt;&lt;/RECIPIENT&gt;

								      &lt;RETENTION&gt;&lt;stated-purpose/&gt;&lt;/RETENTION&gt;

								      &lt;EXTENSION&gt;

								        &lt;p3p11:data-group&gt;

								          &lt;p3p11:datatype&gt;

								            &lt;p3p11:user&gt;

								              &lt;p3p11:name/&gt;

								              &lt;p3p11:home-info&gt;

								                &lt;p3p11:postal/&gt;

								                &lt;p3p11:telecom&gt;

								                  &lt;p3p11:telephone/&gt;

								                &lt;/p3p11:telecom&gt;

								                &lt;p3p11:online&gt;

								                  &lt;p3p11:email/&gt;

								                &lt;/p3p11:online&gt;

								              &lt;/p3p11:home-info&gt;

								              &lt;p3p11:business-info&gt;

								                &lt;p3p11:postal/&gt;

								                &lt;p3p11:telecom&gt;

								                  &lt;p3p11:telephone/&gt;

								                &lt;/p3p11:telecom&gt;

								              &lt;/p3p11:business-info&gt;

								              &lt;p3p11:login&gt;

								                &lt;p3p11:id/&gt;

								                &lt;p3p11:password/&gt;

								              &lt;/p3p11:login&gt;

								            &lt;/p3p11:user&gt;

								            &lt;p3p11:dynamic&gt;

								              &lt;p3p11:miscdata&gt;

								                &lt;p3p11:category&gt;

								                  &lt;p3p11:purchase/&gt;

								                &lt;/p3p11:category&gt;

								              &lt;/p3p11:miscdata&gt;

								            &lt;/p3p11:dynamic&gt;

								          &lt;/p3p11:datatype&gt;

								        &lt;/p3p11:data-group&gt;

								      &lt;/EXTENSION&gt;

								      &lt;DATA-GROUP&gt;

								        &lt;DATA ref="#user.name"/&gt;

								        &lt;DATA ref="#user.home-info.postal"/&gt;

								        &lt;DATA ref="#user.home-info.telecom.telephone"/&gt;

								        &lt;DATA ref="#user.business-info.postal"/&gt;

								        &lt;DATA ref="#user.business-info.telecom.telephone"/&gt;

								        &lt;DATA ref="#user.home-info.online.email"/&gt;

								        &lt;DATA ref="#user.login.id"/&gt;

								        &lt;DATA ref="#user.login.password"/&gt;

								        &lt;DATA ref="#dynamic.miscdata"&gt;

								          &lt;CATEGORIES&gt;

								            &lt;purchase/&gt;

								          &lt;/CATEGORIES&gt;

								        &lt;/DATA&gt;

								      &lt;/DATA-GROUP&gt;

								    &lt;/STATEMENT&gt;

								    &lt;STATEMENT&gt;

								      &lt;CONSEQUENCE&gt;

								       At your request, we will send you carefully selected marketing

								       solicitations that we think you will be interested in.

								      &lt;/CONSEQUENCE&gt;

								      &lt;PURPOSE&gt;

								        &lt;contact required="opt-in"/&gt;

								        &lt;individual-decision required="opt-in"/&gt;

								        &lt;tailoring required="opt-in"/&gt;

								      &lt;/PURPOSE&gt;

								      &lt;RECIPIENT&gt;&lt;ours/&gt;&lt;same required="opt-in"/&gt;&lt;/RECIPIENT&gt;

								      &lt;RETENTION&gt;&lt;stated-purpose/&gt;&lt;/RETENTION&gt;

								      &lt;EXTENSION&gt;

								        &lt;p3p11:data-group&gt;

								          &lt;p3p11:datatype&gt;

								            &lt;p3p11:user&gt;

								              &lt;p3p11:name/&gt;

								              &lt;p3p11:home-info&gt;

								                &lt;p3p11:postal/&gt;

								                &lt;p3p11:telecom&gt;

								                  &lt;p3p11:telephone/&gt;

								                &lt;/p3p11:telecom&gt;

								                &lt;p3p11:online&gt;

								                  &lt;p3p11:email/&gt;

								                &lt;/p3p11:online&gt;

								              &lt;/p3p11:home-info&gt;

								              &lt;p3p11:business-info&gt;

								                &lt;p3p11:postal/&gt;

								                &lt;p3p11:telecom&gt;

								                  &lt;p3p11:telephone/&gt;

								                &lt;/p3p11:telecom&gt;

								              &lt;/p3p11:business-info&gt;

								            &lt;/p3p11:user&gt;

								          &lt;/p3p11:datatype&gt;

								        &lt;/p3p11:data-group&gt;

								      &lt;/EXTENSION&gt;

								      &lt;DATA-GROUP&gt;

								        &lt;DATA ref="#user.name" optional="yes"/&gt;

								        &lt;DATA ref="#user.home-info.postal" optional="yes"/&gt;

								        &lt;DATA ref="#user.home-info.telecom.telephone" optional="yes"/&gt;

								        &lt;DATA ref="#user.business-info.postal" optional="yes"/&gt;

								        &lt;DATA ref="#user.business-info.telecom.telephone" optional="yes"/&gt;

								        &lt;DATA ref="#user.home-info.online.email" optional="yes"/&gt;

								      &lt;/DATA-GROUP&gt;

								    &lt;/STATEMENT&gt;

								    &lt;STATEMENT&gt;

								      &lt;CONSEQUENCE&gt;

								       We allow you to set a password so that you

								       can access your own information.

								      &lt;/CONSEQUENCE&gt;

								      &lt;PURPOSE&gt;&lt;individual-decision required="opt-in"/&gt;&lt;/PURPOSE&gt;

								      &lt;RECIPIENT&gt;&lt;ours/&gt;&lt;/RECIPIENT&gt;

								      &lt;RETENTION&gt;&lt;stated-purpose/&gt;&lt;/RETENTION&gt;

								      &lt;EXTENSION&gt;

								        &lt;p3p11:data-group&gt;

								          &lt;p3p11:datatype&gt;

								            &lt;p3p11:user&gt;

								              &lt;p3p11:login&gt;

								                &lt;p3p11:id/&gt;

								                &lt;p3p11:password&gt;

								                  &lt;CATEGORIES&gt;

								                    &lt;uniqueid /&gt;

								                  &lt;/CATEGORIES&gt;

								                &lt;/p3p11:password&gt;

								              &lt;/p3p11:login&gt;

								            &lt;/p3p11:user&gt;

								          &lt;/p3p11:datatype&gt;

								        &lt;/p3p11:data-group&gt;

								      &lt;/EXTENSION&gt;

								      &lt;DATA-GROUP&gt;

								        &lt;DATA ref="#user.login.id"/&gt;

								        &lt;DATA ref="#user.login.password"&gt;

								          &lt;CATEGORIES&gt;

								            &lt;uniqueid/&gt;

								          &lt;/CATEGORIES&gt;

								        &lt;/DATA&gt;

								      &lt;/DATA-GROUP&gt;

								    &lt;/STATEMENT&gt;

								    &lt;STATEMENT&gt;

								      &lt;CONSEQUENCE&gt;

								       At your request, we will tailor our site and

								       highlight products related to your interests.

								      &lt;/CONSEQUENCE&gt;

								      &lt;PURPOSE&gt;

								        &lt;pseudo-decision required="opt-in"/&gt;

								        &lt;tailoring required="opt-in"/&gt;

								      &lt;/PURPOSE&gt;

								      &lt;RECIPIENT&gt;

								        &lt;ours/&gt;

								      &lt;/RECIPIENT&gt;

								      &lt;RETENTION&gt;

								        &lt;stated-purpose/&gt;

								      &lt;/RETENTION&gt;

								      &lt;DATA-GROUP&gt;

								        &lt;EXTENSION&gt;

								          &lt;p3p11:data-group&gt;

								            &lt;p3p11:datatype optional="yes"&gt;

								              &lt;p3p11:user&gt;

								                &lt;p3p11:bdate&gt;

								                  &lt;p3p11:ymd&gt;

								                    &lt;p3p11:year/&gt;

								                  &lt;/p3p11:ymd&gt;

								                &lt;/p3p11:bdate&gt;

								                &lt;p3p11:gender&gt;

								                &lt;/p3p11:gender&gt;

								              &lt;/p3p11:user&gt;

								            &lt;/p3p11:datatype&gt;

								          &lt;/p3p11:data-group&gt;

								        &lt;/EXTENSION&gt;

								        &lt;DATA ref="#user.bdate.ymd.year" optional="yes"/&gt;

								        &lt;DATA ref="#user.gender" optional="yes"/&gt;

								      &lt;/DATA-GROUP&gt;

								    &lt;/STATEMENT&gt;

								    &lt;STATEMENT&gt;

								      &lt;CONSEQUENCE&gt;

								       We tailor our site based on your past visits.

								      &lt;/CONSEQUENCE&gt;

								      &lt;PURPOSE&gt;

								        &lt;tailoring/&gt;

								        &lt;develop/&gt;

								      &lt;/PURPOSE&gt;

								      &lt;RECIPIENT&gt;

								        &lt;ours/&gt;

								      &lt;/RECIPIENT&gt;

								      &lt;RETENTION&gt;

								        &lt;stated-purpose/&gt;

								      &lt;/RETENTION&gt;

								      &lt;EXTENSION&gt;

								        &lt;p3p11:data-group&gt;

								          &lt;p3p11:datatype&gt;

								            &lt;p3p11:dynamic&gt;

								              &lt;p3p11:cookies&gt;

								                &lt;CATEGORIES&gt;

								                  &lt;state /&gt;

								                &lt;/CATEGORIES&gt;

								              &lt;p3p11:/cookies&gt;

								              &lt;p3p11:miscdata&gt;

								                &lt;CATEGORIES&gt;

								                  &lt;preference /&gt;

								                &lt;/CATEGORIES&gt;

								              &lt;/p3p11:miscdata&gt;

								            &lt;/p3p11:dynamic&gt;

								          &lt;/p3p11:datatype&gt;

								        &lt;/p3p11:data-group&gt;

								      &lt;/EXTENSION&gt;

								      &lt;DATA-GROUP&gt;

								        &lt;DATA ref="#dynamic.cookies"&gt;

								          &lt;CATEGORIES&gt;

								            &lt;state/&gt;

								          &lt;/CATEGORIES&gt;

								        &lt;/DATA&gt;

								        &lt;DATA ref="#dynamic.miscdata"&gt;

								          &lt;CATEGORIES&gt;

								            &lt;preference/&gt;

								          &lt;/CATEGORIES&gt;

								        &lt;/DATA&gt;

								      &lt;/DATA-GROUP&gt;

								    &lt;/STATEMENT&gt;

								  &lt;/POLICY&gt;

								&lt;/POLICIES&gt;</pre>


								<h2 id="Policies">3.2 Policies</h2>


								<p>This section defines the syntax and semantics of P3P policies. All

								policies MUST be encoded using [<a href="#UTF-8">UTF-8</a>].</p>


								<p>In cases where the P3P vocabulary is not precise enough to describe a Web

								site's practices, sites should use the vocabulary terms that most closely

								match their practices and provide further explanation in the

								<code>CONSEQUENCE</code> field and/or their human-readable policy. However,

								policies MUST NOT make false or misleading statements.</p>


								<p>Policies have to be placed inside a <code>POLICIES</code> element.</p>


								<h3 id="POLICIES">3.2.1  The

								<code><strong>POLICIES</strong></code> element</h3>


								<p>The <code>POLICIES</code> element gathers one or more P3P policies

								together in a single file. This is provided as a performance optimization:

								many policies can be collected with a single request, improving network

								traffic and caching.</p>


								<p>A <code>POLICIES</code> element is the root element of policy files.

								Further, the <code>POLICIES</code> element can be put within the policy

								reference file, inside the <code>META</code> element:: in this case, user

								agents need only fetch a single file, containing both the policy reference

								file and the policies.</p>


								<p>The <code>POLICIES</code> element can optionally contain an

								<code>xml:lang</code> attribute (see <a href="#multiple">section 2.4.2</a>),

								an <code><a href="#the_expiry_element">EXPIRY</a></code> element, indicating

								the expiration of the included policies, and an embedded data schema using

								the <code><a href="#Data_Schemas">DATASCHEMA</a></code> element (see <a

								href="#Data_Schemas">Section 5</a>).</p>


								<p>Since policies are included in a <code>POLICIES</code> element, each MUST

								have a <code>name</code> attribute which is unique in the file. This allows

								policy references (in <code>POLICY-REF</code> elements) to link to that

								policy.</p>


								<p><strong>Example 3.3:</strong></p>


								<p>The file in <code>http://www.example.com/Shop/policies.xml</code> could

								have the following content:</p>

								<pre class="sample">&lt;POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								   &lt;POLICY name="policy1" discuri="http://www.example.com/disc1"&gt; .... &lt;/POLICY&gt;

								   &lt;POLICY name="policy2" discuri="http://www.example.com/disc2"&gt; .... &lt;/POLICY&gt;

								   &lt;POLICY name="policy3" discuri="http://www.example.com/disc3"&gt; .... &lt;/POLICY&gt;

								&lt;/POLICIES&gt;</pre>


								<p>The files in <code>http://www.example.com/Shop/CDs/*</code> could then be

								associated to the second policy ("<code>policy2</code>") using the following

								policy reference file in <code>http://www.example.com/w3c/p3p.xml</code> :</p>

								<pre class="sample">&lt;META xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								  &lt;POLICY-REFERENCES&gt;

								    &lt;POLICY-REF about="/Shop/policies#policy2"&gt;

								      &lt;INCLUDE&gt;/Shops/CDs/*&lt;/INCLUDE&gt;

								    &lt;/POLICY-REF&gt;

								  &lt;/POLICY-REFERENCES&gt;

								&lt;/META&gt;</pre>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[20]</td>

								      <td valign="top"><pre>policies</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`&lt;POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1"` [xml-lang] `&gt;`

								[expiry]

								[dataschema]

								*policy

								"&lt;/POLICIES&gt;"</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="POLICY">3.2.2 The <strong><code>POLICY</code></strong> element</h3>


								<p>The <code>POLICY</code> element contains a complete P3P policy. Each P3P

								policy MUST contain exactly one <code>POLICY</code> element. The policy

								element MUST contain an <code>ENTITY</code> element that identifies the legal

								entity making the representation of the privacy practices contained in the

								policy. In addition, the policy element MUST contain an <code>ACCESS</code>

								element and one or more <code>STATEMENT</code> elements.It SHOULD

								contain a <code>DISPUTES-GROUP</code> element. It may contain a <a

								href="#Data_Schemas">P3P data schema</a> and one or more extensions.</p>

								<dl>

								  <dt><strong><code>&lt;POLICY&gt;</code></strong></dt>

								    <dd>includes one or more statements. Each statement includes a set of

								      disclosures as applied to a set of data elements.</dd>

								  <dt><code><strong>name</strong></code> <strong>(<em>mandatory

								  attribute</em>)</strong></dt>

								    <dd>name of the policy, used as a fragment identifier to be able to

								      reference the policy.</dd>

								  <dt><strong><code><a name="disc_URI" id="disc_URI">discuri</a></code>

								  (<em>mandatory attribute</em>)</strong></dt>

								    <dd>URI of the natural language privacy statement.</dd>

								  <dt><code><a name="opturi"

								  id="opturi"><strong>opturi</strong></a></code></dt>

								    <dd>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 <em><strong>mandatory</strong></em> for policies that

								      contain a <code><a href="#PURPOSE">purpose</a></code> with required

								      attribute set to <code>opt-in</code> or <code>opt-out</code>. 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.</dd>

								  <dt><strong><code>xml:lang</code></strong></dt>

								    <dd>Language in which the policy is expressed (see <a

								      href="#multiple">section 2.4.2</a>).</dd>

								</dl>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[21]</td>

								      <td valign="top"><pre>policy</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`&lt;POLICY name=` quotedstring

								         ` discuri=` quoted-URI

								         [` opturi=` quoted-URI]

								         [xml-lang] `&gt;`

								*extension

								[test]

								entity

								access

								[disputes-group]

								1*statement-block

								*extension

								`&lt;/POLICY&gt;`</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[22]</td>

								      <td valign="top"><pre>quoted-URI</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`"` URI `"`</pre>

								      </td>

								    </tr>

								    <tr>

								      <td colspan="4" valign="top">Here, URI is defined as per <a

								        href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986</a> [<a

								        href="#URI">URI</a>].</td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="StatementGroupDef">3.2.3 <code>STATEMENT-GROUP-DEF</code> element

								(EXTENSION)</h3>


								<p>The <code>STATEMENT-GROUP-DEF</code> extension is used to define an

								identifier and optionally properties that can be applied to a group of

								<code>STATEMENT</code> elements using the <code><a

								href="#statement_group">STATEMENT-GROUP</a></code> extension. P3P user agents

								that understand these two extensions MAY take this information into account

								when displaying P3P policy information for users. For example, statements

								that belong to the same group might be displayed together under a single

								heading.</p>

								<dl>

								  <dt><strong><code>&lt;STATEMENT-GROUP-DEF&gt;</code></strong></dt>

								    <dd>an optional extension placed inside a P3P policy before the

								      occurrence of the first <code>STATEMENT</code> element that defines an

								      identifier and optionally properties that can be applied to a group of

								      <code>STATEMENT</code> elements</dd>

								  <dt><strong><code>id</code></strong></dt>

								    <dd>This attribute contains a string that identifies a statement group.

								      It is required to be unique within a policy.</dd>

								  <dt><strong><code>short-description</code></strong></dt>

								    <dd>A short human readable description of the statement group, not to

								      exceed 255 <a href="#character">characters</a>.</dd>

								  <dt><strong><code>consent</code></strong></dt>

								    <dd>This attribute is used to indicate whether or not a user can

								      simultaneously consent to (or withdraw consent from) all the data usage

								      and recipients referenced in the statements that comprise this group.

								      There are four possible values for this attribute. A value of

								      <code>opt-in</code> indicates that a user can simultaneously opt-in. A

								      value of <code>opt-out</code> indicates that a user can simultaneously

								      opt-out. A value of <code>always</code> indicates that no opt-in or

								      opt-out options are available. A value of <code>mixed</code> indicates

								      that opt-in or opt-out may be available for some or all of the data

								      uses and recipients individually, but users are not able to

								      simultaneously consent to or withdraw consent from all of them. If this

								      attribute is omitted, the default value is <code>mixed</code>.</dd>

								</dl>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[23]</td>

								      <td valign="top"><pre>sg-def-extension</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`&lt;EXTENSION optional="yes"&gt;`

								        *[sg-def]

								        `&lt;/EXTENSION&gt;`</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[24]</td>

								      <td valign="top"><pre>sg-def</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`&lt;STATEMENT-GROUP-DEF id="`  quotedstring  `"`

								  [`consent ="`  (`opt-in` | `opt-out` | `always` | `mixed`) `"`]

								  [short-description]

								  `xmlns = "http://www.w3.org/2006/01/P3Pv11"/&gt;`</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<p>(Note that the <code>optional</code> attribute does not need to be

								explicitly included because its default value is <code>yes</code>.)</p>


								<p>Because P3P 1.0 user agents are unaware of this extension (and thus will

								ignore it), all statements that belong to statement groups that have

								<code>consent</code> attributes with values of <code>opt-in</code>,

								<code>opt-out</code>, MUST use the corresponding <code>required</code>

								attribute on all <code>PURPOSE</code> and <code>RECIPIENTS</code> elements.

								If <code>consent="always"</code> the <code>required</code> attribute MUST be

								omitted as its default value is <code>always</code>. Any user agent that

								relies on this extension MUST check to make sure this requirement has been

								followed. If a user agent finds an inconsistency between a

								<code>consent</code> attribute and a <code>required</code> attribute it MUST

								either ignore the extension altogether or treat the statement group as if its

								<code>consent</code> value was <code>mixed</code>.</p>


								<p>Note that the purpose <code>current</code> and the recipient

								<code>ours</code> do not take a <code>required</code> attribute and thus

								cannot be used in statement groups with <code>consent</code> values other

								than <code>required</code> or <code>mixed</code>.</p>


								<p>Statement groups serve two main purposes:</p>

								<ul>

								  <li>A statement group allows policy authors to describe what sections of

								    their P3P policy apply to different user interactions with their

								    site/service. E.g., an e-commerce site may define one group that

								    describes data collection for web browsing and another group that

								    describes the additional data that is collected when items are bought.

								    This enables a person who just browses the site to be aware that only a

								    small portion of the policy is relevant to him/her.</li>

								  <li>The <code>consent</code> attribute of the statement group enables a

								    site to define usages that can only be opted in- or out together. E.g.,

								    an opt-in to a frequent-flyer club implies collection of email and phone

								    for contact as well as clickstream data for individual analysis.</li>

								</ul>


								<p>Statement groups are intended primarily as hints to user agents on how to

								display P3P policy information to users. As currently specified, they are not

								intended for use in automated decision-making. For example, user agents

								cannot make judgments automatically about which statement groups apply to the

								activities of their users.</p>

								<pre class="sample">&lt;POLICY&gt;

								&hellip;

								  &lt;EXTENSION optional="yes"&gt;

								    &lt;p3p11:STATEMENT-GROUP-DEF id="browsing"

								     consent = "always"

								     short-description="Browsing the site"

								     xmlns = "http://www.w3.org/2006/01/P3Pv11" /&gt;

								  &lt;/EXTENSION&gt;

								&hellip;

								&lt;/POLICY&gt;</pre>


								<h3 id="test">3.2.4 The <strong><code>TEST</code></strong>

								element</h3>


								<p>The TEST element is used for testing purposes: the presence of

								<code>TEST</code> in a policy indicates that the policy is just an example,

								and as such, it MUST be ignored, and not be considered as a valid P3P

								policy.</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[25]</td>

								      <td valign="top"><pre>test</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"&lt;TEST/&gt;"</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="ENTITY">3.2.5 The <code><strong>ENTITY</strong></code> element</h3>


								<p>The <code>ENTITY</code> element gives a precise description of the legal

								entity making the representation of the privacy practices.</p>

								<dl>

								  <dt><strong><code>&lt;ENTITY&gt;</code></strong></dt>

								    <dd>identifies the legal entity making the representation of the privacy

								      practices contained in the policy</dd>

								</dl>


								<p>The <code>ENTITY</code> element contains a description of the legal entity

								consisting of <a href="#DATA">datatype EXTENSION elements</a> referencing (all or some of)

								the fields of the <a href="#business_data">business dataset</a> as the text values of their leaf nodes (i.e. the values are typed by the schema XML):

								 it MUST contain both the legal entity's name and one or more contact information

								fields among postal address, telephone number, email address, URI. Note that

								some laws and codes of conduct require entities to include a postal address

								or other specific information in their contact information.</p>


								<p><strong>Example of a valid ENTITY element</strong></p>

								<p>Note that &lt;DATA ref=&quot;.... elements must also be included only for

								backward compatibility and would normally be inserted automatically by a

								policy editor</p>


								<pre class="sample">

								&lt;ENTITY&gt;

								    &lt;EXTENSION&gt;

								      &lt;p3p11:data-group&gt;

								        &lt;p3p11:datatype&gt;

								          &lt;p3p11:business&gt;

								            &lt;p3p11:orgname&gt;CatalogExample&lt;/p3p11:orgname&gt;

								            &lt;p3p11:contact-info&gt;

								              &lt;p3p11:postal&gt;

								                &lt;p3p11:street&gt;4000 Lincoln Ave.&lt;/p3p11:street&gt;

								                &lt;p3p11:city&gt;Birmingham&lt;/p3p11:city&gt;

								                &lt;p3p11:state&gt;MI&lt;/p3p11:state&gt;

								                &lt;p3p11:postalcode&gt;48009&lt;/p3p11:postalcode&gt;

								                &lt;p3p11:country&gt;USA&lt;/p3p11:country&gt;

								              &lt;/p3p11:postal&gt;

								              &lt;p3p11:online&gt;

								                &lt;p3p11:email&gt;catalog@example.co.uk&lt;/p3p11:email&gt;

								              &lt;/p3p11:online&gt;

								              &lt;p3p11:telecom&gt;

								                &lt;p3p11:telephone&gt;

								                  &lt;p3p11:intcode&gt;1&lt;/p3p11:intcode&gt;

								                  &lt;p3p11:loccode&gt;248&lt;/p3p11:loccode&gt;

								                  &lt;p3p11:number&gt;3926753&lt;/p3p11:number&gt;

								                &lt;/p3p11:telephone&gt;

								              &lt;/p3p11:telecom&gt;

								            &lt;/p3p11:contact-info&gt;

								          &lt;/p3p11:business&gt;

								        &lt;/p3p11:datatype&gt;

								      &lt;/p3p11:data-group&gt;

								    &lt;/EXTENSION&gt;

								    &hellip;

								  &lt;/DATA-GROUP&gt;

								&lt;/ENTITY&gt;

								</pre>


								<p>Although it is permissable for a particular <code>datatype</code> element to

								appear more than once within a single <code>ENTITY</code> element, this is

								not recommended as user agents may not display multiple instances of a

								<code>datatype</code> element correctly. Policy writers who wish to indicate

								multiple points of contact for customer service at a web site should use the

								<a href="#DISPUTES"><code>DISPUTES</code></a> element, which is designed to

								have multiple instances.</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[26]</td>

								      <td valign="top"><pre> entity</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"&lt;ENTITY&gt;"

								*extension

								entitydescription

								*extension

								"&lt;/ENTITY&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[27]</td>

								      <td valign="top"><pre> entitydescription</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"&lt;DATA-GROUP&gt;"

								`&lt;DATA ref="#business.name"/&gt;` PCDATA "&lt;/DATA&gt;"

								*(`&lt;DATA ref="#business.` string `"/&gt;` PCDATA "&lt;/DATA&gt;")

								"&lt;/DATA-GROUP&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td colspan="4" valign="top">Here, <code>string</code> is defined as a

								        sequence of characters (with " and &amp; escaped) among the values

								        that are allowed by the <a href="#business_data">business

								        dataset</a>. <code>PCDATA</code> is defined as in [<a

								        href="#XML">XML</a>].</td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="ACCESS">3.2.6 The

								<strong><code>ACCESS</code></strong> element</h3>


								<p>The <code>ACCESS</code> element indicates whether the site provides access

								to various kinds of information.</p>

								<dl>

								  <dt><strong><code>&lt;ACCESS&gt;</code></strong></dt>

								    <dd>the ability of the individual to view identified data and address

								      questions or concerns to the service provider. Service providers MUST

								      disclose one value for the access attribute. The method of access is

								      not specified. Any disclosure (other than <code>&lt;all/&gt;</code>) is

								      not meant to imply that access to all data is possible, but that some

								      of the data may be accessible and that the user should communicate

								      further with the service provider to determine what capabilities they

								      have.

								      <p>Note that service providers may also wish to provide capabilities to

								      access information collected through means other than the Web at the

								      <strong><a href="#disc_URI">discuri</a>.</strong> However, the scope of

								      P3P statements are limited to data collected through HTTP or other Web

								      transport protocols. 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.</p>

								    </dd>

								</dl>


								<p>The <code>ACCESS</code> element must contain one of the following

								elements:</p>

								<dl>

								  <dt><strong><code>&lt;nonident/&gt;</code></strong></dt>

								    <dd>Web site does not collect identified data.</dd>

								  <dt><strong><code>&lt;all/&gt;</code></strong></dt>

								    <dd>All Identified Data: access is given to all identified data.</dd>

								  <dt><strong><code>&lt;contact-and-other/&gt;</code></strong></dt>

								    <dd>Identified Contact Information and Other Identified Data: access is

								      given to identified online and physical contact information as well as

								      to certain other identified data.</dd>

								  <dt><strong><code>&lt;ident-contact/&gt;</code></strong></dt>

								    <dd>Identified Contact Information: access is given to identified online

								      and physical contact information (e.g., users can access things such as

								      a postal address).</dd>

								  <dt><strong><code>&lt;other-ident/&gt;</code></strong></dt>

								    <dd>Other Identified Data: access is given to certain other identified

								      data (e.g., users can access things such as their online account

								      charges).</dd>

								  <dt><strong><code>&lt;none/&gt;</code></strong></dt>

								    <dd>None: no access to identified data is given.</dd>

								</dl>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[28]</td>

								      <td valign="top"><pre>access</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;ACCESS&gt;"

								*extension

								access_disclosure

								*extension

								"&lt;/ACCESS&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[29]</td>

								      <td valign="top"><pre>access_disclosure</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;nonident/&gt;"          | ; Identified Data is Not Used

								"&lt;all/&gt;"               | ; All Identifiable Information

								"&lt;contact-and-other/&gt;" | ; Identified Contact Information and

								                                 Other Identified Data

								"&lt;ident-contact/&gt;"     | ; Identifiable Contact Information

								"&lt;other-ident/&gt;"       | ; Other Identified Data

								"&lt;none/&gt;"                ; None</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="DISPUTES">3.2.7 The <strong><code>DISPUTES</code></strong>

								element</h3>


								<p>A policy SHOULD contain a <code>DISPUTES-GROUP</code> element, which

								contains one or more <code>DISPUTES</code> elements. These elements describe

								dispute resolution procedures that may be followed for disputes about an

								entity's privacy practices. Each <code>DISPUTES</code> element can optionally

								contain a <code>LONG-DESCRIPTION</code> element, an <code>IMG</code> element,

								and a <code>REMEDIES</code> element. Entities with multiple dispute

								resolution procedures should use a separate <code>DISPUTES</code> element for

								each. Since different dispute procedures have separate remedy processes, each

								<code>DISPUTES</code> element would need a separate

								<code>LONG-DESCRIPTION</code>, <code>IMG</code> tag and <code>REMEDIES</code>

								element, if they are being used.</p>

								<dl>

								  <dt><strong><code>&lt;DISPUTES&gt;</code></strong></dt>

								    <dd>Although there may be other ways, the entity offers or acknowledges

								      the following ways for a user to resolve disputes about the entity's

								      privacy practices or alleged protocol violations.</dd>

								  <dt><strong><code>resolution-type</code></strong> <strong>(<em>mandatory

								  attribute</em>)</strong></dt>

								    <dd>takes one of the following four values:

								      <dl>

								        <dt><strong>Customer Service</strong> <code>[service]</code></dt>

								          <dd>The entity's customer service reprsentative is available to

								            help resolve users' disputes regarding the use of collected data.

								            The description MUST include information about how to contact

								            customer service.</dd>

								        <dt><strong>Independent Organization</strong>

								        <code>[independent]</code></dt>

								          <dd>The entity is willing to be bound by the authority of an

								            independent organization for resolution of disputes regarding the

								            use of collected data. The description MUST include information

								            about how to contact the third party organization. <br />

								            Policy writers may also use this attribute to specify seals and

								            certification programs related to the entity's information

								            practices (including privacy and security seals).</dd>

								        <dt><strong>Court</strong> <code>[court]</code></dt>

								          <dd>The entity making the statement believes that the authority

								            referenced in the description offers recourse for disputes

								            arising in connection with the privacy statement.</dd>

								        <dt><strong>Applicable Law</strong> <code>[law]</code></dt>

								          <dd>The laws or regulations referenced in the description may

								            provide recourse procedures and remedies for disputes arising in

								            connection with the privacy statement.</dd>

								      </dl>

								    </dd>

								  <dt><strong><code>service</code></strong> <strong>(<em>mandatory

								  attribute</em>)</strong></dt>

								    <dd>URI of the customer service Web page or independent organization, or

								      URI for information about the relevant court or applicable law</dd>

								  <dt><strong><code>verification</code></strong></dt>

								    <dd>URI or certificate that can be used for verification purposes. It is

								      anticipated that seal providers will provide a mechanism for verifying

								      a site's claim that they have a seal.</dd>

								  <dt><strong><code>short-description</code></strong></dt>

								    <dd>A short human readable description of the name of the appropriate

								      legal forum, applicable law, or third party organization; or contact

								      information for customer service if not already provided at the service

								      URI. No more than 255 <a href="#character">characters</a>.</dd>

								</dl>


								<p>The <code>DISPUTES</code> element can contain a

								<code>LONG-DESCRIPTION</code> element, where a human readable description is

								present: this should contain the name of the appropriate legal forum,

								applicable law, or third party organization; or contact information for

								customer service if not already provided at the service URI.</p>

								<dl>

								  <dt><strong><code><a name="LONG-DESCRIPTION"

								  id="LONG-DESCRIPTION">&lt;LONG-DESCRIPTION&gt;</a></code></strong></dt>

								    <dd>This element contains a (possibly long) human readable

								    description.</dd>

								</dl>

								<dl>

								  <dt><strong><code>&lt;IMG&gt;</code></strong></dt>

								    <dd>An image logo (for example, of the independent organization or

								      relevant court)</dd>

								  <dt><strong><code>src</code></strong> <strong>(<em>mandatory

								  attribute</em>)</strong></dt>

								    <dd>URI of the image logo</dd>

								  <dt><strong><code>width</code></strong></dt>

								    <dd>width in pixels of the image logo</dd>

								  <dt><strong><code>height</code></strong></dt>

								    <dd>height in pixels of the image logo</dd>

								  <dt><strong><code>alt</code> (<em>mandatory attribute</em>)</strong></dt>

								    <dd>very short textual alternative for the image logo</dd>

								</dl>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[30]</td>

								      <td valign="top"><pre>disputes-group</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;DISPUTES-GROUP&gt;"

								*extension

								1*dispute

								*extension

								"&lt;/DISPUTES-GROUP&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[31]</td>

								      <td valign="top"><pre>dispute</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;DISPUTES"

								 " resolution-type=" '"'("service"|"independent"|"court"|"law")'"'

								 " service=" quoted-URI

								 [" verification=" quotedstring]

								 [" short-description=" quotedstring]

								"&gt;"

								*extension

								[longdescription]

								[image]

								[remedies]

								*extension

								"&lt;/DISPUTES&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[32]</td>

								      <td valign="top"><pre>longdescription</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>&lt;LONG-DESCRIPTION&gt; PCDATA &lt;/LONG-DESCRIPTION&gt;</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[33]</td>

								      <td valign="top"><pre>image</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"&lt;IMG src=" quoted-URI

								[" width=" `"` number `"`]

								[" height=" `"` number `"`]

								" alt=" quotedstring

								"/&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[34]</td>

								      <td valign="top"><pre>quotedstring</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`"` string `"`</pre>

								      </td>

								    </tr>

								    <tr>

								      <td colspan="4" valign="top">Here, <code>string</code> is defined as a

								        sequence of characters (with " and &amp; escaped), and

								        <code>PCDATA</code> is defined as in [<a href="#XML">XML</a>].</td>

								    </tr>

								  </tbody>

								</table>


								<p>Note that there can be multiple assurance services, specified via multiple

								occurrences of <code>DISPUTES</code> within the <code>DISPUTES-GROUP</code>

								element. These fields are expected to be used in a number of ways, including

								representing that one's privacy practices are self assured, audited by a

								third party, or under the jurisdiction of a regulatory authority.</p>


								<h3 id="REMEDIES">3.2.8 The <code>REMEDIES</code>

								element</h3>


								<p>Each <code>DISPUTES</code> element SHOULD contain a <code>REMEDIES</code>

								element that specifies the possible remedies in case a policy breach

								occurs.</p>

								<dl>

								  <dt><strong><code>&lt;REMEDIES&gt;</code></strong></dt>

								    <dd>The entity offers or acknowledges that the following remedies may

								      apply to the identified dispute-resolution procedures.</dd>

								</dl>


								<p>The <code>REMEDIES</code> element must contain one or more of the

								following:</p>

								<dl>

								  <dt><strong><code>&lt;correct/&gt;</code></strong></dt>

								    <dd>The entity has implemented a policy to rectify errors or consequences

								      for disputes arising in connection with the privacy statement.</dd>

								  <dt><strong><code>&lt;money/&gt;</code></strong></dt>

								    <dd>The entity has implemented a compensation policy for disputes arising

								      in connection with the privacy statement.</dd>

								  <dt><strong><code>&lt;law/&gt;</code></strong></dt>

								    <dd>Remedies for disputes arising in connection with the Privacy

								      Statement may be specified by the law referenced in the human readable

								      description.</dd>

								</dl>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[35]</td>

								      <td valign="top"><pre>remedies</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;REMEDIES&gt;"

								*extension

								1*remedy

								*extension

								"&lt;/REMEDIES&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[36]</td>

								      <td valign="top"><pre>remedy</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;correct/&gt;" |

								"&lt;money/&gt;"   |

								"&lt;law/&gt;"    </pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h2 id="Statements">3.3 Statements</h2>


								<p>Statements describe data practices that are applied to particular types of

								data.</p>


								<h3 id="STATEMENT">3.3.1 The <strong><code>STATEMENT</code></strong> element</h3>


								<p>The <code>STATEMENT</code> element is a container that groups together a

								<code>PURPOSE</code> element, a <code>RECIPIENT</code> element, a

								<code>RETENTION</code> element, a <code>DATA-GROUP</code> element, and

								optionally a <code>CONSEQUENCE</code> element and one or more extensions. All

								of the data referenced by the <code>DATA-GROUP</code> is handled according to

								the disclosures made in the other elements contained by the statement. Thus,

								sites may group elements that are handled the same way and create a statement

								for each group. Sites that would prefer to disclose separate purposes and

								other information for each kind of data they collect can do so by creating a

								separate statement for each data element.</p>

								<dl>

								  <dt><strong><code>&lt;STATEMENT&gt;</code></strong></dt>

								    <dd>data practices as applied to data elements.</dd>

								</dl>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[37]</td>

								      <td valign="top"><pre>statement-block</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;STATEMENT&gt;"

								*extension

								[consequence]

								((purpose recipient retention 1*data-group) |

								 (non-identifiable [purpose] [recipient] [retention] *data-group))

								*extension

								"&lt;/STATEMENT&gt;"</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<p>To simplify practice declaration, service providers may aggregate any of

								the disclosures (purposes, recipients, and retention) within a statement over

								data elements. Service providers MUST make such aggregations as an additive

								operation. For instance, a site that distributes your age to

								<code>ours</code> (ourselves and our agents), but distributes your postal

								code to <code>unrelated</code> (unrelated third parties), MAY say they

								distribute your name and postal code to <code>ours</code> and

								<code>unrelated</code>. Such a statement appears to distribute more data than

								actually happens. It is up to the service provider to determine if their

								disclosure deserves specificity or brevity. Note that when aggregating

								disclosures across statements that include the <code>NON-IDENTIFIABLE</code>

								element, this element may be included in the aggregated statement only if it

								would otherwise appear in every statement if the statements were written

								separately.</p>


								<p>Also, one must always disclose all options that apply. Consider a site

								with the sole purpose of collecting information for the purposes of

								<code>contact</code> (Contacting Visitors for Marketing of Services or

								Products). Even though this is considered to be for the <code>current</code>

								(Completion and Support of Activity For Which Data Was Provided) purpose, the

								site must state both <code>contact</code> and <code>current</code> purposes.

								Consider a site which distributes information to <code>ours</code> in order

								to redistribute it to <code>public</code>: the site must state both

								<code>ours</code> and <code>public</code> recipients.</p>


								<p>Service providers often aggregate data they collect. Sometimes this

								aggregate data may be used for different purposes than the original data,

								shared more widely than the original data, or retained longer than the

								original data. For example many sites publish or disclose to their

								advertisers statistics such as number of visitors to their Web site,

								percentage of visitors who fit into various demographic groups, etc. When

								aggregate statistics are used or shared such that it would not be possible to

								derive data for individual people or households based on these statistics, no

								disclosures about these statistics are necessary in a P3P policy. However,

								services MUST disclose the fact that the original data is collected and

								declare any use that is made of the data before it is aggregated.</p>


								<h3 id="statement_group">3.3.2 The <code>STATEMENT-GROUP</code> element

								(EXTENSION)</h3>


								<p>A statement can be associated with a statement group. Each statement can

								have at most one <code>&lt;STATEMENT-GROUP&gt; extension.</code></p>


								<p>A <code>STATEMENT-GROUP</code> can carry at most two attributes: The

								<code>id-attribute</code> and the <code>name-attribute</code>:</p>


								<p>The <code>id-attribute</code> associates a <code>STATEMENT</code> with a

								certain group of <code>STATEMENTs</code> to cluster them together to reflect

								a certain typical usage (see <a

								href="#StatementGroupDef"><code>STATEMENT-GROUP-DEF</code></a> for more

								information</p>


								<p>The <code>STATEMENT-GROUP</code> is placed after the opening tag of the

								<code>STATEMENT</code> element.</p>


								<p>The <code>name-attribute</code> associates a name to a certain statement.

								User agents may use this name to improve the display of the policy to the

								user in a human readable format. This extension was taken up from one

								implementer's authoring tool. Note that versions of this tool up through

								version 1.10 used an optional GROUP-INFO extension to name each statement.

								This extension provides the same function as the <code>name attribute</code>

								in the <code>STATEMENT-GROUP</code> extension. For backwards compatibility

								with existing P3P 1.0 policies, user agent implementers may wish to include

								support for this old extension. The old extension provided by the tool is

								placed after the opening tag of a <code>STATEMENT</code> element and takes

								the form</p>

								<pre class="sample">&lt;EXTENSION optional="yes"&gt;

								  &lt;GROUP-INFO

								  xmlns="http://www.software.ibm.com/P3P/editor/extension-1.0.html"

								  name="example"/&gt;

								&lt;/EXTENSION&gt;</pre>


								<p>In this sample <q>example</q> is the name of the statement.</p>

								<dl>

								  <dt><strong><code>&lt;STATEMENT-GROUP&gt;</code></strong></dt>

								    <dd>an optional extension placed inside a <code>STATEMENT</code> element

								      that identifies the statement group to which that statement belongs</dd>

								  <dt><strong><code>id</code></strong></dt>

								    <dd>This attribute contains a string that identifies a statement group

								      that has been defined using a corresponding

								      <code>STATEMENT-GROUP-DEF</code> element.</dd>

								  <dt><strong><code>name</code></strong></dt>

								    <dd>This attribute contains a string that names the

								      <code>STATEMENT</code> element.</dd>

								</dl>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[38]</td>

								      <td valign="top"><pre>sg-extension</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>`&lt;EXTENSION optional="yes"&gt;`

								  `&lt;STATEMENT-GROUP`

								        `id="` quotedstring `"`

								        `name="`  quotedstring `"`

								          [short-description]

								        `xmlns = "http://www.w3.org/2006/01/P3Pv11"  /&gt;`

								`&lt;/EXTENSION&gt;`</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>

								<pre class="sample">&lt;STATEMENT&gt;

								  &lt;EXTENSION optional="yes"&gt;

								    &lt;STATEMENT-GROUP

								     id="browsing"

								     name="browsing of static pages"

								     xmlns="http://www.w3.org/2006/01/P3Pv11" /&gt;

								  &lt;/EXTENSION&gt;

								&hellip;

								&lt;/STATEMENT&gt;</pre>


								<h3 id="CONSEQUENCE">3.3.3 The <strong><code>CONSEQUENCE</code></strong>

								element</h3>


								<p><code>STATEMENT</code> elements may optionally contain a

								<code>CONSEQUENCE</code> element that can be shown to a human user to provide

								further explanation about a site's practices.</p>


								<p>The definition of <code>CONSEQUENCE</code> given here is somewhat

								different from the definition given in the <a

								href="http://www.w3.org/TR/P3P/">P3P 1.0 specification</a>, which stated that

								the element should be used for <q>consequences</q> that can be shown to a

								human user to explain why the suggested practice may be valuable in a

								particular instance even if the user would not normally allow the practice."

								The P3P 1.1 definition has been broadened to reflect how the

								<code>CONSEQUENCE</code>element is being used by web sites in practice. As

								the P3P 1.1 definition subsumes the P3P 1.0 definition, it is not necessary

								for web sites that have developed their policies using the P3P 1.0 definition

								to change their policies unless they want to take advantage of the additional

								flexibility offered by the P3P 1.1 definition. See also <a

								href="#complete_trans">Completeness of Human-Readable Translations</a> .</p>

								<dl>

								  <dt><strong><code>&lt;CONSEQUENCE&gt;</code></strong></dt>

								    <dd>A short summary or explanation of the data practices described in the

								      <code>STATEMENT</code> that can be shown to a human user. This field is

								      not intended to replace or duplicate the detailed information that may

								      be provided in a site's full human-readable privacy policy. Note that

								      user agents that display this field MAY truncate lengthy

								      <code>CONSEQUENCE</code> strings or display this information only if a

								      user follows a hyperlink.</dd>

								</dl>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[39]</td>

								      <td valign="top"><pre>consequence</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;CONSEQUENCE&gt;"

								PCDATA

								"&lt;/CONSEQUENCE&gt;"</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="NON-IDENTIFIABLE">3.3.4 The

								<code><strong>NON-IDENTIFIABLE</strong></code> element</h3>


								<p>A <code>STATEMENT</code> element may optionally contain the

								<code>NON-IDENTIFIABLE</code> element, signifying either that there is no

								data collected under this <code>STATEMENT</code>, or that all of the data

								referenced by that <code>STATEMENT</code> will be anonymized upon

								collection.</p>

								<dl>

								  <dt><strong><code>&lt;NON-IDENTIFIABLE/&gt;</code></strong></dt>

								    <dd>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 <code>STATEMENT</code>. 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".<br />

								      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 media. 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.</dd>

								</dl>


								<p>If the <code>NON-IDENTIFIABLE</code> element is present in any

								<code>STATEMENT</code> elements in a policy, then a human readable

								explanation of how the data is anonymized MUST be included or linked to at

								the <strong><a href="#disc_URI">discuri</a></strong> .</p>


								<p>Also, if the <code>NON-IDENTIFIABLE</code> element is present in a

								<code>STATEMENT</code> then the other elements in that <code>STATEMENT</code>

								are optional.</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[40]</td>

								      <td valign="top"><pre>non-identifiable</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;NON-IDENTIFIABLE/&gt;"</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="PURPOSE">3.3.5 The

								<strong><code>PURPOSE</code></strong> element</h3>


								<p>Each <code>STATEMENT</code> element that does not include a

								<code>NON-IDENTIFIABLE</code> element MUST contain a <code>PURPOSE</code>

								element that contains one or more purposes of data collection or uses of

								data. Sites MUST classify their data practices into one or more of the

								purposes specified below.</p>

								<dl>

								  <dt><strong><code>&lt;PURPOSE&gt;</code></strong></dt>

								    <dd>purposes for data processing relevant to the Web.</dd>

								</dl>


								<p>The <code>PURPOSE</code> element MUST contain one or more of the

								following:</p>

								<dl>

								  <dt><strong><code>&lt;current/&gt;</code></strong></dt>

								    <dd><strong>Completion and Support of Activity For Which Data Was

								      Provided:</strong> 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.</dd>

								  <dt><strong><code>&lt;admin/&gt;</code></strong></dt>

								    <dd><strong>Web Site and System Administration:</strong> Information may

								      be used for the technical support of the Web site and its computer

								      system. This would include processing computer account information,

								      information used in the course of securing and maintaining the site,

								      and verification of Web site activity by the site or its agents.</dd>

								  <dt><strong><code>&lt;develop/&gt;</code></strong></dt>

								    <dd><strong>Research and Development</strong>: Information may be used to

								      enhance, evaluate, or otherwise review the site, service, product, or

								      market. This does not include personal information used to tailor or

								      modify the content to the specific individual nor information used to

								      evaluate, target, profile or contact the individual.</dd>

								  <dt><strong><code>&lt;tailoring/&gt;</code></strong></dt>

								    <dd><strong>One-time Tailoring</strong>: 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 might suggest other

								      items a visitor may wish to purchase based on the items he has already

								      placed in his shopping basket.</dd>

								  <dt><code><strong>&lt;pseudo-analysis/&gt;</strong></code></dt>

								    <dd><strong>Pseudonymous Analysis</strong>: Information may be used to

								      create or build a record of a particular individual or computer that is

								      tied to a pseudonymous identifier, without tying identified data (such

								      as name, address, phone number, or email address) to the record. This

								      profile will be used to determine the habits, interests, or other

								      characteristics of individuals <em>for purpose of research, analysis

								      and reporting</em>, but it will not be used to attempt to identify

								      specific individuals. For example, a marketer may wish to understand

								      the interests of visitors to different portions of a Web site.</dd>

								  <dt><code><strong>&lt;pseudo-decision/&gt;</strong></code></dt>

								    <dd><strong>Pseudonymous Decision</strong>: Information may be used to

								      create or build a record of a particular individual or computer that is

								      tied to a pseudonymous identifier, without tying identified data (such

								      as name, address, phone number, or email address) to the record. This

								      profile will be used to determine the habits, interests, or other

								      characteristics of individuals <em>to make a decision that directly

								      affects that individual</em>, but it will not be used to attempt to

								      identify specific individuals. For example, a marketer may tailor or

								      modify content displayed to the browser based on pages viewed during

								      previous visits.</dd>

								  <dt><code><strong>&lt;individual-analysis/&gt;</strong></code></dt>

								    <dd><strong>Individual Analysis</strong>: Information may be used to

								      determine the habits, interests, or other characteristics of

								      individuals and combine it with identified data <em>for the purpose of

								      research, analysis and reporting</em>. For example, an online Web site

								      for a physical store may wish to analyze how online shoppers make

								      offline purchases.</dd>

								  <dt><code><strong>&lt;individual-decision/&gt;</strong></code></dt>

								    <dd><strong>Individual Decision</strong>: Information may be used to

								      determine the habits, interests, or other characteristics of

								      individuals and combine it with identified data <em>to make a decision

								      that directly affects that individual</em>. For example, an online

								      store suggests items a visitor may wish to purchase based on items he

								      has purchased during previous visits to the Web site.</dd>

								  <dt><strong><code>&lt;contact/&gt;</code></strong></dt>

								    <dd><strong>Contacting Visitors for Marketing of Services or

								      Products</strong>: Information may be used to contact the individual,

								      through a communications channel other than voice telephone, for the

								      promotion of a product or service. This includes notifying visitors

								      about updates to the Web site. This does not include a direct reply to

								      a question or comment or customer service for a single transaction --

								      in those cases, <strong><code>&lt;current/&gt;</code></strong> would be

								      used. In addition, this does not include marketing via customized Web

								      content or banner advertisements embedded in sites the user is visiting

								      -- these cases would be covered by the

								      <code><strong>&lt;tailoring/&gt;</strong></code>,

								      <code><strong>&lt;pseudo-analysis/&gt;</strong></code> and

								      <code><strong>&lt;pseudo-decision/&gt;</strong></code>, or

								      <code><strong>&lt;individual-analysis/&gt;</strong></code> and

								      <code><strong>&lt;individual-decision/&gt;</strong></code>

								    purposes.</dd>

								  <dt><strong><code>&lt;historical/&gt;</code></strong></dt>

								    <dd><strong>Historical Preservation</strong>: Information may be archived

								      or stored for the purpose of preserving social history as governed by

								      an existing law or policy. This law or policy MUST be referenced in the

								      <code>&lt;DISPUTES&gt;</code> element and MUST include a specific

								      definition of the type of qualified researcher who can access the

								      information, where this information will be stored and specifically how

								      this collection advances the preservation of history.</dd>

								  <dt><code><strong>&lt;telemarketing/&gt;</strong></code></dt>

								    <dd><strong>Contacting Visitors for Marketing of Services or Products Via

								      Telephone</strong>: Information may be used to contact the individual

								      via a 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,

								      <code><strong>&lt;current/&gt;</strong></code> would be used.</dd>

								  <dt><strong><code>&lt;other-purpose&gt;</code> <em>string</em>

								  <code>&lt;/other-purpose&gt;</code></strong></dt>

								    <dd><strong>Other Uses</strong>: Information may be used in other ways

								      not captured by the above definitions. (A human readable explanation

								      MUST be provided in these instances).</dd>

								</dl>


								<p>Each type of purpose (with the exception of <code>current</code>) can have

								the following optional attribute:</p>

								<dl>

								  <dt><strong><code><a name="required"

								  id="required">required</a></code></strong></dt>

								    <dd>Whether the purpose is a required practice for the site. The

								      attribute can take the following values:

								      <ul>

								        <li><strong><code>always</code></strong> : The purpose is always

								          required; users cannot opt-in or opt-out of this use of their data.

								          This is the default when no <code>required</code> attribute is

								          present.</li>

								        <li><strong><code>opt-in</code></strong> : Data may be used for this

								          purpose only when the user affirmatively requests this use -- for

								          example, when a user asks to be added to a mailing list. An

								          affirmative request requires users to take some action specifically

								          to make the request. For example, when users fill out a survey,

								          checking an additional box to request to be added to a mailing list

								          would be considered an affirmative request. However, submitting a

								          survey form that contains a pre-checked mailing list request box

								          would not be considered an affirmative request. In addition, for

								          any purpose that users may affirmatively request, there must also

								          be a way for them to change their minds later and decline -- this

								          MUST be specified at the <code><a

								        href="#opturi">opturi</a></code>.</li>

								        <li><strong><code>opt-out</code></strong> : Data may be used for this

								          purpose unless the user requests that it not be used in this way.

								          When this value is selected, the service MUST provide clear

								          instructions to users on how to opt-out of this purpose at the

								          <code><a href="#opturi">opturi</a></code>. Services SHOULD also

								          provide these instructions or a pointer to these instructions at

								          the point of data collection.</li>

								      </ul>

								    </dd>

								</dl>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[41]</td>

								      <td valign="top"><pre> purpose</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;PURPOSE&gt;"

								*extension

								1*purposevalue

								*extension

								"&lt;/PURPOSE&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[42]</td>

								      <td valign="top"><pre> purposevalue</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;current/&gt;"                           | ; Completion and Support of Activity For Which Data Was Provided

								"&lt;admin" [required]   "/&gt;"             | ; Web Site and System Administration

								"&lt;develop" [required] "/&gt;"             | ; Research and Development

								"&lt;tailoring" [required] "/&gt;"           | ; One-time Tailoring

								"&lt;pseudo-analysis" [required] "/&gt;"     | ; Pseudonymous Analysis

								"&lt;pseudo-decision" [required] "/&gt;"     | ; Pseudonymous Decision

								"&lt;individual-analysis" [required] "/&gt;" | ; Individual Analysis

								"&lt;individual-decision" [required] "/&gt;" | ; Individual Decision

								"&lt;contact" [required] "/&gt;"             | ; Contacting Visitors for Marketing of Services or Products

								"&lt;historical" [required] "/&gt;"          | ; Historical Preservation

								"&lt;telemarketing" [required] "/&gt;"       | ; Telephone Marketing

								"&lt;other-purpose" [required] "&gt;" PCDATA "&lt;/other-purpose&gt;"; Other Uses</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[43]</td>

								      <td valign="top"><pre> required</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>" required=" `"` ("always"|"opt-in"|"opt-out") `"`</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<p>Service providers MUST use the above elements to explain the purpose of

								data collection. Service providers MUST disclose <em>all that apply</em>. If

								a service provider does not disclose that a data element will be used for a

								given purpose, that is a representation that data will not be used for that

								purpose. Service providers that disclose that they use data for

								"<code>other</code>" purposes MUST provide human readable explanations of

								those purposes.</p>


								<h4 id="ppurpose">3.3.5.1 The <code>PPURPOSE</code> element (EXTENSION)</h4>


								<p>The primary purpose extension element allows user agents to determine the

								primary reason why the data recipient is collecting data. Multiple primary

								purposes may be used.</p>


								<p>The <code>PPURPOSE</code> is placed after the opening tag of the

								<code>PURPOSE</code> element. It is intended to expand upon the

								<code>&lt;current/&gt;</code> tag, providing a more detailed description of

								data usage.</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[44]</td>

								      <td valign="top"><pre>primary-purpose =</pre>

								      </td>

								      <td valign="top"><pre>"&lt;extension&gt;"

								"&lt;ppurpose&gt;"

								*primary-purpose-value

								"&lt;/ppurpose&gt;"

								"&lt;/extension&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[45]</td>

								      <td valign="top"><pre>primary-purpose-value =</pre>

								      </td>

								      <td valign="top"><pre>"&lt;account/&gt;"              | ; Account and/or Subscription Management

								"&lt;arts/&gt;"         | ; Arts and Entertainment

								"&lt;browsing/&gt;"             | ; Web Browsing

								"&lt;charity/&gt;"              | ; Charitable Donations

								"&lt;communicate/&gt;"  | ; Communications Services

								"&lt;custom/&gt;"               | ; Customization

								"&lt;delivery/&gt;"             | ; Delivery

								"&lt;downloads/&gt;"            | ; Software Downloads

								"&lt;education/&gt;"            | ; Education

								"&lt;feedback/&gt;"             | ; Responding to User

								"&lt;finmgt/&gt;"               | ; Banking and Financial Management

								"&lt;gambling/&gt;"             | ; Online Gambling

								"&lt;gaming/&gt;"               | ; Online Gaming

								"&lt;government/&gt;"           | ; Government Services

								"&lt;health/&gt;"               | ; Healthcare Services

								"&lt;login/&gt;"                | ; Authentication and Authorization

								"&lt;marketing/&gt;"            | ; Advertising, Marketing, and/or Promotion

								"&lt;news/&gt;"         | ; News and Information

								"&lt;payment/&gt;"              | ; Payment and Transaction Facilitation

								"&lt;sales/&gt;"                | ; Sales of Products or Services

								"&lt;search/&gt;"               | ; Search Engines

								"&lt;state/&gt;"                | ; State and Session Management

								"&lt;surveys/&gt;"                ; Surveys and Questionnaires</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>

								<dl>

								  <dt><strong><code>&lt;PPURPOSE&gt;</code></strong></dt>

								    <dd>the primary purpose for information collection.</dd>

								</dl>


								<p>The <code>PPURPOSE</code> element MUST contain one or more of the

								following:</p>

								<dl>

								  <dt><strong><code>&lt;account/&gt;</code></strong></dt>

								    <dd><strong>Account and/or Subscription Management</strong>: Information

								      may be used for managing an account. A common example is updating

								      account information. This may also include creation and/or termination

								      of an account or subscription.</dd>

								  <dt><strong><code>&lt;arts/&gt;</code></strong></dt>

								    <dd><strong>Arts and Entertainment</strong>: Information may be used for

								      delivering the arts. Examples include such interests as music,

								      literature, drama, movies, and the visual arts.</dd>

								  <dt><strong><code>&lt;browsing/&gt;</code></strong></dt>

								    <dd><strong>Web Browsing</strong>: Information may be exchanged

								      automatically for the purpose of browsing web pages.</dd>

								  <dt><strong><code>&lt;charity/&gt;</code></strong></dt>

								    <dd><strong>Charitable Donations</strong>: Information may be used for a

								      charitable donation.</dd>

								  <dt><strong><code>&lt;communicate/&gt;</code></strong></dt>

								    <dd><strong>Communications Services</strong>: Information may be used for

								      facilitating communication between users. Examples include

								      communication conducted over email, telephone, facsimile, videophone,

								      instant messaging, or any other communications medium.</dd>

								  <dt><strong><code>&lt;custom/&gt;</code></strong></dt>

								    <dd><strong>Customization</strong>: Information may be used to customize

								      the user's online experience as explicitly requested by the user. This

								      element should not be used to represent purposes that can be described

								      by <code>tailoring</code>, <code>pseudo-decision</code>, or

								      <code>individual-decision</code>. This element might be used, for

								      example, at a site that allows the user to change the language in which

								      content is presented.</dd>

								  <dt><strong><code>&lt;delivery/&gt;</code></strong></dt>

								    <dd><strong>Delivery</strong>: Information may be used for delivering a

								      product or products.</dd>

								  <dt><strong><code>&lt;downloads/&gt;</code></strong></dt>

								    <dd><strong>Software Downloads</strong>: Information may be used to allow

								      the user to download an executable program. This element should not be

								      used to describe downloads of web pages, multimedia files, scripts run

								      by a web browser, and plugin content. This element might be used, for

								      example, at a site that offers a downloadable media player. However, it

								      would not be used at a site that offers only music files playable by

								      the media player.</dd>

								  <dt><strong><code>&lt;education/&gt;</code></strong></dt>

								    <dd><strong>Education</strong>: Information may be used for educational

								      purposes; examples include teaching, grading, testing, and interactions

								      between educators and students.</dd>

								  <dt><strong><code>&lt;feedback/&gt;</code></strong></dt>

								    <dd><strong>Responding to User</strong>: Information may be used for the

								      purposes of responding to the user. This can vary from responding to a

								      query to simply providing the user with feedback.</dd>

								  <dt><strong><code>&lt;finmgt/&gt;</code></strong></dt>

								    <dd><strong>Banking and Financial Management</strong>: Information may be

								      used for bank transactions or financial management. Examples include

								      opening, closing, and managing financial accounts, as well as trading

								      securities.</dd>

								  <dt><strong><code>&lt;gambling/&gt;</code></strong></dt>

								    <dd><strong>Online Gambling</strong>: Information may be used for online

								      gambling where wagers for money are placed on games of chance.</dd>

								  <dt><strong><code>&lt;gaming/&gt;</code></strong></dt>

								    <dd><strong>Online Gaming</strong>: Information may be used for online

								      games that do not involve gambling.</dd>

								  <dt><strong><code>&lt;government/&gt;</code></strong></dt>

								    <dd><strong>Government Services</strong>: Information may be used for

								      online government services. Examples include voter registration,

								      vehicle registration, and citizen information services.</dd>

								  <dt><strong><code>&lt;health/&gt;</code></strong></dt>

								    <dd><strong>Healthcare Services</strong>: Information may be used to

								      offer the user products or services that relate to their physical

								      and/or mental health.</dd>

								  <dt><strong><code>&lt;login/&gt;</code></strong></dt>

								    <dd><strong>Authentication and Authorization</strong>: Information may be

								      used for the purpose of online identity verification. Usernames and

								      passwords are often exchanged to confirm online identity and/or grant

								      access to protected content.</dd>

								  <dt><strong><code>&lt;marketing/&gt;</code></strong></dt>

								    <dd><strong>Advertising, Marketing, and/or Promotion</strong>:

								      Information may be used for marketing and promotional purposes.</dd>

								  <dt><strong><code>&lt;news/&gt;</code></strong></dt>

								    <dd><strong>News and Information</strong>: Information may be used for

								      delivering news or other information.</dd>

								  <dt><strong><code>&lt;payment/&gt;</code></strong></dt>

								    <dd><strong>Payment and Transaction Facilitation</strong>: Information

								      may be used to facilitate a financial transaction. This is different

								      from <tt>sales</tt> as the payment is sent or received by a third

								    party.</dd>

								  <dt><strong><code>&lt;sales/&gt;</code></strong></dt>

								    <dd><strong>Sales of Products or Services</strong>: Information may be

								      used as part of a business transaction with the user. Information is

								      provided for the purpose of completing a sale.</dd>

								  <dt><strong><code>&lt;search/&gt;</code></strong></dt>

								    <dd><strong>Search Engines</strong>: Information may be used for querying

								      a search engine.</dd>

								  <dt><strong><code>&lt;state/&gt;</code></strong></dt>

								    <dd><strong>State and Session Management</strong>: Information may be

								      used to keep track of sessions. Examples include unique identification

								      numbers or information to identify the previous pages viewed. Other

								      uses include serving the user dynamic content.</dd>

								  <dt><strong><code>&lt;surveys/&gt;</code></strong></dt>

								    <dd><strong>Surveys and Questionnaires</strong>: Information may be used

								      to conduct surveys and questionnaires.</dd>

								</dl>


								<p>In the following sample, information is primarily being provided to

								authenticate a user as well as provide web content.</p>

								<pre class="sample">&lt;PURPOSE&gt;

								  &lt;EXTENSION optional="yes"&gt;

								    &lt;PPURPOSE xmlns="http://www.w3.org/2006/01/P3Pv11"&gt;

								      &lt;browsing/&gt;

								      &lt;login/&gt;

								    &lt;/PPURPOSE&gt;

								  &lt;/EXTENSION&gt;

								  &lt;current/&gt;

								&lt;/PURPOSE&gt;</pre>


								<h3 id="RECPNT">3.3.6 The <strong><code>RECIPIENT</code></strong> element</h3>


								<p>Each <code>STATEMENT</code> element that does not include a

								<code>NON-IDENTIFIABLE</code> element MUST contain a <code>RECIPIENT</code>

								element that contains one or more recipients of the collected data. Sites

								MUST classify their recipients into one or more of the six recipients

								specified.</p>

								<dl>

								  <dt><strong><code>&lt;RECIPIENT&gt;</code></strong></dt>

								    <dd>the legal entity, or domain, where data may be distributed.</dd>

								</dl>


								<p>The <code>RECIPIENT</code> element MUST contain one or more of the

								following:</p>

								<dl>

								  <dt><strong><code>&lt;ours&gt;</code></strong></dt>

								    <dd><strong>Ourselves and/or entities acting as our agents or entities

								      for whom we are acting as an agent</strong>: An agent in this instance

								      is defined as a third party that processes data only on behalf of the

								      service provider for the completion of the stated purposes. (e.g., the

								      service provider and its printing bureau which prints address labels

								      and does nothing further with the information.)</dd>

								  <dt><strong><code>&lt;delivery&gt;</code></strong></dt>

								    <dd><strong>Delivery services possibly following different

								      practices</strong>: Legal entities <em>performing delivery

								      services</em> that may use data for purposes other than completion of

								      the stated purpose. This should also be used for delivery services

								      whose data practices are unknown.</dd>

								  <dt><strong><code>&lt;same&gt;</code></strong></dt>

								    <dd><strong>Legal entities following our practices</strong>: Legal

								      entities who use the data on their own behalf under equable practices.

								      (e.g., consider a service provider that grants the user access to

								      collected personal information, and also provides it to a partner who

								      uses it once but discards it. Since the recipient, who has otherwise

								      similar practices, cannot grant the user access to information that it

								      discarded, they are considered to have equable practices.)</dd>

								  <dt><strong><code>&lt;other-recipient&gt;</code></strong></dt>

								    <dd><strong>Legal entities following different practices</strong>: Legal

								      entities that are constrained by and accountable to the original

								      service provider, but may use the data in a way not specified in the

								      service provider's practices (e.g., the service provider collects data

								      that is shared with a partner who may use it for other purposes.

								      However, it is in the service provider's interest to ensure that the

								      data is not used in a way that would be considered abusive to the

								      users' and its own interests.)</dd>

								  <dt><strong><code>&lt;unrelated&gt;</code></strong></dt>

								    <dd><strong>Unrelated third parties</strong>: Legal entities whose data

								      usage practices are not known by the original service provider.</dd>

								  <dt><strong><code>&lt;public&gt;</code></strong></dt>

								    <dd><strong>Public fora</strong>: Public fora such as bulletin boards,

								      public directories, or commercial CD-ROM directories.</dd>

								</dl>


								<p>Each of the above tags can optionally contain:</p>

								<ul>

								  <li>one or more <code>recipient-description</code> tags, containing a

								    description of the recipient;</li>

								  <li>with the exception of <code>&lt;ours&gt;</code>, a <code><a

								    href="#required">required</a></code> attribute: this attribute is defined

								    exactly as the analogous attribute in the <code>PURPOSE</code> tag,

								    indicating whether opt-in/opt-out of sharing is available (and, its

								    default value is <code>always</code>).</li>

								</ul>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[46]</td>

								      <td valign="top"><pre>recipient</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;RECIPIENT&gt;"

								*extension

								1*recipientvalue

								*extension

								"&lt;/RECIPIENT&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[47]</td>

								      <td valign="top"><pre>recipientvalue</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;ours&gt;" *recdescr

								"&lt;/ours&gt;                         |  ; only ourselves and our agents

								"&lt;same" [required] "&gt;" *recdescr

								"&lt;/same&gt;"                        |  ; legal entities following our practices

								"&lt;other-recipient" [required] "&gt;" *recdescr

								"&lt;/other-recipient&gt;"             |  ; legal entities following different practices

								"&lt;delivery" [required] "&gt;" *recdescr

								"&lt;/delivery&gt;"                    |  ; delivery services following different practices

								"&lt;public" [required] "&gt;" *recdescr

								"&lt;/public&gt;"                      |  ; public fora

								"&lt;unrelated" [required] "&gt;" *recdescr

								"&lt;/unrelated&gt;"                      ; unrelated third parties</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[48]</td>

								      <td valign="top"><pre>recdescr</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;recipient-description&gt;"

								PCDATA                              ; description of the recipient

								"&lt;/recipient-description&gt;"</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<p>Service providers MUST disclose <em>all the recipients that apply</em>.

								P3P makes no distinctions about how that data is released to the recipient;

								it simply requires that if data is released, then that sharing must be

								disclosed in the P3P policy. Examples of disclosing data which MUST be

								covered by a P3P statement include:</p>

								<ul>

								  <li>Transmitting customer data as part of an order-fulfillment or billing

								    process</li>

								  <li>Leasing or selling mailing lists</li>

								  <li>Placing personal information in URIs when redirecting requests to a

								    third party</li>

								  <li>Placing personal information in URIs which link to a third party</li>

								</ul>


								<p>Note that in some cases the above set of recipients may not completely

								describe all the recipients of data. For example, the issue of transaction

								facilitators, such as shipping or payment processors, who are necessary for

								the completion and support of the activity but may follow different practices

								was problematic. Currently, only delivery services can be explicitly

								represented in a policy. Other such transaction facilitators should be

								represented in whichever category most accurately reflects their practices

								with respect to the original service provider.</p>


								<p>A special element for delivery services is included, but not one for

								payment processors (such as banks or credit card companies) for the following

								reasons: Financial institutions will typically have separate agreements with

								their customers regarding the use of their financial data, while delivery

								recipients typically do not have an opportunity to review a delivery

								service's privacy policy.</p>


								<p>Note that the <code>&lt;delivery/&gt;</code> element SHOULD NOT be used

								for delivery services that agree to use data only on behalf of the service

								provider for completion of the delivery.</p>


								<h4 id="jurisdiction">3.3.6.1 The <code>JURISDICTION</code> element

								(EXTENSION)</h4>


								<p>The jurisdiction extension element allows user agents to make judgments

								about the trustworthiness of a data recipient based on the regulatory

								environment they are placed in. Jurisdictions of recipients can be rendered

								machine readable by inserting a known URI into the service field (e.g. the

								URI of a body of legislation which applies). For example organizations within

								the European Union can be assumed to comply to European data protection law

								and could therefore insert the <a href="http://europa.eu.int/eur-lex/lex/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML">URI

								of the 95/46 directive</a> as in the example above. Some jurisdictions

								prohibit transfer of data to certain other jurisdictions without the explicit

								consent of the data subject. It should be noted therefore declaring the data

								transfer activity of a recipient using the P3P jurisdiction extension is not

								sufficient to guarantee its legality.</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0"

								cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[49]</td>

								      <td valign="top"><pre>recipientvalue =</pre>

								      </td>

								      <td valign="top"><pre>&lt;extension&gt;

								  "&lt;jurisdiction [required]  |  ; legal entities in the jurisdiction

								    "service=" quoted-URI       |  ; indicated in the service URI

								    xmlns="http://www.w3.org/2006/01/P3Pv11" &gt;

								    *recdescr

								  "&lt;/jurisdiction&gt;

								&lt;/extension&gt;</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<p>Example:</p>

								<pre class="sample">&lt;RECIPIENT&gt;

								  &lt;EXTENSION&gt;

								    &lt;JURISDICTION

								     service="http://europa.eu.int/eur-lex/lex/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML"

								     short-description="31995L0046 Official Journal L 281,

								     23/11/1995 P. 0031 - 0050"&gt;

								       Directive 95/46/EC of the European Parliament and of the Council

								       of 24 October 1995 on the protection of individuals with regard

								       to the processing of personal data and on the free movement of

								       such data

								    &lt;/JURISDICTION&gt;

								  &lt;/EXTENSION&gt;

								&lt;/RECIPIENT&gt;</pre>


								<h3 id="RETENTION">3.3.7 The

								<strong><code>RETENTION</code></strong> element</h3>


								<p>Each <code>STATEMENT</code> element that does not include a

								<code>NON-IDENTIFIABLE</code> element MUST contain a <code>RETENTION</code>

								element that indicates the kind of retention policy that applies to the data

								referenced in that statement.</p>

								<dl>

								  <dt><strong><code>&lt;RETENTION&gt;</code></strong></dt>

								    <dd>the type of retention policy in effect</dd>

								</dl>


								<p>The <code>RETENTION</code> element MUST contain one of the following:</p>

								<dl>

								  <dt><strong><code>&lt;no-retention/&gt;</code></strong></dt>

								    <dd>Information is not retained for more than a brief period of time

								      necessary to make use of it during the course of a single online

								      interaction. Information MUST be destroyed following this interaction

								      and MUST NOT be logged, archived, or otherwise stored. This type of

								      retention policy would apply, for example, to services that keep no Web

								      server logs, set cookies only for use during a single session, or

								      collect information to perform a search but do not keep logs of

								      searches performed.</dd>

								  <dt><strong><code>&lt;stated-purpose/&gt;</code></strong></dt>

								    <dd>For the stated purpose: Information is retained to meet the stated

								      purpose. This requires information to be discarded at the earliest time

								      possible. 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.</dd>

								  <dt><strong><code>&lt;legal-requirement/&gt;</code></strong></dt>

								    <dd>As required by law or liability under applicable law: Information is

								      retained to meet a stated purpose, but the retention period is longer

								      because of a legal requirement or liability. For example, a law may

								      allow consumers to dispute transactions for a certain time period;

								      therefore a business may for liability reasons decide to maintain

								      records of transactions, or a law may affirmatively require a certain

								      business to maintain records for auditing or other soundness purposes.

								      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.</dd>

								  <dt><strong><code>&lt;business-practices/&gt;</code></strong></dt>

								    <dd>Determined by service provider's business practice: Information is

								      retained under a service provider's stated business practices. 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.</dd>

								  <dt><strong><code>&lt;indefinitely/&gt;</code></strong></dt>

								    <dd>Indefinitely: Information is retained for an indeterminate period of

								      time. The absence of a retention policy would be reflected under this

								      option. Where the recipient is a public fora, this is the appropriate

								      retention policy.</dd>

								</dl>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[50]</td>

								      <td valign="top"><pre>retention</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;RETENTION&gt;"

								*extension

								retentionvalue

								*extension

								"&lt;/RETENTION&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[51]</td>

								      <td valign="top"><pre>retentionvalue</pre>

								      </td>

								      <td valign="top"><pre>= </pre>

								      </td>

								      <td><pre>"&lt;no-retention/&gt;"       | ; not retained

								"&lt;stated-purpose/&gt;"     | ; for the stated purpose

								"&lt;legal-requirement/&gt;"  | ; stated purpose by law

								"&lt;indefinitely/&gt;"       | ; indeterminate period of time

								"&lt;business-practices/&gt;"   ; by business practices</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="DATA">3.3.8 The <strong><code>DATA-GROUP</code></strong> and

								<strong><code>datatype extension</code></strong> elements</h3>


								<p>Each <code>STATEMENT</code> element that does not include a

								<code>NON-IDENTIFIABLE</code> element MUST contain at least one

								<code>DATA-GROUP</code> element that contains one or more <code>

								datatype</code> extension elements. <code>datatype</code> extension

								elements are used to describe the type of data that a site collects.

								A set of <code>datatype</code> extension Elements that every

								user-agent MUST be aware of is defined in <a href="#base_data_structure">

								Structure of Base Data Schema</a></p>


								<dl>

								  <dt><strong><code>&lt;DATA-GROUP&gt;</code></strong></dt>

								    <dd>describes the data to be transferred or inferred</dd>

								</dl>

								<dl>

								  <dt><strong><code>&lt;datatype&gt;</code></strong></dt>

								    <dd>describes the data to be transferred or inferred</dd>

								  <dt><strong><code>optional</code></strong></dt>

								    <dd>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. <em>The default is

								      "no."</em> The <code>optional</code> attribute is used only in policies

								      (not in data schema definitions).</dd>

								</dl>


								<p>Note that user agents should be cautious about using the

								<code>optional</code> attribute in automated decision-making. If the

								<code>optional</code> attribute is associated with a data element directly

								controlled by the user agent (such as the HTTP <code>Referer</code> 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.</p>


								<p><code>datatype</code> elements can contain the actual data (as already seen in

								the case of the <code>ENTITY</code> element), and can contain related <a href="#Categories">category</a> information.</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[52]</td>

								      <td valign="top"><pre>data-group</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;DATA-GROUP"

								[" base=" quoted-URI]

								"&gt;"

								*extension

								1*dataref

								*extension

								"&lt;/DATA-GROUP&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[53]</td>

								      <td valign="top"><pre>dataref</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>`&lt;DATA" ref="` URI-reference `"`

								 [" optional=" `"` ("yes"|"no") `"`] "&gt;"

								 [categories] ; the <a href="#Categories">categories </a>of the data element.

								 [PCDATA] ; the eventual value of the data element

								"&lt;/DATA&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td colspan="4" valign="top">Here, <code>URI-reference</code> is

								        defined as in [<a href="#URI">URI</a>].</td>

								    </tr>

								  </tbody>

								</table>


								<p>For example, to reference the user's home address city, all the elements

								of the data set <code>&lt;user&gt;&lt;business-info/&gt;&lt;/user&gt;</code>

								and (optionally) all the elements of the data set <code>&lt;user&gt;&lt;home-info&gt;

								&lt;telecom/&gt;&lt;/home-info&gt;&lt;/user&gt;</code>, the service

								would send the following references inside a P3P policy:</p>


								<pre class="sample">&lt;DATA-GROUP&gt;

								  &lt;datatype optional="yes"&gt;

								    &lt;user&gt;

								      &lt;home-info&gt;

								        &lt;telecom/&gt;

								      &lt;/home-info&gt;

								    &lt;/user&gt;

								  &lt;/datatype&gt;

								  &lt;datatype optional="yes"&gt;

								    &lt;user&gt;

								      &lt;business-info/&gt;

								    &lt;/user&gt;

								  &lt;/datatype&gt;

								&lt;/DATA-GROUP&gt;</pre>


								<p>When the actual value of the data is known, it can be expressed inside the

								<code>DATA</code> element. For example, as seen in the <a

								href="#encoding">example policies</a>:</p>

								<pre class="sample">&lt;ENTITY&gt;

								  &lt;DATA-GROUP&gt;

								    &lt;EXTENSION&gt;

								      &lt;datatype&gt;

								        &lt;business&gt;

								          &lt;orgname&gt;

								            CatalogExample

								          &lt;/orgname&gt;

								          &lt;contact-info&gt;

								            &lt;postal&gt;

								              &lt;street&gt;

								                4000 Lincoln Ave.

								              &lt;/street&gt;

								              &lt;city&gt;

								                Birmingham

								              &lt;/city&gt;

								              &lt;state&gt;

								                MI

								              &lt;/state&gt;

								              &lt;postalcode&gt;

								                48009

								              &lt;/postalcode&gt;

								              &lt;country&gt;

								               USA

								              &lt;/country&gt;

								            &lt;/postal&gt;

								&hellip;

								</pre>


								<h2 id="Categories">3.4 Categories and the <code>CATEGORIES</code>

								element</h2>


								<p>Categories are elements inside data elements that provide hints to users

								and user agents as to the intended uses of the data. Categories are vital to

								making P3P user agents easier to implement and use. Categories allow users to

								express more generalized preferences and rules over the exchange of their data

								whereas data elements are intended to describe more specific types and even

								instances of data. Categories SHOULD NOT be used within the <code>DATA</code>

								elements of an <code><a href="#ENTITY">ENTITY</a></code> element.</p>


								<p>The following elements are used to denote data categories:</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[54]</td>

								      <td valign="top"><pre>categories</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;CATEGORIES&gt;" 1*category "&lt;/CATEGORIES&gt;"</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[55]</td>

								      <td valign="top"><pre>category</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;physical/&gt;"    | ; Physical Contact Information

								"&lt;online/&gt;"      | ; Online Contact Information

								"&lt;uniqueid/&gt;"    | ; Unique Identifiers

								"&lt;purchase/&gt;"    | ; Purchase Information

								"&lt;financial/&gt;"   | ; Financial Information

								"&lt;computer/&gt;"    | ; Computer Information

								"&lt;navigation/&gt;"  | ; Navigation and Click-stream Data

								"&lt;interactive/&gt;" | ; Interactive Data

								"&lt;demographic/&gt;" | ; Demographic and Socioeconomic Data

								"&lt;content/&gt;"     | ; Content

								"&lt;state/&gt;"       | ; State Management Mechanisms

								"&lt;political/&gt;"   | ; Political Information

								"&lt;health/&gt;"      | ; Health Information

								"&lt;preference/&gt;"  | ; Preference Data

								"&lt;location/&gt;"    | ; Location Data

								"&lt;government/&gt;   | ; Government-issued Identifiers

								"&lt;other-category&gt;" PCDATA "&lt;/other-category&gt;" ; Other</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>

								<dl>

								  <dt><strong><code>&lt;physical/&gt;</code></strong></dt>

								    <dd><strong>Physical Contact Information</strong>: Information that

								      allows an individual to be contacted or located in the physical world

								      -- such as telephone number or address.</dd>

								  <dt><strong><code>&lt;online/&gt;</code></strong></dt>

								    <dd><strong>Online Contact Information</strong>: Information that allows

								      an individual to be contacted or located on the Internet -- such as

								      email. Often, this information is independent of the specific computer

								      used to access the network. (See the category "Computer

								    Information")</dd>

								  <dt><strong><code>&lt;uniqueid/&gt;</code></strong></dt>

								    <dd><strong>Unique Identifiers</strong>: Non-financial identifiers,

								      excluding government-issued identifiers, issued for purposes of

								      consistently identifying or recognizing the individual. These include

								      identifiers issued by a Web site or service.</dd>

								  <dt><strong><code>&lt;purchase/&gt;</code></strong></dt>

								    <dd><strong>Purchase Information</strong>: Information actively generated

								      by the purchase of a product or service, including information about

								      the method of payment.</dd>

								  <dt><strong><code>&lt;financial/&gt;</code></strong></dt>

								    <dd><strong>Financial Information</strong>: Information about an

								      individual's finances including account status and activity information

								      such as account balance, payment or overdraft history, and information

								      about an individual's purchase or use of financial instruments

								      including credit or debit card information. Information about a

								      discrete purchase by an individual, as described in "Purchase

								      Information," alone does not come under the definition of "Financial

								      Information."</dd>

								  <dt><strong><code>&lt;computer/&gt;</code></strong></dt>

								    <dd><strong>Computer Information</strong>: Information about the computer

								      system that the individual is using to access the network -- such as

								      the IP number, domain name, browser type or operating system.</dd>

								  <dt><strong><code>&lt;navigation/&gt;</code></strong></dt>

								    <dd><strong>Navigation and Click-stream Data</strong>: Data

								      <em>passively</em> generated by <em>browsing</em> the Web site -- such

								      as which pages are visited, and how long users stay on each page.</dd>

								  <dt><strong><code>&lt;interactive/&gt;</code></strong></dt>

								    <dd><strong>Interactive Data</strong>: Data <em>actively</em> generated

								      from or reflecting <em>explicit interactions</em> with a service

								      provider through its site -- such as queries to a search engine, or

								      logs of account activity.</dd>

								  <dt><strong><code>&lt;demographic/&gt;</code></strong></dt>

								    <dd><strong>Demographic and Socioeconomic Data</strong>: Data about an

								      individual's characteristics -- such as gender, age, income, postal

								      code, or geographic region</dd>

								  <dt><strong><code>&lt;content/&gt;</code></strong></dt>

								    <dd><strong>Content</strong> : The words and expressions contained in the

								      body of a communication -- such as the text of email, bulletin board

								      postings, or chat room communications.</dd>

								  <dt><strong><code>&lt;state/&gt;</code></strong></dt>

								    <dd><strong>State Management Mechanisms</strong>: Mechanisms for

								      maintaining a stateful session with a user or automatically recognizing

								      users who have visited a particular site or accessed particular content

								      previously -- such as HTTP cookies.</dd>

								  <dt><strong><code>&lt;political/&gt;</code></strong></dt>

								    <dd><strong>Political Information</strong>: Membership in or affiliation

								      with groups such as religious organizations, trade unions, professional

								      associations, political parties, etc.</dd>

								  <dt><strong><code>&lt;health/&gt;</code></strong></dt>

								    <dd><strong>Health Information</strong>: information about an

								      individual's physical or mental health, sexual orientation, use or

								      inquiry into health care services or products, and purchase of health

								      care services or products.</dd>

								  <dt><strong><code>&lt;preference/&gt;</code></strong></dt>

								    <dd><strong>Preference Data</strong>: Data about an individual's likes

								      and dislikes -- such as favorite color or musical tastes.</dd>

								  <dt><strong><code>&lt;location/&gt;</code></strong></dt>

								    <dd><strong>Location Data</strong>: Information that can be used to

								      identify an individual's current physical location and track them as

								      their location changes -- such as GPS position data.</dd>

								  <dt><code><strong>&lt;government/&gt;</strong></code></dt>

								    <dd><strong>Government-issued Identifiers</strong>: Identifiers issued by

								      a government for purposes of consistently identifying the

								    individual.</dd>

								  <dt><strong><code>&lt;other-category&gt;</code> <em>string</em>

								  <code>&lt;/other-category&gt;</code></strong></dt>

								    <dd><strong>Other</strong>: Other types of data not captured by the above

								      definitions. (A human readable explanation should be provided in these

								      instances, between the <code>&lt;other-category&gt;</code> and the

								      <code>&lt;/other-category&gt;</code> tags.)</dd>

								</dl>


								<p>The <strong>Computer</strong>, <strong>Navigation</strong>,

								<strong>Interactive</strong> and <strong>Content</strong> categories can be

								distinguished as follows. The Computer category includes information about

								the user's computer including IP address and software configuration.

								Navigation data describes actual user behavior related to browsing. When an

								IP address is stored in a log file with information related to browsing

								activity, both the Computer category and the Navigation category should be

								used. Interactive Data is data actively solicited to provide some useful

								service at a site beyond browsing. Content is information exchanged on a site

								for the purposes of communication.</p>


								<p>The <strong>Other</strong> category SHOULD be used only when data is

								requested that does not fit into any other category.</p>


								<p>P3P uses categories to give users and user agents additional hints as to

								what type of information is requested from a service. While most data in the

								base data schema is in a known category (or a set of known categories), some

								data elements can be in a number of different categories, depending on the

								situation. The former are called <em>fixed-category data elements</em> (or

								"fixed data elements" for short), the latter <em>variable-category data

								elements</em> ("variable data elements"). Both types of elements are

								described in <a href="#Data_Schemas_categories">Section 5.2.2</a>.</p>


								<h2 id="extension">3.5 Extension Mechanism: the

								<code>EXTENSION</code> element</h2>


								<p>P3P provides a flexible and powerful mechanism to extend its syntax and

								semantics using one element: <code>EXTENSION</code>. This element is used to

								indicate portions of the policy/policy reference file/data schema which

								belong to an extension. The meaning of the data within the

								<code>EXTENSION</code> element is defined by the extension itself.</p>

								<dl>

								  <dt><strong><code>&lt;EXTENSION&gt;</code></strong></dt>

								    <dd>describes an extension to the syntax</dd>

								  <dt><strong><code>optional</code></strong></dt>

								    <dd>This attribute determines if the extension is <em>mandatory</em> or

								      <em>optional</em>. A <em>mandatory</em> extension is indicated by

								      giving the <code>optional</code> attribute a value of <code>no</code>.

								      A <em>mandatory</em> extension to the P3P syntax means that

								      applications that do not understand this extension cannot understand

								      the meaning of the whole policy (or policy reference file, or data

								      schema) containing it. An <em>optional</em> extension, indicated by

								      giving the optional attribute a value of <code>yes</code>, means that

								      applications that do not understand this extension can safely ignore

								      the contents of the <code>EXTENSION</code> element, and proceed to

								      process the whole policy (or policy reference file, or data schema) as

								      usual. The <code>optional</code> attribute is not required; its default

								      value is <code>yes</code>.</dd>

								</dl>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[56]</td>

								      <td valign="top"><pre>extension</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td><pre>"&lt;EXTENSION" [" optional=" `"` ("yes"|"no") `"`] "&gt;" PCDATA "&lt;/EXTENSION&gt;"</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<p>For example, if www.catalog.example.com would like to add to P3P a feature

								to indicate that a certain set of data elements were only to be collected

								from users living in the United States, Canada, or Mexico, it could add a

								mandatory extension like this:</p>

								<pre class="sample">&lt;DATA-GROUP&gt;

								...

								&lt;EXTENSION optional="no"&gt;

								&lt;COLLECTION-GEOGRAPHY type="include" xmlns="http://www.catalog.example.com/P3P/region"&gt;

								&lt;USA/&gt;&lt;Canada/&gt;&lt;Mexico/&gt;

								&lt;/COLLECTION-GEOGRAPHY&gt;

								&lt;/EXTENSION&gt;

								&lt;/DATA-GROUP&gt;</pre>


								<p>On the other hand, if www.catalog.example.com would like to add an

								extension stating what country the server is in, an optional extension might

								be more appropriate, such as the following:</p>

								<pre class="sample">&lt;POLICY&gt;

								&lt;EXTENSION optional="yes"&gt;

								&lt;ORIGIN xmlns="http://www.catalog.example.com/P3P/origin" country="USA"/&gt;

								&lt;/EXTENSION&gt;

								...

								&lt;/POLICY&gt;</pre>


								<p>The <code>xmlns</code> attribute is significant since it specifies the

								namespace for interpreting the names of elements and attributes used in the

								extension. Note that, as specified in [<a href="#XML-Name">XML-Name</a>], the

								namespace URI is just intended to be a unique identifier for the XML entities

								used by the extension. Nevertheless, service providers MAY provide a page

								with a description of the extension at the corresponding URI.</p>


								<p>The <code>EXTENSION</code> element can appear in various places within P3P

								syntax: such positions are normatively specified by the

								<a href="http://www.w3.org/TR/P3P/#Appendix_schema">P3P 1.0 XML Schema</a>

								(and, informally specified by the ABNF syntax..</p>


								<h2 id="PREFERENCES">3.6 User Preferences</h2>


								<p>User agents MUST document a method by which preferences can be imported

								and processed, and SHOULD document a method by which preferences can be

								exported.</p>


								<p>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.</p>

								</div>


								<div id="compact_policies">


								<h1>4. Compact Policies</h1>


								<p>Compact policies are a performance optimization

								that is OPTIONAL for both user agents and servers. They represent only a

								summary of a site's full P3P policy for a cookie; the full P3P policy is the

								authoritative statement of policy. However, if a site makes compact policy

								statements, it MUST make these statements in good faith. 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.</p>


								<p>User agents that use compact policies as part of their decision making

								MUST include a mechanism that allows users to determine that a particular

								decision was made based on a compact policy and to view that compact policy.

								However, user agents that provide general information about a site's P3P

								policies to users MUST use the full P3P policy and MUST NOT use the compact

								policy for this purpose.</p>


								<p>In P3P, compact policies contain policy information related to cookies

								(cf. [<a href="#ref_COOKIES">COOKIES</a>] and [<a

								href="#ref_STATE">STATE</a>]) only. 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.</p>


								<h2 id="referencing_compact_policies">4.1 Referencing compact policies</h2>


								<p>Any HTTP resource MAY include a P3P compact policy through the P3P

								response header (cf. <a href="#syntax_ext">Section 2.2.2</a>). If a site is

								using P3P headers, it SHOULD include this on responses for all appropriate

								request methods, including <code>HEAD</code> and <code>OPTION</code>

								requests.</p>


								<p>The P3P compact policy header has a quoted string that may contain one or

								more delimited tokens (the "compact policy"). Tokens can appear in any order,

								and the space character (" ") is the only valid delimiter. The syntax for

								this header is as follows:</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[57]</td>

								      <td valign="top"><pre>compact-policy-field</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>`CP="` compact-policy `"`</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[58]</td>

								      <td valign="top"><pre>compact-policy</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>compact-token *(" " compact-token)</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[59]</td>

								      <td valign="top"><pre>compact-token</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>compact-access           |

								compact-disputes         |

								compact-remedies         |

								compact-non-identifiable |

								compact-purpose          |

								compact-recipient        |

								compact-retention        |

								compact-categories       |

								compact-test</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<p>As for all HTTP headers, the name of the P3P header field is

								case-insensitive. The field-value (i.e., the content of the header) is

								instead case sensitive.</p>


								<p>If an HTTP response includes more than one compact policy, P3P user agents

								MUST ignore all compact policies after the first one.</p>


								<h2 id="compact_policy_vocabulary">4.2 Compact Policy Vocabulary</h2>


								<p>P3P compact policies use tokens representing the following elements from

								the P3P vocabulary: <code>ACCESS</code>, <code>CATEGORIES</code>,

								<code>DISPUTES</code>, <code>NON-INDENTIFIABLE</code>, <code>PURPOSE</code>,

								<code>RECIPIENT</code>, <code>REMEDIES</code>, <code>RETENTION</code>,

								<code>TEST</code>.</p>


								<p>If a token appears more than once in a single compact policy, the compact

								policy has <em>the same semantics</em> as if that token appeared only once.

								If an unrecognized token appears in a compact policy, the compact policy has

								<em>the same semantics</em> as if that token was not present.</p>


								<p>The P3P compact policy vocabulary is expressed using a developer-readable

								language to reduce the number of bytes transferred over the wire within a

								HTTP response header. The syntax of the tokens follows:</p>


								<h3 id="compact_access">4.2.1 Compact <code>ACCESS</code></h3>


								<p>Information in the <code>ACCESS</code> element is represented in compact

								policies using tokens composed by a three letter code:</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[60]</td>

								      <td valign="top"><pre>compact-access</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"NOI" | ; for &lt;nonident/&gt;

								"ALL" | ; for &lt;all/&gt;

								"CAO" | ; for &lt;contact-and-other/&gt;

								"IDC" | ; for &lt;ident-contact/&gt;

								"OTI" | ; for &lt;other-ident/&gt;

								"NON"   ; for &lt;none/&gt;</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="compact_disputes">4.2.2 Compact <code>DISPUTES</code></h3>


								<p>If a full P3P policy contains a <code>DISPUTES-GROUP</code> element that

								contains one or more <code>DISPUTES</code> elements, then the server should

								signal the user agent by providing a <strong>single</strong>

								"<code>DSP</code>" token in the P3P-compact policy field:</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[61]</td>

								      <td valign="top"><pre>compact-disputes</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"DSP" ; there are some DISPUTES</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="compact_remedies">4.2.3 Compact <code>REMEDIES</code></h3>


								<p>Information in the <code>REMEDIES</code> element is represented in compact

								policies as follows:</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[62]</td>

								      <td valign="top"><pre>compact-remedies</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"COR" | ; for &lt;correct/&gt;

								"MON" | ; for &lt;money/&gt;

								"LAW"   ; for &lt;law/&gt;</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="compact_non_identifiable">4.2.4 Compact <code>NON-IDENTIFIABLE</code></h3>


								<p>The presence of the <code>NON-IDENTIFIABLE</code> element in every

								statement of the policy is signaled by the <code>NID</code> token (note that

								the <code>NID</code> token MUST NOT be used unless the

								<code>NON-IDENTIFIABLE</code> element is present in every statement within

								the policy):</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[63]</td>

								      <td valign="top"><pre>compact-non-identifiable</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"NID" ; for &lt;NON-IDENTIFIABLE/&gt;</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="compact_purposes">4.2.5 Compact <code>PURPOSE</code></h3>


								<p>Purposes are expressed in P3P compact policy format using tokens composed

								by a three letter code plus an optional one letter attribute. Such an

								optional attribute encodes the value of the "<code>required</code>" attribute

								in full P3P policies: its value can be "<code>a</code>", "<code>i</code>" and

								"<code>o</code>", which mean that the "<code>required</code>" attribute in

								the corresponding P3P policy must be set to "<code>always</code>",

								"<code>opt-in</code>" and "<code>opt-out</code>" respectively.</p>


								<p>If a P3P compact policy needs to specify one or more other-purposes in its

								full P3P policy, a single <code>OTP</code> flag is used to signal the user

								agent that other-purposes exist in the full P3P policy.</p>


								<p>The corresponding associations among P3P purposes and compact policy codes

								follow:</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[64]</td>

								      <td valign="top"><pre>compact-purpose</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"CUR"        | ; for &lt;current/&gt;

								"ADM" [creq] | ; for &lt;admin/&gt;

								"DEV" [creq] | ; for &lt;develop/&gt;

								"TAI" [creq] | ; for &lt;tailoring/&gt;

								"PSA" [creq] | ; for &lt;pseudo-analysis/&gt;

								"PSD" [creq] | ; for &lt;pseudo-decision/&gt;

								"IVA" [creq] | ; for &lt;individual-analysis/&gt;

								"IVD" [creq] | ; for &lt;individual-decision/&gt;

								"CON" [creq] | ; for &lt;contact/&gt;

								"HIS" [creq] | ; for &lt;historical/&gt;

								"TEL" [creq] | ; for &lt;telemarketing/&gt;

								"OTP" [creq]   ; for &lt;other-purpose/&gt;</pre>

								      </td>

								    </tr>

								    <tr>

								      <td valign="top">[65]</td>

								      <td valign="top"><pre>creq</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"a"| ;"always"

								"i"| ;"opt-in"

								"o"  ;"opt-out"</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="compact_recipients">4.2.6 Compact <code>RECIPIENT</code></h3>


								<p>Recipients are expressed in P3P compact policy format using a three letter

								code plus an optional one letter attribute. Such an optional attribute

								encodes the value of the "<code>required</code>" attribute in full P3P

								policies: its value can be "<code>a</code>", "<code>i</code>" and

								"<code>o</code>", which mean that the "<code>required</code>" attribute in

								the corresponding P3P policy must be set to "<code>always</code>",

								"<code>opt-in</code>" and "<code>opt-out</code>" respectively.</p>


								<p>The corresponding associations among P3P recipients and compact policy

								codes follow:</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[66]</td>

								      <td valign="top"><pre>compact-recipient</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"OUR"        | ; for &lt;ours/&gt;

								"DEL" [creq] | ; for &lt;delivery/&gt;

								"SAM" [creq] | ; for &lt;same/&gt;

								"UNR" [creq] | ; for &lt;unrelated/&gt;

								"PUB" [creq] | ; for &lt;public/&gt;

								"OTR" [creq]   ; for &lt;other-recipient/&gt;</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="compact_retention">4.2.7 Compact <code>RETENTION</code></h3>


								<p>Information in the <code>RETENTION</code> element is represented in

								compact policies as follows:</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[67]</td>

								      <td valign="top"><pre>compact-retention</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"NOR" | ; for &lt;no-retention/&gt;

								"STP" | ; for &lt;stated-purpose/&gt;

								"LEG" | ; for &lt;legal-requirement/&gt;

								"BUS" | ; for &lt;business-practices/&gt;

								"IND"   ; for &lt;indefinitely/&gt;</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="compact_categories">4.2.8 Compact <code>CATEGORIES</code></h3>


								<p>Categories are represented in compact policies as follows:</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[68]</td>

								      <td valign="top"><pre>compact-categories</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"PHY" | ; for &lt;physical/&gt;

								"ONL" | ; for &lt;online/&gt;

								"UNI" | ; for &lt;uniqueid/&gt;

								"PUR" | ; for &lt;purchase/&gt;

								"FIN" | ; for &lt;financial/&gt;

								"COM" | ; for &lt;computer/&gt;

								"NAV" | ; for &lt;navigation/&gt;

								"INT" | ; for &lt;interactive/&gt;

								"DEM" | ; for &lt;demographic/&gt;

								"CNT" | ; for &lt;content/&gt;

								"STA" | ; for &lt;state/&gt;

								"POL" | ; for &lt;political/&gt;

								"HEA" | ; for &lt;health/&gt;

								"PRE" | ; for &lt;preference/&gt;

								"LOC" | ; for &lt;location/&gt;

								"GOV" | ; for &lt;government/&gt;

								"OTC"   ; for &lt;other-category/&gt;</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<p>Note that if a P3P policy specifies one or more

								<code>other-category</code> in its full P3P policy, a <strong>single</strong>

								<code>OTC</code> token is used to signal the user agent that

								<code>other-category</code>'s exist in the full P3P policy.</p>


								<h3 id="compact_test">4.2.9 Compact <code>TEST</code></h3>


								<p>The presence of the <code>TEST</code> element is signaled by the

								<code>TST</code> token:</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[69]</td>

								      <td valign="top"><pre>compact-test</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"TST" ; for &lt;TEST/&gt;</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="compact_statement">4.2.10 Compact <code>STATEMENT</code></h3>


								<p>The STATEMENT element is represented in compact policies using the curly

								brace { } symbols. The { represents the opening STATEMENT tag and the }

								represents the closing statement tag.</p>


								<p>The syntax of the compact statement corresponds to the syntax of the full

								statement. Unless it surrounds a compact NON-IDENTIFIABLE element, each pair

								of braces MUST surround one compact RETENTION element and at least one of

								each of the following compact elements: PURPOSE, RECIPIENT, and CATEGORIES.

								Alternatively, a pair of braces may surround a compact NON-IDENTIFIABLE

								element; optionally any of the PURPOSE, RECIPIENT, and CATEGORIES elements;

								and optionally a RETENTION element.</p>


								<p>A compact policy that has an improperly matching pair of curly braces or

								is missing one of the required statement elements MUST be treated as if no

								curly braces are present.</p>


								<p>A compact policy may contain one or more statements. A compact policy with

								no {} elements is considered to have a single implied statement element.</p>


								<p>It is reminded here that the <code>&lt;our-host&gt;</code> compact token

								can be used here. The <code>OHO</code> token is specified in

								the section on <a href="#oho_ex">Domain Relationships</a>.</p>


								<table class="abnf" summary="BNF-syntax" border="0" cellpadding="0" cellspacing="0" width="100%">

								  <tbody>

								    <tr>

								      <td valign="top">[70]</td>

								      <td valign="top"><pre>compact-statement</pre>

								      </td>

								      <td valign="top"><pre>=</pre>

								      </td>

								      <td valign="top"><pre>"{" ; for &lt;STATEMENT&gt;

								((compact-retention compact-purpose compact-recipient 1*compact-categories) |

								 (compact-non-identifiable [compact-purpose] [compact-recipient]

								 [compact-retention] *[compact-categories]))

								"}" ; for &lt;/STATEMENT&gt;</pre>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h2 id="compact_policy_scope">4.3 Compact Policy Scope</h2>


								<p>When a P3P compact policy is included in a HTTP response header, it

								applies to cookies set by the current response. This includes cookies set

								through the use of a HTTP <code>SET-COOKIE</code> header or cookies set by

								script.</p>


								<h2 id="compact_policy_lifetime">4.4 Compact Policy Lifetime</h2>


								<p>To use compact policies, the validity of the full P3P policy must span the

								lifetime of the cookie. There is no method to indicate that policy is valid

								beyond the life of the cookie because the value of user agent caching is

								marginal, since sites would not know when to optimize by not sending the

								compact policy. When a server sends a compact policy, it is asserting that

								the compact policy and corresponding full P3P policy will be in effect for at

								least the lifetime of the cookie to which it applies.</p>


								<h2 id="full_into_compact">4.5 Transforming a P3P Policy to a Compact

								Policy</h2>


								<p>When using P3P compact policies, the Web site is responsible for building

								a compact policy by summarizing the policy referenced by the

								<code>COOKIE-INCLUDE</code> elements of a P3P policy reference file. If a

								site's policy reference file uses <code>COOKIE-EXCLUDE</code> elements then

								the site will need to manage sending the correct P3P compact policies to the

								user agent given the cookies set in a specific response.</p>


								<p>The transformation of a P3P policy to a P3P compact policy may result in a

								loss of descriptive policy information -- the compact policy may not contain

								all of the policy information specified in the full P3P policy. The

								information from the full policy that is discarded when building a compact

								policy includes expiry, data group/data-schema elements, entity elements,

								consequences elements, and disputes elements are reduced.</p>


								<p>Full policies that include mandatory extensions MUST NOT be represented as

								compact policies.</p>


								<p>The P3P 1.0 specification required that all purposes, recipients, and

								categories that appear in multiple statements in a full policy be aggregated

								in a compact policy, as described in section 3.3.1. With the addition of the

								compact <code>STATEMENT</code> element in P3P 1.1, this is no longer

								necessary, although it is still permitted. When performing the aggregation, a

								Web site MUST disclose all relevant tokens (for instance, observe Example

								4.1, where multiple retention policies are specified.)</p>


								<p>In addition, for each fixed category data element appearing in a statement

								the associated category as defined in the associated schema MUST be included

								in the compact policy.</p>


								<p><strong>Example 4.1:</strong></p>


								<p>Consider the following P3P policy:</p>

								<pre class="sample">&lt;POLICY name="sample"

								 discuri="http://www.example.com/cookiepolicy.html"

								 opturi="http://www.example.com/opt.html"&gt;

								  &lt;ENTITY&gt;

								    &lt;DATA-GROUP&gt;

								      &lt;DATA ref="#business.name"&gt;Example, Corp.&lt;/DATA&gt;

								      &lt;DATA ref="#business.contact-info.online.email"&gt;privacy@example.com&lt;/DATA&gt;

								    &lt;/DATA-GROUP&gt;

								  &lt;/ENTITY&gt;

								  &lt;ACCESS&gt;&lt;none/&gt;&lt;/ACCESS&gt;

								  &lt;DISPUTES-GROUP&gt;

								    &lt;DISPUTES resolution-type="service"

								     service="http://www.example.com/privacy.html"

								     short-description="Please contact our customer service desk with

								     privacy concerns by emailing privacy@example.com"/&gt;

								  &lt;/DISPUTES-GROUP&gt;

								  &lt;STATEMENT&gt;

								    &lt;PURPOSE&gt;

								      &lt;admin/&gt;

								      &lt;develop/&gt;

								      &lt;pseudo-decision/&gt;

								    &lt;/PURPOSE&gt;

								    &lt;RECIPIENT&gt;

								      &lt;ours/&gt;

								    &lt;/RECIPIENT&gt;

								    &lt;RETENTION&gt;

								      &lt;indefinitely/&gt;

								    &lt;/RETENTION&gt;

								    &lt;DATA-GROUP&gt;

								      &lt;DATA ref="#dynamic.cookies"&gt;

								        &lt;CATEGORIES&gt;

								          &lt;preference/&gt;

								          &lt;navigation/&gt;

								        &lt;/CATEGORIES&gt;

								      &lt;/DATA&gt;

								    &lt;/DATA-GROUP&gt;

								  &lt;/STATEMENT&gt;

								  &lt;STATEMENT&gt;

								    &lt;PURPOSE&gt;

								      &lt;individual-decision required="opt-out"/&gt;

								    &lt;/PURPOSE&gt;

								    &lt;RECIPIENT&gt;

								      &lt;ours/&gt;

								    &lt;/RECIPIENT&gt;

								    &lt;RETENTION&gt;

								      &lt;stated-purpose/&gt;

								    &lt;/RETENTION&gt;

								    &lt;DATA-GROUP&gt;

								      &lt;DATA ref="#user.name.given"/&gt;

								      &lt;DATA ref="#dynamic.cookies"&gt;

								        &lt;CATEGORIES&gt;

								          &lt;preference/&gt;

								          &lt;uniqueid/&gt;

								        &lt;/CATEGORIES&gt;

								      &lt;/DATA&gt;

								    &lt;/DATA-GROUP&gt;

								  &lt;/STATEMENT&gt;

								&lt;/POLICY&gt;</pre>


								<p>The corresponding compact aggregated policy is:</p>

								<pre class="sample">"NON DSP ADM DEV PSD IVDo OUR IND STP PHY PRE NAV UNI"</pre>


								<p>The corresponding compact policy using the new compact

								grouping mechanism called <code>compact-statement</code>:</p>

								<pre class="sample">"NON DSP { ADM DEV PSD OUR IND PRE NAV } { IVDo OUR STP PHY PRE UNI }"</pre>

								</div>


								<div id="Data_Schemas">


								<h1>5. Data Schemas</h1>


								<h2 id="Data_Schemas_intro">5.1. Introduction</h2>


								  <p>Each <code>STATEMENT</code> element in a P3P Policy must

								  define the data type to which it applies using a

								  <code>DATA-GROUP</code> element.  A <em>data schema</em> is a

								  description of the set of data types which may be used within

								  policy <code>DATA-GROUP</code> elements.  A data schema is a hierarchical

								  set of data types of increasing granularity, which

								  allow P3P <code>DATA-GROUP</code> elements to describe the  specific classes

								  of data a service is actually or potentially collecting collect. Policies may

								  use either the Base Data Schema provided by this specification, or may create

								  custom data schemas according to the rules set out in <a

								  href="#Data_Schemas_new">section 5.3</a></p>


								  <p> <code>STATEMENT</code> data types may be specified to different levels

								  of granularity. For example, <code>STATEMENTS</code> may declare that they

								  collect data which are: </p>


								    <ol>

								      <li> Of type <q>user</q> (&lt;user/&gt;) or</li>

								      <li> Of type <q>user, homeinfo AND online: </q>


								<pre class="sample">&lt;user&gt;

								  &lt;homeinfo&gt;

								    &lt;online/&gt;

								  &lt;/homeinfo&gt;

								&lt;/user&gt;:

								</pre>

								      i.e. data such as a person's email address which is both

								      user data, home info data and online data. This is obviously

								      a more granular description than just "User". In set theory

								      terms, we mean the intersection of these 3 classes</li>

								    </ol>


								  <p><em>For a given <code>STATEMENT</code> data type declared, it must be

								  assumed that all levels of detail below the lowest type in the

								  hierarchy are also collected</em>. So in the above example if

								  the <code>STATEMENT</code> only specifies collection of User data (case 1.)

								  then for evaluation purposes, it should be assumed that the

								  service also collects data such as a user's work address,

								  navigation data etc&hellip;. In the second case however, it should

								  be assumed that the service collects only a user's home online

								  data - i.e. home email and uri. The more general the type you

								  choose (the higher in the hierarchy), the more data types you

								  are making statements about.</p>


								  <p>Note that for the purposes of evaluating

								  a <code>STATEMENT</code>, user agents MUST interpret <em>MAY

								  collect</em> as conservatively as possible and assume that any

								  data types mentioned, <em>WILL be collected</em>.

								  However for the purposes of data collection, <code>STATEMENT</code> elements

								  MUST NOT be understood as a request for data for all the data types

								  declared.</p>


								  <p> The structure of the default hierarchy of types is

								  described in the <a href="#base_data_structure">base data

								  structure</a> section. P3P 1.1. provides a new format for

								  expressing P3P data schemas in a simpler way than P3P 1.0.

								  The hierarchy of the P3P 1.1 data schema is

								  <em>based on</em> the hierarchy of the <a

								  href="http://www.w3.org/TR/P3P/#Data_Schemas">P3P 1.0 data

								  schema</a> but is expressed using standard XML syntax.  A

								  description of the <a

								  href="http://www.w3.org/TR/P3P/#Data_Schemas">P3P 1.0 data

								  schema</a> can be referenced in the P3P 1.0 Specification The

								  new format uses <a

								  href="http://www.w3.org/TR/xmlschema-1/">Structures</a> and

								  the more general <a

								  href="http://www.w3.org/TR/xmlschema-2/">Datatypes</a> which

								  can be validated against an XML schema.</p>


								<h3 id="Data_Schemas_overview">5.1.1. P3P 1.1 Data Element Syntax

								Overview</h3>


								  <p>The P3P 1.1 Data Schema is an XML schema which describes

								  elements organized in a hierarchy of increasing specificity.

								  The elments in higher places include all allowed subtypes. An element high

								  up in the hierarchy thus contains all the meaning of the allowed subtypes,

								  unless the collected subtypes are declared by inserting a child element.</p>


								  <p>For example</p>

								<pre class="sample">&lt;datatype&gt;

								  &lt;user/&gt;

								&lt;/datatype&gt;</pre>


								  <p>means: "the service may collect any of the allowed subtypes

								  of user data" (name,birthdate,login, cert etc....) Furthermore

								  this property is carried through to all the subtypes of these

								  elements. So collecting user data also means collecting login-id

								  and login-password etc &hellip;</p>


								<p>If instead the following is specified:</p>


								<pre class="sample">&lt;datatype&gt;

								  &lt;user&gt;

								    &lt;cert&gt;

								      &lt;key/&gt;

								    &lt;/cert&gt;

								  &lt;/user&gt;

								&lt;/datatype&gt;</pre>


								  <p>this means that the service may only collect the user's

								  certificate key and nothing else.</p>


								  <p>P3P defines a default data schema called the <em>P3P base data

								  schema</em> that includes a large number of data elements commonly

								  used by services. The elements of the base data schema, their names

								  and meanings were properly internationalized. Note that the data element

								  names specified in the base data schema or in custom data schemas may be

								  used for purposes other than P3P policies. For example, Web sites may

								  use these names to label HTML form fields. By referring to data

								  the same way in P3P policies and forms, automated form-filling

								  tools can be better integrated with P3P user agents. Note

								  however that automatic form filling tools cannot deal with

								  abstract data types (i.e. types must specify how they are

								  instantiated. For example &lt;user/&gt; is abstract but

								  &lt;user&gt;&lt;name&gt;&lt;prefix/&gt;&lt;/name&gt;&lt;/user&gt;

								  can be instantiated.)</p>


								<h2 id="Data_Schemas_types">5.2. How to express data types in P3P

								Policies</h2>


								<h3 id="Data_Schemas_basics">5.2.1 Basics</h3>


								  <p>The following is an example instance of a P3P1.1 compliant

								  datatype element. Full details of the data schema hierarchy are

								  given in <a href="#base_data_structure">section 5.5.</a>. Details on backward

								  compatibility are given in <a href="#Data_Schemas_back">section

								  5.7</a></p>


								<pre class="sample">&lt;DATA-GROUP&gt;

								  &lt;EXTENSION&gt;

								    &lt;datatype optional="yes"&gt;

								      &lt;dynamic&gt;

								        &lt;cookies&gt;

								          &lt;categories&gt;

								            &lt;preference/&gt;

								          &lt;/categories&gt;

								        &lt;/cookies&gt;

								        &lt;clickstream/&gt;

								      &lt;/dynamic&gt;

								    &lt;/datatype&gt;

								  &lt;/EXTENSION&gt;

								  &lt;DATA ref="#dynamic.clickstream"&gt;

								    &lt;categories&gt;preference&lt;/categories&gt;

								  &lt;/DATA&gt;

								&lt;/DATA-GROUP&gt;</pre>


								<p>This example shows the following aspects of how to use data elements in

								P3P 1.1:</p>

								<ul>

								  <li>All data types are expressed as children of a <code>datatype</code>

								    element.</li>

								  <li>The optional attribute of the <code>datatype</code> element indicates

								    whether or not the site requires visitors to submit

								    this type of data in order 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.".</li>

								  <li>Under this are nested elements describing the types of data that the

								    P3P <code>STATEMENT</code> is about. The hierarchy of these elements is described in

								    detail in <a href="#base_data_structure">section 5.5 Structure of Base

								    Data Schema</a>.</li>

								  <li>Greater levels of detail in the specification of a data type are

								    expressed by using allowed children of a particular data type, according

								    to the scheme expressed in the P3P 1.1 Data Schema. Nesting corresponds

								    to increasing specificity of possible data collected, so for instance in

								    the above example, the meaning of the data element is that the controller

								    of the policy may collect data of type <code>dynamic</code>, but only the

								    subclass of <code>dynamic data</code> which is also <code>clickstream

								    data</code>.</li>

								  <li>Elements may be nested as siblings. For example:


								<pre class="sample">

								&lt;user&gt;

								  &lt;name/&gt;

								  &lt;bdate/&gt;

								&lt;/user&gt;

								</pre>


								    <p>Is equivalent to: </p>


								<pre class="sample">

								&lt;user&gt;

								  &lt;name/&gt;

								&lt;/user&gt;

								&lt;user&gt;

								  &lt;bdate/&gt;

								&lt;/user&gt;

								</pre>


								    </li>

								  <li>Natural language descriptors of the meaning of these elements are found

								    in the Data Schema and therefore should not be included in policy

								    instances. The human readable descriptor corresponds to an XSD annotation

								    beneath the element it refers to, of format:


								<pre class="sample">&lt;annotation&gt;

								  &lt;documentation&gt;

								   HTTP Protocol Information

								  &lt;/documentation&gt;

								  &lt;appinfo&gt;

								    &lt;categories&gt;

								      &lt;navigation/&gt;

								      &lt;computer/&gt;

								    &lt;/categories&gt;

								  &lt;/appinfo&gt;

								&lt;/annotation&gt;

								</pre>

								  </li>

								  <li>User agents SHOULD use these descriptors when rendering data types in

								    human readable format (for example in a human readable translation of a

								    P3P policy).</li>

								  <li>Variable-category data elements (in the base data schema this means:

								   &lt;dynamic&gt; &lt;cookies/&gt; &lt;/dynamic&gt; and &lt;dynamic&gt;

								   &lt;miscdata/&gt; &lt;/dynamic&gt;), MUST specify the categories of

								   the data collected using &lt;categories/&gt; element.

								   Although all other data elements have categories assigned to them

								   when they are defined in a data schema, elements used in policies

								   must specify categories only for so-called "variable-category"

								   elements (those which do not define categories in the schema).

								   For more information, see 5.2.2 <a href="#Data_Schemas_categories">

								   Categories</a> for more information on categories.

								  </li>

								  <li> Specifying <code>categories</code> for fixed category elements (such as

								   <code>dynamic</code>, <code>clickstream</code> in the above example) has no

								   effect and is not recommended. All "fixed category" data elements have

								   categories assigned to them when they are defined in a data schema. This only

								   serves as extra semantics for the benefit of rule systems.

								  </li>

								  <li>Most data elements have categories assigned to them when they are

								    defined in a data schema. See 5.2.2 <a

								    href="#Data_Schemas_categories">Categories</a> for more information on

								    categories.

								   </li>

								</ul>


								<h3 id="Data_Schemas_categories">5.2.2 Categories in P3P Data Schemas</h3>


								  <p>Categories are a way of giving a meaning to types of data

								  which may be too general to be contained in specific data

								  types. For example cookie data may contain any kind of

								  information and it is therefore useful to be able to describe

								  whether the cookie data is demographic, navigation etc&hellip;

								  Another example is clickstream data, which may be delimited as

								  navigation, computer or demographic type clickstream data.</p>


								  <p>Categories are used in different ways in writing and

								  evaluating P3P policies.</p>


								<h4 id="variable">5.2.2.1. Use of categories in policies -

								variable category elements</h4>


								  <p><code>Variable-category</code> data elements are elements which do not

								  fit into any specific category because they may contain any

								  kind of information and therefore require the policy writer to

								  specify the category of information which is actually

								  collected.  In P3P policies, the <code>CATEGORIES</code> element is used to

								  specify the type of such variable-category data elements.

								  Services MUST specify at least one category for each

								  variable-category element in a P3P policy, using a <code>CATEGORIES</code>

								  element. Extra categories are appended as siblings below a

								  single <code>CATEGORIES</code> element.</p>


								  <p>In the base data schema, there are only 2 so-called

								  variable-category elements,

								  <code>&lt;dynamic&gt;&lt;cookies/&gt;&lt;/dynamic&gt;</code> and

								  <code>&lt;dynamic&gt;&lt;miscdata/&gt;&lt;/dynamic&gt;</code>. Cookies are

								  defined as variable-category because they contain any kind of

								  personally identifiable data and applications evaluating a

								  policy need more information about what kind of data is stored

								  in a cookie.  The miscdata element acts as a catchall data type

								  which can in effect be used to specify miscellaneous data in a

								  number of the P3P categories.  </p>


								  <p>An element in a custom schema is defined as

								  "variable-category" if it satisfies the following

								  conditions</p>

								  <ol>

								    <li>It has no categories assigned in the XSD documentation,

								    appinfo element.</li>

								    <li>None of its descendent nodes have categories assigned in

								    the XSD documentation, appinfo element.</li>

								  </ol>


								  <p>In this capacity as broad types for variable-category data

								  elements such as cookies, <code>categories</code> can only be assigned as a

								  leaf child of the hierarchy.</p>


								  <p>For example the following is correct syntax:</p>

								<pre class="sample">&lt;p3p11:data-group&gt;

								  &lt;p3p11:datatype&gt;

								    &lt;p3p11:dynamic&gt;

								      &lt;p3p11:cookies&gt;

								        &lt;p3p:CATEGORIES&gt;

								          &lt;p3p:navigation/&gt;

								          &lt;p3p:preference/&gt;

								        &lt;/p3p:CATEGORIES&gt;

								      &lt;/p3p11:cookies&gt;

								    &lt;/p3p11:dynamic&gt;

								  &lt;/p3p11:datatype&gt;

								&lt;/p3p11:data-group&gt;

								</pre>


								  <p>Whereas the following is not:</p>

								<pre class="sample">&lt;p3p11:data-group&gt;

								  &lt;p3p11:datatype&gt;

								    &lt;p3p11:dynamic&gt;

								      &lt;p3p11:cookies/&gt;

								      &lt;p3p:categories&gt;

								        &lt;p3p:navigation/&gt;

								        &lt;p3p:preference/&gt;

								      &lt;/p3p:categories&gt;

								    &lt;/p3p11:dynamic&gt;

								  &lt;/p3p11:datatype&gt;

								&lt;/p3p11:data-group&gt;

								</pre>


								  <p>And nor is the following (no categories specified for a

								  variable-category element):</p>

								<pre class="sample">&lt;p3p11:data-group&gt;

								  &lt;p3p11:datatype&gt;

								    &lt;p3p11:dynamic&gt;

								      &lt;p3p11:cookies/&gt;

								    &lt;p3p11:/dynamic&gt;

								  &lt;p3p11:/datatype&gt;

								&lt;/p3p11:data-group&gt;

								</pre>


								<h4 id="category_rules">5.2.2.2 Use of categories in rules</h4>


								  <p>Categories are intended for use in rule systems such as <a

								  href="http://www.w3.org/TR/P3P/#APPEL">APPEL</a>

								  to allow preference sets to match a broad range of data elements

								  without listing each one individually. Most of the elements in

								  the base data schema are so called <code>fixed data elements</code>:

								  they belong to one or more category classes. By assigning a

								  category invariably to elements or structures in the base data

								  schema, user agent rule systems are able to refer to entire

								  groups of elements simply by referencing the corresponding

								  category. For example, using [<a

								  href="http://www.w3.org/TR/P3P/#APPEL">APPEL</a>], the privacy

								  preferences exchange language, users can write rules that warn

								  them when they visit a site that collects any data element in the

								  navigation category.</p>


								  <p> Categories are assigned to all elements in the XSD schema

								  except variable category elements. Categories for fixed elements

								  are defined using the XSD annotation, appinfo element. These

								  category assignments <em>are never used in policies</em> but add

								  semantics to data types for the purposes of matching. These

								  semantics can then be used by rule systems within user-agents to

								  match ranges of data types according to categories rather than

								  specifying each individual data type.  Rule evaluation engines

								  should extract categories assigned from the <code>appinfo</code> element in

								  data schemas.  Multiple categories may be assigned for example

								  the following element in the base data schema defines the contact

								  data type </p>


								  <pre class="sample">&lt;xsd:element

								 minOccurs="0"

								 name="home-info"

								 type="contactComplexType"&gt;

								  &lt;xsd:annotation&gt;

								    &lt;xsd:appinfo&gt;

								      &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								        &lt;physical /&gt;

								        &lt;online /&gt;

								        &lt;demographic /&gt;

								      &lt;/CATEGORIES&gt;

								    &lt;/xsd:appinfo&gt;

								    &lt;xsd:documentation&gt;

								      User's Home Contact Information

								    &lt;/xsd:documentation&gt;

								  &lt;/xsd:annotation&gt;

								&lt;/xsd:element&gt;</pre>


								  <p>Please note that user agents MUST ignore any categories

								  assigned to fixed-category elements in policies and use the

								  original category (or set of categories) listed in the schema

								  definition for the purposes of rule-matching.</p>


								<h3 id="Data_Schemas_extern">5.2.4 Referencing External Schemas</h3>


								  <p>Data elements or custom schemas may reference elements in

								  other schemas simply by referring to another namespace.</p>


								  <p>Example data element referencing a custom data element:</p>

								<pre class="sample">&lt;datatype

								 xmlns="http://www.example.com/creditcardDataSchema"&gt;

								  &lt;creditCard&gt;

								    &lt;date/&gt;

								  &lt;/creditCard&gt;

								&lt;/datatype&gt;

								</pre>


								<p>For more information, please have a look at <a href="#Data_Schemas_new">

								5.3. Defining New Schemas</a></p>


								  <p>Example schema referencing another schema: </p>


								<h3 id="Data_Schemas_natural">5.2.5 Natural Language description of data

								elements</h3>


								  <p>Natural language descriptions of the meaning of data

								  elements may be found within <code>&lt;annotation&gt;</code>

								  children of the element definition in any P3P1.1 XSD data

								  schema. These may be of 2 kinds:</p>


								  <p><code>&lt;description&gt;A short description for display in

								  data capture summaries.&lt;/description&gt;</code></p>


								  <p><code>&lt;appinfo&gt; &lt;long-description&gt;A long

								  description for documentation purposes&lt;/long-description&gt;

								  &lt;/appinfo&gt; </code> </p>


								  <p>These descriptions are intended to be used by user-agents in

								  creating human-readable translations of policies. They SHOULD

								  NOT however be included in machine readable policies.</p>


								  <p>Services publishing custom data schemas MAY wish to

								  translate these fields into multiple languages. The annotation

								  element's contents MAY be translated, but the element name MUST

								  NOT be translated - this field needs to stay constant across

								  translations of a data schema. If a service is going to provide

								  a data schema in multiple natural languages, then it SHOULD

								  examine the Accept-Language HTTP request-header on requests for

								  that data schema to pick the best available alternative.</p>


								<h2 id="Data_Schemas_new">5.3 Defining new Schemas</h2>


								  <p>Services may declare new data elements by creating and

								  publishing their own data schemas expressed using [<a

								  href="#XML-Schema1">XML-Schema1</a>] or [<a

								  href="#XML-Schema2">XML-Schema2</a>]. These schemas MUST also

								  comply with the following rules over and above the rules of

								  correct XML Schema syntax. </p>


								  <p>Custom schemas:</p>


								  <ol>

								    <li>MUST define a root element named <code>datatype</code> with an

								    <code>optional</code> attribute with allowed values <code>yes/no</code>:

								    See the examples below.</li>

								    <li>MUST define a hierarchy of nested elements corresponding

								    to data types of increasing specificity. (see <a

								    href="#Data_Schemas_semantics">Section 5.3.1</a> for a

								    precise definition of what this means)</li>

								    <li>MUST define any human readable descriptions using

								    xsd:description and xsd:appinfo elements  (see section <a

								    href="#Data_Schemas_natural">5.2.5</a>)</li>

								  </ol>


								  <p>There are some additional requirements relating to the use

								  of categories</p>


								  <p>Custom Schemas:</p>


								  <ol start="4">

								   <li>MUST define a <code>xsd:complexType</code> to reference P3P1.0 categories

								   (this can also be copied from the base data schema - see the examples

								   below)</li>

								   <li>MUST define any <code>variable-category</code> elements by referencing

								   the categories type defined in 1 above. (i.e. they must be required

								   to define at least one category from the P3P schema) For example:


								<pre class="sample">&lt;xsd:element

								 minOccurs="0"

								 name="miscdata"

								 type="categoriesComplexType"&gt;

								  &lt;xsd:annotation&gt;

								    &lt;xsd:documentation&gt;

								     Miscellaneous non-base data schema information

								    &lt;/xsd:documentation&gt;

								  &lt;/xsd:annotation&gt;

								&lt;/xsd:element&gt;</pre>


								   </li>

								   <li>Unless the custom schema author intends to create a

								   <code>variable-category</code> element, <code>categories</code>

								   MUST also be assigned for all elements defined in custom data schemas,

								   according to the scheme of categories defined in the P3P 1.0 schema

								   (see <a href="#Categories">Section 3.4</a> for the complete

								   list of allowed categories).Custom schemas MUST NOT create

								   new categories. If custom schema authors need to create broad

								   types of data which do not fall within the 17 category elements

								   defined by P3P1.1, these may instead be defined within the standard

								   hierarchy of the data schema as top level data types.


								   <p>Categories are assigned using the <code>xsd:appinfo</code> element as in

								   the following example:</p>


								<pre class="sample">

								&lt;xsd:element minOccurs="0" name="CreditCard" type="CC"&gt;

								  &lt;xsd:annotation&gt;

								    &lt;xsd:appinfo&gt;

								      &lt;categories

								       xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								        &lt;financial /&gt;

								        &lt;purchase /&gt;

								        &lt;location /&gt;

								      &lt;/categories&gt;

								    &lt;/xsd:appinfo&gt;

								    &lt;xsd:documentation&gt;

								     Credit Card Data

								    &lt;/xsd:documentation&gt;

								  &lt;/xsd:annotation&gt;

								&lt;/xsd:element&gt;</pre>

								   </li>


								   <li>Categories assigned MUST be upward inherited.

								   That is, if a data type is in a certain category then any

								   broader data types that it is a member of, must also be assigned

								   this category. For example if a given <a href="#URI">URI</a> may collect

								   data in the category online, then User may also collect data in the

								   category online.</li>

								  </ol>


								  <p>In addition, it is helpful for schema readability (but not

								  required) to organize the structure in terms of named and reuseable

								  <code>xsd:complexType</code> elements. For example the base data schema

								  repeatedly reuses the dateComplexType. This also provides additional semantics

								  about the structure of the schema (e.g. the information that a

								  certain set of types are all dates). The syntax used in the P3P

								  base data schema should act as a guide to authors of custom data

								  schemas. The following commented snippet from the base data schema

								  shows good syntax for creating custom schemas and includes all the

								  requirements stated above:</p>


								  <p>Sample of typical syntax for a P3P1.1 schema (commented snippet

								  of base data schema)</p>


								<pre class="sample">&lt;schema

								 xmlns="http://www.w3.org/2001/XMLSchema"

								 xmlns:p3p="http://www.w3.org/2002/01/P3Pv1"

								 xmlns:p3p11="http://www.w3.org/2006/01/P3Pv11"

								 xmlns:p3p11bds="http://www.w3.org/2006/01/P3Pv11BDS"

								 xmlns:example="http://example.org/2006/01/custom"

								 targetNamespace="http://example.org/2006/01/custom"

								 elementFormDefault="qualified" &gt;

								&lt;!-- *****************************************************************************

								  The following section can be cut and pasted into all custom schemas - Start here.

								  All types in the custom schema are descendents of the datatype element.

								******************************************************************************* --&gt;

								  &lt;import

								    namespace="http://www.w3.org/2002/01/P3Pv1"

								    schemaLocation="http://www.w3.org/2002/01/P3Pv1.xsd" /&gt;

								  &lt;import

								    namespace="http://www.w3.org/2006/01/P3Pv11"

								    schemaLocation="http://www.w3.org/2006/01/P3Pv11" /&gt;

								  &lt;import

								    namespace="http://www.w3.org/2006/01/P3Pv11BDS"

								    schemaLocation="http://www.w3.org/2006/01/P3Pv11BDS" /&gt;


								  &lt;complexType name="categoriesComplexType"&gt;

								    &lt;all&gt;

								      &lt;element ref="p3p:categories" minOccurs="1" /&gt;

								    &lt;/all&gt;

								  &lt;/complexType&gt;

								&lt;!-- *****************************************************************************

								  Root type and optional(yes/no) attribute

								******************************************************************************* --&gt;

								  &lt;element name="datatype" type="datadefComplexType" /&gt;

								&lt;!-- *****************************************************************************

								  First child of root

								******************************************************************************* --&gt;

								    &lt;complexType name="datadefComplexType"&gt;

								      &lt;all&gt;

								&lt;!-- *****************************************************************************

								  The preceding section can be cut and pasted into all custom schemas - Finish here

								******************************************************************************* --&gt;

								        &lt;element minOccurs="0" name="dynamic" type="dynamicComplexType" /&gt;

								        &lt;element minOccurs="0" name="user" type="userComplexType" /&gt;

								        &lt;element minOccurs="0" name="thirdparty" type="thirdpartyComplexType" /&gt;

								          &lt;element minOccurs="0" name="business" type="businessComplexType" /&gt;

								      &lt;/all&gt;

								&lt;!--****************************************************************************

								  Also add this attribute definition - optional attribute of datatype element

								***********************************************************************************--&gt;

								      &lt;attribute type="p3p:yes_no" default="no" use="optional" name="optional" /&gt;

								&lt;!--***************************************************************************

								  Also add this attribute definition (above) - optional attribute of datatype element

								*****************************************************************************--&gt;

								    &lt;/complexType&gt;

								&lt;!--***************************************************************************

								  The user data complex type

								*****************************************************************************--&gt;

								   &lt;complexType name="userComplexType"&gt;

								     &lt;all&gt;

								       &lt;element minOccurs="0" name="name" type="personnameComplexType"&gt;

								         &lt;annotation&gt;

								           &lt;appinfo&gt;

								             &lt;p3p:CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								               &lt;physical /&gt;

								               &lt;demographic /&gt;

								             &lt;/p3p:CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;

								            User's Name

								           &lt;/documentation&gt;

								         &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="bdate" type="dateComplexType"&gt;

								         &lt;annotation&gt;

								           &lt;appinfo&gt;

								&lt;!--***************************************************************************

								  Categories defined here

								*****************************************************************************--&gt;

								             &lt;categories xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								               &lt;demographic /&gt;

								             &lt;/categories&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;

								            User's Birth Date

								           &lt;/documentation&gt;

								         &lt;/annotation&gt;

								       &lt;/element&gt;

								       &hellip;etc&hellip;

								     &lt;/all&gt;

								   &lt;/complexType&gt;

								&lt;!--***************************************************************************

								  The dynamic data complex type

								*****************************************************************************--&gt;

								   &lt;complexType name="dynamicComplexType"&gt;

								     &lt;all&gt;

								       &lt;element minOccurs="0" name="clickstream" type="loginfoComplexType"&gt;

								         &lt;annotation&gt;

								           &lt;appinfo&gt;

								             &lt;p3p:CATEGORIES&gt;

								               &lt;p3p:navigation /&gt;

								               &lt;p3p:computer /&gt;

								             &lt;/p3p:CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;

								            Click-stream information

								           &lt;/documentation&gt;

								         &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="http" type="httpinfoComplexType"&gt;

								         &lt;annotation&gt;

								           &lt;appinfo&gt;

								             &lt;p3p:CATEGORIES&gt;

								               &lt;p3p:navigation /&gt;

								               &lt;p3p:computer /&gt;

								             &lt;/p3p:CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;

								            HTTP protocol information

								           &lt;/documentation&gt;

								         &lt;/annotation&gt;

								       &lt;/element&gt;

								           &hellip;etc&hellip;

								&lt;!--***************************************************************************

								  A variable-category element

								*****************************************************************************--&gt;

								       &lt;element minOccurs="0" name="cookies" type="categoriesComplexType"&gt;

								         &lt;annotation&gt;

								           &lt;documentation&gt;

								            Use of HTTP cookies

								           &lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								     &lt;/all&gt;

								   &lt;/complexType&gt;

								     &hellip;etc&hellip;

								&lt;/schema&gt;

								</pre>


								<h3 id="Data_Schemas_semantics">5.3.1 Semantics of data

								schemas</h3>


								  <p>This section defines exactly what is meant by a <em>hierarchy

								  of increasing specicifity</em>.</p>


								  <p>More formally speaking, for an element

								  <code>&lt;B&gt;</code> to be defined as an allowed child of

								  element <code>&lt;A&gt;</code> means if the policy states that

								  it may collect data of type <code>&lt;A&gt;</code>, <em>then it

								  can also be taken to state that it may also collect data of

								  type <code>&lt;B&gt;</code></em>. The inverse relation however

								  does not hold.  Transitivity also holds for this relation. That

								  is, if a policy states that it collects data of type

								  <code>&lt;A&gt;</code> and if <code>&lt;B&gt;</code> is an

								  allowed subelement of <code>&lt;A&gt;</code> and

								  <code>&lt;C&gt;</code> is an allowed subelement of

								  <code>&lt;B&gt;</code>, then it can be assumed that the

								  controller of the policy may also collect data of type

								  <code>&lt;C&gt;</code>. The hierarchy is mirrored by the

								  hierarchy of XML elements used to express them. It should be

								  noted that the use of a particular data element is <em>NOT</em>

								  a request for that particular type of data, or a statement that

								  the data <em>is</em> collected, rather a <em>hypothetical

								  statement</em> that it <em>may</em> be collected.</p>


								<!-- This is a duplication of the assertion in the introduction

								  <p>Note that <em>for the purposes of evaluating policy

								  statements</em>, user agents MUST interpret "MAY collect" as

								  conservatively as possible and assume that any data types which

								  "MAY" be collected, WILL be collected.  However for the

								  purposes of data collection, <code>STATEMENT</code> elements MUST NOT be

								  understood as a request for data including all the types which

								  may be collected.</p>-->


								  <p>For example if <code>&lt;classicalmusicpreference&gt;</code>

								  is defined as an allowed subelement of

								  <code>&lt;musicalpreference&gt;</code>, this means that if a

								  policy statement has the data type</p>


								<pre class="sample">&lt;datatype&gt;

								  &lt;musicalpreference/&gt;

								&lt;/datatype&gt;

								</pre>


								  <p>then it can be assumed that the <code>STATEMENT</code> is also describing

								  the collection of data of classical music preference data.</p>


								  <p>The relationships are also transitive, so

								  <code>&lt;baroquemusicpreference&gt;</code> is understood to be

								  a subclass of <code>&lt;musicalpreference&gt;</code> because it

								  is a subelement of

								  <code>&lt;classicalmusicpreference&gt;</code> which is a

								  subelement of <code>&lt;musicalpreference&gt;</code></p>.

								  <p>This could be expressed in the following XML Schema:</p>


								<pre class="sample">

								&lt;xsd:schema

								 xmlns:xsd="http://www.w3.org/2001/XMLSchema"

								 xmlns:p3p="http://www.w3.org/2002/01/P3Pv1"

								 xmlns:sample="http://example.org/sample"

								 targetNamespace="http://example.org/sample"

								 elementFormDefault="qualified" &gt;

								&lt;!-- *****************************************************************************

								  The following section can be cut and pasted into all custom schemas - Start here.

								  All types in the custom schema are descendents of the datatype element.

								******************************************************************************* --&gt;

								  &lt;xsd:import

								   schemaLocation="http://www.w3.org/2002/01/P3Pv1.xsd"

								   namespace="http://www.w3.org/2002/01/P3Pv1" /&gt;

								    &lt;xsd:complexType name="categoriesComplexType"&gt;

								      &lt;xsd:all&gt;

								        &lt;xsd:element ref="p3p:categories" minOccurs="1" /&gt;

								      &lt;/xsd:all&gt;

								    &lt;/xsd:complexType&gt;

								&lt;!-- *****************************************************************************

								  root type and optional(yes/no) attribute

								******************************************************************************* --&gt;

								  &lt;xsd:element name="datatype" type="datadefComplexType" /&gt;

								&lt;!-- *****************************************************************************

								  first child of root

								******************************************************************************* --&gt;

								    &lt;xsd:complexType name="datadefComplexType"&gt;

								      &lt;xsd:all&gt;

								&lt;!-- *****************************************************************************

								  The preceding section can be cut and pasted into all custom schemas - Finish here

								******************************************************************************* --&gt;

								        &lt;xsd:element minOccurs="0"

								         name="musical-preference"

								         type="musical-preferenceComplexType"&gt;

								          &lt;xsd:annotation&gt;

								            &lt;xsd:documentation&gt;

								             Musical Preferences

								            &lt;/xsd:documentation&gt;

								            &lt;xsd:appinfo&gt;

								              &lt;categories xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								                &lt;preference/&gt;

								              &lt;/categories&gt;

								            &lt;/xsd:appinfo&gt;

								          &lt;/xsd:annotation&gt;

								        &lt;/xsd:element&gt;

								      &lt;/xsd:all&gt;

								&lt;!--****************************************************************************

								  Optional attribute of datatype element

								  Always add this attribute definition - optional attribute of datatype element

								***********************************************************************************--&gt;

								      &lt;xsd:attribute type="p3p:yes_no" default="no" use="optional" name="optional" /&gt;

								    &lt;/xsd:complexType&gt;

								    &lt;xsd:complexType name="musical-preferenceComplexType"&gt;

								      &lt;xsd:all&gt;

								        &lt;xsd:element minOccurs="0"

								         name="classicalmusic-preference"

								         type="classicalmusic-preferenceComplexType"&gt;

								        &lt;xsd:annotation&gt;

								          &lt;xsd:documentation&gt;

								           Classical Music Preferences

								          &lt;/xsd:documentation&gt;

								          &lt;xsd:appinfo&gt;

								            &lt;categories xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								              &lt;preference/&gt;

								            &lt;/categories&gt;

								          &lt;/xsd:appinfo&gt;

								        &lt;/xsd:annotation&gt;

								      &lt;/xsd:element&gt;

								    &lt;/xsd:all&gt;

								  &lt;/xsd:complexType&gt;

								  &lt;xsd:complexType

								   name="classicalmusic-preferenceComplexType"&gt;

								    &lt;xsd:all&gt;

								      &lt;xsd:element minOccurs="0" name="baroquemusic-preference"&gt;

								        &lt;xsd:annotation&gt;

								          &lt;xsd:documentation&gt;

								           Baroque Music Preferences

								          &lt;/xsd:documentation&gt;

								          &lt;xsd:appinfo&gt;

								            &lt;categories xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								              &lt;preference/&gt;

								            &lt;/categories&gt;

								          &lt;/xsd:appinfo&gt;

								        &lt;/xsd:annotation&gt;

								      &lt;/xsd:element&gt;

								    &lt;/xsd:all&gt;

								  &lt;/xsd:complexType&gt;

								&lt;/xsd:schema&gt;

								</pre>


								<h2 id="Data_Schemas_persistence">5.4 Persistence of data schemas</h2>


								  <p>An essential requirement on data schemas is the

								  <strong><em>persistence of data schemas</em></strong>: data

								  schemas that can be fetched at a certain URI can only be

								  changed by extending the data schema in a

								  <em>backward-compatible</em> way (that is to say, changing the

								  data schema does not change the meaning of any policy using

								  that schema). This way, the URI of a policy acts in a sense

								  like a unique identifier for the data elements and structures

								  contained therein: any data schema that is not

								  backward-compatible <em>must therefore use a new different

								  URI</em>.</p>


								  <p>Note that a useful application of the persistence of data

								  schemas is given for example in the case of multi-lingual

								  sites: multiple language versions (translations) of the same

								  data schema can be offered by the server, using the HTTP

								  "Content-Language" response header field to properly indicate

								  that a particular language has been used for the data

								  schema.</p>


								<h2 id="base_data_structure">5.5 Structure of the Base Data Schema</h2>


								  <p>The XML schema is not designed to be human readable, but in

								  writing policies, and choosing data elements to make statements

								  about, it can be useful to have a picture of the hierarchy of

								  categories available. <a href="#base_data_overview">Section

								  5.5.1.</a> gives a visual overview of the data schema hierarchy

								  which is intended to be used as a quick reference. Section

								  5.5.2.  lists elements with their exact definitions and their

								  allowed children. It does not show the allowed categories,

								  which are described in <a href="#schema_detail">section

								  5.5.2.</a></p>


								  <p>All P3P-compliant user agent implementations MUST be aware

								  of the Base Data Schema.</p>


								<h3 id="base_data_overview">5.5.1 Visual overview of the base data schema

								hierarchy</h3>


								<h4 id="dynamic_data">5.5.1.1 Dynamic Data</h4>

								<pre class="tree">  dynamic

								    ├clickstream

								    │  ├uri

								    │  │  ├authority

								    │  │  ├stem

								    │  │  └querystring

								    │  ├timestamp

								    │  │  ├ymd.year

								    │  │  ├ymd.month

								    │  │  ├ymd.day

								    │  │  ├hms.hour

								    │  │  ├hms.minute

								    │  │  ├hms.second

								    │  │  ├fractionsecond

								    │  │  └timezone

								    │  ├clientip

								    │  │  ├hostname

								    │  │  ├partialhostname

								    │  │  ├fullip

								    │  │  └partialip

								    │  ├other.httpmethod

								    │  ├other.bytes

								    │  └other.statuscode

								    ├http

								    │  ├referer

								    │  │  ├authority

								    │  │  ├stem

								    │  │  └querystring

								    │  └useragent

								    ├clientevents

								    ├cookies

								    ├searchtext

								    ├interactionrecord

								    └miscdata</pre>


								<h4 id="user_data">5.5.1.2 User Data</h4>

								<pre class="tree">user

								  ├name

								  │  ├prefix

								  │  ├given

								  │  ├middle

								  │  ├family

								  │  ├suffix

								  │  └nickname

								  ├bdate

								  │  ├ymd.year

								  │  ├ymd.month

								  │  ├ymd.day

								  │  ├hms.hour

								  │  ├hms.minute

								  │  ├hms.second

								  │  ├fractionsecond

								  │  └timezone

								  ├login

								  │  ├id

								  │  └password

								  ├cert

								  │  ├key

								  │  └format

								  ├gender

								  ├jobtitle

								  ├home-info

								  │  ├postal

								  │  │  ├name

								  │  │  │  ├prefix

								  │  │  │  ├given

								  │  │  │  ├middle

								  │  │  │  ├family

								  │  │  │  ├suffix

								  │  │  │  └nickname

								  │  │  ├street

								  │  │  ├city

								  │  │  ├stateprov

								  │  │  ├postalcode

								  │  │  ├organization

								  │  │  └country

								  │  ├telecom

								  │  │  ├telephone

								  │  │  │  ├intcode

								  │  │  │  ◁loccode

								  │  │  │  ├number

								  │  │  │  ├ext

								  │  │  │  └comment

								  │  │  ├fax

								  │  │  │  ├intcode

								  │  │  │  ├loccode

								  │  │  │  ├number

								  │  │  │  ├ext

								  │  │  │  └comment

								  │  │  ├mobile

								  │  │  │  ├intcode

								  │  │  │  ├loccode

								  │  │  │  ├number

								  │  │  │  ├ext

								  │  │  │  └comment

								  │  │  └pager

								  │  │    ├intcode

								  │  │    ├loccode

								  │  │    ├number

								  │  │    ├ext

								  │  │    └comment

								  │  └online

								  │    ├email

								  │    └uri

								  └business-info

								    ├postal

								    │  ├name

								    │  │  prefix

								    │  │  given

								    │  │  middle

								    │  │  family

								    │  │  suffix

								    │  │  nickname

								    │  │street

								    │  │city

								    │  │stateprov

								    │  │postalcode

								    │  │organization

								    │  │country

								    │telecom

								    │  ├telephone

								    │  │  ├intcode

								    │  │  ├loccode

								    │  │  ├number

								    │  │  ├ext

								    │  │  └comment

								    │  ├fax

								    │  │  ├intcode

								    │  │  ├loccode

								    │  │  ├number

								    │  │  ├ext

								    │  │  └comment

								    │  ├mobile

								    │  │  ├intcode

								    │  │  ├loccode

								    │  │  ├number

								    │  │  ├ext

								    │  │  └comment

								    │  └pager

								    │    ├intcode

								    │    ├loccode

								    │    ├number

								    │    ├ext

								    │    └comment

								    │online

								    │  ├email

								    │  └uri

								    ├employer

								    └department</pre>


								<h3 id="third_party_data">5.5.1.3 Third Party Data</h3>

								<pre class="tree">

								thirdparty

								  ├name

								  │  ├prefix

								  │  ├given

								  │  ├middle

								  │  ├family

								  │  ├suffix

								  │  └nickname

								  ├bdate

								  │  ├ymd.year

								  │  ├ymd.month

								  │  ├ymd.day

								  │  ├hms.hour

								  │  ├hms.minute

								  │  ├hms.second

								  │  ├fractionsecond

								  │  └timezone

								  ├login

								  │  ├id

								  │  └password

								  ├cert

								  │  ├key

								  │  └format

								  ├gender

								  ├jobtitle

								  ├home-info

								  │  ├postal

								  │  │  ├name

								  │  │  │  ├prefix

								  │  │  │  ├given

								  │  │  │  ├middle

								  │  │  │  ├family

								  │  │  │  ├suffix

								  │  │  │  └nickname

								  │  │  ├street

								  │  │  ├city

								  │  │  ├stateprov

								  │  │  ├postalcode

								  │  │  ├organization

								  │  │  └country

								  │  ├telecom

								  │  │  ├telephone

								  │  │  │  ├intcode

								  │  │  │  ├loccode

								  │  │  │  ├number

								  │  │  │  ├ext

								  │  │  │  └comment

								  │  │  ├fax

								  │  │  │  ├intcode

								  │  │  │  ├loccode

								  │  │  │  ├number

								  │  │  │  ├ext

								  │  │  │  └comment

								  │  │  ├mobile

								  │  │  │  ├intcode

								  │  │  │  ├loccode

								  │  │  │  ├number

								  │  │  │  ├ext

								  │  │  │  └comment

								  │  │  ├pager

								  │  │    ├intcode

								  │  │    ├loccode

								  │  │    ├number

								  │  │    ├ext

								  │  │    └comment

								  │  ├online

								  │    ┒email

								  │    └uri

								  └business-info

								      │postal

								      │  │name

								      │  │  │prefix

								      │  │  │given

								      │  │  │middle

								      │  │  │family

								      │  │  │suffix

								      │  │  │nickname

								      │  │street

								      │  │city

								      │  │stateprov

								      │  │postalcode

								      │  │organization

								      │  │country

								      │telecom

								      │  ├telephone

								      │  │  │intcode

								      │  │  │loccode

								      │  │  │number

								      │  │  │ext

								      │  │  │comment

								      │  ├fax

								      │  │  │intcode

								      │  │  │loccode

								      │  │  │number

								      │  │  │ext

								      │  │  │comment

								      │  ├mobile

								      │  │  ├intcode

								      │  │  ├loccode

								      │  │  ├number

								      │  │  ├ext

								      │  │  └comment

								      │  └pager

								      │    ├intcode

								      │    ├loccode

								      │    ├number

								      │    ├ext

								      │    └comment

								      ├online

								      │  ├email

								      │  └uri

								      ├employer

								      └department</pre>


								<h3 id="business_data">5.5.1.4 Business Data</h3>

								<pre class="tree">

								business

								  ├name

								  │department

								  ├cert

								  │  ├key

								  │  └format

								  └contact-info

								    ├postal

								    │  ├name

								    │  │  ├prefix

								    │  │  ├given

								    │  │  ├middle

								    │  │  ├family

								    │  │  ├suffix

								    │  │  └nickname

								    │  ├street

								    │  ├city

								    │  ├stateprov

								    │  ├postalcode

								    │  ├organization

								    │  └country

								    └telecom

								      ├telephone

								      │  ├intcode

								      │  ├loccode

								      │  ├number

								      │  ├ext

								      │  └comment

								      ├fax

								      │  ├intcode

								      │  ├loccode

								      │  ├number

								      │  ├ext

								      │  └comment

								      ├mobile

								      │  ├intcode

								      │  ├loccode

								      │  ├number

								      │  ├ext

								      │  └comment

								      ├pager

								      │  ├intcode

								      │  ├loccode

								      │  ├number

								      │  ├ext

								      │  └comment

								      └online

								        ├email

								        └uri</pre>


								<h3 id="schema_detail">5.5.2. Data Schema Element Details</h3>


								  <p>The Table below defines the details of the data schema

								  elements. Although it is a flat list, it does define the

								  hierarchy by defining the allowed subtypes of each class. The

								  following tables are mainly for referencing the exact

								  description of the meaning of each data type and the allowed

								  categories. More than one category may be associated with a

								  fixed data element. However, each base data element is assigned

								  to only one category whenever possible. Data schema designers

								  are recommended to do the same. To choose an element from the

								  hierarchy, you should refer to the tables in <a

								  href="#base_data_overview">section 5.5.1.</a></p>


								<table class="schema" summary="Data Types for P3P Base Data Schema">

								  <thead>

								    <tr class="bds">

								      <th>Type</th>

								      <th>Allowed Categories</th>

								      <th>Allowed Descendents</th>

								      <th>Short Description</th>

								      <th width="50%">Notes</th>

								    </tr>

								  </thead>

								  <tbody>

								    <tr>

								      <td class="bds">Dynamic</td>

								      <td class="bds">Variable</td>

								      <td class="bds">clickstream ,http, clientevents, cookies, searchtext,

								        interactionrecord, miscdata</td>

								      <td class="bds">Dynamic Data</td>

								      <td class="bds" width="50%">In some cases, there is a need to specify data elements

								        that do not have fixed values that a user might type in or store in a

								        repository. In the P3P base data schema, all such elements are

								        grouped under the class of dynamic data. Sites may refer to the types

								        of data they collect using the dynamic data set only, rather than

								        enumerating all of the specific data elements.</td>

								    </tr>

								    <tr>

								      <td class="bds">User</td>

								      <td class="bds">Physical Contact Information, Demographic and

								        Socioeconomic Data, Unique Identifiers,Online Contact Information</td>

								      <td class="bds">name, bdate, login, cert, gender, jobtitle, home-info,

								        business-info</td>

								      <td class="bds">General information about the user</td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds">Third-party</td>

								      <td class="bds">Physical Contact Information, Demographic and

								        Socioeconomic Data, Unique Identifiers,Online Contact Information</td>

								      <td class="bds">name, bdate, login, cert, gender, jobtitle, home-info,

								        business-info</td>

								      <td class="bds">&nbsp;</td>

								      <td class="bds">The <strong>thirdparty</strong> data set allows users

								        and businesses to provide values for a related third party. This can

								        be useful whenever third party information needs to be exchanged, for

								        example when ordering a present online that should be sent to another

								        person, or when providing information about one's spouse or business

								        partner. Such information could be stored in a user repository

								        alongside the user data set. User agents may offer to store multiple

								        such thirdparty data sets and allow users to select the appropriate

								        values from a list when necessary. The allowed subtypes of thirdparty

								        <em>data</em> element are identical to those of the <em>user

								        data</em> set.</td>

								    </tr>

								    <tr>

								      <td class="bds">Business</td>

								      <td class="bds">&nbsp;</td>

								      <td class="bds">orgname, department, cert, contact-info</td>

								      <td class="bds">&nbsp;</td>

								      <td class="bds">The <strong>business</strong> data type features a

								        subset of user data relevant for describing legal entities. In

								        P3P1.1, this data element is primarily used for describing the policy

								        entity, although it should also be applicable to business-to-business

								        interactions.</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>orgname</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information, Demographic and

								        Socioeconomic Data</p>

								      </td>

								      <td class="bds">

								      </td>

								      <td class="bds"><p>Organization Name</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>name</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information, Demographic and

								        Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p>prefix, given, family, middle, suffix, nickname</p>

								      </td>

								      <td class="bds"><p>User's Name</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>bdate</p>

								      </td>

								      <td class="bds"><p>Demographic and Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p>ymd.year, ymd.month, ymd.day, hms.hour, hms.minute,

								        hms.second, fractionsecond, timezone</p>

								      </td>

								      <td class="bds"><p>User's Birth Date</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>login</p>

								      </td>

								      <td class="bds"><p>Unique Identifiers</p>

								      </td>

								      <td class="bds"><p>id,password</p>

								      </td>

								      <td class="bds"><p>User's Login Information</p>

								      </td>

								      <td class="bds"><p>The <strong>login element and its children</strong>

								        refer to information (IDs and passwords) for computer systems and Web

								        sites which require authentication. Note that this data element

								        should not be used for computer systems or Web sites which use

								        digital certificates for authentication: in those cases, the

								        <em>cert</em> element should be used.</p>

								      </td>

								    </tr>

								    <tr>

								      <td class="bds"><p>cert</p>

								      </td>

								      <td class="bds"><p>Unique Identifiers</p>

								      </td>

								      <td class="bds"><p>key, format</p>

								      </td>

								      <td class="bds"><p>User's Identity Certificate</p>

								      </td>

								      <td class="bds">The <strong>cert element and its children</strong>

								        refer to identity certificates (like, for example, X.509).</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>gender</p>

								      </td>

								      <td class="bds"><p>Demographic and Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p>-</p>

								      </td>

								      <td class="bds"><p>User's Gender (Male or Female)</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>employer</p>

								      </td>

								      <td class="bds"><p>Demographic and Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p>-</p>

								      </td>

								      <td class="bds"><p>User's Employer</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>department</p>

								      </td>

								      <td class="bds"><p>Demographic and Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p>-</p>

								      </td>

								      <td class="bds"><p>Department or Division of Organization where User is

								        Employed</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>jobtitle</p>

								      </td>

								      <td class="bds"><p>Demographic and Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p>-</p>

								      </td>

								      <td class="bds"><p>User's Job Title</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>home-info</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information, Online Contact

								        Information, Demographic and Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p>postal, telecom, online</p>

								      </td>

								      <td class="bds"><p>User's Home Contact Information</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>contact-info</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information, Online Contact

								        Information, Demographic and Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p>postal, telecom, online</p>

								      </td>

								      <td class="bds"><p>Contact Information for the Organization</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>business-info</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information, Online Contact

								        Information, Demographic and Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p>postal, telecom, online, employer, department</p>

								      </td>

								      <td class="bds"><p>User's Business Contact Information</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>clickstream</p>

								      </td>

								      <td class="bds"><p>Navigation and Click-stream Data, Computer

								        Information</p>

								      </td>

								      <td class="bds"><p>uri, timestamp, clientip, other.httpmethod,

								        other.bytes, other.statuscode</p>

								      </td>

								      <td class="bds">Click-stream Information</td>

								      <td class="bds"><p>The clickstream <strong>element and its

								        children</strong> refer to information typically stored in Web-server

								        access logs.</p>


								        <p>The clickstream element is expected to apply to practically all

								        Web sites. It represents the combination of information typically

								        found in Web server access logs: the IP address or hostname of the

								        user's computer, the URI of the resource requested, the time the

								        request was made, the HTTP method used in the request, the size of

								        the response, and the HTTP status code in the response. Web sites

								        that collect standard server access logs as well as sites which do

								        URI path analysis can use this data element to describe how that data

								        will be used. Web sites that collect only some of the data elements

								        listed as allowed children of the clickstream element MAY choose to

								        list those specific elements rather than the entire

								        dynamic-clickstream element. This allows sites with more limited

								        data-collection practices to accurately present those practices to

								        their visitors.</p>


								        <p>The resource in the HTTP request is captured by the uri field. The

								        IP address of the client system making the request is given by the

								        clientip field.</p>

								      </td>

								    </tr>

								    <tr>

								      <td class="bds"><p>http</p>

								      </td>

								      <td class="bds"><p>Navigation and Click-stream Data, Computer

								        Information</p>

								      </td>

								      <td class="bds"><p>referer, useragent</p>

								      </td>

								      <td class="bds">HTTP Protocol Information</td>

								      <td class="bds">The http element contains additional information

								        contained in the HTTP protocol. The http <strong>element and its

								        children</strong> refer to information carried by the HTTP protocol

								        which is not covered by the clickstream element and its children.</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>clientevents</p>

								      </td>

								      <td class="bds"><p>Navigation and Click-stream Data</p>

								      </td>

								      <td class="bds"><p>-</p>

								      </td>

								      <td class="bds">User's Interaction with a Resource</td>

								      <td class="bds">The clientevents element represents data about how the

								        user interacts with their Web browser while interacting with a

								        resource. For example, an application may wish to collect information

								        about whether the user moved their mouse over a certain image on a

								        page, or whether the user ever brought up the help window in a Java

								        applet. This kind of information is represented by the clientevents

								        data element. Much of this interaction record is represented by the

								        events and data defined by the Document Object Model (DOM) Level 2

								        Events [<a

								        href="http://www.w3.org/TR/P3P/#ref_DOM2-Events">DOM2-Events</a>].

								        The clientevents data element also covers any other data regarding

								        the user's interaction with their browser while the browser is

								        displaying a resource. The exception is events which are covered by

								        other elements in the base data schema. For example, requesting a

								        page by clicking on a link is part of the user's interaction with

								        their browser while viewing a page, but merely collecting the URL the

								        user has clicked on does not require declaring this data element;

								        clickstream covers that event. However, the DOM event DOMFocusIn

								        (representing the user moving their mouse over an object on a page)

								        is not covered by any other existing element, so if a site is

								        collecting the occurrence of this event, then it needs to state that

								        it collects the dynamic.clientevents element. Items covered by this

								        data element are typically collected by client-side scripting

								        languages, such as JavaScript, or by client-side applets, such as

								        ActiveX or Java applets. Note that while the previous discussion has

								        been in terms of a user viewing a resource, this data element also

								        applies to Web applications which do not display resources visually -

								        for example, audio-based Web browsers.</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>cookies</p>

								      </td>

								      <td class="bds"><p><a

								        href="http://www.w3.org/TR/P3P/#variable"><em>variable-category</em></a></p>

								      </td>

								      <td class="bds"><p>-</p>

								      </td>

								      <td class="bds">Use of HTTP Cookies</td>

								      <td class="bds">The cookies element should be used whenever HTTP

								        cookies are set or retrieved by a site. Please note that cookies is a

								        <em>variable category data element</em> and requires the explicit

								        declaration of usage categories in a policy.</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>miscdata</p>

								      </td>

								      <td class="bds"><p><a

								        href="http://www.w3.org/TR/P3P/#variable"><em>variable-category</em></a></p>

								      </td>

								      <td class="bds"><p>-</p>

								      </td>

								      <td class="bds">Miscellaneous Non-base Data Schema Information</td>

								      <td class="bds">The miscdata element references information collected

								        by the service that the service does not reference using a specific

								        data element. Categories have to be used to better describe these

								        data: sites MUST reference a separate miscdata element in their

								        policies for each category of miscellaneous data they collect.</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>searchtext</p>

								      </td>

								      <td class="bds"><p>Interactive Data</p>

								      </td>

								      <td class="bds"><p>-</p>

								      </td>

								      <td class="bds">Search Terms</td>

								      <td class="bds">The searchtext element references a specific type of

								        solicitation used for searching and indexing sites. For example, if

								        the only fields on a search engine page are search fields, the site

								        only needs to disclose that data element.</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>interactionrecord</p>

								      </td>

								      <td class="bds"><p>Interactive Data</p>

								      </td>

								      <td class="bds"><p>-</p>

								      </td>

								      <td class="bds">Server Stores the Transaction History</td>

								      <td class="bds">The interactionrecord element should be used if the

								        server is keeping track of the interaction it has with the user (i.e.

								        information other than clickstream data, for example account

								        transactions, etc).</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>ymd.year</p>

								      </td>

								      <td class="bds"><p><a

								        href="#variable"><em>variable-category</em></a></p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Year</p>

								      </td>

								      <td class="bds">The following elements refer to data connected with

								        dates. Since date information can be used in different ways,

								        depending on the context, all such information is tagged as being of

								        <em>variable</em> category. For example, schema definitions can

								        explicitly set the corresponding category in the element referencing

								        these elements, where soliciting the birthday of a user might be

								        "Demographic and Socioeconomic Data", while the expiration date of a

								        credit card might belong to the <code>Purchase Information</code>

								        category.</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>ymd.month</p>

								      </td>

								      <td class="bds"><p><a

								        href="#variable"><em>variable-category</em></a></p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Month</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>ymd.day</p>

								      </td>

								      <td class="bds"><p><a

								        href="#variable"><em>variable-category</em></a></p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Day</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>hms.hour</p>

								      </td>

								      <td class="bds"><p><a

								        href="#variable"><em>variable-category</em></a></p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Hour</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>hms.minute</p>

								      </td>

								      <td class="bds"><p><a

								        href="#variable"><em>variable-category</em></a></p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Minute</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>hms.second</p>

								      </td>

								      <td class="bds"><p><a

								        href="#variable"><em>variable-category</em></a></p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Second</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>fractionsecond</p>

								      </td>

								      <td class="bds"><p><a

								        href="#variable"><em>variable-category</em></a></p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Fraction of Second</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>timezone</p>

								      </td>

								      <td class="bds"><p><a

								        href="#variable"><em>variable-category</em></a></p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Time Zone</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>prefix</p>

								      </td>

								      <td class="bds"><p>Demographic and Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Name Prefix</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>given</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Given Name (First Name)</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>family</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Family Name (Last Name)</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>middle</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Middle Name</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>suffix</p>

								      </td>

								      <td class="bds"><p>Demographic and Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Name Suffix</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>nickname</p>

								      </td>

								      <td class="bds"><p>Demographic and Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Nickname</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>id</p>

								      </td>

								      <td class="bds"><p>Unique Identifiers</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Login ID</p>

								      </td>

								      <td class="bds"><p></p>


								        <p>The "id" element represents the ID portion of the login

								        information for a computer system. Often, user IDs are made public,

								        while passwords are kept secret. IDs do not include any type of

								        biometric authentication mechanisms.</p>


								        <p>&nbsp;</p>

								      </td>

								    </tr>

								    <tr>

								      <td class="bds"><p>password</p>

								      </td>

								      <td class="bds"><p>Unique Identifiers</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Login Password</p>

								      </td>

								      <td class="bds">The "password" element represents the password portion

								        of the login information for a computer system. This is a secret data

								        value, usually a character string, that is used in authenticating a

								        user. Passwords are typically kept secret, and are generally

								        considered to be sensitive information</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>key</p>

								      </td>

								      <td class="bds"><p>Unique Identifiers</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Certificate Key</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>format</p>

								      </td>

								      <td class="bds"><p>Unique Identifiers</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Certificate Format</p>

								      </td>

								      <td class="bds">The "format" element is used to represent the

								        information of an IANA registered public key or authentication

								        certificate format, while the "key" field is used to represent the

								        corresponding certificate key.</td>

								    </tr>

								    <tr>

								      <td class="bds" id="Postal"><p>postal</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information, Demographic and

								        Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p>name, street, city, stateprov, postalcode,

								        organization, country</p>

								      </td>

								      <td class="bds"><p>Postal Address Information</p>

								      </td>

								      <td class="bds">The following 3 elements and their children refer to

								        contact information. Services can specify precisely which set of data

								        they need, postal, telecommunication, or online address information.

								        The <strong>postal element and its children</strong> refer to a

								        postal mailing address.</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>telecom</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information</p>

								      </td>

								      <td class="bds"><p>telephone, fax, mobile, pager</p>

								      </td>

								      <td class="bds"><p>Telecommunications Information</p>

								      </td>

								      <td class="bds">The <strong>telecom element and its children</strong>

								        refer to the characteristics of telephone, fax, mobile and pager

								        numbers.</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>online</p>

								      </td>

								      <td class="bds"><p>Online Contact Information</p>

								      </td>

								      <td class="bds"><p>email,uri</p>

								      </td>

								      <td class="bds"><p>Online Address Information</p>

								      </td>

								      <td class="bds">The <strong>online element and its children</strong>

								        refer to online information about a person or legal entity.</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>intcode</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>International Telephone Code</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>loccode</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Local Telephone Area Code</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>number</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Telephone Number</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>ext</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Telephone Extension</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>comment</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Telephone Optional Comments</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>street</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Street Address</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>city</p>

								      </td>

								      <td class="bds"><p>Demographic and Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>City</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>stateprov</p>

								      </td>

								      <td class="bds"><p>Demographic and Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>State or Province</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>postalcode</p>

								      </td>

								      <td class="bds"><p>Demographic and Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Postal Code</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>country</p>

								      </td>

								      <td class="bds"><p>Demographic and Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Country Name</p>

								      </td>

								      <td class="bds">The "country" element represents the information of the

								        name of the country (for example, one among the countries listed in

								        [<a href="#iso3166">ISO3166</a>]).</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>organization</p>

								      </td>

								      <td class="bds"><p>Demographic and Socioeconomic Data</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Organization Name</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>telephone</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information</p>

								      </td>

								      <td class="bds"><p>intcode, loccode, number, ext, comment</p>

								      </td>

								      <td class="bds"><p>Telephone Number</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>fax</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information</p>

								      </td>

								      <td class="bds"><p>intcode, loccode, number, ext, comment</p>

								      </td>

								      <td class="bds"><p>Fax Number</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>mobile</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information</p>

								      </td>

								      <td class="bds"><p>intcode, loccode, number, ext, comment</p>

								      </td>

								      <td class="bds"><p>Mobile Telephone Number</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>pager</p>

								      </td>

								      <td class="bds"><p>Physical Contact Information</p>

								      </td>

								      <td class="bds"><p>intcode, loccode, number, ext, comment</p>

								      </td>

								      <td class="bds"><p>Pager Number</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>email</p>

								      </td>

								      <td class="bds"><p>Online Contact Information</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Email Address</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>uri</p>

								      </td>

								      <td class="bds"><p>Online Contact Information</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Home Page Address</p>

								      </td>

								      <td class="bds"><p>The uri <strong>element and its children</strong>

								        refer to Universal Resource Identifiers (URI), which are defined in

								        [<a href="#URI">URI</a>].</p>


								        <p>Since URI information can be used in different ways, depending on

								        the context, all the child elements of the uri element are tagged as

								        being of <em>variable</em> category. Schema definitions MUST

								        explicitly set the corresponding category in the element referencing

								        this data structure.</p>

								      </td>

								    </tr>

								    <tr>

								      <td class="bds"><p>authority</p>

								      </td>

								      <td class="bds"><p><a

								        href="#variable"><em>variable-category</em></a></p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>URI Authority</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>stem</p>

								      </td>

								      <td class="bds"><p><a

								        href="#variable"><em>variable-category</em></a></p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>URI Stem</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>querystring</p>

								      </td>

								      <td class="bds"><p><a

								        href="#variable"><em>variable-category</em></a></p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Query-string Portion of URI</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>authority</p>

								      </td>

								      <td class="bds"><p><a

								        href="#variable"><em>variable-category</em></a></p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>URI Authority</p>

								      </td>

								      <td class="bds"><p>The authority of a URI is defined as the authority

								        component in [<a href="#URI">URI</a>]. 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, and the querystring is the information contained in the portion

								        of the URI after the first '?' character. For URIs which do not

								        contain a '?' character, the stem is the entire URI, and the

								        querystring is empty.</p>

								      </td>

								    </tr>

								    <tr>

								      <td class="bds"><p>stem</p>

								      </td>

								      <td class="bds"><p><a

								        href="#variable"><em>variable-category</em></a></p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>URI Stem</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>querystring</p>

								      </td>

								      <td class="bds"><p><a

								        href="#variable"><em>variable-category</em></a></p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Query-string Portion of URI</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>hostname</p>

								      </td>

								      <td class="bds"><p>Computer Information</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Complete Host and Domain Name</p>

								      </td>

								      <td class="bds">The <code>hostname</code> element is used to represent

								        collection of either the simple hostname of a system, or the full

								        hostname including domain name. The <code>partialhostname</code>

								        element represents the information of a fully-qualified hostname

								        which has had <em>at least</em> the host portion removed from the

								        hostname. In other words, everything up to the first '.' in the

								        fully-qualified hostname MUST be removed for an address to quality as

								        a "partial hostname".</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>partialhostname</p>

								      </td>

								      <td class="bds"><p>Demographic</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Partial Hostname</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>fullip</p>

								      </td>

								      <td class="bds"><p>Computer Information</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Full IP Address</p>

								      </td>

								      <td class="bds"><p>The <code>fullip</code> element represents the

								        information of a full IP version 4 or IP version 6 address. The

								        <code>partialip</code> element represents an IP version 4 address

								        (only - not a version 6 address) which has had <em>at least</em> the

								        last 7 bits of information removed. This removal MUST be done by

								        replacing those bits with a fixed pattern for all visitors (for

								        example, all 0's or all 1's).</p>


								        <p>Certain Web sites are known to make use not of the visitor's

								        entire IP address or hostname, but rather make use of a reduced form

								        of that information. By collecting only a subset of the address

								        information, the site visitor is given some measure of anonymity. It

								        is certainly not the intent of this specification to claim that these

								        "stripped" IP addresses or hostnames are impossible to associate with

								        an individual user, but rather that it is significantly more

								        difficult to do so. Sites which perform this data reduction MAY wish

								        to declare this practice in order to more-accurately reflect their

								        practices.</p>

								      </td>

								    </tr>

								    <tr>

								      <td class="bds"><p>partialip</p>

								      </td>

								      <td class="bds"><p>Demographic</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Partial IP Address</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>uri</p>

								      </td>

								      <td class="bds"><p>Navigation and click-stream data</p>

								      </td>

								      <td class="bds"><p>authority, stem, querystring</p>

								      </td>

								      <td class="bds"><p>URI of Requested Resource</p>

								      </td>

								      <td class="bds">&nbsp;</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>timestamp</p>

								      </td>

								      <td class="bds"><p>Navigation and click-stream data</p>

								      </td>

								      <td class="bds"><p>ymd.year, ymd.month, ymd.day, hms.hour, hms.minute,

								        hms.second, fractionsecond, timezone</p>

								      </td>

								      <td class="bds"><p>Request Timestamp</p>

								      </td>

								      <td class="bds">The time at which the server processes the request is

								        represented by the timestamp field. Server implementations are free

								        to define this field as the time the request was received, the time

								        that the server began sending the response, the time that sending the

								        response was complete, or some other convenient representation of the

								        time the request was processed.</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>clientip</p>

								      </td>

								      <td class="bds"><p>Computer Information, Demographic and Socioeconomic

								        Data</p>

								      </td>

								      <td class="bds"><p>hostname, partialhostname, fullip, partialip</p>

								      </td>

								      <td class="bds"><p>Client's IP Address or Hostname</p>

								      </td>

								      <td class="bds">The clientip <strong>element and its children</strong>

								        refer to IP addresses and Domain Name System (DNS) hostnames.</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>other.httpmethod</p>

								      </td>

								      <td class="bds"><p>Navigation and click-stream data</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>HTTP Request Method</p>

								      </td>

								      <td class="bds">The <code>HTTP method</code> (such as GET, POST, etc)

								        in the client's request</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>other.bytes</p>

								      </td>

								      <td class="bds"><p>Navigation and click-stream data</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Number of Data Bytes in Response</p>

								      </td>

								      <td class="bds">The number of bytes in the response-body sent by the

								        server</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>other.statuscode</p>

								      </td>

								      <td class="bds"><p>Navigation and click-stream data</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>Response Status Code</p>

								      </td>

								      <td class="bds">The HTTP status code on the request, such as <code>200,

								        302, or 404</code> (see section 6.1.1 of [<a

								        href="#HTTP1_1_ref"><code>HTTP1.1</code></a>] for details).</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>referer</p>

								      </td>

								      <td class="bds"><p>Navigation and click-stream data</p>

								      </td>

								      <td class="bds"><p>authority, stem, querystring</p>

								      </td>

								      <td class="bds"><p>Last URI Requested by the User</p>

								      </td>

								      <td class="bds">The referer element represents the information in the

								        HTTP Referer header, which gives information about the previous page

								        visited by the user. Note that this field is misspelled in exactly

								        the same way as the corresponding HTTP header</td>

								    </tr>

								    <tr>

								      <td class="bds"><p>useragent</p>

								      </td>

								      <td class="bds"><p>Computer Information</p>

								      </td>

								      <td class="bds"><p><em>-</em></p>

								      </td>

								      <td class="bds"><p>User Agent Information</p>

								      </td>

								      <td class="bds"><p>The useragent field represents the information in

								        the HTTP User-Agent header (which gives information about the type

								        and version of the user's Web browser), and/or the HTTP accept*

								        headers.</p>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h2 id="using_elements">5.6. Using Data Elements</h2>


								  <p>P3P offers Web sites a lot of flexibility in how they

								  describe the types of data they collect.</p>


								  <ul>

								    <li>Sites may describe data generally using the

								    <code>&lt;dynamic&gt;&lt;miscdata/&gt;&lt;/dynamic&gt;</code>

								    element and the appropriate categories.</li>

								    <li>Sites may describe data specifically using the data

								    elements defined in the base data schema.</li>

								    <li>Sites may describe data specifically using data elements

								    defined in new data schemas.</li>

								  </ul>


								  <p>Any of these three methods may be combined within a single

								  policy.</p>


								  <p>By using the

								  <code>&lt;dynamic&gt;&lt;miscdata/&gt;&lt;/dynamic&gt;</code>

								  element, sites can specify the types of data they collect without

								  having to enumerate every individual data element. This may be

								  convenient for sites that collect a lot of data or sites belonging

								  to large organizations that want to offer a single P3P policy

								  covering the entire organization. However, the disadvantage of this

								  approach is that user agents will have to assume that the site might

								  collect any data element belonging to the categories referenced by

								  the site.  So, for example, if a site's policy states that it

								  collects

								  <code>&lt;dynamic&gt;&lt;miscdata/&gt;&lt;/dynamic&gt;</code> of the

								  physical contact information category, but the only physical contact

								  information it collects is business address, user agents will

								  nonetheless assume that the site might also collect telephone

								  numbers. If the site wishes to be clear that it does not collect

								  telephone numbers or any other physical contact information other

								  than business address, than it should disclose that it collects

								  <code>&lt;user&gt;&lt;business-info&gt;&lt;contact&gt;&lt;postal/&gt;

								  &lt;/contact&gt;&lt;/business-info&gt;&lt;/user&gt;</code>.

								  Furthermore, as user agents are developed with automatic

								  form-filling capabilities, it is likely that sites that enumerate

								  the data they collect will be able to better integrate with these

								  tools.</p>


								  <p>By defining new data schemas, sites can precisely specify

								  the data they collect beyond the base data set. However, if

								  user agents are unfamiliar with the elements defined in these

								  schemas, they will be able to provide only minimal information

								  to the user about these new elements. The information they

								  provide will be based on the category and display names

								  specified for each element.</p>


								  <p>Regardless of whether a site wishes to make general or

								  specific data disclosures, there are additional advantages to

								  disclosing specific elements from the

								  <code>&lt;dynamic/&gt;</code>data set. For example, by

								  disclosing

								  <code>&lt;dynamic&gt;&lt;cookies/&gt;&lt;/dynamic&gt;</code> a

								  site can indicate that it uses cookies and explain the purpose

								  of this use. User agent implementations that offer users cookie

								  control interfaces based on this information are encouraged.

								  Likewise, user agents that by default do not send the

								  HTTP_REFERER header, might look for the

								  <code>&lt;dynamic&gt;&lt;http&gt;&lt;referrer/&gt;&lt;/http&gt;&lt;/dynamic&gt;</code>

								  element in P3P policies and send the header if it will be used

								  for a purpose the user finds acceptable.</p>


								<h2 id="Data_Schemas_back">5.7. Backward Compatibility Requirements</h2>


								<p>Backward compatibility with P3P 1.0 is addressed as follows:</p>


								  <p>P3P 1.1 policies must include data elements in both P3P 1.0

								  and P3P1.1 (extension) data element syntax.  It is anticipated

								  that most policy authors will use a P3P1.1 policy editor which

								  will output the correct formats automatically, however in the

								  case that the policy is being written without a GUI, this can

								  be easily achieved by writing policies using P3P1.1 data

								  elements and publishing the <a href="http://www.w3.org/2005/09/p3p-converter.html">

								  P3P1.1 Data Element backward compatibility transform</a> of

								  the policy. The corresponding XSLT-Sheets are reproduced in the

								  <a href="#Appendix_xslt">Annex 4</a></p>


								  <p>For Example, write the DATA-GROUP element as:</p>

								<pre class="sample">&lt;DATA-GROUP

								  base="http://www.w3.org/2005/09/p3p-converter.html?uri=http:%2F%2Fwww.example.com%2Fcustomdataschema.xsd"&gt;

								  &lt;EXTENSION&gt;

								    &lt;datatype xmlns="http://www.example.com/customdataschema.xsd"&gt;

								      &lt;dynamic&gt;

								        &lt;clickstream&gt;

								          &lt;CATEGORY&gt;preference&lt;/CATEGORY&gt;

								        &lt;/clickstream&gt;

								      &lt;/dynamic&gt;

								    &lt;/datatype&gt;

								  &lt;/EXTENSION&gt;

								&lt;/DATA-GROUP&gt;

								</pre>


								  <p>and transform it to compliant format using the <a

								  href="http://www.w3.org/2005/09/p3p-converter">

								  P3P1.1 Data Element backward compatibility transform</a> to the

								  following:</p>


								<pre class="sample">&lt;DATA-GROUP

								 base="http://www.w3.org/2005/09/p3p-converter.html?uri=http:%2F%2Fwww.example.com%2Fcustomdataschema.xsd"&gt;

								  &lt;EXTENSION&gt;

								    &lt;datatype xmlns="http://www.example.com/customdataschema.xsd"&gt;

								      &lt;dynamic&gt;

								        &lt;clickstream&gt;

								          &lt;categories&gt;preference&lt;/categories&gt;

								        &lt;/clickstream&gt;

								      &lt;/dynamic&gt;

								    &lt;/datatype&gt;

								  &lt;/EXTENSION&gt;

								  &lt;DATA ref="#dynamic.clickstream"&gt;

								    &lt;categories&gt;

								      &lt;preference/&gt;

								    &lt;/categories&gt;

								  &lt;/DATA&gt;

								&lt;/DATA-GROUP&gt;

								</pre>


								  <p>Web sites using custom data schemas MUST publish these

								  schemas in P3P1.1 format only.</p>


								  <p>User agents are only required to validate P3P1.1 policy data

								  elements elements according to a P3P1.1 data schema.  User

								  agents may optionally continue to parse and perform validation

								  according to <a

								  href="http://www.w3.org/TR/P3P/#Data_Schemas">P3P 1.0

								  format</a> custom data schemas This can also be acheived in an

								  implementation independent way using a set of <a

								  href="http://www.w3.org/2005/09/p3p-converter.html">xslt

								  transforms</a> provided to transform both policy elements and

								  custom schemas to the P3P1.1 format.  </p>


								  <p>Web sites using custom data schemas MUST publish these

								  schemas in P3P1.1 format only. </p>


								  <p>User agents are only required to validate P3P1.1 policy data

								  elements according to a P3P1.1 data schema.  User

								  agents may optionally continue to parse and perform validation

								  according to <a

								  href="http://www.w3.org/TR/P3P/#Data_Schemas">P3P 1.0

								  format</a> custom data schemas</p>


								  <p>This can also be acheived in an implementation independent way

								  using <a href="http://www.w3.org/2005/09/removeDuplicatePolicyDataElements.xsl">

								  policytransformP3PDataElements.xsl</a> and

								  <a href="http://www.w3.org/2005/09/removeDuplicatePolicyDataElements.xsl">

								  removeDuplicatePolicyDataElements.xsl</a> xslt transforms provided to

								  transform both policy elements and custom schemas to the P3P1.1

								  format.</p>


								  <p>A typical process of producing a policy with custom data

								  elements may be summarized as follows (note that usually this

								  would be taken care of by a policy editor).</p>


								<p>For custom schemas:</p>

								<ol>

								  <li>Create and publish a custom data schema according to P3P1.1

								    specification.</li>

								  <li>Create policies using P3P1.1 data elements based on the schema created

								    in 1. - e.g.

								   <pre class="sample">&lt;DATA-GROUP&gt;

								  &lt;EXTENSION&gt;

								    &lt;datatype xmlns="http://www.example.com/customdataschema.xsd"&gt;

								      &lt;classicalmusicpreference&gt;

								        &lt;baroquemusicpreference/&gt;

								      &lt;/classicalmusicpreference&gt;

								    &lt;/datatype&gt;

								  &lt;/EXTENSION&gt;

								&lt;/DATA-GROUP&gt;

								</pre>

								  </li>

								  <li><p>Publish <a href="http://www.w3.org/2005/09/p3p-converter.html">

								  Backward compatibility transform</a> of policy referencing P3P1.1 custom

								  data schema. E.g.</p>

								<pre class="sample">&lt;DATA-GROUP&gt;

								  &lt;EXTENSION&gt;

								    &lt;datatype xmlns="http://www.example.com/customdataschema.xsd"&gt;

								      &lt;classicalmusicpreference&gt;

								        &lt;baroquemusicpreference/&gt;

								      &lt;/classicalmusicpreference&gt;

								    &lt;/datatype&gt;

								  &lt;/EXTENSION&gt;

								    &lt;DATA ref="#classicalmusicpreference.baroquemusicpreference"&gt;

								    &lt;CATEGORIES&gt;

								      &lt;preference/&gt;

								    &lt;/CATEGORIES&gt;

								  &lt;/DATA&gt;

								&lt;/DATA-GROUP&gt;

								</pre>

								  </li>

								</ol>


								  <p>Data elements can also be written in P3P1.0 format and

								  transformed to the P3P1.1 format using

								  <a href="http://www.w3.org/2005/09/p3p-converter.html">P3P1.1

								  Data Element forward transform</a></p>


								<h2 id="data_semantics">5.8. Semantics of P3P Data Schemas</h2>


								  <p>XML does not define a formal semantics except when used

								  within RDF. The use of XSD to define classes of data types

								  however necessarily implies a correspondence between XML

								  elements and real-world classes of data, which is therefore a

								  form of semantics. We have chosen not to use a language with

								  formal semantics because of the sparse support for such

								  languages as RDF and OWL in commercial browser implementations.

								  </p>


								</div>


								<div id="ua">

								<h1>6.0 User Agent Guidelines</h1>


								<p>This section specifies guidelines for P3P 1.1 user agents. Some of these

								guidelines serve to reinforce requirements that appear elsewhere in this

								specification, providing specific guidance for user agent implementers. Other

								guidelines introduce new requirements for full compliance with this

								specifcation or provide suggestions for implementers. All of these guidelines

								are designed to promote consistency among user agent implementations and to

								assist implementers in designing user agents that will be both usable and

								useful. By using consistent language to describe web site privacy practices,

								user agent implementers can help ensure that their implementations represent

								web site privacy practices accurately. In addition, consistent

								implementations serve to reduce the uncertainty web site operators have about

								how their policies will be displayed by P3P user agents.</p>


								<h3 id="complete_trans">6.1 Completeness of Human-Readable Translations</h3>


								<p>P3P user agents may display human-readable translations of P3P policies.

								Because of the large number of fields in a P3P policy, in some case, user

								agent implementers may wish to develop human-readable translations that do

								not include all P3P policy elements. The following guidelines are designed to

								reduce the chance that abridged translations may mislead users.</p>

								<ol>

								  <li>While the default view of a human-readable P3P translation MAY be

								    abridged, user agents SHOULD include a mechanism that allows users to

								    view a complete translation, including an enumeration of all data

								    elements referenced in a P3P policy.</li>

								  <li>Translations that include information about P3P DATA elements MAY

								    provide this information at differing levels of granularity; however,

								    they SHOULD include information about all relevant data elements in the

								    policy. For example, a user agent that displays only category information

								    and not individual element names SHOULD include the categories that

								    correspond to the elements referenced explicitly by name. Thus, a user

								    agent that displays only category information would display some

								    indication that online contact information was being collected if it

								    encountered a site that said it collected the user.home-info.online.email

								    data element.</li>

								  <li>Translations that include information about P3P PURPOSE elements SHOULD

								    provide information to indicate whether any of these purposes are being

								    performed on an opt-in or opt-out basis.</li>

								  <li>Translations that include information about P3P RECIPIENTS elements

								    should provide information to indicate whether data is disclosed to any

								    of these recipients on an opt-in or opt-out basis.</li>

								  <li>Translations SHOULD include relevant human-readable fields from a P3P

								    policy. However, user agents MAY truncate lengthy human-readable fields

								    or display such fields on a click-through basis. Typically, 500

								    characters is adequate for the human-readable P3P fields.</li>

								</ol>


								<h3 id="plain_trans">6.2 Plain Language Translations of P3P Vocabulary

								Elements</h3>


								<p>Section 3 includes normative definitions for all P3P vocabulary elements.

								However, many of these definitions are rather verbose and use language that

								is unsuitable for display to end users. Therefore, the P3P 1.1 Working Group

								has developed a set of "plain language" translations for most of the P3P

								vocabulary elements. These translations are designed to convey the essence of

								each element in relatively simple language, without conflicting with the

								normative definition. A "plain English" version is presented here,

								translations to other languages will be posted on the W3C Web-site when they

								become available. P3P user agents SHOULD display P3P policy information to

								users using the plain English wording shown here or an equivalent

								translation.</p>


								<table

								summary="table with user  friendly strings to display by a user agent in case the corresponding element  is found"

								border="1" cellpadding="10" cellspacing="1">

								  <caption>P3P 1.0 element definitions and translations</caption>

								  <thead>

								    <tr class="head">

								      <th>P3P Element</th>

								      <th>Attribute</th>

								      <th>Plain Language Translation</th>

								    </tr>

								  </thead>

								  <tbody>

								    <tr class="green">

								      <td><a href="#POLICY">POLICY</a></td>

								      <td>discuri (attribute of POLICY element)</td>

								      <td>Read our full privacy policy at [with link to discuri]</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#POLICY">POLICY</a></td>

								      <td>opturi (attribute of POLICY element)</td>

								      <td>Find out how to opt-in or opt-out at [with link to opturi]</td>

								    </tr>

								    <tr class="grey">

								      <td colspan="2"><a href="#ENTITY">ENTITY</a></td>

								      <td>This policy is issued by: [display all entity information provided

								        by site]</td>

								    </tr>

								    <tr class="green">

								      <td colspan="2"><a href="#ACCESS">ACCESS</a></td>

								      <td>Your access to information about you:</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#ACCESS">ACCESS</a></td>

								      <td>nonident</td>

								      <td>We do not keep any information identified with you</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#ACCESS">ACCESS</a></td>

								      <td>all</td>

								      <td>We give you access to all of our information identified with

								      you</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#ACCESS">ACCESS</a></td>

								      <td>contact-and-other</td>

								      <td>We give you access to your contact information and some of our

								        other information identified with you</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#ACCESS">ACCESS</a></td>

								      <td>ident-contact</td>

								      <td>We give you access to only your contact information in our

								      records</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#ACCESS">ACCESS</a></td>

								      <td>other-ident</td>

								      <td>We allow you to access some of our information identified with you,

								        but not your contact information</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#ACCESS">ACCESS</a></td>

								      <td>none</td>

								      <td>We do not give you access to our information about you</td>

								    </tr>

								    <tr class="grey">

								      <td colspan="2"><a href="#DISPUTES">DISPUTES</a></td>

								      <td>Ways to resolve privacy-related disputes with us include:</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#DISPUTES">DISPUTES</a></td>

								      <td>service</td>

								      <td>[display long description and short description, if provided, with

								        hyperlink to service URI, otherwise display "customer service" with

								        hyperlink to service URI]</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#DISPUTES">DISPUTES</a></td>

								      <td>independent</td>

								      <td>[display long description and short description, if provided, with

								        hyperlink to service URI, otherwise display "independent

								        organization" with hyperlink to service URI]</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#DISPUTES">DISPUTES</a></td>

								      <td>court</td>

								      <td>We believe that the following authority offers recourse for

								        disputes: [display long description and short description, if

								        provided, with hyperlink to service URI, otherwise display "possible

								        legal complaint" with hyperlink to service URI]</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#DISPUTES">DISPUTES</a></td>

								      <td>law</td>

								      <td><p>We believe that the following laws or regulations provide

								        recourse:</p>


								        <p>[display long description and short description, if provided, with

								        hyperlink to service URI, otherwise display "law" with hyperlink to

								        service URI]</p>

								      </td>

								    </tr>

								    <tr class="green">

								      <td colspan="2"><a href="#REMEDIES">REMEDIES</a></td>

								      <td>[no heading - display this following corresponding disputes

								      element]</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#DISPUTES">DISPUTES</a></td>

								      <td>correct</td>

								      <td>We will correct any errors we make related to the commitments in

								        our privacy policy</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#DISPUTES">DISPUTES</a></td>

								      <td>money</td>

								      <td>We will compensate individuals if it is determined that we have

								        violated our privacy policy</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#DISPUTES">DISPUTES</a></td>

								      <td>law</td>

								      <td>Our privacy policy references a law that may determine remedies for

								        breaches of our policy</td>

								    </tr>

								    <tr class="grey">

								      <td colspan="2"><a href="#NON-IDENTIFIABLE">NON-IDENTIFIABLE</a></td>

								      <td>We do not keep any information that could be used to identify you

								        personally</td>

								    </tr>

								    <tr class="green">

								      <td colspan="2"><a href="#PURPOSE">PURPOSE</a></td>

								      <td>The ways your information may be used:</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#PURPOSE">PURPOSE</a></td>

								      <td>current</td>

								      <td>To provide the service you requested</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#PURPOSE">PURPOSE</a></td>

								      <td>admin</td>

								      <td>To perform web site and system administration</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#PURPOSE">PURPOSE</a></td>

								      <td>develop</td>

								      <td>For research and development, but without connecting any

								        information to you</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#PURPOSE">PURPOSE</a></td>

								      <td>tailoring</td>

								      <td>To customize the site for your current visit only</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#PURPOSE">PURPOSE</a></td>

								      <td>pseudo-analysis</td>

								      <td>To do research and analysis in which your information may be linked

								        to an ID code but not to your personal identity</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#PURPOSE">PURPOSE</a></td>

								      <td>pseudo-decision</td>

								      <td>To make decisions that directly affect you without identifying you,

								        for example to display content or ads based on links you clicked on

								        previously</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#PURPOSE">PURPOSE</a></td>

								      <td>individual-analysis</td>

								      <td>To do research and analysis that uses information about you</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#PURPOSE">PURPOSE</a></td>

								      <td>individual-decision</td>

								      <td>To make decisions that directly affect you using information about

								        you, for example to recommend products or services based on your

								        previous purchases</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#PURPOSE">PURPOSE</a></td>

								      <td>contact</td>

								      <td>To contact you through means other than telephone (for example,

								        email or postal mail) to market services or products</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#PURPOSE">PURPOSE</a></td>

								      <td>historical</td>

								      <td>To aid in historical preservation as governed by a law or policy

								        described in this privacy policy</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#PURPOSE">PURPOSE</a></td>

								      <td>telemarketing</td>

								      <td>To contact you by telephone to market services or products</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#PURPOSE">PURPOSE</a></td>

								      <td>other-purpose</td>

								      <td>For other uses: [include site's human, readable explanation; if

								        site omits human-readable explanation say "not described here"]</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#PURPOSE">PURPOSE</a></td>

								      <td>required (attribute of purpose and recipients elements)</td>

								      <td>(attribute, see below)</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#PURPOSE">PURPOSE</a></td>

								      <td>required always</td>

								      <td>(no remark)</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#PURPOSE">PURPOSE</a></td>

								      <td>required opt-in</td>

								      <td>[append to purpose/recipient] -- only if you request this</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#PURPOSE">PURPOSE</a></td>

								      <td>required opt-out</td>

								      <td>[append to purpose/recipient] -- unless you opt-out</td>

								    </tr>

								    <tr class="grey">

								      <td colspan="2"><a href="#RECPNT">RECIPIENT</a></td>

								      <td>With whom we may share your information</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#RECPNT">RECIPIENT</a></td>

								      <td>ours</td>

								      <td>Companies that help us fulfill your requests (for example, shipping

								        a product to you), but these companies must not use your information

								        for any other purpose</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#RECPNT">RECIPIENT</a></td>

								      <td>delivery</td>

								      <td>Delivery companies that help us fulfill your requests and who may

								        also use your information in other ways</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#RECPNT">RECIPIENT</a></td>

								      <td>same</td>

								      <td>Companies that have privacy policies similar to ours</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#RECPNT">RECIPIENT</a></td>

								      <td>other-recipient</td>

								      <td>Companies that are accountable to us, though their privacy policies

								        may be different from ours</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#RECPNT">RECIPIENT</a></td>

								      <td>unrelated</td>

								      <td>Other companies whose privacy policies are unknown to us</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#RECPNT">RECIPIENT</a></td>

								      <td>public</td>

								      <td>People who may access your information from a public area, such as

								        a bulletin board, chat room, or directory</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#RECPNT">RECIPIENT</a></td>

								      <td>required (attribute of purpose and recipients elements)</td>

								      <td>(attribute, see below)</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#RECPNT">RECIPIENT</a></td>

								      <td>required always</td>

								      <td>(no remark)</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#RECPNT">RECIPIENT</a></td>

								      <td>required opt-in</td>

								      <td>[append to purpose/recipient] -- only if you request this</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#RECPNT">RECIPIENT</a></td>

								      <td>required opt-out</td>

								      <td>[append to purpose/recipient] -- unless you opt-out</td>

								    </tr>

								    <tr class="green">

								      <td colspan="2"><a href="#RETENTION">RETENTION</a></td>

								      <td>How long we may keep your information</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#RETENTION">RETENTION</a></td>

								      <td>no-retention</td>

								      <td>We do not keep your information beyond your current online

								      session</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#RETENTION">RETENTION</a></td>

								      <td>stated-purpose</td>

								      <td>We keep your information only long enough to perform the activity

								        for which we collected it</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#RETENTION">RETENTION</a></td>

								      <td>legal-requirement</td>

								      <td>We keep your information only as long as we need to for legal

								        purposes</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#RETENTION">RETENTION</a></td>

								      <td>business-practices</td>

								      <td>Our full privacy policy explains how long we keep your

								      information</td>

								    </tr>

								    <tr class="green">

								      <td><a href="#RETENTION">RETENTION</a></td>

								      <td>indefinitely</td>

								      <td>We may keep your information indefinitely</td>

								    </tr>

								    <tr class="grey">

								      <td colspan="2"><a href="#Categories">CATEGORIES</a></td>

								      <td>We may collect the following types of information about you</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>physical</td>

								      <td>Name, address, phone number, or other physical contact

								      information</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>online</td>

								      <td>Email address or other online contact information</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>uniqueid</td>

								      <td>Website login IDs and other identifiers (excluding government IDs

								        and financial account numbers)</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>purchase</td>

								      <td>Information about your purchases, including payment methods</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>financial</td>

								      <td>Financial information such as accounts, balances, and transaction

								        history</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>computer</td>

								      <td>Information about the computer you are using, such as its hardware,

								        software, or Internet address</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>navigation</td>

								      <td>Which pages you visited on this web site and how long you stayed at

								        each page</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>interactive</td>

								      <td>Activities you engaged in at this web site, such as your searches

								        and transactions</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>demographic</td>

								      <td>Information about social and economic categories that might apply

								        to you, such as your gender, age, income, or where you are from</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>content</td>

								      <td>Messages you send to us or post on this site, such as email,

								        bulletin board postings, or chat room conversations</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>state</td>

								      <td>Cookies and mechanisms that perform similar functions</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>political</td>

								      <td>Which groups you might be a member of such as religious

								        organizations, trade unions, and political parties</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>health</td>

								      <td>Health information such as information about your medical condition

								        or your interest in health-related topics, services, or products</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>preference</td>

								      <td>Information about your tastes or interests</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>location</td>

								      <td>Information about an exact geographic location, such as data

								        transmitted by your GPS-enabled device</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>government</td>

								      <td>Government-issued identifiers such as social security numbers</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>other-category</td>

								      <td>Other types of data: [include site's human, readable explanation;

								        if site omits human-readable explanation say "not described

								      here"]</td>

								    </tr>

								    <tr class="grey">

								      <td><a href="#Categories">CATEGORIES</a></td>

								      <td>optional (attribute of data elements)</td>

								      <td><ul>

								          <li>if no: the data element is required [append to data element or

								            category]</li>

								          <li>if yes: the data element is optional [append to data element or

								            category]</li>

								        </ul>

								      </td>

								    </tr>

								  </tbody>

								</table>


								<h3 id="ua_storage">6.3 Storage of P3P Policies and Translations</h3>


								<p>P3P user agents SHOULD include mechanisms that allow users to store P3P

								policies and their corresponding translations easily to make them available

								for later viewing or printing.</p>


								<h3 id="ua_compact">6.4 Compact Policy Processing</h3>


								<p>P3P user agents MUST NOT rely on P3P compact policies that do not comply

								with the P3P 1.0 or P3P 1.1 specifications or are obviously erroneous. Such

								compact policies SHOULD be deemed invalid and the corresponding cookies

								should be treated as if they had no compact policies. The following

								guidelines are designed to reduce the chance that a P3P user agent will

								accept an invalid compact policy.</p>

								<ol>

								  <li>Compact policies that do not comply with the syntax specified in

								    section 4 of the P3P 1.0 Specificaiton or section 4 of the P3P 1.1

								    specification are invalid.</li>

								  <li>Compact policies for which there is no corresponding full P3P policy

								    are invalid. (Note, in some cases user agents may not be able to verify

								    that a corresponding full P3P policy exists until after storing and

								    possibly even replaying a cookie. In that case, upon determining that no

								    full P3P policy exists, the user agent should refrain from further replay

								    of that cookie.)</li>

								  <li>Compact policies that include the IVA token that do not include at

								    least one of the following tokens are invalid: PHY, ONL, FIN, PUR, GOV.

								    (RATIONALE: This purpose requires "identified data". While it is possible

								    to have other categories associated with an identified subject, the

								    actual identification is impossible without a data element associated

								    with one or more of the above categories.)</li>

								  <li>Compact policies that include the IVD token that do not include at

								    least one of the following tokens are invalid: PHY, ONL, FIN, PUR, GOV.

								    (RATIONALE: This purpose requires "identified data". While it is possible

								    to have other categories associated with an identified subject, the

								    actual identification is impossible without a data element associated

								    with one or more of the above categories.)</li>

								  <li>Compact policies that include the CON token that do not include at

								    least one of the following tokens are invalid: PHY, ONL. (RATIONALE:

								    Logic dictates that to contact an individual the initiator of the contact

								    would possess a data element identifying the individual in a place where

								    he or she would be contacted - either the online or offline worlds. This

								    would presuppose elements contained by one of the above categories.)</li>

								  <li>Compact policies that include the TEL token that do not include the PHY

								    token are invalid. (RATIONALE: Again logic dictates that if you are going

								    to contact someone via telephone, you at least have a data element that

								    contains phone numbers. These data elements should all be within the

								    Physical category.)</li>

								</ol>


								<h3 id="ua_sanity">6.5 Sanity Checking P3P Policies</h3>


								<p>Although the P3P 1.1. specification does not hold user agents responsible

								for verifying that web site P3P policies are accurate, it is a good idea for

								user agents to do some sanity checking to flag P3P policies that are

								obviously erroneous. Such policies should be deemed invalid. The following

								guidelines are designed to reduce the chance that a P3P user agent will

								accept an invalid policy. (See also <a href="#XHTML-link">section 2.4.4</a> Policy and Policy Reference

								File Processing by User Agents.)</p>

								<ol>

								  <li>A policy is invalid if it contains a <code>STATEMENT</code> that includes the

								    individual-analysis element and does not include at least one data

								    element from one of the following data categories: physical, online,

								    financial, purchase, government. (RATIONALE: This purpose requires

								    "identified data". While it is possible to have other categories

								    associated with an identified subject, the actual identification is

								    impossible without a data element associated with one or more of the

								    above categories.)</li>

								  <li>A policy is invalid if it contains a <code>STATEMENT</code> that includes the

								    individual-decision element and does not include at least one data

								    element from one of the following data categories: physical, online,

								    financial, purchase, government. (RATIONAEL: This purpose requires

								    "identified data". While it is possible to have other categories

								    associated with an identified subject, the actual identification is

								    impossible without a data element associated with one or more of the

								    above categories.)</li>

								  <li>A policy is invalid if it contains a <code>STATEMENT</code> that includes the

								    contact element and does not include at least one data element from one

								    of the following data categories: physical, online. (RATIONALE: Logic

								    dictates that to contact an individual the initiator of the contact would

								    possess a data element identifying the individual in a place where he or

								    she would be contacted - either the online or offline worlds. This would

								    presuppose elements contained by one of the above categories.)</li>

								  <li>A policy is invalid if it contains a <code>STATEMENT</code> that includes the

								    telemarketing element and does not include at least one data element from

								    the physical category. (<em>Rationale</em>: Again logic dictates that if

								    you are going to contact someone via telephone, you at least have a data

								    element that contains phone numbers. These data elements should all be

								    within the Physical category.)</li>

								</ol>


								<h3 id="ua_notice">6.6 Timing of Notices to Users</h3>


								<p>As a best practice, users should receive notice about a site's privacy

								practices prior to their user agent transmitting any personal data. Personal

								data means anything which might reasonably be linked to the user (see section

								<a href="#def_identity">1.3 Identity Definitions</a>) and as such can even

								include IP addresses and locale data transmitted in http headers before a

								page has even loaded. In order to present such notice, a user agent would

								need to fetch a P3P policy prior to loading a page following the guidelines

								specified in section <a href="#safezone">2.4.3 The Safe Zone.</a> However,

								implementers will need to consider the performance, usability, and privacy

								tradeoffs associated with displaying privacy information prior to loading a

								page. One way that privacy and usability might be simultaneously maximized is

								to treat all requests made prior to display of policy information as <a

								href="#safezone">safe zone</a> requests.</p>


								<p>At sites that include form fields, user agents SHOULD provide notice about

								the corresponding privacy practices prior to form submittal. Besides being

								best practice, this may be needed in order to comply with regulations in some

								jurisdictions (such as the European Union) that require a notice about the

								purpose of data collection to be presented to the user before any personal

								information is captured. User interface designs should recognize that the

								privacy policy for the form's action [URI] may be different than the privacy

								policy for the HTML page in which the form is embedded. In order to allow

								users to view privacy policy information associated with action URIs prior to

								form submittal, user agents might include a privacy tab that loads policy

								information for action URIs as a page loads, a button or menu item that

								causes policy information for action URIs to be displayed, or a pop-up that

								appears when a user begins entering information into a form field.</p>

								</div>


								<hr />


								<h1 id="Appendices">7. Appendices</h1>


								<div id="References_normative">

								<h2 >Appendix 1: References (Normative)</h2>

								<dl>

								  <dt>[<a name="ABNF" id="ABNF"><strong>ABNF</strong></a>]</dt>

								    <dd>D. Crocker, P. Overel. "<a

								      href="http://www.ietf.org/rfc/rfc2234.txt">Augmented BNF for Syntax

								      Specifications: ABNF</a>," RFC2234, IETF, November 1997.<br />

								      Available at <a

								      href="http://www.ietf.org/rfc/rfc2234.txt">http://www.ietf.org/rfc/rfc2234.txt</a>.</dd>

								  <dt>[<a name="CHARMODEL" id="CHARMODEL"><strong>CHARMODEL</strong></a>]</dt>

								    <dd>M. Dürst, <em>et al.</em> (Eds.), "<a

								      href="http://www.w3.org/TR/charmod/">Character Model for the World Wide

								      Web</a>," <a href="http://www.w3.org/">World Wide Web Consortium</a>

								      Working Draft. 20 February 2002.<br />

								      Latest version available at <a

								      href="http://www.w3.org/TR/charmod/">http://www.w3.org/TR/charmod/</a>.</dd>

								  <dt>[<strong><a name="ref_DOM2-Events"

								  id="ref_DOM2-Events">DOM2-Events</a></strong>]</dt>

								    <dd>T. Pixley (Ed.), "<a

								      href="http://www.w3.org/TR/DOM-Level-2-Events/">Document Object Model

								      (DOM) Level 2 Events Specification</a>," <a

								      href="http://www.w3.org/">World Wide Web Consortium</a>,

								      Recommendation. 13 November 2000.<br />

								      Available at <a

								      href="http://www.w3.org/TR/DOM-Level-2-Events/">http://www.w3.org/TR/DOM-Level-2-Events/</a>.</dd>

								  <dt>[<a name="HTTP1_0_ref"

								  id="HTTP1_0_ref"><strong>HTTP1.0</strong></a>]</dt>

								    <dd>T. Berners-Lee, R. Fielding, H. Frystyk, "<a

								      href="http://www.ietf.org/rfc/rfc1945.txt">Hypertext Transfer Protocol

								      -- HTTP/1.0</a>," RFC1945, IETF, May 1996.<br />

								      Available at <a

								      href="http://www.ietf.org/rfc/rfc1945.txt">http://www.ietf.org/rfc/rfc1945.txt</a>.</dd>

								  <dt>[<a name="HTTP1_1_ref"

								  id="HTTP1_1_ref"><strong>HTTP1.1</strong></a>]</dt>

								    <dd>R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach,

								      T. Berners-Lee, "<a

								      href="http://www.ietf.org/rfc/rfc2616.txt">Hypertext Transfer Protocol

								      -- HTTP/1.1</a>," RFC2616, IETF, June 1999. [Updates <a

								      href="http://www.ietf.org/rfc/rfc2068.txt">RFC2068</a>]<br />

								      Available at <a

								      href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a>.</dd>

								  <dt>[<strong><a name="HTML" id="HTML">HTML</a></strong>]</dt>

								    <dd>D. Raggett, A. Le Hors, and I. Jacobs (Eds.). "<a

								      href="http://www.w3.org/TR/html401/">HTML 4.01 Specification</a>" <a

								      href="http://www.w3.org/">World Wide Web Consortium</a>,

								      Recommendation. 24 Dicember 1999.<br />

								      Available at <a

								      href="http://www.w3.org/TR/html401/">http://www.w3.org/TR/html401/</a>.</dd>

								  <dt>[<a name="KEY" id="KEY"><strong>KEY</strong></a>]</dt>

								    <dd>S. Bradner. "<a href="http://www.ietf.org/rfc/rfc2119.txt">Key words

								      for use in RFCs to Indicate Requirement Levels</a>." RFC2119, IETF,

								      March 1997.<br />

								      Available at <a

								      href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>.</dd>

								  <dt>[<strong><a name="LANG" id="LANG">LANG</a></strong>]</dt>

								    <dd>H. Alvestrand, "<a href="http://www.ietf.org/rfc/rfc1766.txt">Tags

								      for the Identification of Languages.</a>" RFC1766, IETF, 1995.<br />

								      Available at <a

								      href="http://www.ietf.org/rfc/rfc1766.txt">http://www.ietf.org/rfc/rfc1766.txt</a>.</dd>

								  <dt>[<a name="ref_STATE" id="ref_STATE"><strong>STATE</strong></a>]</dt>

								    <dd>D. Kristol, L. Montulli, "<a

								      href="http://www.ietf.org/rfc/rfc2965.txt">HTTP State Management

								      Mechanism</a>." RFC2695, IETF, October, 2000 [Obsoletes <a

								      href="http://www.ietf.org/rfc/rfc2109.txt">RFC2109</a>]<br />

								      Available at <a

								      href="http://www.ietf.org/rfc/rfc2965.txt">http://www.ietf.org/rfc/rfc2965.txt</a>.</dd>

								  <dt>[<a name="URI" id="URI"><strong>URI</strong></a>]</dt>

								    <dd>T. Berners-Lee, R. Fielding, and L. Masinter. "<a

								      href="http://www.ietf.org/rfc/rfc3986.txt">Uniform Resource Identifiers

								      (URI): Generic Syntax and Semantics</a>." RFC3986, IETF, August 1998.

								      [Updates <a href="http://www.ietf.org/rfc/rfc1738.txt">RFC1738</a>]<br

								      />

								      Available at <a

								      href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>.</dd>

								  <dt>[<a name="UTF-8" id="UTF-8"><strong>UTF-8</strong></a>]</dt>

								    <dd>F. Yergeau. "<a href="http://www.ietf.org/rfc/rfc2279.txt">UTF-8, a

								      transformation format of ISO 10646</a>." RFC2279, IETF, January

								      1998.<br />

								      Available at <a

								      href="http://www.ietf.org/rfc/rfc2279.txt">http://www.ietf.org/rfc/rfc2279.txt</a>.</dd>

								  <dt>[<strong><a name="XHTML-MOD" id="XHTML-MOD">XHTML-MOD</a></strong>]</dt>

								    <dd>M. Altheim, <em>et al.</em> (Eds.). "<a

								      href="http://www.w3.org/TR/xhtml-modularization/">Modularization of

								      XHTML</a>". <a href="http://www.w3.org/">World Wide Web Consortium</a>,

								      Recommendation. 10 April 2000.<br />

								      Available at <a

								      href="http://www.w3.org/TR/xhtml-modularization/">http://www.w3.org/TR/xhtml-modularization/</a>.</dd>

								  <dt>[<a name="XML" id="XML"><strong>XML</strong></a>]</dt>

								    <dd>T. Bray, J. Paoli, C. M. Sperberg-McQueen, E.Maler (Eds.). "<a

								      href="http://www.w3.org/TR/REC-xml/">Extensible Markup Language (XML)

								      1.0 Specification (Second Edition)</a>." <a

								      href="http://www.w3.org/">World Wide Web Consortium</a>,

								      Recommendation. 6 October 2000.<br />

								      Available at <a

								      href="http://www.w3.org/TR/REC-xml/">http://www.w3.org/TR/REC-xml/</a>.</dd>

								  <dt>[<a name="XML-Name" id="XML-Name"><strong>XML-Name</strong></a>]</dt>

								    <dd>T. Bray, D. Hollander, A. Layman (Eds.). "<a

								      href="http://www.w3.org/TR/REC-xml-names/">Namespaces in XML.</a>" <a

								      href="http://www.w3.org/">World Wide Web Consortium</a>,

								      Recommendation. 14 January 1999.<br />

								      Available at <a

								      href="http://www.w3.org/TR/REC-xml-names/">http://www.w3.org/TR/REC-xml-names/</a>.</dd>

								  <dt>[<a name="XML-Schema1"

								  id="XML-Schema1"><strong>XML-Schema1</strong></a>]</dt>

								    <dd>H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn (Eds.). "<a

								      href="http://www.w3.org/TR/xmlschema-1/">XML Schema Part 1:

								      Structures</a>" <a href="http://www.w3.org/">World Wide Web

								      Consortium</a> Recommendation. 2 May 2001.<br />

								      Available at <a

								      href="http://www.w3.org/TR/xmlschema-1/">http://www.w3.org/TR/xmlschema-1/</a>.</dd>

								  <dt>[<a name="XML-Schema2"

								  id="XML-Schema2"><strong>XML-Schema2</strong></a>]</dt>

								    <dd>P. Biron, A. Malhotra (Eds.). "<a

								      href="http://www.w3.org/TR/xmlschema-2/">XML Schema Part 2:

								      Datatypes</a>" <a href="http://www.w3.org/">World Wide Web

								      Consortium</a> Recommendation. 2 May 2001.<br />

								      Available at <a

								      href="http://www.w3.org/TR/xmlschema-2/">http://www.w3.org/TR/xmlschema-2/</a>.</dd>

								</dl>

								</div>


								<div id="References_nonnormative">

								<h2>Appendix 2: References (Non-Normative)</h2>

								<dl>

								  <dt>[<strong><a name="APPEL" id="APPEL">APPEL</a></strong>]</dt>

								    <dd>M. Langheinrich (Ed.). "<a

								      href="http://www.w3.org/TR/P3P-preferences/">A P3P Preference Exchange

								      Language (APPEL)</a>." <a href="http://www.w3.org/">World Wide Web

								      Consortium</a> Working Draft. 26 February 2001.<br />

								      Available at <a

								      href="http://www.w3.org/TR/P3P-preferences/">http://www.w3.org/TR/P3P-preferences</a>.</dd>

								  <dt>[<a name="CACHING" id="CACHING"><strong>CACHING</strong></a>]</dt>

								    <dd>I. Cooper, I. Melve, G. Tomlinson. "<a

								      href="http://www.ietf.org/rfc/rfc3040.txt">Internet Web Replication and

								      Caching Taxonomy</a>." RFC3040, IETF, January 2001.<br />

								      Available at <a

								      href="http://www.ietf.org/rfc/rfc3040.txt">http://www.ietf.org/rfc/rfc3040.txt</a>.</dd>

								  <dt>[<a name="ref_COOKIES"

								  id="ref_COOKIES"><strong>COOKIES</strong></a>]</dt>

								    <dd><q><a

								      href="http://tools.ietf.org/html/rfc2965">Persistent

								      Client State -- HTTP Cookies</a></q>, RFC2965, IETF, October 2000<br/>

								      Available at <a href="http://www.ietf.org/rfc/rfc2965.txt">

								      http://www.ietf.org/rfc/rfc2965.txt</a>.</dd>

								  <dt>[<a name="coremetrics" id="coremetrics">Coremetrics</a>]</dt>

								    <dd><q><a href="http://www.w3.org/2002/p3p-ws/pp/coremetrics.pdf">Agents

								      and P3P</a></q>P3P Position Paper: W3C Workshop on the Future of P3P

								      November 12-13, 2002</dd>

								  <dt>[<a name="cranor-p3p"

								  id="cranor-p3p"><strong>Cranor,P3P</strong></a>]</dt>

								    <dd><q><a href="http://p3pbook.com/">Web Privacy with P3P</a></q> by

								      Lorrie Faith Cranor, O'Reilly &amp; Associates, 2002</dd>

								  <dt>[<a name="iso3166" id="iso3166"><strong>ISO3166</strong></a>]</dt>

								    <dd>"ISO3166: Codes for The Representation of Names of Countries."

								      International Organization for Standardization.</dd>

								  <dt>[<a name="ISO8601" id="ISO8601"><strong>ISO8601</strong></a>]</dt>

								    <dd>"ISO8601: Data elements and interchange formats -- Information

								      interchange -- Representation of dates and times." International

								      Organization for Standardization.</dd>

								  <dt>[<a name="P3P-HEADER"

								  id="P3P-HEADER"><strong>P3P-HEADER</strong></a>]</dt>

								    <dd>M. Marchiori, R. Lotenberg (Eds.), "The HTTP header for the Platform

								      for Privacy Preferences 1.0 (P3P 1.0)." IETF Internet Draft, 2002.<br />

								      Latest version available as text at <a

								      href="http://www.w3.org/2002/04/P3Pv1-header.txt">http://www.w3.org/2002/04/P3Pv1-header.txt</a>.<br

								      />

								      Latest version available as HTML at <a

								      href="http://www.w3.org/2002/04/P3Pv1-header.html">http://www.w3.org/2002/04/P3Pv1-header.html</a>.<br

								      />

								      Latest version available as XML at <a

								      href="http://www.w3.org/2002/04/P3Pv1-header.xml">http://www.w3.org/2002/04/P3Pv1-header.xml</a>.</dd>

								  <dt>[<strong><a name="P3P-RDF" id="P3P-RDF">P3P-RDF</a></strong>]</dt>

								    <dd>B. McBride, R.Wenning, L.Cranor. "<a

								      href="http://www.w3.org/TR/p3p-rdfschema/">An RDF Schema for P3P</a>."

								      <a href="http://www.w3.org/">World Wide Web Consortium</a>, Note. 25

								      January 2002.<br />

								      Latest version available at <a

								      href="http://www.w3.org/TR/p3p-rdfschema/">http://www.w3.org/TR/p3p-rdfschema/</a>.</dd>

								  <dt>[<a name="RDF" id="RDF"><strong>RDF</strong></a>]</dt>

								    <dd>O. Lassila and R. Swick (Eds.). "<a

								      href="http://www.w3.org/TR/REC-rdf-syntax/">Resource Description

								      Framework (RDF) Model and Syntax Specification.</a>" <a

								      href="http://www.w3.org/">World Wide Web Consortium</a>,

								      Recommendation. 22 February 1999.<br />

								      Available at <a

								      href="http://www.w3.org/TR/REC-rdf-syntax/">http://www.w3.org/TR/REC-rdf-syntax/</a>.</dd>

								  <dt>[<a name="UNICODE" id="UNICODE"><strong>UNICODE</strong></a>]</dt>

								    <dd>Unicode Consortium. "<a

								      href="http://www.unicode.org/unicode/standard/standard.html">The

								      Unicode Standard</a>"<br />

								      Available at <a

								      href="http://www.unicode.org/unicode/standard/standard.html">http://www.unicode.org/unicode/standard/standard.html</a>.</dd>

								</dl>

								</div>


								<h2 id="basedataxml">Appendix 3: The P3P

								    1.1 Base Data schema Definition (Normative)</h2>


								<p>The data schema corresponding to the P3P 1.1 base data schema follows for easy

								reference. The schema below is using XML Schema to express the P3P Base Data Schema.

								It includes syntax and semantics of the old P3P 1.0 Base Data Schema. Using the

								<a href="#Appendix_xslt">Transforms for backwards compatibility</a> below, it can be

								also used by P3P 1.0 user agents.  The schema is also present as a separate file at the URI <a

								href="http://www.w3.org/2006/01/P3Pv11BDS">http://www.w3.org/2006/01/P3Pv11BDS</a> .</p>


								<pre>

								&lt;?xml version="1.0" encoding="UTF-8"?&gt;

								&lt;!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN"

								 "http://www.w3.org/2001/XMLSchema.dtd" &gt;

								&lt;schema

								  xmlns="http://www.w3.org/2001/XMLSchema"

								  xmlns:p3p11bds="http://www.w3.org/2006/01/P3Pv11BDS"

								  xmlns:p3p="http://www.w3.org/2002/01/P3Pv1"

								  xmlns:p3p11="http://www.w3.org/2006/01/P3Pv11"

								  elementFormDefault="qualified"

								  targetNamespace="http://www.w3.org/2006/01/P3Pv11BDS"&gt;


								  &lt;import

								    namespace="http://www.w3.org/2002/01/P3Pv1"

								    schemaLocation="http://www.w3.org/2002/01/P3Pv1.xsd"  /&gt;

								  &lt;import

								    namespace="http://www.w3.org/2006/01/P3Pv11"

								    schemaLocation="http://www.w3.org/2006/01/P3Pv11.xsd" /&gt;


								     &lt;complexType name="categoriesComplexType"&gt;

								       &lt;all&gt;

								        &lt;element ref="p3p:CATEGORIES" minOccurs="1" /&gt;

								       &lt;/all&gt;

								     &lt;/complexType&gt;


								     &lt;complexType name="dynamicComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="clickstream" type="p3p11bds:loginfoComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES  xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;navigation /&gt;

								             &lt;computer /&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Click-stream Information&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="http" type="p3p11bds:httpinfoComplexType"&gt;

								        &lt;annotation&gt;

								         &lt;appinfo&gt;

								          &lt;CATEGORIES  xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								           &lt;navigation /&gt;

								           &lt;computer /&gt;

								          &lt;/CATEGORIES&gt;

								         &lt;/appinfo&gt;

								         &lt;documentation&gt;HTTP Protocol Information&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="clientevents"&gt;

								        &lt;annotation&gt;

								         &lt;appinfo&gt;

								          &lt;CATEGORIES  xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								           &lt;navigation /&gt;

								          &lt;/CATEGORIES&gt;

								         &lt;/appinfo&gt;

								         &lt;documentation&gt;User's Interaction with a Resource&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="cookies" type="p3p11bds:categoriesComplexType"&gt;

								        &lt;annotation&gt;

								         &lt;documentation&gt;Use of HTTP Cookies&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="searchtext"&gt;

								        &lt;annotation&gt;

								         &lt;appinfo&gt;

								          &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								           &lt;interactive /&gt;

								          &lt;/CATEGORIES&gt;

								         &lt;/appinfo&gt;

								         &lt;documentation&gt;Search Terms&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="interactionrecord"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;interactive /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Server Stores the Transaction History&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="miscdata" type="p3p11bds:categoriesComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;documentation&gt;Miscellaneous Non-base Data Schema = information&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								     &lt;complexType name="loginfoComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="uri" type="p3p11bds:uriComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;navigation /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;URI of Requested Resource&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="timestamp" type="p3p11bds:dateComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;navigation /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Request Timestamp&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="clientip" type="p3p11bds:ipaddrComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;documentation&gt;Client's IP Address or Hostname&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="other.httpmethod"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;navigation /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;HTTP Request Method&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="other.bytes"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;navigation /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Data Bytes in Response&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="other.statuscode"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;navigation /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Response Status Code&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								     &lt;complexType name="uriComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="authority"&gt;

								        &lt;annotation&gt;

								           &lt;documentation&gt;URI Authority&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="stem"&gt;

								        &lt;annotation&gt;

								           &lt;documentation&gt;URI Stem&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="querystring"&gt;

								        &lt;annotation&gt;

								           &lt;documentation&gt;Query-string Portion of URI&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								     &lt;complexType name="dateComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="ymd.year"&gt;

								        &lt;annotation&gt;

								           &lt;documentation&gt;Year&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="ymd.month"&gt;

								        &lt;annotation&gt;

								           &lt;documentation&gt;Month&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="ymd.day"&gt;

								        &lt;annotation&gt;

								           &lt;documentation&gt;Day&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="hms.hour"&gt;

								        &lt;annotation&gt;

								           &lt;documentation&gt;Hour&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="hms.minute"&gt;

								        &lt;annotation&gt;

								           &lt;documentation&gt;Minutes&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="hms.second"&gt;

								        &lt;annotation&gt;

								           &lt;documentation&gt;Second&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="fractionsecond"&gt;

								        &lt;annotation&gt;

								           &lt;documentation&gt;Fraction of Second&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="timezone"&gt;

								        &lt;annotation&gt;

								           &lt;documentation&gt;Time Zone&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								     &lt;complexType name="ipaddrComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="hostname"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;computer /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Complete Host and Domain Name&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="partialhostname"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Partial Hostname&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="fullip"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;computer /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Full IP Address&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="partialip"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Partial IP Address&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								     &lt;complexType name="httpinfoComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="referer" type="p3p11bds:uriComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;navigation /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Last URI Requested by the User&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="useragent"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;computer /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;User Agent Information&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								     &lt;complexType name="userComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="name" type="p3p11bds:personnameComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;User's Name&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="bdate" type="p3p11bds:dateComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;User's Birth Date&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="login" type="p3p11bds:loginComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;uniqueid /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;User's Login Information&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="cert" type="p3p11bds:certificateComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;uniqueid /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;User's Identity Certificate&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="gender"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;User's Gender&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="jobtitle"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;User's Job Title&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="home-info" type="p3p11bds:contactComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								             &lt;online /&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;User's Home Contact Information&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="business-info" type="p3p11bds:contactComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								             &lt;online /&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;User's Business Contact Information&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="employer"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Name of User's Employer&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="department"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Department or Division of Organization where User is Employed&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								     &lt;complexType name="personnameComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="prefix"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Name Prefix&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="given"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Given Name (First Name)&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="middle"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Middle Name&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="family"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Family Name (Last Name)&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="suffix"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Name Suffix&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="nickname"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Nickname&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								     &lt;complexType name="loginComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="id"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;uniqueid /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Login ID&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="password"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;uniqueid /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Login Password&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								     &lt;complexType name="certificateComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="key"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;uniqueid /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Certificate key&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="format"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;uniqueid /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Certificate format&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								     &lt;complexType name="contactComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="postal" type="p3p11bds:postalComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;documentation&gt;Postal Address Information&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="telecom" type="p3p11bds:telecomComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Telecommunications Information&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="online" type="p3p11bds:onlineComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;online /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Online Address Information&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								     &lt;complexType name="postalComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="name" type="p3p11bds:personnameComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;documentation /&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="street"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Street Address&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="city"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;City&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="stateprov"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;State or Province&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="postalcode"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Postal Code&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="organization"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Organization Name&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="country"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Country Name&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								     &lt;complexType name="telecomComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="telephone" type="p3p11bds:telephonenumComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Telephone Number&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="fax" type="p3p11bds:telephonenumComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Fax Number&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="mobile" type="p3p11bds:telephonenumComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Mobile Telephone Number&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="pager" type="p3p11bds:telephonenumComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Pager Number&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								     &lt;complexType name="telephonenumComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="intcode"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;International Telephone Code&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="loccode"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Local Telephone Area Code&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="number"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Telephone Number&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="ext"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Telephone Extension&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="comment"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Telephone Optional Comments&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								     &lt;complexType name="onlineComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="email"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;online /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Email Address&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="uri"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;online /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Home Page Address&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								     &lt;complexType name="thirdpartyComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="name" type="p3p11bds:personnameComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Third Party's Name&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="bdate" type="p3p11bds:dateComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Third Party's Birth Date&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="login" type="p3p11bds:loginComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;uniqueid /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Third Party's Login Information&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="cert" type="p3p11bds:certificateComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;uniqueid /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Third Party's Identity Certificate&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="gender"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Third Party's Gender&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="jobtitle"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Third Party's Job Title&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="home-info" type="p3p11bds:contactComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								             &lt;online /&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Third Party's Home Contact Information&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="business-info" type="p3p11bds:contactComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								             &lt;online /&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Third Party's Business Contact Information&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="employer"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Name of Third Party's Employer&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="department"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Department or Division of Organization where Third Party is Employed&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								     &lt;complexType name="businessComplexType"&gt;

								      &lt;all&gt;

								       &lt;element minOccurs="0" name="orgname"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Organization Name&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="department"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Department or Division of Organization&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="cert" type="p3p11bds:certificateComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;uniqueid /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Organization Identity certificate&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								       &lt;element minOccurs="0" name="contact-info" type="p3p11bds:contactComplexType"&gt;

								        &lt;annotation&gt;

								           &lt;appinfo&gt;

								            &lt;CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"&gt;

								             &lt;physical /&gt;

								             &lt;online /&gt;

								             &lt;demographic /&gt;

								            &lt;/CATEGORIES&gt;

								           &lt;/appinfo&gt;

								           &lt;documentation&gt;Contact Information for the Organization&lt;/documentation&gt;

								        &lt;/annotation&gt;

								       &lt;/element&gt;

								      &lt;/all&gt;

								     &lt;/complexType&gt;

								  &lt;/schema&gt;

								</pre>


								<h2 id="Appendix_xslt">Appendix 4: XSLT Transforms for

								  Policies and Schema files from P3P 1.0 to P3P 1.1</h2>


								There are two transforms:

								  <ol>

								    <li>A <a href="http://www.w3.org/2005/09/policytransformP3PDataElements.xsl">

								      Policy transform [XSLT-sheet]</a> that turns P3P 1.1 Data Elements into the

								      backward compatible form as well as turning P3P 1.0 Data Elements into

								      the same backward compatible form

								    </li>

								    <li>If applied twice or more, the Policy-transform above duplicates the elements.

								      <a href="http://www.w3.org/2005/09/removeDuplicatePolicyDataElements.xsl">

								      A second XSLT-sheet [XSLT-sheet]</a> removes those duplicates introduced accidently.

								    </li>

								  </ol>


								<p>As described in <a href="#Data_Schemas_back">5.7. Backward Compatibility

								Requirements</a>, the <a href="http://www.w3.org/2005/09/policytransformP3PDataElements.xsl">

								Policy transform</a> serves to transform policies or custom schemata

								from either the new P3P 1.1 format or the old P3P 1.0 format into a backwards

								compatible format containing both versions. This can be done using the XSLT-Sheets

								below or just using the <a href="http://www.w3.org/2005/09/p3p-converter.html">

								W3C P3P Transformation Service</a> </p>


								<p> This way, users can either use the well known P3P Editors or use

								widely available XML-tools to produce P3P Dataschemas. Once the P3P Data Schema

								(which is now pure XML Schema) is produced, it can

								be transformed using the transforms mentioned and annexed below.</p>


								<h3 id="policy_xslt">P3P Policy backward compatibility

								transform</h3>


								  <p>This XSLT stylesheet transforms P3P 1.1 <code>datatype</code>

								  elements into a combined code of <code>datatype</code> elements

								  and P3P 1.0 <code>DATA</code> elements for backwards compatibility.

								  See <a href="#Data_Schemas_back">5.7. Backward Compatibility

								  Requirements</a> for more information</p>


								<pre>

								&lt;?xml version="1.0" encoding="UTF-8"?&gt;

								&lt;xsl:stylesheet

								version="1.0"

								xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

								    xmlns="http://www.w3.org/2002/01/P3Pv1"

								    exclude-result-prefixes="xsl"&gt;


								&lt;!--

								****************************************************************************************************

								Note that if the input policy contains a mixture of P3P1.0 and P3P1.1 elements or you

								have already run the transform once on your policy, then you should run the

								removeduplicates xslt (following in the specification).

								 ****************************************************************************************************

								 --&gt;

								  &lt;!-- Simple identity function to output the rest of the policy--&gt;


								  &lt;xsl:template match="@*|*|processing-instruction()|comment()" priority="-2"&gt;

								    &lt;xsl:copy&gt;

								      &lt;xsl:apply-templates select="*|@*|text()" /&gt;

								    &lt;/xsl:copy&gt;

								  &lt;/xsl:template&gt;


								 &lt;!--

								****************************************************************************************************

								 Transform new data elements to old data elements and add the transformations alongside

								 Works by getting the leaves and then going back up to the top (as there can be multiple leaves now.

								****************************************************************************************************

								  --&gt;


								  &lt;xsl:template match="//*[local-name()='EXTENSION'][count(child::*[local-name()='datatype'])!=0]"&gt;

								    &lt;xsl:for-each

								      select=".//*[count(child::*[local-name()!='CATEGORIES'])=0

								      and count(ancestor::*[local-name()='CATEGORIES'])=0]"&gt;

								        &lt;xsl:element name="DATA"&gt;

								          &lt;xsl:attribute name="ref"&gt;

								            &lt;xsl:variable name="tempStr"&gt;

								              &lt;xsl:call-template name="StrConcat"&gt;

								                &lt;xsl:with-param name="dot"&gt;

								                  .

								                &lt;/xsl:with-param&gt;

								              &lt;/xsl:call-template&gt;

								            &lt;/xsl:variable&gt;

								            &lt;xsl:value-of

								              select="concat('#',substring-after($tempStr,'.'))"/&gt;

								          &lt;/xsl:attribute&gt;

								          &lt;xsl:if test="count(.//*[local-name()='CATEGORIES'])!=0"&gt;

								            &lt;xsl:copy-of select=".//*[local-name()='CATEGORIES']"/&gt;

								          &lt;/xsl:if&gt;

								          &lt;xsl:value-of select="."/&gt;

								        &lt;/xsl:element&gt;

								    &lt;/xsl:for-each&gt;

								    &lt;xsl:copy-of select="."/&gt;

								  &lt;/xsl:template&gt;


								  &lt;!--

								   ****************************************************************************************************

								   Transform old data elements and add the transformations alongside

								    ****************************************************************************************************

								   --&gt;

								  &lt;xsl:template match="//*[local-name()='DATA']" &gt;

								    &lt;xsl:element name="EXTENSION"&gt;

								      &lt;xsl:element name="datatype"&gt;

								        &lt;xsl:if test="@*[local-name()='optional']"&gt;

								          &lt;xsl:copy-of select="@*[local-name()='optional']"/&gt;

								        &lt;/xsl:if&gt;

								        &lt;xsl:variable name="refAttribute" select="@*[local-name()='ref']"/&gt;

								          &lt;xsl:call-template name="StrSplit"&gt;

								            &lt;xsl:with-param name="str" select="substring-after($refAttribute,'#')"/&gt;

								          &lt;/xsl:call-template&gt;

								      &lt;/xsl:element&gt;

								    &lt;/xsl:element&gt;

								    &lt;xsl:copy-of select="."/&gt;

								  &lt;/xsl:template&gt;


								&lt;!--

								*****************************************************************************************************************

								reconsitute the ref attributes - for backward (P3P1.1 -&gt; P3P1.0) transform

								****************************************************************************************************************

								--&gt;


								 &lt;xsl:template name="StrConcat"&gt;

								   &lt;xsl:param name="dot" select="/.."/&gt;

								    &lt;xsl:if test="local-name()!='datatype'"&gt;

								      &lt;xsl:for-each select="parent::*"&gt;

								        &lt;xsl:call-template name="StrConcat"&gt;

								          &lt;xsl:with-param name="dot"&gt;

								            .

								          &lt;/xsl:with-param&gt;

								        &lt;/xsl:call-template&gt;

								      &lt;/xsl:for-each&gt;

								      &lt;xsl:value-of select="$dot"/&gt;

								  &lt;!-- Change the business.name attribute if there is one --&gt;

								      &lt;xsl:choose&gt;

								        &lt;xsl:when

								          test="local-name()='orgname'"&gt;

								            name

								        &lt;/xsl:when&gt;

								        &lt;xsl:otherwise&gt;

								          &lt;xsl:value-of select="local-name()"/&gt;

								        &lt;/xsl:otherwise&gt;

								      &lt;/xsl:choose&gt;

								    &lt;/xsl:if&gt;

								  &lt;/xsl:template&gt;


								&lt;!--

								 ****************************************************************************************************

								String Split for forward (P3P1.0 -&gt; P3P1.1) transform

								 ****************************************************************************************************

								--&gt;


								  &lt;xsl:template name="StrSplit"&gt;

								    &lt;xsl:param name="str" select="/.."/&gt;

								    &lt;xsl:param name="parent" select="/.."/&gt;

								    &lt;xsl:choose&gt;

								      &lt;xsl:when test="contains($str,'.')

								        and substring-before($str,'.')!='ymd'

								        and substring-before($str,'.')!='hms'"&gt;

								          &lt;xsl:element name="{substring-before($str,'.')}"&gt;

								            &lt;xsl:call-template name="StrSplit"&gt;

								              &lt;xsl:with-param name="str"

								                select="substring-after($str,'.')" /&gt;

								              &lt;xsl:with-param name="parent" select="$str" /&gt;

								            &lt;/xsl:call-template&gt;

								          &lt;/xsl:element&gt;

								      &lt;/xsl:when&gt;

								&lt;!--

								Change the business name to Orgname so it doesn't expect children like firstname, prefix etc...

								--&gt;


								      &lt;xsl:when test="$parent='business.name'"&gt;

								        &lt;xsl:element name="orgname"&gt;

								          &lt;xsl:for-each select="./*[local-name()='CATEGORIES']"&gt;

								            &lt;xsl:copy-of select="."/&gt;

								          &lt;/xsl:for-each&gt;

								          &lt;xsl:copy-of select="./text()"/&gt;

								        &lt;/xsl:element&gt;

								      &lt;/xsl:when&gt;

								      &lt;xsl:otherwise&gt;

								        &lt;xsl:element name="{$str}"&gt;

								          &lt;xsl:for-each select="./*[local-name()='CATEGORIES']"&gt;

								            &lt;xsl:copy-of select="."/&gt;

								          &lt;/xsl:for-each&gt;

								          &lt;xsl:copy-of select="./text()"/&gt;

								        &lt;/xsl:element&gt;

								      &lt;/xsl:otherwise&gt;

								    &lt;/xsl:choose&gt;

								  &lt;/xsl:template&gt;

								&lt;/xsl:stylesheet&gt;

								</pre>


								<h3 id="duplicates_xslt">P3P 1.1 transform to remove duplicates

								from previous transforms</h3>


								  <p>This XSLT stylesheet removes duplicate elements that have been

								  generated by applying the <a href="#policy_xslt">Policy-transform</a>

								  multiple times. See <a href="#Data_Schemas_back">5.7. Backward

								  Compatibility Requirements</a> for more information</p>


								<pre>

								&lt;?xml version="1.0" encoding="UTF-8"?&gt;

								&lt;xsl:stylesheet version="1.0"

								xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

								exclude-result-prefixes="xsl" &gt;


								  &lt;xsl:output method="xml" media-type="application/xml" /&gt;


								  &lt;!-- Simple identity function to output the rest of the policy--&gt;


								  &lt;xsl:template match="@*|*|processing-instruction()|comment()" priority="-2" &gt;

								    &lt;xsl:copy&gt;

								      &lt;xsl:apply-templates select="*|@*|text()|processing-instruction()|comment()" /&gt;

								    &lt;/xsl:copy&gt;

								   &lt;/xsl:template&gt;


								&lt;!-- remove duplicate EXTENSION elements --&gt;


								  &lt;xsl:template match="//*[local-name()='DATA-GROUP']/*[local-name()='EXTENSION']"&gt;

								    &lt;xsl:variable name="duplicates"&gt;

								      &lt;xsl:call-template name="detectDuplicateSiblings"&gt;

								        &lt;xsl:with-param name="node" select="."/&gt;

								      &lt;/xsl:call-template&gt;

								    &lt;/xsl:variable&gt;

								    &lt;xsl:if test="$duplicates!='true'"&gt;

								      &lt;xsl:copy-of select="."/&gt;

								    &lt;/xsl:if&gt;

								  &lt;/xsl:template&gt;


								  &lt;xsl:template name="detectDuplicateSiblings"&gt;

								    &lt;xsl:param name="node" select="/.."/&gt;

								    &lt;xsl:variable name="A" select="$node/descendant::*[(not(text()) or

								    not(normalize-space(string(.))='')) and count(child::*)=0]"/&gt;

								    &lt;xsl:variable name="extensionLeaves"

								    select="following-sibling::*[local-name()='EXTENSION']/descendant::*[(not(text())

								    or not(normalize-space(string(.))='')) and count(child::*)=0]"/&gt;

								    &lt;xsl:variable name="isTrue"&gt;

								      &lt;xsl:call-template name="loopExtensions"&gt;

								        &lt;xsl:with-param name="count" select="0"/&gt;

								        &lt;xsl:with-param name="contextNodeToTest" select="$A"/&gt;

								        &lt;xsl:with-param name="nodeList" select="$extensionLeaves"/&gt;

								      &lt;/xsl:call-template&gt;

								    &lt;/xsl:variable&gt;

								    &lt;xsl:value-of select="$isTrue"/&gt;

								  &lt;/xsl:template&gt;


								  &lt;xsl:template name="loopExtensions"&gt;

								    &lt;xsl:param name="count" select="/.."/&gt;

								    &lt;xsl:param name="nodeList" select="/.."/&gt;

								    &lt;xsl:param name="contextNodeToTest" select="/.."/&gt;

								    &lt;xsl:variable name="isEqualDeep"&gt;

								      &lt;xsl:call-template name="recurseComparison"&gt;

								        &lt;xsl:with-param name="A" select="$contextNodeToTest"/&gt;

								        &lt;xsl:with-param name="B" select="$nodeList[$count]"/&gt;

								        &lt;xsl:with-param name="level" select="0"/&gt;

								      &lt;/xsl:call-template&gt;

								    &lt;/xsl:variable&gt;

								    &lt;xsl:choose&gt;

								      &lt;xsl:when test="$isEqualDeep='true'"&gt;

								        true

								      &lt;/xsl:when&gt;

								      &lt;xsl:otherwise&gt;

								        &lt;xsl:if test="$count&amp;lt;count($nodeList)"&gt;

								          &lt;xsl:call-template name="loopExtensions"&gt;

								            &lt;xsl:with-param name="count" select="$count + 1"/&gt;

								            &lt;xsl:with-param name="nodeList" select="$nodeList"/&gt;

								            &lt;xsl:with-param name="contextNodeToTest" select="$contextNodeToTest"/&gt;

								          &lt;/xsl:call-template&gt;

								        &lt;/xsl:if&gt;

								      &lt;/xsl:otherwise&gt;

								    &lt;/xsl:choose&gt;

								  &lt;/xsl:template&gt;


								  &lt;xsl:template name="recurseComparison"&gt;

								    &lt;xsl:param name="A" select="/.."/&gt;

								    &lt;xsl:param name="B" select="/.."/&gt;

								    &lt;xsl:param name="level" select="/.."/&gt;

								    &lt;xsl:variable name="isEqual"&gt;

								      &lt;xsl:if test="local-name($A)=local-name($B)"&gt;

								        true

								      &lt;/xsl:if&gt;

								    &lt;/xsl:variable&gt;

								    &lt;xsl:choose&gt;

								      &lt;xsl:when test="$isEqual='true'"&gt;

								        &lt;xsl:choose&gt;

								          &lt;xsl:when

								            test="local-name($A/parent::*)!='datatype'

								            and local-name($B/parent::*)!='datatype'

								            and count($A/parent::*)!=0 "&gt;

								              &lt;xsl:call-template name="recurseComparison"&gt;

								                &lt;xsl:with-param name="A" select="$A/parent::*"/&gt;

								                &lt;xsl:with-param name="B" select="$B/parent::*"/&gt;

								                &lt;xsl:with-param name="level" select="$level+1"/&gt;

								              &lt;/xsl:call-template&gt;

								           &lt;/xsl:when&gt;

								           &lt;xsl:otherwise&gt;

								            true

								           &lt;/xsl:otherwise&gt;

								        &lt;/xsl:choose&gt;

								      &lt;/xsl:when&gt;

								      &lt;xsl:otherwise&gt;

								        false

								      &lt;/xsl:otherwise&gt;

								    &lt;/xsl:choose&gt;

								  &lt;/xsl:template&gt;


								&lt;!-- remove duplicate DATA elements --&gt;


								  &lt;xsl:template match="//*[local-name()='DATA']"&gt;

								    &lt;xsl:variable name="ref" select="@*[local-name()='ref']"/&gt;

								      &lt;xsl:if test="not($ref=following-sibling::*[local-name()='DATA']/@*[local-name()='ref'])"&gt;

								        &lt;xsl:copy-of select="."/&gt;

								      &lt;/xsl:if&gt;

								  &lt;/xsl:template&gt;


								&lt;/xsl:stylesheet&gt;

								</pre>


								<h2 id="p3p11_schema">Appendix 5: The XML Schema for P3P 1.1 Extensions and

								the P3P generic attribute</h2>


								<p>This appendix contains the XML schema for P3P 1.1 policy reference files, for

								P3P 1.1 policy documents, and for P3P 1.1 data schema documents. P3P 1.1 policy reference

								files, P3P policy documents and P3P data schema documents are XML documents

								that MUST conform to this schema. Note that this schema is based on the XML

								Schema specification [<a href="#XML-Schema1">XML-Schema1</a>][<a

								href="#XML-Schema2">XML-Schema2</a>]. The schema is also present as a

								separate file at <a href="http://www.w3.org/2006/01/P3Pv11.xsd">

								  http://www.w3.org/2006/01/P3Pv11.xsd</a>. </p>


								<p>The P3P 1.1 XML Schema imports all elements from the P3P 1.0 Schema.

								The P3P 1.0 XML Schema is not presented here, but can be found in the

								P3P 1.0 Specification or under it's namespace URI, notably <a

								href="http://www.w3.org/2002/01/P3Pv1.xsd">

								http://www.w3.org/2002/01/P3Pv1.xsd</a>.</p>


								<pre>

								&lt;?xml version="1.0" encoding="UTF-8"?&gt;

								&lt;schema

								  elementFormDefault="qualified"

								  targetNamespace="http://www.w3.org/2006/01/P3Pv11"

								  xmlns="http://www.w3.org/2001/XMLSchema"

								  xmlns:p3p="http://www.w3.org/2002/01/P3Pv1"

								  xmlns:p3p11="http://www.w3.org/2006/01/P3Pv11"

								  xmlns:p3p11bds="http://www.w3.org/2006/01/P3Pv11BDS"&gt;


								&lt;!-- enabling xml:lang attribute --&gt;

								  &lt;import

								    namespace="http://www.w3.org/XML/1998/namespace"

								    schemaLocation="http://www.w3.org/2001/xml.xsd"/&gt;

								  &lt;import

								    namespace="http://www.w3.org/2002/01/P3Pv1"

								    schemaLocation="http://www.w3.org/2002/01/P3Pv1"/&gt;

								  &lt;import

								    namespace="http://www.w3.org/2006/01/P3Pv11BDS"

								    schemaLocation="http://www.w3.org/2006/01/P3Pv11BDS.xsd" /&gt;


								  &lt;!-- *********** P3P 1.1 Elements ************ --&gt;

								  &lt;!-- p3p attribute --&gt;

								  &lt;attribute name="p3p" type="anyURI"&gt;

								    &lt;annotation&gt;

								      &lt;documentation&gt;

								        &lt;div xmlns="http://www.w3.org/1999/xhtml"&gt;

								          &lt;p&gt;The P3P-generic attribute takes a URI as its value.&lt;/p&gt;

								          &lt;p&gt;The meaning is that a P3P document describing the privacy

								            policy relevant to this element may be found at the URI given.&lt;/p&gt;

								        &lt;/div&gt;

								      &lt;/documentation&gt;

								    &lt;/annotation&gt;

								  &lt;/attribute&gt;


								  &lt;simpleType name="consent_value"&gt;

								    &lt;restriction base="string"&gt;

								      &lt;enumeration value="opt-in"/&gt;

								      &lt;enumeration value="opt-out"/&gt;

								      &lt;enumeration value="always"/&gt;

								      &lt;enumeration value="mixed"/&gt;

								    &lt;/restriction&gt;

								  &lt;/simpleType&gt;


								  &lt;element name="STATEMENT-GROUP-DEF"&gt;

								    &lt;complexType&gt;

								      &lt;attribute name="id" type="ID" use="required"/&gt;

								      &lt;attribute name="consent" type="p3p11:consent_value" use="optional"/&gt;

								      &lt;attribute name="name" type="string" use="optional"/&gt;

								      &lt;attribute name="short-description" type="string" use="optional"/&gt;

								    &lt;/complexType&gt;

								  &lt;/element&gt;


								  &lt;element name="STATEMENT-GROUP"&gt;

								    &lt;complexType&gt;

								      &lt;attribute name="id" type="IDREF" use="required"/&gt;

								    &lt;/complexType&gt;

								  &lt;/element&gt;


								  &lt;!-- ************ PPURPOSE ************* --&gt;

								  &lt;element name="PPURPOSE"&gt;

								    &lt;complexType&gt;

								      &lt;sequence&gt;

								        &lt;choice maxOccurs="unbounded"&gt;

								          &lt;element name="account" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="arts" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="browsing" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="charity" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="communicate" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="custom" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="delivery" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="downloads" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="education" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="feedback" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="finmgt" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="gambling" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="gaming" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="government" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="health" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="login" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="marketing" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="news" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="payment" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="sales" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="search" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="state" type="p3p11:ppurpose-value"/&gt;

								          &lt;element name="surveys" type="p3p11:ppurpose-value"/&gt;

								        &lt;/choice&gt;

								      &lt;/sequence&gt;

								    &lt;/complexType&gt;

								  &lt;/element&gt;


								  &lt;complexType name="ppurpose-value"/&gt;


								  &lt;!-- ************ JURISDICTION ************ --&gt;

								  &lt;element name="JURISDICTION"&gt;

								    &lt;complexType&gt;

								      &lt;simpleContent&gt;

								        &lt;extension base="string"&gt;

								          &lt;attribute name="service" type="anyURI" use="required"/&gt;

								          &lt;attribute name="short-description" type="string" use="optional"/&gt;

								        &lt;/extension&gt;

								      &lt;/simpleContent&gt;

								    &lt;/complexType&gt;

								  &lt;/element&gt;


								  &lt;!-- ********* P3P 1.1 Data-Group Element below Entity --&gt;

								  &lt;!-- &lt;element name="datatype" type="p3p11:datatypeComplexType" /&gt; --&gt;

								  &lt;complexType name="datatypeComplexType"&gt;

								    &lt;all&gt;

								      &lt;element minOccurs="0" name="dynamic" type="p3p11bds:dynamicComplexType" /&gt;

								      &lt;element minOccurs="0" name="user" type="p3p11bds:userComplexType" /&gt;

								      &lt;element minOccurs="0" name="thirdparty" type="p3p11bds:thirdpartyComplexType" /&gt;

								      &lt;element minOccurs="0" name="business" type="p3p11bds:businessComplexType" /&gt;

								    &lt;/all&gt;

								    &lt;attribute type="p3p:yes_no" default="no" use="optional" name="optional" /&gt;

								  &lt;/complexType&gt;


								  &lt;element name='DATA-GROUP'&gt;

								    &lt;complexType&gt;

								      &lt;sequence&gt;

								        &lt;any processContents="lax"/&gt;

								        &lt;!--  ******* Definition of 1.1 datatype ************** --&gt;

								        &lt;element minOccurs="0" name="datatype" type="p3p11:datatypeComplexType" /&gt;

								      &lt;/sequence&gt;

								    &lt;/complexType&gt;

								   &lt;/element&gt;

								<!-- ********* Definition of the OUR-HOST element below the Extension of POLICY-REF ********* -->

								  &lt;element name="our-host" type="our-host-type" /&gt;


								  &lt;complexType name="our-host-type"&gt;

								    &lt;attribute name='name' type='string' use='optional'/&gt;

								    &lt;attribute name="authority" type="string" use="optional" /&gt;

								  &lt;/complexType&gt;

								&lt;/schema&gt;

								  </pre>


								<div id="Appendix_Notation">

								<h2>Appendix 6: ABNF Notation (Normative)</h2>


								<p>The formal grammar of P3P is given in this specification using a slight

								modification of [<a href="#ABNF">ABNF</a>]. The following is a simple

								description of the ABNF.</p>

								<dl>

								  <dt><code><strong>name = (elements)</strong></code></dt>

								    <dd>where &lt;name&gt; is the name of the rule, &lt;elements&gt; is one

								      or more rule names or terminals combined through the operands provided

								      below. Rule names are case-insensitive.</dd>

								  <dt><code>(</code><code><strong>element1 element2)</strong></code></dt>

								    <dd>elements enclosed in parentheses are treated as a single element,

								      whose contents are strictly ordered.</dd>

								  <dt><code><strong>&lt;a&gt;*&lt;b&gt;element</strong></code></dt>

								    <dd>at least &lt;a&gt; and at most &lt;b&gt; occurrences of the

								    element.</dd>

								    <dd><em>(1*4&lt;element&gt; means one to four elements.)</em></dd>

								  <dt><code><strong>&lt;a&gt;element</strong></code></dt>

								    <dd>exactly &lt;a&gt; occurrences of the element.</dd>

								    <dd><em>(4&lt;element&gt; means exactly 4 elements.)</em></dd>

								  <dt><code><strong>&lt;a&gt;*element</strong></code></dt>

								    <dd>&lt;a&gt; or more elements</dd>

								    <dd><em>(4*&lt;element&gt; means 4 or more elements.)</em></dd>

								  <dt><code><strong>*&lt;b&gt;element</strong></code></dt>

								    <dd>0 to &lt;b&gt; elements.</dd>

								    <dd><em>(*5&lt;element&gt; means 0 to 5 elements.)</em></dd>

								  <dt><code><strong>*element</strong></code></dt>

								    <dd>0 or more elements.</dd>

								    <dd><em>(*&lt;element&gt; means 0 to infinite elements.)</em></dd>

								  <dt><code><strong>[element]</strong></code></dt>

								    <dd>optional element, equivalent to *1(element).</dd>

								    <dd><em>([element] means 0 or 1 element.)</em></dd>

								  <dt><code><strong>"string"</strong></code> or

								  <code><strong>'string'</strong></code></dt>

								    <dd>matches the literal string given inside double quotes.</dd>

								</dl>


								<p>Other notations used in the productions are:</p>

								<dl>

								  <dt><strong>;</strong> or <strong><code>/* ... */</code></strong></dt>

								    <dd>comment.</dd>

								</dl>

								</div>


								<div id="guiding_principles">

								<h2>Appendix 7: P3P Guiding Principles (Non-normative)</h2>


								<p>This appendix describes the intent of P3P development and recommends

								guidelines regarding the responsible use of P3P technology. An earlier

								version was published in the W3C Note "<a

								href="http://www.w3.org/TR/NOTE-P3P10-principles">P3P Guiding Principles</a>"

								(<a

								href="http://www.w3.org/TR/NOTE-P3P10-principles">http://www.w3.org/TR/NOTE-P3P10-principles</a>).</p>


								<p>The Platform for Privacy Preferences Project (P3P) has been designed to be

								flexible and support a diverse set of user preferences, public policies,

								service provider polices, and applications. This flexibility will provide

								opportunities for using P3P in a wide variety of innovative ways that its

								designers had not imagined. The P3P Guiding Principles were created in order

								to: express the intentions of the members of the P3P Working Groups when

								designing this technology and suggest how P3P can be used most effectively in

								order to maximize privacy and user confidence and trust on the Web. In

								keeping with our goal of flexibility, this document does not place

								requirements upon any party. Rather, it makes recommendations about 1) what

								<em>should</em> be done to be consistent with the intentions of the P3P

								designers and 2) how to maximize user confidence in P3P implementations and

								Web services. P3P was intended to help protect privacy on the Web. We

								encourage the organizations, individuals, policy-makers and companies who use

								P3P to embrace the guiding principles in order to reach this goal.</p>


								<h3 id="principles_privacy">Information Privacy</h3>


								<p>P3P has been designed to promote privacy and trust on the Web by enabling

								service providers to disclose their information practices, and enabling

								individuals to make informed decisions about the collection and use of their

								personal information. P3P user agents work on behalf of individuals to reach

								agreements with service providers about the collection and use of personal

								information. Trust is built upon the mutual understanding that each party

								will respect the agreement reached.</p>


								<p>Service providers should preserve trust and protect privacy by applying

								relevant laws and principles of data protection and privacy to their

								information practices. The following is a list of privacy principles and

								guidelines that helped inform the development of P3P and may be useful to

								those who use P3P:</p>

								<ul>

								  <li><a href="http://www.the-cma.org/consumer/ethics_2.cfm">CMA Code of

								    Ethics &amp; Standards of Practice: Protection of Personal

								  Privacy</a></li>

								  <li><a

								    href="http://www.privacy.org/pi/intl_orgs/coe/dp_convention_108.txt">1981

								    Council of Europe Convention For the Protection of Individuals with

								    Regard to Automatic Processing of Personal Data</a></li>

								  <li><a href="http://www.csa.ca/">CSA</a>--Q830-96 Model Code for the

								    Protection of Personal Information</li>

								  <li><a href="http://europa.eu.int/eur-lex/lex/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML">Directive

								    95/46/EC of the European Parliament and of the Council of 24 October 1995

								    on the protection of individuals with regard to the processing of

								    personal data and on the free movement of such data</a></li>

								  <li><a href="http://www.the-dma.org/guidelines/onlineguidelines.shtml">The

								    DMA's Marketing Online Privacy Principles and Guidance</a> and <a

								    href="http://www.the-dma.org/guidelines/ethicalbusinesscommittee.shtml">The

								    DMA Guidelines for Ethical Business Practice</a></li>

								  <li><a

								    href="http://www.oecd.org/document/18/0,2340,en_2649_34255_1815186_1_1_1_1,00.html">OECD

								    Guidelines on the Protection of Privacy and Transborder Flows of Personal

								    Data</a></li>

								  <li><a

								    href="http://www.privacyalliance.org/resources/ppguidelines.shtml">Online

								    Privacy Alliance Guidelines for Online Privacy Policies</a></li>

								</ul>


								<p>In addition, service providers and P3P implementers should recognize and

								address the special concerns surrounding children's privacy.</p>


								<h3 id="principles_evaluation">Timing of Policy Evaluation and Notices to

								Users</h3>


								<p>Service providers should provide timely and effective notices of their

								information practices, and user agents should provide effective tools for

								users to access these notices and make decisions based on them.</p>


								<p>Service providers should:</p>

								<ul>

								  <li>Communicate explicitly about data collection and use, expressing the

								    purpose for which personal information is collected and the extent to

								    which it may be shared.</li>

								  <li>Use P3P privacy policies to communicate about all information they

								    propose to collect through a Web interaction.</li>

								  <li>Prominently post clear, human-readable privacy policies.</li>

								</ul>


								<p>User agents should:</p>

								<ul>

								  <li>Provide mechanisms for displaying a service's information practices to

								    users.</li>

								  <li>Provide users an option that allows them to easily preview and agree to

								    or reject each transfer of personal information that the user agent

								    facilitates.</li>

								  <li>Not be configured by default to transfer personal information to a

								    service provider without the user's consent.</li>

								  <li>Inform users about the privacy-related options offered by the user

								    agent.</li>

								</ul>


								<p>Certain jurisdictions view the storage of cookies on a user's hard drive

								as an act of data processing. In such jurisdictions (e.g. the EU), policies

								should always be evaluated before a cookie is set and cookies should not be

								stored unless the cookie's policy is found to comply with the user's

								preferences.</p>


								<h3 id="principles_choice">Choice and Control</h3>


								<p>Users should be given the ability to make meaningful choices about the

								collection, use, and disclosure of personal information. Users should retain

								control over their personal information and decide the conditions under which

								they will share it.</p>


								<p>Service providers should:</p>

								<ul>

								  <li>Limit their requests to information necessary for fulfilling the level

								    of service desired by the user. This will reduce user frustration,

								    increase trust, and enable relationships with many users, including those

								    who may wish to have an anonymous, pseudonymous, customized, or

								    personalized relationship with the service.</li>

								  <li>Obtain informed consent prior to the collection and use of personal

								    information.</li>

								  <li>Provide information about the ability to review and if appropriate

								    correct personal information.</li>

								</ul>


								<p>User agents should:</p>

								<ul>

								  <li>Include configuration tools that allow users to customize their

								    preferences.</li>

								  <li>Allow users to import and customize P3P preferences from trusted

								    parties.</li>

								  <li>Present configuration options to users in a way that is neutral or

								    biased towards privacy.</li>

								  <li>Be usable without requiring the user to store user personal information

								    as part of the installation or configuration process.</li>

								</ul>


								<h3 id="principles_fairness">Fairness and Integrity</h3>


								<p>Service providers should treat users and their personal information with

								fairness and integrity. This is essential for protecting privacy and

								promoting trust.</p>


								<p>Service providers should:</p>

								<ul>

								  <li>Accurately represent their information practices in a clear and

								    unambiguous manner -- never with the intention of misleading users.</li>

								  <li>Use information only for the stated purpose and retain it only as long

								    as necessary.</li>

								  <li>Ensure that information is accurate, complete, and up-to-date.</li>

								  <li>Disclose accountability and means for recourse.</li>

								  <li>For as long as information is retained, continue to treat information

								    according to the policy in effect when the information was collected,

								    unless users give their informed consent to a new policy.</li>

								</ul>


								<p>User agents should:</p>

								<ul>

								  <li>Act only on behalf of the user according to the preferences specified

								    by the user.</li>

								  <li>Accurately represent the practices of the service provider.</li>

								</ul>


								<h3 id="principles_security">Security</h3>


								<p>While P3P itself does not include security mechanisms, it is intended to

								be used in conjunction with security tools. Users' personal information

								should always be protected with reasonable security safeguards in keeping

								with the sensitivity of the information.</p>


								<p>Service providers should:</p>

								<ul>

								  <li>Provide mechanisms for protecting any personal information they

								  collect.</li>

								  <li>Use appropriate trusted protocols for the secure transmission of

								  data.</li>

								</ul>


								<p>User agents should:</p>

								<ul>

								  <li>Provide mechanisms for protecting the personal information that users

								    store in any data repositories maintained by the agent.</li>

								  <li>Use appropriate trusted protocols for the secure transmission of

								  data.</li>

								  <li>Warn users when an insecure transport mechanism is being used.</li>

								</ul>

								</div>


								<hr />


								<div id="Appendix_Working">

								<h2>Appendix 8: Working Group Contributors

								(Non-normative)</h2>


								<p>The P3P 1.1 Specification was produced by the P3P 1.1 Specification

								Working Group. The following individuals contributed: Lorrie Cranor (Chair),

								Diana Alonso-Blas (European Commission), Eric Brunner-Williams

								(Invited Expert), Brooks Dobbs (Doubleclick Inc), Bill Duserick

								(Fidelity), Jeff Edelen (American Express), Serge Egelman (CMU),

								Jeremy Epling (Microsoft), Giles Hogben (JRC), Jack Humphrey

								(Invited Expert), Patrick C. K. Hung (CSIRO), Marc Langheinrich

								(ETH Zürich), Helena Lind (Ericsson), Matthias Schunter (IBM

								Zürich), Ari Schwartz (CDT), David Stampley (Invited Expert),

								Rigo Wenning (W3C)</p>


								<p>The P3P 1.0 specification was produced by the P3P Specification Working

								Group. The following individuals participated in the P3P Specification

								Working Group, chaired by Lorrie Cranor (AT&amp;T): Mark Ackerman (University

								of California, Irvine), Margareta Björksten (Nokia), Eric Brunner (Engage),

								Joe Coco (Microsoft), Brooks Dobbs (DoubleClick), Rajeev Dujari (Microsoft),

								Matthias Enzmann (GMD), Patrick Feng (RPI), Aaron Goldfeder (Microsoft), Dan

								Jaye (Engage), Marit Hansen (Privacy Commission of Land

								Schleswig-Holstein, Germany), Yuichi Koike (NEC/W3C), Yusuke Koizumi (ENC),

								Daniel LaLiberte (Crystaliz), Marc Langheinrich (NEC/ETH Z&uuml;rich), Daniel Lim

								(PrivacyBank), Ran Lotenberg (IDcide), Massimo Marchiori (W3C/MIT/UNIVE),

								Christine McKenna (Phone.com, Inc.), Mark Nottingham (Akamai), Paul Perry

								(Microsoft), Jules Polonetsky (DoubleClick), Martin Presler-Marshall (IBM),

								Joel Reidenberg (Fordham Law School), Dave Remy (Geotrust), Ari Schwartz

								(CDT), Noboru Shimizu (ENC), Rob Smibert (Jotter Technologies Inc.), Tri Tran

								(AvenueA), Mark Uhrmacher (DoubleClick), Danny Weitzner (W3C), Michael

								Wallent (Microsoft), Rigo Wenning (W3C), Betty Whitaker (NCR), Allen Wyke

								(Engage), Kevin Yen (Netscape), Sam Yen (Citigroup), Alan Zausner (American

								Express).</p>


								<p>The P3P Specification Working Group inherited a large part of the

								specification from previous P3P Working Groups. The Working Group would like

								to acknowledge the contributions of the members of these previous groups

								(affiliations shown are the members' affiliations at the time of their

								participation in each Working Group).</p>


								<p>The P3P Implementation and Deployment Working Group, chaired by Rolf

								Nelson (W3C) and Marc Langheinrich (NEC/ETH Zurich): Mark Ackerman

								(University of California, Irvine), Rob Barrett (IBM), Joe Coco (Microsoft),

								Lorrie Cranor (AT&amp;T), Massimo Marchiori (W3C/MIT), Gabe Montero (IBM),

								Stephen Morse (Netscape), Paul Perry (Microsoft), Ari Schwartz (CDT), Gabriel

								Speyer (Citibank), Betty Whitaker (NCR).</p>


								<p>The P3P Syntax Working Group, chaired by Steve Lucas (Matchlogic): Lorrie

								Cranor (AT&amp;T), Melissa Dunn (Microsoft), Daniel Jaye (Engage

								Technologies), Massimo Marchiori (W3C/MIT), Maclen Marvit (Narrowline), Max

								Metral (Firefly), Paul Perry (Firefly), Martin Presler-Marshall (IBM),

								Drummond Reed (Intermind), Joseph Reagle (W3C).</p>


								<p>The P3P Vocabulary Harmonization Working Group, chaired by Joseph Reagle

								(W3C): Liz Blumenfeld (America Online), Ann Cavoukian (Information and

								Privacy Commission/Ontario), Scott Chalfant (Matchlogic), Lorrie Cranor

								(AT&amp;T), Jim Crowe (Direct Marketing Association), Josef Dietl (W3C),

								David Duncan (Information and Privacy Commission/Ontario), Melissa Dunn

								(Microsoft), Patricica Faley (Direct Marketing Association), Marit Köhntopp

								(Privacy Commissioner of Schleswig-Holstein, Germany), Tony Lam (Hong Kong

								Privacy Commissioner's Office), Tara Lemmey (Narrowline), Jill Lesser

								(America Online), Steve Lucas (Matchlogic), Deirdre Mulligan (Center for

								Democracy and Technology), Nick Platten (Data Protection Consultant, formerly

								of DG XV, European Commission), Ari Schwartz (Center for Democracy and

								Technology), Jonathan Stark (TRUSTe).</p>


								<p>The P3P Protocols and Data Transport Working Group, chaired by Yves Leroux

								(Digital): Lorrie Cranor (AT&amp;T), Philip DesAutels (Matchlogic), Melissa

								Dunn (Microsoft), Peter Heymann (Intermind), Tatsuo Itabashi (Sony), Dan Jaye

								(Engage), Steve Lucas (Matchlogic), Jim Miller (W3C), Michael Myers

								(VeriSign), Paul Perry (FireFly), Martin Presler-Marshall (IBM), Joseph

								Reagle (W3C), Drummond Reed (Intermind), Craig Vodnik (Pencom Web Worlds).</p>


								<p>The P3P Vocabulary Working Group, chaired by Lorrie Cranor (AT&amp;T):

								Mark Ackerman (W3C), Philip DesAutels (W3C), Melissa Dunn (Microsoft), Joseph

								Reagle (W3C), Upendra Shardanand (Firefly).</p>


								<p>The P3P Architecture Working Group, chaired by Martin Presler-Marshall

								(IBM): Mark Ackerman (W3C), Lorrie Cranor (AT&amp;T), Philip DesAutels (W3C),

								Melissa Dunn (Microsoft), Joseph Reagle (W3C).</p>


								<p>Finally, <a href="#guiding_principles">Appendix 7</a> is drawn from the

								W3C Note "<a href="http://www.w3.org/TR/NOTE-P3P10-principles">P3P Guiding

								Principles</a>", whose signatories are: Azer Bestavros (Bowne Internet

								Solutions), Ann Cavoukian (Information and Privacy Commission Ontario

								Canada), Lorrie Faith Cranor (AT&amp;T Labs-Research), Josef Dietl (W3C),

								Daniel Jaye (Engage Technologies), Marit Köhntopp (Land Schleswig-Holstein),

								Tara Lemmey (Narrowline; TrustE), Steven Lucas (MatchLogic), Massimo

								Marchiori (W3C/MIT), Dave Marvit (Fujitsu Labs), Maclen Marvit (Narrowline

								Inc.), Yossi Matias (Tel Aviv University), James S. Miller (MIT), Deirdre

								Mulligan (Center for Democracy and Technology), Joseph Reagle (W3C), Drummond

								Reed (Intermind), Lawrence C. Stewart (Open Market, Inc.).</p>

								</div>


								<hr />


								<h3 id="changelog">Changelog</h3>

								<ul>

								  <li>removed mention of OWL-Schema in 5.8 as this was not

								  published yet and it is unclear at this moment whether

								  it will be done.</li>

								  <li>Fixed all the links to the transforms</li>

								  <li>Removed the remainders of the P3P 1.0 Schema and linked it</li>

								  <li>added the <code>&lt;our-host&gt;</code> element to the

								  XML Schema</li>

								  <li>changed all the namespaces in all example_scenarios</li>

								  <li>changed the XML Schema and fixed it</li>

								  <li>added the new base data schema that allows to for the XML

								  Schema format in the base data schema</li>

								  <li>added the XSLT-transforms for the backwards compatibility</li>

								  <li>merged changes in the Base Data Schema from Giles</li>

								  <li>cleared some wording in 5.1.1</li>

								  <li>Fixed a typo on line 8933</li>

								  <li>Added the new <a href="#Data_Schemas">Base data schema notation</a></li>

								  <li><a href="#backwards">1.1.7 Backwards Compatibility</a> now reflects

								  the changes made to the Base_Data_Schema, notably the switch to XML Schema</li>

								  <li>changed <a href="#goals_and_capabs">1.1.1 Goals and Capabilities of P3P 1.1</a>

								 now reflect all changes made.</li>

								  <li>Added a section about Timing of Policy Evaluation and Notices to Users

								    to the <q>P3P Guiding Principles</q></li>

								  <li>Removed the DTD as it can't express P3P 1.1 anymore (mixing in new

								    elements)</li>

								  <li>added timing of notices to the UA-Guidelines as 6.6 (covering the

								    removed 4.6 and 4.7 as well as behavior on full policies)</li>

								  <li>removed 4.6 and 4.7 as they are already covered by the UA-Guidelines in

								    6.</li>

								  <li>added the compact clustering mechanism as 4.2.10 compact statement and

								    changed example 4.1 and 4.2 accordingly</li>

								  <li>added the section about primary purposes to 3.3.5</li>

								  <li>added a paragraph about security seals to 3.2.7 Disputes</li>

								  <li>added the new mechanism about Domain Relationsships as 2.3.2.9</li>

								  <li>added a paragraph about evaluation time to 2.3.2.7</li>

								  <li>added 1.1.7 Backwards Compatibility</li>

								  <li>Changed 1.3.4. about Linked and linkable Data</li>

								  <li>Removed <q>Linked Data</q> from 1.3.2 as well as the associated

								    Paragraph.</li>

								</ul>

								<ul>

								  <li><a

								    href="http://lists.w3.org/Archives/Public/public-p3p-spec/2004May/0010.html">Included

								    Remarks from Lorrie's email</a></li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=171">Bug

								    171</a>: No name attributes, as already defined in consent choices

								  draft.</li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=172">Bug 172</a>

								    cleard, changed the <a href="#def_identity">Identity Definitions in the

								    P3P Specification</a></li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=174">Bug

								    174</a>: 2.3.2.7 and guidelines altered.</li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=522">Bug

								    522</a>: added <a href="#oho">Domain Relationsships</a>, as defined in

								    the <a

								    href="http://www.w3.org/P3P/2004/03-domain-relationships.html">initial

								    draft</a></li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=523">Bug

								    523</a>: Removed Section 5 (DTD) and added some notes

								    why this happend.</li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=570">Bug

								    570</a>: Adjusted list of Authors</li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=642">Bug

								    642</a>: Removed section 4.7 and corrected section 6.4</li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=645">Bug

								    645</a>: Added the <a href="#compact_statement">Compact Statement</a>

								    Grouping mechanism</li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=652">Bug

								    652</a>: Art. 10 Purpose Specification added as <a href="#ua_notice">6.5

								    Timing of Notices</a></li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=653">Bug

								    653</a>: Added the &lt;jurisdiction&gt; Element to the <a

								    href="#RECPNT">RECIPIENT</a> Element.</li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=654">Bug

								    654</a>: Added allowance for security seals to independend organization

								    in the <a href="#DISPUTES">DISPUTES</a> Element.</li>

								</ul>

								<ul>

								 <li>Changed the <a href="#CHARMODEL">reference to the character

								  model</a> to the new specification that does not contain a

								 special section for URIs anymore.</li>

								  <li>Adjusted <a href="#goals_and_capabs">1.1.1</a> to reflect the changes in

								    P3P 1.1</li>

								  <li>Added some wording to <a href="#UserAgents">1.1.4</a> to reflect user

								    agent guidelines</li>

								  <li>Ajusted <a href="#Future">1.1.6 Future</a> to reflect the changes in

								    P3P 1.1</li>

								  <li>Added wording about identity as defined in <a

								    href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=167">Issue 167 in

								    Bugzilla</a> as <a href="#def_identity">1.3 Identity Definitions in the

								    P3P Specification</a></li>

								  <li>changed <a href="#Terminology">1.4 Terminology to reflect changes in

								    1.3</a></li>

								  <li>added the <a href="#generic_attribute">2.5. The P3P Generic Attribute

								    for XML Applications</a></li>

								  <li>changed number of examples to 2.6</li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=334">Bug 334</a>

								    corrected. The wording of <a href="#POLICY">3.2.2</a> was changed to

								    reflect that this section should indicate that the <a

								    href="#DISPUTES">DISPUTES-GROUP</a> is optional, not mandatory. The BNF

								    is correct as is section 3.2.6 and Appendix 4.</li>

								  <li>Added new wording to <a href="#ENTITY">3.2.4 ENTITY</a> according to

								    findings in <a

								    href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=224">Bug 224</a></li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=212">Bug

								    212</a>: changed wording in <a href="#ACCESS">3.2.5 ACCESS</a> in

								    ident-contact from identifiable to identified</li>

								  <li><a href="#DISPUTES">Section 3.2.6 DISPUTES</a>: fixed wording according

								    to the new <a href="#ua">ua-guidelines in section 6</a>. <br />

								    See Bugs: <a

								    href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=284">284,</a> <a

								    href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=361">361,</a> <a

								    href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=362">362,</a> <a

								    href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=393">393.</a></li>

								  <li>Fixed 3.2.7 REMEDIES according to the ua guidelines in section 6. <br />

								    See Bugs: <a

								    href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=384">384,</a> <a

								    href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=385">385,</a> <a

								    href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=386">386,</a> <a

								    href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=387">387.</a></li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=170">Bug

								    170</a>: Added the changed definition to <a href="#CONSEQUENCE">3.3.2

								    Consequences</a></li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=141">Bug

								    141</a>: In <a href="#DATA">3.3.7 DATA-GROUP</a> added a link to

								  5.5 Basic Data Structures (obsoleted by new data schema)</li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=178">Bug

								    178</a>: Changed definition of demographic category in <a

								    href="#Categories">section 3.4</a> as indicated.</li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=169">Bug

								    169</a>: add the Grouping mechanism: Definitions of groups added as <a

								    href="#StatementGroupDef">3.2.3 <code>STATEMENT-GROUP-DEF</code> element

								    (EXTENSION)</a>. Statement attaching system and naming added as <a

								    href="#statement_group">3.3.2 The <code>STATEMENT-GROUP</code> element

								    (EXTENSION)</a>. This also includes contents a solution to <a

								    href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=171">Bug 171</a></li>

								  <li><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=215">Bug

								    215</a>: Text added as 4.7 Compact Policy

								    Processing by User Agents (and removed later)</li>

								  <li>Section 5.8 was labelled as 5.6: fixed (now removed)</li>

								  <li>Included new <a href="#ua">section 6</a> from user agent guidelines

								    into the specification</li>

								  <li>removed 3.7 and integrated the <code>STATEMENT-GROUP-DEF</code>and

								    <code>STATEMENT-GROUP</code> into their respective sections as 3.2.3 and

								    3.3.2</li>

								<li>Added the following <a href="http://www.w3.org/P3P/2006/05-last-call.html">last call comments</a>:

								<ul>

								<li> S&ouml;ren Preibusch's comments (except changing EXPIRY).</li>

								<li> Rewritten conformance section based on Karl Dubost' conformance requirequments.</li>

								<li> Typos identified by Matthias Schunter.</li>

								<li> Updated header and preamble</li>

								<li> Added fragment requirement to ection 2.5 (pointed out by Mark Wahl)</li>

								</ul>

								</li>

								</ul>

								</body>

								</html>