3 Policy Syntax and SemanticS

P3P policies are encoded in XML. They may also be represented using the RDF data model ([RDF]); however, an RDF representation is not included in this specification. (Such a representation is planned to be made available as a W3C Note prior to submitting P3P as a Proposed Recommendation, together with a suitable RDF encoding of the policy reference file).

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 statements?that apply only to the handling of particular types of data referred to by data references. Section 3.2 describes the POLICY element and policy-level assertions. Section 3.3 describes statements and data references.

3.1 Example Policies

3.1.1 English Language Policies

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.

CatalogExample
4000 Lincoln Ave.
Birmingham, MI 48009 USA
email: catalog@example.com
Telephone 248-EXAMPLE (248-392-6753)

CatalogExample
4000 Lincoln Ave.
Birmingham, MI 48009 USA
email: catalog@example.com
Telephone +1 248-EXAMPLE (+1 248-392-6753)

3.1.2 XML Encoding of Policies

The following pieces of [XML] capture the information as expressed in the above two examples. P3P policies are statements that are properly expressed as well-formed XML. The policy syntax will be explained in more detail in the sections that follow.

[View full width]
<POLICY name="forBrowsers"
    discuri="http://www.catalog.example.com/
       PrivacyPracticeBrowsing.html">
 <ENTITY>
  <DATA-GROUP>
   <DATA ref="#business.name">CatalogExample</DATA>
   <DATA ref="#business.contact-info.postal.street">4000 Lincoln
      Ave.</DATA>
   <DATA ref="#business.contact-info.postal.city">Birmingham</
DATA>
   <DATA ref="#business.contact-info.postal.stateprov">MI</DATA>
   <DATA ref="#business.contact-info.postal.postalcode">48009</
DATA>
   <DATA ref="#business.contact-info.postal.country">USA</DATA>
   <DATA ref="#business.contact-info.online.email">
      catalog@example.com</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.intcode">1
      </DATA>
   <DATA ref="#business.contact-info.telecom.telephone.
loccode">248
      </DATA>
   <DATA ref="#business.contact-info.telecom.telephone.number">
      3926753</DATA>
  </DATA-GROUP>
 </ENTITY>
 <ACCESS><nonident/></ACCESS>
 <DISPUTES-GROUP>
  <DISPUTES resolution-type="independent"
    service="http://www.PrivacySeal.example.org"
    short-description="PrivacySeal.example.org">
   <IMG src="http://www.PrivacySeal.example.org/Logo.gif"
      alt="PrivacySeal's logo"/>
   <REMEDIES><correct/></REMEDIES>
  </DISPUTES>
 </DISPUTES-GROUP>
 <STATEMENT>
  <PURPOSE><admin/><develop/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION> <!-- 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. 
-->
  <DATA-GROUP>
   <DATA ref="#dynamic.clickstream"/>
   <DATA ref="#dynamic.http"/>
  </DATA-GROUP>
 </STATEMENT>
</POLICY>

[View full width]
<POLICY name="forShoppers"
    discuri="http://www.catalog.example.com/Privacy/
       PrivacyPracticeShopping.html"
    opturi="http://catalog.example.com/preferences.html">
 <ENTITY>
  <DATA-GROUP>
   <DATA ref="#business.name">CatalogExample</DATA>
   <DATA ref="#business.contact-info.postal.street">4000 Lincoln
      Ave.</DATA>
   <DATA ref="#business.contact-info.postal.city">Birmingham</
DATA>
   <DATA ref="#business.contact-info.postal.stateprov">MI</DATA>
   <DATA ref="#business.contact-info.postal.postalcode">48009</
DATA>
   <DATA ref="#business.contact-info.postal.country">USA</DATA>
   <DATA ref="#business.contact-info.online.email">
      catalog@example.com</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.intcode">1
      </DATA>
   <DATA ref="#business.contact-info.telecom.telephone.
loccode">248
      </DATA>
   <DATA ref="#business.contact-info.telecom.telephone.number">
      3926753</DATA>
  </DATA-GROUP>
 </ENTITY>
 <ACCESS><contact-and-other/></ACCESS>
 <DISPUTES-GROUP>
  <DISPUTES resolution-type="independent"
    service="http://www.PrivacySeal.example.org"
    short-description="PrivacySeal.example.org">
   <IMG src="http://www.PrivacySeal.example.org/Logo.gif" alt=
      "PrivacySeal's logo"/>
   <REMEDIES><correct/></REMEDIES>
  </DISPUTES>
 </DISPUTES-GROUP>
 <STATEMENT>
  <CONSEQUENCE>
    We record some information in order to serve your request
    and to secure and improve our Web site.
  </CONSEQUENCE>
  <PURPOSE><admin/><develop/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#dynamic.clickstream"/>
   <DATA ref="#dynamic.http.useragent"/>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <CONSEQUENCE>
    We use this information when you make a purchase.
  </CONSEQUENCE>
  <PURPOSE><current/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#user.name"/>
   <DATA ref="#user.home-info.postal"/>
   <DATA ref="#user.home-info.telecom.telephone"/>
   <DATA ref="#user.business-info.postal"/>
   <DATA ref="#user.business-info.telecom.telephone"/>
   <DATA ref="#user.home-info.online.email"/>
   <DATA ref="#user.login.id"/>
   <DATA ref="#user.login.password"/>
   <DATA ref="#dynamic.miscdata">
    <CATEGORIES><purchase/></CATEGORIES>
   </DATA>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <CONSEQUENCE>
    At your request, we will send you carefully selected 
marketing
    solicitations that we think you will be interested in.
  </CONSEQUENCE>
  <PURPOSE>
   <contact required="opt-in"/>
   <individual-decision required="opt-in"/>
   <tailoring required="opt-in"/>
  </PURPOSE>
  <RECIPIENT><ours/><same required="opt-in"/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#user.name" optional="yes"/>
   <DATA ref="#user.home-info.postal" optional="yes"/>
   <DATA ref="#user.home-info.telecom.telephone" optional="yes"/>
   <DATA ref="#user.business-info.postal" optional="yes"/>
   <DATA ref="#user.business-info.telecom.telephone" 
optional="yes"/>
   <DATA ref="#user.home-info.online.email" optional="yes"/>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <CONSEQUENCE>
    We allow you to set a password so that you
    can access your own information.
  </CONSEQUENCE>
  <PURPOSE><individual-decision required="opt-in"/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#dynamic.miscdata">
    <CATEGORIES><uniqueid/></CATEGORIES>
   </DATA>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <CONSEQUENCE>
    At your request, we will tailor our site and
    highlight products related to your interests.
  </CONSEQUENCE>
  <PURPOSE>
    <pseudo-decision required="opt-in"/>
    <tailoring required="opt-in"/>
  </PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#user.bdate.ymd.year" optional="yes"/>
   <DATA ref="#user.gender" optional="yes"/>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <CONSEQUENCE>
    We tailor our site based on your past visits.
  </CONSEQUENCE>
  <PURPOSE><tailoring/><develop/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#dynamic.cookies">
    <CATEGORIES><state/></CATEGORIES>
   </DATA>
   <DATA ref="#dynamic.miscdata">
    <CATEGORIES><preference/></CATEGORIES>
   </DATA>
  </DATA-GROUP>
 </STATEMENT>
</POLICY>

3.2 Policies

This section defines the syntax and semantics of P3P policies.

All policies MUST be encoded using [UTF-8]. P3P servers MUST encode their policies using this encoding. P3P user agents MUST be able to parse this syntax. User agents SHOULD NOT act upon or render policy data containing a syntax error. Furthermore, user agents MUST NOT act upon or render policy data containing a syntax error, unless the user has been informed in a meaningful way that there may be an error, or unless the user's preferences specify that errors may be ignored.

Policies have to be placed inside a POLICIES element.

3.2.1 The POLICIES Element

The POLICIES element is used to gather several 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. Even, the POLICIES element can be placed in the well-known location, inside the META element: in this case, user agents need only fetch a single file, containing both the policy reference file and the policies.

The POLICIES element can optionally contain an EXPIRY element, indicating the expiration of the included policies, and an embedded data schema using the DATASCHEMA element (see Section 5).

Since policies are included in a POLICIES element, they MUST have a name attribute which is unique in the file. This allows policy references (in POLICY-REF elements) to link to that policy.

[View full width]
<POLICIES xmlns="http://www.w3.org/2001/09/P3Pv1">
   <POLICY name="policy1" discuri="http://www.example.com/
disc1"> ....
      </POLICY>
   <POLICY name="policy2" discuri="http://www.example.com/
disc2"> ....
      </POLICY>
   <POLICY name="policy3" discuri="http://www.example.com/
disc3"> ....
       </POLICY>
</POLICIES>

<META xmlns="http://www.w3.org/2001/09/P3Pv1">
<POLICY-REFERENCES>
    <POLICY-REF about="/Shop/policies#policy2">
      <INCLUDE>/Shops/CDs/*</INCLUDE>
    </POLICY-REF>
 </POLICY-REFERENCES>
</META>

`<POLICIES xmlns="http://www.w3.org/2001/09/P3Pv1">`



[expiry]
[dataschema]
*policy
"</POLICIES>"

3.2.2 The POLICY Element

The POLICY element contains a complete P3P policy. Each P3P policy MUST contain exactly one POLICY element. The policy element MUST contain an ENTITY 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 ACCESS element, and optionally STATEMENT elements, a DISPUTES-GROUP element, a P3P data schema, and one or more extensions.

<POLICY>

Includes one or more statements. Each statement includes a set of disclosures as applied to a set of data elements.

• name (mandatory attribute)

  name of the policy, used as a fragment identifier to be able to reference the policy.

• discuri (mandatory attribute)

  URI of the natural language privacy statement

• opturi

  URI of instructions that users can follow to request or decline to have their data used for a particular purpose (opt-in or opt-out). This attribute is mandatory for policies that contain a purpose with required attribute set to opt-in or opt-out.

`<POLICY name=` quotedstring
         ` discuri=` quoted-URI
         [` opturi=` quoted-URI]
          `>`
*extension
[test]
entity
access
[disputes-group]
*statement-block
*extension
`</POLICY>`

3.2.3 The TEST Element

The TEST element is used for testing purposes: the presence of TEST 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.

3.2.4 The ENTITY Element

The ENTITY element gives a precise description of the legal entity making the representation of the privacy practices.

<ENTITY>

Identifies the legal entity making the representation of the privacy practices contained in the policy.

The ENTITY element contains a description of the legal entity consisting of DATA elements referencing (all or some of) the fields of the business dataset: it MUST contain both the legal entity's name as well as contact information such as postal address, telephone number, email address, or other information that individuals may use to contact the entity about their privacy policy. Note that some laws and codes of conduct require entities to include a postal address or other specific information in their contact information.

"<ENTITY>"
*extension
entitydescription
*extension
"</ENTITY>"

"<DATA-GROUP>"
`<DATA ref="#business.name"/>`
 PCDATA "</DATA>"
*(`<DATA ref="#business.` string `"/
>` PCDATA "</DATA>")
"</DATA-GROUP>"

3.2.5 The ACCESS Element

The ACCESS element indicates whether the site provides access to various kinds of information.

<ACCESS>

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 <all/>) 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.

Note that service providers may also wish to provide capabilities to access information collected through means other than the Web at the discuri. 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.

The ACCESS element must contain one of the following elements:

• <nonident/>

  Web site does not collect identified data.

• <all/>

  All Identified Data: access is given to all identified data.

• <contact-and-other/>

  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.

• <ident-contact/>

  Identifiable Contact Information: access is given to identified online and physical contact information (e.g., users can access things such as a postal address).

• <other-ident/>

  Other Identified Data: access is given to certain other identified data (e.g., users can access things such as their online account charges).

• <none/>

  None: no access to identified data is given.

"<ACCESS>"
access_disclosure
*extension
"</ACCESS>"

"<nonident/>"          | ; Identified
                           Data is
                           Not Used
"<all/>"               | ; All
                           Identifiable
                           Information
"<contact-and-other/>" | ; Identified
                           Contact
                           Information
                           and Other
                           Identified
                           Data
"<ident-contact/>"     | ; Identifiable
                           Contact
                           Information
"<other-ident/>"       | ; Other
                           Identified
                           Data
"<none/>"                ; None

3.2.6 The DISPUTES Element

A policy SHOULD contain a DISPUTES-GROUP element, which contains one or more DISPUTES elements. These elements describe dispute resolution procedures that may be followed for disputes about a service's privacy practices. Each DISPUTES element can optionally contain a LONG-DESCRIPTION element, an IMG element, and a REMEDIES element. Service providers with multiple dispute resolution procedures should use a separate DISPUTES element for each. Since different dispute procedures have separate remedy processes, each DISPUTES element would need a separate LONG-DESCRIPTION, IMG tag and REMEDIES element, if they are being used.

<DISPUTES>

Describes dispute resolution procedures that may be followed for disputes about a service's privacy practices, or in case of protocol violation.

• resolution-type (mandatory attribute)

  Takes one of the following four values:

  1. Customer Service [service]

     Individual may complain to the Web site's customer service representative for resolution of disputes regarding the use of collected data. The description MUST include information about how to contact customer service.

  2. Independent Organization [independent]

     Individual may complain to 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.

  3. Court [court]

     Individual may file a legal complaint against the Web site.

  4. Applicable Law [law]

     Disputes arising in connection with the privacy statement will be resolved in accordance with the law referenced in the description.

• service (mandatory attribute)

  URI of the customer service Web page or independent organization, or URI for information about the relevant court or applicable law

• verification

  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.

• short-description

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

The DISPUTES element can contain a LONG-DESCRIPTION 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.

<LONG-DESCRIPTION>

This element contains a (possibly long) human readable description.

<IMG>

An image logo (for example, of the independent organization or relevant court)

• src (mandatory attribute)

  URI of the image logo

• width

  width in pixels of the image logo

• height

  height in pixels of the image logo

• alt (mandatory attribute)

  very short textual alternative for the image logo

"<DISPUTES-GROUP>"
1*dispute
*extension
"</DISPUTES-GROUP>"

"<DISPUTES"
" resolution-type=" '"'("service"|
   "independent"|"court"|"law")'"'
" service=" quoted-URI
[" verification=" quotedstring]
[" short-description=" quotedstring]
">"
*extension
[longdescription]
[image]
[remedies]
*extension
"</DISPUTES>"

<LONG-DESCRIPTION> PCDATA
   </LONG-DESCRIPTION>

"<IMG src=" quoted-URI
[" width=" `"` number `"`]
[" height=" `"` number `"`]
" alt=" quotedstring
"/>"

Note that there can be multiple assurance services, specified via multiple occurrences of DISPUTES within the DISPUTES-GROUP 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.

3.2.7 The REMEDIES Element

Each DISPUTES element SHOULD contain a REMEDIES element that specifies the possible remedies in case a policy breach occurs.

<REMEDIES>

Remedies in case a policy breach occurs.

The REMEDIES element must contain one or more of the following:

• <correct/>

  Errors or wrongful actions arising in connection with the privacy policy will be remedied by the service.

• <money/>

  If the service provider violates its privacy policy it will pay the individual an amount specified in the human readable privacy policy or the amount of damages.

• <law/>

  Remedies for breaches of the policy statement will be determined based on the law referenced in the human readable description.

"<REMEDIES>"
1*remedy
*extension
"</REMEDIES>"

"<correct/>" |
"<money/>"   |
"<law/>"

3.3 Statements

Statements describe data practices that are applied to particular types of data.

3.3.1 The STATEMENT Element

The STATEMENT element is a container that groups together a PURPOSE element, a RECIPIENT element, a RETENTION element, a DATA-GROUP element, and optionally a CONSEQUENCE element and one or more extensions. All of the data referenced by the DATA-GROUP 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.

<STATEMENT>

data practices as applied to data elements.

"<STATEMENT>"
*extension
[consequence]
[non-identifiable]
purpose
recipient
retention
1*data-group
*extension
"</STATEMENT>"

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 ours (ourselves and our agents), but distributes your postal code to unrelated (unrelated third parties), MAY say they distribute your name and postal code to ours and unrelated. 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 NON-IDENTIFIABLE 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.

Also, one must always disclose all options that apply. Consider a site with the sole purpose of collecting information for the purposes of contact (Contacting Visitors for Marketing of Services or Products). Even though this is considered to be for the current (Completion and Support of Current Activity) purpose, the site must state both contact and current purposes. Consider a site which distributes information to ours in order to redistribute it to public: the site must state both ours and public recipients.

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.

3.3.2 The CONSEQUENCE Element

STATEMENT elements may optionally contain a CONSEQUENCE element that can be shown to a human user to provide further explanation about a site's practices.

<CONSEQUENCE>

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

"<CONSEQUENCE>"
PCDATA
"</CONSEQUENCE>"

3.3.3 The NON-IDENTIFIABLE Element

STATEMENT elements may optionally contain a NON-IDENTIFIABLE element, only when the requirements specified below are fulfilled.

<NON-IDENTIFIABLE/>

This is an element that can only be present in the statement, if there is no data or no identifiable data collected. Data is seen as non-identifiable in the sense of the present specification, if there is no reasonable way for the entity or a third party to attach the collected data to the identity of a natural person.

If the <NON-IDENTIFIABLE/> element is present, a human-readable explanation of how this is achieved MUST be included at the discuri.

3.3.4 The PURPOSE Element

Each STATEMENT element MUST contain a PURPOSE 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.

<PURPOSE>

Purposes for data processing relevant to the Web.

The PURPOSE element MUST contain one or more of the following:

• <current/>

  Completion and Support of Activity For Which Data Was Provided: 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.

• <admin/>

  Web Site and System Administration: 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.

• <develop/>

  Research and Development: 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.

• <tailoring/>

  One-time Tailoring: 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 that suggests other items a visitor may wish to purchase based on the items he has already placed in his shopping basket.

• <pseudo-analysis/>

  Pseudonymous Analysis: 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 for purpose of research, analysis and reporting, 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.

• <pseudo-decision/>

  Pseudonymous Decision: 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 to make a decision that directly affects that individual, 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.

• <individual-analysis/>

  Individual Analysis: Information may be used to determine the habits, interests, or other characteristics of individuals and combine it with identified data for the purpose of research, analysis and reporting. For example, an online Web site for a physical store may wish to analyze how online shoppers make offline purchases.

• <individual-decision/>

  Individual Decision: Information may be used to determine the habits, interests, or other characteristics of individuals and combine it with identified data to make a decision that directly affects that individual. 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.

• <contact/>

  Contacting Visitors for Marketing of Services or Products: 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, <current/> 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 <tailoring/>, <pseudo-analysis/> and <pseudo-decision/>, or <individual-analysis/> and <individual-decision/> purposes.

• <historical/>

  Historical Preservation: 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 <DISPUTES> 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.

• <telemarketing/>

  Contacting Visitors for Marketing of Services or Products Via Telephone: 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, <current/> would be used.

• <other-purpose> string </other-purpose>

  Other Uses: Information may be used in other ways not captured by the above definitions. (A human readable explanation should be provided in these instances).

  Each type of purpose (with the exception of current) can have the following optional attribute:

  required

  Whether the purpose is a required practice for the site. The attribute can take the following values:

  • always: The purpose is always required; users cannot opt-in or opt-out of this use of their data. This is the default when no required attribute is present.

  • opt-in: 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 opturi.

  • opt-out: 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 opturi. Services SHOULD also provide these instructions or a pointer to these instructions at the point of data collection.

"<PURPOSE>"
1*purposevalue
*extension
"</PURPOSE>"

"<current/>"
| ; Completion and Support of Activity For
    Which Data Was Provided
"<admin" [required]   "/>"
| ; Web Site and System Administration
"<develop" [required] "/>"
| ; Research and Development
"<tailoring" [required] "/>"
| ; One-time Tailoring
"<pseudo-analysis" [required] "/>"
| ; Pseudonymous Analysis
"<pseudo-decision" [required] "/>"
| ; Pseudonymous Decision
"<individual-analysis" [required] "/>"
| ; Individual Analysis
"<individual-decision" [required] "/>"
| ; Individual Decision
"<contact" [required] "/>"
| ; Contacting Visitors for Marketing of
    Services or Products
"<historical" [required] "/>"
| ; Historical Preservation
"<telemarketing" [required] "/>"
| ; Telephone Marketing
"<other-purpose" [required] ">" PCDATA "
   </other-purpose>"; Other Uses

" required=" `"` ("always"|"opt-in"|
   "opt-out") `"`

Service providers MUST use the above elements to explain the purpose of data collection. Service providers MUST disclose all that apply. 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 "other" purposes MUST provide human readable explanations of those purposes.

3.3.5 The RECIPIENT Element

Each STATEMENT element MUST contain a RECIPIENT 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.

<RECIPIENT>

The legal entity, or domain, beyond the service provider and its agents where data may be distributed.

The RECIPIENT element MUST contain one or more of the following:

• <ours>

  Ourselves and/or our entities acting as our agents or entities for whom we are acting as an agent: 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).

• <delivery>

  Delivery services possibly following different practices: Legal entities performing delivery services 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.

• <same>

  Legal entities following our practices: 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.)

• <other-recipient>

  Legal entities following different practices: 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.).

• <unrelated>

  Unrelated third parties: Legal entities whose data usage practices are not known by the original service provider.

• <public>

  Public fora: Public fora such as bulletin boards, public directories, or commercial CD-ROM directories.

Each of the above tags can optionally contain:

• one or more recipient-description tags, containing a description of the recipient;

• with the exception of <ours>, a required attribute: this attribute is defined exactly as the analogous attribute in the