W3C home > Mailing lists > Public > public-p3p-ws@w3.org > November 2002

AOL Position Paper

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 11 Nov 2002 21:23:50 -0800
Message-ID: <006d01c28a0b$af4c4600$f4457743@mnotlaptop>
To: <public-p3p-ws@w3.org>

I don't have the opportunity to attend the Workshop, but I would like to
make comments about the position papers, and this seems like the
appropriate forum.

In the AOL position paper[1], it is claimed

The P3P specification could have a tremendous negative impact on network
operations and the servers on those networks.

First, a HTTP 1.1 connection can never be guaranteed in requesting the P3P
policies and, as a consequence, every time a user requests a page, the
browser will request two P3P objects, the policy reference file and the
P3P policy, directly from the origin server. The impact on the network
operations will be a significant increase in latency and use of resources.
The impact will be magnified where the requested page contains content
from other domains.

Second, network resources, servers and bandwidth, will be taxed by the
multitude of requests and the mechanisms for requesting P3P policies
outlined in the specification. Many sites have multiple servers at
different domains providing advertisements or partners that share content
or facilitate commerce transactions. For each http request to a different
domain, the browser must request a minimum of two other files, the P3P
reference file and, after analyzing the reference file, the P3P policy.
This multiplying effect on a busy network will consume a significant
amount of network and computer resources and add significant latency to
the browsing process.

This is demonstrably false. P3P states[2]:

[...] if a user agent is requesting a policy reference file or a policy,
and does not know for certain that there are no HTTP 1.0 caches in the
path to the origin server, then the request MUST force an end-to-end

So, *when* the client needs a new policy reference file or policy, it must
do an end-to-end revalidation. This does not mean that P3P User-Agents
cannot use the expiry information in those files themselves to cache the
file locally. Additionally, although HTTP caches cannot calculate a
freshness lifetime for the representation, they can use validation,
signficantly improving latency and network load. P3P User-Agents will not
requires two P3P objects "every time a user requests a page" *unless* they
do not implement a local, P3P-aware cache.

That having been said, I do agree that P3P's prohibition of any HTTP
freshness lifetime to be unfortunate; the requirement for absolute
freshness is a very high bar, and I question whether it's absolutely

1. http://www.w3.org/2002/p3p-ws/pp/aol.html
2. http://www.w3.org/TR/P3P/#the_expiry_element

Mark Nottingham
Received on Tuesday, 12 November 2002 00:23:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:37:54 UTC