p3pdeployment 55.7 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="iso-8859-1"?>
<!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 content="text/html; charset=iso-8859-1" http-equiv="Content-Type" />
  <title>The Platform for Privacy Preferences 1.0 Deployment Guide</title>
  <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-NOTE.css" />
</head>

<body>

<div class="head">
<a href="http://www.w3.org/"><img alt="W3C" height="48" src="http://www.w3.org/Icons/w3c_home" width="72" /></a>

<h1>The Platform for Privacy Preferences 1.0 Deployment Guide</h1>

<h2>W3C Note 11 February 2002</h2>
<dl>
  <dt>This Version:</dt>
    <dd><a
        href="http://www.w3.org/TR/2002/NOTE-p3pdeployment-20020211">http://www.w3.org/TR/2002/NOTE-p3pdeployment-20020211</a></dd>
  <dt>Latest Version:</dt>
    <dd><a
      href="http://www.w3.org/TR/p3pdeployment">http://www.w3.org/TR/p3pdeployment</a></dd>
  <dt>Previous Version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2001/NOTE-p3pdeployment-20011130">http://www.w3.org/TR/2001/NOTE-p3pdeployment-20011130</a></dd>
  <dt>Author/Editor:</dt>
    <dd>Martin Presler-Marshall, IBM (<a
      href="mailto:mpresler@us.ibm.com">mpresler@us.ibm.com</a>)</dd>
  <dt>Contributors:</dt>
    <dd>See <a href="#Acknowledgments">Acknowledgments</a></dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">Copyright</a>
©2001, 2002 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
(<a href="http://www.lcs.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
<a href="http://www.inria.fr/"><abbr xml:lang="fr" lang="fr" title="Institut National de Recherche en Informatique et Automatique">INRIA</abbr></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved.
W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</a>,
<a href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</a>,
<a href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document use</a> and <a
href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software licensing</a> rules apply.</p>
<hr title="Separator for header" />
</div>

<h2>Abstract</h2>

<p>This is a guide to help site operators deploy the Platform for Privacy
Preferences (<a href="http://www.w3.org/P3P/">P3P</a>) on their site. It
provides information on the tasks required, and gives guidance on how to best
complete them.</p>

<h2>Status of This Document</h2>

<p><i>This section describes the status of this document at the time of its
publication. Other documents may supersede this document. The latest status
of this document series is maintained at the W3C.</i></p>

<p>This Note is made available for Web site owners and administrators wishing
to implement P3P on their Web site. It is not intended to be a normative
specification. Instead, it captures the authors' thoughts on the process for
deploying P3P1.0 on a Web site. This note has been produced by several
members of the <a href="http://www.w3.org/P3P/">Platform for Privacy
Preferences project (P3P)</a>, and reflects the opinions of some members of
that working group.</p>

<p>The authors welcome comments on this document, but they do not guarantee a
reply or any further action. Please send comments to <a
href="mailto:www-p3p-public-comments@w3.org">www-p3p-public-comments@w3.org</a>;
public archives are available. Comments may also be directed to the editor at
the address given above. This document may be updated or added to based on
implementation experience, but no commitment is made by the W3C, or any of
its members, regarding future updates.</p>

<p>This document is a NOTE made available by the W3C for discussion only.
Publication of this Note by W3C indicates no endorsement by W3C or the W3C
Team, or any W3C Members. A list of current W3C technical reports and
publications, including Working Drafts and Notes, can be found at <a
href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p>

<h2>Table of Contents</h2>
<ol>
  <li><a href="#Introduction">Introduction</a>
    <ol>
      <li><a href="#Purpose">Purpose</a></li>
      <li><a href="#Whats_Involved">What's Involved?</a></li>
    </ol>
  </li>
  <li><a href="#Planning">Planning</a>
    <ol>
      <li><a href="#What_PRF_Covers">What Does a Policy Cover?</a>
        <ol>
          <li><a href="#How_PRFs_Work">How Policy Reference Files
          Work</a></li>
          <li><a href="#Pages_vs_Entities">Pages vs. "Entities"</a></li>
          <li><a href="#Use_of_Forms">Use of Forms</a></li>
        </ol>
      </li>
      <li><a href="#How_Many_Policies">How Many Policies For The
      Site?</a></li>
      <li><a href="#Locating_PRF">Locating The Policy Reference File</a></li>
      <li><a href="#Compact_Policies">Compact Policies</a>
        <ol>
          <li><a href="#Compact_Policies_Good">Description and Advantages of
            Using Compact Policies</a></li>
          <li><a href="#Compact_Policies_Bad">Restrictions of Compact
            Policies</a></li>
        </ol>
      </li>
      <li><a href="#Cookie_Policies">Cookie Policies</a>
        <ol>
          <li><a href="#Describing_Cookies">Describing Cookies in P3P
            Policies</a></li>
          <li><a href="#Policies_Specific_Cookies">Assigning P3P Policies to
            Specific Cookies</a></li>
        </ol>
      </li>
      <li><a href="#Policy_Updates">How Will the Site Handle Policy
        Updates?</a></li>
    </ol>
  </li>
  <li><a href="#Deployment">Deployment</a>
    <ol>
      <li><a href="#Using_HTTP_Headers">Using HTTP Headers</a></li>
      <li><a href="#Using_Link_Tags">Pointing To A Policy Reference File With
        A Link Tag</a></li>
    </ol>
  </li>
  <li><a href="#Conclusion">Conclusion</a></li>
  <li><a href="#Acknowledgments">Acknowledgments</a></li>
  <li><a href="#Appendices">Appendices</a><br />
    <a href="#Appendix_Servers">Appendix A: Instructions For Specific
    Servers</a><br />
    <a href="#Appendix_Apache">Appendix A.1: Apache and derivatives</a><br />
    <a href="#Appendix_CERN">Appendix A.2: CERN HTTPD and derivatives</a><br
    />
    <a href="#Appendix_IIS">Appendix A.3: Microsoft Internet Information
        Server</a><br />
    <a href="#Appendix_iPlanet">Appendix A.4: iPlanet Web Server</a><br/>
    <a href="#Appendix_Jigsaw">Appendix A.5: Jigsaw - The W3C's Web
    Server</a><br />
    <a href="#Appendix_FAQ">Appendix B: Frequently Asked Questions</a><br />
    <a href="#Appendix_Changelog">Appendix C: Change History</a></li>
</ol>
<hr />

<h2><a id="Introduction" name="Introduction">1.0 Introduction</a></h2>

<p>The <a href="http://www.w3.org/P3P/">Platform for Privacy Preferences</a>
(P3P) provides a way for Web sites to publish their privacy policies in a
machine-readable syntax. This guide explains how to deploy P3P on a Web site,
and issues that Webmasters and content owners should consider when deploying
P3P.</p>

<p>This guide is intended for Web site administrators and owners. You can use
it whether you operate your own Web server (or many of them), or are
responsible for some pages on a server someone else operates. You should have
some familiarity with publishing content (HTML files, images, etc.) to a Web
server, but do not need to be an expert at configuring and operating Web
servers. You also don't need to be a P3P expert.</p>

<p>This guide will discuss how to go about deploying P3P. It will discuss:</p>
<ul>
  <li>What's involved in deploying P3P on a Web site.</li>
  <li>How to decide how many P3P policies to use, and how to map those
    policies onto the Web site.</li>
  <li>Different ways to publish your privacy policy, and the pros and cons of
    each.</li>
  <li>Step-by-step instructions for deploying your privacy policy on various
    popular Web servers.</li>
</ul>

<p>The following topics will not be covered in this guide:</p>
<ul>
  <li>Overview of P3P and its operation. The <a
    href="http://www.w3.org/TR/P3P/">P3P specification</a> contains <a
    href="http://www.w3.org/TR/P3P/#Introduction">a section</a> which gives an
    overview of its operation.</li>
  <li>How to craft a privacy policy for a Web site.</li>
  <li>How to code a privacy policy in the P3P syntax. The W3C maintains a <a
    href="http://www.w3.org/P3P/implementations">list of P3P
    implementations</a>, which includes pointers to tools which can help with
    this task.</li>
</ul>

<h3><a id="Purpose" name="Purpose">1.1 Purpose</a></h3>

<p>A Web site will deploy P3P in order to make its privacy practices more
transparent to the site's visitors. P3P defines a way for sites to publish
statements of their privacy practices in a machine-readable format. A
visitor's Web browser can then download those machine-readable privacy
statements, and compare the contents of those statements to the user´s
preferences. This way, the user´s browser can automatically notify the user
when they visit a site whose practices match the user´s preferences - or warn
the user if the practices and preferences don't match.</p>

<h3><a id="Whats_Involved" name="Whats_Involved">1.2 What's Involved?</a></h3>

<p>P3P is designed to be deployed on existing Web server software without any
software changes or upgrades. It is also designed to be deployed without
requiring any new server-side programs (such as CGI programs or servlets).</p>

<p>Deploying P3P on a Web site requires:</p>
<ol>
  <li>Creating one or more policy statements which describes the data the
    site collects and how it will be used. These are XML documents, typically
    less than 10K bytes in size. The policy statements must be published on
    the Web site.</li>
  <li>Creating a policy reference file, which gives the URL for the site´s
    policy statements, and indicates what portions of the site - and the
    site's cookies - are covered by which statements. This is an XML
    document, and is typically a few kilobytes in size. The policy reference
    file then must be published on the Web site.</li>
  <li>The site´s human-readable privacy policy must be published. P3P
    policies contain a link pointing to a human-readable version of the
    privacy policy, so the human-readable policy must be published at the
    same time that the machine-readable XML version is published.</li>
  <li>Telling browsers how to locate the policy reference file. There are
    several mechanisms available to do this. The policy reference file can be
    published in a predefined location on the site, the server can send an
    HTTP response header giving the location of the reference file, or the
    site´s HTML content can be modified to contain links to the reference
    file.</li>
</ol>

<p>This guide will not cover how to create the P3P policy statements. Several
P3P policy editors and generators are available; look at the <a
href="http://www.w3.org/P3P/implementations">P3P implementations page</a> for
more information.</p>

<h3><a id="Planning" name="Planning">2.0 Planning</a></h3>

<p>There are several important items which you should consider before
deploying P3P on your Web site:</p>
<ul>
  <li><b>What does a policy cover?</b> P3P allows applying policies on a very
    broad level, or at a very fine level. It's important to understand how
    P3P applies policies before deciding how many policies to use or how to
    deploy them.</li>
  <li><b>How many policies will you deploy on your site?</b> Using more
    policies allows each policy to be more precise, but this requires more
    policy and site management.</li>
  <li><b>What method will you use to notify clients of the location of the
    policy reference file?</b> P3P policies and policy reference files always
    use the same syntax, but there are three different ways by which Web
    clients can locate the policy reference file for a page:
    <ol>
      <li>Place the a policy reference file in the &ldquo;well-known
        location&rdquo; (at the location <tt>/w3c/p3p.xml</tt> on the
      site).</li>
      <li>Add an extra HTTP header to each response from the Web site giving
        the location of the policy reference file.</li>
      <li>Place a link to the policy reference file in each HTML page on the
        site.</li>
    </ol>
  </li>
  <li><b>Will the site use compact policies in addition to full P3P
    policies?</b> Compact policies are a performance optimization, allowing
    clients to process the policies more quickly, but there is additional
    work for the site to deploy them, as the compact policies must be
    deployed in addition to the full policies.</li>
  <li><b>Will the site use policies for specific cookies?</b> By default, the
    P3P policy covering a resource (a URL) covers all cookies returned with
    that resource. However, it is possible to set different P3P policies on
    different cookies in a response. A site may wish to consider this if it
    uses several cookies with significantly different properties.</li>
  <li><b>How will the site handle policy updates?</b> P3P has ways for the
    Web site to tell clients how long they may cache policy the information.
    This needs to be set correctly on your site to allow for future updates
    to the site's privacy policy.</li>
</ul>

<h4><a id="What_PRF_Covers" name="What_PRF_Covers">2.1 What Does a Policy
Cover?</a></h4>

<p>A P3P policy file contains a description of data collection, use, and
sharing practices. It does not, however, declare what that policy applices
to. P3P uses a seperate file, called a policy reference file, to list the P3P
policies in use at a site (or portion of a site), and what portions of the
site and what cookies are covered by each policy.</p>

<h5><a id="How_PRFs_Work" name="How_PRFs_Work">2.1.1 How Policy Reference
Files Work</a></h5>

<p>P3P policy reference files list the P3P policies which a site is currently
using, and map out what parts of the site each one applies to. This mapping
is done by giving a list of one or more URL patterns that each policy applies
to. Each pattern is a local URL, and is allowed to contain wildcards. Thus a
policy reference file might say that policy <tt>policy-1</tt> applies to just
<tt>/index.html</tt>, or to <tt>/content*</tt>, which means "all URLs on this
host that begin with <tt>/content</tt>". Policy reference files use the
<tt>&lt;INCLUDE&gt;</tt> element to indicate what URLs are covered by a
specific policy.</p>

<p>Policy reference files can also list URLs which explicitly are not covered
by a given policy; this is done with the <tt>&lt;EXCLUDE&gt;</tt> element.
For example, it's possible to say that <tt>policy-1</tt> applies to the
entire site except for <tt>/cgi-bin</tt>; to do this, the following policy
reference file might be used:</p>

<p><strong><a id="Example_1" name="Example_1">Example 1:</a></strong></p>
<pre>&lt;META xmlns="http://www.w3.org/2000/12/P3Pv1"&gt;
   &lt;POLICY-REFERENCES&gt;
      &lt;EXPIRY max-age="172800"&gt;
      &lt;POLICY-REF about="/P3P/Policy1.xml"&gt;
      &lt;INCLUDE&gt;/*&lt;/INCLUDE&gt;
      &lt;EXCLUDE&gt;/cgi-bin*&lt;/EXCLUDE&gt;
      &lt;/POLICY-REF&gt;
   &lt;/POLICY-REFERENCES&gt;
&lt;/META&gt;
</pre>

<p>Note that a single policy reference file need not cover an entire host. In
some cases, a single hostname contains multiple Web sites controlled by
different individuals or organizations. In that case, each portion of the
site would likely have its own policy reference file. However, if a single
organization owns the entire host, then it is a good idea to use a single
policy reference file to cover the entire site whenever possible. Refer to <a
href="#Locating_PRF">section 2.3, Locating the Policy Reference File</a>, for
information on how clients find a site's policy reference file.</p>

<h5><a id="Pages_vs_Entities" name="Pages_vs_Entities">2.1.2 Pages vs.
"Entities"</a></h5>

<p>P3P policy reference files map policies onto URLs. The P3P specification
also uses the term "entity" for describing what a policy applies to. This
term comes from the HTTP 1.1 specification; an "entity" is a single HTTP
request or response - the HTTP headers plus the content body. Generally, a
single HTTP request will ask for a single URL, which is returned as the
"response entity".</p>

<p>Web site visitors, however, are looking at pages, not "HTTP response
entities". A page will typically be composed of many entities. Some examples
follow:</p>
<ul>
  <li>a plain HTML page which uses no graphics, stylesheets or any other
    external content is a single "entity".</li>
  <li>a non-frame HTML page is generally multiple "entities" - one for the
    HTML, and one for each image in the page, plus one for each external
    style sheet the page loads (plus more if it's using Java, or other
    imbedded content)</li>
  <li>a frameset with left and right sections is composed of multiple
    "entities". Consider a two-part frame, where the left HTML page has three
    imbedded images, while the right has a stylesheet and 9 images. The
    result is 16 "entities": 1 frameset HTML, two HTML documents which fill
    the frame sections, one stylesheet, and 12 images.</li>
  <li>anchors within a single HTML document are not seperate entities. This
    document, for example, uses many internal anchors to help readers
    navigate the document. Those internal anchors are not different
  entities.</li>
</ul>

<p>As a practical note, placing many different P3P policies on different
entities on a single page may make rendering the page and informing the user
of the relevant policies difficult for a Web browser. Services should 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>

<h5><a id="Use_of_Forms" name="Use_of_Forms">2.1.3 Use of Forms</a></h5>

<p>When developing a site's policy reference file, one important principle to
keep in mind is that P3P policies declare practices at the point that data
collection occurs. This is particularly important in the case of HTML forms.
Presenting a site visitor with a form asking them for their name and address
does not collect that personal information from the visitor; it is the act of
submitting the form which collects the personal information.</p>

<p>Thus, a site which wishes to use multiple policies could place one policy
on the URL where the form is loaded from, and a seperate one on the URL where
the form is submitted to. The policy for the URL that the form is submitted
to must declare all of the information collected on the form; the policy for
the URL that the form was loaded from need not declare that information.
Practically, this makes it much easier to declare the appropriate policy: a
site may have forms scattered in many places, but the server-side
applications tend to be deployed under just a few URL trees.</p>

<h4><a id="How_Many_Policies" name="How_Many_Policies">2.2 How Many Policies
For The Site?</a></h4>

<p>When deploying P3P, the Web site developer can choose how many policy
statements to use to cover the site. This consideration may seem strange for
someone used to text-based privacy policies, but there is an important
distinction for P3P privacy statements.</p>

<p>A P3P privacy statement is specific about the data or types of data being
collected by the site. Thus the statement will list specific elements of data
which the site collects, such as &ldquo;User´s name&rdquo;, or else specific
types of data which the site collects, such as &ldquo;User´s physical contact
information&rdquo;.</p>

<p>This is important, as Web sites generally collect different amounts of
data in different parts of the site. For example, a web site may collect no
information about the visitor´s name and address at the site homepage, but
may need detailed contact information to complete an order.</p>

<p>It is acceptable, in the P3P protocol, to publish a statement which
overstates the data collection of the site. Thus it´s allowed to have a
single policy which covers all of the data collected anywhere on the site.
However, it is in the site´s interest to have highly specific P3P statements.
In the example above, the site doesn´t need to claim - and probably doesn´t
want to claim - that it needs the visitor´s name and address just to access
the homepage when that information is really only needed to submit an order.
This could well scare away visitors who are simply browsing.</p>

<p>It´s also in the site´s interest to use as few P3P statements as possible
to cover the site. After all, it takes some amount of time to create a P3P
statement, and managing 100 P3P statements on a single site is probably
unrealistic even for the most heroic Webmaster or Webmistress. Thus a site
needs to strike a balance between specificity and number of policies. While
there is no right answer for every site, most sites can be covered by five or
fewer P3P statements, and it is a very rare site which needs more than 10 P3P
statements.</p>

<h4><a id="Locating_PRF" name="Locating_PRF">2.3 Locating The Policy
Reference File</a></h4>

<p>Part of deploying P3P on a Web site is deciding how browsers will find the
site´s policy reference file. The policy reference file lists the P3P
policies used by the site, and tells clients which policies apply to which
parts of the site. P3P defines three different ways for clients to locate
this policy reference file:</p>
<ol>
  <li>Place the a policy reference file in the &ldquo;well-known
    location&rdquo; (at the location <tt>/w3c/p3p.xml</tt> on the site)</li>
  <li>Add an extra HTTP header to each response from the Web site giving the
    location of the policy reference file</li>
  <li>Place a link to the policy reference file in each HTML page on the
  site</li>
</ol>

<p>The preferred deployment choice is to place the policy reference file in
the well-known location. This is the simplest for the site administrator, as
no server configuration changes are required. It is also simple for clients,
as P3P client software knows to look in the well-known location for a policy
reference file before accessing the site. However, it´s only possible to use
the well-known location for the organization which controls the entire Web
site. For example, someone who controls a personal page on a multiuser server
cannot deploy P3P using the well-known location for their personal page, as
they cannot place files in that directory.</p>

<p>Giving the location of the policy reference file in an HTTP header is a
second choice. In some cases, a site owner may be able to add HTTP headers to
their content even if they are not able to place files in the well-known
location directory. This method has advantages over editing HTML, as it will
give quicker turnaround time for clients, and can be used for non-HTML
content.</p>

<p>Inserting a link to the policy reference file is the choice to use when
the site owner does not control the entire Website, and it not able to add
HTTP headers to the response. It can be used on any site where it´s possible
to publish HTML, but has the lowest performance of all three deployment
methods. If the link tags must be inserted by manually editing the HTML, this
method is also tedious and error-prone.</p>

<h4><a id="Compact_Policies" name="Compact_Policies">2.4 Compact
Policies</a></h4>

<h5><a id="Compact_Policies_Good" name="Compact_Policies_Good">2.4.1
Description and Advantages of Using Compact Policies</a></h5>

<p>In addition to the full XML privacy statements defined by P3P, P3P also
defines a compact policy format. The compact policy summarizies the portion
of the P3P policy which applies to the cookies in a response. The summary is
sent in a simple, compact syntax. The compact policy is returned as an HTTP
response header. This means that the client will have the compact policy
available to it when it considers any cookies sent by the site.</p>

<p>The use of compact policies is optional for Web sites; however, their use
is strongly encouraged. Due to their location and simple syntax, compact
policies can be quickly processed by clients, allowing them to make decisions
on processing the cookies in that response. In addition, the Microsoft
Internet Explorer 6.0 client does not implement the <tt>COOKIE-INCLUDE</tt>
mechanism described in the most recent version of the P3P specification. As a
result, Internet Explorer 6.0 will only consider the compact policy when
deciding how to handle a site's cookies.</p>

<p>Note that compact policies are not an alternative to full P3P statements.
If a site uses compact policies, it must also supply full P3P statements. The
compact policies only cover the site's cookies, and they omit important
information which a client might need in order to interact with the site.</p>

<p>If you have used a tool to create your P3P policy, it should also generate
the corresponding compact policy. The text of the compact policy is sent in a
<tt>P3P:</tt> header, as <tt>CP="<i>text of compact policy</i>"</tt>. See <a
href="#Example_5">Example 5</a> for an example of a P3P header which includes
a compact policy.</p>

<h5><a id="Compact_Policies_Bad" name="Compact_Policies_Bad">2.4.2
Restrictions of Compact Policies</a></h5>

<p>While compact policies are encouraged for sites which can use them, there
are some significant restrictions on the use of compact policies which a site
operator should be aware of before deciding to use them:</p>
<ol>
  <li>There is only one mechanism for sites to serve compact policies; they
    are sent as HTTP response headers. Thus, if a site is unable or unwilling
    to add HTTP response headers, compact policies cannot be used.</li>
  <li>The HTML element <tt>META</tt> with the <tt>http-equiv</tt> attribute
    is sometimes used to simulate the effect of adding HTTP headers to HTML
    content. Some servers will scan HTML content, looking for these tags, and
    generate the corresponding HTTP response headers, and this will work well
    with P3P client software.<br />
    However, for servers which are not scanning the HTML in this manner, the
    <tt>http-equiv</tt> mechanism should not be used to send a P3P compact
    policy header, as this information may not be available to a client until
    after it has processed the cookies in the response.</li>
  <li>A single compact policy covers all of the cookies in the response it
    comes with, and applies to those cookies until the cookies expire. This
    means that the site is bound to uphold the policy on those cookies for
    their entire lifetime; this can be a difficult burden for a site if it
    uses cookies with a long lifetime.<br />
    If a site using compact policies needs to change the policy associated
    with a cookie, then the site needs to reset the cookie (with a new
    <tt>Set-Cookie</tt> header from the Web site), and send a new compact
    policy with that <tt>Set-Cookie</tt> header. This will cause clients to
    evaluate the new policy and make a decision on how to handle the cookie
    under its new policy.</li>
  <li>Compact policies have less granularity than do full P3P policies. If
    the full P3P policy contains multiple statements, then all of the data
    categories, uses, and recipients across all of the statements are merged
    when the compact policy is built. This loss of granularity can make a
    site's data use practices appear more privacy-invasive than they actually
    are. When writing the site's P3P policy, you should carefully examine the
    contents of the compact policy, and make sure that your are comfortable
    with the way it represents your site's practices before using the compact
    policy.</li>
</ol>

<h4><a id="Cookie_Policies" name="Cookie_Policies">2.5 Cookie
Policies</a></h4>

<h5><a id="Describing_Cookies" name="Describing_Cookies"></a>2.5.1 Describing
Cookies in P3P Policies</h5>

<p>If a site (or a portion of a site) uses cookies, then its P3P needs to
disclose that cookies are used and explain how they are used. Use of cookies
is disclosed by putting the P3P data element <tt>dynamic.cookies</tt> into a
statement in the policy.</p>

<p>Since cookies can be used to collect or link to many different types of
data, a P3P policy must disclose the data categories associated with the
cookies when they are included in a P3P policy. All data collected by the
cookie, or linked to by the cookie, should be included in the data categories
associated with the cookie policy.</p>

<p><strong><a id="Example_2" name="Example_2">Example 2:</a></strong></p>

<p>Consider the case of a cookie which stores an key to look up a user in a
company's customer information database. In that database, information about
the user's name, mailing address, and e-mail address are kept. The cookie
would be disclosed as follows in the P3P policy:</p>
<pre>&lt;DATA-GROUP&gt;
    &lt;DATA ref="#dynamic.cookies"&gt;
        &lt;CATEGORIES&gt;&lt;demographic/&gt;&lt;online/&gt;&lt;physical/&gt;&lt;/CATEGORIES&gt;
    &lt;/DATA&gt;
&lt;/DATA-GROUP&gt;
</pre>

<h5><a id="Policies_Specific_Cookies" name="Policies_Specific_Cookies">2.5.2
Assigning P3P Policies to Specific Cookies</a></h5>

<p>Typically, a site will cover all the cookies being sent by the site with a
single policy; this is done by putting one <tt>&lt;COOKIE-INCLUDE&gt;</tt>
element in the policy reference file:</p>

<p><strong><a id="Example_3" name="Example_3">Example 3:</a></strong></p>
<pre>&lt;META xmlns="http://www.w3.org/2000/12/P3Pv1"&gt;
&lt;POLICY-REFERENCES&gt;
    &lt;POLICY-REF about="/P3P/Policy1.xml"&gt;
        &lt;COOKIE-INCLUDE
            name="*"
            value="*"
            domain="*"
            path="*"/&gt;
    &lt;/POLICY-REF&gt;
&lt;/POLICY-REFERENCES&gt;
&lt;/META&gt;
</pre>

<p>This is the most straightforward way to cover the cookies generated by a
site with a P3P policy. However, a site may wish to assign policies to
individual cookies sent by a Web site. A site should consider doing this
if:</p>
<ul>
  <li>the site uses multiple cookies, and</li>
  <li>the different cookies have different data collection practices
    associated with them, and</li>
  <li>it is possible for a visitor to use the site if they reject some of the
    site's cookies but accept others.</li>
</ul>

<p>The disadvantage to doing this is that you must write more policies - one
for each cookie that will get its own policy. In addition, the site's policy
reference file must specify the cookies by name, and this information must be
kept synchronized with the actual cookie names.</p>

<p>If your site wishes to do this, then write seperate P3P policies for each
cookie, and then list the cookies seperately (by cookie name, cookie domain,
or cookie path) in the site's policy reference file. Then deploy the policy
reference file and the P3P policies as normal.</p>

<h4><a id="Policy_Updates" name="Policy_Updates">2.6 How Will the Site Handle
Policy Updates?</a></h4>

<p>It is desirable for servers to inform user agents 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 page. 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 restrictive "safe zone" practices for their
requests. If clients have policy reference files which they know are still
valid, then they can make more informed decisions on how to proceed.</p>

<p>The lifetime of a policy reference file tells user agents how long they
can rely on the claims made in the 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
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 P3P policies is to use separate policy
reference files for each policy.</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 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. P3P also
imposes a lower limit on policy reference file lifetime; the lifetime cannot
be less than 1 day.</p>

<p>The lifetime of a policy reference file is given with the
<tt>&lt;EXPIRY&gt;</tt> element in the policy reference file. When generating
the policy reference file, put the lifetime you desire in this element of the
policy reference file. Likewise, the lifetime of a policy is given by the
<tt>&lt;EXPIRY&gt;</tt> element in the policy; this should be inserted in the
policy when it's created.</p>

<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. 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><a id="Deployment" name="Deployment">3.0 Deployment</a></h3>

<p>This section gives specific instructions on what needs to be done to
deploy P3P using each of the three methods described earlier:</p>
<ol>
  <li>Placing the policy reference file in the well-known location. This is
    done by simply publishing the policy reference file on the server.</li>
  <li>Using HTTP headers to allow clients to locate the policy reference
  file.</li>
  <li>Placing <tt>&lt;link&gt;</tt> tags within HTML to give the location of
    the policy reference file.</li>
</ol>

<p>Regardless of the method clients will use to locate the site´s policy
reference file, there are several other tasks to complete:</p>
<ol>
  <li>Place the policy reference file in the location selected. This will
    either be in the well-known location, if using that deployment method, or
    the location given by the P3P header, or the location given in the HTML
    <tt>&lt;link&gt;</tt> tag which points to the policy reference file.</li>
  <li>Place the P3P policy files in the correct directories so that they are
    accessible by clients at the URLs listed in the policy reference file.
    The "correct directories" are the locations given in the policy reference
    file.</li>
  <li>Place the site´s human-readable privacy policy in the correct location.
    The correct location is the location specified in the P3P policy
  files).</li>
  <li>If compact policies are being used, add the HTTP response header
    containing the compact policy. See the <a
    href="#Using_HTTP_Headers">Using HTTP Headers</a> section for additional
    information.</li>
</ol>

<h4><a id="Using_HTTP_Headers" name="Using_HTTP_Headers">3.1 Using HTTP
Headers</a></h4>

<p>A Web site may need to add HTTP headers in its responses to either give
the location of the policy reference file, or to send compact P3P policies.
The name of the header to be sent in the response is defined by P3P; it is
<tt>P3P</tt>.The HTTP header follows the format of several other HTTP headers
in being one or more key-value pairs. The value is always a quoted string.
The following keys are used in P3P:</p>
<ul>
  <li><tt>policyref</tt> - this field gives the location of the policy
    reference file; its value is a URL where the site´s policy reference file
    can be located</li>
  <li><tt>CP</tt> - this field gives a compact policy for the resource (URL)
    that has been requested. Its value is the text of the compact P3P
  policy.</li>
</ul>

<p>If the site needs to use both keys in a single response, then they are
seperated by a comma.</p>

<p><a id="Example_4" name="Example_4"><strong>Example 4</strong></a></p>

<p>A client is requesting the homepage for catalog.example.com, and the site
returns a P3P header which gives the location of the site´s policy reference
file.</p>
<ol>
  <li>Client makes a GET request.
    <pre>GET /index.html HTTP/1.1
Host: catalog.example.com
Accept: */*
Accept-Language: de, en
User-Agent: WonderBrowser/5.2 (RT-11)</pre>
  </li>
  <li>Server returns content and the P3P header pointing to the policy of the
    page.
    <pre>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

...content follows...</pre>
  </li>
</ol>

<p><a id="Example_5" name="Example_5"><strong>Example 5</strong></a></p>

<p>A client is requesting a page on the <tt>catalog.example.com</tt> site,
and the site is returning a compacy P3P policy and the location of the site´s
policy reference file in a single P3P header.</p>
<ol>
  <li>Client makes a GET request:
    <pre>GET /products/prod42-09.html HTTP/1.1
Host: catalog.example.com
Accept: */* Accept-Language: en, ru
User-Agent: WonderBrowser/5.2 (RT-11)</pre>
  </li>
  <li>Server returns content and the P3P header.
    <pre>HTTP/1.1 200 OK
P3P: policyref="http://catalog.example.com/P3P/PolicyReferences.xml",
    CP="NON DSP COR CURa ADMa DEVa CUSa TAIa OUR SAMa IND"
Content-Type: text/html
Content-Length: 8104
Server: CC-Galaxy/1.3.18

...content follows...</pre>
  </li>
</ol>

<p>The appendix contains information on how to add HTTP response-headers for
some popular Web servers.</p>

<h4><a id="Using_Link_Tags" name="Using_Link_Tags">3.2 Pointing To A Policy
Reference File With A Link Tag</a></h4>

<p>Sites can have their HTML content link to the policy reference file with
an HTML <tt>&lt;link&gt;</tt> tag. The <tt>&lt;link&gt;</tt> tag looks like
the following:</p>

<blockquote>
  <pre>&lt;link rel="P3Pv1" href="some-URL"&gt;</pre>
</blockquote>

<p>The actual URL where the site´s policy reference file is located is given
in place of some-URL.</p>
<strong>Example 1</strong>

<p>A client is requesting the homepage for catalog.example.com; the site
returns the following in the HTML page which makes up their homepage:</p>
<pre>&lt;html&gt;
&lt;head&gt;
&lt;link rel="P3Pv1"
    href="http://catalog.example.com/P3P/PolicyReferences.xml"&gt;
...
</pre>

<p>Note that editing every HTML page on a site can be very tedious and
error-prone for sites which contain more than just a few HTML pages. One way
to insert the link tags more easily is to use server-side includes. This is a
feature supported by many Web servers, which allows the Web server to insert
text, or the contents of another file, within a page when it is being served
by the server. Information about server-side includes is available from
a number of sources, including the documentation for <tt>mod_include</tt>
in
the <a href="http://httpd.apache.org/docs/mod/mod_include.html">Apache Web
server manual</a>.</p>

<h3><a id="Conclusion" name="Conclusion">4.0 Conclusion</a></h3>

<p>This guide should help you deploy P3P on your Web site. We hope it has
been helpful and informative.</p>

<h3><a id="Acknowledgments" name="Acknowledgments">5.0
Acknowledgments</a></h3>

<p>We would like to thank the following people for their assistance with this
document:</p>
<ul>
  <li>Lorrie Cranor, AT&amp;T</li>
  <li>Thomas Deml, Microsoft</li>
  <li>Yuichi Koike, NEC Corporation</li>
  <li>Marc Langheinrich, ETH Zentrum</li>
</ul>
<a id="Appendices" name="Appendices"></a>

<h3><a id="Appendix_Servers" name="Appendix_Servers">Appendix A: Instructions
For Specific Servers</a></h3>

<p>When deploying P3P, your site may need to send additional HTTP response
headers. While HTTP headers all have a standard format, and the headers used
by P3P are defined as part of the P3P specification, the technique for adding
HTTP headers to a server´s response varies from server to server.</p>

<p>This section describes how to add HTTP headers to the response for some
popular Web servers. The choice of Web servers here is not meant to imply
that P3P can only be used with these servers; we expect that P3P should be
able to be deployed with any Web server.</p>

<h4><a id="Appendix_Apache" name="Appendix_Apache">A.1 Apache and
derivatives</a></h4>

<p>This section covers the Apache Web Server 1.2.x and 1.3.x, as well as
servers derived from those versions of Apache. This mechanism will work on
all platforms supported by Apache. It will not work on earlier releases
(1.1.x, for example), as the headers module was not introduced until Apache
1.2.</p>

<h5>A.1.1 Basics</h5>

<p>The Apache Web server includes a module called <tt>mod_headers</tt> which
is used to add extra headers to HTTP responses. The configuration directive
which is used to add these headers makes use of the normal Apache scoping
rules, so headers can be added to an individual file, a set of files matching
a regular expression, a set of directories matching a regular expression, or
an entire Web site.</p>

<p>The headers module is used to add any arbitrary headers to an HTTP
response. Thus the Apache Web server does not need to "understand" the P3P
headers.</p>

<h5>A.1.2 Possible Difficulties</h5>

<p>The headers module (<tt>mod_headers</tt>) is an "Extension" module. This
means that the source distribution from Apache does not have this module
included by default. If you have compiled your own server, you may need to
rebuild it to include mod_headers. If you are using a binary distribution of
Apache, then you should check that distribution's documentation to see if
<tt>mod_headers</tt> is built in. The IBM HTTP Server distribution, for example, has
<tt>mod_headers</tt> built in.</p>

<p>If you need to rebuild Apache to include the headers module, read the "<a
href="http://httpd.apache.org/docs/install.html">compiling Apache</a>"
instructions from <a href="http://httpd.apache.org/">the Apache Web site</a>,
and make sure that you update the configuration before compiling to include
<tt>mod_headers</tt>.</p>

<h5>A.1.3 How to do it</h5>
<ol>
  <li>Publish the site's policy reference file and privacy policies. Before
    you put the P3P headers on the content, you should first publish the P3P
    privacy policies. Copy the policy files to the appropriate part of your
    server's content tree.</li>
  <li>Verify that the headers module is being loaded and enabled. If
    <tt>mod_headers</tt> is compiled as a dynamic shared object (certain
    binary distributions do this on UNIX platforms, for example), then
    <tt>httpd.conf</tt> should contain a <tt>LoadModule</tt> directive:
    <pre>LoadModule headers_module <em>path</em>/mod_headers.so</pre>
  </li>
  <li>The configuration file also needs an <tt>AddModule</tt> directive to
    activate the header module:
    <pre>AddModule mod_headers.c
    </pre>
    The <tt>AddModule</tt> directive is required even if mod_headers is
    compiled into the server (i.e., even if it is not dynamically loaded by a
    <tt>LoadModule</tt> directive).</li>
  <li>Decide how the headers will be arranged on the site. If the same
    compact policy is used on the entire site, then it is usually possible to
    send the same <tt>P3P</tt> header for the entire site. On the other hand,
    if different parts of the site require different compact policies, then
    seperate <tt>P3P</tt> headers will be required. For this example, we'll
    assume that we're using one <tt>P3P</tt> header on the entire site.</li>
  <li>Create the appropriate scope sections in the server configuration file
    (httpd.conf). This is explained in "<a
    href="http://httpd.apache.org/docs/sections.html">How Directory,
    Location, and Files sections work</a>". For our example, it will look
    like this:
    <pre>&lt;Location / &gt;
&lt;/Location&gt;</pre>
  </li>
  <li>Add the P3P header. To do this, place a Header directive within the
    section(s) created in the previous step. For our example, the result will
    look as follows:
    <pre>&lt;Location / &gt;
Header append P3P "policyref=\"http://catalog.example.com/P3P/PolicyReferences.xml\""
&lt;/Location&gt;</pre>
  </li>
</ol>

<p>Done! You have now associated the page with its P3P privacy policy.</p>

<h5>A.1.4 Other Notes</h5>

<p>For more information on the Header directive, see <a
href="http://httpd.apache.org/docs/mod/mod_headers.html">the documentation
for mod_headers</a>.</p>

<p>If you need to apply different compact policies to different parts of the
site, Apache supports this.
Create a seperate set of Header directives for each compact policy.
Then use the information at
<a href="http://httpd.apache.org/docs/sections.html">http://httpd.apache.org/docs/sections.html</a>
("How Directory, Location, and Files Sections Work") to apply those directives to the appropriate parts of the site.
</p>

<h4><a id="Appendix_CERN" name="Appendix_CERN">A.2 CERN HTTPD and
derivatives</a></h4>

<p>This section covers CERN httpd version 3.0 and derivatives. "Derivatives"
include Lotus Domino Go Webserver (LDGW) version 4.6, and the IBM Internet
Connection Server (IBM ICS) version 4.2, and possibly other servers. Note
that the metafile mechanism described in this chapter does not function
properly in IBM ICS version 1.0.</p>

<h5>A.2.1 Basics</h5>

<p>CERN httpd has a concept called "metafiles" for associating
meta-information (additional HTTP headers) with Web content. Each content
file - HTML, image, sound file, or whatever - may have one metafile
associated with it. CERN httpd has no support for a single metafile covering
multiple documents, an entire directory, or a directory tree. Note that
metafiles are optional, since Web sites never need to add extra headers to
their content. If a Web site does not contain any metafiles, then the content
served by that site will just have the standard headers created by the Web
server. Metafiles may contain any HTTP headers. The server does not examine
the contents of a metafile to perform any kind of validation. Thus the Web
server does not need to "understand" the P3P headers.</p>

<h5>A.2.2 Possible Difficulties</h5>

<p>Since each metafile only covers a single document, this can be a very
tedious way to link to the site's policy reference file. If you're using a
CERN derivative which supports server-side includes (SSI), then you may wish
to consider that method for publishing your privacy policy.</p>

<p>Metafiles cannot be used for CGI programs; they must generate their own
P3P headers.</p>

<h5>A.2.3 How to do it</h5>
<ol>
  <li>Publish the site's policy reference file and privacy policies. Before
    you put the P3P headers on the content, you should first publish the P3P
    privacy policies. Copy the policy files to the appropriate part of your
    server's content tree.</li>
  <li>Create a metafile. A metafile simply contains header information that
    will be copied verbatim into the response, in the header section (before
    the actual document content). This means that you should just enter the
    headers exactly as they will be seen by the browser, as in the following
    example:
    <pre>File index.html.meta
P3P: policyref="http://catalog.example.com/P3P/PolicyReferences.xml"</pre>
  </li>
  <li>Configure the server to use metafiles. CERN httpd and derivatives use a
    master configuration file called <tt>httpd.conf</tt>. On UNIX platforms,
    this is located in the <tt>/etc</tt> directory. Windows versions
    typically place this file in other directories, such as the Windows
    directory (<tt>\WINNT</tt> on the boot drive). CERN httpd will look for
    and use metafiles by default, but IBM ICS and LDGW have them disabled by
    default.To instruct those servers to make use of metafiles, place the
    following directive anywhere in the server configuration file:<br />
    <tt>UseMetafiles ON</tt></li>
  <li>Put the metafile on the server. Metafiles are associated with content
    by location and filename. The metafiles for a content directory are
    located in a special subdirectory named .web. Metafiles have the name of
    their parent (content) file, with the suffix <tt>.meta</tt> added. So,
    consider the case of serving <tt>/index.html</tt> from the filesystem
    directory <tt>/home/httpd/content/index.html</tt>. To associate a
    metafile with that file, create the directory
    <tt>/home/httpd/content/.web</tt>. Then place the metafile in that
    directory, using the name <tt>index.html.meta</tt>. As stated above, a
    seperate metafile is required for each content file that you want to put
    the P3P headers on.</li>
</ol>

<p>Done! You have now associated the page with its P3P privacy policy.</p>

<h4><a id="Appendix_IIS" name="Appendix_IIS">A.3 Microsoft Internet
Information Server</a></h4>
<!-- IIS section from Thomas Deml. Thanks, Thomas!-->

<p>This section covers Microsoft Internet Information Server (IIS) on a
Microsoft Windows 2000 Server platform.</p>

<h5>A.3.1 Basics</h5>

<p>The P3P header can be added through the IIS snap-in from the Computer
Management console (MMC) on a Microsoft Windows 2000 server. This section
assumes that you have already published your site's policy reference file and
P3P policy files. It also assumes that you have decided how you will arrange
the P3P headers on the site. If the same compact policy is used on the entire
site, then it is usually possible to send the same P3P header for the entire
site. On the other hand, if different parts of the site require different
compact policies, then separate P3P headers are required. For more
information on compact policies, see <a href="#Compact_Policies">Compact
Policies</a> in this document.</p>

<p>For this example, one P3P header is used for the entire site.</p>

<h5>A.3.2 Possible Difficulties</h5>

<p>None known.</p>

<h5>A.3.3 How to do it</h5>
<ol>
  <li>Start the IIS snap-in. To access the IIS snap-in from the Start menu,
    click Programs, Administrative Tools, and then Internet Information
    Services. The Internet Information Services snap-in appears.</li>
  <li>Navigate to the Web site to which you want to apply the privacy
  policy.</li>
  <li>Select the Web site and right-click to open the context menu. Select
    the Properties menu item. The IIS snap-in appears.</li>
  <li>Select the HTTP Headers property page.</li>
  <li>Select Add. The Add/Edit Custom HTTP Header dialog box appears.</li>
  <li>In the Custom Header Name text box, type in <tt>P3P</tt>. In the Custom
    Header Value dialog box, type in the contents of the P3P header.</li>
</ol>

<p>Done! You have now associated the page with its P3P privacy policy.</p>

<h4><a id="Appendix_iPlanet" name="Appendix_iPlanet">A.4 iPlanet Web Server</a></h4>
<p>This section covers the iPlanet Web Server (iWS) version 4.1 and 6.0.</p>

<h5>A.4.1 Basics</h5>
<p>iWS does not provide a way to configure the Web server to send custom
response headers. Instead, this must be done by building and installing
a server plugin which will add the response headers.</p>
<p>iPlanet has provided a document in their knoledge base which documents how
to do this. It is available at <a href="http://knowledgebase.iplanet.com/ikb/kb/articles/7747.html">
    http://knowledgebase.iplanet.com/ikb/kb/articles/7747.html</a>, and it
documents the steps required. See the example under "Method 2" in the
article for specific instructions.</p>

<h5>A.4.2 Possible Difficulties</h5>
<p>This requires compiling and installing a NSAPI plugin. In order to do this,
you will need access to a C compiler for the platform your server runs on.</p>

<h5>A.4.3 How to do it</h5>
<p>See the article above for specific instructions</p>

<!-- Jigsaw section written by Yuichi Koike. Thanks, Yuichi!-->

<h4><a id="Appendix_Jigsaw" name="Appendix_Jigsaw">A.5 Jigsaw - The W3C's Web
Server</a></h4>

<p>This section covers Jigsaw version 2.1 and later. It covers all platforms
supported by Jigsaw.</p>

<h5>A.5.1 Basics</h5>

<p>Jigsaw has an administration/configuration tool with a GUI, called
<b>JigAdmin</b>, which allows the administrator to add any HTTP headers to
any web resources (files, directories, and CGI scripts).</p>

<p>With JigAdmin, you can put an HTTP header to a resource in the following
procedure:</p>
<ol>
  <li>Double-click the mouse on the target resource in the <b><tt>"Docs
    space"</tt></b> pane, then the resource editor will be launched.</li>
  <li>Select an appropriate frame in the <b><tt>Frames</tt></b> pane.
    "Appropriate frame" will be <b><tt>HTTPFrame</tt></b> for normal files
    and directories, and <b><tt>CGIFrame</tt></b> for CGI scripts.</li>
  <li>Select <b><tt>Add frame to selected resourece/frame</tt></b> menu item
    to launch the <b><tt>Add Frame</tt></b> dialog.</li>
  <li>Select <b><tt>org.w3c.jigsaw.filters.HeaderFilter</tt></b> in the
    <b><tt>Class name</tt></b> field in the <b><tt>Add Frame</tt></b> dialog
    and push <b><tt>OK</tt></b> button.</li>
  <li>Now you see the <b><tt>HeaderFilter</tt></b> item in the
    <b><tt>Frames</tt></b> pane in the resource editor.</li>
  <li>Select <b><tt>HeaderFilter</tt></b> item, then you see the
    <b><tt>header-name</tt></b> and <b><tt>header-value</tt></b> fields in
    the <b><tt>Attribute</tt></b> pane.</li>
  <li>Type the header name and value in the fields. For example, if you put
    <tt>P3P</tt> in the <b><tt>header-name</tt></b> field and
    <tt>policyref="http://catalog.example/P3P/ref.xml"</tt> in the
    <b><tt>header-value</tt></b> field, the HTTP header <tt>P3P:
    policyref="http://catalog.example/P3P/ref.xml"</tt> will be added to the
    response of the target resource.</li>
  <li>When you want to put more than one HTTP header, you have to repeat
    steps 3-7.</li>
</ol>

<p>Jigsaw provides other ways to add HTTP headers other than the above
procedure. And, the server does not examine the contents of the header.</p>

<h5>A.5.2 Possible Difficulties</h5>

<p>The configuration with JigAdmin does not cover the servlets; they must
generate their own P3P headers.</p>

<h5>A.5.3 How to do it</h5>
<ol>
  <li>Publish the P3P Privacy Policies and Policy Reference Files.
    <p>Before you put the P3P headers on the content, you should first
    publish the P3P privacy policies and Policy reference files. Copy the
    policy files to the appropriate part of your server's content tree.</p>
  </li>
  <li>Configure using JigAdmin
    <p>Configure using JigAdmin to add the required HTTP headers to the
    target resource (files, directories, and CGI scripts).</p>
  </li>
</ol>

<p>Done! You have now associated the page with its P3P privacy policy.</p>

<p>For more information on the Header directive, see <a
href="http://www.w3.org/Jigsaw/Doc/">the documentation for Jigsaw</a>.</p>

<h3><a id="Appendix_FAQ" name="Appendix_FAQ">Appendix B: Frequently Asked
Questions</a></h3>

<p>This appendix covers common questions people have when deploying P3P.</p>

<p><strong>Questions</strong></p>
<ol>
  <li>My policy editor says I have to give the data categories and purposes
    for the cookies my Web site uses. How do I do this?</li>
</ol>

<p><strong>Answers</strong></p>
<ol>
  <li>See section 2.4.1, <a href="#Describing_Cookies">Describing Cookies in
    P3P Policies</a>.</li>
</ol>

<h3><a id="Appendix_Changelog" name="Appendix_Changelog">Appendix C: Change
History</a></h3>

<p>The initial version of this guide was published May 10, 2001.</p>

<p><i>Changes from the November 30, 2001 version:</i></p>
<ul>
    <li>Added information about how to apply different compact policies
    to different sections of a site in Apache.</li>
    <li>Added <a href="#Appendix_iPlanet">Appendix A.4</a>.</li>
</ul>

<p><i>Changes from the July 24, 2001 version:</i></p>
<ul>
  <li>This change history added.</li>
  <li>The &lt;COOKIE-INCLUDE&gt; syntax in example 3 has been updated to the
    latest syntax.</li>
  <li>Added section 2.4.2, explaining the restrictions on the use of compact
    policies.</li>
  <li>Expanded <a href="#Appendix_IIS">appendix A.3</a>.</li>
  <li>Several typo, numbering, and formatting errors corrected.</li>
</ul>

<p><i>Changes from the May 10, 2001 version:</i></p>
<ul>
  <li>Added section 2.1, providing more information on how policies are
    mapped to a site.</li>
</ul>
</body>
</html>