Mark Nottingham wrote:
On 23/01/2008, at 5:36 PM, Jonas Sicking wrote:
So P3P has a few ways to associate policies with documents [1]:
1. "magic uri"
The policy file is located at a magic uri that is defined in the
specification. We've gotten a lot of negative feedback about this
approach before, I know hixie is very much against it and has provided
good arguments in the past.
While the web architectural implications of a "magic" well-known
location are known, it's also an eminently practical solution, one
that's been used not only for P3P, but also robots.txt and site maps
(which leverages robots). Why is this problem so different that it
requires people to learn a whole new way to associate policy with
resources?
Saying "hixie is very much against it" utterly fails to convince me;
provide use cases, requirements, and specific rationale for the
trade-offs made and gain consensus on them. Document the good arguments.
It'd be great if others could step up here as this isn't something I've
looked into a lot.
4. HTTP header.
This is a header that contains a pointer to the actual policy file.
Seems like our solution of actually putting the access policy inside
the header instead results in a much less chatty implementation.
It depends. Having a well-known location means that policy only has to
be retrieved once per site, rather than once per resource.
You still have to retrieve the url of the policy every time. Granted, if
the policy is big then the url could be meaningfully shorter. It does
make the simple cases more chatty though (two GETs rather than one).
/ Jonas
