Data schemas often need to reuse a common group of data elements. P3P data schemas support this through data structures. A data structure is a named, abstract definition of a group of data elements. When a data element is defined, it can be defined as being of an unstructured type, in which case it has no child elements. The data element can also be defined as being of a specific structured type, in which case the data element will be automatically expanded to include as sub-elements all of the elements defined in the data structure. For example, the following structure is used to represent a date and time:
<!-- "date" Data Structure --> <DATA-STRUCT name="date.ymd.year" short-description="Year"/> <DATA-STRUCT name="date.ymd.month" short-description="Month"/> <DATA-STRUCT name="date.ymd.day" short-description="Day"/> <DATA-STRUCT name="date.hms.hour" short-description="Hour"/> <DATA-STRUCT name="date.hms.minute" short-description="Minute"/> <DATA-STRUCT name="date.hms.second" short-description="Second"/>
Now we shall define a "meeting" data element, which has a time and place for the meeting:
<DATA-DEF name="meeting.time" short-description="Meeting time" structref="#date"/> <DATA-DEF name="meeting.place" short-description="Meeting place/>
Since meeting.place
does not reference a structure, it is of
an unstructured type, and has no child elements. The meeting.time
element uses the date
structure. By declaring this, the following
sub-elements are created:
meeting.time.ymd.year meeting.time.ymd.month meeting.time.ymd.day meeting.time.hms.hour meeting.time.hms.minute meeting.time.hms.second
A P3P policy can now declare that it collects the meeting
data
element, which implies that it collects all of the sub-elements of
meeting
, or it can use data elements lower down the hierarchy -
meeting.time
, for example, or
meeting.time.ymd.day
.
DATA-DEF
and
DATA-STRUCT
elements<DATA-DEF>
and
<DATA-STRUCT>
<STATEMENT>
in a P3P policy to describe data covered
by that statement.The following attributes are common to these two elements:
name
(mandatory attribute)user.gender
is different from USER.GENDER
or
User.Gender
. Furthermore, in names of data elements and
structures no number character can appear immediately following a
dot.structref
structref
attribute (and, so, without
an associated structure) are called unstructured.short-description
The DATA-DEF
and DATA-STRUCT
elements can also
contain a long description of the data element or structure, using the
LONG-DESCRIPTION
element.
| [64] | datadef |
= |
"<DATA-DEF name=" quotedstring [` structref="` URI-reference `"`] [" short-description=" quotedstring] ">" [categories] ; the categories of the data element. [longdescription] ; the long description of the data element "</DATA-DEF>" |
| [65] | datastruct |
= |
"<DATA-STRUCT name=" quotedstring [` structref="` URI-reference `"`] [" short-description=" quotedstring] ">" [categories] ; the categories of the Data Structure. [longdescription] ; the long description of the Data Structure "</DATA-STRUCT>" |
Here, URI-reference is defined
as in [URI]. |
Data elements can be structured, much like in common programming languages:
structures are hierarchical (tree-like) descriptions of data elements: this
hierarchical description is performed in the name
attribute using
a dot (".
") character as separator.
P3P provides the P3P base data schema, which has built-in definitions of a number of widely used structures and data elements. All P3P implementations are required to understand the P3P base data schema, so the structures and elements it defines are always available to P3P implementers.
A data schema may include multiple DATA-STRUCT
elements that
together describe a structure. For example, there is no single
DATA-STRUCT
for the uri
data structure (cf. section <IP_ADDRESS>) in the P3P base data schema.
Instead uri.authority
, uri.stem
, and
uri.querystring
are interpreted together to define this
structure.
Categories can be assigned to data structures or data elements. The following rules define how those category definitions are meant to be used:
<DATA-STRUCT>
elements MAY include category
definitions. If a structure definition includes categories, then all uses
of those structures in data definitions and data structures pick up those
categories. If a structure contains no categories, then the categories for
that structure MAY be defined when it is used in another structure or data
element. Otherwise, a data element using this structure is a
variable-category element. Any uses of a variable-category data element in
a policy require that its categories be listed in the policy.<DATA-DEF>
with an unstructured type is a
variable-category data element if no categories are defined in the
<DATA-DEF>
, and has exactly those categories listed in
the <DATA-DEF>
if any categories are included.<DATA-DEF>
or <DATA-STRUCT>
with
a structured type which has no categories defined on that structure
produces a variable-category data element/structure if no categories are
defined in the <DATA-DEF>
or
<DATA-STRUCT>
. If the <DATA-DEF>
or
<DATA-STRUCT>
does have categories listed, then those
categories are applied to that data element, and all of its sub-elements.
In other words, categories are pushed down into sub-elements when defining
a data element to be of a structured type, and the structured type does
not define any categories.<DATA-DEF>
using a structured type which has
categories defined on that structure picks up all the categories listed on
the structure. In addition, categories may be listed in the
<DATA-DEF>
, and these are added to the categories
defined in the structure. These categories are defined only at the level
of that data element, and are not "pushed down" to any sub-elements.<DATA-STRUCT>
that has no categories assigned to
it, and which is using a structured subtype which has categories defined
on the subtype picks up all the categories listed on the subtype.<DATA-STRUCT>
that has categories assigned to it,
and which is using a structured subtype replaces all of the categories
listed on the subtype.foo.a.w
,
foo.a.y
, and foo.b.z
MUST be considered to apply
to data element foo
.<DATA-STRUCT>
cannot be defined with some
variable-category elements and some fixed-category elements. Either all of
the sub-elements of a structure must be in the variable category, or else
all of them must have one or more assigned categories.<DATA-DEF>
with some variable-category elements and
some fixed-category elements MUST NOT be referenced. Note, this means that
the dynamic
structure (cf. section 5.6.4 "Dynamic Data"), existing in the basedata schema,
cannot be referenced in a policy (each�of its sub-elements
dynamic.clickstream
, �dynamic.http
, etc. can be
referenced individually).Consider the case where the company HyperSpeedExample wishes to describe
the features of a vehicle, using a structure called vehicle
. This
structure includes:
vehicle.model
),vehicle.color
),vehicle.built.year
),
andvehicle.price
).If HyperSpeedExample also wants to include in the definition of a vehicle
the location of manufacture, it could add other fields to the structure with
all the relevant data like country, street address, postal code, and so on.
But, each part of a structure can use other structures as well: structures
can be composed. In this case, the P3P base data
schema already provides a structure postal
,
describing all the postal information of a location. So, the final definition
of the structure vehicle is
vehicle.model
(unstructured)vehicle.color
(unstructured)vehicle.price
(unstructured)vehicle.built.year
(unstructured)vehicle.built.where
(with structure postal
from the base data schema)The structure postal
has fields postal.street
,
postal.city
, and so on. Since we have applied the structure
postal
to vehicle.built.where
, it means that we can
access the street and city of a vehicle using the descriptions
vehicle.built.where.street
and
vehicle.built.where.city
respectively. So, by applying a
structure (in this case, postal
) we can build very complex
descriptions in a modular way.
HyperSpeedExample wants to declare that all of the vehicle information will
be in the <preference/>
category. The vehicle.model,
vehicle.color, vehicle.price,
and vehicle.built.year
fields are all unstructured types, so assigning them to the
<preference/>
category accomplishes this for those fields.
Since vehicle is a structure definition, assigning the
<preference/>
category to vehicle.built.where
will override (replace) the categories defined on all of the sub-elements of
vehicle.built.where
, placing all of them in the
<preference/>
category, even though the postal
structure was originally defined as being in other categories.
As said, structures do not contain data elements; they are just abstract
data types. We can use them to rapidly build structured collections of data
elements. Going on with the example, HyperSpeedExample needs this abstract
description of the features of a vehicle because it wants to actually exchange
data about cars and motorcycles. So, it could define two data elements called
car
and motorcycle
, both with the above structure
vehicle
.
This description of the data elements and data structures is encoded in XML using a data schema. In the HyperSpeedExample case, it would be something like:
<DATASCHEMA xmlns="http://www.w3.org/2002/01/P3Pv1"> <DATA-STRUCT name="vehicle.model" short-description="Model"> <CATEGORIES><preference/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="vehicle.color" short-description="Color"> <CATEGORIES><preference/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="vehicle.built.year" short-description="Construction Year"> <CATEGORIES><preference/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="vehicle.built.where" structref="http://www.w3.org/TR/P3P/base#postal" short-description="Construction Place"> <CATEGORIES><preference/></CATEGORIES> </DATA-STRUCT> <DATA-DEF name="car" structref="#vehicle"/> <DATA-DEF name="motorcycle" structref="#vehicle"/> </DATASCHEMA>
Continuing with the example, in order to reference a car model and construction year, HyperSpeedExample or any other service could send the following references inside a P3P policy:
<DATA-GROUP> <!-- First, the "car.model" data element, whose definition is in the data schema at http://www.HyperSpeed.example.com/models-schema --> <DATA ref="http://www.HyperSpeed.example.com/models-schema#car.model"/> <!-- And second, the "car.built.year" data element, whose definition is the data schema at http://www.HyperSpeed.example.com/models-schema --> <DATA ref="http://www.HyperSpeed.example.com/models-schema#car.built.year"/> </DATA-GROUP>
Using the base
attribute, the
above references can be written in an even more compact way:
<DATA-GROUP base="http://www.HyperSpeed.example.com/models-schema"> <DATA ref="#car.model"/> <DATA ref="#car.built.year"/> </DATA-GROUP>
Alternatively, the data schema could be embedded directly into a policy file. In this case, the policy file could look like:
<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1"> <!-- Embedded data schema --> <DATASCHEMA> <DATA-STRUCT name="vehicle.model" short-description="Model"> <CATEGORIES><preference/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="vehicle.color" short-description="Color"> <CATEGORIES><preference/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="vehicle.built.year" short-description="Construction Year""> <CATEGORIES><preference/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="vehicle.built.where" structref="http://www.w3.org/TR/P3P/base#postal" short-description="Construction Place"> <CATEGORIES><preference/></CATEGORIES> </DATA-STRUCT> <DATA-DEF name="car" structref="#vehicle"/> <DATA-DEF name="motorcycle" structref="#vehicle"/> </DATASCHEMA> <!-- end of embedded data schema --> <POLICY name="policy1" discuri="http://www.example.com/disc1"> ... <DATA-GROUP base=""> <DATA ref="#car.model"/> <DATA ref="#car.built.year"/> </DATA-GROUP> ... </POLICY> <POLICY name="policy2" discuri="http://www.example.com/disc2"> .... </POLICY> <POLICY name="policy3" discuri="http://www.example.com/disc3"> .... </POLICY> </POLICIES>
Note that in any case there MUST NOT be more than one data schema per file.
Note that the data element names specified in the base data schema or in extension 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.
An essential requirement on data schemas is the persistence of data schemas: data schemas that can be fetched at a certain URI can only be changed by extending the data schema in a backward-compatible 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 must therefore use a new different URI.
Note that a useful application of the persistence of data schema 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.
The Basic Data Structures are structures used by the P3P base data schema (and possibly, due to their basic nature, they should be reused as much as possible by other different data schemas). All P3P-compliant user agent implementations MUST be aware of the Basic Data Structures. Each table below specifies the elements of a basic data structure, the categories associated, their structures, and the display names shown to users. 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.
The date structure specifies a date. Since date information can be used in different ways, depending on the context, all date information is tagged as being of "variable" category (see Section 5.7.2). For example, schema definitions can explicitly set the corresponding category in the element referencing this data structure, 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 "Purchase Information" category.
date |
Category | Structure | Short display name |
| ymd.year | (variable-category) | unstructured | Year |
| ymd.month | (variable-category) | unstructured | Month |
| ymd.day | (variable-category) | unstructured | Day |
| hms.hour | (variable-category) | unstructured | Hour |
| hms.minute | (variable-category) | unstructured | Minute |
| hms.second | (variable-category) | unstructured | Second |
| fractionsecond | (variable-category) | unstructured | Fraction of Second |
| timezone | (variable-category) | unstructured | Time Zone |
The "time zone" information is for example described in the time standard [ISO8601]. Note that "date.ymd" and "date.hms" can be used to fast reference the year/month/day and hour/minute/second blocks respectively.
The personname structure specifies information about the naming of a person.
personname |
Category | Structure | Short display name |
| prefix | Demographic and Socioeconomic Data | unstructured | Name Prefix |
| given | Physical Contact Information | unstructured | Given Name (First Name) |
| family | Physical Contact Information | unstructured | Family Name (Last Name) |
| middle | Physical Contact Information | unstructured | Middle Name |
| suffix | Demographic and Socioeconomic Data | unstructured | Name Suffix |
| nickname | Demographic and Socioeconomic Data | unstructured | Nickname |
The login structure specify 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 certificate structure should be used.
login |
Category | Structure | Short display name |
| id | Unique Identifiers | unstructured | Login ID |
| password | Unique Identifiers | unstructured | Login Password |
The "id" field 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.
The "password" field 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
The certificate structure is used to specify identity certificates (like, for example, X.509).
certificate |
Category | Structure | Short display name |
| key | Unique Identifiers | unstructured | Certificate Key |
| format | Unique Identifiers | unstructured | Certificate Format |
The "format" field 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.
The telephonenum structure�specifies the characteristics of a telephone number.
telephonenum |
Category | Structure | Short display name |
| intcode | Physical Contact Information | unstructured | International Telephone Code |
| loccode | Physical Contact Information | unstructured | Local Telephone Area Code |
| number | Physical Contact Information | unstructured | Telephone Number |
| ext | Physical Contact Information | unstructured | Telephone Extension |
| comment | Physical Contact Information | unstructured | Telephone Optional Comments |
The contact structure is used to specify contact information. Services can specify precisely which set of data they need, postal, telecommunication, or online address information.
contact |
Category | Structure | Short display name |
| postal | Physical Contact Information, Demographic and Socioeconomic Data | postal | Postal Address Information |
| telecom | Physical Contact Information | telecom | Telecommunications Information |
| online | Online Contact Information | online | Online Address Information |
The postal structure specifies a postal mailing address.
postal |
Category | Structure | Short display name |
| name | Physical Contact Information, Demographic and Socioeconomic Data | personname | Name |
| street | Physical Contact Information | unstructured | Street Address |
| city | Demographic and Socioeconomic Data | unstructured | City |
| stateprov | Demographic and Socioeconomic Data | unstructured | State or Province |
| postalcode | Demographic and Socioeconomic Data | unstructured | Postal Code |
| country | Demographic and Socioeconomic Data | unstructured | Country Name |
| organization | Demographic and Socioeconomic Data | unstructured | Organization Name |
The "country" field represents the information of the name of the country (for example, one among the countries listed in�[ISO3166]).
The telecom structure specifies telecommunication information about a person.
telecom |
Category | Structure | Short display name |
| telephone | Physical Contact Information | telephonenum | Telephone Number |
| fax | Physical Contact Information | telephonenum | Fax Number |
| mobile | Physical Contact Information | telephonenum | Mobile Telephone Number |
| pager | Physical Contact Information | telephonenum | Pager Number |
The online structure specifies online information about a person or legal entity.
online |
Category | Structure | Short display name |
| Online Contact Information | unstructured | Email Address | |
| uri | Online Contact Information | unstructured | Home Page Address |
Two structures used for representing forms of Internet addresses are
provided. The uri
structure covers Universal Resource Identifiers
(URI), which are defined in [URI]. The ipaddr
structure represents IP addresses and Domain Name System (DNS) hostnames.
uri |
Category | Structure | Short display name |
| authority | (variable-category) | unstructured | URI Authority |
| stem | (variable-category) | unstructured | URI Stem |
| querystring | (variable-category) | unstructured | Query-string Portion of URI |
The authority of a URI is defined as the authority
component
in [URI]. �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.
Since URI information can be used in different ways, depending on the
context, all the fields in the uri
structure are tagged as being
of "variable" category. Schema definitions MUST explicitly set the
corresponding category in the element referencing this data structure.
The ipaddr
structure represents the hostname and IP address of
a system.
ipaddr |
Category | Structure | Short display name |
| hostname | Computer Information | unstructured | Complete Host and Domain Name |
| partialhostname | Demographic | unstructured | Partial Hostname |
| fullip | Computer Information | unstructured | Full IP Address |
| partialip | Demographic | unstructured | Partial IP Address |
The hostname
element is used to represent collection of either
the simple hostname of a system, or the full hostname including domain name.
The partialhostname
element represents the information of a
fully-qualified hostname which has had at least 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".
The fullip
element represents the information of a full IP
version 4 or IP version 6 address. The partialip
element
represents an IP version 4 address (only - not a version 6 address) which has
had at least 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).
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.
The loginfo
structure is used to represent information
typically stored in Web-server access logs.
loginfo |
Category | Structure | Short display name |
| uri | Navigation and click-stream data | uri | URI of Requested Resource |
| timestamp | Navigation and click-stream data | date | Request Timestamp |
| clientip | Computer Information, Demographic and Socioeconomic Data | ipaddr | Client's IP Address or Hostname |
| other.httpmethod | Navigation and click-stream data | unstructured | HTTP Request Method |
| other.bytes | Navigation and click-stream data | unstructured | Data Bytes in Response |
| other.statuscode | Navigation and click-stream data | unstructured | Response Status Code |
The resource in the HTTP request is captured by the uri
field.
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. The IP
address of the client system making the request is given by the
clientip
field.
The other
data fields represent other information commonly
stored in Web server access logs. other.httpmethod
is the HTTP
method (such as GET
, POST
, etc) in the client's
request. other.bytes
indicates the number of bytes in the
response-body sent by the server. other.statuscode
is the HTTP
status code on the request, such as 200, 302, or 404 (see section 6.1.1 of [HTTP1.1] for details).
The httpinfo
structure represents information carried by the
HTTP protocol which is not covered by the loginfo
structure.
httpinfo |
Category | Structure | Short display name |
| referer | Navigation and click-stream data | uri | Last URI Requested by the User |
| useragent | Computer Information | unstructured | User Agent Information |
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.
The referer
field 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.
All P3P-compliant user agent implementations MUST be aware of the data
elements in the P3P base data schema. The P3P base data schema includes the
definition of the basic data structures, and four data element sets:
user
, thirdparty
,
business
and
dynamic
. The user
,
thirdparty
and business
sets include elements that
users and/or businesses might provide values for, while the
dynamic
set includes elements that are dynamically generated in
the course of a user's browsing session. User agents may support a variety of
mechanisms that allow users to provide values for the elements in the
user
set and store them in a data repository, including
mechanisms that support multiple personae. Users may choose not to provide
values for these data elements.
The formal XML definition of the P3P base data schema is given in Appendix 3. In the following sections, the base data elements and sets are explained one by one. In the future there will be in all likelihood�demand for the creation of other data sets and elements. Obvious applications include catalogue, payment, and agent/system attribute schemas (an extensive set of system elements is provided for example in http://www.w3.org/TR/NOTE-agent-attributes.)
Each table below specifies a set, the elements within the set, the category associated with the element, its structure, and the display name shown to users. 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. It is recommended that data schema designers do the same.
The user
data set includes general
information about the user.
user |
Category | Structure | Short display name |
| name | Physical Contact Information, Demographic and Socioeconomic Data | personname | User's Name |
| bdate | Demographic and Socioeconomic Data | date | User's Birth Date |
| login | Unique Identifiers | login | User's Login Information |
| cert | Unique Identifiers | certificate | User's Identity Certificate |
| gender | Demographic and Socioeconomic Data | unstructured | User's Gender (Male or Female) |
| employer | Demographic and Socioeconomic Data | unstructured | User's Employer |
| department | Demographic and Socioeconomic Data | unstructured | Department or Division of Organization where User is Employed |
| jobtitle | Demographic and Socioeconomic Data | unstructured | User's Job Title |
| home-info | Physical Contact Information, Online Contact Information, Demographic and Socioeconomic Data | contact | User's Home Contact Information |
| business-info | Physical Contact Information, Online Contact Information, Demographic and Socioeconomic Data | contact | User's Business Contact Information |
Note, that this data set includes elements that are actually sets of data
themselves. These sets are defined in the Data
Structures subsection of this document. The short display name for an
individual element contained within a data set is defined as the concatenation
of the short display names that have been defined for the set and the element,
separated by a separator appropriate for the language/script in question, e.g.
a comma for English. For example, the short display name for
user.home-info.postal.postalcode
could be "User's Home Contact
Information, Postal Address Information, Postal code". User agent
implementations may prefer to develop their own short display names rather
than using the concatenated names when displaying information for the
user.
The thirdparty
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 thirdparty
data set is identical with the
user
data set. See section 5.6.1 User
Data for details.
The business
data set features a subset of
user
data relevant for describing legal entities. In P3P1.0, this
data set is primarily used for declaring the policy entity, although it should
also be applicable to business-to-business interactions.
business |
Category | Structure | Short display name |
| name | Demographic and Socioeconomic Data | unstructured | Organization Name |
| department | Demographic and Socioeconomic Data | unstructured | Department or Division of Organization |
| cert | Unique Identifiers | certificate | Organization Identity Certificate |
| contact-info | Physical Contact Information, Online Contact Information, Demographic and Socioeconomic Data | contact | Contact Information for the Organization |
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 dynamic
data set. 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.
dynamic |
Category | Structure | Short display name |
| clickstream | Navigation and Click-stream Data, Computer Information | loginfo | Click-stream Information |
| http | Navigation and Click-stream Data, Computer Information | httpinfo | HTTP Protocol Information |
| clientevents | Navigation and Click-stream Data | unstructured | User's Interaction with a Resource |
| cookies | (variable-category) | unstructured | Use of HTTP Cookies |
| miscdata | (variable-category) | unstructured | Miscellaneous Non-base Data Schema Information |
| searchtext | Interactive Data | unstructured | Search Terms |
| interactionrecord | Interactive Data | unstructured | Server Stores the Transaction History |
These elements are often implicit in navigation or Web interactions. They should be used with categories to describe the type of information collected through these methods. A brief description of each element follows.
clickstream
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 for
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.http
http
element contains additional information
contained in the HTTP protocol. See the definition of the
httpinfo
structure for descriptions of specific elements.
Sites MAY use the dynamic.http
field as a shorthand to
cover all the elements in the httpinfo
structure if they
wish, or they MAY reference the specific elements in the
httpinfo
structure.clientevents
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 dynamic.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 [DOM2-Events]. 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.cookies
cookies
element should be used whenever HTTP cookies
are set or retrieved by a site. Please note that cookies
is
a variable data element and requires the explicit declaration
of usage categories in a policy.miscdata
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.searchtext
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.interactionrecord
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).Most of the elements in the base data schema are so called "fixed" data elements: they belong to one or at most two category classes. By assigning a category invariably to elements or structures in the base data schema, services and users are able to refer to entire groups of elements simply by referencing the corresponding category. For example, using [APPEL], the privacy preferences exchange language, users can write rules that warn them when they visit a site that collects any data element in a certain category.
When creating data schemas for fixed data elements, schema creators have to explicitly enumerate the categories that these element belong to. For example:
<DATA-STRUCT name="postal.street" structref="#text" short-description="Street Address"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT>
If an element or structure belongs to multiple categories, multiple elements referencing the appropriate categories can be used. For example, the following piece of XML can be used to declare that the data elements in user.name have both category "physical" and "demographic":
<DATA-STRUCT name="user.name" structref="#personname" short-description="User's Name"> <CATEGORIES><physical/><demographic/></CATEGORIES> </DATA-STRUCT>
Please note that the category classes of fixed data elements/structures can not be overridden, for example by writing rules or policies that assign a different category to a known fixed base data element. User agents MUST ignore such categories and instead use the original category (or set of categories) listed in the schema definition. User agents MAY preferably alert the user that a fixed data element is used together with a non-standard category class.
Not all data elements/structures in the base data schema belong to a pre-determined category class. Some can contain information from a range of categories, depending on a particular situation. Such elements/structures are called variable-category data elements/structures (or "variable data element/structure" for short). Although most variable data elements in the P3P base data schema are combined in the dynamic element set, they can appear in any data set, even mixed with fixed-category data elements.
When creating a schema definition for such elements and/or structures, schema authors MUST NOT list an explicit category attribute, otherwise the element/structure becomes fixed. For example when specifying the "Year" Data Structure, which can take various categories depending on the situation (e.g. when used for a credit card expiration date vs. for a birth date), the following schema definition can be used:
<DATA-STRUCT name="date.ymd.year" short-description="Year"/> <!-- Variable Data Structure-->
This allows new schema extensions that reference such variable-category Data Structures to assign a specific category to derived elements, depending on their usage in that extension. For example, an e-commerce schema extension could thus define a credit card expiration date as follows:
<DATA-STRUCT name="Card.ExpDate" structref="#date.ymd" short-description="Card Expiration Date"> <CATEGORIES><purchase/></CATEGORIES> </DATA-STRUCT>
Under these conditions, the variable Data Structure date is assigned a fixed category "Purchase Information" when being used for specifying a credit card expiration date.
Note that while user preferences can list such variable data elements
without any additional category information (effectively expressing
preferences over any usage of this element), services MUST always
explicitly specify the categories that apply to the usage of a variable data
element in their particular policy. This information has to appear as a
category element in the corresponding DATA
element listed in the
policy, for example as in:
<POLICY ... > ... <DATA ref="#dynamic.cookies"><CATEGORIES><uniqueid/></CATEGORIES></DATA> ... </POLICY>
where a service declares that cookies are used to recognize the user at this site (i.e. category Unique Identifiers).
If a service wants to declare a data element that is in multiple categories, it simply declares the corresponding categories (as shown in the above section):
<POLICY ... > ... <DATA ref="#dynamic.cookies"><CATEGORIES><uniqueid/><preference/></CATEGORIES></DATA> ... </POLICY>
With the above declaration a service announces that it uses cookies both to recognize the user at this site and for storing user preference data. Note that for the purpose of P3P there is no difference whether this information is stored in two separate cookies or in a single one.
Finally, note that categories can be inherited as well: Categories inherit downward when a field is structured, but only into fields which have no predefined category. Therefore, we suggest to schema authors that they do their best to insure that all applicable categories are applied to new data elements they create.
P3P offers Web sites a great deal of flexibility in how they describe the types of data they collect.
Any of these three methods may be combined within a single policy.
By using the dynamic.miscdata
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
dynamic.miscdata
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
user.business-info.contact.postal
. 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.
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.
Regardless of whether a site wishes to make general or specific data
disclosures, there are additional advantages to disclosing specific elements
from the dynamic
data set. For example, by
disclosing dynamic.cookies
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
dynamic.http.referer
element in P3P policies and
send the header if it will be used for a purpose the user finds
acceptable.
The data schema corresponding to the P3P base data schema follows for easy reference. The schema is also present as a separate file at the URI http://www.w3.org/TR/P3P/base .
<DATASCHEMA xmlns="http://www.w3.org/2002/01/P3Pv1"> <!-- ********** Base Data Structures ********** --> <!-- "date" Data Structure --> <DATA-STRUCT name="date.ymd.year" short-description="Year"/> <DATA-STRUCT name="date.ymd.month" short-description="Month"/> <DATA-STRUCT name="date.ymd.day" short-description="Day"/> <DATA-STRUCT name="date.hms.hour" short-description="Hour"/> <DATA-STRUCT name="date.hms.minute" short-description="Minutes"/> <DATA-STRUCT name="date.hms.second" short-description="Second"/> <DATA-STRUCT name="date.fractionsecond" short-description="Fraction of Second"/> <DATA-STRUCT name="date.timezone" short-description="Time Zone"/> <!-- "login" Data Structure --> <DATA-STRUCT name="login.id" short-description="Login ID"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="login.password" short-description="Login Password"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-STRUCT> <!-- "personname" Data Structure --> <DATA-STRUCT name="personname.prefix" short-description="Name Prefix"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="personname.given" short-description="Given Name (First Name)"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="personname.middle" short-description="Middle Name"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="personname.family" short-description="Family Name (Last Name)"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="personname.suffix" short-description="Name Suffix"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="personname.nickname" short-description="Nickname"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <!-- "certificate" Data Structure --> <DATA-STRUCT name="certificate.key" short-description="Certificate key"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="certificate.format" short-description="Certificate format"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-STRUCT> <!-- "telephonenum" Data Structure --> <DATA-STRUCT name="telephonenum.intcode" short-description="International Telephone Code"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="telephonenum.loccode" short-description="Local Telephone Area Code"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="telephonenum.number" short-description="Telephone Number"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="telephonenum.ext" short-description="Telephone Extension"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="telephonenum.comment" short-description="Telephone Optional Comments"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <!-- "postal" Data Structure --> <DATA-STRUCT name="postal.name" structref="#personname"> </DATA-STRUCT> <DATA-STRUCT name="postal.street" short-description="Street Address"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="postal.city" short-description="City"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="postal.stateprov" short-description="State or Province"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="postal.postalcode" short-description="Postal Code"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="postal.organization" short-description="Organization Name"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="postal.country" short-description="Country Name"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <!-- "telecom" Data Structure --> <DATA-STRUCT name="telecom.telephone" short-description="Telephone Number" structref="#telephonenum"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="telecom.fax" short-description="Fax Number" structref="#telephonenum"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="telecom.mobile" short-description="Mobile Telephone Number" structref="#telephonenum"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="telecom.pager" short-description="Pager Number" structref="#telephonenum"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <!-- "online" Data Structure --> <DATA-STRUCT name="online.email" short-description="Email Address"> <CATEGORIES><online/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="online.uri" short-description="Home Page Address"> <CATEGORIES><online/></CATEGORIES> </DATA-STRUCT> <!-- "contact" Data Structure --> <DATA-STRUCT name="contact.postal" short-description="Postal Address Information" structref="#postal"> </DATA-STRUCT> <DATA-STRUCT name="contact.telecom" short-description="Telecommunications Information" structref="#telecom"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="contact.online" short-description="Online Address Information" structref="#online"> <CATEGORIES><online/></CATEGORIES> </DATA-STRUCT> <!-- "uri" Data Structure --> <DATA-STRUCT name="uri.authority" short-description="URI Authority"/> <DATA-STRUCT name="uri.stem" short-description="URI Stem"/> <DATA-STRUCT name="uri.querystring" short-description="Query-string Portion of URI"/> <!-- "ipaddr" Data Structure --> <DATA-STRUCT name="ipaddr.hostname" short-description="Complete Host and Domain Name"> <CATEGORIES><computer/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="ipaddr.partialhostname" short-description="Partial Hostname"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="ipaddr.fullip" short-description="Full IP Address"> <CATEGORIES><computer/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="ipaddr.partialip" short-description="Partial IP Address"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <!-- "loginfo" Data Structure --> <DATA-STRUCT name="loginfo.uri" short-description="URI of Requested Resource" structref="#uri"> <CATEGORIES><navigation/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="loginfo.timestamp" short-description="Request Timestamp" structref="#date"> <CATEGORIES><navigation/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="loginfo.clientip" short-description="Client's IP Address or Hostname" structref="#ipaddr"> </DATA-STRUCT> <DATA-STRUCT name="loginfo.other.httpmethod" short-description="HTTP Request Method"> <CATEGORIES><navigation/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="loginfo.other.bytes" short-description="Data Bytes in Response"> <CATEGORIES><navigation/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="loginfo.other.statuscode" short-description="Response Status Code"> <CATEGORIES><navigation/></CATEGORIES> </DATA-STRUCT> <!-- "httpinfo" Data Structure --> <DATA-STRUCT name="httpinfo.referer" short-description="Last URI Requested by the User" structref="#uri"> <CATEGORIES><navigation/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="httpinfo.useragent" short-description="User Agent Information"> <CATEGORIES><computer/></CATEGORIES> </DATA-STRUCT> <!-- ********** Base Data Schemas ********** --> <!-- "dynamic" Data Schema --> <DATA-DEF name="dynamic.clickstream" short-description="Click-stream Information" structref="#loginfo"> <CATEGORIES><navigation/><computer/><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="dynamic.http" short-description="HTTP Protocol Information" structref="#httpinfo"> <CATEGORIES><navigation/><computer/></CATEGORIES> </DATA-DEF> <DATA-DEF name="dynamic.clientevents" short-description="User's Interaction with a Resource"> <CATEGORIES><navigation/></CATEGORIES> </DATA-DEF> <DATA-DEF name="dynamic.cookies" short-description="Use of HTTP Cookies"/> <DATA-DEF name="dynamic.searchtext" short-description="Search Terms"> <CATEGORIES><interactive/></CATEGORIES> </DATA-DEF> <DATA-DEF name="dynamic.interactionrecord" short-description="Server Stores the Transaction History"> <CATEGORIES><interactive/></CATEGORIES> </DATA-DEF> <DATA-DEF name="dynamic.miscdata" short-description="Miscellaneous Non-base Data Schema = information"/> <!-- "user" Data Schema --> <DATA-DEF name="user.name" short-description="User's Name" structref="#personname"> <CATEGORIES><physical/><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.bdate" short-description="User's Birth Date" structref="#date"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.login" short-description="User's Login Information" structref="#login"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.cert" short-description="User's Identity Certificate" structref="#certificate"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.gender" short-description="User's Gender"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.jobtitle" short-description="User's Job Title"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.home-info" short-description="User's Home Contact Information" structref="#contact"> <CATEGORIES><physical/><online/><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.business-info" short-description="User's Business Contact Information" structref="#contact"> <CATEGORIES><physical/><online/><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.employer" short-description="Name of User's Employer"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.department" short-description="Department or Division of Organization where User is Employed"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <!-- "thirdparty" Data Schema --> <DATA-DEF name="thirdparty.name" short-description="Third Party's Name" structref="#personname"> <CATEGORIES><physical/><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.bdate" short-description="Third Party's Birth Date" structref="#date"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.login" short-description="Third Party's Login Information" structref="#login"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.cert" short-description="Third Party's Identity Certificate" structref="#certificate"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.gender" short-description="Third Party's Gender"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.jobtitle" short-description="Third Party's Job Title"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.home-info" short-description="Third Party's Home Contact Information" structref="#contact"> <CATEGORIES><physical/><online/><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.business-info" short-description="Third Party's Business Contact Information" structref="#contact"> <CATEGORIES><physical/><online/><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.employer" short-description="Name of Third Party's Employer"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.department" short-description="Department or Division of Organization where Third Party is Employed"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <!-- "business" Data Schema --> <DATA-DEF name="business.name" short-description="Organization Name"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="business.department" short-description="Department or Division of Organization"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="business.cert" short-description="Organization Identity certificate" structref="#certificate"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-DEF> <DATA-DEF name="business.contact-info" short-description="Contact Information for the Organization" structref="#contact"> <CATEGORIES><physical/><online/><demographic/></CATEGORIES> </DATA-DEF> </DATASCHEMA>
This appendix contains the XML schema for P3P policy reference files, for P3P policy documents, and for P3P data schema documents. P3P 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 [XML-Schema1][XML-Schema2]. The schema is also present as a separate file at the URI http://www.w3.org/2002/01/P3Pv1.xsd .
<?xml version='1.0' encoding='UTF-8'?> <schema xmlns='http://www.w3.org/2001/XMLSchema' xmlns:p3p='http://www.w3.org/2002/01/P3Pv1' targetNamespace='http://www.w3.org/2002/01/P3Pv1' elementFormDefault='qualified'> <!-- enabling xml:lang attribute --> <import namespace='http://www.w3.org/XML/1998/namespace' schemaLocation='http://www.w3.org/2001/xml.xsd' /> <!-- Basic P3P Data Type --> <simpleType name='yes_no'> <restriction base='string'> <enumeration value='yes'/> <enumeration value='no'/> </restriction> </simpleType> <!-- *********** Policy Reference *********** --> <!-- ************** META ************** --> <element name='META'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <element ref='p3p:POLICY-REFERENCES'/> <element ref='p3p:POLICIES' minOccurs='0'/> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> <attribute ref='xml:lang' use='optional'/> </complexType> </element> <!--  ************* HINT ************* --> <element name='HINT'> <complexType> <attribute name='scope' type='string' use='required'/> <attribute name='path' type='string' use='required'/> </complexType> </element> <!-- ************ POLICIES ************ --> <element name='POLICIES'> <complexType> <sequence> <element ref='p3p:EXPIRY' minOccurs='0'/> <element ref='p3p:DATASCHEMA' minOccurs='0'/> <element ref='p3p:POLICY' minOccurs='0' maxOccurs='unbounded'/> </sequence> <attribute ref='xml:lang' use='optional'/> </complexType> </element> <!-- ************* EXPIRY ************* --> <element name='EXPIRY'> <complexType> <attribute name='max-age' type='nonNegativeInteger' use='optional'/> <attribute name='date' type='string' use='optional'/> </complexType> </element> <!-- **************** Policy **************** --> <!-- ************* POLICY ************* --> <element name='POLICY'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <element ref='p3p:TEST' minOccurs='0'/> <element ref='p3p:ENTITY'/> <element ref='p3p:ACCESS'/> <element ref='p3p:DISPUTES-GROUP' minOccurs='0'/> <element ref='p3p:STATEMENT' maxOccurs='unbounded'/> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> <attribute name='discuri' type='anyURI' use='required'/> <attribute name='opturi' type='anyURI' use='optional'/> <attribute name='name' type='ID' use='required'/> <attribute ref='xml:lang' use='optional'/> </complexType> </element> <!-- ************* TEST ************* --> <element name='TEST'> <complexType/> </element> <!-- ************* ENTITY ************* --> <element name='ENTITY'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <element name='DATA-GROUP'> <complexType> <sequence> <element name='DATA' type='p3p:data-in-entity' maxOccurs='unbounded'/> </sequence> </complexType> </element> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <complexType name='data-in-entity' mixed='true'> <attribute name='ref' type='anyURI' use='required'/> </complexType> <!--   ******** LONG-DESCRIPTION ******** --> <element name='LONG-DESCRIPTION'> <simpleType> <restriction base='string'/> </simpleType> </element> <!-- ************** IMG *************** --> <element name='IMG'> <complexType> <attribute name='src' type='anyURI' use='required'/> <attribute name='width' type='nonNegativeInteger' use='optional'/> <attribute name='height' type='nonNegativeInteger' use='optional'/> <attribute name='alt' type='string' use='required'/> </complexType> </element> <!-- ************ REMEDIES ************ --> <element name='REMEDIES'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <choice maxOccurs='unbounded'> <element name='correct' type='p3p:remedies-value'/> <element name='money' type='p3p:remedies-value'/> <element name='law' type='p3p:remedies-value'/> </choice> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <complexType name='remedies-value'/> <!-- *********** STATEMENT ************ --> <element name='STATEMENT'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <element name='CONSEQUENCE' minOccurs='0' type='string'/> <choice> <sequence> <element ref='p3p:PURPOSE'/> <element ref='p3p:RECIPIENT'/> <element ref='p3p:RETENTION'/> <element name='DATA-GROUP' type='p3p:data-group-type' maxOccurs='unbounded'/> </sequence> <sequence> <element name='NON-IDENTIFIABLE'/> <element ref='p3p:PURPOSE' minOccurs='0'/> <element ref='p3p:RECIPIENT' minOccurs='0'/> <element ref='p3p:RETENTION' minOccurs='0'/> <element name='DATA-GROUP' type='p3p:data-group-type' minOccurs='0' maxOccurs='unbounded'/> </sequence> </choice> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <!--  *********** RECIPIENT ************ --> <element name='RECIPIENT'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <choice maxOccurs='unbounded'> <element name='ours'> <complexType> <sequence> <element ref='p3p:recipient-description' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <element name='same' type='p3p:recipient-value'/> <element name='other-recipient' type='p3p:recipient-value'/> <element name='delivery' type='p3p:recipient-value'/> <element name='public' type='p3p:recipient-value'/> <element name='unrelated' type='p3p:recipient-value'/> </choice> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <complexType name='recipient-value'> <sequence> <element ref='p3p:recipient-description' minOccurs='0' maxOccurs='unbounded'/> </sequence> <attribute name='required' use='optional' type='p3p:required-value'/> </complexType> <element name='recipient-description'> <complexType mixed='true'/> </element> <!-- *********** RETENTION ************ --> <element name='RETENTION'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <choice> <element name='no-retention' type='p3p:retention-value'/> <element name='stated-purpose' type='p3p:retention-value'/> <element name='legal-requirement' type='p3p:retention-value'/> <element name='indefinitely' type='p3p:retention-value'/> <element name='business-practices' type='p3p:retention-value'/> </choice> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <complexType name='retention-value'/> <!-- ************** DATA ************** --> <complexType name='data-group-type'> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <element name='DATA' type='p3p:data-in-statement' maxOccurs='unbounded'/> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> <attribute name='base' type='anyURI' use='optional' default='http://www.w3.org/TR/P3P/base'/> </complexType> <complexType name='data-in-statement' mixed='true'> <sequence minOccurs='0' maxOccurs='unbounded'> <element ref='p3p:CATEGORIES'/> </sequence> <attribute name='ref' type='anyURI' use='required'/> <attribute name='optional' use='optional' default='no' type='p3p:yes_no'/> </complexType> <!-- ************** Data Schema ************* --> <!-- *********** DATASCHEMA *********** --> <element name='DATASCHEMA'> <complexType> <choice minOccurs='0' maxOccurs='unbounded'> <element ref='p3p:DATA-DEF'/> <element ref='p3p:DATA-STRUCT'/> <element ref='p3p:EXTENSION'/> </choice> <attribute ref='xml:lang' use='optional'/> </complexType> </element> <element name='DATA-DEF' type='p3p:data-def'/> <element name='DATA-STRUCT' type='p3p:data-def'/> <complexType name='data-def'> <sequence> <element ref='p3p:CATEGORIES' minOccurs='0'/> <element ref='p3p:LONG-DESCRIPTION' minOccurs='0'/> </sequence> <attribute name='name' type='ID' use='required'/> <attribute name='structref' type='anyURI' use='optional'/> <attribute name='short-description' type='string' use='optional'/> </complexType> <!-- *********** CATEGORIES *********** --> <element name='CATEGORIES'> <complexType> <choice maxOccurs='unbounded'> <element name='physical' type='p3p:categories-value'/> <element name='online' type='p3p:categories-value'/> <element name='uniqueid' type='p3p:categories-value'/> <element name='purchase' type='p3p:categories-value'/> <element name='financial' type='p3p:categories-value'/> <element name='computer' type='p3p:categories-value'/> <element name='navigation' type='p3p:categories-value'/> <element name='interactive' type='p3p:categories-value'/> <element name='demographic' type='p3p:categories-value'/> <element name='content' type='p3p:categories-value'/> <element name='state' type='p3p:categories-value'/> <element name='political' type='p3p:categories-value'/> <element name='health' type='p3p:categories-value'/> <element name='preference' type='p3p:categories-value'/> <element name='location' type='p3p:categories-value'/> <element name='government' type='p3p:categories-value'/> <element name='other-category' type='string'/> </choice> </complexType> </element> <complexType name='categories-value'/> <!-- *********** EXTENSION ************ --> <element name='EXTENSION'> <complexType mixed='true'> <choice minOccurs='0' maxOccurs='unbounded'> <any minOccurs='0' maxOccurs='unbounded' processContents='skip'/> </choice> <attribute name='optional' use='optional' default='yes' type='p3p:yes_no'/> </complexType> </element> </schema>
This appendix contains the DTD for P3P policy reference files, for P3P policy documents, and for P3P data schema documents. This DTD MAY be used to verify that P3P files are valid (although, note that there are some valid files that may be rejected if checked against the DTD). The DTD is also present as a separate file at the URI http://www.w3.org/2002/01/P3Pv1.dtd .
<!-- *************** Entities *************** --> <!ENTITY % URI "CDATA"> <!ENTITY % NUMBER "CDATA"> <!-- *********** Policy Reference *********** --> <!-- ************** META ************** --> <!ELEMENT META (EXTENSION*, POLICY-REFERENCES, POLICIES?, EXTENSION*)> <!ATTLIST META xml:lang NMTOKEN #IMPLIED> <!ATTLIST META xmlns CDATA #FIXED "http://www.w3.org/2002/01/P3Pv1"> <!-- ******* POLICY-REFERENCES ******** --> <!ELEMENT POLICY-REFERENCES (EXPIRY?, POLICY-REF*, HINT*, EXTENSION*)> <!-- *********** POLICY-REF *********** --> <!ELEMENT POLICY-REF (INCLUDE*, EXCLUDE*,
COOKIE-INCLUDE*,
COOKIE-EXCLUDE*, METHOD*, EXTENSION*)> <!ATTLIST POLICY-REF about %URI; #REQUIRED > <!-- ************** HINT ************** --> <!ELEMENT HINT EMPTY> <!ATTLIST HINT scope CDATA #IMPLIED path CDATA #IMPLIED > <!-- ************* EXPIRY ************* --> <!ELEMENT EXPIRY EMPTY> <!ATTLIST EXPIRY max-age %NUMBER; #IMPLIED date CDATA #IMPLIED > <!-- ************ POLICIES ************ --> <!ELEMENT POLICIES (EXPIRY?, DATASCHEMA?, POLICY*)> <!ATTLIST POLICIES xml:lang NMTOKEN #IMPLIED> <!ATTLIST POLICIES xmlns CDATA #FIXED "http://www.w3.org/2002/01/P3Pv1"> <!--  **************** Policy **************** --> <!-- ************* POLICY ************* --> <!ELEMENT POLICY (EXTENSION*, TEST?, ENTITY, ACCESS, DISPUTES-GROUP?, STATEMENT+, EXTENSION*)> <!ATTLIST POLICY name ID #REQUIRED discuri %URI; #REQUIRED opturi %URI; #IMPLIED xml:lang NMTOKEN #IMPLIED> <!-- ******** TEST ******** --> <!ELEMENT TEST EMPTY> <!-- ************* ENTITY ************* --> <!ELEMENT ENTITY (EXTENSION*, DATA-GROUP, EXTENSION*)> <!-- ************* ACCESS ************* --> <!ELEMENT ACCESS (EXTENSION*, (nonident | all | contact-and-other | ident-contact | other-ident | none), EXTENSION*)> <!ELEMENT nonident EMPTY> <!ELEMENT all EMPTY> <!ELEMENT contact-and-other EMPTY> <!ELEMENT ident-contact EMPTY> <!ELEMENT other-ident EMPTY> <!ELEMENT none EMPTY> <!-- ************ DISPUTES ************ --> <!ELEMENT DISPUTES-GROUP (EXTENSION*, DISPUTES+, EXTENSION*)> <!ELEMENT DISPUTES (EXTENSION*, ( (LONG-DESCRIPTION, IMG?, REMEDIES?, EXTENSION*) | (IMG, REMEDIES?, EXTENSION*) | (REMEDIES, EXTENSION*) )?)> <!ATTLIST DISPUTES resolution-type (service | independent | court | law) #REQUIRED service %URI; #REQUIRED verification CDATA #IMPLIED short-description CDATA #IMPLIED > <!-- ******** LONG-DESCRIPTION ******** --> <!ELEMENT LONG-DESCRIPTION (#PCDATA)> <!-- ************** IMG *************** --> <!ELEMENT IMG EMPTY> <!ATTLIST IMG src %URI; #REQUIRED width %NUMBER; #IMPLIED height %NUMBER; #IMPLIED alt CDATA #REQUIRED > <!-- ************ REMEDIES ************ --> <!ELEMENT REMEDIES (EXTENSION*, (correct | money | law)+, EXTENSION*)> <!ELEMENT correct EMPTY> <!ELEMENT money EMPTY> <!ELEMENT law EMPTY> <!-- *********** STATEMENT ************ --> <!ELEMENT STATEMENT (EXTENSION*, CONSEQUENCE?, ((PURPOSE,RECIPIENT,RETENTION,DATA-GROUP+)| (NON-IDENTIFIABLE,PURPOSE?,RECIPIENT?,RETENTION?,DATA-GROUP*)), EXTENSION*)> <!-- ********** CONSEQUENCE *********** --> <!ELEMENT CONSEQUENCE (#PCDATA)> <!-- ******** NON-IDENTIFIABLE ******** --> <!ELEMENT NON-IDENTIFIABLE EMPTY> <!-- ************ PURPOSE ************* --> <!ELEMENT PURPOSE (EXTENSION*, (current | admin | develop | customization | tailoring | pseudo-analysis | pseudo-decision | individual-analysis | individual-decision | contact | historical | telemarketing | other-purpose)+, EXTENSION*)> <!ENTITY % pur_att "required (always | opt-in | opt-out) #IMPLIED"> <!ELEMENT current EMPTY> <!ATTLIST current %pur_att;> <!ELEMENT admin EMPTY> <!ATTLIST admin %pur_att;> <!ELEMENT develop EMPTY> <!ATTLIST develop %pur_att;> <!ELEMENT customization EMPTY> <!ATTLIST customization %pur_att;> <!ELEMENT tailoring EMPTY> <!ATTLIST tailoring %pur_att;> <!ELEMENT pseudo-analysis EMPTY> <!ATTLIST pseudo-analysis %pur_att;> <!ELEMENT pseudo-decision EMPTY> <!ATTLIST pseudo-decision %pur_att;> <!ELEMENT individual-analysis EMPTY> <!ATTLIST individual-analysis %pur_att;> <!ELEMENT individual-decision EMPTY> <!ATTLIST individual-decision %pur_att;> <!ELEMENT contact EMPTY> <!ATTLIST contact %pur_att;> <!ELEMENT profiling EMPTY> <!ATTLIST profiling %pur_att;> <!ELEMENT historical EMPTY> <!ATTLIST historical %pur_att;> <!ELEMENT telemarketing EMPTY> <!ATTLIST telemarketing %pur_att;> <!ELEMENT other-purpose (#PCDATA)> <!ATTLIST other-purpose %pur_att;> <!-- *********** RECIPIENT ************ --> <!ELEMENT RECIPIENT (EXTENSION*, (ours | same | other-recipient | delivery | public | unrelated)+, EXTENSION*)> <!ELEMENT ours (recipient-description*)> <!ELEMENT same (recipient-description*)> <!ATTLIST same %pur_att;> <!ELEMENT other-recipient (recipient-description*)> <!ATTLIST other-recipient %pur_att;> <!ELEMENT delivery (recipient-description*)> <!ATTLIST delivery %pur_att;> <!ELEMENT public (recipient-description*)> <!ATTLIST public %pur_att;> <!ELEMENT unrelated (recipient-description*)> <!ATTLIST unrelated %pur_att;> <!ELEMENT recipient-description (#PCDATA)> <!-- *********** RETENTION ************ --> <!ELEMENT RETENTION (EXTENSION*, (no-retention | stated-purpose | legal-requirement | indefinitely | business-practices), EXTENSION*)> <!ELEMENT no-retention EMPTY> <!ELEMENT stated-purpose EMPTY> <!ELEMENT legal-requirement EMPTY> <!ELEMENT indefinitely EMPTY> <!ELEMENT business-practices EMPTY> <!-- ************** DATA ************** --> <!ELEMENT DATA-GROUP (EXTENSION*, DATA+, EXTENSION*)> <!ATTLIST DATA-GROUP base %URI; "http://www.w3.org/TR/P3P/base" > <!ELEMENT DATA (#PCDATA | CATEGORIES)*> <!ATTLIST DATA ref %URI; #REQUIRED optional (yes | no) "no" > <!-- *********** DATA SCHEMA *********** --> <!ELEMENT DATASCHEMA (DATA-DEF | DATA-STRUCT | EXTENSION)*> <!ATTLIST DATASCHEMA xml:lang NMTOKEN #IMPLIED> <!ATTLIST DATASCHEMA xmlns CDATA #FIXED "http://www.w3.org/2002/01/P3Pv1"> <!ELEMENT DATA-DEF (CATEGORIES?, LONG-DESCRIPTION?)> <!ATTLIST DATA-DEF name ID #REQUIRED structref %URI; #IMPLIED short-description CDATA #IMPLIED > <!ELEMENT DATA-STRUCT (CATEGORIES?, LONG-DESCRIPTION?)> <!ATTLIST DATA-STRUCT name ID #REQUIRED structref %URI; #IMPLIED short-description CDATA #IMPLIED > <!-- *********** CATEGORIES *********** --> <!ELEMENT CATEGORIES (physical | online | uniqueid | purchase | financial | computer | navigation | interactive | demographic | content | state | political | health | preference | location | government | other-category)+> <!ELEMENT physical EMPTY> <!ELEMENT online EMPTY> <!ELEMENT uniqueid EMPTY> <!ELEMENT purchase EMPTY> <!ELEMENT financial EMPTY> <!ELEMENT computer EMPTY> <!ELEMENT navigation EMPTY> <!ELEMENT interactive EMPTY> <!ELEMENT demographic EMPTY> <!ELEMENT content EMPTY> <!ELEMENT state EMPTY> <!ELEMENT political EMPTY> <!ELEMENT health EMPTY> <!ELEMENT preference EMPTY> <!ELEMENT location EMPTY> <!ELEMENT government EMPTY> <!ELEMENT other-category EMPTY> <!-- *********** EXTENSION ************ --> <!ELEMENT EXTENSION ANY> <!ATTLIST EXTENSION optional (yes | no) "yes" >
The formal grammar of P3P is given in this specification using a slight modification of [ABNF]. The following is a simple description of the ABNF.
name = (elements)�
(
element1 element2)
<a>*<b>element
<a>element
<a>*element
*<b>element
*element
[element]
"string"
or
'string'
Other notations used in the productions are:
/* ... */
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 "P3P Guiding Principles" (http://www.w3.org/TR/NOTE-P3P10-principles).
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 should 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.
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.
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:
In addition, service providers and P3P implementers should recognize and address the special concerns surrounding children's privacy.
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.
Service providers should:
User agents should:
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.
Service providers should:
User agents should:
Service providers should treat users and their personal information with fairness and integrity. This is essential for protecting privacy and promoting trust.
Service providers should:
User agents should:
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.
Service providers should:
User agents should:
This specification was produced by the P3P Specification Working Group. The following individuals participated in the P3P Specification Working Group, chaired by Lorrie Cranor (AT&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 Koehntopp (Privacy Commission of Land Schleswig-Holstein, Germany), Yuichi Koike (NEC/W3C), Yusuke Koizumi (ENC), Daniel LaLiberte (Crystaliz), Marc Langheinrich (NEC/ETH Zurich), 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).
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).
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&T), Massimo Marchiori (W3C/MIT), Gabe Montero (IBM), Stephen Morse (Netscape), Paul Perry (Microsoft), Ari Schwartz (CDT), Gabriel Speyer (Citibank), Betty Whitaker (NCR).
The P3P Syntax Working Group, chaired by Steve Lucas (Matchlogic): Lorrie Cranor (AT&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).
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&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).
The P3P Protocols and Data Transport Working Group, chaired by Yves Leroux (Digital): Lorrie Cranor (AT&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).
The P3P Vocabulary Working Group, chaired by Lorrie Cranor (AT&T): Mark Ackerman (W3C), Philip DesAutels (W3C), Melissa Dunn (Microsoft), Joseph Reagle (W3C), Upendra Shardanand (Firefly).
The P3P Architecture Working Group, chaired by Martin Presler-Marshall (IBM): Mark Ackerman (W3C), Lorrie Cranor (AT&T), Philip DesAutels (W3C), Melissa Dunn (Microsoft), Joseph Reagle (W3C).
Finally, Appendix 7 is drawn from the W3C Note "P3P Guiding Principles", whose signatories are: Azer Bestavros (Bowne Internet Solutions), Ann Cavoukian (Information and Privacy Commission Ontario Canada), Lorrie Faith Cranor (AT&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.).


I am a lead data scientist for Organizational Solutions at McKinsey & Company, interested in
statistics, machine learning, education, and open science, among other things.
All opinions and views expressed on this blog are my own and do not represent my employer.


Description: Remove all event handlers previously attached using .live() from the elements.
Any handler that has been attached with .live()
can be removed with .die()
. This method is analogous to calling .unbind()
with no arguments, which is used to remove all handlers attached with .bind()
.
See the discussions of .live()
and .unbind()
for further details.
As of jQuery 1.7, use of .die()
(and its complementary method, .live()
) is not recommended. Instead, use .off()
to remove event handlers bound with .on()
Note: In order for .die() to function correctly, the selector used with it must match exactly the selector initially used with .live().
Description: Remove an event handler previously attached using .live() from the elements.
eventType: String
A string containing a JavaScript event type, such as click
or keydown
.
handler: String The function that is no longer to be executed.
events: PlainObject
A map of one or more event types, such as click
or keydown
and their corresponding functions that are no longer to be executed.
Any handler that has been attached with .live()
can be removed with .die()
. This method is analogous to .unbind()
, which is used to remove handlers attached with .bind()
.
See the discussions of .live()
and .unbind()
for further details.
Note: In order for .die()
to function correctly, the selector used with it must match exactly the selector initially used with .live()
.
<!DOCTYPE html>

<button id="theone">Does nothing...</button>
<button id="bind">Bind Click</button>
<button id="unbind">Unbind Click</button>

Click!

$("p").die()
$("p").die( "click" )
var foo = function () {
// code to handle some kind of event
};
$("p").live("click", foo); // ... now foo will be called when paragraphs are clicked ...
$("p").die("click", foo); // ... foo will no longer be called.


Please use another device This device is too small for this website..
Varun Engineering Work
Loading . . .
An ISO 2000:2022 certified company
STANDARD SELF CENTRING CHUCKS
Master Grip Chucks
ACCURACY ADJUSTMENT CHUCKS
LEVER OPERATED SCROLL CHUCKS
DRILL POINT GRINDER CHUCKS
EXTRA LIGHT INDEPENDENT CHUCKS
EXTRA HEAVY INDEPENDENT CHUCKS
HEAVY DUTY INDEPENDENT CHUCKS
BIG BORE INDEPENDENT CHUCKS
SCREW OPERATED SELF CENTRING CHUCK
STANDARD & BEARING RACES CHUCKS
3-JAW CRANKSHAFT GRINDER CHUCKS
Email :-
|
,
Tel. :-<PHONE_NUMBER>1,
Mob. :-<PHONE_NUMBER>5,<PHONE_NUMBER>5


| 1 |
Waltner-Toews_1986 |
Dairy calf management, morbidity and mortality in Ontario Holstein herds. III. Association of management with morbidity |
Waltner-Toews, D.; Martin, S.W.; Meek, A.H. |
1986 |
1986-08-31 |
PMC |
N |
PMC7134374 |
|
10.1016/0167-5877(86)90019-x |
4g906q7y |
0.950475 |
Waltner-Toews_1986, Pithua_2009 |
Waltner-Toews_1986, Waltner-Toews_1986, Donovan_1998 |
| 2 |
Kaukonen_2019 |
Feather Pecking and Cannibalism in Non-Beak-Trimmed Laying Hen Flocks—Farmers’ Perspectives |
Kaukonen, Eija; Valros, Anna |
2019 |
2019-01-30 |
COMM-USE |
N |
PMC6406704 |
30704113.0 |
10.3390/ani9020043 |
hjc2pcgt |
0.941779 |
|
Arsenopoulos_2018 |
| 3 |
Mohd_Nor_2013 |
First-calving age and first-lactation milk production on Dutch dairy farms |
Mohd Nor, N.; Steeneveld, W.; van Werven, T.; Mourits, M.C.M.; Hogeveen, H. |
2013 |
2013-02-28 |
PMC |
N |
PMC7094526 |
23219115.0 |
10.3168/jds.2012-5741 |
9nvpwuam |
0.930802 |
Stevenson_2011, Pithua_2009, Jamaluddin_1996 |
Urie_2018, Hawkins_2019, Waltner-Toews_1986, Waltner-Toews_1986 |
| 4 |
Waltner-Toews_1986 |
Dairy calf management, morbidity and mortality in Ontario Holstein herds. I. The data |
Waltner-Toews, D.; Martin, S.W.; Meek, A.H.; McMillan, I. |
1986 |
1986-08-31 |
PMC |
N |
PMC7134328 |
|
10.1016/0167-5877(86)90017-6 |
t8f820ui |
0.912940 |
Waltner-Toews_1986, Jamaluddin_1996, Sasaki_2017 |
Waltner-Toews_1986, Waltner-Toews_1986, Donovan_1998 |
| 5 |
Godden_2008 |
Colostrum Management for Dairy Calves |
Godden, Sandra |
2008 |
2008-03-31 |
PMC |
N |
PMC7127126 |
18299030.0 |
10.1016/j.cvfa.2007.10.005 |
tqc1usry |
0.896246 |
|
Godden_2019, Urie_2018, Quigley_2001 |
| 6 |
Franklin_2002 |
Replacement Management in Cattle | Health Management |
Franklin, S.T.; Jackson, J.A. |
2002 |
2002-12-31 |
PMC |
N |
PMC7149964 |
|
10.1016/b978-0-12-374407-4.00447-7 |
wbvs8c6x |
0.887778 |
|
Dutta_2016, Hart_2011 |
| 7 |
Waltner-Toews_1986 |
Dairy calf management, morbidity and mortality in Ontario Holstein herds. IV. Association of management with mortality |
Waltner-Toews, D.; Martin, S.W.; Meek, A.H. |
1986 |
1986-08-31 |
PMC |
N |
PMC7134175 |
|
10.1016/0167-5877(86)90020-6 |
1k215hy7 |
0.887430 |
Pithua_2009, Waltner-Toews_1986 |
Waltner-Toews_1986, Waltner-Toews_1986, Donovan_1998 |
| 8 |
Boulton_2020 |
Risk factors for bobby calf mortality across the New Zealand dairy supply chain |
Boulton, Alana C.; Kells, Nikki J; Cogger, Naomi; Johnson, Craig B.; O’Connor, Cheryl; Webster, Jim; Palmer, Anna; Beausoleil, Ngaio J. |
2020 |
2020-01-31 |
PMC |
N |
PMC7127677 |
31765960.0 |
10.1016/j.prevetmed.2019.104836 |
jb3s97j5 |
0.857635 |
Waltner-Toews_1986, Pithua_2009 |
Waltner-Toews_1986, Waltner-Toews_1986, Waltner-Toews_1986, Maier_2019 |
| 9 |
Tilling_2012 |
Case Study: Calf Pneumonia |
Tilling, Oliver |
2012 |
2012-10-04 |
PMC |
N |
PMC7165762 |
|
10.1111/j.2044-3870.2012.00148.x |
h9zx9phk |
0.850293 |
Erickson_2020, Pithua_2009 |
|
| 10 |
Dutta_2016 |
Replacement Management in Cattle: Health Management |
Dutta, Ritaban |
2016 |
2016-12-31 |
PMC |
N |
PMC7157480 |
|
10.1016/b978-0-08-100596-5.01035-0 |
oe3yv69y |
0.808413 |
|
Franklin_2002, Hawkins_2019 |
| 11 |
Hawkins_2019 |
An Economic Analysis of the Costs Associated with Pre-Weaning Management Strategies for Dairy Heifers |
Hawkins, Anna; Burdine, Kenneth; Amaral-Phillips, Donna; Costa, Joao H.C. |
2019 |
2019-07-23 |
COMM-USE |
N |
PMC6680651 |
31340508.0 |
10.3390/ani9070471 |
28lmys1a |
0.804510 |
|
Franklin_2002, Dutta_2016, Urie_2018, Urie_2018 |
| 12 |
Godden_2019 |
Colostrum Management for Dairy Calves |
Godden, Sandra M.; Lombard, Jason E.; Woolums, Amelia R. |
2019 |
2019-11-30 |
PMC |
N |
PMC7125574 |
31590901.0 |
10.1016/j.cvfa.2019.07.005 |
3um07feu |
0.789574 |
|
Godden_2008, Urie_2018, Franklin_2002 |
| 13 |
Otterby_1981 |
Advances in Nutrition and Management of Calves and Heifers |
Otterby, D.E.; Linn, J.G. |
1981 |
1981-06-30 |
PMC |
N |
|
|
10.3168/jds.s0022-0302(81)82709-9 |
eagt8qnd |
0.770725 |
Erickson_2020 |
Quigley_1995, Berge_2009, Hart_2016, Hart_2011 |
| 14 |
Urie_2018 |
Preweaned heifer management on US dairy operations: Part V. Factors associated with morbidity and mortality in preweaned dairy heifer calves |
Urie, N.J.; Lombard, J.E.; Shivley, C.B.; Kopral, C.A.; Adams, A.E.; Earleywine, T.J.; Olson, J.D.; Garry, F.B. |
2018 |
2018-10-31 |
None |
N |
PMC7094390 |
29935825.0 |
10.3168/jds.2017-14019 |
8w202sq2 |
0.767600 |
Waltner-Toews_1986, Jamaluddin_1996 |
Urie_2018, Maier_2019, Donovan_1998, Waltner-Toews_1986 |
| 15 |
Urie_2018 |
Preweaned heifer management on US dairy operations: Part I. Descriptive characteristics of preweaned heifer raising practices |
Urie, N.J.; Lombard, J.E.; Shivley, C.B.; Kopral, C.A.; Adams, A.E.; Earleywine, T.J.; Olson, J.D.; Garry, F.B. |
2018 |
2018-10-31 |
PMC |
N |
PMC7094552 |
29908815.0 |
10.3168/jds.2017-14010 |
anfozah4 |
0.682880 |
Kuehn_1994, Jamaluddin_1996, Franklin_2003, Eppard_1982, Dezfouli_2006 |
Urie_2018, Maier_2019, Waltner-Toews_1986 |
| 16 |
UETAKE_2012 |
Newborn calf welfare: A review focusing on mortality rates |
UETAKE, Katsuji |
2012 |
2012-12-26 |
PMC |
N |
PMC7159576 |
23384350.0 |
10.1111/asj.12019 |
m934yuk0 |
0.638549 |
|
|
| 17 |
Lorenz_2011 |
Calf health from birth to weaning. III. housing and management of calf pneumonia |
Lorenz, Ingrid; Earley, Bernadette; Gilmore, John; Hogan, Ian; Kennedy, Emer; More, Simon J |
2011 |
2011-10-21 |
COMM-USE |
N |
PMC3220626 |
22018053.0 |
10.1186/2046-0481-64-14 |
wfekg2wl |
0.632563 |
|
Waltner-Toews_1986 |
| 18 |
Donovan_1998 |
Associations between passive immunity and morbidity and mortality in dairy heifers in Florida, USA |
Donovan, G.Arthur; Dohoo, Ian R.; Montgomery, David M.; Bennett, Fred L. |
1998 |
1998-02-06 |
PMC |
N |
|
9541949.0 |
10.1016/s0167-5877(97)00060-3 |
cy57hr8n |
0.614124 |
Waltner-Toews_1986 |
|
| 19 |
Beaver_2019 |
Invited review: A systematic review of the effects of early separation on dairy cow and calf health |
Beaver, Annabelle; Meagher, Rebecca K.; von Keyserlingk, Marina A.G.; Weary, Daniel M. |
2019 |
2019-07-31 |
PMC |
N |
PMC7094284 |
31079908.0 |
10.3168/jds.2018-15603 |
ifwjvvjj |
0.611088 |
|
Berge_2009 |
| 20 |
Phipps_2018 |
A survey of northern Victorian dairy farmers to investigate dairy calf management: colostrum feeding and management |
Phipps, AJ; Beggs, DS; Murray, AJ; Mansell, PD; Pyman, MF |
2018 |
2018-03-25 |
PMC |
N |
PMC7159743 |
29577249.0 |
10.1111/avj.12683 |
b2p1jvyc |
0.600823 |
Erickson_2020 |
|
| 21 |
Thurmond_1986 |
Epidemiologic approaches used in a herd health practice to investigate neonatal calf mortality |
Thurmond, Mark C. |
1986 |
1986-12-31 |
PMC |
N |
|
|
10.1016/0167-5877(86)90013-9 |
1cqch98y |
0.592926 |
Waltner-Toews_1986 |
Donovan_1998, Maier_2019 |
| 22 |
Virtala_1996 |
The Effect of Calfhood Diseases on Growth of Female Dairy Calves During the First 3 Months of Life in New York State |
Virtala, A.-M.K.; Mechor, G.D.; Gröhn, Y.T.; Erb, H.N. |
1996 |
1996-06-30 |
PMC |
N |
|
8827469.0 |
10.3168/jds.s0022-0302(96)76457-3 |
jigow1i0 |
0.488578 |
Kuehn_1994, Sasaki_2017, Luebbe_2019 |
Donovan_1998 |
| 23 |
Maier_2019 |
Management factors associated with bovine respiratory disease in preweaned calves on California dairies: The BRD 100 study |
Maier, G.U.; Love, W.J.; Karle, B.M.; Dubrovsky, S.A.; Williams, D.R.; Champagne, J.D.; Anderson, R.J.; Rowe, J.D.; Lehenbauer, T.W.; Van Eenennaam, A.L.; Aly, S.S. |
2019 |
2019-08-31 |
None |
N |
PMC7094750 |
31202656.0 |
10.3168/jds.2018-14773 |
ajj4qy7c |
0.465326 |
|
Urie_2018 |
| 24 |
Stevenson_2011 |
Replacement Management in Cattle | Breeding Standards and Pregnancy Management |
Stevenson, J.S.; Ahmadzadeh, A. |
2011 |
2011-12-31 |
PMC |
N |
PMC7149803 |
|
10.1016/b978-0-12-374407-4.00446-5 |
sllxevf7 |
0.420179 |
Erickson_2020, Jamaluddin_1996, Pithua_2009, Franklin_2002 |
Hawkins_2019, Franklin_2002, Dutta_2016, Hart_2011 |
| 25 |
Jamaluddin_1996 |
Effect of preweaning feeding of pasteurized and nonpasteurized milk on postweaning weight gain of heifer calves on a Californian dairy |
Jamaluddin, A.A.; Hird, D.W.; Thurmond, M.C.; Carpenter, T.E. |
1996 |
1996-09-01 |
PMC |
N |
|
|
10.1016/0167-5877(96)01040-9 |
da1hsuj4 |
0.388018 |
Kuehn_1994, Franklin_2003, Eppard_1982, Dezfouli_2006 |
Berge_2009, Quigley_1995, Dezfouli_2006, Velasquez-Munoz_2019 |
| 26 |
Roy_J_1983 |
Problems of calf rearing in connection with their mortality and optimal growth: A review |
Roy, J.H.B |
1983 |
1983-08-31 |
PMC |
N |
|
|
10.1016/0301-6226(83)90018-0 |
l60t5lmr |
0.354912 |
Erickson_2020 |
Otterby_1981 |
| 27 |
Fischer_2019 |
Invited Review: Nutritional regulation of gut function in dairy calves: From colostrum to weaning |
Fischer, A.J.; Villot, C.; van Niekerk, J.K.; Yohe, T.T.; Renaud, D.L.; Steele, M.A. |
2019 |
2019-10-31 |
PMC |
N |
|
|
10.15232/aas.2019-01887 |
jpkveiqo |
0.350717 |
Erickson_2020 |
Gruse_2016, Berge_2009, Vlčková_2018 |
| 28 |
Dunn_2017 |
Evaluation of factors associated with immunoglobulin G, fat, protein, and lactose concentrations in bovine colostrum and colostrum management practices in grassland-based dairy systems in Northern Ireland |
Dunn, A.; Ashfield, A.; Earley, B.; Welsh, M.; Gordon, A.; Morrison, S.J. |
2017 |
2017-03-31 |
PMC |
N |
PMC7127401 |
28088405.0 |
10.3168/jds.2016-11724 |
7r6g1pn5 |
0.321937 |
Kuehn_1994, Jamaluddin_1996, Dezfouli_2006, Franklin_2003, Eppard_1982 |
Davenport_2000, Mellado_2007, Jones_2004, Quigley_2001 |
| 29 |
Burns_2010 |
A review of factors that impact on the capacity of beef cattle females to conceive, maintain a pregnancy and wean a calf—Implications for reproductive efficiency in northern Australia |
Burns, B.M.; Fordyce, G.; Holroyd, R.G. |
2010 |
2010-10-31 |
PMC |
N |
PMC7131258 |
20447780.0 |
10.1016/j.anireprosci.2010.04.010 |
qzw00q1s |
0.305462 |
Stevenson_2011 |
Luebbe_2019, Summers_2015, Fthenakis_2015 |


DETAILS
Submit a valid URL in the form above.
For a valid url the api returns a JSON with the original url and the
shortened URL:
{"original_url": "http://www.exampleUrl.com" ,"short_url":
"root_url/a/addlurl"}
Clicking on the url link will redirect you to the same website as the
original link
Providing an invalid URL will return the following JSON:
{"error": "invalid URL" }
AUTHOR
Coded by: Niccolo Lampa
Email<EMAIL_ADDRESS>For MongoDB, Mongoose, Express and NodeJS demo purposes only


My quiz title.
Which of the following were not Beatles?
John
Paul
Charlie
Ringo
Yoko
What is the answer to life, the universe, and everything?
Candy
Birds
42
Computers


The mathematics of money course allows students to learn mathematical techniques that aid in the understanding of life's financial decisions, such as those involving interest, annuities, investments, retirement plans, taxes, credit cards, and mortgages. The goal of this course is to help students develop the knowledge and skills needed to make sound financial decisions. The U.S. Department of Treasury has stated that "Today's complex financial-services market offers consumers a vast array of products and providers to meet their financial needs. This degree of choice requires that consumers be equipped with the knowledge and skills to evaluate the options and identify those that best suit their needs and circumstances." This course will help students obtain this knowledge and skills.
Upon successful completion of Math 034, the student should be able to:
Business Math: The Mathematics of Money, Second Edition, by Timothy Biehler.
| Unit | Category | Topic(s) |
|---|---|---|
| 1 | The Basics - Time Value of Money | - Introduce and work with loans and associated interest calculations |
| 2 | Common Investment |
- Work with basic investments such as annuities, stocks and bonds - Understand sales and income taxes - Introduce retirement planning |
| 3 | Business Applications and Personal Financial Planning |
- Work with inflation and depreciation
- Consider consumer implications associated with credit cards, mortgages and leasing - Consider profit margin and cost-revenue analysis associated with business |
| Quizzes | Midterm Exams | Final Exam (Comprehensive) |
|---|---|---|
| 10 Weekly Quizzes (10 pts / each) | 2 Midterm Exams (50 pts / each) | 1 Proctored Exam |
| Each may be taken twice | First Midterm is Unproctored | |
| Best score recorded | Second Midterm is Proctored | |
| 100 pts | 100 pts | 100 pts |
| Letter Grade | % Score | Total Points |
|---|---|---|
| A | 93-100% | 279-300 |
| A- | 90-92% | 270-278 |
| B+ | 87-89% | 261-269 |
| B | 83-86% | 249-260 |
| B- | 80-82% | 240-248 |
| C+ | 77-79% | 231-239 |
| C | 70-76% | 210-230 |
| D | 60-69% | 180-209 |
| F | 0-59% | 0-179 |
In this class you may take your tests remotely and they will be proctored by a service called Examity®. Please log in as soon as possible to set up your profile. You will not be able to schedule exams until your profile is complete. Examity® system requirements are:
After you create your Examity profile, you will have the option to schedule proctoring times for each of your exams. On the day of your exam, go to your Examity dashboard using the single sign-on link and select the ‘Start Exam’ button to meet the proctor.
Examity’s proctors are highly-trained individuals who go through a rigorous process of selection, including background checks and comprehensive training. All proctors have a college degree, advanced technical and communication skills, and have completed online courses.
This course may require you to take exams using certain proctoring software that uses your computer’s webcam or other technology to monitor and/or record your activity during exams. The proctoring software may be listening to you, monitoring your computer screen, viewing you and your surroundings, recording and storing any and all activity (including visual and audio recordings) during the proctoring process. By enrolling in this course, you consent to the use of the proctoring software selected by your instructor, including but not limited to any audio and/or visual monitoring which may be recorded. Please contact your instructor with any questions.
This information is provided by Penn State World Campus
If you have any technical questions or concerns, contact Examity’s support team 24/7 via email or phone at<PHONE_NUMBER>.


Capture Context Request Success
Your request returned the Capture Context encoded as JWT. This JWT contains all of the information to start Microform on your checkout page. There is a JavaScript URL, SRI hash, and more, all cryptographically signed by Visa.


{% extends "base.html" %}
{% load static %}
{% block title %}
CraftTechSolution - Integrating Payments Mode company in kenya
{% endblock %}
{% block navbar %}
{% include "navbar.html" %}
{% endblock %}
{% block slideshow %}
{% include "slideshow.html" %}
{% endblock %}
{% block content %}
We support Customer to Business (C2B) and Business to Customer (B2C) payment integrations. We have successfully delivered MPesa API integration to clients and we always ensure that you receive real time MPesa payments from your web and mobile application. We also provide other payment integration solutions like airtel money, orange money for mobile money category, third-party integrations for solutions like pesapal, jambopay, paypal and kopokopo and also direct integrations like visa and mastercard.
{% endblock %} {% block footer %} {% include "footer.html" %} {% endblock %}